THを進める水曜日
作業記録の共有 TH+00の書き下ろし うちあわせCastの確認→お休みをお願いする トンネルChannel+3月のテーマ 本を探す→SF超入門 KW+ブックカタリストで続報を送信する KW+応援プランの設定 7:00 おはようござます。本日はTHを進めつつ、新しいサイトの準備も行います。 あとで読む:春のリスト（あるいはファン） - 23-seconds rambler 自分には「ファン」と呼べるような対象がはたしてあるだろうか。 あとで読む:タスク管理にそもそも2種類あるのでは - タスク管理のScrapbox 8:00 TH: 00の続きを書きましょう。 ＊ ＊ ＊ 前回の原稿を共有した後で、編集者さんとタイトル案についてブレストした結果、少し方向性が見えてきたので、そのタイトルに合わせて原稿の冒頭部分をもう一度書き直します。 ＊ ＊ ＊ 3000字ほどがまとまりました。だいぶ長い気がしますが、まあ今は気にしないでおきましょう。 トンネルChannel: 3月のお題記事を書いておきます。 ＊ ＊ ＊ publish:【トリガ・エントリ】「アウトライナーの使い方」 - by 倉下忠憲@rashita2 - トンネルChannel 9:00 KW: 新サイトの応援プランを作っておきます。 ＊ ＊ ＊ noteと、pixivFanboxに新プランを設定。でもって、substackのニュースレターにもsubscriptionを設定。告知はおいおいと。 ＊ ＊ ＊ KWのアイコン（ファビコン）が必要ですね。
原稿を進める火曜日
作業記録の共有 ブックカタリスト058アフター下書き 確定申告書提出 TH+00を書く 環読プロジェクト+お知らせページを作る メルマガ+原稿1を書く メルマガ+原稿４を書く 8:00 おはようございます。本日は原稿を進めつつ、確定申告作業も終わらせてしまいましょう。 メルマガ: 原稿１を書きます。 ＊ ＊ ＊ ２時間ほど書いて、6500文字になりました。まだ終わっていないので後で続きを書きましょう。 12:00 メルマガ: 分量的に1〜３はクリアしたとして、続きを書きましょう。 ＊ ＊ ＊ トータル9500文字を書きました。これで本編はOKですね。 環読プロジェクト: 紹介＆説明のためのページを作りましょう。 ＊ ＊ ＊ 気が向いたので、ドメインを取得します。 18:00 publish:BC058 『運動の神話 下』 - by 倉下忠憲@rashita2 and goryugo - ブックカタリスト
準備を進める月曜日
作業記録の共有 メルマガ+ツイート メルマガ+ファイルの準備 ブックカタリスト会報作成 ブックカタリスト058アフター下書き 確定申告の準備+売り上げ確認 Textbox+朝の処理を変更する Minutes+PDFの確認 ListLauncher+jsonフォルダの指定を変更する 7:00 おはようございます。本日はいろいろな準備を進めます。 Dropbox: 今までだましだまし使ってきましたが、上限がそろそろ限界です。プランを2Tに切り替えて、そのかわりにEvernoteの有料プランをいったんクリアしておきます。 publish:アイデアの散策と育成 / 書いてから、建て直す / Twitterを不便にする / RSP+最後の微調整｜倉下忠憲｜note メルマガ: まずは設定ファイルの更新から。 ＊ ＊ ＊ OKです。 Textbox: 朝の処理がエラーが出まくっているので、変更しておきます。前日にiPhoneに体重を入力していないとエラーが出る模様。その辺をまず修正します。 ＊ ＊ ＊ 一行日記も、現状はテキストで書いているが、jsonに変更する？ daily.jsonのtitle？ ＊ ＊ ＊ 体重の入力がなかったときは処理をパスするようにしました。でもって、この一連の作業自体が必要なのかを検討したいところ。 ListLauncher: 先日、jsonファイルをjson/フォルダにまとめたので、ListLauncherでファイルを参照できなくなっていました。フォルダの指定を加えてOKです。 ビルドは、npm run build で実行可能。 8:00 Minutes: うちあわせCast書き起こしプロジェクトの簡単な確認作業です。 ブックカタリスト: ２月の会報を書いておきましょう。 あとで読む:継続的ドキュメンテーション: Github DiscussionsとADRのすすめ - LIFULL Creators Blog ＊ ＊ ＊ 書けました。明日に配信です。 9:00 朝から猛烈に仕事を片付けましたね。なかなか良いです。
ゆっくり整える日曜日
作業記録の共有 来週やることの整理 メモの整理 考え事の整理 SUZURIを試す 8:00 おはようございます。本日はメモの整理と、来週のやることの確認です。 SUZURI: 電子コンテンツが販売できるようになったらしいので、試しに登録してみます。 ＊ ＊ ＊ 簡単でいいですね。 これから本を書く人への手紙 by R-style Store ( rashita ) ∞ SUZURI（スズリ） やることの整理: まずは、タスクとスケジュールの確認です。 メモの整理: 次にメモの整理です。紙のメモをフィルターしたものは作ったので、次はデジタル生メモの処理。 ＊ ＊ ＊ いくつか、生メモを処理しました。「エッセイ」のネタになりそうなものをどう保存するのかが難しいです。メモとして置いておいても、時間が来たら"賞味期限切れ"してしまうので。 10:00 考え事の整理: まず何について考える必要があるのか。 一つは環読プロジェクトについて。それをどう進めて行くのか。 もう一つは新しいWebサイトについて。それをどう作っていくのか。 あと、project-THの全体像。それをどう構成するのか。 この三つが、現状今抱えている「考え事」。確定申告などの作業もありますが、それは「考え事」はほぼなしで進められると思います。 で、「考え事」は、それを書き留めておいておくだけでは何も処理が進みません。一定の時間をかけて、それについて実際に考えることがその「処理」になります。 17:00 考え事の整理: その２です。 ＊ ＊ ＊ だいたい整理ができました。でもって、整理の仕方も少しずつまとまってきました。
メルマガを書く土曜日
作業記録の共有 メルマガ+原稿1の続き メルマガ+原稿2 メルマガ+原稿3 メルマガ+原稿4 アンケートを転記しておく ツイートの振り返り メルマガ+はじめに、おわりに 8:00 おはようございます。本日はメルマガを書きます。 メルマガ: 原稿1の続きを書きましょう。 ＊ ＊ ＊ 書けました。3600文字ほどになりました。 9:00 メルマガ: 原稿2を書きましょう。 ＊ ＊ ＊ これまた3000字ほどの原稿が書けました。あと二つですね。 10:00 メルマガ: 原稿3を書きましょう。 ＊ ＊ ＊ 2000字ほどが書けました。 14:00 メルマガ: 四つ目を書きます。 ＊ ＊ ＊ 2000字ほどが書けました。これでOKですね。 アンケートの転記: メルマガのアンケートに寄せていただいた答えを整理して、Textboxに転記しておきます。 一週間の振り返り: ツイートを読み返します。 publish:2023年02月25日までのツイートノート - Addless Letter OKです。 15:00 メルマガ: 「はじめに」と「おわりに」を書きます。 ＊ ＊ ＊ できました。少し寝かせましょう。 16:00
PTを送信する
作業記録の共有 8:00 おはようございます。今日はPTの送信日で、夕方から妻の面談に付き添いで、夜からはブックカタリストの読書会です。なかなか忙しいですね。頑張りましょう。 Textbox: 次のステップは、inputboxを呼び出したときに、IDを付与しておくこと。 でもって、IDが付与されたページのrefの処理。 まず、既存の処理がどうなっているのかを確認しておく。 ＊ ＊ ＊ まずcommand + mを押すと、以下の三つの関数が起動する。 1 2 3 4 setModalBtn() modalToggle() searchHistoryBox() このどれかにIDを引き数として渡せばよいだろう。で、次。setModalBtnの中身は、OKボタンの動作を処理している。入力されたデータを受け取ってAPIに渡す処理。そのためにsendToHistory関数にデータを渡している。fromの項目としてすでにファイル名とID名が渡されている。 sendToHistoryは、appendtextに渡している。ここで保存するファイル（history.json）とtype(lineかcardか）を指定している。 最終的に、cgi-appendtextに変数が渡される。 でcgi-appendtextではすでにfromに値が入っていたときのref処理が書かれていた（そういえば書いた記憶がある）。 ということは、まず「この本についてのノートを書く」というボタンを押したら、ファイル名とID名を付与してinputboxを開けばOK，ということになる。 ＊ ＊ ＊ あっという間にできました。ref処理を書いていたのであっという間ですね。 ただ、現状のrefはIDしか処理していません。ファイル名がない。探す対象がhistoryだけであればそれでOKですが、libraryとdoに関連がある場合などは拾い切れません。一応ファイル名も添えるようにした方がいいでしょうか。 あと、別にrefとして保存するのはID名だけでなくても良いような気もします。本文の冒頭部分だけでも保存しておけば表示するときにいちいちサーチしなくていいのでよいのでは？ ＊ ＊ ＊ idとファイル名とタイトルをセットにして保存することにしました。通常の表示はタイトルだけでOKで、詳細表示をするときに、idとファイル名を使います。 ＊ ＊ ＊ histroyboxの表示、from欄に値が入っているときは、それを示す、をやりたい。 ＊ ＊ ＊ 表示自体はできました。あとは、fromに保存するときの処理です。 ＊ ＊ ＊ わりと簡単にできました。あと、ファイル名を指定して、対象のIDで絞り込む、というのは何度もやる操作なので関数化しておいた方が良さそうです。
うちあわせCastな木曜日
作業記録の共有 Textbox+朝の処理を変更しておく 14:00~ うちあわせCast 9:00 おはようございます。本日はごごからうちあわせCastの収録です。午前中は原稿を進めたいのですが、昨日のTextboxの続きもちょっと考えたいところです。 publish:倉下忠憲意味空間におけるスキーマ - 倉下忠憲の発想工房 今自分が作っている情報空間について一度整理しておきたいところです。ちょっとスキーマを勉強しましょう。 あとで読む:セマンティック・ウェブ - とほほのWWW入門 Textbox: 昨日は、読書メモについてのメモについて少し考えました。 まず本の詳細情報がある。で「この本についてノートを取る」というボタンを押す。すると、メモ用のウィンドウが開く。ここまでは鉄板です。で、そうして書いたメモについてのメモを取りたくなったらどうするかを考えました。 で、思ったのが「まず保存しよう」というものです。一つ目のノートを書いているときに、最後まで書き切ってしまう。 すると、ウィンドウが消えてさきほどの詳細情報の下に関連するノートとしてそれが表示されるようになります。 その状態においても当然「この本についてノートを取る」があって、それを押せば同じような動作になり、保存ボタンを押せば、それもまた追加されます。上に追加されるのがよいでしょうか。そんな風に右側に作成領域→保存して下に追加を繰り返していく。 で、それぞれのノートに対しては右側に「このノートについてノートを取る」が表示されて、それを押すと、そのノートのIDがfrom欄に入ったノート作成領域ができる。これが一番整合性がある操作でしょう。 で、問題は、どのような「分岐」をどのように表示するかです。もっと言えば「本の詳細」を開いているときに、その「ノートについてのノート」をどれだけ表示するのか、という点。 まず、脇道はまったく表示させないならこれまでのUIとほとんど同じです。しかし、本についてのノートにrefが設定されているなら、それも本の詳細表示を見たときに表示するとなると（再帰になるので）結構な問題が発生しそうです。 そのように全方位に表示するか、「一段回目を表示」のように脇道の度合いを決定できる表示スタイルにすることもできるでしょう。あるいは、本についてノートをクリックしてそれを詳細表示に持ってきたときだけ表示するという塩梅でも良さそうです。 完璧に全方位を対応すれば、たぶんそれは「メメックス」としてブッシュがイメージしていたものに近くなるのではないかと予想されます。でもってこれはかなりツェッテルカステンに近いものになるでしょう。 ＊ ＊ ＊ とりあえず、入力する側のイメージはできてきました。「本についてのノートについてのノート」のID欄に、大本の本の情報を含めるかどうかは検討課題ですが、from欄は一つにした方が良さそうです。 ほんとに？ 一人の人間は二つの「ソース」を持ちます。だったら、fromも二つあっていいのでは？x:fromとy:from。むしろ既存のツールはこのような「合流」がうまく表現できないのが問題ではなかったのか？ たとえば、本という情報源が一つあるとして、それについての読書ノートは「その本」と「倉下忠憲」という二つのソースによって生まれていると表現できるでしょう。で、たいていの場合片方は「倉下忠憲」だから消去しておいて問題ない、という格好です。 そう考えると、「本についてのノートについてのノート」は、片方に「その本」があり、もう片方に「倉下忠憲の〜〜という考え」というより具体的なfromが示されていると考えられるでしょう。普段の着想は「倉下忠憲」という一番大きなカテゴリにおいて作成されているのに対し、それらのノートは「倉下忠憲の〜〜についての考え」という部分集合によって生成されていると定義できるわけです。 ただし、このように経路を二つ持ってしまうと、管理がすさまじく面倒になりそうな予感があります。一応、1st fromと2nd fromとを分けて、普段の処理は1stだけを優先して、とかをやれば問題は小さいかもしれませんが。 ＊ ＊ ＊ fromのidを二つ持たせることの弊害は、もちろんこれまで書いてきたコードの改修があるという点ですが、それ以外には何かあるでしょうか。 よくよく考えてみるとあまりないような気がしてきました。「親に向かって辿っていく」という工程があったときに、それが分岐を生んでしまう、ということくらいでしょうか。「一意」に定まらないわけです。 ＊ ＊ ＊ たとえば、「本についてのノートについてのノート」の詳細を開いたときに、大本の本が表示されているとちょっと嬉しいのではないかという気がします。あるいはそれは気のせいなのかもしれません。もしリンクによって詳細情報を辿っていけるなら、大きな問題にはならないでしょう。ふむ。 ただし、そのように「現実に近い形」をしたとして、それが情報ツールとして好ましいとは限りません。最高地図は現実だ、みたないことになってしまいます。 リンクを辿っていけば大本の本にたどり着けるならそれでいい、という考え方も実際実用的です。ようはその詳細情報を開いたときのパースペクティブがどのようなものであるのかを考えればいいのでしょう。そうした思考を展開するときに、大本の本の情報はどこまで必要なのか。 ＊ ＊ ＊ Javaはクラスの多重継承はできないことになっている。つまり「親」は一つというわけだ。そのかわりにインターフェースは複数実装できる。親ではないけれども何かしらの「継承」は複数行えるということ。 無理やり生物に応用すれば、卵子的なものを「クラス」と考えれば一応この枠組みで理解することはできる。なんであれ、何か「骨子」や「ベース」になるものがあり、それは一つだけなのだ、と。 ＊ ＊ ＊ そもそもGUIにおいて、「二つの入力」というのがなかなか難しいだろう。以前Textboxに実装した付箋を二つ以上選択するとカードが表示される、というのはその意味で斬新だったかもしれない。あれも「ソース」を二つ以上持つことがはじめから想定されている。 ＊ ＊ ＊ fromを二つ以上持てるならば、それはaddress（/tag）と変わらないことになる。単に有向であるだけだ。でも、それでもいいのかもしれない。 ＊ ＊ ＊
原稿を進めたい水曜日
作業記録の共有 TH+書き進め メルマガ+原稿１ Textbox+detailの実装 うちあわせCastの確認→Takさんにギフト券の受領を確認する 8:00 おはようございます。本日はもろもろ原稿作業を「少し」進めましょう。 Textbox: 最終的に詳細の項目を編集し、タグを入力できるようにしたいのですが、まずは深く考えずに表示だけ実装していきましょう。 ＊ ＊ ＊ 画面のモックアップ的な実装はできました。表示だけはできます。 あとはタグです。これができたら大躍進。 ＊ ＊ ＊ ロジックだけ考えておきましょう。まず保存ボタンを付ける。 モーダルの画面からデータを収集する。そのデータでJSONを生成して、APIに送信する。 API的Pythonは、受け取ったデータからまずIDを見て、対象の項目をフィルターし、項目が見つかったら、それぞれの項目を上書きしていく。差分があったら、という感じにもしたいが、まあここでは深く考えない。 基本的にjsonで受け取ったデータをそのまま表示しているだけなので問題はないだろう。著者名などの編集を不可能にするならば、変更できるのは「読了」と「タグ」だけになる。そちらの方が管理自体は簡単。 とりあえず、それだけを考えるとしよう。タグはtextareaに入っている。スペースで区切ることにする。できれば一度入力したものを覚えておいて、サポートされるようにしたい。 で、そのタグはどこに保存されるか？ library.jsonにだけtagという属性を作ってもいいし、現状使われていないaddressを使ってもいい。まあaddressでいいか。 ということは、apiはどのようにデザインすればいいか。このページでしか使わないならファイルもlibraryに限定すればいいが、さすがに狭すぎるか。do.jsonなども完了の更新をしたい。 ということは、ファイル名を指定する。 updateJSON(file) 当然、更新する内容が必要。 updateJSON(file,json) これだけでOKだろうか。jsonの中にIDが入っているからサーチはできるだろう。「どのようにアップデートするか」の指示もいらないはず。であればこれだけでOKか。 そんなに難しくはなさそう。 12:00 Textbox: JSONを上書きするapiとそれにデータを渡す関数ができました。これで自由にタグを変更できます。 で、あとは、ボタンですね。現状は一つのボタンをクリックしたら、あらかじめ指定しているIDの本を開く、となっていますが、これをそれぞれの表示している本に対応させます。クリックイベントはそれぞれの要素に付与するのか、それとも全体のdivに付与するのか。 リンクにする？ onclickに引き数付でコマンドを与えておく？ とりあえず、できました。処理速度の高低はぜんぜん考えておりません。 ＊ ＊ ＊ ついでに読了日のデータも操作できるようにしました。これで最低限のことはできると思います。あとは、読み始めの日と、モーダル外をクリックしたときに、フォーカスを戻す作業ですね。 ＊ ＊ ＊ 問題なくできました。これでベースはOKです。しばらくこの状態で使い続けてみるのもよいでしょう。あるいは「この本についてノートを書く」機能を考えてみてもいいでしょう。 ＊ ＊ ＊ 複雑に考えずに、inputboxを開けばいいでしょうか。ただしそちらもモーダルなので調整は必要です。 当初は、本の情報が記載されたモーダルの横に、新しいモーダルが追加される、みたいなイメージでしたが、それだとわりと実装作業が増えそうです。「メモする」という共通的な機能として捉えれば、IDだけを受け取ってinputboxを開くのがよいような気がします。 ＊ ＊ ＊ モーダルの重ね掛け。inputboxは常に最大のz-indexを割り当てておくか、モーダルを開くたびに最高値を更新するz-indexを割り当てるか、ちょっと考えたいところ。 inputboxを使いまわせば、実装は手早いです。その代わり、ノートを書いているときに、書誌情報の画面が見えなくなります。これがよいのかわるいのか。
ブックカタリストな火曜日
作業記録の共有 13:30~ ブックカタリスト収録 Textbox+inputのID処理について検討 Textbox+朝の処理を変更しておく 8:00 おはようございます。今日は午後からブックカタリストの収録です。それまでは原稿とTextboxについて進めましょう。 Textbox: 状況を整理します。まず昨日は、from欄にIDが入っていたときの処理を書きました。 で、ここからの作業です。まず、histroy-boxでfromに値が入っていたときの表示をどうするのかがあります。IDを示して、リンクボタンにして、クリックしたらそれが表示されるか、そこにスクロールするというのがあるでしょう。あるいは、from欄にはidだけではなく、テキストも入れておき一緒に表示する、という手もありそうです。 通常の表示ではfromがあることだけを示し、詳細表示（今はありませんが）したときにfrom先の内容を引っ張ってくる、というのもあるでしょう。とりあえずいろいろできそうではあります。が、それはいったん後回しにしましょう。 今考えているのは、referrerの表示。特にbooksでの表示の仕方。ある本のjson項目に、referrerとして読書日記の項目のIDが入っている。で、本の詳細を表示すると、referrerを探しにいって、それを表示させる。そういうやり方です。で、この「探す」をどうするか。 当然ID名から探すわけですが、その検索先がどこになるのか。 読書メモであれば、historyが現状の保存地帯で、そこに読書日記.jsonのようなものも選択肢に加えるかどうか。 で、たとえば、ある本が別の本と関係している、というのはどうすればいいか。もしこれもreferrerで表現するならば、historyだけでなくlibrary.jsonも検索対象である必要があるでしょう。 しかしここで問題が出てきます。ある本の中で別の本が言及されていることと、倉下がある本と別の本が関係していると感じることはイコールではありません。前者はreferrer的ですが、後者は違うでしょう。 あるいは、読書メモの中で関連する本について言及する、という形をとる？ Scrapboxでは、本のページを作り、その頁の中に別の本のタイトルを書いてリンクにすることで「ノード」が生成されます。で、linksとreletedという二種類の「関係性」が保存されます。同じことを行う？ あるいは、そういうのとはぜんぜん別に関係性を扱うか。 ＊ ＊ ＊ 読み終えた本にタグ付けするような作業（たとえば、SFとかライトノベルとか）は、その本のメタ情報としてつけ加えればいいでしょう。では、関連している本はどうか？ 「関連している本」（敷延して関連している項目）という欄を設ける？ それはreferrerとどう違う？ ＊ ＊ ＊ たとえば『独学大全』という本がある。この本は、たとえば『アイデア大全』や『問題解決大全』とつながりがあると言えるだろう。また、『文章大全』のような「きたるべき」本ともつながりがある（あるいは潜在的つながりを持つ）とも言える。 一方で、たとえば『Learn Better』や『私たちはどう学んでいるのか』とのつながりもあるだろう。学習系というジャンル的なつながりだ。また『勉強の哲学』とのつながりは学習系というよりは「勉強」という言語的つながりといえる。 さらに『発想法』や『知的生産の技術』のように内容的かつ、倉下的視点とのつながりもある。 以上のように、一冊の本がもつ「つながり」はグラフ理論ではすべて単一の表現に収まるが、個人的認知としては実は十分ではない。しかし、その認知的差異をすべてデータ的に違いを持って保存するのは現実的ではないだろう。 では、どうするか。 一つは、linksとreletedの二種類くらいにわけておくこと。でもって、カテゴリやジャンルごとのつながりはaddressでなんとかすること。 次に。メタ情報としてでなく、文章としてその繋がりを示すこと。『独学大全』にrefを貼る読書メモの中で、「この本は勉強の視点で『勉強の哲学』と共通点がある」と表記する。それはそれでいいとして、じゃあそこからどうするかというと、やっぱり『勉強の哲学』をリンクにすることだろう。で、そのキーワードで検索して、本を見つけて、IDを付与する、という作業が必要となる。ふむ。 問題はこれをするとつながりが非常に複雑になることだ。『独学大全』という本の項目にリンクを張っているのではなく、そのrefの読書メモにリンクが貼られることになる。 なんかもうそういうことはすべてScrapboxでやった方がいいんじゃね、とは思う。思うけども、もうちょっとだけ頑張って考えてみる。 ようするに、上記のやり方で「関連する本」を一覧したければ、2hop先のリンクまで拾ってくる必要がある、ということだろう。 逆に言えば、このやり方をすれば「グラフに名前（タイトル）をつけられる」。これはScrapboxにはなかった道のりかもしれない。 ＊ ＊ ＊ たとえば、タグに「勉強の本」とつけるとする。で、『勉強の哲学』にも「勉強の本」をつける。すると、タグで抽出したらこの二冊の本を拾い上げることは可能になる。で、そのグループは「勉強の本」と言えるだろう。この一般的なやり方と、自分が今考えているやり方は何か違うのだろうか。 『独学大全』という本の項目 『独学大全』のIDをfromに入れた、addressが読書日記（メモの方がいいか）の項目。その項目内の記述に『勉強の哲学』がある（この時点で『勉強の哲学』のIDをどのように保存しているのかは考えないとする）。 このとき、『独学大全』という本の詳細を開く。当然初期の想定では、読書日記の項目は表示される。『勉強の哲学』の本の詳細はここでは表示されていなくてもいいだろう。せいぜいクリックしたらその本の詳細にジャンプできる程度でいい。 逆に『勉強の哲学』の詳細を表示したらどうなる。先ほどの読書メモは表示されていて欲しい。つまり、refに先ほどの読書メモのIDが入っていて欲しい。 つまり、先ほどの読書メモは記述ないに本のタイトル＋リンクを含むことで、その本の項目にピンを送っている（トラックバックを送っている）と考えられる。そのピンを処理したら、二つの項目間でエッジが成立する。 別の言い方をすれば、読書日記の項目が二つの本をブリッジしている。 ここまではいいだろう。 ＊ ＊ ＊ Mapについて。 ぜんぜん実装はしていないが、リンク関係があるならば、それを「一つ上の視点」から眺めてみたいと思う。ある本に関係する本を一覧したい、という場合どうするか。 その本へのrefは自分の項目が持っている。まずそれを表示させる（それは基本的には読書メモだけであるはず）。でもって、読書メモが持っているidがある。それは別の本へのリンクだ。それも拾い上げる。2hop。さらにその本も、という感じでいくらでも拾い上げられる。 この場合、『独学大全』と『勉強の哲学』はエッジ（線）で結ばれるわけだが、その線はただの線ではなく「読書メモ」という内容＝テキストをもっている。普段は線の形で表示しておけばいいが、ホバーすればそのテキストが表示される、といったことができる。 ふむ。 面白そうではある。やっていることも、やや手間ではあるが、プログラミング的に高度という印象はうけない（あくまで印象）。 ＊ ＊ ＊ 一応の検討課題は、本文内に埋め込んだ書名リンクの処理である。その項目のfrom欄はすでに埋まっている。となるとfor欄を新設するか、という話しになるのだが、それは結局addressのことになるだろう。 ここで機能の衝突が生じている。addressに加えるか、それとも何か別の欄を設けるか、それとも作成時に単にピンを送るだけで、それ以外の情報は持たないようにするか、だ。 役割を考えるならば、今やろうとしていることがアドレスにして、もともとの機能はタグにリネームするのが良さそうにも思う。 本当にそうだろうか？ そもそもaddressという機能はそこまで必要だろうか。「メモは送り先がある」という認識からスタートしているわけだが、いまのところは単なるタグ機能にしかなっていない。これも結局、historyに保存しつつ、別の場所（たとえばpegeやjson）に送る、ということが念頭にあったわけだ。が、現状なくても特に困っていない。だから簡易のタグ付け装置として機能しているし、それはそれで悪くない。
準備を進める月曜日
作業記録の共有 Textbox+朝の処理を変更しておく 8:00 おはようございます。本日はメルマガなどの準備を進めましょう。 Textbox: 全体で何をしようとしているのかを再検討します。 たとえば、以下はBooklogからのフィードを解析して作成されたjsonをもとに生成されているページです。 で、これが以前までの買った本の情報を取り扱うページ。 こちらはテキストベース。でもって、本の名前をクリックしたら赤字と黒字がトルグします。読了のチェック代わりです。 後者の以前スタイルはテキストしかもっていないのに対して、前者のjsonはテキスト+画像の形でもっているので、ボタンを押せばテキストだけの形にするといったことも可能です。で、読了のパラメータを持っておくなら、読了した本の書名を赤字にすることも不可能ではありません。 つまり、jsonベースにすれば以前のスタイルはほぼ不要ということです。ただし、テキストを編集するのとjsonを編集するのとではちょっと違いがあるので、そこを介入する必要はあるでしょう。 あとは、「2022年12月」のような仕切り（見出し）の存在です。そうしたものは、書影が並んでいる状態だと不要ですが、テキスト形式で並べる場合は必要でしょう（あるいはそうではないのかもしれませんが）。 表示を切り替えるときは、display:flexを解除するか、directionの方向を横ではなく立てにすればOK。buyのデータ(日付）も持っているので、それを表示すれば日付の仕切りも不要かもしれません。 ということは、必要なのは、Textboxから操作して対象のjsonファイルの既存の項目を操作する機能でしょう。 ダブルクリック→読了、というのは簡潔ですが、本にタグ付けしたりすることを考えるなら、それだけでは足りません。たとえば、クリックしたら詳細が表示され、そこからメタ情報が編集できる、という形の方がよいでしょう。 そうしたUIの実装と、編集後の内容をjsonに反映させる操作が必要です。 やりたいのは、その本を削除する、あるいはメタ情報を修正すること。書名かID名でjsonデータから対象の項目を見つけ出し、必要な処理を行う、という感じでしょうか。 問題は、それらの処理をクライアントサイド（JavaScript）でやるのか、サーバーサイド（Python）でやるのか、という点。 クライアントならば、jsonをfetchし、そのjsonに項目の修正などを行って、修正後の内容をサーバーに送り、サーバーはその内容をjsonファイル全体を上書きする、というやり方になるでしょう。非常に大雑把な感じがします。 サーバーサイドであれば、「編集したいJSONファイル名、編集後の項目」を送信し、Pythonはその項目からIDを見つけて、対象の項目を探して差し替え、という感じになるでしょうか。このとき、差し替える前のjsonを保存しておけばバックアップがききますね。 ある本を読了にするだけであれば、ID名だけ与えて、その項目のstateをdoneにして日付を与えればOKですが、しかしそれは「読了した日にダブルクリックする」という前提がつくのでやはりこれでは駄目ですね。詳細から読了日のパラメータを与えられる必要があります。 ＊ ＊ ＊ で、たとえば読書日記を書くときには、ここで本を探して、その詳細に書く、というのが一番自然なのかもしれません。 ただしその場合、「読書日記」だけを串座して並べることができません。やはりそれはちょっと違うような気もします。本ごとにこうして並んでいるのもいいですが、たとえば時系列で「読書日記」だけを並べてみたい気もします。どうするか。 ＊ ＊ ＊ 「これについてのノートを書く」というアクションを作る？ 9:00 メルマガ: ファイルの準備だけしておきましょう。 ＊ ＊ ＊ ファイル設定だけはできました。 Textbox: 本の情報が入ったlibrary.jsonがあり、それを編集できるようにしたら便利では、という点は確認できた。 で、たとえば読書日記もその動作の延長線上に置くことができる。たとえば、books.mdで『惑う星』を探し、その詳細を開いたらメモ欄が出てくるので、そこに感想を書く、というスタイル。 こうすれば本を検索したりするのと同じように、自分の感想が検索できる。あるいは、自分の感想をキーにして本の情報を探すことができる（「あの登場人物が格好良かった本ってなんだっけ？」）。 一方で、library.jsonに入れ込んでしまうと、読書日記だけを取り出して並べることが難しい。不可能ではないが、「読書日記を書いた時系列」では並ばない。本が持つメタデータ順になってしまう。 読了日順にソートすればいい？ 読書メモそれ自体にもメタ情報を持たせる？ 読書メモを別途項目で作り、そのリンクを本の情報に入れ込む形にする？ いろいろ解決策がありそうだ。 library.jsonに保存しても、それだけを抽出すれば、串座しての閲覧は可能だが、たとえば別のページで、他のメモと読書メモを並べることはできるだろうか。一応可能ではあるか。本のメタ情報の一つに「メモ」を作ればいい。あるいは本のメタ情報のlineは、「メモ」として扱うようにすればいい。内容紹介はdescriptionsがあるので、そちらにいれたらOK。 一応、この形式でも他のページで情報を利用することはできそうだ。ただし、一冊の本のメモを数日書けて記録していくような場合は、読了日にすべてまとめられてしまう。その点をフレキシブルにするならば、メモそれ自体にメタ情報を持たせるしかない（入れ子構造にしてしまう）。 以上検討してみたが、「できなくはない」という感じだ。データを処理する方で頑張れば、先ほど検討した機能の実装だけで運用できる。 で、別のパターン。 ＊ ＊ ＊ 「読書メモ」は読書メモとして別に項目を作り、その項目へのリンクを本のメタ情報として添えるやり方。 イメージしてるUIとしては、books.mdで本をクリックすると詳細（メタ情報）が表示される。で、下に「この本についてのノートを書く」というボタンが表示される。それを押すと、inputboxが表示され、そこにfromが設定されている。あとは読書日記タグをつけて、保存する。 すると、読書メモ項目がhistoryに追加されて、そこにはIDが設定されている。それと共に、library.jsonのその本の項目にも、「link」のような形でそのIDが追加される。 で、もう一度books.mdでその本の詳細をクリックすると、先ほど書いた読書メモも一緒に表示される。さらに新しくメモを追加することもできる。 という感じ。 全体的に悪くない。ただ、すごく面倒そうだが。特に、生成されたIDを、library.jsonにも渡すときがかなり面倒。jsonファイルを分けないで単一でやってもいいのかもしれない。ただ項目数が多くなると処理速度などが気になる。 ちょっと処理の流れを図にしてみよう。 ようは少し前まで考えていた「from」の機能を作り、さらにその結果をfrom元のjsonに反映させれば基本的にはOKだと言えそう。でもってやはり問題はファイル名。ファイルが分かれてしまっているので、「どのjsonのIDか」という指定が必要（あるいは、すべてのjsonファイルを走査するか（重複はないはず））。 あと、読書日記としての項目のIDは、それを生成するまで決定されないので、「同時」に両ファイルに追記はできない。まず、読書日記の項目を作り、その処理が終わったらIDをリターンして、そこからcallbackでrefを追記しないといけない。この処理がたぶん面倒。 ＊ ＊ ＊