の作業記録
シゴタノを書く金曜日
9:00
おはようございます。本日は雨ですね。
昨日は結構がんばりましたので、今日は比較的ゆっくりめで進めたいところです。
金曜日なのでシゴタノを書き、昨日いろいろとやったので状況整理をしておきたいです。
あと、明日粗大ごみの日なので、出すのを忘れないようにしないと。
モーニング・コーディング
原本ファイルの新規作成時、その日の概要だけでなく、しゃーぷ×2個を置いておくことにした。
で、そのファイルを開いたときに、カーソルを先頭にしておきたい。
| |
あと、昨日ファイルのネーミングを変えたときに、やはり二つのファイルを変更したので、共通の関数にしておいた方が良さそう。
Python で別ファイルに書いた関数を呼び出す方法 - Python の関数 - Python の基本 - Python 入門
別ファイルを作り、そこで関数を定義して、呼び出す方でそのファイルをインポートして、関数はファイル名（モジュール名）付きで使用する、という感じか。
とりあえず、小さく実装してみる。ファイルを作るところから。
さて、名前は何だろうか。この関数は何をするか。今日の日付から、使用するファイル名（パス）を作成する。
関数としては、呼び出すとファイル名が返ってくる、というところか。
getTodayFilePath.py
とでもしておこう。関数は
| |
とだけ書いておく。原本ファイルと共有ファイルはパスが違うので、配列で返して[0]と[1]で使い分けるか、原本ファイル用のパスを返す関数と、共有ファイル用のパスを関数を別に定義していもいい。
とりあえずは、ここまでにしておく。
あと、hey juizコマンドで、原本ファイルだけでなく、デイリータスクリストの初期状態(init)も作れるといいな。最近、これを書き始めてから、WorkFlowyでデイリータスクリストを作成するのが若干面倒になっている。一緒にできればヨロシイ。
ただし、WorkFlowyはAPIが無いので、Pythonでブラウザを操作するようなことをするか、いっそデイリータスクリストもテキストファイルに以降するか、だ。これは大きなプロジェクトになりそうな予感。
setnumber コーディングとライティングの名付け
コードのファイルないしは関数名をつけることと、文章のタイトルないし見出しをつけることの相似。
10:00
シゴタノ！を書きます
Obsidianではなく、『独学大全』についてです。
週一の確認
Obsidianは日常遣いしていないので、毎週一回シゴタノ！を更新するタイミングでアップデートを確認する、という流れになっている。まるで週次レビューのようだ。
setnumber
chaotic-lifeと防波堤としての秩序
11:00
setbumber
VR世界にこんまり流は必要か。
あとで読む
- 【2020年10月版】近所のコンビニ3社で売られていたサンドイッチを全部買ってパンをめくってみた | ロケットニュース24
- 哲学はなぜ世界の崩壊の快楽を探究してしまうのか（飯盛 元章） | 現代新書 | 講談社（1/5）
- 【第4回】総体としての喫茶アメリカン性｜Tak. (Word Piece)｜note
- 私的アウトライナーガイド - Word Piece
12:00
『Spherize』
ゆうびんやさんの最新回が更新されております。
Day8 本には「自分」が、日記には「他人」がいる｜ゆうびんや｜note
シゴタノ！を続けます
＊ ＊ ＊
書き終わりました。さすがに記事一つで紹介しきるのは無理なので、少しずつ読み込んでいくスタイルにしました。
日曜日に公開される予定です。
13:00
fragment:問題解決者の苦悩
問題解決を仕事にしている人にとって、その問題を解決してしまう技術は非常に困った存在になる。だから、必然的にポジショントーク（新しい技術に対して批判的な意見）が生まれる。
しかし、問題解決法を自ら考案した人ならば、新しい状況においても新しい問題解決を生み出せるだろう。一方、誰かの問題解決を受け売りしている人は、まったく新しい状況に対応できない。
そのつど、問題解決者の受け売りを更新していくか、自分が解決できる問題は「問題」なのだと言い続けることになる。 →ハンマーを持つものは
fragment:物語を書くかのように
鹿の声と地下の空間 - 結城浩のサブスタック への返信メールの中身
メール拝読しました。
これはあくまで想像ですけれど、そのような文章を書く方法の一つは、自分の中に題材を深く沈めて引き上げる。そんなふうにして書くことじゃないでしょうか。最初からわかりやすい筋書きを作ってから書くのではなくて、自分という存在全体を使って書く。そんな仮説を持っています。
このメール自体が不思議な面白さを持っていましたが、特に上の部分が心に残りました。基本的に結城先生の仮説に賛成です。
僕自身も、今「最初からわかりやすい筋書きを作って書く」という方法以外での書き方を模索しています。解説書を書くときは、どうしても（読者の理解の）通りの良い話を書きたい思いが強く、筋書き指向で書いてしまうのですが、最近そうした執筆に「狭い土俵で戦っている」感覚を覚え始めました。 そこで、いろいろな執筆法を試みているところです。とは言え「自分という存在全体を使って書く」というのは、言うは易いの代表例のようなもので、ちょっとしたコツで解決できるものではないさそうです（そりゃそうです）。
個人的には、あたかも物語を書くように何かしらの紹介や解説を書いていけたらいいなと感じています。そうすれば、自分の執筆の楽しみも増え、また面白い本ができるのではないか。それが僕なりの仮説です。
倉下
idea:substackに過去記事のリンクを入れる
タイムラインにブログの過去記事を流すのもいいけれども、ニュースレターにその内容に関係ありそうな記事のリンクを添えることで、循環や発掘を促す、というのは良い方法だと思った。
『独学大全』のレビューを読んで思ったことを書きました
この作業記録の見栄え
見出し３と見出し４の区別がつきにくいのが若干難点ですね。文字サイズだけでなく、フォントのカラーも変えてみようかしら。
同様に、fragmentなどもスタイルを変えた方がいいかもしれない。
14:00
review:手持ちのプロジェクトをいったん整理します
■NL: 編集者さんに叩き台となる目次案を送信。まだ細かい章立ての中身までは出来ていないが、大ざっぱな項目と概要だけ送信。現状は返信待ち。もう少し細かい詰めが必要となるか、大きな見直しが必要となるかは、返信次第。次のタスクもそれで変わってくる。
■SO: 編集者さんに原稿を共有済み。おそらくコメントをいただけるので、それを修正・反映する作業が次に待っている。現状はコメント待ち。
■タスク管理の取材:転記済み 昨日インタビューが終わり。同意書と請求書の項目の連絡待ち。あとできあがった原稿をチェックする作業も後々発生する。
■オーディオブック化:転記済み 先方の進捗待ち。実際の私の作業は、完成した音声ファイルの確認と、販促だけ。たぶん、契約書を交わすこともタスクに入ってくる。
■『Re:vision』:転記済み 読み返しの途中で中断中。今年中には終わらせたいし、なんなら『Spherize』のnote連載が終わる前に終わらせたい。あまり深く考えないで、まず通して読めるように仕上げることを目標とする。
■『僕らの生存戦略』:転記済み 第二章の途中で中断中。新しい執筆スタイルを試しているところだった。一日1000字ペースで、細かいことを考えずに書いていき（≒勢いよく書いていき）、後からそれらを直して、手を入れるのが良いのではないかと考えつつある。
■かーそる第四号:転記済み 原稿が出そろうのを待つタイミング。同時に、自分の原稿の微修正も進めていきたいところ。とりあえず、BCCKSに「本」を作っておいてもいいかもしれない。
■本のポッドキャスト:転記済み 来週ごりゅごさんと、うちあわせcastでうちあわせする予定。
■総合サイト作り:転記済み 来年の作成に向けてアイデアを温め中。方向性が見えてきたら、少しずついろいろな人に声を掛けていきたい。どんな項目があれば嬉しいのかも一緒に検討しておく。
編集後記:
だいたい今「気になっていること」はこれくらいですかね。枝葉にまで注目するとさらにいろいろ出てきそうですが、そこまでの精緻化は現状は必要ないでしょう。
でもって、たぶんこういうアクションがGTDにおけるレビューに相当するのだと思います。
たとえば、org-modeなら、上のように書き出して、それぞれのプロジェクト名を見出しにして、下位項目を閉じ、それぞれを自分の注意を向けたい順で再ソートしておけばいい。アウトライナーでも同じことができる。
16:00
プロジェクトノートはどうするか
先ほど書き出したプロジェクトの整理情報は、どのように利用されるのが良いか。
たとえば、プロジェクトごとに切り分けて保存しておき、juizに何か話しかけることで、上の記述がcatされる、というような形はどうか。
あるいは、朝一VS Codeで原本ファイルを開いているのと同じ要領で、切り分けたファイルを開いたり、あるいは、このファイルの上の部分を開いたりすることもできる。いろいろ考えられる。
プロジェクトごとにファイルを作ってもいいし、プロジェクトリスト的なフィアルを一つ作る手もある。
あるいはそんなものは作らずに、単に作業記録からgrepする手もある。いろいろありすぎて、なかなか一つに決め切れない。
そもそも保存しておく意味が、どれくらいあるのかは一度検討する必要があるだろう。
17:00
プロジェクトノート
たとえが、GitHubのリポジトリには、だいたいReadMe(.md)がある。
でもって、現状の自分は、一プロジェクトに一フォルダを与えている形で、リポジトリと同じ構成と言える。
だとしたら、readmeを作るのは有益ではないか。
リポジトリ（フォルダ）を作るほどでもない、短期の作業についてどうするのか、という問題はありつつも、全体的な方向性は良いように思う。
GitHubにも、リポジトリだけでなく、Gistがあるので、そういう使い分けがどうにかして可能かもしれない。どうするかは、今から考える。
手持ちのプロジェクトの一覧 ↓ それに準じたファイルへの保存
Dropboxの中のフォルダで、「プロジェクト」に相当するものには、接頭辞に「■」を付け加えておくことで、識別しやすくする手はどうか。
しかし、cdが若干面倒になるか。接頭辞ではなくて、接尾辞にする手もあるか。
あるいはフォルダを整理して、プロジェクトに相当するものだけを集めるフォルダを作る手もある。
フォルダをすべてwalkして、特殊な拡張子（しかし中身はテキストファイル）なものを抽出する手もある。新しいプロジェクトを作るときは、その特殊な拡張子のファイルを作ることになる。
＊ ＊ ＊
いったん整理します。
まず、テキストファイルベースで管理するまでは、原稿ファイルはDropbox/textというフォルダの中にプロジェクト単位でフォルダを作っていましたが、このtestをarchiveにします。
ただし、archiveにすると、ファイル名順のソートでトップ近くに来てしまうので、フォルダ名は「書庫」としました。本当は、他にどんな名前を付けても、絶対に最後に位置する漢字を使おうかとjisコードの検索をしてみたりもしましたが、そもそも他のフォルダで漢字を使わなければ、このフォルダが一番下に来るので、それで十分でしょう。覚えやすい名前が良いですし。
とりあえず、今のところ使っていないフォルダを削除or書庫に移動しました。
ここからです。
18:00
プロジェクト管理
各フォルダの中に、「TODO」ないし「ReadMe」を作る。
先ほどのプロジェクトレビューは、「TODO」だろうか。直接のタスクは記述されておらず、そこから抽出が必要だ。むしろ、この記述は、Tak.さんの「DO」が近いだろうか。
とりあえず、あまり深く考えず、todo.txtをいくつかのフォルダにつくって、そこに上で書いたレビューを転記しました。プロジェクトフォルダを作るまでもない、ショートプロジェクトは、dropbox直下にtodo.txtを作って、そこにまとめて記述することにします。
20:00
プロジェクト管理
こりずにプロジェクト管理について。
MEMO,TODO,ReadMe、そしてChangelog。
ReadMeを作るというよりも、Changelogを作るイメージが近いかもしれない。
いや、ReadMeは、そのプロジェクトにtouchしたときに作り、大幅な変更が起きたときなどに編集する、という感じだろうか。
日々の細かいことは、Changelog的なものの方がいいかもしれない。
より良いChangeLogを書くたの指針を示す「Keep a CHANGELOG」 - ソフトアンテナブログ
とりまZennアカウント取得
VS Codeとか、そういうものの使い方をページで解説しようかしら。
21:00
家事周りを片づけます
プロジェクト管理
最大の問題は、どういう形になればもっとも望ましいのか、自分でわかっていないところ。調整のしようがない。
作業記録に書き込んだら、それが自動的に処理されるのが望ましい、というのはベースだが、じゃあ、その情報をどう利用するのか、というビジョンが欠けている。
単に前回のレビューを振り返りたいだけなら、検索すればいいだけだし、あえて一手間かける理由はいまのところ見つからない。
いまいちまとまらないので、いったんこの案件は保留にしておきます。
本日の振り返り
本日は、シゴタノ！を書き、後はプロジェクトの整理アンド管理方法の見直しに明け暮れました。
たぶんプロジェクト管理の話は、デイリータスクリストをどう作るのかと深く関わってくるので、それ単体で考えてもあまり見えてこないのかもしれません。
この作業記録、デイリータスクリスト、プロジェクト情報。これらの情報生態系がうまく成立するように整えたいところです。
というわけで本日はそろそろ閉店ガラガラです。
仕事終わりの妻を迎えに行ってきます。