一言でまとめると

仕事にゆるやかに復帰しています。

ハイライト

• 新米の父親として、時間のやりくりが少しずつ上手くなってきました。
• 2本のブログ記事の反応が悪いと落ち込んでいましたが、その後どちらも伸びてくれました。
• ソフトウェア開発でスタックド・ディフのワークフローを試してみました。gitの弱点を除けば気に入っています。

目標の自己採点

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

家族との時間を楽しむ

• 結果: 妻と息子との時間を楽しむことができました。
• 評価: A

長時間仕事をしていないように感じても、それは自分で選んだことであり、自分の時間はまだ概ねコントロールできているのだと意識するのが役に立ちました。

仕事と家族の時間のちょうどいいバランスはまだ模索中ですが、状況は着実に良くなってきています。

Nixを使ったファズテストのチュートリアルを公開する

• 結果: ようやく記事を完成させましたが、あまり反響はありませんでした。
• 評価: A

仕事に少しずつ戻る

この振り返りを書こうと腰を据えたとき、仕事をする時間が取れないことへの不安は、もうずいぶん昔のことのように感じられました。2ヶ月も前のことだろうと思っていたら、見返してみると前回の振り返りで書いたことだったので驚きました。

幸い、家族と過ごす時間とのバランスについては、ずいぶんリラックスできるようになりました。家族との時間をたっぷり楽しみつつ、これまで以上に多くの文章を公開できています。

背景にはいくつかの要因があります。

息子が夜によく眠るようになった

最初は一晩に3〜4回起き、そのたびに60〜90分かけて授乳していましたが、今は起きるのが一晩に2〜3回になり、15〜60分でまた寝てくれるようになりました。

昨夜は通しで7時間45分眠ってくれて、とても嬉しかったです。

家族のサポートが増えた

息子が少し大きくなり、家族に来てもらって自分たちがいなくても面倒を見てもらうことに抵抗がなくなってきました。今は週に5時間ほど手伝ってもらっていますが、家族はもっと手伝う意思があるので、今後も増えていくと思います。

息子を抱っこしながら仕事ができる

息子は誰かに抱っこされているときや胸の上の抱っこ紐の中にいるときの方が長く眠るので、1日1〜3時間は胸に乗せたまま仕事をしています。妻にとっては数時間ひとりになれる時間になるので、いい息抜きになっています。

確実に確保された作業時間がある

不規則なスケジュールで仕事をするのは難しいと感じています。妻が息子を見てくれている時間や、息子が胸の上で眠っている時間はたくさんありますが、いつ急に呼ばれてもおかしくないと思うと集中しづらいのです。

妻が毎日90分間は確実に集中できる時間をくれると提案してくれて、これが集中するのに役立っています。毎日その時間が確保されていると分かっているので、高い集中力を要するタスクはその時間に回すことができます。

ブログ記事に投資しすぎているだろうか？

以前の自分には、何か難しいことを学ぶたびに、必ずそれを解説するブログ記事を書かなければならないという悪い癖がありました。

記事の対象読者がごくわずかだったり、自分に読者へ届ける手段がなかったりしても、すべての記事を最大限磨き上げようとしていました。過去の例としては「Hiring Content Writers: A Guide for Small Businesses」（読者はいるが届ける手段がない）や「Retrofitting Apps for Cloud Storage with Zero Code Changes」（非常にニッチで、自分の特殊なユースケース以外では面白くないもの）があります。

これらの記事を評価してくれた読者にも話を聞きましたが、機会費用も考えなければなりません。これらを書くのに費やした時間で、もっと多くの読者に届いたり、全体としてより大きな価値を提供できたりする別の記事があったのではないでしょうか。

それ以来、投稿についてはより戦略的になるようにしています。十分な数の読者に届く見込みがない記事は、書かないか、「Notes」セクションに簡単な走り書きとして残すだけにしています。

「Using Nix to Fuzz Test a PDF Parser」

この記事にどれだけ時間を投資すべきだったか、今でも複雑な気持ちです。

記事を書くことでNixやファズテストについて多くを学べましたが、思ったより時間がかかってしまいました。最初は「数時間でサクッとまとめられるだろう」と思っていたのに、結局20時間以上かかりました。

LLMの時代にソフトウェアのチュートリアルを書くのは気が滅入ることでもあります。数年前までは、チュートリアルには長期的なリターンがありました。ウェブ検索を通じて後から見つけてもらえるからです。最近では、ニッチなチュートリアルを書いてもLLMに内容を盗用され、読者はそれが自分のものだとは気づきません。

「Lessons from my First Exit」

最初から、この記事はリスクが高いと分かっていました。いくつかの不利な条件が重なっていたからです。

• 事業売却の生々しい詳細についての記事であり、読者の99%はそれを実行する予定がありません。
  • 前回の売却についての記事は反響がありましたが、あれはストーリーとして楽しめる内容だったので、自分で売却するつもりがなくても読者は楽しめたのです。
• とにかく長い記事です。
  • 1記事あたりの読了時間を10分程度にしたいと思っていますが、この記事は推定33分もかかります。
• まともに拡散する可能性があるSNSはHacker Newsしかありませんでした。

Hacker Newsに投稿してみましたが、まったくフロントページに載りませんでした。

今でもHacker Newsで伸びる可能性は十分あると思っていますが、仮に完全に失敗したとしても、書いたこと自体には満足しています。自分自身のために買収について整理できたし、もしまた事業を売却することがあれば役立つ資料になります。買収を経験した、あるいは考えている創業者たちからは肯定的なフィードバックももらえています。

そして突然、それらの記事が伸びた

上の文章を書いた後、Hackadayが自分のNixファズテストのチュートリアルについて書いてくれていることに気づき、報われた気持ちになりました。

そして「Lessons from my First Exit」が不発だったという節を書いた翌日、読者の誰かが再びHacker Newsに投稿してくれて、2位まで上がりました。

とはいえ、自分の当初の分析は正しかったと思っています。ファズテストの記事には投資しすぎたし、TinyPilot売却についての記事には適切な投資ができました。

スタックド・ディフで大きな機能を実装する

ここ数週間、趣味のプログラミング時間のほとんどを、テレビや映画のレビュー用ウェブアプリであるScreenJournalに費やしてきました。このアプリはLetterboxdやGoodreadsのようなものですが、レビューは友達にしか見えず、コードはオープンソースというコンセプトです。

当初からScreenJournalでは映画とテレビ番組の両方をサポートしたいと思っていましたが、映画の方がシンプルなので先に実装しました。テレビ番組に対応するか分からなかったので、すでにある機能を最適化するために、あえてコードを汎用化しませんでした。

10月にテレビ番組のレビュー機能を追加したので、レビューは常に映画だという前提で書かれていたコードベースの多くの仮定を修正する必要がありました。

最終的に変更量は2,000行に達し、単一のチェンジリストで理解するには少し扱いづらい規模になりました。ここで「チェンジリスト」と言っているのは、GitHubでいうプルリクエストやGitLabでいうマージリクエストのようなものです。

以前はこのような大きな変更に取り組むとき、機能が完成するまで壊れたり未完成だったりするフィーチャーブランチを用意していました。そのフィーチャーブランチに直接変更を加えるか、さらにそこからサブタスク用のブランチを切って、完了したらマージするというやり方です。

このアプローチの問題は、フィーチャーブランチが巨大な変更の塊になってしまい、理解するには大きすぎることです。What Got DoneをFirestoreからSQLiteに移行したときがその例で、その変更の中にも多くのサブステップがありましたが、すべてが混ざり合っているため個別に確認することはできません。

そこで今回のScreenJournalの変更では、違うやり方を試してみました。大きくて雑然としたフィーチャーブランチを維持する代わりに、スタックド・ディフを採用したのです。

今回は、テレビ番組のレビューフローにおけるページごとにチェンジリストを作って作業を分割しました。

レビューを投稿する最初のステップは、レビューしたい作品を検索することです。以前は映画だけだったので、テレビ番組対応の第一歩として、映画かテレビ番組かを選べるラジオボタンを追加しました。

次に必要だったのは、ユーザーがテレビ番組のシーズンを選べるようにすることでした。映画だけのときにはなかった機能なので、これも独立した変更として実装しました。

以降も同じように、フローの各段階を新しいブランチと独立したプルリクエストとして進めていきました。

この開発スタイルから得られた気づきをいくつか紹介します。

良かった点：スタックド・ディフの方がモチベーションが上がる

スタックド・ディフの良いところは、機能の各サブタスクがそれぞれ独立したチェンジリストになることです。

変更を小さな単位に分割することで、達成感や進捗感が得やすくなりました。1つの大きな雑然としたブランチでサブタスクを完了しても全体の30%から35%に進んだだけという状態よりも、1つのチェンジリストを完了して100%終わったと分かる方が満足感があります。

悪かった点：変更履歴を常に消さなければならない

スタックド・ディフのワークフローで最も気に入らないのは、ソース履歴を消してしまうことであり、これはソース管理の大きな利点を打ち消してしまいます。

スタックの前の方で変更しておくべきだったことに気づくたびに、git rebaseをする必要があり、履歴が書き換えられてしまいます。そのためGitHubにforce pushしなければならず、チェンジリストには見苦しいforce-pushedの記録が大量に残ってしまいます。

変更のすべてを、まるで各コミットが殺人事件の証拠であるかのように正確に残したい人もいることは知っています。自分はそこまでこだわりませんが、もし間違えたときに元に戻せるような、筋の通ったアンドゥ履歴は欲しいと思っています。force pushはリモート側のアンドゥ履歴を上書きしてしまい、ローカル側からも複雑な手順を踏まなければ復元できないのが気に入りません。

良かった点：--update-refsでスタックド・ディフのリベースが簡単になる

スタックド・ディフのワークフローを試している最中に、gitの--update-refsフラグについて知りました。これを使うと複数のブランチを一度にリベースできます。

以前は各ブランチを順番にリベースしていて、スタックが4つになると途端に面倒になっていたので、このテクニックのおかげでスタックド・ディフが楽になりました。

悪かった点：--update-refs後のプッシュが依然として面倒

ブランチA、B、Cがあって、それらを一度にリベースすると、gitの出力は次のようになります。

$ git rebase master --update-refs
Successfully rebased and updated refs/heads/C.
Updated the following refs with --update-refs:
        refs/heads/A
        refs/heads/B

--update-refsはリベース自体を簡単にしてくれますが、「さあ、リベースしたブランチをプッシュしよう」というコマンドは用意されていません。代わりにgitの出力をテキストエディタにコピーし、ブランチ名だけを抜き出して編集してから、git push origin A B C -fのようなコマンドに組み立て直さなければなりません。いつも作業の流れが中断される面倒なプロセスです。

悪かった点：よく予期せぬgitの状態に陥る

正しい方法でリベースしているつもりでも、頻繁に混乱する状態に陥りました。リベースしたのに、すでに解消したはずのコンフリクトをまた解消しろと求められたりするのです。

コミットをスカッシュしてから再度リベースすることで回避しましたが、これもまた履歴を書き換えることになり、間違いを元に戻すのが難しくなります。コードを書くことよりも、どうやってgitにうまく謝るかを考えることに頭を使ってしまうのも苛立たしかったです。

もしかしたらjujutsuを試すべきかもしれない

最近、Google内で標準になりつつある新しいバージョン管理システム、jujutsuについての話題をますます耳にするようになりました。

数ヶ月前には試してみようかと考えて、「まあ、gitで必要なことはできているし、次から次へと新しいものを追いかける必要はないか」と思っていました。だが今回git rebaseでこうした経験をして、これまで多くのフラストレーションを当然のこととして受け入れてきたことに気づきました。

Steve Kalabnikのチュートリアルをざっと読んだ感じでは、jujutsuはgitよりもスタックド・ディフや複数ブランチのリベースをうまくサポートしているようです。

おすすめ

Jonas Hietala氏による「Why I still blog after 15 years」

このブログについての記事にはとても共感しました。Jonasのサイトをさらに見ていくうちに、「この人はスウェーデン版の自分だな」と思うようになりました。もし私の文章を楽しんでくれているなら、彼の文章も気に入るはずです。

Matt Lakeman氏による「Notes on Ukraine」

先週Mattのブログを見つけて以来、毎日「この人は一体何者なんだ？」と考え続けています。

Mattはあまり人気のない目的地に、たいてい10日ほど滞在して、その国についてのブログ記事を公開しています。ただ母親に送る絵葉書のような記事ではありません。国史を何時間もかけて学び、現地の人々と対話した上で書かれた、中編小説くらいの長さの記事なのです。

また、dormin111というユーザー名でインターネット上の別の場所にも長い投稿歴があることも知りました。例えば映画『The Disaster Artist』についての詳細な分析などがそうです。

彼の仕事で最も驚くべきことは、そこに何の狙いも見えないことです。通常、誰かがこれほど執筆に力を注いでいるのを見れば、それがどう自分の利益になるのかは明らかです。Substackや有料講座で稼いでいて、無料記事はロスリーダーになっているといった具合に。ですがLakemanの作品にはそうした狙いや営利目的がまったく見当たりません。彼はただ深く考え、その考えを共有することを純粋に愛しているように見えます。

話をこのウクライナの記事に戻すと、私は彼が戦争前に訪れたのだろうと思っていましたが、実際には開戦の2ヶ月後に訪れ、前線から数マイルの場所で兵士や民間人にインタビューしていました。職業的なジャーナリストではない人物が、それでもウクライナで多様な生の人々にインタビューして伝える戦争の記録は興味深かったです。従来のメディアで見たどの報道よりも、より本物で個人的な視点で状況を捉えているように感じました。

Cyberpunk 2077（ゲーム）

私はあまりゲームをしません。年に1本新しいゲームを買い、飽きるまでプレイするのですが、たいてい数日で5〜25時間ほどです。このゲームはすでに25時間ほどプレイしていますが、まだ楽しめています。

その奥深さには驚かされます。25時間プレイしても全体の5%ほどしか探索できていないと思うので、現代のゲームがいかに広大な世界を持っているかに驚きます。

普段はゲームのストーリーにあまり興味がなく、退屈な説明を延々と見せられるのは煩わしく感じるのですが、Cyberpunk 2077は数少ない、ストーリーが魅力的でちゃんと耳を傾けたくなるゲームです。キアヌ・リーブスが主要な役で出演するほど声優に力を入れているのもすごいと思います。

Detroiters（テレビ番組）

この番組のことは以前から聞いていましたが、タイトルがずっと観るのをためらわせていました。登場人物がデトロイトに住んでいることが最大の特徴の番組？ 退屈そうだと思っていたのです。

それから番組のクリップを観て、素晴らしい人たちが出演していること、そしてトーンがI Think You Should Leaveを少しだけ地に足のついたシットコム形式にしたような感じだと気づきました。ちょうどシーズン1を見終えたところですが、とても良かったです。

まとめ

何ができたか？

• 長編記事を2本公開しました。
  • 「Lessons from my First Exit」
  • 「Using Nix to Fuzz Test a PDF Parser」
• 短いノートを5本公開しました。
  • 「Delete the Timestamps from your Static Blog」
  • 「Massachusetts Residents Can Sue Online Merchants for Spam」
  • 「An Unsuccessful Experiment with Nemotron」
  • 「Creating a Nix Workflow to Fuzz netconsd」
  • 「Takeaways from Charles Marohn’s ‘Escaping the Housing Trap’」
• ScreenJournalにテレビ番組のレビュー機能を追加しました。

学んだこと

• スタックド・ディフは大規模な変更に対して優れたワークフローを提供しますが、gitはそれをうまくサポートしていません。
• ブログ記事への投資は、期待されるリターンに見合うようにしましょう。
  • 学んだことすべてを記録するのが大好きですが、ブログを財政的に持続可能にするためには、長編記事の大部分が、有料プロジェクトに興味を持ってくれる可能性のある読者を引きつけるものでなければなりません。

来月の目標

• 家族との時間を楽しむ。
• Refactoring Englishの一章を完成させ、公開する。