の作業記録
メルマガを仕上げる土曜日
- 作業記録の共有
- ツイートの振り返り
- メルマガ+はじめにおわりに
- メルマガ+配信予約作業
- Googleフォームでアンケートを作る
- 今年の振り返り
- Honkure+人間の解剖は
- ニュースレター+活動報告
- ListLuncherについて検討する
- [-] これからの執筆活動について検討する→来年でヨシとする
8:00
おはようございます。年末ですが、通常通り仕事です。とりあえず、メルマガを仕上げて、後は本棚の整理でもしたいところです。
ツイートの振り返り:
まずは一週間分のツイートの振り返りから。
＊ ＊ ＊
だいたいOKです。
9:00
メルマガ:
「はじめに」と「おわりに」を書きましょう。
＊ ＊ ＊
書けました。少しおいてから、全体を読み返しましょう。
10:00
メルマガ:
全体の読み返しと、配信予約作業です。
＊ ＊ ＊
読み返し、OKです。
＊ ＊ ＊
配信予約作業もOKです。
15:00
ListLuncherについて検討する:
スタートはPythonのスクリプト（しかもGUI）としてはじめましたが、最近の流行りと自分のコード資産を考えたときに、Node.jsベースでやった方がいいのかもしれません。ここは難しいところです。
今年の振り返り:
メルマガでも書きましたが、改めて全体的な振り返りを。
＊ ＊ ＊
画面左にObsidianのCanvasを設置し、右にWorkFlowyを設置し、まず左側でざっとした項目を書き出し、その後右側で文章を書き下ろしました。わりとこの連携は良いです。
16:00
Honkure:
書きます。
＊ ＊ ＊
17:00
ListLuncherについて検討する:
考えがとっちらかってきているので、いったん整理します。
まず、起点は執筆中の本のアウトラインが呼び出せると便利だ、というものでした。で、それがTextboxのサイドバーと非常に似ているので、それをなんとか統合できないか、と考えました。
まず、アウトラインについて。これはスクリプトから動的に生成しました。これをどう考えるのか。毎回そのようにして生成するのか、たとえばファイルをGitにコミットするたびに、ファイルを生成するようにするのか。たとえば、それをoutline.mdみたいなファイルに保存してもいいですし、プロジェクトファイルに保存しておいてもいいでしょう。
独立したファイルにしておくと、扱いが楽になります。Textboxならインテグレートページにすることで内容が分離していても統合的に表示することは可能です。手作業で作らないなら、別ファイルにしておいても別によいでしょう。
project-th/outline.md
などにする。でもって、すべての書籍プロジェクトにおいて、同名のファイルにすればOK。ただし、この場合はTextboxに直接入れることはできません。同名のファイルが存在できないからです。ファイル名を変えるか、フォルダ分けの必要が出てきます。
同様にtodo.mdみたいなものを作ったとしても、Textboxに配置する場合はフォルダ分けか名前の細分化が必要です。以前はその方法をやっていましたが、少し前にTextboxのプロジェクトノートに統合したのですが、もう一度考え直す必要がありそうです。
プロジェクトのタスク、あるいはアウトラインのようなものはTextboxで表示する必要があるのかどうか。
逆に言えば、いまだにプロジェクトに所属するタスクをどう表示したらいいのかについて具体的な指針を持っていない、ということになります。これは基本的にデイリーベースで仕事をしているせいでしょう。プロジェクトノートはどうでもいいわけではありませんが二の次的になりがちです。
もともとタスク的なものはタスク管理ツールか、Evernoteなどのノートツールに保存していました。で、原稿はテキストエディタで書いて、その後Evernoteに保存していました。作業場所は異なっていて、保存場所だけが一緒だったわけです。よって、テキストエディタを開きながら、タスクを確認する場合は、Evernoteという別のツールを開くことになったわけです。
そのことを念頭において、タスクの情報をどこで扱うか。現状VS Codeで原稿を書いているわけで、VS Codeでタスクを開くのは案外不合理なのではないか。そうしたとき、じゃあTextboxで開くか、となり、そうなるとどういう形にすればいいのか、という話になります。
なんとなく、プロジェクト用のフォルダを作り、そこにoutline.mdとかtodo.mdとかを作る、という形が良さそうな感じがします。なんとなくオブジェクト思考で、オブジェクトを初期化しているような（≒インスタンスを作る）印象です。
しかし、それだとあまり開かれないことが多いというのが実体験です。なぜならテキストエディタは「今書いている原稿」が開かれているからです。
ではなぜ、そのフォルダにおいておくと良さそうなのかと言えば、おそらく「開きやすい」からでしょう。これはごく自然な推論です。
しかし、開きやすい別の形があればどうか。
VS Codeも画面分割して、片方にタスク的な情報（admin情報と個人的には呼んでいます）、もう片方に原稿、という感じで開ければ今よりももっとタスク的な情報を目にしやすくなるでしょうが、その画面の狭さは少なくともMacBook Air君では厳しそうな気がします。むしろ、仮想ディスプレイを移動したほうがずっとやりやすい。
＊ ＊ ＊
Textboxは、もしかしてプロジェクトノートの粒度が大きいのだろうか。現状はproject-th.mdというファイルを作ってそこに情報Ｗを集めているが、もしかしてもっとカード的に作ったほうがいい？たとえばproject-th_taskとかproject-th_outlineとか。
なぜそう思うのかと言えば、そうして個別に作ったほうが引き出す（呼び出す）ときに明確になるから。「今、タスクを確認しているんだ」とか「今アウトラインを確認しているんだ」というコンテキストがくっきりと立つ。現状のプロジェクトノートは統合的な分、コンテキストが大きすぎる。もしScrapboxで同種の情報を保存するならば、間違いなくproject-th_taskのレベルで保存するだろう。もっと細かい（たとえば一週間ごと）になる可能性すらある。
_task、という名前を準拡張子として、プロジェクトあるいはそれ以外でもこの名前を付ければタスクということにすればいい。そのやり方なら、別にプロジェクトのフォルダに入れる必要はなくなる。
オブジェクト指向で言えば、オブジェクトの切り方を変える。「プロジェクト」という単位でオブジェクトを設定すれば、そのオブジェクトが情報としてタスクやアウトラインを持つだろう。しかし「タスク」という単位をオブジェクトにすれば、それぞれのプロジェクトのタスクをそのオブジェクトが持つことになる。今までは前者的だったが、それを後者的に捉え直す。
あるいは、関数型の考え方を取り入れたらどうなるか。タスクというリスト（配列）を処理して、表示する、という形になるだろう。それは今考えているListLuncherと近しいものになるかもしれない。
＊ ＊ ＊
とりあえず、Textboxにproject-th_task.mdとproject-th_outline.mdを作った。project-th_outlineの方は、スクリプトで動的に中身を作り替える予定。それはmakeコマンドに入れ込んでおく。make olとかそういうのでよいだろう。
で、そのファイルを読み込んで、ランチャーから呼び出せるようにする。Textboxのサイドバーからでも良いのだが、そうやって増やしていくと際限がなくなってくる。すでにセレクトボックスが6個になっているし、こうやって増えていけば対処できなくなってくるだろう。
特定の準拡張子を持っているファイルを読み込む、という方法にして、それを検索で絞り込めるようにしても良いが、やはりそれがブラウザで閉じてしまうのがもったいない。Textbox自体が独立したアプリケーションになっているなら話は別だが、現状はブラウザで開く一つのページでしかないので、その限界をどうするのかはちょっと考えたい。もちろんここでTextboxをアプリケーション化する、という方策をとることもありえる。