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" }) .

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

作業記録の共有 メルマガ+原稿4 ツイート振り返り メルマガ+はじめに メルマガ+全体稿確認 メルマガ+配信予約 ブックカタリスト+102アフター下書き 一日一英文 環読プロジェクト+第一章 Kindle+11月セール 7:00 おはようございます。本日はメルマガを仕上げます。それ以外の原稿作業も進めたいところです。 メルマガ: 短い原稿を一つだけ書いておきます。 ＊　＊　＊ 1000字の原稿を書きました。これで本編はOKです。 ツイート振り返り: 一週間分のツイートを振り返りましょう。 ＊　＊　＊ ツイートの抜き出しは終わりました。 一つの印象として、そうやってテキストファイルに並べておけばよいものと、カード化して操作できるようにした方がよいものがありそうです。 8:00 メルマガ: 「はじめに」を書きましょう。 ＊　＊　＊ 「はじめに」と「おわりに」が書けました。 10:00 メルマガ: 全体稿を確認しましょう。 ＊　＊　＊ OKです。 あとで読む:クローズアップ②若い力で風を起こす！新書編集の仕事術 | 集英社 2026年度定期採用情報 11:00 メルマガ: 配信予約に移りましょう。 ＊　＊　＊ まぐまぐOKです。 ＊　＊　＊ noteOKです。 これで今週のメルマガ作業は一段落しました。 12:00 一日一英文: My physician advised me to refrain from alcohol for the time begin.

原稿を進める金曜日

作業記録の共有 メルマガ+原稿4 TH+「はじめに」修正 環読プロジェクト KW+ミニエッセイ 一日一英文 月替わり作業 ブックカタリスト+102アフター下書き じっくり読書+「学び」 レシート入力 小林さんにメールを返信する 8:00 おはようございます。今日は午後から妻の病院の付き添いです。それまでは原稿作業を進めましょう。 というか、月が代わっていますね。その作業をやらないと。 月替わり作業: まずは作業のリストアップから。 カレンダーをめくる 拠点ノートの更新 KW+サポーターページの更新 KW+一ヶ月のまとめページの送信 実行は後にしましょう。 TH: 乗り気でないのを押しきって、修正を進めましょう。 ＊　＊　＊ 編集者さんからいただいたコメントを反映させました。かなりすっきりしたと思います。 9:00 KW: サポーターページの更新を行います。 ＊　＊　＊ noteとfanboxはOK。 ＊　＊　＊ publish:先月の振り返り&2024年11月のサポーターページのご案内 - by 倉下忠憲@rashita2 ニュースレターもOKです。 メール返信: 昨日、打ち合わせの打診メールが来ていたのでした。さっそく返信しておきます。 11:00 拠点ノート更新: Obsidianの月拠点ノートを更新します。 ＊　＊　＊ 更新して、ついでにメンバー限定記事を書いておきました。 publish:2024年11月の拠点ノート更新風景 | メンバー限定記事 - by 倉下忠憲@rashita2 12:00 月替わり処理: 細かい事務作業を片づけていきましょう。

うちあわせCastな木曜日

作業記録の共有 Textbox+lifeJournal計画 メルマガ+原稿3(2100文字) うちあわせCast収録 一日一英文 環読プロジェクト 8:00 おはようございます。本日は午後からうちあわせCastです。それまでは原稿作業を進めましょう。 Textbox: iPhoneで撮影した食事の写真などをTextboxに取り込みたい、という欲求があります。Life Journalと、ひとまずは呼びます。 それは通常の思いつきメモとは別の、ライフログ的な記録です。日記もその系列に入れるのがいいのかもしれません。 ひとまずは、それようのフォルダに写真を保存していく、というのが第一ルートです。それならば特に難しくはありません。しかし、写真の名前やコメントをつけるとなると、一ひねりが必要です。 方法は二つ。HTMLないしはマークダウンでそれらを記述し、画像を image タグで指定するというやり方。もう一つはJSON形式で保存し、画像もそこにファイル名を置くというやり方。後者はJSONをfetchしてHTML要素を生成する、といういつものやつになります。 ＊　＊　＊ ヒントにしたいのは以下のサイト。 Using static websites for tiny archives – alexwlchan 自分で静的なサイトを作っているということで、Textboxと同じコンセプトです。 各年ごとにフォルダがあり、そこに画像ファイルがまとめられているのでしょう。で、トップの階層にindex.htmlとmetadata.jsが置かれています。おそらくmetadata.jsにファイルの説明などが入っているのではないかと予想します。 index.htmlでそのjsを呼び出して、ページを生成する。あるいは記述されたものに説明を加える、という感じでしょう。たとえば、HTMLにイメージタグがあって、そこにidがふってあって、そのidの説明がmetadataにある、みたいな形。 こちら側のシステムはいくらでも作り込めるので、考えたいのはiPhoneでの処理。写真を撮影して、それをTextboxに送る段取りをどうするのか。 ＊　＊　＊ 直接パターンと、間接パターンがあります。 直接パターンは、ショートカット.appなどを使い、画像を選択し、テキストを記述して、それをセットにして何らかのかたちでtextboxのフォルダに保存すること。ようするにiPhoneだけで完結するやり方。 間接パターンは、Textboxのimageフォルダに「inbox」というフォルダを設けて、そこに保存だけして、テキストを加えるなどの処置はパソコン上で行う、というもの。iPhoneは前処理だけに使い、Textboxへの編入はパソコンで作業するやり方です。 後者であればあっという間に作れます。ショートカット.appで３〜４ステップくらいで済むでしょう。 前者はかなりやっかいです。でもって、それとTextbox上の実装が関わってきます。 ＊　＊　＊ データをJSONで保存する場合を考えてみましょう。 当然のように、そのJSONにテキストと画像ファイルの名前を保存することが必要です。その上で、画像ファイルそのものを特定のフォルダに保存すること。Dropbox経由でそれを行うので結構時間はかかりそうです。最初に保存されているJSONを読み込んで、そこに追記して保存する、という往復が必要なので、iCloud Driveよりも体感はかなり遅く感じると予想できます。 単に画像を保存するだけならばあっという間です。 JSONを経由せずに、mdファイルに直接記述を追記する場合なら、少しだけ話は変わってきて、末尾ないしは冒頭に追記ができるので、その場合は少し速くなると思います。 さて、どうするか。 mdファイルに直接記述してしまうと、逆順でのソートや検索が少し難しくなります（一応不可能ではない）。 ＊　＊　＊ JSONの作成自体は後から行うことも不可能ではないので（やや面倒ですが）、とりあえず、iPhoneで撮影した画像をTextboxのフォルダに保存する仕組みだけを作っておきましょうか。 ＊　＊　＊ とりあえず、photo と screenshot という二つのフォルダを作りました。日記というようなカテゴリよりもこちらの方がよいかと思います。 さらにその中身を分けるかどうかは一旦保留にしておきましょう。photoなら「食べ物」「飲み物」という分け方もできますし、オブジェクト指向ノーティングならそういうやり方になりそうですが、とりあえずはこの二つ。 あとで読む:iOSのローカルを全文検索するSamurai Search - Jazzと読書の日々

原稿を進める水曜日

作業記録の共有 メルマガ+原稿2(4600文字) うちあわせCast確認→実施 デジタルノート研究会+2020年のEvernoteカレンダー 一日一英文 環読プロジェクト KW+ミニエッセイ 9:00 おはようございます。本日はもろもろ原稿作業です。 Evernote: ふと思いたって、Evernoteの拠点ノートを作ってみました。 わりと見た目はいい感じです。 10:00 デジタルノート研究会: 記事を書きましょう。 ＊　＊　＊ OKです。 publish:2020年のEvernoteのカレンダーを振り返る - by 倉下忠憲@rashita2 あとで読む:コースターボーイ＃00 ゆびダイス | 『ゲームマーケット』公式サイト | 国内最大規模のアナログゲーム・ テーブルゲーム・ボードゲーム イベント メルマガ: 二つ目の原稿を書きましょう。 13:00 一日一英文: Some of ingredients in this beverage are harmful, especially if you are pregnant. 環読プロジェクト: 第一章の続きを読みます。 ＊　＊　＊ OKです。 14:00 メルマガ: 原稿２を続けます。 ＊　＊　＊

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

作業記録の共有 Textbox+今日のランダム名言 メルマガ+原稿1(1500文字) TH+ ブックカタリスト+101収録 BCイベント準備+ファイルをつくる 一日一英文 ブックカタリスト+102準備 環読プロジェクト じっくり読書 KW+ミニエッセイ 住所変更プロジェクト Textbox+今日の名言をランダムにひっぱってくる 8:00 おはようございます。本日は午後からブックカタリストの収録です。それまでは原稿作業を進めましょう。 Textbox: ぜんぜん原稿に関係ない作業から。 homeにしているページに「Today’s word」という欄があるのですが、モックアップで常に同じ言葉が表示されています。これをランダムに替えたい。 どう変えるか？ どこかから引っ張ってくる、というのは決定で、それをどのタイミングで行うか。 ページが表示される毎にするのか、日付単位で変えるのか。 まあ、ページが表示される毎がいいですかね。 ＊　＊　＊ では、どこから引っ張ってくるのか。 ソースは二つ。一つは引用集.mdというページ。もう一つは、history.jsonの引用集というタグがついているもの。後者の方が、フォーマットが揃っている分使いやすくはあります。データベース的。 前者の場合、引用タグで囲まれているので、その部分を抜き出して、ということになるでしょうか。 ＊　＊　＊ 実身、仮身の考え方を拝借すれば、mdページの利用方法も別様が可能ですね。これまでの考え方であれば、mdページのテキストを取得し、それを分割して配列に入れ、ランダムにそれを一つ選び、テキスト処理を施してウィジェットに入れる、という形になります。 仮身の考え方を使えば、mdページそのものを表示して、ランダムな項目にスクロールする、というやり方がありそうです。 ふむ。 このやり方の場合、表示を切り替えるときに読み込みボタンを押すのではなく、適当にスクロールさせればいい、となりますね。 ＊　＊　＊ fetchして読み込んでもいいし、ページを表示させるオブジェクトを新しく作ってもいいです。 ページを開くオブジェクトは、以前途中まで作っていたので、その続きをすれば一応実装は可能です。でもその場合、ページを開くだけになります。ページ内部のCSSは別途考える必要がある。整合性がややこしい場合はありますね。 その意味で、ページのテキストをデータとして扱って、再処理したほうがそれぞれの「見せ方」がやりやすい側面はありそう。 ふむ。 ＊　＊　＊ すぐに実装できるJSONで考えてみましょうか。mdファイルの星。でも、テキスト処理のロジックを差し替えればすぐに転用できるでしょうし。 history.jsonをfetchして、引用集というaddressでフィルターして、あとはランダムという感じ。 ＊　＊　＊ できました。ほぼGeminiにコードを書いてもらいました。 history.jsonからランダムに一つピックアップされております。同じように英語の勉強ノートなどもここに表示させたらいいですね。 10:00 メルマガ: 一つ目の原稿を書きましょう。 ＊　＊　＊ 1500文字書きました。 13:00 ブックカタリスト: 11月17日のイベントの準備を進めましょう。まずはKeynoteのファイルだけ作っておきます。 ＊　＊　＊