うちあわせな火曜日

作業記録の共有 book-map作り Obsidian+Webクリッパー メルマガ+原稿2(4000文字) デジタル書斎術+内要検討 14:00~うちあわせ KW+ミニエッセイ 読書メモづくり+フィールドワーク本 7:00 おはようございます。本日はCastではないうちあわせが午後からあります。午前中はその準備と、それ以外の原稿を進めましょう。 book-mapづくり: 買った本をMapで整理する、という試みをやりたいと思います。最終的にはTextboxでの実装を目指しますが、まずはObsidian Canvasでやってみましょう。 [[/Canvas/bookmap.canvas]] ＊　＊　＊ とりあえず、こういう感じになりました。 書籍のノートがなかったので、それを作るのに手間取りましたが、もしこういうノートがはじめから存在しているならば、一応手軽には作れそうです。 現状のWebクリッパーでは望むノートが作れないので、ブックマークレットを調整する必要がありそうです。 ObsidianでURLを使ったWebクリップ - 倉下忠憲の発想工房 Obsidian: Webクリッパーが正式実装された感じです。 とりあえずFirefoxには入れてあるので、Safariでも試したいところ。ただ、「記事」のページしか綺麗に切り取れない印象。広告が本文に埋め込まれているものも手を入れる必要がありそうです。 8:00 メルマガ: すでにめちゃくちゃ眠いですが、とりあえずメルマガだけは書いておきましょう。週末にイベントがあるので、今週は巻き返しができないため。 ＊　＊　＊ 二つ目の原稿を書きます。 ＊　＊　＊ けっこう時間がかかりましたが、4000字ほどの原稿が書けました。 12:00 一日一英文: Many people encouraged me to fulfill my ambitions. 環読プロジェクト: 第六章を続けます。今日で読み終わりそうです。 ＊　＊　＊ 「Chapter06 メモをとるときは、つながりを意識する」を読む - Knowledge Walkers あとはまとめですね。 14:00 うちあわせ: zoomでうちあわせです。 ＊　＊　＊ 30分ほどで終わりました。 15:00 ニュースレター: デジタルノート研究会の記事を書きます。

ブックカタリストな月曜日

作業記録の共有 旅の準備 メルマガ+ツイート メルマガ+ファイル準備 メルマガ+原稿1 TH+第一章の書き下ろし デジタル書斎術+内容の検討 13:30~ ブックカタリスト収録 住所変更手続き+出版社への連絡 一日一英文 環読プロジェクト+第六章 7:00 おはようございます。本日は午後からブックカタリストの収録です。それまでは、いろいろ準備作業を進めましょう。 旅の準備: 移動の新幹線および電車、ホテルの場所やルートを検索しておきます。 ＊　＊　＊ だいたいOKです。 宿が新宿なので、ブックファースト新宿店はいってみたいですね。 8:00 メルマガ: publish:CT連載03：リストって何？ / 方法の発見 / 本棚の新構築その２ / ボードゲーム風シンキングツール｜倉下忠憲 まずはファイルの準備から。 ＊　＊　＊ OKです。 だいたい書くことも決めておりました。 あとで読む:「Python」で簡単にGUIを構築できる国産フレームワーク「TkEasyGUI」がv1.0に - 窓の杜 9:00 TH: 第一章を少し書きます。 ＊　＊　＊ 冒頭の数行を書きました。 10:00 一日一英文: Many people regard the current compulsory education system as being obsolete. 11:00 環読プロジェクト: 第六章の続きを読みます。

ゆっくり過ごす日曜日

作業記録の共有 来週のSTL確認 週報作成 デジタルツールの運用について検討する WorkFlowy, Capacities, Evernote, Obsidian 電車の時間を調べる ブックカタリスト+102話すことの確認 デジタル書斎術+内容の検討 一日一英文 環読プロジェクト+第六章 7:00 おはようございます。本日は来週の予定などを確認して、残りはゆっくりしたいところですが、来週の日曜日にはもう東京でイベントなので、その辺の準備もしっかりしておきたいところです。 来週のSTL確認: まずは来週の予定確認から。 ＊　＊　＊ Textboxで来週の予定を書き込むときにエラー。JSONの構造が変更されて書き込まれてしまっている。 とりあえず、DropboxでJSONファイルを復元した。コードのエラーをチェック。 ＊　＊　＊ 保存は　updateJSON() を使っている。これは cgi-updateJSON.cgi にデータを送る関数。 で、このcgi-updateJSONは少し前に書き換えたものだ。そのリファクタリングがうまくいっていなかった。 現状Textboxで扱っているJSONは、mainがあって、そこにデータが入っているものと、直接データが入っているものがある。そうするとデータを変更するためのアルゴリズムが違ってくるので最初に「mainを持っているかどうか」で分岐させて、処理していた。 そのif文が不格好だったので書き換えたのだが、それがまずかった。 変数Xにデータを入れる。ただし、mainを持っていたらmainの中身をXに入れる、という処理でスムーズに書き換えられたのだが、そうして書き換えたデータを保存するときのことを考慮していなかった。Xをそのまま保存していたのだ。 mainの中身をXに入れて、それを保存したら一つ上の階層が消えてしまう。うまくいかないのも当然である。 というわけで、そもそもすべてのデータをmainありにすべきなのだが、それはそれとして処理の方法をいったん前のバージョンに戻すことにする。 たぶんこれで大丈夫だと思う。 ＊　＊　＊ OKでした。 9:00 来週のSTL確認: 各種プロジェクトをチェックしていきましょう。 ＊　＊　＊ プロジェクトまわりもOKです。あとは、各種リストを。 ＊　＊　＊ リストまわりもOKです。 10:00 妻と30分ほど散歩していました。 あとで読む:柳澤　田実：消費社会の宗教、ファンダム・カルチャー｜特集｜三田評論ONLINE 11:00 一日一英文: The minister was obliged to resign from the Cabinet.

メルマガを仕上げる土曜日

作業記録の共有 ツイート振り返り メルマガ+「はじめに」 メルマガ+全体項確認 メルマガ+配信予約 おとなの書斎術+使い方の紹介検討 ブックカタリスト+102準備（本の神話学） 考え事ノートをデジタルでやるには？ 7:00 おはようございます。本日は、まずメルマガを仕上げて、残りは原稿作業にあてます。 Evernote: 来年からはもうあまり使う気持ちがないEvernoteですが、ここにきてやっぱりいいな感が出ています。使うのが楽なのがいいですね。オブジェクト的な考え方も整ってきているので、それを使えばもう少し利用しやすくなるのでは、という感じもあります。 まあ、最終的には使わないとしても、もし使うならどうするのかは考えておいてもよさそう。 階層とネットワークの両方が意識できるようになったので、どういうノートツールでもだいたい思う感じで使えるようになってきた。 ツイート振り返り: 一週間分のツイートを振り返りましょう。 ＊　＊　＊ ツイートの振り返りが終わりました。いくつかは、抜き出してTextboxに入れました。 Knowledge Walkersのつぶやきまとめページも更新完了です。 8:00 メルマガ: まずは、「はじめに」を書きます。 ＊　＊　＊ 「はじめに」と「おわりに」が書けました。 10:00 メルマガ: 全体稿を確認しましょう。 ＊　＊　＊ OKです。 12:00 お昼はカレーヌードル。 メルマガ: 配信予約作業に移りましょう。 ＊　＊　＊ まぐまぐOK。 ＊　＊　＊ note、OK。これで今週のメルマガ作業は一段落です。 13:00 一日一英文: The government did not take appropriate measures to prevent the infection from spreading. 環読プロジェクト: 第五章に入ります。 ＊　＊　＊

原稿を書く金曜日

作業記録の共有 TH+第一章の内容検討 TH+第一章肉付け TH+編集者さんに共有 ブックカタリスト+セミナー準備（画像を作成） 一日一英文+ 環読プロジェクト+第四章 舘神さんの本を紹介する 7:00 おはようございます。結局昨日は、THがあまり進まなかったので、本日頑張ります。 TH: 第一章の肉付けを。 ＊　＊　＊ 少し項目を書き足しました。 Capacities Capacitiesのカードビューはとてもよく、下の矢印ボタンでカードをくっていけるのですが、並び順がソート限定なのが一番のネックです。 ＊　＊　＊ そうか。そういうときに、ツェッテルカステンの枝番号を使えばいいのか。 ＊　＊　＊ タイトルの頭に接頭辞としてナンバリングを振り、カードをアルファベット順にソートしました。まさにツェッテルカステンがやっていたことそのままですね。これはとてもいい感じです。 ＊　＊　＊ テーブルビューにしたときに、descriptionが表示されて、noteの本文は表示されないことがわかったので、本文はnoteではなくdescriptionに書くことにしました。でもって、カード法の使い方としては、まさにこれが適切だと感じます。 9:00 TH: 第一章の肉付けを続けます。 ＊　＊　＊ 結構できました。この段階でいったん共有しておきましょうか。 11:00 一日一英文: Our hypothesis is that eating excessive amounts of junk food contributes to early mortality. 環読プロジェクト: 第四章に入りましょう。 ＊　＊　＊ 「Chapter04 「メモ」はあなたオリジナルの「思考」を生む魔法のツール」を読む - Knowledge Walkers

THを進める木曜日

作業記録の共有 Notionの整備+蔵書ノート メルマガ+原稿状況確認 メルマガ+原稿4(4000字) TH+第一章の内要検討 一日一英文 [-] 環読プロジェクト+第二章のまとめ 環読プロジェクト+第三章 ブックカタリスト+102の準備 ブックカタリスト+セミナーの準備（画像を準備） WorkFlowyでのメモの集まりの管理 7:00 おはようございます。本日はTHの原稿を進めましょう。 Notion: たとえば、Notionで書籍管理のデータベースを作ったとします。で、そこから読書メモ・ノートなどをとれるようにしたいとする。そういうとき、どうすればいいか。知的生産におけるNotionの使い方。 ＊　＊　＊ 基本的な書誌情報は、ネットで検索すれば見つかるのだとして、しかし、最悪ネットワーク環境下にない場合でも参照できるように（その場合は、そもそもNotionにアクセスできないわけですが、それはさておき）、最低限の情報は残しておきたい。 いや、そういうことではないな。調べたらわかるのに書き残すのは、なんとなく印象に残すため。そう考えたほうがいいです。ああこの本は○○年に発売されたんだな、ということを軽く記憶に留めるために自分で入力する。だから検索して見つかるようなことでも改めて入力する。 そうすると、自分はブクログ経由で登録しているので、ほとんどその情報に触れていないことになります。あまりよくないのかもしれません。 その辺はおいおい検討しましょう。 ＊　＊　＊ とりあえず、書誌情報を入力するとする。 書名、著者名、出版年月日あたりは必要で、あと山本貴光さんがその本を買った場所も入力されているということで、これは拝借したいアイデアです。 で、自分が買った日時、読みはじめた日時、読み終えた日時なんかもメタ情報として付与できますし、これらはググっても出てこない情報でしょう。入力する価値はあります。 で、問題は読書メモ・ノートと、読書メモタスクリストの存在。 それらのデータベースには書名をタイトルにしたノートが生まれるわけで、読書メモなどはそこに書き込むことができます。それでいいのか、それとも別に読書ノートを作り、リンクで接続する形にするのか。 次に、そのデータベースに「読書メモ済み」のようなチェックボックスを作れば、読書メモを作ろうとしている本のタスクリストができるわけですが、それは好ましいのかどうか。 一元管理すれば管理の手間は省けますが、いろいろ詰め込み過ぎることになりかねません。 その辺をどうするか。 ＊　＊　＊ たとえば、読書ノートを蔵書リスト内に閉じ込めてしまうと、複数の本を読んで考えた事などは、別の場所にいくことになります。一方で、読書ノートという別のデータベースを作り、そこに関連する本の形でリンクさせるなら複数の本であっても問題なく扱えます。 そのどちらを主軸にするのか。 ＊　＊　＊ 昨日『学力喪失』という本を読み終えました。この本は読書メモをつくろうと思っていますが、まだ作っていません。このときに、「自分はこの本の読書メモを作ろうと思っていた」ということをリマインドできるようにしたい。 「読書メモスタンバイリスト」というリストを作って、そこに加えるのも手ですが、読書ノートデータベースや蔵書データベースでも対応できるのではないか。あるいは対応した方がいいのではないか。そういう思いがあります。 ＊　＊　＊ 一度入力してみましたが、メタ情報が多くなると列が横に長くなって、閲覧性が下がりますね。その辺はやや問題かもしれません。 ＊　＊　＊ Notionのlinkedデータベースを使ってみましょう。 蔵書リストには、この本の基本的な情報を入力し、それとは別に読書メモ用のデータベースを作って、それをリンクさせる形です。 こうすれば読書ノートの方にはAuthorのような項目は不要になります。ただ、この場合、こちらのノートから向こうのノートへのバックリンクは見えないのでしょうかね。 ＊　＊　＊ リレーションを双方向で同期にすれば問題解決です。 この話はまたニュースレターでも書きましょう。 あとで読む:Dnynalistでタスク管理｜武久真士 あとで読む:仕事に必要なたった一つのツールとルール｜Tokimaru Tanaka

原稿を進める水曜日

作業記録の共有 メルマガ+原稿3 note+アナログノート話 TH+第一章の検討 書斎術+第三章の検討 Gmailのフッター変更 一日一英文 環読プロジェクト ブックカタリスト+102の準備 ブックカタリスト+イベントの準備 じっくり読書+クリエイティブ・プログラマー KW+ミニエッセイ 7:00 おはようございます。本日は書籍の原稿を進めましょう。もうちょっと、ペースや進め方を再検討したほうがいいかもしれません。 Gmailのフッター変更: 昨日たくさんメールを送ったときに気がついたのですが、Gmailのフッターの記述がhttpになっていて、ぜんぜん変更していませんでした。 変えておきましょう。 ＊　＊　＊ Gmailの署名を変更する - 倉下忠憲の発想工房 メルマガ: まずはメルマガの原稿からはじめましょう。これも、書籍の原稿から着手した方がいいのかもしれませんが、とりあえず。 ＊　＊　＊ 3000字の原稿を書きました。 9:00 KW: 一つ投稿を書きましょう。一応サポーター向けページとして書きます。 ＊　＊　＊ 一つページを追加しました。これは現状は表玄関にはリンクを置かないことにします。 一日一英文: The surgeon persuaded him to undergo an organ transplant. 環読プロジェクト: 第二章の続きを読みます。 ＊　＊　＊ 一気に二項読み終えて、第二章は終わりました。章ごとのバランスがあまりよくないですね。 12:00 ブックカタリスト: セミナーの準備を進めましょう。 ＊　＊　＊ 20241117「ブックカタリストの語り方」イベント用メモ - 倉下忠憲の発想工房 粗書きができました。あとは、情報の補強や画像の添付あたりをちょこちょこ行えばよいでしょう。 13:00 note: アナログノートについて何か書きましょう。 ＊　＊　＊

もろもろを進める火曜日

作業記録の共有 『ライフハックの道具箱2024』+原稿依頼の本文をつくる R-style+ 『ライフハックの道具箱2024』の原稿募集 メルマガ+原稿2(2000文字) TH+第一章の検討 書斎術+内容の検討 じっくり読書+クリエイティブ・プログラマー 一日一英文 環読プロジェクト+第二章 ブックカタリスト+102の準備 ブックカタリスト+イベントの準備 KW+ミニエッセイ 9:00 おはようございます。本日はいろいろな作業を進めましょう。各種プロジェクトを進めていきます。 あとで読む:積読を消化する技術 - sasasin’s blog 『ライフハックの道具箱2024』: まずは、原稿を依頼する文をつくりましょう。前回のコピペでいいと思います。 問題はTwitterのDMとメールを使うのか、それともメール一本でいくのか。まあ、メールの方がいいかもしれませんね。 ＊　＊　＊ とりあえず、メールの本文を考えて、去年の寄稿者の方にメールをしておきました。それと共に、メールを送ったよ、というDMも送っておきました。やや手間ですが、移行期なので仕方がありません。 さまざまな連絡手段がありますが、基本はメールでいいと思います。あるいはそういうdiscordのグループを作るか。でも、きっと同じ問題が起こるでしょうね。 まあ、しばらくはメールの運用でいきましょう。連絡手段としてのSNSは、短期的にはよくても、長期的には限界があるかと思います。DMがきたら、メールでリマインドというのを設定してあれば話は別ですが。 10:00 R-style: 記事募集の記事を書きましょう。 [[/Drafts/『ライフハックの道具箱2024』の原稿募集]] ＊　＊　＊ 書けました。 publish:『ライフハックの道具箱2024』の原稿募集 | R-style 11:00 一日一英文: He caught a nasty cold because he stayed up late last night. 環読プロジェクト: 本日から第二章に入ります。 「Chapter02 メモはとればとるほど、財産になる」を読む - Knowledge Walkers

準備を進める月曜日

作業記録の共有 WorkFlowy+アーカイブ処理 メルマガ+原稿1(1700文字) ニュースレター+Textboxの移動の紹介 TH+第一章の見通しを考える ブックカタリスト+102準備 ブックカタリスト+イベント準備 メルマガ+ツイート メルマガ+ファイル準備 Honkure+警告してやる声が要る 読書メモ作り じっくり読書 環読プロジェクト 環読プロジェクト+第一章のまとめ記事 一日一英文 KW+ミニエッセイ 『ライフハックの道具箱2024』+リストを作る 7:00 おはようございます。本日はもろもろの準備です。 Workflowy: 通常の項目でcompiledになっている項目を、Archiveにまとめて移動させます。 ＊　＊　＊ こういう感じ。 移動する項目をまずArchiveにmove toしていき、すべて終わったら日付の項目を作って、そこにまとめて放り込む、という流れです。 8:00 メルマガ: publish:CT連載02：タスクリストって何？ / 発想とアイデアとそのプロセス/ ツールと欠けたベル理論/ 本棚の新構築その１｜倉下忠憲 まずは、ファイルの準備を。 ＊　＊　＊ 続いて、今週書くこともざっと決めておきました。 9:00 ニュースレター: 書きたくなったので、記事を書きます。 publish:循環式のホーム移動 - by 倉下忠憲@rashita2 - Rashita’s Newsletter 10:00 メルマガ: 一つ目の原稿を書いてしまいましょう。 ＊　＊　＊ OKです。1700文字の原稿を書きました。この話の流れでよいのなか、という思いもありますが、とりあえずは書きましょう。 12:00 あとで読む:わが大学の先生と語る 「『他者』として沖縄の声を聴く」岸 政彦（京都大学教授） ｜読書のいずみ ｜全国大学生活協同組合連合会(全国大学生協連)

ゆっくりすごす日曜日

作業記録の共有 来週のSTL確認 今週の週報作成 「やること」の整理 8:00 おはようございます。本日は来週の予定などを確認し、なんとか「やること」を整理したいと思います。 Textbox: 「通知欄」について考えています。 今、iPhoneで撮影した画像をTextboxのフォルダに保存できるようになったわけですが、画像が保存されただけで、何も更新されていません。 イメージとしては、新しく画像が入ったことを自分に知らせて、そこで日記などを作成しその画像を添付する、というやり方をやってみたい。 では、その「自分に知らせる」をどうするか。ということを考えています。 iPhoneからTextboxのJSONを直接更新すれば、少なくともこの通知はいらないわけですが、iPhoneでながながとテキストを打つのも面倒なので、Macでやりたい気分はあります。 あと、こうした画像の追加だけでなく、通知機能があればリマイダー的なものになるのではないか、という思いもあります。 で、仮にそういう通知欄を作るとしたらどうするか。 ＊　＊　＊ 一応、Textboxにはowlコマンドというのがあり、プログラムからの通知をテキストとして表示する機能はあります。 owlcall - 倉下忠憲の発想工房 しかしこれは何も操作しなくても自動的に消えてしまいます。やりたいのはそういうことではなく、更新されたものがありますよと、表示し続けるものです。 で、その後どうするか？ チェックボックスのようなものが表示されていて、それをチェックして完了にできるようにするのか。それとも、必要なページにジャンプするリンクを表示したり、画像ファイルをFinderで表示させたり。 ＊　＊　＊ とりあえず、Homeに当たる場所に、「れんらく帳」という欄を増やしました。うまい英語が思い浮かばなかったので、暫定のネーミングです。普通にUpdateでいいかな。 いや、Updateでもないか。というか、そこの情報が残っていくのか、消すのかで名前が変わりますね。「2024年11月03日 画像追加」のようなタイムスタンプで通知情報が残っていくならば、Updateでいいと思います。 そうではなく「こういう変更があったよ。行動とってね」という通知なら、通知欄(notification)が適切でしょう。あるいは、今日の日付を見て、とるべき行動を通知する場合もそうでしょう。 そもそも、「通知」という概念で異なるものをまとめようとしすぎている？ とりあえず、notification でいくことにしました。 ＊　＊　＊ このページを表示したら「通知確認」の関数を走らせる。 その関数は、何かしらのmdファイルか、jsonを確認して、通知すべき情報があれば、ここに表示する。 通知すべき情報は、日付データに入っている「予定」、曜日ごとのデータに入って要る「曜日別やること」の他に、Textboxに外部的に追加された画像やメモについて、あたりだろうか。 ＊　＊　＊ 「Notice」に変更しました。 ＊　＊　＊ 上記画面の下の方にはページリストが表示されています。たしか、「新規作成したページ」の情報がリストで保存されていて、それがそのまま表示されているという記憶です。 で、これを編集したページのリストとして表示させたら、「プロジェクトノート」の管理手法としてはなかなかよいのではないかと思いました。 ページの粒度も、その辺で考えやすくなるのでは？ 問題があるとすれば、ページの編集画面を開いて、閉じただけでも順番が変わってしまうことくらいか。ページのメンテナンスをしているだけで、その順列が代わっていく。 ＊　＊　＊ 現状使っている、page.jsonと、タスクなどの情報を含んだdeepfilelist.jsonがあって、ほとんど同じ情報が含まれている。これを統合する必要がある。 みたところ、page.jsonはページを新規作成したときだけにタッチされ、ページが変更されたときには触られていない。新規作成のページリストとして使えるかもしれないが、「created」のデータがdeepfilelist.jsonにもあるので、それでソートすればいいだけだ。 とりあえず、deepfilelist.jsonを読み込んで表示するようにしてみよう。 const url = "json/page.json"; fetch(url,{ method: "get", cache: "no-store" }) .