一言サマリー

同じ章を50回も書き直してしまうのを、どうすれば止められるだろうか？

ハイライト

• なぜ本の執筆が思ったより進んでいないのか？
• Asciidoctorの執筆・プレビューのワークフローを最適化した。
• Hacker Newsのパフォーマンスをリアルタイムで追跡するサイドプロジェクトに取り組んでいる。

目標の成績表

毎月月初に、その月に達成したいことを宣言している。目標に対してどれだけできたか振り返ってみる。

Kickstarterから得た教訓についてのブログ記事を書く

• 結果: My $6k Advance as a Self-Published Technical Authorを公開した
• 評価: A

当初はKickstarterに焦点を当てたガイドを書くつもりだったが、書けば書くほど、Kickstarter自体はそれほど面白い部分ではないと感じるようになった。本当に書きたいのは、セルフ出版の著者にとってのクラウドファンディングという道であり、Kickstarterはその一手段に過ぎないのだと気づいた。

本の新しい章を完成させる、あるいは本のトピックについてライブセッションを行う

• 結果: ライブセッションを実施し、新しい章の執筆に着手した
• 評価: A

本を予約購入してくれた人全員をライブ授業に招待した。何年も前からブログを読んでくれていたのに、これまで直接話したりメールしたりしたことがなかった人たちに会えて楽しかったし、寄せられた質問は本の内容を磨くのに役立った。

Kickstarter支援者へのリターン対応

• 結果: プレミアムリターンを購入したすべてのKickstarter支援者に連絡した
• 評価: A

連絡が遅れていることにストレスを感じていた。「Kickstarterについて新しいブログ記事を書いている暇があるなら、実際に支援してくれた人に連絡すべきでは？」と支援者に思われるのではないかと心配だった。ただ、一括メッセージは送りたくなかった。75〜150ドルのパッケージを支援してくれたのだから、一人ひとりに合わせた返信をするのが当然だと感じたからだ。

ずっとメールを先延ばしにしていたが、いざ取り掛かってみると、全員に書き終えるのに2時間ほどしかかからなかった。相手にウェブサイトがあったり、以前やり取りしたことがある場合は、一斉送信ではないことが伝わるようにメッセージをパーソナライズした。

本を書きながらの時間管理

毎週本の執筆を進めているが、進み方は遅く感じている。

進捗を測るのが難しい。どの章が終わっていてどの章がまだかは分かっているが、章ごとに難易度や長さが大きく違うからだ。

もう一つの問題は、同じ章を永遠に書き直し続けられることだ。どこかで「これで十分」と決めて次の章に進まなければならない。特定の章をいつまでに仕上げるというプレッシャーがないと、際限なく書き直してしまいそうになる。

書き始めて1時間ほど経つと効率がガクッと落ちることにも気づいた。単純に力尽きて気が散りやすくなったり、どうでもいいことにこだわりすぎたりする。午前と午後で別のトピックを書くことで多少は緩和できるが、どちらのセッションでも1時間ほどで力尽きてしまう。

幸い、スランプやモチベーションの低下は経験していない。平日は毎日書けているし、本へのワクワク感も失われていない。

そうしたことを踏まえて、今後より集中して執筆するための計画はこうだ。

• 1日少なくとも60分はフロー状態で書く時間を確保する。
  • さらに調べる必要がある、フォーマットを直す、画像を追加するといった作業が必要になっても、フロー状態を中断しないようにTODOを残しておく。
  • 退屈しても、メールやSNSをチェックしたい衝動をこらえる。出来が気に入らなくても、区切りの時間まではとにかく書き続ける。
    • 当初はLeechBlockNGが役に立ったが、Firefoxが頻繁にハングするようになったので使うのをやめた。おそらく既知の問題である“LeechBlock doesn’t get along well with Firefox’s GC.”が原因だと思う。2つほど小さな修正をプルリクエストとして送ってみたが、改善は見られなかった。
• 朝一番でその日の計画を立て、どの執筆タスクにどれだけ時間を割り当てるかを決める。
  • カレンダーとToDoリストを確認し、紙に30分単位で1日のスケジュールを書き出す。
• 各章にどれだけ執筆時間をかけるかを決める。
  • たとえば、メールの章は読者に草稿を送るまでに10時間だけかける、といった具合にあらかじめ決めておく。

リストの中には、すでにやっていて今後より徹底したいものもあれば、本を初めて書くという課題に向けて新たに加えたものもある。

Asciidoctor：今のところ順調

先月、本を書くためのマークアップ言語の候補を比較検討したことについて書いたが、結局Asciidoctorに落ち着いた。今のところ気に入っている。

Liran Tal氏のasciidoc-book-starterを出発点にして、Nix向けにアレンジした。今はNix flakeを用意してあり、nix runを実行すればPDF、epub3、HTMLの3形式で本をビルドできる。nix run .#pdfのようなコマンドで個別の形式だけをビルドすることも可能だ。

3つの形式すべてをサポートするかはまだわからない。カスタムのフォーマットも試していないし、画像や表の埋め込みもまだなので、3形式すべてでレイアウトやスタイルを整えるのにどれだけ手間がかかるか次第だ。

Asciidoctorの最大の欠点は、ライブリロードができないことだ。Hugoでの執筆に慣れているので、普段はVS Codeを片方のウィンドウで、レンダリング結果をブラウザの別ウィンドウで開いている。VS Codeで保存するたびに、数百ミリ秒でブラウザ側に反映される。

Asciidoctorでは、執筆→ビルド→確認の流れはこうなる。

1. ファイルを保存する。
2. ターミナルに切り替える。
3. nix run .#pdfを実行する。
4. ブラウザのウィンドウに切り替える。
5. PDFを再読み込みする。

こうして書き出してみると、自動化すべきだと気づいたので、LLMに聞いてこんなシンプルなスクリプトを手に入れた。

#!/usr/bin/env bash
set -euo pipefail

nix run .#pdf

zathura dist/Refactoring\ English.pdf &
ZATHURA_PID=$!

trap 'kill $ZATHURA_PID' EXIT

find book -type f \
  | entr -dr nix run .#pdf

zathuraは聞いたことがなかったが、ファイルが変更されると自動で再読み込みしてくれるオープンソースのPDFリーダーだ。実際に動かすとこんな感じになる。

自作のホットリロードは、Hugoで慣れ親しんだほぼ瞬時のパフォーマンスに比べればかなり遅いが、手動でやるよりは5倍は楽になった。

サイドプロジェクト：Hacker News Observer

Hacker Newsでのちょっとした特技の一つに、ある投稿がなぜトップページから消えたのか大体わかるというものがある。といっても、HN RankingsというHacker Newsの過去データをグラフ化しているサイトを知っていれば、誰でもできることだ。いくつかのパターンを見分けられればいいだけなのだ。

HN Rankingsで主に見られるのは、投稿の順位が突然大きく上がったり下がったりする動きだ。ある投稿がじわじわと3位まで上がってきて、次の更新で突然45位に落ちていたら、モデレーターが手動でランクを下げた可能性が高い。

チャートからは、モデレーターが手動で投稿をブーストしたことも読み取れる。300位あたりで埋もれていた投稿が突然10位に入ってきたら、モデレーターがブーストしたということだ。おそらくセカンドチャンスプールによるもので、これは通常の投票ではトップページに届かなかったストーリーを、モデレーターやボランティアが手作業で選び出す仕組みだ。

HN Rankingsは素晴らしいが、順位と並んで得票数やコメント数も見たいと思い、自分で同じようなものを作った。まだ公開はしていないが、Hacker News APIを1分ごとにポーリングして、現在掲載されているすべてのストーリーのメタデータを追跡している。

Hacker Newsのトップページに載っている全ストーリーの得票数やコメント数を集計すると、どんなパターンが見えてくるのか前から気になっていた。

最も目を引くのは、毎日東部時間の正午ごろに投稿の平均経過時間が大きく下がることだ。古い投稿がトップページから外れて、新しい投稿に場所を譲るタイミングなのだろう。

「My $6k Advance as a Self-Published Author」のHNでの議論のように、自分の投稿についてより詳しいデータが見られるのも面白い。チャートを見ると、この投稿は一度もトップページに載らなかったのに、その後も得票し続けているのがわかる。どこにもHacker Newsの議論へのリンクを貼っていないので、なぜそうなったのか今でもよくわからない。

まだ追加したい機能はこんな感じだ。

• Hacker Newsがネタ不足の日なのか、トップページが混み合っている日なのかを自動で判定する。
• モデレーターがブーストまたは抑制したストーリーに自動でタグを付ける。
• 投票やコメントの出だしから、ストーリーのその後の推移を予測する。

久しぶりに「ビッグデータ」っぽいプロジェクトになった。普段のサイトは月に1MB程度しかデータを生成しないが、HN Observerは1日で30〜40MBも生成する。収集するデータ量や更新頻度によって、この量は増減できる。

HNのデータ保存は、Tursoを試す良い機会に思える。少し前から注目していたが、SQLiteの利点をほぼそのままに、マネージドなデータベースサービスとして提供されているようだ。

DRMフリーの映画を買う

最近、合法的に購入できるDRMフリーの映画やテレビ番組を誰も提供していないと友人に愚痴っていた。大手スタジオや配信プラットフォームがDRMを手放す気がないのはわかるが、小規模なスタジオやインディー映画作家なら、4KのDRMフリーmp4を10ドルで買えるチェックアウトページくらい簡単に作れそうなものだと思ったのだ。

あちこち探してみると、そういったものが一応存在することがわかった。Vimeo on DemandではDRMフリーの映画を提供している。多くはインディー作品や非英語作品だが、合法的に購入できるDRMフリー映画としては、これまで見た中で最大の品揃えだ。

Vimeo on Demandを試してみたが、体験はまあまあだった。とはいえ、DRMフリー映画を販売しているのはここだけなので、注意点を付けた上でおすすめする。

購入するタイトルがダウンロード提供しているかどうかは必ず確認してほしい。すべてのタイトルが対応しているわけではないからだ。ボタンに「Stream anytime」と表示されているものはDRMフリーではない。

この間違いをやらかして購入をキャンセルしたときの体験も、Vimeoをおすすめしづらく感じた理由だ。人間と話すためのわかりやすい窓口がまったく用意されていない。代わりにチャットボットと話すことになり、「セキュリティ上の理由」でビデオ・オン・デマンドの購入は返金できないと言われた（購入した作品を一度も視聴していないことが向こうにも見えているのに、だ）。唯一の選択肢は、映画の配信元に直接連絡して返金を求めることだったので、そうした。だが、1週間以内に返事がなければ、クレジットカード会社にチャージバックを申請するつもりだ。

Vimeoの利用規約には拘束的仲裁条項が含まれており、Vimeoが違法行為をしても、裁判所で訴えたり集団訴訟に参加したりすることができない。米国でこのような条項が合法とされているのは馬鹿げている。仲裁人は企業側を消費者よりも大幅に優遇するからだ。拘束的仲裁からはオプトアウトできるので、私はそうした。

まとめ

何ができたか？

• Refactoring Englishのライブセッションを実施した。
• プレミアムリターンを購入したすべてのKickstarter支援者に個別に連絡した。

学んだこと

• 本の各章に時間制限を設けて、永遠に作業し続けるのを防ぐべきだ。時間目標があれば、本全体の進捗もより正確に把握できる。
• Asciidoctorでも、自作のライブリロード環境は簡単に作れる。

来月の目標

• 本の2つの章を予約購入者に公開する。
• 本のすべての章に緩やかな執筆時間の上限を設定する。
• 本のプレビュー用の章をAsciidocに移行する。