の作業記録
メルマガを仕上げてゆっくりする日曜日
- メルマガ読み返し
- メルマガ配信予約
What’s this?
9:00
おはようございます。本日は午前中にメルマガを仕上げ、午後からは書店に出かけるか、あるいは家にこもって読書をしたいところです。
あと、zennを少し試すかもしれません。
MEMO:プログラミングとライティング MEMO:デジタルでいかに考えるのか
作業記録のアイデア
hey juizコマンドから、たとえば何かしらのWebページを開く、という手はある。
あとで読む
nonoc「mement」
nonocのアニメ『Re:ゼロから始める異世界生活』の2期ED「mement」という曲がむちゃくちゃMYTH & ROIDの曲調に似ているなと思ったら、作曲がTom-H@ckさん(MYTH & ROIDの作曲の人)だった。
曲を買いました
『Broken Sky』(富田美憂)
10:00
メルマガ読み返しを進めます
* * *
終わりました。配信予約作業を進めます。
* * *
終わりました。
メルマガのmakeコマンドの編集
現状以下のようにimportにテキストファイルを指定しているけども、すべてテキストフィルであることが前提なので、拡張子の入力を省きたい。
| |
二行目を書き足した。
the answer
17:00
書誌情報の管理について
現状は、ブクログに登録→フィードをITFFFでキャッチ→Evernoteにノートを作成、という手順になっている。
→Dropboxという流れにすることは可能。
いったん整理する。
まず、このまま路線。
ブクログに登録と、そこから生成されるEvernoteのノートだけに管理を留めておく。ただし、現状のEvernoteのレスポンスの悪さからいって、だんだん使わなくなる可能性は高い。
個人的には、一年を振り返ってどんな本を買ったのか、読んだのかを一覧できると嬉しい。あと、未読の本を一覧して、そういえばこの本を読んでいなかった、をやってみたい。
ブクログでの管理をベースに、Scrapboxでも管理する手はある。が、現状Scrapboxは自動でうんぬんは極めて難しいので、手動での登録となる。
一番ややこしいパターンは、AmazonのAPIを叩いて、完璧な書誌情報のテキストファイルを作ること。
たとえば、買った本をこの作業記録に書き込むと、その情報を拾って、書誌情報ファイルと購入本リストが更新される、とかだったらすごくハッピーな気がする。
データベースにアクセスする感じ。
SQL(Structured Query Language)「構造化問い合わせ言語」
ここに書き込むのではなく、ターミナルに書き込むのでもいい。
あるいは、ここで書き込むこととターミナル書き込むことが同義でもいい。それなら作業記録に書かない本でも登録できる。
登録。
Registration.
詳しい書誌情報についてはいったん置くとして、単純に買った本を記録していく、という行為で考えてみる。
でもってそれは、たとえば「洗車した日」や「その日買ったもの」の記録にも敷延できるはず。そういう拡張的なものでないと、今後の拡大は難しくなるだろう。
複数の種類のデータがある。それをどう管理するか。
データによって処理は異なるだろう。その異なり方はどう異なるか。
移動するファイルだけが変わるのか、移動の仕方も変わるのか。おそらく後者だろう。
本のタイトルのテキストファイルを作ることの意義はどのくらいあるだろうか。それは、もうScrapboxに一任して、買った本の一覧だけを更新すればいいだろうか。
こづかい帳ならば、何を買ったのか、という品目について一つ一つページを作ることはしなくていい。ただ一覧と金額の合計、できれば費目ごとの合算がわかればいい。
読書メモはどうするか。
そのままこの作業記録に書名と共に書けばいいのではないか。grepで抽出可能である。わざわざ別ページを作ることの意義はどこにあるか。
Obsidianならば、情報同士の関連を閲覧できるから、独立したページを作ることには意義があるだろう。しかし、それ以外はどうか。わざわざ一冊一枚のテキストファイルを作る意義がそれほどあるだろうか。
そこまで強くは見出せない。少なくとも、軽くググればいくらでも書誌情報が見つかる現代において、そんなに重要なのかは不明だ。もちろん、存在して不便になるということはないのだが。
あとで検索して抽出できるように、いくつかの記法を埋め込んでおくだけで十分ではないか。
- 本の情報一覧
- 今年買った本の一覧
- n月に買った本の一覧
- 『hogehoge』に関するメモの一覧
- キーワードhogeに関するメモの一覧
ということが検索で抜き出せればそれでよいのではないか。
別ファイルを作ると、その本について何か書き込むときに、そのファイルをまず呼び出さないといけなくなる。
VS Codeならそれほど難しいことではないが、それは敷き居を高くしてしまうのではないか。
非データベース的データベース。
おこづかい帳的記録は、原本から共有に転記しない工夫が必要だが、それ以外は単に記法の問題だけではないのだろうか。
言い換えれば、検索で抽出することと、別ファイルにまとめておくことにはどのような違いがあるのだろうか。
おそらく違いは、抽出した後にもう一操作加えるかどうかが違いだろう。加える場合は別ファイルにまとめておく方が都合が良い。
ここで富豪的メモ環境を思い出す。howmでは、メモをすべて一枚一枚のファイルを作成し、grepで力技的に全文検索している。それが最近のコンピュータでは問題なく実行できる。
だとすれば、別ファイルを作ってもいいし、作らなくてもいい、という考え方はできる。
まったく使わない別ファイルが存在していても、別に気にしない、というスタンス。
たぶんそれもありだろう。
映画:『記憶にございません!』を観ます
なかなかハートフルな作品でした。
書誌情報の管理について
まずは、抽出可能な形でログを書いていく、という方針でいきましょう。
それで不都合が出てきたら、別ファイルを検討する、ということで。
20:00
家事周りを片づけます
21:00
たとえば、zennについて
たとえば、いまzennで展開する本のアイデアを考えようと思ったとする。すでに何かしらここに書きつけた、という感触はある。
キーワードで検索すれば、その結果が表示される。
- ライター向け軽プログラミング本
- VS Codeの本
- 知的生産ツールの紹介
という部分も拾ってこれる。しかし、今こうしてコピペしてきた。もし、zennアイデアというようなテキストファイルを作っていた場合、コピペは必要なく、ただそのファイルで操作すればいい。
しかし、そのテキストファイルを開くという操作は必要で、その点は検索を経由する必要はある。具体的には、command + p から探すことになるだろう。
はたして、どちらが良いのか。
WorkFlowyなら難しいことは考えずに、単にトップに項目を作ればいいだけだろう。それで情報の単位が出来て、すぐにアクセスでき、また検索も可能となる。そう考えると、やはり素晴らしいツールである。
一方で、いちいちコピペすることで、全体の再構築がそのたびごとに起こる(すでにある構造にとらわれないで考えを進められる)というメリットもあるかもしれない。
fragment:『道具論的欲望 〜言語・貨幣・VR〜』
「コンピュータは融通がきかない」と言われるが一番カスタマイズできるのがコンピュータだし、デジタルは0/1だと言われるが「aでもあり、bでもある」を作りやすいのがデジタルデータだったりする。
それは単にツールの使い勝手の話だけでなく、この世界:社会:制度:道具をどう捉えるかの認識につながってくると思う。
「道具論」は英語でなんと表現するか? toology?
fragment:負荷を減らせば良いというわけでもなく
負荷が行動を阻害する→行動を生むためにとことん負荷を減らす→負荷のない行動が大量に生まれる。
ということが求めていることかどうかを検討する必要がありますね。もし求めていることが慣れではなく負荷を必要とするならば、段階的に負荷を付与していかないと目指していない場所にたどり着きそう。
作業記録アイデア
朝一、hey juizで作業記録のファイルを作った後、たとえばスケジュールを記録しているWorkFlowyのページを開いたり、Googleカレンダーを開いたりするのもありだろう。
あるいは、そういうテキストファイルを作っておいてそれを開くか、あるいは、それらの情報をまとめて表示するダッシュボード(前に作った記憶あり)を表示させても良い。
setnumber
それは革命的な革命だった。 #何かの書き出し
本日の振り返り
本日も無事メルマガを配信でき、その後はゆっくり過ごしました。ほぼ一日書けて、作業記録をどう展開して行くかを考えていた格好です。
テキストファイル+プログラミングだと、かなり自由度が高いので、その分絞り込んでいくのが難しくなります。贅沢な悩みですね。
EvernoteやWorkFlowyは今後も使っていくのですが、それはそれとして、テキストファイルによる環境構築がどこまで可能なのかは、ちょっと実験的に模索したいところです。
あと、一通り差し迫っていた作業が終わったので、明日以降、どう作業を進めていくかをもう一度検討したほうが良さそうです。これまでとまったく同じ、というわけにも行かないでしょうから。
というわけで本日はそろそろ閉店ガラガラです。
お疲れさまでした。仕事終わりの妻を迎えに行ってきます。


