の作業記録
ゆっくりしたい日曜日
- 作業記録の共有
- 来週のSTL確認
- Discord巡回
- Textbox+ツイートカードの処理検討
- Textbox+メモーダルのcard保存
- トランジッションノート術+月ページの検討
- 3月からの進行検討
7:00
おはようございます。本日はゆっくり過ごす予定です。来週の予定の確認と週報の作成。あとは、保存したツイートの扱いなどについて考えましょう。
来週のSTL確認:
作業の手順を意識しながら進めていきましょう。
＊ ＊ ＊
まず、Textboxでtodo-board.mdを開きます。すると、その週の月曜日（今なら2/26）を起点とした一週間の予定表が表示されます。すでに日曜日なので予定表というよりは結果表なのですが、まあそれはいいでしょう。
この段階で「今週はどうだったのか」という振り返りが想起されます。週報作成の機運です。
ただし、todo-board.mdを開いた状態で、メモーダルをさらに開くと、（モーダルなので）予定表が目に入らなくなります。
今週やったことの確認（情報の更新）、今週やったことの確認（週報の執筆）、来週やることの設定、といったアクションが同時に起きるのですが、それをどうフォローするのか。
週報を別の場所で（たとえばCotEditorなどで）書けば問題はありません。仮にそこで書いても、Textbox内のフォルダに保存すれば事無きを得ます。Obsidianでも可能でしょう。
これが第一の選択肢で、特に難しいことはなにもありません。
＊ ＊ ＊
では、Textboxだけで完結させるとしたら？
メモーダルは表示を隠すので、隠さない表示にする。
やりかたその１：画面上に配置され、ドラッグで移動できる入力装置を作る。そこに入力されたものは、history.jsonなどどこかしらのJOSNとして保存される。
やり方その２：todo-board.mdに今週の振り返り欄を設ける。そこに入力されたものは、history.jsonかdiary.jsonのどこかに保存される。
前者は、このページだけでなく全体で使える機能としてのデザイン、後者は、このページに特化した機能としてのデザインです。
まず後者から考えましょう。ページのどこかに「この週の週報を書く」というボタンを置く。それをクリックするとテキストエリアが表示される。そこまで大きいものでなくていい。そこに入力して「保存」というボタンを押すと、diary.jsonから該当週の項目を探し、そこにlines:として保存される。でもってページにもその内容が追加で表示される。
まずまず順当なやり方でしょう。diary.jsonにきれいにデータがまとまる点も魅力的です。逆にmemo.mdからは閲覧できません。memo.mdはhistory.jsonのデータを参照しているからです。
ここで大きな分岐が発生します。そもそものhistory.jsonやdiary.jsonの分割は適切か、あるいは、memo.mdの運用は必要か、といった分岐です。
あるいは「週報」はtodo-board.mdで見たいのか、memo.mdで見たいのか、という問題もあります。こちらがより本質的かもしれません。
＊ ＊ ＊
書くときは当然、todo-board.mdを表示しながらがよいでしょう。では、書いたものを見返したいときはどうか。diary.jsonに書いておけば、週の記録を辿りながら週報のログも読んでいけます。一見合致している（オブジェクト指向ならこちらでしょう）ようにも思えますが、そうした「読み物」を欲しているのかは微妙なところです。
強いて言えば、月間カレンダーに日記を書いているようなものですから。
＊ ＊ ＊
そもそもとして、まったく新しい考え方があります。
一枚のカードがあり、それはhistory.jsonの一項目に対応しています。タイトルは2024年13週とかそういうタイトルです。で、そのlinesに、月曜日から日曜日までの予定、その週にやりたいことのピックアップ、週報を書く欄がセットになっている。
ようするに手書きノートのイメージをそのまま作る、という感じ。
現状は常に月曜日から日曜日のセットで表示しているわけですが、今のやりかたならば火曜日から月曜日のような表示のさせかたもできます。それぞれ独立して日付データを持っているからです。しかし、そういう表示の変え方をしたいかというと微妙なところ。二週間分のデータを表示させられる点は、Googleカレンダーのようで嬉しいですが、それもあまり実装しようとは考えていません。
今後、「カレンダー機能」を特化させるならば、今のデータ方式がよいでしょう。しかし、ノートツールとして柔軟性を持たせるならば、「週ごとのページ」方式の方がいいのかもしれません。
＊ ＊ ＊
曜日ごとの個別のデータがあることで、たとえば別のところで情報が追加されたとき、そこに日付の情報が含まれているならば、diary.jsonの該当日付にも情報を追加することで、自動的にこのtodo-boardでも表示できるようにする、みたいなことは可能です。たとえば、気になっていた本の発売日とかを表示させる使い方です。
ただ、現状その機能は実装されていないし、そこまで強く要求するものでもない。
今の実装はかなりhey calenderの影響を受けているのだけども、このまま続けるかどうか。
＊ ＊ ＊
現状の入力UI自体は気に入っているので、あまりメスを入れない方がいいかもしれない。
＊ ＊ ＊
UpNoteで「週ノート」的なものを作ってみた。
Textboxと見た目は似ていて、週報を書く欄があることと、やろうと思えば日付ノートへのリンクが貼れることが違いと言えば違い。文字サイズの微細なコントロールが聞かないのでデザイン的には苦しいものがある。
＊ ＊ ＊
ノートは記述的なものであり、カレンダーは記録的なものであるとするならば、diary.jsonに週報を記述するのは違っている気がする。
ということは、現状のままで考えればtodo-boardを表示しつつ、history.jsonに週報を追記できればいい？
＊ ＊ ＊
週報というのは、todo-boardに表示される情報を見つつ、文章でその週について書いたものであって、todo-boardと週報はお互いを保管し合うものであると共に、情報的な重複はある。その意味で、todo-boardで週報を表示させなくても良い、という選択肢は十分にありえる。
では、todo-boardを閲覧しているときに、先週の週報を読みたくなったらどうするか？ いちいちmemo.mdやメモダールに飛ぶ？ あるいはリンクしておく？それで特定の項目だけ取り出せるようにする？
悪くはない気がする。
たとえば、todo-boardに「この週の週報を書く」というボタンを用意しておく。で、ノートスペースを開く。そこに書く。hisotory.jsonに記録されると共に、diary.jsonのその週の項目にリンクが貼られる。そのリンクがあるときは、「この週の週報を書く」というボタンではなく、「この週の週報を読む」ボタンになる、といった具合。
diary.jsonの週番号項目に「descriptions」にそのリンクを置いてもいいし、素直にlinksやrelatedPagesという項目をJSONに追加してもいい。
イメージとしては悪くないですね。実装はいろいろややこしそうですが。普通にテキストファイルに書くのが楽ではありますが、まあちょっと実験的に考えてみましょう。
＊ ＊ ＊
とりあえず、今週の週報は書けました。続いて来週のタスクの設定です。
＊ ＊ ＊
OKです。あとは、いくつかのリストを確認したいところ。「買いたいもの」とか「読みたいもの」とかそういうものですね。問題はそのための場所が現状Textboxにないところ。たしか以前リスト用のjsonを作った気がしますが、そのビューがありません。
探してみると、list.jsonがありました。が、普通にhistory.jsonに混ぜ込むのがよいかもしれません。それを呼びだして、編集できればGoogです。
＊ ＊ ＊
list.jsonの中身をhistory.jsonに移しました。list.jsonは消しておきましょう。
とりあえずはOKです。あとは、history.jsonの項目をこのmemo.mdから修正できるようになると使い勝手が上がりそうです。改めて編集のためのモーダルを設計してもいいですし、メモーダルを流用してもいいでしょう。
メモーダルにID欄を設けて、IDが設定されているものは新規追加ではなく、規定の項目の上書きをする、とすればバッチリです。そのときにアップデートのメタ情報も変更するのがよいでしょう。
Scrapboxing:
publish:階層的整理とヒエラルキー的整理 - 倉下忠憲の発想工房
13:00
Textbox:
溜まっているツイートまとめノートの扱い方を検討します。
まず、idea.jsonがありそこにこれまでのツイートのログが（部分的に）保存されている状態です。このJSONからマークダウンファイルに「解凍」することもできるので、別の形式が必要ならばいつでも変換できることは念頭においておきましょう。
で、そのファイルをどう扱うか。
一つには、「ただ見返す」というだけは難しいこと。週報の作成のように何かを書く、作る、という行為とセットにならないと継続はおぼつかないでしょう。
＊ ＊ ＊
イメージとして、memo.mdのように、全体を一覧表示して、ボタンを押せば絞り込めるという運用はよさそうです。でも、それだけでは次には進めません。新しいメモを作る、が生まれないと。
＊ ＊ ＊
さがしてみたら、tweetlist.mdというファイルがあり、ここでidea.jsonを読み込んでいました。が、絞り込み機能はなく単に表示されているだけです。
問題は、idea.jsonのaddressはすべてideaになっていて、history.jsonのように分類とは機能していない点。
で、すべて同じaddressになっているならこの要素の意味がないので、それぞれのツイートに合わせて「分類」していくことが必要なわけですが、それをどのように行うのかが問題です。なにせ、ツイートをまとめたファイルにはそうした属性を付与するようはないわけですから。
一つには本文にハッシュタグをつけておき、抽出の段階でそれを取り込む方法はあるでしょう。本文を確認して、#ハッシュタグ、にマッチするものがあればそれをアドレスに指定しておく、というもの。ごくまっとうなルートです。
あるいは、取り込む時点ではハッシュタグを設けず、むしろそれを付ける作業を先ほどの「何かを作る」に相当させる、という考え方もあります。つまり、取り込み時点ではプレーンな状態になっていて、それをコンテキスト付けする作業を設定しておくことで見返しが促進されるというやり方。一度つけたタグは、上部に表示されるようにすれば固まりがより生まれやすくなる傾向はあるでしょう。ハッシュタグがついていないものだけを抽出することも難しくはありません。
＊ ＊ ＊
まずは絞り込み機能から。これはmemo.mdからほぼコピペでクリアです。
＊ ＊ ＊
取り込み時にハッシュタグからアドレスをつける、という方法も存在しても構わないですね。ただ、事前にすべてをつける必要はなくて、明らかに明確ならばつけておく、くらいの運用でよいでしょう。
そうやってタグ付けすることがまず第一段階で、タグ付けじたものをどうするのかが第二段階。
＊ ＊ ＊
ツイートを取り込んだもののaddressが配列ではなく文字列になっているのでそれを修正しておきましょう。
＊ ＊ ＊
OKです。ついでに、idea.jsonのデータ内も書き換えておきました。
＊ ＊ ＊
あとは、ハッシュタグで抽出した後に何をするのかと、ハッシュタグを後からつける方法。
基本的にはクリックして、編集という感じでしょうか。直接編集できるようにするにはタグ欄が必要ですね。
＊ ＊ ＊
まずdivにidを付与しました。これで特定の項目を探せるようになります。
あとは、JSONの項目を変更するcgiにデータを渡せるようにすればOKです。とりあえず、クリックしたら詳細データを表示するDivを生成しましょうか。
タイトル、本文、タグが編集できればとりあえずはOKです。できれば汎用的なやり方が良いのですが。
＊ ＊ ＊
タグ（address）だけを変更するというのはどうか。ideaというタグを表示しておいて、それをクリックしたら、inputが表示されて、確定したらその中身で差し替える。ついでに変更データを送信するというような。
とはいえその場合は、本文を編集するときも画面のデザインが必要になりますね。まあそれもテキストエリアをカードと同じ場所に表示して、みたいなやり方でも可能か。
＊ ＊ ＊
とりあえず、できました。これでツイートをタグで分類していけます。
＊ ＊ ＊
問題は絞り込んだ状態で、タグ付けすると、絞り込みが解除されてしまうこと。今何で絞り込んでいるのかを保存しておく必要がありそうです。
で、タグ付けはタグがついてない状態のものだけを抽出したいので、この機能はかなり切実です。
あるいは、タグがついていないものだけを表示するのをデフォルトにしましょうか。
＊ ＊ ＊
抽出するためのキーワードを保持して、復帰できるようにしました。これでかなり使い勝手があがりましたね。しばらくこれで運用してみましょう。
あとは、そうして抽出した後にどうするのか。