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を追記しないといけない。この処理がたぶん面倒。 ＊ ＊ ＊
ゆっくりしたい日曜日
作業記録の共有 週報の作成 来週の予定を確認する Textbox+毎朝の処理を調整する Discrod巡回 9:00 おはようございます。本日は週報の作成と、来週のタスクの確認だけして、あとは本を読んでおきます。 週報作成: そもそも、ここに直接書けばいいのでは？ という疑問が湧いてきたのでちょっとだけ書いてみます。 まず、THは、いったん書き終わった原稿を念頭に入れながら全体の再構成を進めました。二週間ほど時間を使い、とりあえずposition:0にあたる原稿の冒頭ができました。かなりメモ書きも一緒に書いたので、のちほどそれは整理したいと思います。 ここからは、position:0の文章を完成させることを目指します。その上で、章立てがどのようになるのかをもう一段考えます。現状は「この本を通して何をいおうとしているのか」という全体像（英語ではなんというのでしょうか。big picture？perspective？）を確認しただけの段階です。 ただ、全体像が決まってしまえば文章もおのずと決まってくるので、あとは定期的な進捗が作れると思います。 次に、PT。これは2-4が送信できました（だったよな）。とりあえず、2月の第一週めから始めて週に一回編集者さんに送信する、というリズムが続いています。これを続けていきましょう。 でもって、minutes。これは新しく始まったプロジェクトで、うちあわせCastの音声ファイルを書き起こししたものを「本」にする計画で、私とTak.さんが主体ではなく別の方が主体となって進める予定の計画です。私個人のコミットメントは大きくありませんので、適宜作業をするという形になりそうです。 Textbox。今週は見事にほとんどコードを触りませんでした。原稿を書くと、コードが止まる。まあ、そんなものですね。ただ、「カード型の情報をどう作るのか」「語りをどう扱うのか」という新しい問題の視点が得られました。これについては考えていきます。 読書。Textboxのコードを書くのを止めると、読書も進みます。結局、頭をいろいろなことに動かし続けるのは無理、ということです。しばらく読書量が激減していたので、少しずつ回復させていきたいところ。 心療内科。前回で通院が終わったので記録自体がなくなってしまったので、ここで一応書いておきます。一年くらい継続した通院が終わりました。特に何事もなく仕事はできています。あとは、無理しないように自分の作業量を維持しておくことに注意しましょう。 以上、今週の振り返りでした。こういう「情報」（というか語り）をどのように保存するのか。ちょっと考えたいところです。 来週の予定を確認する: まず、タスクの設定から。 でもって、スケジュール（日付を伴う予定）も確認しました。 Textbox: hatchという小窓があるのですが、そのデザインを直します。 あれっぽくいきましょう。Imba - The friendly full-stack language!っぽく。 ＊ ＊ ＊ 修正しました。 18:00 気になっている本のまとめ: 3月発売の気になっている本をまとめました。 publish:2023年3月発売の気になっている本 - 倉下忠憲の発想工房 こういう風にメモしておいたものをただ並べておくだけでなく、一つの成果物として整理しておきたいです。その方が良さそうな気がします。
メルマガを書きあげる土曜日
作業記録の共有 メルマガ+原稿3 メルマガ+原稿4 一週間の振り返り メルマガ+はじめに、おわりに メルマガ+全体の読み返し メルマガ+配信予約 8:00 おはようございます。本日はメルマガを書きあげます。あと半分くらいですね。 メルマガ: さっそく書きましょう。 ＊ ＊ ＊ 4000字ほどの記事を書きました。あと一つですね。 9:00 メルマガ: 最後の記事を書きます。 ＊ ＊ ＊ 1000字ほどの記事が書けました。これで本編は終わりです。 気がつけば、週の冒頭で書こうと想定していたことのほとんどを書きませんでした。ままならないものです。 10:00 一週間の振り返り: ツイートを読み返しましょう。 ＊ ＊ ＊ publish:2023年02月18日までのツイートノート - Addless Letter 14:00 メルマガ: 「はじめに」と「おわりに」を書きます。 ＊ ＊ ＊ 書けました。寝かせましょう。 あとで読む:書籍「ゲームの歴史」について(2) | Colorful Pieces of Game 16:00 メルマガ: 読み返しましょう。 ＊ ＊ ＊ 配信予約です。 ＊ ＊ ＊ まぐまぐOKです。 ＊ ＊ ＊
PTを書く金曜日
作業記録の共有 PT+2-4? PT+ 原稿の共有 メルマガ+原稿2 TH+タイトル案再検討 TH+本文を進める 9:00 おはようございます。今日はPT原稿の送信日なので、まずそれを書きましょう。あとはメルマガとTHも少し進めておきたいところです。 PT: まずは本日送信分の原稿を書きましょう。 ＊ ＊ ＊ 1500文字ほど書きました。メールを送信しておきましょう。 ＊ ＊ ＊ メールを書いておきました。 12:00 TH: タイトル案がいくつか出てきたので、考えを整理しておきます。 ＊ ＊ ＊ すでに書いたものから全体を再構成するときに、やはり「タイトル案」が鍵になります。タイトル案を再定義しつつ、それを再構成しようとしている内容の"代表"とすること。この観点が必要でしょう。 あとで読む:[「App Store」の存在は“悪”なのか、iPhoneアプリ開発者から見るアプリストアの存在とは] - ケータイ Watch 13:00 メルマガ: 一つだけ原稿を書いておきましょう。 ＊ ＊ ＊ 2700文字ほど書けました。昨日の分と合わせて半分くらいはOKですね。
うちあわせな木曜日
作業記録の共有 メモの扱いの検討 14:00~うちあわせ TH+冒頭部分 TH+原稿共有 9:00 本日はCastではない方のうちあわせです。あと、THの進捗共有日なので、冒頭部分でも固めておきたいところ。 メモの扱い: 現状の「メモ」はたまたま二種類の方式を持っている。一つはTextboxにあるinboxによるjson形式でメタ情報をたくさん残すスタイル。生成日だけでなく「address」というタグ情報も添付でき、それによって同じグループのメモを簡単に参照できる。また、Textbox上のどのページからでも、そうしたメモを利用できる。 もう一つは、iOSのショートカット.appを使ったもの。これは純粋に、テキストファイルを扱う。メタ情報がとてつもなく少ないが、ちょっとしたメモには案外こちらの方が良かったりする。 で、機能まではこれらの統合を考えていたわけだが、むしろ別々に使っていけばいいのではないか。 テキストファイルベースのメモを「生（き）メモ」と呼ぶ。英語ならナチュラル・メモ。で、inputboxへのメモは「プロセス・メモ」。英語ならプロセスド・メモ。そういう風に同じメモでも違うものとして扱えばいいのでは？ そういう感じでしばらくやってみよう。 あとで読む:1日10分の小さな成果を積み重ねて大きなものを作る - by goryugo - ナレッジスタック 10:00 TH: 冒頭を固めます。 14:00 うちあわせ: 新しいプロジェクトのうちあわせです。 18:00 TH: 原稿を書きましょう。 ＊ ＊ ＊ 文字数的には微量ですが、文章の書き方がかなり定まった感じです。とりあえず、共有しておきましょう。
THを試しに書く水曜日
作業記録の共有 TH+「はじめに」リライト メルマガ+原稿1 R-style+注意の防波堤としてのnote メモ環境について検討 ニュースレター+1月の活動報告 7:00 おはようございます。本日は、昨日整理した全体像をベースにTHの「はじめに」の書き直しをしてみます。あとはメルマガの原稿を進めておきましょう。 Textbox: ページを更新したら、ページリストの順番が変わって欲しいので、ソートについて調べておきました。 publish;Textboxでpage.jsonを更新日順にソートしたい - 倉下忠憲の発想工房 あとで読む:なぜ日本の音楽ヒットは新陳代謝しないのか？──“推し”ドーピングの副作用から離脱するために（松谷創一郎） - 個人 - Yahoo!ニュース 8:00 TH: 「はじめに」の書き出しをいくつかのパターンで試してみましょう。吟味します。 ＊ ＊ ＊ いろいろごっちゃになったメモ＋原稿を1700文字ほど書きました。以下のものが含まれています。 本のタイトル案、「はじめに」のデッサン的テキスト、「おわりに」のメモ、「おわりに」のひとつ前の章のメモ。 これを少しずつ書き足して、育てていきましょう。 12:00 TH: ひたすら「はじめに」の冒頭を書き直しています。直すというか、ブレストのように書き並べている、という感じです。 16:00 ニュースレター: 活動報告を書きましょう。 publish:2023年1月の活動報告 - by 倉下忠憲@rashita2 - Rashita’s Newsletter 17:00 R-style: 記事を書きます。 ＊ ＊ ＊ 書きました。 publish:ノートで注意の防波堤を築く – R-style あとで読む:今この時代だからこそ敢えてブログで情報発信をしたい | Hacks for Creative Life!