の作業記録
メルマガを書く金曜日
- 作業記録の共有
- 買った本の登録
- トンネルChannel+リアルタイムマガジン
- メルマガ+原稿2
- メルマガ+原稿3
- 21:00~ブックカタリスト読書会
8:00
おはようございます。本日はメルマガの原稿を書きましょう。あと、inputboxに画像をドラッグしたら保存できるようにしたいところです。
とりあえず、今日もVS Codeではなく、CotEditorで作業を進めましょう。毎日作業記録を作成するコマンドをうったらVS Codeでその日の作業記録が開く設定になっていますが、それをCotEditorに変えたいところ。
wakeup.pyの書き換え
普段はVS Codeなので、作業記録ファイルを開いたまま、その他のスクリプトも編集できるのですが、ターミナル+CotEditorだとそうはいきません。
ターミナルで対象のpythonファイルを開く必要があります。でなんとなくvimにしました。やはり起動が速いですね。が、modeの移行で少し戸惑いました。でも、:wとか:qは覚えていましたね。
こういう風にツールを切り替えるのも悪くないです。
作業記録用のエディタ:
CotEditorは全般的に悪くないのですが、ある程度書くとカーソルが一番下にいっぱなしになるのを避けたいところです。タイプライターモードが欲しい。
＊ ＊ ＊
検索してみるといくつかマークダウンエディタでタイプライターモードを持っているものがある。が、それはそれとして自分で作ってみるのもよいだろう。
Textbox:
たとえば以下のようなメモを入力するとして、
このメモの「送り先」はどこになるだろうか。アイデア台帳？ やること帳？ Textbox？ Textbox開発記録？ アプリアイデア？
まず、「アイデア台帳」は違う気がする。同じように「やること帳」でもない。強いていえば「やりたいこと帳」だろう。
で、「Textbox」は違う。これはタグであって「送り先」ではない。逆に「Textbox開発記録」はそれっぽい。ようするにプロジェクト名ということだ。
「アプリアイデア」（アプリアイデア帳とすべき）は一つ上の階層で、ツール開発に関するアイデアを書き留める。
この「送り先」は、そのメモを入力しようと思ったときに一緒に表示されると嬉しいのは何か？という視点から考えることができる。
＊ ＊ ＊
本文中にブラケットでinputboxが囲まれているが、これはタグであろう。送り先ではないが、これで絞り込めれば嬉しい的なもの。まずこの二つを区別する。送り先とタグ。
で、このinputboxは、Textboxの関連要素・子要素である。タグの階層構造。だからといって、二つのタグをつけたり、inputboxをつけたら、Textboxと直接関連付けられるのは嬉しいか？ それは2hop先のリンクと言えるか？
微妙にぴんとこない。
＊ ＊ ＊
先ほどの一緒に表示されると嬉しい問題について考える。
まず、Textbox開発記録（日誌でもいいな）だと、Textboxの他の機能などの実装の記録などが一緒に表示されることになる。一方で、アプリアイデア帳だと、Textbox以外のツール、あるいはこれから造ろうと考えているツールのアイデアと一緒に表示される。その代わり、こちらは実績や実装の記録は表示されない。
つまり、プロジェクトとして単位を見て、その「記録と展望」を一緒のものとして表示させるか、あるいはプロジェクトを横断して（ないしはそういう境界線を考えずに）「ツール作り」い関する包括的な「展望」を一緒のものとして表示させるか。
で、たとえば、タグによる絞り込みをandではなくorにするならば、「Textbox開発記録」と「アプリアイデア帳」の二つをタグにすれば、上にあげた要素のすべてが一望できる。実装としては難しくない。が、それははたして嬉しいのだろうか。
たとえば、inputboxという本文中のタグで絞り込めるとして、そういう状況で「送り先」を考えるとしたら何が嬉しいか。単語＝概念の共有以外のもの。
inputboxはtextboxという概念に含まれている。つまり、本文中にinputboxというタグがあるならば、「送り先」にTextbox開発記録は不要ではないか。つまり、開発の記録を残す場合もinputboxにかかわるものはそれをタグにしておくことで、そちらで一緒に並べることができる。
ただし、Textboxの他の機能の記録といったものは一緒には並ばない。それが並ぶことによる「偶発的融合」みたいなものは期待できなくなる。
「Textbox開発記録」という送り先があるのはよい。それはログを溜めていくための場所として機能するだろう。一方で、アイデアはどうか。それを一緒に混ぜ込んでしまうのはよいことか。
＊ ＊ ＊
“[inputbox]に画像ファイルをドラッグできるようにしたい。“は、開発の記録ではないだろう。開発の途中で思いついたアイデアの記録ではある。このこうもり性をどう片付けるか。
二つのタグを付けるのは安直ではあるが、それは何か大切なことを考えていないだけな気がしないでもない。
が、現状考えていてもラチがあかないので、とりあえず二つ付ける方向でいってみる。
9:00
買った本の登録:
昨日、『標本作家』という本を買ったので、それをinputboxに登録してみます。（ブクログには登録済み）。
＊ ＊ ＊
この場合「あて先」はどうなるか。本を読んでいるわけではないので「読書日記」はおかしいだろう。「書誌情報」「ライブラリ」あたりか。「送り先」でいうならば、まず「ライブラリ」が適切だろう。「書誌情報」は送り先ではなく、「分類」にすぎない。「書誌情報帳」であれば適切だ。
「ライブラリ」「書庫」「ブックシェルフ」「シェルフ」あたり。
「ライブラリ」は間違いではないが、微妙に違和感がある。「マイライブラリ」だとその違和感は小さい。「買った本リスト」は一番直感的。
＊ ＊ ＊
とりあえず「買った本リスト」と「シェルフ」の二つをつけておく。
＊ ＊ ＊
ようするに今考えているのは、「一つだけのタグだと微妙に違和感がある」という情報の扱いなのだろう。一つだけでよいものは、すでにスムーズに保存できるようになって、次のステップに入ったということだ。
＊ ＊ ＊
で、このときに、書影の画像を保存したい。が、本に関してはいちいちドラッグする必要はない。ISBNを入れれば、そこから書誌情報を持ってくるpythonは以前に書いた。それを使うことで書影画像の取得はできる。あと、そもそもこうして直接入力せず、booklogのフィードから自動的に生成してもいい。
で、一応それをやったとして、じゃあそれをどのようにHistoryboxで表示するのか、という問題がある。見せ方の問題。
＊ ＊ ＊
たとえばこういう風に本文中にISBNを埋め込んだとする（記法はまた後で考える）。それを感知して、スクリプトが書誌情報を持ってくる。このとき、その書誌情報をこのメモ内に埋め込むのか、それともそれとは別にbookフォルダ下に書誌情報を生成し、それとこのメモを関連付けるのか、という選択がある。後者のbookフォルダ下の書誌情報は「ライブラリ」と呼ぶにふさわしいものだろう。
買った本リストは、私の記録.jsonであり、それをトリガーとして生成される（マイ）ライブラリ.jsonがある、という考え方だ。後者のライブラリはきわめて「純粋」なものといえる。言い換えれば私の主観が含まれない。そういうものは別にAmazonを見ればいいわけだが、自分のローカルに構築することには何か意味がありそうな気もする（気のせいかもしれない）。
＊ ＊ ＊
考えてみると、historyで眺めたいのは書誌情報ではないはずだ。単に自分がその本を買ったという事実だけがあればいい。すると、書誌情報はメモに埋め込まれるがhiddenされているか、あるいは上で考えたように書誌情報は別途「ライブラリ」に保存されるか、だ。
とりあえず、面白そうなので後者で考えるとして、今は画像の扱いについてだけ考えよう。
＊ ＊ ＊
現状のjsonには、image属性があるので、ここを使えばいい。コードからの生成は後回しにして、まずは手動でjsonに書き込む（この辺がjsonの便利なところだ）。基本的にはimgタグのsrcとして使われるわけだから、ファイルへのパスがそこに書き込まれていればいい。imgタグごと保存してもいいが、クラスの付与を状態によって変えることを考えれば、パスだけでいいだろう。
index.htmlで表示されるのだから、/image/hoge.jpgとかになる。
＊ ＊ ＊
imageがnullでないならimgを挿入する、にしてみた。当然でかい。
小さすぎる。それにちょっと余白が多い。
divを整理して、flexにしました。なかなかいい感じ。
あとは「ライブラリ」の方。owl-commandでISBNを入力すると書誌情報がゲットできるが、それをjsonにして保存する計画。
library.jsonとして、問題はその中身。在る程度普段使っているjsonと形式を合わせた方がいい。
その上で「media type」なるものを持ちたい。映画、書籍、漫画、音楽、といったカテゴライズをする。この項目が決まれば、コード自体はそう難しくない（はず）。
10:00
メルマガ:
おそくなりましたが、メルマガを書きはじめましょう。これもCotEditorで書いていきます。
12:00
Textbox:
library,jsonについて。
現状、history.jsonは、以下のような項目を持つ。
| |
このtypeを"media"とするとして、他の項目はどうか。created、updated、accessedは作成されたこのデータのメタ情報であって、本の書誌ではないだろう。imageは共通でよいとして、addressをどうするか。で、本そのもののメタ情報をこの階層に置くか、それとも下位の階層に置くか。
15:00
断片:タスクの作成と設定
JavaScriptで、document.createElementしても、それをappendしないと表示されない。インスタンスの作成と、表示領域への追加。タスクについても同じ考え方ができるかもしれない。
メルマガ:
原稿を書きましょう。トータルで5000字くらいは書いておきたいところ。
＊ ＊ ＊
3500文字ほどの原稿を書きました。
16:00
今思い出しましたが、今日は夜からブックカタリスト読書会ですね。
メルマガ:
もう一つ原稿を書きましょう。
＊ ＊ ＊
1500文字くらいの原稿が書けました。さらに原稿を続けましょう。
＊ ＊ ＊
2600文字の原稿が書けました。
17:00
メルマガ:
さらに原稿を続けます。
＊ ＊ ＊
2000字ほどの記事が書けました。これで本編はOKですね。