メルマガを仕上げる土曜日
作業記録の共有 Textbox+ツールの位置づけ ツイート振り返り メルマガ+はじめに note+セールチェック メルマガ+全体稿確認 メルマガ+配信予約 Obsidian base連載+第二回 Textbox+分割と検索の設計 各種日課 復文勉強 集中的読書 サブ執筆 KW+ミニエッセイ 7:00 おはようございます。本日はメルマガを仕上げます。あと、Textboxまわりの検討も引き続き。 Textbox: その１。現在ツイートを一週間分振り返って、テキストファイルに保存するということをやっている。ただし、適切に運用できた例は少ない。なぜだろうかと考えてみると、たしかにテキストエディタでそうしたものを保存することはできるが、文章ではないので「テキストエディット」の機能がそこまで合うわけではないから、と気がついた。 以前、WorkFlowyの全体を「タスク」などで検索したときの操作感はとてもよかった。つまり、そういう断片向けの場所に保存するのがよいのだと思う。 WorkFlowyはまさしくその選択肢だが、ローカルベースであればBikeを考えたい。が、Bikeはもろもろ手に馴染まない部分がある。 あと、テキストエディタの機能を拡張して、断片を扱う機能を増やしたとしても、たぶんそのファイルの位置づけが、自分のワークフローに合致していない。具体的に言えば、保存するルートは確立していても、それを使うフローがない。たとえば、メルマガで次何を書こうかと考えているときに、そのファイルを開くことがない。それを変えない限りうまく運用できないだろう。 「ネタ」を扱うための専用ツールを作る、というのは一つの手だ。 その２。TextboxとHTMLツールの関係を悩んでいる。そこでいったんアナログツール的に考えてみる。たとえば、ノートと手帳を別に持つというのは自然な発想だ。それは、ある程度自由に書いていける媒体と、「自己管理」に必要な媒体を分けていると言える。で、それでめちゃくちゃ不便かというとそうではない。その二つが別の媒体であっても、アナログ時代は運用できていた。 自己管理に必要な情報。特に「時間」の制約を受ける情報を扱う場所と、そうでないものを分ける、という切り口は一応成立する。もちろん、デジタルツールならそのすべてを一つにまとめることも可能ではある。 とすれば、人間の認知にとってどうなのか、という判断が必要になるだろう。 その３。上の考え方を「専門職ノート」と仮に呼ぶとして、プロジェクトノート・仕事ノートについて考えたい。コンビニ店長時代は、仕事用のノートを持っていた。手書きノート。サイズはそのときどきでバラバラで、B5の大学ノートだったり、A5のリングノートだったりした。そこに、必要な情報を雑多に書き並べていた。たぶん、デイリー＋トピックが区別なく並んでいたと思う。一方で、手帳は別にあった（もうその当時からGoogleカレンダーだったかもしれない）。 雑多なノートは、とにかくすぐに書けるのがよい。その上で、「仕事で使う」という文脈では統治されている。本当に「なんでも」書いているわけではない。「仕事のことはなんでも」書いているだけ。 今の仕事だと、そういう線引きが難しい。日常に起こる出来事全てが、何かしらの意味で「ネタ」になる。そうなると、扱う範囲も非常に広くなってしまう。コンテキストが有限化されない。 いったん「物書きの仕事ノート」という概念を検討してみたい。それは手帳とは別の存在として考える。 その４。Textbox python版は、基本的にリンクと検索でページを呼び出すスタイルだったが、ナビゲーションの「循環」を設定していた。Homeとなるindexがあり、メモ一覧があり、todoがあり、リスト一覧があり、再びindexに返ってくるという動作を、同じショートカットキーで実現していた。それを押すたびに表示されるノートが「市内循環」する。 これは、それらのノートを頻繁に使うことが意図されていたし、実際その通りだった。一方でそれはそれらのノートの特権化でもあった。他のノートに目をやる余地が減っていたとも言える。特に、Python版は「すべてのノートの一覧」がうまく機能していなかったので、余計に同じノートしか使わない、感じが強かった。この問題はもうちょっと考えたい。 そのように特権化されるノートは、別のツールとして独立させるというアイデアは十分ありえるだろう。 ＊ ＊ ＊ たとえば、Textboxの一ページに、ただメモを書き並べていくことはできる。なにせただのmdファイルだし。ただしそれが使いやすいかは別の話。 同様に、引用を書き留めていくノート、短歌や俳句を書き留めていくノートも、ただテキストが並べばいいとは言えない。ここに問題がある。 HTMLツールと、Textboxのmdとの違いは、HTMLツールは基本的にツールの枠組みだけを提供し、データは別の形式で保存されるに対して、mdノートは自身がまずデータを保持し、それに必要なfunctionも自身のScriptで保持しているということ。メインはデータであり、funcは付加的に必要になるもの。ある意味で、mdノートはそれだけで完結している。 HTMLツールの場合、ツールはツール、データはデータという切り分けで、その方が使いやすい場面ももちろんあるだろう。 ＊ ＊ ＊ 断片的な知識や覚え書きを書き留めていく場所と、ツイートのまとめのように連続的に保存され、その全体を対象とした操作が行われる場所は異なるだろう。 ひとまず、走り書きメモについては、その一つひとつをテキストファイル化するのではなく、すべてを一つのテキストファイルにまとめる、という方針でいくとする。mdかjsonかjsonlか、は選択がいろいろある。 その上で、どのようなビューを設計するのか。 これは自作ツールで「世界」で検索したところ。世界を含むメモが抜粋されている。この体験はとてもよいのだが、一つだけ引用が混じっていて、微妙にそれだけ見栄えがよくない。言い換えれば、引用がメモの形式に揃えられていて、あまり引用っぽくない。 検索で対象にしつつ、しかし見え方は変えるようなツールがよいのだろうか。 ＊ ＊ ＊ これは別の自作ツールで、こちらはタイトル＋本文のカード形式になっている。 この感じもよい。しかし、このように分けると検索で一気にとはいかなくなる。いや、現状はいかないというだけだが。 現状の検索は、おそらく（自分で書いたわけではないから推測だが）、mdファイルの内容をすべて読み込んで、それをメモリ上に展開し、その中で検索操作をおそらく行っている。 ツールを分けると、その画面上で表示されている情報しか検索の対象にはならない。ここが考えるポイントだろう。 保存する情報に合わせて、「見せ方」を分ける場合、個別に保存したほうがいいが、そうすると「一括の検索」ができなくなる。 逆に言えば、個別に保存してなお一括の検索ができるならば、分かれていてもさほど不便はない。 たぶんこれが解決すべき真なる問題ですね。越境性の問題だ。 8:00 Textbox: ようは、何かを保存するときには入り口は一ヶ所の方がよく、それらを使うときは別のコンテキストがまざっていない方がよく、しかし、検索するときはときどき一括で検索したいというときがある、という超わがままな要望があるわけです。
ニュースレターを書く金曜日
作業記録の共有 Textbox+JSON操作 ニュースレター+購読者限定 Obsidian bases+第一回 TH+第二章のアウトライン Textbox+位置づけの検討 Textbox+位置づけの確認 各種日課 復文勉強 集中的読書 サブ執筆 KW+ミニエッセイ 7:00 おはようございます。本日はニュースレターもろもろです。 Textbox: node.js版への移植を進めます。 ＊ ＊ ＊ JSONのデータから詳細を表示することができました。まだJSONへの書き込みはできません。それができたら、ほぼこれまで通り使っていけそうです。 が、「これまで通り」使うのがいいのかはちょっと検討が必要ですね。 ＊ ＊ ＊ より汎用的に、JSONの項目を編集できるようにしました。 これでAPI周りもだいたいOKですね。 Fri, 24 Apr 2026 08:44:24 8:00 ニュースレター: メンバー限定記事を書きましょう。 ＊ ＊ ＊ publish:infotoxicity | メンバー限定記事 - by 倉下忠憲@rashita2 書きました。 Fri, 24 Apr 2026 09:56:35 少し休憩します。 11:00 Obsidian bases: 連載記事の第一回を書きます。 ＊ ＊ ＊
原稿を進める木曜日
作業記録の共有 Textbox+基礎ページ Obsidianbase連載 TH+第一章の検討 TH+第二章のアウトライン Textbox+トップページのデザイン 各種日課 復文勉強 集中的読書 サブ執筆 KW+ミニエッセイ 7:00 おはようございます。本日も原稿とツール調整です。 Textbox: 現在TextboxはPythonのローカルサーバーで、NUKAなどはNode.jsのローカルサーバーで立ち上げています。さすが管理が面倒なのでこれを統一します。 かなりややこしい問題がたくさんあるのですが、一つひとつ進めていきましょう。 ＊ ＊ ＊ まず基礎的なhtmlを作ります。そこから少しずつ拡大していきます。 ＊ ＊ ＊ ひとまず、mdファイルをfetchして、マークダウン変換してから表示する機能だけを実装しました。まだ保存などはできません。この感じを確かめつつ、起点となるフォルダ構造をどうするのか考えます。 9:00 TH: 第一章の流れをもう一度チェックします。で、その後どうするか。文章化するのか、それとも第二章のアウトラインを検討するのか。 ひとまず二章にしましょうかね。 ＊ ＊ ＊ 第一章のアウトラインはだいたいよい感じになりました。この段階で、それ以前に作ったものはおよびではなくなります。 それに加えて、一つだけ置き場所が定まらない話題がありました。とりあえず第一章のアウトラインの中に含めておきます。 13:00 Obsidian bases連載: さっそくnoteに記事をアップしていきましょう。 ＊ ＊ ＊ publish:Obsidian bases徹底攻略入門「はじめに」｜倉下忠憲 ようやくスタートできました。こういうのはだいだい決まったら、そのまま書き始めるのが吉ですね。 14:00 Textbox: トップページを考えます。Cosenseっぽい感じを目指したいですね。 ＊ ＊ ＊ だいたいできてしまいました。カードをクリックしたら、そのmdファイルが開きます。 もうこれで十分ではないだろうか。
原稿を書く
作業記録の共有 メルマガ+原稿2(4000文字) TH+第一章アウトライン Obsidianbase+記事を書く R-style+デジタルツールクラフティング(DTC) 各種日課 復文勉強 集中的読書 サブ執筆 KW+ミニエッセイ うちあわせCast確認→お休み 8:00 おはようございます。本日ももろもろの原稿です。 朝のClaude活動: ツールの数が増えてきたので、ポータルページのデザインを検討します。 ＊ ＊ ＊ 和風な感じで。 建物をクリックしたら、個別のツールに移動します。 9:00 メルマガ: 二つ目の原稿を書きましょう。 ＊ ＊ ＊ 約4000字の原稿を書きました。これで本編はほぼ終わりましたね。 14:00 TH: まずは第一章の話を再確認します。頭から語り直します。 Claude: 13時のセッションです。 ＊ ＊ ＊ マンダラ形式を試してみました。クリックして、下位要素があるならそのマンダラが開きます。
ニュースレターを書く火曜日
作業記録の共有 朝のClaude活動 ニュースレター+思考はデータベースの代替ではない メルマガ+原稿1(5000文字) TH+第一章アウトライン 各種日課 集中的読書 復文勉強 サブ執筆 KW+ミニエッセイ KW+ミニエッセイ更新 8:00 おはようございます。本日はニュースレターもろもろを書きます。 朝のClaude活動: ブラウザ上で使えるエディタの整備。 ＊ ＊ ＊ 見出しと箇条書きリストが使えるようになりました。 ニュースレター: 書きましょう。 ＊ ＊ ＊ publish:データベースは思考の代替ではない - by 倉下忠憲@rashita2 - Rashita’s Newsletter 10:00 図書館に返却にいってきました。 メルマガ: 一つ目の文章を書きましょう。 ＊ ＊ ＊ 5000文字の原稿を書きました。 13:00 ノート選び: ツバメノートを使い切ったので、次のノートの探求に。一つのアイデアとして、そのままツバメノートを使う、ないしはA5の綴じ・リングノートを使うという案が一定レベルでありとして、ルーズリーフならどうか、をちょっと考えます。 ＊ ＊ ＊ これまでは、LIFEのちょっと良い紙のルーズリーフを使っていましたが、そうすると「書きなぐる」ことができません。それが一つのネックになっていたので、KOKUYOのルーズリーフにしてみました。マルマンという選択もありです。 これで書き心地と書きなぐりしやすさを考えてみます。 自分の飽き性を考えると、「書きなぐりようノート」という役割だけ与えておいて、そのときどきで好きなノートを使うのがよいかと思います。ただ、MDノートは値段的にあまり書きなぐりしにくいので、そういうノートはまた別に考えるとよいでしょう。 「思考」を扱うノートでも、実はいろいろ違いがあると言えそうです。 ＊ ＊ ＊ ルーズリーフだと、スキャンしてデジタル化がずいぶんやりやすくなりますが、それが本当に必要なのかは謎です。あと、ルーズリーフ用の穴開けをかえば、市販のリーフ以外も選択肢になります。それこそコピー用紙なども。 14:00 KW: ちょっと思いついたことがあったので、先にミニエッセイを書いておきます。更新はのちほどということで。
準備を進める月曜日
作業記録の共有 今週の書くこと検討 ブックカタリスト+137下書き ブックカタリスト+配信予約 メルマガ+ツイート メルマガ+ファイル準備 ノートのまとめ TH+第一章のアウトライン Obsidianbases連載+第一回の原稿 各種日課 復文勉強 集中的読書 サブ執筆 KW+ミニエッセイ 7:00 おはようございます。本日はもろもろの準備を進めます。 publish:思考の補助に必要なもの / 執筆法と壁その１ / 社会的なもの、個人的なもの｜倉下忠憲 今週書くこと検討: まずは、全体として今週何を書くのかを決めます。といっても、メルマガとニュースレターが中心ですが。 ＊ ＊ ＊ 生メモはWorkFlowyに保存されており、「今週書くこと」もWorkFlowyなので、POPupウィンドウでもWorkFlowyを開いて、横に並べて今週書くことを考えました。 まず第一に、この手の作業をするときは、かならずウィンドウが二ついる、ということです。今週書く媒体のリストを見ながら、書き留めてあるメモを見る、という「見比べる」という操作が必要で、単にズームインの状態で行き来しているだけでは足りません。 なので、どちらかを別のツールにするという手はありえます。たとえば、メモはそこまでアウトライン操作を必要としないので、他の場所においておき、それを見ながらWorkFlowyで、というのはありでしょう。 この辺は、今後の検討課題です。 で、ここでは「今週書くこと」を扱っていますが、より大きな「今後考えていきたいこと」という場面でも同じでしょう。そこでは上位構造を並べる場所が必要。 これまでの考え方であれば、そうした上位構造（というか上位レイヤー）をつくり、その中にメモを位置づけていく（移動させていく）という考え方でしたが、今はメモを横目に、新しく項目を書き足していく形をとっています。つまり、移動ではなく「書き写す」とうい手作業に近いです。 つまりメモはメモとしてそのままあり、上位レイヤーは上位レイヤーとしてある。メモを構造化して上位に変換する、という流れではない、という感じになってきました。こっちの方がむしろよりデジタル的かもしれません。階層構造に縛られる必要はなく、しかし「上位のレイヤー」はありえる、という話です。 ＊ ＊ ＊ ひとまず気がついたのは、この作業の場合「メモのライン」と「今週書くことのライン」の二つがあれば十分ということです。実際この「今週書くことのライン」というのは、current なもの、くらいの意味です。中間的なものはぜんぜん不要な気がします。 現状最上位には４つの項目＋アルファが並んでいますが、MemoとDraftで事足りるなら、あと二つは何か別のものを差し込めますね。 ＊ ＊ ＊ Draftingは、ようするにWritingなんですが、Writingとしてしまうと、書くこと全般に意識が向いてむしろうまく使えなくなります。そうではなく、Draftを作っているんだ、と意識を限定した方が良さそう。 逆に言えば、別の項目として「企画案リスト」という項目が存在するのはよいですね。最上位に置くかどうかは別にして。 ＊ ＊ ＊ 昨日のObsidianもそうですが、今は「サイドバーの再検討」を進めている感じですね。結果的にそうなっている、ということですが。 8:00 生成AIと議論: https://chatgpt.com/share/69e57047-6620-8321-a958-61cae0f61bae 途中、あまりにも発想が貧困なので、発想技法を添えてみました。案外うまくいったと思います。 ＊ ＊ ＊ 同じ話題について、Geminiとも議論しました。面白いのはGeminiも「進化」という言葉を持ち出したところです。なので途中までは同じ話になりましたが途中からぜんぜん違う話に展開していきました。
ゆっくり過ごす日曜日
作業記録の共有 claude+ポメラっぽいエディタ相談 13:00~Claude+ポメラっぽいエディタ実装 18:00~Claude+ポメラっぽいエディタ修正 週報作成 Obsidian+ワークスペースの調整 来週のSTL確認 ブックカタリスト+読書会ページ更新 読書メモ更新 読書 8:00 おはようございます。本日はゆっくりデーです。 来週のSTL確認: まずは予定確認から。 ＊ ＊ ＊ 大きな予定はなし。引き続き原稿作業になりそうです。 ＊ ＊ ＊ 続いて、タスク。ここでの「タスク」は何を確認したらよいと言えるのか。 ＊ ＊ ＊ いったん、自作のタスク管理ツールで管理をして、実際に自分が何をやりたいのかを見極めようと思います。汎用ノートであるObsidianでやってしまうと、そこが見えにくい気がします。 ＊ ＊ ＊ たとえば、上のツールだと、プロジェクト名をクリックしながら、それぞれのタスクの状況を「見て回る」（視察）ことができます。Obsidianでそれをやろうとしたら、フォルダ「project」を作って、そこに並べることになるでしょう。 あるいは、basesです。あまりフォルダ分けはしたくないので（この気持ちも検討が必要ですが）、ひとまずbaseにするとして、それはどうなるか。 現状、カード形式にこうなっていますが、 これはあまりサイドバーにあるリストと同じ感じはしませんね。たぶん、リストビューにした方がいい。でも、それですら同じかというとちょっと違う気がします。 おそらくここをいじり回すよりも、projectというフォルダを作って、そこにプロジェクトのmdファイルを並べるのがスムーズな解決だと思います。フォルダ分けしないことに囚われすぎてはいけない。 ＊ ＊ ＊ 今までは、サイドバーがうまく使えていませんでしたが、ワークスペースを切り替えるとサイドバーの設定も切り替えられるとわかったので、リデザインが可能です。 それぞれのワークスペースにおいて、適切なサイドバーを置いておく。上ならばプロジェクト名のbaseを置いておくことでファイラーっぽくなります。 ＊ ＊ ＊ baaseではなく、普通にリンクを並べるファイルならどうなるか？ 別にこれでもいいですね。大量の情報を扱うならbaseですが、一度にコミットするプロジェクトの数は限定的なので問題はなさそうです。 最終的にObsidianで管理するかどうかは別にして、ようはこういう体験ができればいい。mdファイル＋特定の項目でグルーピングしたノート。 Cosenseでもこの感じがあるとよいのですが。 ＊ ＊ ＊ びびびと来ました。上の感じでObsidianを再調整しましょう。左にリゾミックツリーを置く、です。 9:00 claude: ポメラっぽいエディタを作ろう、というアイデアを閃いたので、まずはclaudeさんと内容の相談です。 ＊ ＊ ＊ あくまでモックアップですが、書くことに集中するためのエディタ空間をイメージしています。 内容を詰めたあと、いったん仕様書をまとめてもらいました。次回のセッションではそれをベースに作ってもらう予定です。 ブックカタリスト: 読書会ページを更新しましょう。 ＊ ＊ ＊
メルマガと読書会な土曜日
作業記録の共有 ツイート振り返り メルマガ+はじめに メルマガ+全体稿確認 メルマガ+配信予約 考え事 Obsidianbases+第〇回原稿(1000文字) 20:00~ ブックカタリスト読書会 各種日課 集中的読書 復文勉強 サブ執筆 KW+ミニエッセイ 8:00 おはようございます。本日はメルマガを仕上げます。あと、夜からは読書会です。 ツイート振り返り: まずは、一週間分のツイートを振り返ります。Blueskyもちょっと読み返したいですね。 ＊ ＊ ＊ TwitterはOKです。 ＊ ＊ ＊ blueskyも振り返りました。現状はただテキストを保存しているだけです。IFTTT経由で。RSSを自分でチェックするならば、JSONLの形式やデータベースに入れることも可能ですね。 とりあえず、2024年、2025年分とファイルを分けました。今後運用の仕方を考えましょう。 9:00 メルマガ: 「はじめに」を書きましょう。 ＊ ＊ ＊ 書けました。 Sat, 18 Apr 2026 10:32:00 10:00 メルマガ: 全体稿の読み返しです。 ＊ ＊ ＊ 読み返しが終わりました。 Sat, 18 Apr 2026 11:31:22 11:00 メルマガ: 配信予約作業に移りましょう。 ＊ ＊ ＊ まぐまぐOKです。 ＊ ＊ ＊ note、OKです。
原稿を書く金曜日
作業記録の共有 ニュースレター+メンバー限定記事 メルマガ+原稿3(800文字) revision+紙版づくり メルマガ+原稿3(1100文字) TH+第一章のアウトライン 各種日課 サブ執筆 ニュースレター+noteにも転載するか検討する 7:00 おはようございます。本日は結婚記念日です。が、妻は仕事なので特に予定はありません。私も仕事を進めましょう。 昨日作ってもらった、「時間割り」を意識したいところですが、どうするのがよいか。タスクリストに組み込むのか、それとも別の表示方法をかんがえるのか。 別の表示情報？ たとえば、小さい窓（ウィジェット）を表示しておき、時刻と共に「今は〜〜の時間です」のようなことがわかりやすくする、というもの。タスクリストとは別に、現時点の「コンテキスト」を示すというもの。 悪くはなさそうですが。 8:00 ニュースレター: まずはメンバー限定記事からです。 ＊ ＊ ＊ 書きました。 publish:ただのPKMには興味がありません | メンバー限定記事 - by 倉下忠憲@rashita2 かなり過激なことを書いたので、noteにも転載するのかちょっと迷いますね。 Fri, 17 Apr 2026 08:45:03 メルマガ: 三つ目の記事を書きましょう。 ＊ ＊ ＊ 800文字くらい書いて、いったん中断です。 9:00 revision: 紙版づくりの続きです。 ＊ ＊ ＊ 中身がからっぽのときは、PDFファイルは作れますが、mdから変換した中身を入れるとそもそも変換がうまくいきません。手ごわいです。 ＊ ＊ ＊ ChatGPTといろいろ改修してみましたが、埒がありきませんね。またClaudeとやり直しです。 ＊ ＊ ＊ どうやら箇条書きリストがうまく変換できていないっぽいです。 ＊ ＊ ＊ Pandoc をアップデートしたら Markdown -> LaTeX -> PDF で失敗する - Tak Hの日記
原稿を書く木曜日
作業記録の共有 メルマガ+原稿2（1600字） デジタル環境権等 Workflowy Obsidianbase+アウトラインを増やす 企画案検討+次の企画案について考える revision+PDFづくり TH+第一章のアウトライン続き 各種日課 復文勉強 集中的読書 サブ執筆 KW+ミニエッセイ 8:00 おはようございます。本日ももろもろの原稿作業です。 メルマガ: まずは二つ目の原稿から。 ＊ ＊ ＊ 1600文字の原稿を書きました。 デジタル環境権等: 休憩代わりにちょっと考えます。 まず、普段はWorkFlowyを入り口としていろいろ書き、必要に応じて「切り出す」ということをしたいと考えていました。しかし、WorkFLowyだと、WorkFlowy内に「切り出す」のは難しいです。Cosenseのような「新しいページとして切り出す」という操作感はまず得られません。 APIを使って、現在選択している項目群で新しい項目を作り、APIの返り値でその新規項目のIDが返ってくるから、その項目へのリンクを、最初に選択した項目と差し替える、みたいな処理をする必要があります（不可能ではないですね）。 で、いったんWorkFlowy以外のツールへの移動を考えています。たとえば、Obsidian。あるいはCosense。 前者はURLスキームで、後者はAPIで新規ページを作れるので、たとえばWorkFlowyにブックマークレットを起き、選択している項目から新規ページを作ることは可能でしょう。頑張れば、ブラウザ拡張をつくることもできます。 で、それができたとして、はたしてそれが嬉しいのかという問題があります。昨日もちょっと思いましたが、アウトライン上で「いいかんじ」の内容が、必ずしもノートとして「いいかんじ」とは限らないと思います。 すべてがアウトラインであることが前提のものと、平文のテキストであるということは、情報の実存が違っている。 そのように考えれば、単純に「切り出して」はい終わりというわけにはいかないでしょう。だとしたら、スクリプト経由でそのまま移すことはどこまで適切なのか、という迷いが出てきます。 この辺は、しばらく運用して確かめるしかないですね。もし、この連携がうまくいけば、自作ツールとして、スタートがアウトラインになっていて、そこからノートを生成できるようなツールが作れそうです。 9:00 Workflowy: ちょっと思いつきました。 WorkFlowyで隠しゴミ箱 - 倉下忠憲の発想工房 ＊ ＊ ＊ これを試していて思いついたのですが、階層構造で大分類をつくるのではなく、1スクロールで区分けすればいいのでは？ つまり、大項目が「Writng」「Craft」「Stock」「memo」みたいにあったときに、その４つの連続で並べるのではなく、間に1スクロール分の空白を挟んで並べれば？ ＊ ＊ ＊ ちょっと面白そうなので試してみましょう。 ＊ ＊ ＊ スクロールは、スペースキーで送る、shift+スペースキーで戻るができるので、操作感も悪くありませんね。 11:00 book:read:end:『書物を楽しむ』: 副題は「あえて今、紙の本を読む理由」。電子書籍や図書館の運用方法への異議申し立てなど、いかにもという感じ。とは言え著者はデジタル嫌いなのではなく、執筆はデジタルツールでやっているという点で、その使い分けがごく自然だとは感じます。 Knowledge Walkers: リンクの戻るボタンの動作が不安定なので、Claudeに見てもらいました。あと、画面移動時のスクロールも修正。 でもって、このページの仕組みを使って、Honkureもリニューアルしようと考えています。でも、独自の仕組みを作るのも楽しそうではあります。サーバーサイドをしっかり構築する。 12:00 軽く昼食を。 Knowledge Walkers: 今、Knowledge Walkersの記事エトセトラは、VS Codeで書いていますが、Script周りの処理はほぼなくなったので、Obsidianのvaultで管理した方が早いかもしれません。リンクが使えるので。VS codeでも似た拡張機能はあるのですが、いかんせん処理が重くなりがちです。