THを進める木曜日
作業記録の共有 TH+第三章アウトライン整理 TH+第三章アウトライン起項 TH+第三章書き下ろし TH+第三章書き下ろし メルマガ+原稿３ KW+ミニエッセイ 7:00 おはようございます。本日はTHを進めます。 TH: 第三章のアウトラインを付箋で整理します。 ＊ ＊ ＊ まず流れを考えずに、思い付くままに項目を書きだし、それをブロックとして整理して、その後に順番を考えるという寸法です。 Scrivenerのコルクボードを使いましょう。 だいたいOKです。あとはこれを並び替えます。 できました。ここからどう進めるか。 ＊ ＊ ＊ とりあえず、Scrivenerでブロック単位で文章を書き下ろしました。だいたい3400文字。つながりも文章も不完全ですが、とりあえずは文章にしていきましょう。 17:00 TH: 書き並べたものの、順番を検討します。 ＊ ＊ ＊ ぜんぜんできていませんが、とりあえずここまでを編集者さんに共有しましょう。 ＊ ＊ ＊ 明日移行は、話の流れを検討します。というか、自分がここで何を書こうとしているのかを詰めます。短いテキストで要点をぎゅっと、しかも面白く伝える。
ややゆっくり過ごす水曜日
作業記録の共有 Textbox+昨日の作業の振り返り メルマガ+原稿2 『群論への第一歩』+第九章続き 環読プロジェクト+第四章続き KW+ミニエッセイ TH+第三章ブロック１ 8:00 おはようございます。昨日、Textboxの開発に没頭しすぎたせいか、若干ヘタれております。少しペースダウンして過ごしましょう。 Textbox: 昨日行った作業について振り返り、Workflowyを整理しておきましょう。これまでは、次に次ぎに進んで行く形でしたが、振り返りつつ進むを実践しようと思います。 ＊ ＊ ＊ とりあえず作業をして、その後に、その作業について「見出し」を作る。このやり方はgit的でいいですね。採用してみましょう。 ついでに次にする作業もまとめておきました。 9:00 メルマガ: 原稿を書きましょう。 ＊ ＊ ＊ 1時間ほどで、3500文字の原稿を書きました。機能の分とあわせてだいたい7000文字ほど。半分は超えましたね。あともう一つ3000文字か、2000字と1000字で二つ分かといったところ。 16:00 book: 近内さんの『利他・ケア・傷の倫理学──「私」を生き直すための哲学』を買いにいきます。 ＊ ＊ ＊ 無事買えました。 KW: 本日のエッセイを書きます。 TH: なんでもいいので、冒頭部分を書きましょう。 ＊ ＊ ＊ 文章が進まないので、紙に書きだすことにしました。
Textboxを整える火曜日
作業記録の共有 ブックカタリスト+配信予約 Textbox+JSON Callerの実装 メルマガ+原稿1(3800文字） Textbox+Mult Pager TH+第三章の本文 『群論への第一歩』+第九章 環読プロジェクト+第四章続き KW+ミニエッセイ 7:00 おはようございます。本日はTextboxの機能を整えます。 ブックカタリスト: まずは、今日配信される記事の予約から。 ＊ ＊ ＊ OKです。本日17字に配信されます。 Textbox: 昨日は、インクリメンタルサーチで検索候補を表示するところまでできたので、後は中身の実装です。それはまあ明日でいいですかね。 最終的にやりたいのは、テキストを入力、そのままエンターから下に表示されるものから選択してエンター、そのJSONをカードとして表示という流れ。 で、Obsidianのcommand + O では、テキスト欄が空っぽの状態でも選択肢が表示されていて、一番上の項目が選択状態になっている。これはテキストを入力していても同じ。で、エンターを押すと、その一番上の項目が選択されたことになる。 ようは、テキスト欄のテキストはあくまで補助でしかない。で、一つも候補がヒットしない場合は、テキスト欄から選択肢が作られていて、そこでエンターを押すと新規項目の作成になる。 一応この動作をベースに考えよう。 ＊ ＊ ＊ できました。 見た目などは未調整ですが、呼びだしが可能になりました。あとは、どういうjsonファイルを対象にするのかということ。あと、doやhistoryといったファイル名もインクリメンタルサーチの対象にするかどうかですね。 ＊ ＊ ＊ historyは、callしたいものもあれば、そうでないものもあります。英語ノートなどは別に個別に呼びだすことは無さそうです。あと、titleを対象にしているので、type:lineは、本文がtitleに入っているのですごく鬱陶しい。 この辺をうまく調整できれば、すごく便利になりそう。 ＊ ＊ ＊ 残すはマルチページの実装ですね。これができれば、Textbox3.0は達成と言えそうです（2.0はJSONを導入した当たり）。 9:00 メルマガ: 原稿を書きましょう。 ＊ ＊ ＊ 3800文字の原稿を書きました。だいたい二つ分くらいのボリューム。 13:00 『群論への第一歩』: 第九章を頭から読み返していきます。 publish:『群論への第一歩』「第9章 作用」ノート - 倉下忠憲の発想工房 14:00 Textbox: ついでにMult Pagerも実装してしまいましょう。 現状hatchという、独立ウィンドウとして、ページを開く機能があるので、それを改造しようと思います。 表示先を独立ウィンドウではなく、メインウィンドウの「横」に並べるようにすればまずはOKです。 ＊ ＊ ＊
準備を進める月曜日
作業記録の共有 メルマガ+ツイート メルマガ+ファイル準備 Workflowy+タスク管理 R-style+文脈エディタ Textbox+今後の開発の整理 Textbox+Agendaの表示の実装 環読プロジェクト+第四章続き 7:00 おはようございます。本日はもろもろの準備と、Textboxにおけるタスクの扱いについて検討します。 メルマガ publish:メモにある不整合 / ノウハウ研究家という在り方 / 六目式Workflowy / 知性をどう捉えるか｜倉下忠憲 まずはファイルの準備。 ＊ ＊ ＊ OKです。ついでに今週書くこともいくらかあたりをつけておきました。 Workflowy: Workflowyで純粋にタスク管理するとしたら、どうなるかを検討します。 ＊ ＊ ＊ これが一番簡易版の仕方。 publish:Workflowyで簡易情報整理システム - 倉下忠憲の発想工房 タスク主体にしたバージョン。 publish:Workflowyで簡易タスク管理システム - 倉下忠憲の発想工房 これをベースにして、必要に応じて項目を増やすというイメージ。 基本的にこの二つは主眼とする切り口が違っているので、やや排他的ではあるが、融合はできるだろうか。 8:00 R-style: 記事を書きます。 ＊ ＊ ＊ めちゃ長い記事を書きました。 publish:文脈エディタについて | R-style 10:00 Textbox: いろいろ考えがひろがってきたので、当面の開発をどう方向づけるかを考えましょう。 ＊ ＊ ＊
ゆっくり振り返る日曜日
作業記録の共有 今週の振り返り&来週のSTL確認 discrod巡回 Textbox+次のミッションの整理 アイデアノートを眺める 7:00 おはようございます。本日は来週の予定を確認し、プロジェクトのネクストアクションも確信して、あとはTextboxの実装などをやってみましょう。 今週の振り返り: 今週の日記やタスクを振り返りつつ、来週の予定を確認しましょう。 ＊ ＊ ＊ 一週間の予定表が、日記表に変わっているのはなかなか良い。 具体的な行動が「今週やること」に乗っているのは気持ち悪いので、そのやり方は止めるようにする。 「今週やること」をカード型で表示させているが、これでいいのだろうか。一タスク一カードの形ではなく「今週やること」というカードがいいのではないか。で、それを週報に変える。 が、それはそれとして、個別にタスクを管理したい気持ちもある。融合はできるか。 ＊ ＊ ＊ とりあえず、「今週やること」をつくり、それを一週間後に「週報」に作り替えるアイデアはやってみる。で、そのファイルhistory.jsonでもdo.jsonでもなく、diary.jsonという手もある。表示のさせ方次第ではそちらの方がいいかもしれない。todo-board.mdに一緒に表示させるならば、diary.jsonがいいことは間違いない。 ＊ ＊ ＊ command + h で、→home → ideascape→todo-boardに移動できるようになったのがかなり便利。たぶん、memo.mdにもこういう形で移動できた方が良い。しかし、四つ目を増やせば、だいぶ面倒になりそう。 三つに収める場合、何かを統合させることになる。 memo.mdをideaScapeに統合するか、todo-boardをmemo.mdに統合するか。 まず後者から。「今週やること」をmemo.mdで保存するようになったわけで、do.jsonを表示する必要は減ったと考えられる。todo-boardは、diary.jsonとdo.jsonを表示するページなのだから、あとは、diary.jsonをなんとかすればいい、という話になる。memo.mdにdiary,jsonを表示させるというのが安直な解決。 あと前者は、ideaScapeの中で、memo.mdを表示させるやり方。あるいは、ideaScapeの中身をhomeに移動して、ideaScapeの代わりに、meme,mdをトグルストリームに加えるか。 まあ、単純に四つ目を増やしてみよう。それで様子を見る。 ＊ ＊ ＊ command + h でページを移動していると、トグルしている感覚で、巡回という感じがする。それはつまり感覚として「位置」があるということだ。前があり、後ろがある。で、メモ→タスク→ノート（実際はカード）という順番を巡っている感じになる。これって、結構手帳的だ。どういう並びであれ、予定やタスク的なものがあって、次にメモ頁があるというのが一般的な手帳だろう。でもって、一番前にメモできる付箋を貼りつけておくみたいな運用だと、まさにこういう感じになる。 ＊ ＊ ＊ 「今週のやること」をmemoに保存すると、週報への転換は楽なのだが、一方で個別のタスクの詳細を書くことが難しくなる。細かく書けば一覧性が損なわれる。 詳細と概要モデルを適用する？ todo-board(do.json)には、基本的に発生したタスクをすべて登録しておく。つまり「今週やること」と決めたことだけでなく、「やること」をすべて登録する。いわばマスタータスクリストにしておく。で、それらのうちから「今週やる」と決めたものを、「今週のやること」(history.json)に書きとめておく。具体的な内容は、do.jsonにある、という感じ。
メルマガを仕上げる土曜日
作業記録の共有 メルマガ+原稿4 一週間のツイートの振り返り メルマガ+はじめに メルマガ+全体稿の確認 メルマガ+配信予約 アイデアメモの扱いについて検討 PT+メールの返信 KW+ミニエッセイ 『群論への第一歩』+第八章続き 7:00 おはようございます。本日はメルマガ周りの作業を中心に。 メモの整理: あとで読む:【タスク管理】TickTickのいいところと「料理」というリスト - works4Life あとで読む:精選版 日本国語大辞典 あとで読む:知識詰め込み型のマーケターは仕事ができない 「考える力」を鍛えるアウトプット方法：トライバルメディアハウスの「マーケティングの学び方を学ぶ塾」（1/3 ページ） - ITmedia ビジネスオンライン あとで読む:「読むためのトゥルーイズム」第4回解説 - YouTube メルマガ: 原稿を書きましょう。短めを意識して。 ＊ ＊ ＊ 1800文字を書きました。これで本編はOKです。 8:00 ツイート振り返り: 一週間分のツイートを振り返ります。 ＊ ＊ ＊ OKです。 メルマガ: 「はじめに」と「おわりに」を書きましょう。 ＊ ＊ ＊ 書けました。しばらく寝かせて全体を読み返します。 9:00 PT: 編集者さんにメールを返しましょう。 ＊ ＊ ＊
原稿を書く金曜日
作業記録の共有 タスクについて メルマガ+原稿3(2300文字) メルマガ+原稿4 ブックカタリスト+087アフター用記事 新刊チェック→書店 Kindleセールスタート KW+ミニエッセイ 環読プロジェクト+第四章 『群論への第一歩』+第八章 7:00 おはようございます。本日は引き続き、タスク・プロジェクトの管理を検討します。でもって原稿です。 タスクについて: JSONでリストを扱うとして、次なる問題はそのJSONファイルをどう切り分けるか。 現状の選択肢として、history.jsonかdo.jsonか、あるいは新しいファイルを作るかの三択。 現状のプロジェクト・タスクは、do.jsonに置いてあるので、そのままそこに置くのが自然な流れではある。 実行済みとそうでないものを、stateで管理して、表示の切り替えもそのpropertyを使っている。よって、「やること」というコンテキストでデータが統一され、実行済みという過去と、未実行という未来が一つのファイルの中で切り分けられている。 では、これをhistory.jsonに入れるとどうなるか。すでに名前エラーがおきつつある。なにせヒストリーは明らかに過去に属しているわけで、「これからやること」は未来方向舵から。ただ、これを「〜〜をプロジェクトだと認定した」というログだと捉えるならば、一応整合性はとれる。 で、その場合、「執筆プロジェクトリスト」のようなものを作ったら、基本的にそれを更新して使うことになるだろうか。それとも「2024年3月第三週のプロジェクトリスト」のようにアップデートして使うことになるだろうか。同じ項目のタイトルを変えることもできるし、新しい項目として作り、過去分はアーカイブ的な項目にすることもできる。 決めなければならないことが山ほどあるな。 ＊ ＊ ＊ 「週報」は現状historyに保存している。これは過去方向の記録だから問題ない。で、現状「予定」→「日記」の同一化がうまくいっているので、週報にもこれを適用できたらいいとは思う。 つまり「この週のやること」→「週報」という流れ。 これも実際は、週の項目がdiary.jsonにあるので、そこに書くのがいいのかもしれない。また混乱の度合いが増えた。 ＊ ＊ ＊ 「これからすること」は扱いによって、未来方向とも言え、過去方向とも言える（決定したと捉えるならば）。 よって、単に情報の性質だけをみると決定できない。たとえば「済」の扱いにしたいならば、「やること」というコンテキストで統一して、その中で分けたほうがいいだろう。 ＊ ＊ ＊ pin機能を使って、プロジェクトリストなどは先頭に表示させる？ ＊ ＊ ＊ 週報や読書日記などは、明らかに過去方向の情報で、タスクリストは明らかに未来方向の情報で、各種チェックリストは中立的（非時間的）な情報と言えそう。 それぞれは実は分けた方がいい？ history do list diary こういうもの？ たぶんネーミングが違うが、それは置いておく。 とりあえず、listは、lineでもcardでもnoteでもない第四のタイプなのかもしれない。種別で言えば、cardに属するがしかし、微妙に異なる気もする。 行動に関すること、で集合を作れば、やることリスト、プロジェクトリスト、やったこと、などが集まるだろう。各種チェックリストも、行動において使われるのでそこに入るはず。 ＊ ＊ ＊ 着想を書きとめるときは、上記のような種別の判定は働いていない。で、それを整理したり、後から使うときにそういう種別が要請される。これをどう処理するか。 ＊ ＊ ＊ ファイルをわけて管理するのはよいとして、そのビューをどうするか。 現状のmemo.jsで読み込むfileを切り替えるボタンを付ける？ とりあえず、問題はファイルを切り分けると、目に入るものとそうでないものの格差が大きくなる、という点。未来方向の情報ばかり見て、過去方向の情報が見られなくなるとか、その逆とか、そういう事態が起こる。だからこそ、単一のファイルにまとめておくことに利点がある。 ＊ ＊ ＊ とりあえず、history.jsonにまとめてみることに。 ＊ ＊ ＊
うちあわせCast収録な木曜日
作業記録の共有 日記を書く タスク管理について KW+ミニエッセイ 環読プロジェクト+第四章 『群論への第一歩』+第八章 タスクのビューについて メルマガ+原稿2 メルマガ+原稿3 TH+第三章ラフスケッチのコピー TH+第三章ブロック１書く 新刊チェック 14:00~うちあわせcast収録 郵便局に荷を取りに行く 8:00 おはようございます。本日は午後からうちあわせCastの収録です。それまでは原稿を書きましょう。 タスク管理について: 包括的に言えば、すべては「気になっていること」と言える。つまり、タスクも、リマインダーも、プロジェクトも、「気になっていること」という根源的な属性の共通を持つ。極論すればアイデアもそこに含まれるだろう。 その上で、それぞれに求められる操作が異なるから、扱いも異なってくるという状況がある。 そうした差異に注目すると、複数のリストを持つタスク管理ツールが出てくる。 逆に同一性に注目するとどうなるか。一つはGoogle的なものだろう。一つのリストに入れておき、検索などで抽出する。あるいは、AIにぶん投げて答えてもらう。 一つのリストでありながらも、それぞれに性質が異なるというようなこと。JSONであれば可能だろう。実際Textboxでは、line,cardという二つのtypeでカードの描写を制御している。 そのようにして、さまざまな「気になっていること」にアクセスするための一元化ルートを作る。そうすると、簡単に「気になっていること」にアクセスできる。それは嬉しいか？ たとえば、Webブラウザの「履歴」は、履歴一覧として別のウィンドウで表示させることもできるが、アドレスバーにテキストを入力したときに、その履歴からインクリメンタルサーチが行われる。これは、データ全体を利用してはいるが、利用者としては「そのデータ」を直接取り出しているとも言える。 たとえば「読書メモ」という文字列を入力したときに、自分が「気になっていること」に保存したデータからインクリメンタルサーチが行われるなら。ようするにScrapboxでやっていることだ。 ＊ ＊ ＊ CotEditorでも実装自体はできるか。PythonでScriptを書いて、気になっていること2024.mdからテキストを抽出し、リストを作っておく。あとはGUIを作って、インクリメンタルサーチ、という感じ。 でも、実際はTextboxでやった方が良い。あるいは、それ用のデスクトップアプリを作るか。 つまり、「読書メモリスト」というのを作り、読書メモタスクを実行する際にそのリストを参照するのではなく、タスクリストのinputに「読書メモ」と打ち込むと、それまでに自分が「読書メモ〜」と書き込んだ「気になっていること」の項目がサジェストされる、という感じ。 これが「入力と利用」の一致を促す。これは、ビューの設計ではない。一つの新しい掲示を得た。タスクリストのようなものは作らない。それでいて、タスクをアシストするもの。 Scrapboxと同じで、タスクを入力しようとしない限りは、そのサジェストはまったく効果を持たない。その意味で強制性は薄い。逆に言えば、普段は邪魔にならない。 ScrapboxやObsidianでも、一枚一ファイルで作っておけばいける。Workflowyならもっと簡単か。タスクを入力するときに常にリンクにすればいいだけ。 この方向を追求してみるのは面白そう。 もちろん「読書メモ」という入力をしないと、何もサジェストされないわけだが、空っぽのときは直近の5つをサジェストする、的なことをすれば自分が希望しているのと近しいものにはなるだろう。 とりあえず、ビュアーから入力サジェストへ、という流れは悪くない。 その上で、あらためてビューについて考える。 上記のサジェスト用データがあれば、ビューを作ることもできる。そのビューは「何のために」作られるのか。 一覧することで得られる安心感的なことだろうか。 ＊ ＊ ＊ 行為はタスクとして実行されて、つまりそれは作業記録にログが残る。だから、「気になっていること」のアーカイブはあまり必要ではない。特に実行済みかどうかの情報は必要なくて、単に不要なら削除すればいい。「気にならなくなったこと」は、「気になっていること」ではないので、それは削除しなければならないが、だとしたら「気になったこと」というログ指向にすれば解決。 あとはビューの問題。 ＊ ＊ ＊ たとえば、上記をWorkflowyで実行するならば、どこかしらにデータを置いておき、その項目へのリンクを作る、という形になる。これはいい。 で、Workflowyでデータを置くということは、リストにするということ。種別ごとのリストにしてもいいし、統一的なリストにしてもいい。よって、どう実装するかはかなり自由。途中で変えて問題ない。項目が、どの項目の子どもなのかよりもどう記述されているかの方がはるかに重要。でもってそれは健全なスタイルと言える。 OSベースでやるならば、変換の単語登録にすることになる。が、それはあまりにもという感じ。 何かのショートカットキーで入力ボックスだけ表示するアプリケーションを作り(Raycastのような感じ）、そこでインクリメンタルサーチをして、決定を押したらクリップボードにコピーされる、という具合になるだろう。CotEditorの現在のカーソル位置に直接挿入できたらGoodだが。 では、Textboxではどうだろうか。「今日のタスクリスト」のようなページでタスクの入力をするときに、サジェストが働くようにする。あるいは、タスクの入力だけでなく？ それこそJSONからインクリメンタルサーチで項目を探せる機能がそれに当たるのではないか？巨大なデータセットでも、言語空間が重ならないのならば単一のJSONでも問題ない。 もちろん、タスクのときはタスク、本のタイトルのときは本のタイトルとドメインが切り分けられるのがよいとは思うが、これもタスク名の記述に気をつければ、切り分けは不要になるかもしれない。 入力時にサジェストを表示させようとすると、textareaでは少々厳しい？ そんなこともないか。カーソル位置の座標さえ分かるならば、一応は行けるはず。ただ、すべての入力に反応はできないからやはりリンクを作ってということになるが、ということは、入力されているのがリンク記法なのかどうかという判断を常に働かせる必要はある（textareaのvalueを、正規表現でマッチし続ける）。 というか[[というものを入力したら、特別なインプットボックスを表示させるというのでもいい。とにかく、入力することと、その入力するときに以前に作ったデータセット（ようするに入力したもの）が活かされる形をつくればいい。 できるだけ自然な形で、つまり「今からリンクを呼びだすよ」のような強い意志の発露なしにサジェストが動くのがいいとは思う。この辺は要検討。 ＊ ＊ ＊ で、ビューについて。ビューについての考えがあまり深まらない。 もしかして必要なのかもしれない。 「気になったこと」のデータセットがあり、それがサジェストされるか、せいぜいリストで一覧できれば十分？ 少なくとも、Scrapboxはその思想だ。可視化して安心感を得るというその心理性に抗っている気がする。 実際、タスク入力時にサジェストされるだけで十分ということはある。でもって、そのサジェストを有効にするためにデータセットに入力しておこうというモチベーションが高まる効果もあるだろう。「使う」からその効果が感じられる、というような。 というか、Workflowyがビューとリンクの実装してはたぶん完璧。これ以外の形は結構「あえてやっている」感が出てきそう。それを踏まえて、あえてTextboxでやるとしたらを考えたい。
タスク管理を固める水曜日
作業記録の共有 タスク管理の制定 うちあわせCastの確認→実施 メルマガ+原稿 1 TH+第三章のアウトライン作成 レシート入力 『群論への第一歩』+第八章 環読プロジェクト+第四章に入る KW+ミニエッセイ 8:00 おはようございます。本日は、タスク管理の方法を固めましょう。 タスク管理の制定: 大きな問いは「自分は、どういう形のタスク管理が必要か」というもの。 それに合わせる形で、タスク管理ツーツを設計していく。 ＊ ＊ ＊ 実行については、デイリーベースで問題なく回っている。課題があるとすれば、そのデイリータスクリストの「つくり方」だろう。何かしらのリストを参照せずに作っているので、出たとこ勝負の日が多い。それがよいのかどうか。 ＊ ＊ ＊ ネタ帳と考えたいことと気になっていることは、同じか違うか。 ＊ ＊ ＊ Obsidianに、新しいHomeを二つ作る。 「2024年3月プロジェクトノート」「2024年3月気になっていること」の二つを作った。一瞬「2024年3月プロジェクトノート_home」のようにインクリメントサーチで見つけやすくしようと思ったが、見た目が不細工なのでやめておいた。 たぶん、デジタルノートであればこのやり方でうまくいくと思う。ネタ帳はどちらでもいい。 もし分類したければ、ページの中でリストを分ける。たとえば「気になっていること」の中で、「買い物リスト」や「行きたい場所」などを作る。 これはこれで保険として運用できると思う。 ＊ ＊ ＊ プロジェクト→一つ上の視点 気になっていること→メモ全般 タスクリスト→具体的な行動一覧 考えたいこと→作業場所 ネタ帳→ややタスク たとえば、プロジェクトノートの上部に現在コミットしているプロジェクトをいくつかリストし、その下に具体的な行動を並べるという方法がある。 プロジェクトの全般はまた別のノートで持っておく。ようするにマスター。 ＊ ＊ ＊ 実行することと、思考すること。それらを区別するかどうか。 ＊ ＊ ＊ たとえば「通帳記入」という気になっていることは、ただ実行すればいい。分解も必要ないし、思考の展開も必要ない。一方で「粗大ごみで大きな物置きを捨てる」だと、実行のためにいくつか事前準備が必要かもしれない。中身を片づけておくとか。GTDにおけるプロジェクト。順行(in order） ＊ ＊ ＊ 順当にやるならば、「3月の気になること」に次々メモしていく形がいいのだろう。そこから他の場所に移動させたりする。で、次の月になったらまるっとリストを新しくする。そういう運用。 それがまっとうなやり方であるとして、ぜんぜん別のアプローチを考えてみる。 月ごとに切り分けないで、すべての「気になること」が入っているとしたら？ それをたとえば、YahooインデックスがGoogleに切り替わったようなパラダイムで迎え入れたら？ ＊ ＊ ＊ たとえばここに「買い物」と入れたら、その条件にあう「気になること」が抽出される。そこからたとえば買い物リストを作る、ということをしてもいい。 そうしたフィルターはJSONだとやりやりやすい。しかし、テキストデータであっても、改行で分割して配列にすれば同じようなフィルターは可能。でもって、そのデータからHTMLを生成すればいい。それ自体は可能。 あとは、その検索をどうするか。つまり「買い物」と検索して、買い物がうまくピックアップされるようにするためには、データの入力をどうするか。 一つは、書きとめることに「買い物」という語句にするようにしておく。もう一つは「買い物」というタグを付ける。タグはテキストベースならハッシュタグ、JSONならaddressになる。 ＊ ＊ ＊
ブックカタリストな火曜日
作業記録の共有 Obsidian+テーマーボードの拡充 タスクとメモについて考える タスクについて考える 『群論への第一歩』+第八章 環読プロジェクト+第四章入る メルマガ+原稿1 TH+第三章のアウトラインを考える 13:30~ ブックカタリスト収録 8:00 おはようございます。本日はブックカタリストの収録です。午前中は、原稿作業を進めましょう。 タスクとメモの扱いについて: Textbox上でのプロジェクトの扱い方に見通しが立ったので、その次に「タスク」の扱いについて考えたいところ。でもって、それはメモの扱い方と考えることとも関係してきます。 ＊ ＊ ＊ 富豪的タスク管理というアイデアを思い付きました。これをベースに考えを進めたいところです。 publish:富豪的タスク管理 - 倉下忠憲の発想工房 問題は、ファイルをプレーンテキストにするのかJSONにするのか。メタ情報をどう管理するかでそれが変わってきます。 12:00 『群論への第一歩』: 第八章の続きを読みます。 13:00 ブックカタリスト: 収録です。 ＊ ＊ ＊ 終わりました。アフターの下書きを書くタスクが発生しました。 17:00 タスクについて考える: プロジェクトにまつわる、自分がコミットを確認しているタスクについては、memo,mdに入れていく、というやり方はよいとして、ワンアクションだけのタスクはどうするか。あるいはそうしたタスクの手間にある「こうこういうことをしたらいいかも」というような思いはどう拾っていくか。 どこかのテキストファイル、あるいはWorkflowyにつらつらと書き連ねていくというのが一つ。いや、Worflowyは長大なリストにならない場合だけ可能。もし長大なリストになるならば、テキストファイルないしはJSONがいいだろう。 単にテキストファイルだけでも、それなりにメタ情報を持たせることはできる。 すべノーの試験問題利用の履歴をまとめておく 2024/03/5 #執筆補助 みたいに書いて、正規表現でマッチすれば、日付やらタグやらは付与できる。 そういうものをずら〜〜と縦に並べていく、というのが一つの方策。todo.txtとコンセプトは同じになるだろう。 あとはどういうビューで眺めたいのか。 案1：普通に縦長のリスト 案２：何かしらの区切りを入れて、カードでまとめる（たとえば、2024年3月のやること） 案３：基本的には表示させない。あるいは上位５つだけ表示させる。あとは検索して見つける 案４：一行を一つのカードとして表示させる。 タスクの手前の「気になっていること」と殆どタスクの「やること」。そのグラデーションをどう扱うか。 あるいは企画案などの「やりたいこと」はどうか。それをみてテンションがあがるかどうかの違いがある？ ＊ ＊ ＊ ハッシュタグでもいいが、タスクに含まれる名詞や動詞で抽出する？ たとえば、テキストだけで「読書メモ」というタスクだけを抜き出すことはできるか。 ハッシュタグにしておくならば、それを抜きだしてボタン機能を付与することはできる。そのボタンを押したら、同じハッシュタグのボタンが含まれている項目だけを抜粋する、ということはできる。HTMLの要素を抜粋するというよりは、それ以外のdisplayをnoneにする、という感じだろうか。 保存するときは、displayを無視すればいい。あと、リンクのボタンも消せばいい。URLがないならば処理は比較的簡単。 仮にJSONでやっても、アウトライナーっぽい表示にするのがいいかもしれない。 テキスト形式ならば、ideaScapeと同じ処理をすることで、階層を扱える。 実際は、「プロジェクト」やプロジェクトの次の一歩も、広い意味で「気になっていること」であり、包括的な整理が可能ではある。 もし、JSONにするなら、これをdo.jsonで保存するのがいいだろう。テキストファイルで保存するならば、ideascapeと同じで、テキストを保存してあるファイルと、それを表示するビューのページを分けるのがよいと思う。 ＊ ＊ ＊ 順番の任意の入れ替えがやりやすいのは、テキストファイルの方だ。これをどう考えるか。これまでのmemo.mdは別段入れ替えは必須ではなかった。ただタスクではそういう操作もあった方がいいとも思う。ふむ。