の作業記録
PTを進める金曜日
- 作業記録の共有
- PT+chapter03-3
- PT+原稿送信
- メルマガ+原稿4
- ブックカタリスト+BC065の下書き
- LM+章立ての再検討
- substackのサブスクリプションを確認する
- ミニ本作り環境の整備
8:00
大雨のようですが、通常通り作業です。今日はPTの原稿を送信し、メルマガの本文も書きあげておきましょう。
あとLMの編集者さんからメールが返ってきていたので、それにも返信しておきます。LMの章構造の再構成もやりたいですが、前二つが優先ですね。
PT:
続きを書きましょう。どこまで書いたのか忘れたので、それを読み返すところから。
＊ ＊ ＊
とりあえず「現在地点」を思い出せました。
9:00
昨日、原稿を集中して書きすぎたのか、雨のせいなのか、ほとんど頭がまわりませんね。
KW:
MacOS Venturaを13.4にあげたので、ファイル名の問題が解決しているかチェックします。
原稿管理:
メルマガで20回くらい書いた連載を一つの電子書籍としてまとめるときに、どういうツールを使って、どういう手法で進めて行くのか、というのがまだ固まっていない。
Scrivenerが最適だとは思うけども、そこに置いておくと「重く」なってしまう。
かといってVS Codeのワークスペースを完全にコミットしていないプロジェクトまで作りはじめると膨れ上がる。が、prebookという完成までもっていく途中のプロジェクトを集めたワークスペースを作っても、結局開かなかった。ターゲットがシンボルと結びつかないからだろう。
WorkFlowyかEvernoteのような多目的な場所に入れておくか、VS Codeであれば、orgあるいはlogtextのように作業記録に関するワークスペースにまぜておいた方がいいと予想する。
WorkFlowyで10万字に相当する原稿を扱うのはちょっとオーバーワークさせ過ぎだろう。
となると、Evernoteか、あるいはそのためのツールを自分で作るか、だ。
一応Textboxでもやれなくはないが、何か違うかもしれない、という気持ちがある。
作業記録を書き、そうしたドキュメントのプロセッシングもできるツール。それが一つの目的地点という感じ。
＊ ＊ ＊
ためしにEvernoteに連載原稿の一つを入れてみましたが、まあダメですね。
見出しスタイルは付けられますがそれでアウトラインが表示されるわけでもなく、アウトライン操作ができるわけでもなく、下位項目が開閉できるわけでもありません。
圧倒的に向いていません。
ランチャー代わりにはなるか？ 何かしら別のアプリを開くための動線としては使えるかも。
＊ ＊ ＊
連載各回のmdファイルをEvernoteに添付してあって、これは便利に使えます。ファイルをダブルクリックすれば中身がVS Codeで開いてくれるのもGoodです。
＊ ＊ ＊
アウトライン操作を優先するならば、Bikeを起動するのがよいでしょうし、ドキュメント操作ならScrivenerやObsidianが候補にあがりそうです。
＊ ＊ ＊
Knowledge Walkersと同じワークスペースに割り振っておきましょうか。bookフォルダを作って、その中に保存しておく。
仮にそのやり方をするとして、フォルダの中身はどんな感じがよいでしょうか。
その１：それぞれの企画案ごとのフォルダを作る。並行して進むものが増えればフォルダも増えていく。
その２：bookというフォルダを一つだけ作り、そこにすべてのmdファイルを集める。企画が違ってもフォルダわけはせず、mdファイルのファイル名だけで識別する
その３：bookというフォルダを一つだけ作り、そこに一つの企画案のファイルしかいれない。一時一プロジェクトに限定し、それが終わったら中身をクリアにして、新しい企画案のファイルを入れるようにする。
さて。
あと、ファイルの作り方も、複数にわかれた原稿ファイルを統合して一つにするのか、それともはじめから一つのテキストファイルにまとめていくのか、という問題もありますね。まあ10万字ほどならわけた方がよさそうですが。
＊ ＊ ＊
とりあえず、Knowledge Walkersのワークスペースに「books」というフォルダを作るところからやってみましょう。
＊ ＊ ＊
すでにTextboxにmdファイルが保存されていて、gtというフォルダにまとまっていました。これをKnowledge Walkersにそのまま移動しましょう。たしかボタン一つでPDFを作れるようになっていたはず。
これは悪くないのですが、ドキュメントの順番などがうまく操作できなかったような気がします。
「makePDF」という関数が準備されていました。
makePDF()は、cgi-makepdf.cgiを叩き、そのpythonスクリプトは、pandocを動かしています。まあ想定通りです。それと同じことをVS Codeでも実現すればいいだけで、できればボタンをクリックするだけでPDFが作れる、というところまでやってみたい。拡張機能を作れればいけるはずですが、やっぱり最終目的地は自作ツールになりそうです。
でも、そのまえにどういう機能があればいいのかをVS Code上で実験しながら確かめましょう。
＊ ＊ ＊
そういえば、これまでPandocへのコマンドをmakeファイルでまとめていたのですが、「PDFを作る」まで実行して、その後主導でPDFファイルを開いていたのですが、それもコマンドでやればいいのでは、と思い立ちました。
作成→閲覧までを自動化するか、閲覧用のコマンドを作っておくかですね。
＊ ＊ ＊
結城タスクは、showというコマンドでPDFなどを閲覧するようです。
11:00
少しだけでも原稿を進めていきましょう。
PT:
原稿を進めます。
＊ ＊ ＊
なんとか2000字、2項目進みました。今週はこれでよいでしょう。
13:00
ブックカタリスト:
来週の火曜日の配信用の記事を書いておきます。
＊ ＊ ＊
書いておきました。
15:00
メルマガ:
原稿を書きます。
＊ ＊ ＊
800字ほど書きました。やや短いですが、今週はちょっとポンコツなのでこれくらいでよしとしておきましょう。
ニュースレター:
paidを設定しているニュースレターがきちんと機能しているのかチェックしてみます。
トンネルChannel:
今月のお題記事を書きます。
プロジェクト管理:
プロジェクトgtは、Knowledge Walkersのワークスペースに入れたのですが、前々からちょっと考えていたことがあって、現状プロジェクトごとに個別に作っているワークスペースを、「書籍執筆」というワークスペースに当どうしたらどうか、というもの。
Dropbox上のフォルダは現状と同じように一プロジェクト一フォルダという形にしておいて、それを書籍執筆用ワークスペースですべて読み込む、というもの。
これだといちいちワークスペースを切り替える手間が減ります。その代わり、開いているファイルが多くなって、メモリ消費的にハードになるかもしれません。
あと、ターミナルもいちいち移動が必要になりますね。
でも、現状ワークスペースを切り替えるとターミナルも再起動させるので効率がよいのかどうかちょっとわかりません。
「同種のものはまとめる」のマインドセットであれば、「書籍の執筆」はまとめてもよいはずですが、実際の運用はどうなるでしょうか。
＊ ＊ ＊
たとえば、mdファイルからpandox経由でPDFを作る、みたいなものはどのプロジェクトでも共通しているでしょうし、makeファイルを複数作らずに、一つでまとめられたらハッピーだとは思います。その場合は、個別のフォルダに奥のではなく、PDFを作るpythonスクリプトにパスを通しておくのがよいのでしょうか。この辺の最適解は、ターミナルを触る歴が浅いのでぱっと思いつきませんね。
16:00
LM:
章構成の再検討を進めます。
＊ ＊ ＊
構成を再検討して、追加で必要になりそうな文章を書き下ろしました。
文章はまだもう少し整理が必要でしょうが、大きな作業はこれでOKだと思います。
＊ ＊ ＊
文章も直しておきました。作業はWorkFlowyで行ったので、その修正をdraftファイルに戻す必要がありますが、それは明日でよいでしょう。