ひとことで言うと

同じ章を50回も書き直さないようにするには、どうすればいいのでしょうか？

ハイライト

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

目標の評価

毎月の初めに、その月に達成したいことを宣言しています。目標に対してどれだけできたか、以下にまとめます。

Kickstarterから学んだことについてブログ記事を書く

• 結果：個人出版する技術書著者として受け取った6,000ドルの前払い金を公開した
• 評価：A

当初はKickstarterに焦点を当てたガイドを書くつもりでした。しかし書けば書くほど、興味深いのはKickstarterそのものではないと感じるようになりました。個人出版の著者にとっての道筋として、私がよりわくわくしたのはクラウドファンディングです。Kickstarterはクラウドファンディングの一手段にすぎません。

本の新しい章を完成させる、または本のテーマについてライブセッションを行う

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

本を予約注文してくれた全員をライブ授業に招待しました。楽しいセッションでした。何年も私のブログを読んでくれていたものの、これまで話したこともメールしたこともなかった人たちに会えましたし、質問は本の内容を形作る助けにもなりました。

Kickstarter支援者へのリワード対応を進める

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

なかなか連絡できていないことにストレスを感じていました。支援者が、「実際に支援した人たちと話す代わりに、なぜあなたのKickstarterについて新しいブログ記事ばかり書いているんだ？」と思うのではないかと心配でした。ただ、75〜150ドルのパッケージを予約注文してくれた人には、個別の返信に値すると思ったので、一斉送信のメッセージは送りたくありませんでした。

メールをずっと先延ばしにしていましたが、ようやく送ってみると、全員に書くのにかかったのは2時間ほどでした。支援者にウェブサイトがあったり、以前に話したことがあったりする場合は、一人ずつ書いていることが伝わるよう、メッセージを個別化しました。

本を書きながら時間を管理する

毎週本を書いていますが、進みが遅く感じられます。

どの章を完成させ、どの章が未完成なのかは分かっていますが、章ごとに難易度も長さも大きく異なります。だから進捗を測るのは難しいです。

もう一つの問題は、同じ章をいつまでも書いては書き直せてしまうことです。どこかで十分に良くなったと判断し、ほかの章に移らなければなりません。特定の章をいつまでに終えなければならないというプレッシャーがなければ、永遠に書き直し続けられる気がします。

また、1時間ほど書くと効率が大きく落ちることにも気づきました。単純に息切れして、気が散りやすくなったり、重要でないことに時間をかけすぎたりします。午前と午後で別のテーマを書くことで多少は緩和できますが、どちらのセッションでも1時間ほどでやはり息切れします。

幸い、書けなくなったり意欲を失ったりはしていません。平日は毎日書けていますし、本への興奮もまだ続いています。

こうしたことを踏まえ、今後はより集中して書くために、次のようにするつもりです。

• 毎日少なくとも60分は、フロー状態で書く時間を確保する。
  • 追加の調査、書式の修正、画像の追加が必要なら、TODOを追加する。そうすればフロー状態を中断せずに済みます。
  • 飽きてきても、メールやソーシャルメディアを確認したい衝動を抑える。文章が気に入らなくても、その時間枠が終わるまで書き続ける。
    • 当初はLeechBlockNGが役立ちましたが、Firefoxが頻繁にハングするようになったので使うのをやめました。既知の問題である「LeechBlockはFirefoxのGCと相性が悪い」ことに関係しているのだと思います。小さな修正をいくつか提出しましたが、効果はなさそうでした。
• 朝いちばんに仕事日の計画を立て、どの執筆タスクにどれだけ時間を割り当てるかを決める。
  • カレンダーとTo Doリストを確認し、紙の上で1日を30分単位のブロックとして予定に入れます。
• 各章にどれだけの執筆時間をかけるべきか決める。
  • たとえば、メールに関する章は、読者に草稿を送るまでの執筆時間を10時間だけにすると、あらかじめ決めておくべきです。

リストの項目には、すでにやっていて、もっときちんと行いたいこともあります。初めて本を書くという課題に対応するため、新たに加えるものもあります。

Asciidoctor：ここまでは順調

先月は、本を書くためのさまざまな選択肢を評価したことについて書き、最終的にAsciidoctorを選びました。今のところ楽しめています。

Liran Talのasciidoc-book-starterを出発点にして、Nix向けに調整しました。今ではNix flakeを用意してあり、nix runを実行すれば、本がPDF、epub3、HTMLとしてレンダリングされます。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位になったなら、モデレーターがその記事を押し上げたということです。通常の投票ではフロントページに届かなかった記事をモデレーターやボランティアが選ぶシステム、second chance poolによるものかもしれません。

HN Rankingsは素晴らしいのですが、順位とともに賛成票数やコメント数といったデータも見たいと思い、自分版を作りました。まだ公開していませんが、Hacker News APIを毎分ポーリングし、現在のHacker Newsの全記事に関するメタデータを追跡しています。

Hacker Newsのフロントページにある全記事について、賛成票とコメントを時系列で集計するとどのようなパターンが現れるのか、以前から気になっていました。

最も目を引くのは、毎日米国東部時間の正午ごろに投稿の平均年齢が大きく下がることです。つまり、その時間に古い投稿がフロントページから落ち、新しい投稿のための場所が空くのでしょう。

自分の投稿について、より詳しい情報を見るのも面白いです。たとえば「個人出版する著者として受け取った6,000ドルの前払い金」についてのHN上の議論です。グラフを見ると、その投稿はフロントページに一度も載らなかったのに、賛成票を受け続けていました。意外です。Hacker News上の議論にはどこからもリンクしていなかったので、どうしてそうなったのかは今も分かりません。

まだ追加したい機能がいくつかあります。

• Hacker Newsでニュースの少ない日なのか、フロントページが混み合っているのかを自動判定する。
• モデレーターが押し上げた、または抑制した記事に自動でタグを付ける。
• 投票とコメントの始まり方に基づいて、記事の推移を予測する。

これは、長い間で最も「ビッグデータ」らしいプロジェクトです。私のサイトの大半は月あたり約1 MBのデータしか生成しない一方、HN Observerは1日あたり30〜40 MBを生成します。収集するデータ量と更新頻度に応じて、これは増減できます。

HNのデータ保存は、Tursoを試すよい機会に思えます。以前から遠巻きに見ていましたが、SQLiteを使う利点の大半を保てるDatabase as a Serviceのようです。

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向けに調整する。