一言でまとめると

AI革命のさなかに本を書いている場合なのだろうか？

ハイライト

• AI革命を傍観していることに疑問を感じている。
• 本にさらに時間を注ぐ前に、本を買ってくれる人がいることを自分自身に証明すべきだ。
• ブログを読むのにRSSが最高の手段だと気づいたのは、地球上でおそらく自分が最後だろう。

目標の自己採点

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

2024年の年次レビュー記事を公開する

• 結果：My Seventh Year as a Bootstrapped Founderを公開した
• 評価：A

出来には満足している。すでに書いた大きな出来事がいくつもあって、一年が断片的に感じられたため、何を盛り込むか悩んだ。結果として、良い一年のまとめになったと思う。

一時はHacker Newsで1位になったのだが、突然63位まで落とされ、理由はよくわからない。

本の次の章をもう1章完成させる

• 結果：「Passive Voice Considered Harmful」と、それに付随するインタラクティブ演習を公開した。
• 評価：A

クイズは予定していなかったので、予想より少し多くできた。クイズ自体はすごい出来とは思わないが、テキストコンテンツにインタラクティブな要素を組み合わせる楽しい試みになった。

読者のフィードバックをもとにチュートリアルの章を改訂する

• 結果：新しいセクション「Use unambiguous example values」を追加した。
• 評価：A

読者の提案をもとに細かな文面の修正も行ったが、最大の改訂は新しいセクションの追加だった。例の中で使うダミーデータの選び方についてのガイダンスを求める声がいくつかあり、自分でも記事に加えるべきだと感じた。

AI革命の最中に本を書くのは愚かなことなのか？

AIがソフトウェア開発に革命を起こしているのは明らかだ。

今のAIモデルは優秀なジュニアエンジニアのレベルで動く。このペースで進化すれば、2年以内にほとんどのプログラミング作業でトップクラスの人間にすら勝るようになるだろう。

ソフトウェア業界の多くがAIを中心に再編されると見ている。自分の人生で一番近い例えは、デスクトップソフトからインターネットへの移行だ。

今は仕事も経営する会社もないので、最近のAIの進展を活かして何にでも取り組める完全な自由がある。

そして私はAIとは何の関係もない本を書いている……

単に新しくてキラキラしたものを追いかけたいわけではないが、かといってAI革命を傍観するのは、90年代後半にインターネットが来ているのを見ながら「CDにソフトを焼いて郵送で売ろうと思う」と言っているようなものだとも感じている。

本に集中すると決めた理由自体は今も有効だが、半年前に計画したときよりも機会費用は思っていたより大きくなっている。

この本に市場はあるのか？

もう一つの問題は、本を書くのは長期的なコミットメントなのに、読んでくれる人がいるという確信がまだ持てないことだ。

最初に公開した章は好評だったが、あれは楽しくて間口の広い章だ。「Passive voice considered harmful」のような章は「野菜を食べなさい」的なレッスンになるのではないかと恐れている。ためになるとは分かっても、読んでいて楽しいものではない。そしてHacker Newsやredditのような自分のいつもの主戦場では、受動態についての投稿が注目されることはないだろう。

問題は、私の本のほとんどの章がそうした「野菜を食べなさい」系の章だということだ。

「投稿を声に出して読む」といったヒントをブログの章の中で語るように再構成することもできるが、あらゆる種類の文章に当てはまることなので、ブログの章だけに含めるのは少ししっくりこない。

でも、考え方が間違っているのかもしれない。ウェブをブラウジングしている人が受動態についての記事をわざわざ読みたいとは思わないだろうが、効果的なライティングについての本を読むと決めた人なら、受動態の章も読んでくれるはずだ。

オンラインで無料公開するサンプルは本の中身と一字一句同じ章だと思い込んでいたが、そうする必要はない。ウェブ向けに内容をどうアレンジしてもいいのだ。だから、ウェブのサンプル章ではブログの章の一部として音読のヒントを語っても構わない。実際の本では、そのヒントがブログの章に属さない形で構成すればいい。

それでも、あと数か月を費やす前に、この本にお金を払ってくれる人がいるかを検証する必要がある。そこで、次は「Write blog posts that developers read」のような楽しくてとっつきやすい章に集中し、最初の3章をもとにKickstarterで予約販売を始めようと考えている。書き続ける価値があると判断するための、最低限の予約数の目標を決める必要がある。

今さらだけど：RSSは素晴らしい

RSSは25年前からあるのに、これまでRSSで記事を読むことにハマったことがなかった。

2011年にGoogle Readerを試したのだが、フィードに面白い記事が十分になく、そのうちチェックしなくなって忘れてしまった。

ここ数年で、RSSへの興味を高めるいくつかの変化があった：

• Twitterでフォローしていたテック系の人たちがみんなバラバラの場所に分散してしまった。
• ソーシャルメディアが、面白い技術的な投稿よりも目を引く投稿を増幅していることをより意識するようになった。
• OSをNixOSに切り替え、無料のオープンソースRSSリーダーを簡単にセルフホストできるようになった。
• ブログをメールで購読するのは好きではないと気づいた。受信箱がごちゃごちゃするし、読む気分でないときに読まなければいけないような気分になる。
• AIによる低品質なコンテンツがウェブを覆う中で、自分が好きな特定の人たちをフォローしたいと思うようになった。

そこでfusion RSSリーダーをインストールしたのだが、新しいブログ記事を読むのに今では一番気に入っている方法の一つになっている。ソーシャルメディアで気に入ったブログ記事を見つけたら、その人の他の記事をざっと見る。面白いことを書いている人であれば、すぐにフィードに追加する。

サイドプロジェクト

wordword：ブログ記事の中の語彙的錯覚を見つける

最近、Matt Mightのブログ記事で「lexical illusions（語彙的錯覚）」という考え方を知った。テキスト中で重複した単語に気づかない現象のことで、例えば次のようなものだ：

Many readers are not aware that the
the brain will automatically ignore
a second instance of the word “the”
when it starts a new line.

私もブログを書くときによくこのミスをするので、自動で検出してくれるツールが欲しくなった。

このツールはAIアシスタントのClineに大きく頼って作った。Clineがプロンプトとテストケースをもとにツールを実装する精度の高さには、感心すると同時に恐ろしさすら感じた。

そしてツールはよく動く。すでに公開済みの記事から7つの語彙的錯覚を見つけることができた。

# Find lexical illusions (and also some false positives like "Duck Duck Go").
$ wordword ./content/
./content/retrospectives/2019/11/index.md:114: the
./content/retrospectives/2022/05/index.md:175: Duck
./content/retrospectives/2022/05/index.md:175: Duck
./content/retrospectives/2022/05/index.md:175: Duck
./content/retrospectives/2022/05/index.md:175: Duck
./content/retrospectives/2022/05/index.md:177: Duck
./content/notes/nix-git-bash-shell/index.md:78: time
./content/notes/cypress-vs-playwright/index.md:278: makes
./content/posts/simple-vue-pre-rendered/index.md:36: for
./content/posts/bootstrapped-founder-year-6/index.md:132: case
./content/posts/ansible-role-clipbucket/index.md:83: a
./content/posts/bootstrapped-founder-year-1/index.md:177: NOW
./content/posts/bootstrapped-founder-year-1/index.md:177: NOW
./content/book-reports/chaos-monkeys/index.md:8: names
./content/book-reports/go-programming-blueprints/index.md:50: of
212 total files checked
15 total errors found

wordwordをブログのCIビルドとgit pre-commitフックに追加した。

そしてZigで書いたので、とにかく速い。ブログにある212個のMarkdownファイルをわずか28.7ミリ秒でチェックする：

$ hyperfine 'wordword ./'
Benchmark 1: wordword ./
  Time (mean ± σ):      28.7 ms ±   1.3 ms    [User: 11.7 ms, System: 16.5 ms]
  Range (min … max):    26.8 ms …  31.7 ms    90 runs

その他の小さなこと

Codebergのメンバーになった

より企業色が薄く、オープンソース寄りのGitホスティングサービスを探していた。

それまでGitLabを使っていたのだが、彼らは2週間ごとにすべてのユーザーを強制的にログアウトさせるという奇妙な決定を下した。

GitLabを使うたびにログアウトされている。そしてサインインしようとすると、パスワードマネージャーの自動入力を許可せず、メールでワンタイムコードを確認させられて作業の流れが途切れてしまう。

Codebergを試してみたら気に入った。GitLabよりシンプルで、GitLabはいつも自分には複雑すぎると感じていたのでちょうどいい。そして完全にオープンソースで、GoとHTMLテンプレートで実装されているのも、私の好きなウェブスタックだ。

Codebergへの支払い方法の一つとして、議決権を持つメンバーとして会社に参加できることを知ったので、そうすることにした。まだメンバー権限を使って何かをしたわけではないが、単なるユーザーではなく協同組合の一員になったような気分で楽しい。

Codebergの最大の欠点は、対応しているマネージドな継続的インテグレーションベンダーが見当たらないことだ：

• WoodpeckerCI：マネージドホスティングを提供するベンダーがない。
• Forgejo Actions：有料サポートのない実験的なプロジェクト。
• CircleCI：Forgejo/Giteaをサポートしていない。
• Garnix：Forgejo/Giteaをサポートしていない。
• Buildkite：Forgejo/Giteaをサポートしていない。
• Drone：Forgejo/Giteaをサポートしているが、マネージドホスティングはEnterprise向けのみのようだ。
• Harness：Droneの新しいもののようだが、Forgejo/Giteaをサポートしているかわからない。

Codebergは公式にWoodpecker CIのセルフホストを推奨しており、楽しそうだが非現実的にも聞こえたので、無料のOracle Cloud VMで一日かけてセットアップしてみた。今ではwordwordや他のいくつかのプロジェクトでCIをセルフホストしている。ただ、有料ベンダーほど安全に運用できる自信はないので、そこにシークレットを置くつもりはない。それが、本格的なCI/CDソリューションとして使う上での大きな制約になっている。

10 Gbpsルーターを導入した

初めて自分のISPが上下2 Gbpsの対称回線を提供し始めたので、その性能をフルに活かしたくなった。

それまで使っていたルーターはQotom Q355G4で、よく働いてくれていたが、ラックマウントできないうえにポートが1 Gbpsまでしか対応していなかった。

OPNsenseやProtectliのような信頼できるハードウェアベンダーから買いたかったのだが、OPNsenseの10 Gbps対応で最も安いラックマウント型ルーターは1,200ドルで、Protectliにはラックマウント対応の選択肢がなかった。

結局、Qotom C3758R 1U 10 Gbpsルーター（送料・税込み417ドル）を買い、そこにOPNsense businessをインストールした。

ルーターのRAMやディスク容量が足りなくなるのではないかといつも心配になるが、OPNsenseはほとんどリソースを必要としない。8 GBのRAMと128 GBのディスクを選んだ。スピードテストを実行しながらシステム負荷を確認したところ、RAM使用率は13%を超えず、CPUも最大で30%程度だったので、このハードウェアで十分すぎる。なお、ファイアウォールルールを大量に入れているわけでも、OPNsenseのIDS/IPS機能を使っているわけでもない。

完全にRackstuds派になった

初めて自宅用サーバーラックを組み立てた記事を公開した後、ケージナットではなくRackstudsを試してみるよう何人かの読者から勧められた。

Rackstudsはプラスチック製なので金属のケージナットより壊れやすそうで懐疑的だった。だがRackstudsは最大40ポンドまでの機器を支えられるというラボテスト結果を公開している。

Rackstudsはケージナットより明らかに扱いやすい。ケージナットは機器の取り付けが難しく、特に重いものでは大変だった。片手で機器を持ち上げて水平を保ちつつ、もう一方の手でネジを締めて固定しなければならない。

Rackstudsはこの問題を解決してくれる。先にスタッドを取り付けておき、あとは機器をそこに引っ掛けるだけでいいからだ。

戸惑ったのは、Rackstudsには赤と紫の2種類があることだ。その違いがややこしい。紫のスタッドの製品ページにはこう書かれている：

レール厚が2.7mm/0.106インチから3.2mm/0.125インチの場合に適合。2.2mm/0.086インチ以下の場合は、代わりに新しい赤バージョンを使用してください

は？

サーバーラックの「レール」と聞くと、サーバーに取り付けてスライドさせて収納するためのものを想像するが、どの寸法をとっても3mmよりずっと大きい。

最終的に、Rackstudsが言う「レールの厚さ」とは、ラック前面の金属部分のことを指しているとわかった：

私のStarTech製ラックでは、紫のRackstudsの方がしっくりきた。

もう一つの落とし穴として、Rackstuds Duoを買うと、ちょうど1Uの機器にしか使えない。一方、バラ売りのRackstudsなら何でもラックマウントできる。まずは8個入りのサンプルパックを買い、その後、将来のラック機器用に20個入りを買い足した。

まとめ

何ができたか？

• Refactoring Englishの「Passive Voice Considered Harmful」の章と、それに付随するインタラクティブ演習を公開した。
• My Seventh Year as a Bootstrapped Founderを公開した。
• 短いノート記事を5本公開した：
  • The Cline AI Assistant is Mesmerizing
  • Increase Your Reply Rate on Cold Emails to Me
  • Install NixOS on a Free Oracle Cloud VM
  • How to Resolve Local Hostnames in OPNSense
  • Overcoming Gotchas in Samsung Secure Erase
• Zigで新しいブログ用のエラーチェックツールを自作した。

学んだこと

• 本の企画が、かかる時間やAIの変化をより活かせる代替プロジェクトを考えると、果たして正しい戦略なのか再評価する必要がある。
• 本の内容をウェブ向けにアレンジして読者を引きつけることができる。抜粋が本の中身と100%一致している必要はない。

来月の目標

• Refactoring Englishのブログに関する章を完成させる。
• Refactoring Englishの予約販売を開始する。

手助けのお願い

• 電子書籍の出版にもっと特化したKickstarterの代替サービスについておすすめがあれば、教えてほしい。
  • LeanPubは知っているが、Kickstarterのような「最低ラインに届かなければ成立しない」仕組みを探している。
• PDFとHTMLの両方にレンダリングできるマークアップ言語で本を書くためのツールについて意見があれば、連絡するか下にコメントを残してほしい。
  • 検討している選択肢は：
    • AsciiDoc
    • mdBook
    • Pollen - 発想は好きなのだが、使うにはPollenを、つまりRacketを、つまりLispを学ばなければならず、負担が大きい。