Refactoring English:2か月目
一行サマリー
AI革命のただなかで、本を書いている場合なのだろうか。
ハイライト
- AI革命を傍観していていいのか、迷いが出てきました。
- これ以上時間を投じる前に、本を買ってくれる人がいることを自分自身に証明すべきだと感じています。
- ブログを読むのにRSSが最高だと、地球上で最後の一人としてようやく気づいたかもしれません。
目標の自己評価
毎月のはじめに、その月に達成したいことを宣言しています。結果は次のとおりでした。
2024年の年次レビュー記事を公開する
- 結果:My Seventh Year as a Bootstrapped Founderを公開しました
- 評価:A
仕上がりには満足しています。すでに記事にした大きな出来事がいくつもあり、一年が断片的に感じられたため、何を盛り込むべきか悩みました。結果として、一年をうまくまとめられたと思います。
この記事は一時はHacker Newsで1位になりましたが、突然63位まで落とされ、理由はよくわかりません。
本の次の章を完成させる
- 結果:「Passive Voice Considered Harmful」と、付随するインタラクティブな演習を公開しました
- 評価:A
クイズを入れる予定はなかったので、想定以上に進めることができました。クイズ自体がすばらしい出来だとは思いませんが、テキストのコンテンツとインタラクティブな要素を組み合わせる楽しい試みになりました。
読者のフィードバックをもとにチュートリアルの章を改訂する
- 結果:新しいセクション「Use unambiguous example values」を追加しました
- 評価:A
読者からの提案をもとに細かな修正も行いましたが、最大の改訂は新しいセクションの追加でした。例で使うダミーデータについて指針がほしいという声が何件かあり、この記事に含めるべきだと私も思いました。
AI革命の最中に本を書くのは愚かなことなのか
AIがソフトウェア開発に革命を起こしていることは、私には明らかです。
AIモデルはすでに優秀なジュニアエンジニアのレベルで動作しています。このペースで進化すれば、2年以内にほとんどのプログラミングタスクで、AIは最も優秀な人間をも上回るでしょう。
ソフトウェア業界の多くがAIを中心に再編されると予想しています。私が生きてきた中で最も近い例は、デスクトップソフトウェアからインターネットへの移行です。
私は会社も仕事も抱えていないので、最近のAIの進展を活かして、好きなことに自由に取り組めます。
それなのに、私はAIとはまったく関係のない本を書いているのです……。
ただ目新しいものを追いかけたいわけではありません。ただ、AI革命を傍観するのは、90年代後半にインターネットの到来を目の当たりにしながら「郵送で注文を受けるCDでソフトウェアを配布したい」と言うようなものだと感じています。
本に集中しようと決めた理由自体は今も妥当だと思っています。ただ、半年前に計画したときよりも、機会費用はずっと大きくなっています。
そもそもこの本に市場はあるのか
もう一つの問題は、本の執筆が長期的な取り組みであるにもかかわらず、読んでくれる人がいるという確信がまだ持てないことです。
最初に公開した章は好評でしたが、あれはとっつきやすく間口の広い、楽しい章の一つです。「Passive voice considered harmful」のような章は、いわば「野菜を食べなさい」的なレッスンではないかと懸念しています。有益だとは思ってもらえても、読んで楽しいものではありません。しかもHacker Newsやredditといった私が普段投稿している場所では、受動態についての投稿が取り上げられることはないでしょう。
問題は、私の本のほとんどの章が、そうした「野菜を食べなさい」系の章だということです。

「投稿を声に出して読む」といったコツをブログの章の一部として紹介するように再構成することもできますが、それはあらゆる文章に当てはまることなので、ブログに限定するのは少し無理があります。
ただ、考え方が間違っているのかもしれません。ウェブを流し読みしている人が、受動態についての記事をわざわざ読みたいとは思わないでしょう。しかし、効果的なライティングについての本を読もうと決めた人なら、受動態の章も読んでくれるはずです。
オンラインで無料公開するサンプルは、本の章を一字一句そのまま載せるものだと思い込んでいましたが、そうする必要はありません。ウェブ向けに自由にアレンジできるのです。だから、ブログについてのサンプル章の中で「文章を声に出して読む」ことに触れてもかまいません。実際の本では、そのコツをブログの章に含めない構成にすればいいのです。
とはいえ、さらに数か月を費やす前に、この本にお金を払ってくれる人がいるのかを検証する必要があります。そこで、次は「開発者に読まれるブログ記事を書く」のような、楽しくてとっつきやすい章に集中し、その最初の3章をもとにKickstarterで予約販売を始めるつもりです。執筆を続ける価値があると判断できる、妥当な最低予約数の目標を設定しなければなりません。
今さらですが:RSSは素晴らしい
RSSは25年前から存在しますが、私はこれまでRSSで記事を読む習慣がありませんでした。
2011年にGoogle Readerを試したのですが、フィードに面白い記事が十分に集まらず、そのうちチェックしなくなり、忘れてしまいました。
ここ数年で、RSSへの関心を高める出来事がいくつかありました。
- Twitterでフォローしていたテック系の人たちが、ばらばらの場所に分散してしまったこと。
- ソーシャルメディアが、興味深い技術的な投稿よりも目を引く投稿を増幅していることに気づいたこと。
- OSをNixOSに切り替えたことで、無料のオープンソースRSSリーダーをセルフホストするのが簡単になったこと。
- ブログをメールで購読するのは、受信箱が散らかるし、読む気分でないときにも読まなければいけない気がして好きではないと気づいたこと。
- AIが生成した低品質なコンテンツがウェブを埋め尽くす中で、自分が好きな特定の人をフォローしたいと思うようになったこと。
そこでRSSリーダーのfusionをインストールしてみたのですが、新しいブログ記事を読む手段として、今では一番気に入っています。ソーシャルメディアで気に入ったブログ記事を見つけたら、その人の他の記事もざっと目を通し、興味のあることを書いていればフィードに追加するようにしています。

最近使い始めたRSSリーダーのfusion。気になるブログをフォローするのに役立っています
サイドプロジェクト
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 foundwordwordを、ブログの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の最大の欠点は、対応しているマネージドな継続的インテグレーション(CI)ベンダーが見当たらないことです。
- 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として使える範囲は大きく制限されています。
10Gbpsルーターを導入しました
初めてISPが上下2Gbpsの対称回線を提供し始めたので、その性能をフルに活かしたいと思いました。
それまで使っていたルーターはQotom Q355G4で、ラックマウントできないことと1Gbpsポートしかないことを除けば、よく働いてくれていました。
OPNsenseやProtectliのような信頼できるハードウェアベンダーからルーターを買いたかったのですが、OPNsenseの最も安い10Gbps対応のラックマウントルーターは1,200ドルもするうえ、Protectliにはラックマウント対応の選択肢がありません。
結局、Qotom C3758R 1U 10Gbpsルーター(送料・税込み417ドル)を購入し、そこにOPNsense Businessをインストールしました。

ISPの新しい2Gbpsプランを活かすため、Qotom C3758R 10Gbpsルーター(上から3番目)を購入しました
ルーターのRAMやディスク容量が足りるかいつも心配になりますが、OPNsenseはほとんどリソースを必要としません。今回はRAM 8GB、ディスク128GBにしました。スピードテスト実行中にシステム負荷を確認したところ、RAM使用率は13%を超えず、CPUも最大で30%程度だったので、私の用途には十分すぎるスペックでした。なお、ファイアウォールルールを大量に設定しているわけではなく、OPNsenseのIDS/IPS機能も使っていません。

完全にRackstuds派になりました
初めて自宅サーバーラックを組み立てた記事を公開したあと、何人かの読者からケージナットの代わりにRackstudsを試してみてはと勧められました。

標準的なケージナットよりもRackstudsの方がずっと気に入っています
当初は懐疑的でした。Rackstudsはプラスチック製なので、金属のケージナットよりも壊れやすそうに見えたからです。しかしRackstudsはラボテストで最大40ポンド(約18kg)までの機器を支えられることが示されています。
Rackstudsはケージナットよりも明らかに扱いやすいです。ケージナットは機器の取り付けが大変で、特に重い機器では苦労しました。片手で機器を持ち上げて水平を保ちつつ、もう一方の手でネジを締めて固定しなければなりません。
Rackstudsはこの問題を解決します。先にスタッドを取り付けてから、そこに機器を引っ掛けるだけでいいからです。
戸惑ったのは、Rackstudsには赤と紫の2種類があることです。違いがややこしいのです。紫のスタッドの製品ページにはこう書かれています。
Suitable for rails between 2.7mm/0.106 and 3.2mm/0.125". If ≤ 2.2mm/0.086", use the new red version instead
は?
私がサーバーラックの「レール」と聞いて思い浮かべるのは、サーバーに取り付けてスライドさせるための部品で、どの寸法も3mmよりはるかに大きいのです。

私がサーバーラックの「レール」だと思っていたもの
ようやくわかったのですが、Rackstudsが言う「レールの厚さ」とは、ラック前面の金属部分のことを指していました。

私のStarTech製ラックでは、紫のRackstudsの方がしっくりきました。
もう一つの注意点として、Rackstuds Duoを買うと、ちょうど1Uの機器にしか使えませんが、バラ売りのRackstudsなら何でもラックマウントできます。最初に8個入りのサンプルパックを買い、その後、今後のラック機器用に20個入りを購入しました。
まとめ
何をやり遂げたか
- Refactoring Englishの章「Passive Voice Considered Harmful」と、付随するインタラクティブ演習を公開しました。
- My Seventh Year as a Bootstrapped Founderを公開しました。
- 短いノート記事を5本公開しました。
- Zigで作った新しいブログのエラーチェックツールを作成しました。
学んだこと
- 本の企画が、かかる時間やAIの変化を活かせる別のプロジェクトと比べて、適切な戦略なのか再評価する必要があります。
- 本の内容をウェブ向けにアレンジして読者を惹きつけることができます。抜粋が本編と100%一致している必要はありません。
来月の目標
- Refactoring Englishのブログの章を完成させる。
- Refactoring Englishの予約販売を開始する。
協力をお願いしたいこと
記事をランダムに読む