原稿を書く金曜日
作業記録の共有 タスクについて メルマガ+原稿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は別段入れ替えは必須ではなかった。ただタスクではそういう操作もあった方がいいとも思う。ふむ。
準備を進める月曜日
作業記録の共有 メルマガ+ツイート メルマガ+ファイル準備 メルマガ+お題設定 TH+第三章のアウトライン立案 Obsidian+テーマボード作成 Obsidian+テーマボード拡充 Textbox+プロジェクト情報の管理 環読プロジェクト+第三章レジュメ KW+ミニエッセイ 群論への第一歩+第八章続き 9:00 おはようございます。本日はもろもろの準備デーです。 publish:メモの随伴性２ / 情報カード、縦から書くか？横から書くか？ / 一週間に見出しをつける / Excelとデジタルツール的思考｜倉下忠憲 Obsidian: テーマノートを作ります。 ＊ ＊ ＊ 通常はテーマに合わせて黒背景なのですが、CSSを上書きして白にしました。 あとはここに自分がテーマ群について考えていることをつけていきましょう。 一旦書き終わったらスナップショットを残しておくのもよさそうですね。 メルマガ: ファイルの準備です。 ＊ ＊ ＊ ファイルの準備はOKです。 ＊ ＊ ＊ 今週書くことも暫定的に決めておきました。 あとで読む:Make.md 13:00 プロジェクトの管理について: プロジェクト的な情報をどう扱うのかを検討しましょう。 ＊ ＊ ＊ たとえば、こういうのがよくあるパターンでしょう。 これ以外にどんな形があるのか。 カードスタイル。 https://gyazo.com/42c4441efd0085f15e95818f09da60c0 カードの構成方法を変更。これはこれであり、もっとmemo.mdページに寄せて、プロジェクトやタスクをそれぞれ一枚のカードやラインとして表示する手はある。あるいは、いっそのことmemo.mdに書き込んでも言い。 ＊ ＊ ＊ projectを特別なページとして作り込んでもいいし、テキスト+箇条書きでいい感じに見せるだけに留めておいてもいい。あるいはmemo.mdと統合して、閲覧頻度をあげてもいい。 ビューの設計に加えて、いつ入力し、いつ閲覧し、いつ修正するのか、という観点も必要。 ＊ ＊ ＊
ゆっくり過ごす日曜日
作業記録の共有 来週のSTL確認 discord巡回 アイデアとテーマの扱いについて 7:00 おはようございます。本日は来週の予定などを確認し、その後はゆっくりと考え事をして過ごしましょう。 あとで読む:集合的予測符号化に基づく言語と認知のダイナミクス： 記号創発ロボティクスの新展開に向けて 来週のSTL確認: 来週の予定周りを確認します。 ＊ ＊ ＊ 予定とタスクはOKです。日記との連携もいい感じになってきました。 あとはSTLの「L」で、この立ち位置がまだはっきりしていません。各種のリストをどう管理するのかは、また検討しましょう。「今月読みたい本」などをリストにしておくのは有効だと思うので、あとはそれをどのように「目に入れる」ようにするかですね。 8:00 情報環境: 自分の情報環境をちょっと整理してみましょう。全体の図を描くと膨大になるので、まずは部分的に。 一週間の終わりに、次の一週間の予定を確認し、Textboxに入力することで「予定表」を作るのがファーストステップ。以前はこれで終わっていたが、今はその入力した予定を起点にして「日記」を書くようになっている。これはすこぶるよい。 「予定」→「日記」 でもって、週報。週報はhistory.jsonに他のメモと混ぜて記録するようになった。「週報」というアドレスを当ててある。でもって、lineではなくcardで保存するのでタイトルをつけることになる。そのタイトルは、週の期間表すデータではなく、一週間の「見出し」のような一文にしている。これもなかなかよい。 週報の中身をどう書くかはまだ固まっていないが、大枠としては運用はスムーズにいっている。 「週報」→「一週間の見出し」
メルマガを仕上げる土曜日
作業記録の共有 メルマガ+原稿4 ツイート振り返り メルマガ+「はじめに」 メルマガ+全体の読み返し メルマガ+配信予約 『群論への第一歩』 8:00 おはようございます。本日はメルマガです。一つ書いていない原稿があるので、それを書き、その後「はじめに」などを調整しましょう。 Textbox: システムを改修したおかげで、「今日のカード」や「昨日のカード」を呼びだしやすくなりました。で、だいたい朝に昨日の日記をちょこっと書きつけています。これがなかなかよいです。 特にこの「日のカード」は一週間の前に予定を確認するときに使っているので、それがそのまま日記に書き変わるのが快適です。 たとえば、予定では「病院にいく」と書いてあったら、そのまま日記でその記述を利用して文章的記述を続けることができます。ようするに、Googleカレンダーにそのまま日記を書いている感じ。ただ、Googleカレンダーは予定＋メモの形になっているので、完全な文章型日記にしにくいのですが、この場合はほとんど思ったような形になっています。たいへんよいです。 メルマガ: では、４つめの原稿を書きましょう。 ＊ ＊ ＊ 2000字ほどの原稿が書けました。これでOKとします。 9:00 ツイート振り返り: 一週間分のツイートを振り返ります。 ＊ ＊ ＊ OKです。 メルマガ: 「はじめに」と「おわりに」を書きます。 ＊ ＊ ＊ 書けました。 11:00 『群論への第一歩』: 8章の続きを読みます。 毎日少しずつ。 12:00 メルマガ: 全体の読み返しを進めましょう。 ＊ ＊ ＊ OKです。 13:00 メルマガ: 配信予約作業に移ります。 ＊ ＊ ＊ まぐまぐOK。 ＊ ＊ ＊ noteもOKです。 これでメルマガ作業は一段落。あとはメモの扱いについて考えましょう。 19:00 アイデアメモの扱いについて: まず、毎週ツイートを振り返り、ピックアップしていく行為があります。 で、一ヶ月分が溜まったら、それをJSONに変換してTextboxで表示できるようにする。 Textboxでは、カード状に陳列され、それらを見ながらタグ付けしていくことができるようになっています。で、タグ付けしたものは抽出して表示可能、と。 流れが決まっているのはまずこれだけ。 で、このidea.jsonは現状ツイートまとめファイルからの転記になっているわけですが、Textbox上で直接項目を追加できてもいいでしょう。あるいは、一旦その月のツイートまとめファイルに追記しておき、あとから合流させるというやり方もできそうです。 ここまではいいとして、その次です。抽出して表示したものからどう次のアクションに移るのか。そして、タグづけなどをしているときに浮かんできた「全体図の構想」をどう扱うか。これが次なる課題です。
原稿を進める金曜日
作業記録の共有 Textbox+ストリームの調整 Scrapbox+infoboxのテスト アイデア整理 メルマガ+原稿4 KW+ミニエッセイ 環読プロジェクト+第三章 群論への第一歩+第八章続き 8:00 おはようございます。今日は午後から妻の病院の付き添いです。午前中はメルマガの原稿などを進めましょう。 Textbox: メモストリームの調整を少し。 Scrapbox: 新機能をテストします。 publish:Scrapboxのinfoboxのテスト - 倉下忠憲の発想工房 9:00 メモの整理: あとで読む:目指すのは、『高度情報民藝運動』｜MojoSugiyama 12:00 アイデア整理: いくつか考えたことの整理と、考えたことをどう整理するのかを考えます。 publish:「考える」は行為であり、体験である - 倉下忠憲の発想工房 やはり、Scrapboxに置いておくのが一番アイデアを「広く」使える。ただし、ただページを作るだけでなく、関連ページを読み返し、記述をリライトしていく必要がある。場合によって、新しいページを作ることも。 ネタ帳として使うのではなく、それ自身をアウトプットとして。 で、それはそれとして、別のまとめノートみたいなものがあった方がいいかもとは思う。 というか、アイデアメモをScrapboxに移しながら、それと並行してまとめノートを作る、というのがよいのではないか。 15:00 環読プロジェクト: 第三章の読書メモです。 ＊ ＊ ＊ とりあえず、第三章は終わり。レジュメをまとめましょう。 『群論への第一歩』: 第８章の続きを読みます。ゆっくりと。 16:00 KW: 今日のエッセイを更新しましょう。 あとで読む:集合的予測符号化に基づく言語と認知のダイナミクス： 記号創発ロボティクスの新展開に向けて 19:00 KW: Obsidian入門を更新しましょう。
THを書く木曜日
作業記録の共有 メルマガ+原稿3 TH+第二章手直し 8:00 おはようございます。今日は午前中は妻のつきそいでお出かけ。今日中にTHの第二章を送信したいところです。 Textbox: 朝一に開きたいのは、今日のカードではなくむしろ昨日のカードということに気がつきました。日記的なものを書きたい。 caller(selector)を実装すれば簡単ですが、現状の「今日のカード」から「昨日のカード」へのジャンプを考えましょう。 ショートカットキーを押して、前日のカードを表示させるというやり方です。 ＊ ＊ ＊ できました。command + ←で前日のカードを表示です。このとき、今日のカードを消して前日を表示するのか、追加で前日のカードが置かれるのかに分岐がありますね。現状は単に追加するだけにしておきます。 メルマガ: 三つ目の原稿を書きましょう。 ＊ ＊ ＊ 2500文字の原稿を書きました。あと一つくらいですね。 13:00 TH: 第二章の原稿をgoogleドキュメント上で直しましょう。 ＊ ＊ ＊ かなり時間がかかりましたが、いただいたコメントの反映および修正を終えました。あ〜疲れた。
原稿を進める水曜日
作業記録の共有 Textbox+リマインダについて Textbox+アイデアの整理について Textbox+Homeについて メルマガ+原稿2 うちあわせCast確認→お休み Textbox+アイデアストリーム 7:00 おはようございます。今日は原稿を進めつつ、Textboxのカードシステムについて考えます。 ＊ ＊ ＊ Textboxのリマインダーについて。Home画面に戻ったタイミングで、というのを考えていたが、だいたいHome画面で終わり、次の日もその画面からスタートするので求めているタイミングでリマインダーが表示されない可能性が高い。 むしろ、メモーダルを立ち上げたり、今日のカードを立ち上げたりするときに表示させるのがいいだろう。 あと、メモーダルとカードを統合できないかも考えたい。現状のcallはすでにあるJSONの項目を呼びだすことだが、まったく新しい項目を入力するためのブランクカードを表示できれば（そして保存ボタンの動作を変えれば）、メモーダルと役割が似てくる。 メモーダルは、history.jsonの名前の通り、入力しつつ過去のものを表示させるという役割があり、その辺をどう整合させるかは考えたい。 まあ、二つ入力画面があっても構わないわけだが。 メモーダルは過去の履歴が表示されると共に、タグの選択も過去の履歴から可能になっているので、書いたものと邂逅する可能性が上がる点がよい。ある意味で、リマインダーではあるか。リセントリーなものを表示するリマインダ。 で、リマイダーについて。 一応メモーダルを立ち上げたときでもリマインダーを表示させることはできるし、ある意味で自然な流れかもしれない。「今日のカード」を表示するときでも変ではないか。 前者の場合、モーダルなので入力が終わればリマインド表示も消える。後者はおそらく「カード」として描写するのでそのまま残る。その違いがある。そしてこれは大きな違いだ。 単に通知的なものと、チェックリストのようにその場に残ってくれると嬉しいものがあるに違いない。リマインドされるものによってちょっとタイプが変わってくるわけだ。 たとえば、名言とか英語の一文などは一度目に入りすればいいわけで、固定的に表示させておく必要はない。表示されたカードを消すための操作も面倒。 ルーチンのリストなどは、むしろ「今日のカード」に自動的に追加すればいいのではないか？少なくとも、それらはたしかに「今日のカード」の項目足りえる。いちいち別にカードを表示させて、転記する、みたいなことをやる必要はない。 一方で、名言とか英文は「その日のノート」と言えるかは怪しい。ほぼ日手帳のように、入力欄の下に別途そういうものを表示させてもいいが、なんとなくそれはアナログ的なやり方に思える。 たとえば、原稿command + p は今日のカードを表示するためのコマンドになっている。selectorを呼びだすコマンドにする予定だったが、とりあえずは「今日のカードを表示する」というコマンドにしたとしよう。 そのときに、今日のカード+αを表示させるというやり方はできる。たとえば、今日の日付から-7したものとか、そういうの。そうしたものを、小さいカードで周辺に描写する。あるいは、名言集から引っ張ってきて、カード化する。そのための関数も準備して、発動する。 単純にそれをやると、command + P を押す度にたくさんのカードが描写され、いちいちそれを消してまわらなければならない。 それは好ましくない。かといって、command + pの操作自体によってそうしたものを消したり出したりするのは、モーダルとあまり変わりない。つまり、カードを表示させているのではなく、「今日のカードを書くモード」を作ってしまっている。 ちょっと思ったが、command + p はまずセレクターを表示するが、セレクターはデフォルトで「今日のカード」が選択されていて、何も操作せずにそのままリターンすると「今日のカード」が表示される、というのはどうだろうか。 ＊ ＊ ＊ セレクター経由で呼びだすならば、単に今日のカードを表示するのと「今日のカードセット」を表示するので分けられる。後者は連用日記的なものも一緒に表示するという操作。 ふむ。 とりあえず、セレクターを実装してみるのがよさそう。 ObsidianやVS CodeのUIを真似するのがいいだろう。 Obsidianのcommand+oのモーダル - 倉下忠憲の発想工房 HTMLに初期配置して消しておくか、操作のたびに生成するかすればいい。同一のものを使い回すし、モーダルになるからindex.htmlに置いておいてもいいだろう。 これを実装してみて使い勝手を検討しよう。 8:00 Textbox: 続いて、アイデア整理について。特にカードを併用する整理について。 現状ideaScapeに、以下のような形でメモが並んでいる。あるいは、tweetlistにはツイートの履歴がカード形式で残っている。これらはうまく保存されているが、ここからの展開を考えたい。 最初は、ideaScapeにリンクを置き、そのリンクをクリックしたら、左側にページとして開くという機能を実装したのだが、最近はほとんど使っていない。その代わりに、細かいメモ2〜3個をちょっとまとめたい、というニーズが生まれている。 だとしたら、新規カードの作成を行い、そこに書き写す形で「処理」していくのはどうか。「考え事」のタグをつけるなどして、拾えるようにしてもいい。 で、このideaScapeにあるタイムラインについてはむしろHomeに表示させた方がいいのではないか。あるいはこのページをホームにしてもいいが。 この辺の調整は別途検討する。 tweetlist的なものも、「カード」それ自身に処理はできるが、カードを見ながら考えたことがそのままでは掛けない（メモダールを表示する必要があり、モーダルだからカード表示が消えてしまう）。この点を考えるとやはり、モーダルとは別にカードの形で新規作成できた方がいい。 よって、方針は二つ。 まず、セレクターのUIと機能を実装する。でもって、空っぽのカードを描写できるようにする。後者は、まずJSONに新規項目を作り、その項目を呼びだす、という形を取ってもいいし、普通にカードを描写して、それを空っぽにしたものを保存する形でもいい。 で、セレクターから「新規カード」の選択が選べればいい。