一言でまとめると

先延ばしにするのをやめなければいけない。

ハイライト

• 本の執筆を先延ばしする方法を見つけてしまった。
• オープンソースプロジェクトのファズテストを楽しんだ。
• ソフトウェア開発用の新しいハイエンド・デスクトップPCのパーツを選んだ。

目標の自己評価

毎月の初めに、その月に達成したいことを宣言している。目標に対する結果は次のとおりだ。

家族との時間を楽しむ

• 結果：家族との時間を楽しみ続けることができた。
• 評価：A

自主的に取得している育児休暇中、家族との時間と、個人的・仕事上のプロジェクトに取り組む時間のバランスを楽しみ続けている。

Refactoring Englishの1章を完成させて公開する

• 結果：執筆は進めたが、何も公開できなかった。
• 評価：D

この目標を立てたときは甘く見ていた。何年も前に書き始めた章があり、断続的に手を入れてきた。記憶の中ではすでに8割はできているつもりだったが、今回改めて向き合ってみると、むしろ2割程度しかできていないように感じた。

章は6割程度まで進んだが、もっと集中できたはずだ。

本の執筆で先延ばしするのはもうやめなければいけない

もしかして新しいフォントが必要なのかも

本の第1章に取りかかったのだが、サイトの凡庸なデザインがどうも気になって集中できなかった。

本のウェブサイトでは、自作のシンプルなデザインテーマを使っている。BootstrapのデフォルトのCSSに、自分で追加したカスタムスタイルを少し足しただけのものだ。具体的にどこが悪いとは指摘できないが、見た目が何となくしっくりこなかった。

好きなブログやサイトを見て、そこで使われているフォントを自分のサイトで試してみることにした。

• Jonas Hietalaは、Matthew Butterick氏がデザインした有料フォントであるConcourseとCentury Supraを使っている。
• Xe IasoはIosevka Aile Iasoを使っているが、これは彼女自身がデザインしたフォントだそうだ。
• fasterthanlimeはAtkinson Hyperlegibleを使っている。これはBraille Instituteが視覚に障害のある人にも読みやすいようにと無料で配布しているフォントだ。

本のウェブサイトに一番合うと感じたのはConcourseで、そこからMatthew Butterickのフォントを一通り見てみることになった。生まれて初めてGoogle Fontsの無料フォントではなく、お金を出してフォントを購入した。見出しにConcourseを、本文にHeliotropeを使った。

良いフォントに変えるだけでこれほど印象が変わるとは驚いた。他のデザインは一切変えていないのに、サイトの見栄えが3倍は良くなったように感じられ、なんだかずるをしているような気分だった。

もしかして表紙が必要なのかも

かっこいい新しいフォントを入れたあと、本の表紙のことを考え始めた。出版前には表紙を外注する予定なので、どうせなら今頼んでしまってもいい。素敵な表紙があれば、興味を持ってくれる人も増えるはずだ。そこで表紙デザインの仕様書を書き、デザイナーに依頼した。

もしかして前の企画に戻るべきかも

数日後、読者から未完成のHit the Front Page of Hacker Newsのレッスンを購入できないかというメールが届いた。未公開の2つのレッスンと旧コースへのリンクを送ったところ、相手は満足してくれたようだった。これをきっかけに、Refactoring Englishは一旦中断して、Hit the Front Page of Hacker Newsの改訂版を完成させるべきかと考え始めた。

やはり集中すべきなのかも

ここまで来て、自分が本の執筆以外の活動ばかりを見つけて取り組んでいることに気づいた。

本の完成はあまりに遠い目標に感じられるので、気が散りやすい。しかも文章についての本だからこそ、自分の文章は完璧でなければならないというプレッシャーがあり、一語一句にこだわりすぎてしまう。

最初のサンプルチャプターを公開して読者の反応を見れば、本の方向性ももっと掴めるはずだ。とにかく公開まで突き進むことにした。

ファジングはとにかく楽しい

前節で書いたことはさておき、先月はファズテストで大いに楽しんだ。

11月の大半は、生後3ヶ月の息子を寝かしつけてから最初の夜泣きまでの数時間を一人で過ごしていた。寝かしつけてから1〜4時間後に起きるのだが、その間の時間は日中の疲れもあるし、いつ起こされるか分からないのでプログラミングに集中するのは難しい。ただ、ファズテストをするには絶好の時間だった。ファズテストはセットアップに試行錯誤は必要なものの、そこまで高い集中力は要らないからだ。

openc2eのファジング

Nixはファズテストのワークフローを簡単に構築できるようにしてくれるのだが、まだ世の中にあまり知られていないように思う。

ある夜、Facebookが公開した何の変哲もないオープンソースのユーティリティをファジングしたというブログ記事を読んだので、そのファジングのワークフローをNixで再現するのに1時間ほど費やしてみた。

数日後の夜には、数時間かけてopenc2e向けのファザーを書いた。openc2eはCreaturesシリーズのオープンソースの再実装だ。

1996年に発売されたオリジナルのCreaturesには、カスタムスクリプト言語とそれに対応する仮想マシンが含まれていた。その言語はCreatures Agent Object Script (CAOS)と呼ばれ、プレイヤーがゲーム用のカスタムアドオンを作れるようになっている。

CAOSはアセンブリに少し似た低水準言語だ。

SETS VA00 "he"
ADDS VA00 "llo"
DBG: ASRT VA00 eq "hello"

有志によってopenc2eの中にCAOSインタプリタが再実装されているが、これまで誰もファジングしたことがないのではないかと思う。ただ、アドオンをインストールすると信頼できないサードパーティのコードをパースすることになるので、ファジングする価値は十分にある。

まずはCAOS言語のレキサーからファジングを始めてみたところ、たちまち大量のクラッシュが見つかった。

クラッシュの1つは、ただダブルクォートを閉じ忘れただけのものだった。やはり誰もこのコードをファジングしていなかったのだろうと確信した。

* The following line crashes openc2e's CAOS lexer.
"

最も単純なクラッシュの修正と、それを実証するユニットテストを添えてプルリクエストを送ったが、プロジェクトは半ば休止状態なので、すべての修正が取り込まれるまでには時間がかかりそうだ。いずれレビューしてもらえることを願っている。自分でもなかなか良いPRだと思っているので。

ファジングなら何をやっても自由だ

Nixでファジングするうえで最も楽しいことの1つは、誰にも気兼ねせずに元プロジェクトをいじり回せることだ。

openc2eをファジングしようとしたとき、リンクしたいコードがリンクしにくい形でオブジェクトにコンパイルされていることに気づいた。どうやってリンクしようか悩んでいたとき、自分のリポジトリでMakefileにパッチを当てるだけで好きなように変えてしまえばいいのだと気づいた。

通常、オープンソースプロジェクトにコントリビュートする際に、ライブラリを非公開から公開に変えるような大きな変更をしたい場合は、なぜ非公開になっているのかを深く理解し、そのうえで公開すべき理由をメンテナーに説明する必要がある。だがファジングの場合は、自分だけのサンドボックスでやっているので、好きなようにいじり回せるのだ。

新しい開発用デスクトップを組む

ソフトウェア開発のスタイルを大きく変えようと思っている。普通のやり方でコードを書く生活に戻るのだ。

10年ほど前から、ソフトウェア開発はLinuxの方が楽だと感じるようになったが、メインのOSはやはりWindowsの方が好みだった。そこでWindowsデスクトップ上のVirtualBoxでLinux VMを動かすことで折り合いをつけていた。依存関係の衝突を避けるため（例えばPython 2のプロジェクトがPython 3のプロジェクトを壊すといった事態を防ぐため）、プロジェクトごとにVMを分けていた。

2017年には、Windowsを再起動するたびにすべてのVMを再起動しなければならないのが面倒になり、初めてのホームラボ用VMサーバーを自作した。

2019年までには、VS CodeとRemote SSHですべての開発を行うようになっていた。ほぼ問題なく動くのだが、やや特殊な構成ゆえに時々不具合が起きることもあった。

そしてこの1年で、2つの変化があった。

1. 使いたいソフトウェアはほぼすべてLinuxで手に入ることに気づいた。Microsoftのしつこさを増すテレメトリや広告にもうんざりしてきたので、Linuxに乗り換える準備ができた。
2. Nixのプロジェクトごとの環境を知ってからは、プロジェクトごとのVMを使うのをやめ、Nixをインストールした単一のDebian VMですべての開発を行うようになった。

この2つの変化により、もはやVMサーバーもWindowsデスクトップも必要なくなった。1台のデスクトップに集約し、ここ数ヶ月Framework 13ラップトップで気に入って使っているNixOSを導入することにした。

2台を1台に減らすという経済的に堅実な選択をすることで、新しいシステムにお金をかけすぎたことを正当化した。

自分のワークフローではディスクがボトルネックになることが最も多いので、そこには最高のものを惜しみなくつぎ込んだ。贅沢に感じはするが、データの大部分はストレージサーバーにあるので、OS用のディスクは1台あれば十分だ。

CPUは高速だが最上位ではない。CPUを買うときはベンチマークを見て、最上位モデルの8〜9割の性能を持ちながら、価格は半分以下というものを選ぶようにしている。

一番の贅沢はモニターだ。49インチのウルトラワイド有機ELだ。

11歳のとき、父がCompUSAから帰ってきて、当時としては最大級のモニターが入った箱を差し出してくれたときの喜びを今でもはっきり覚えている。おそらく17インチのCRTだった。「モニターを見る時間の長さを考えれば、良いものに投資する価値がある」と父は説明してくれた。ちなみに両親はともにプログラマーで、私は幼い頃から自由な時間の大半をコンピューターの前で過ごしていた。

それ以来、私は父の理屈を盾にプレミアムなモニターを買い続けてきたが、その判断は間違っていなかった。私は年間2500時間をコンピューターの前で過ごしている。1時間あたりのコストで考えれば、ハイエンドなモニターの値段などあってないようなものだ。

それに、一度Hacker Newsを5120x1440pxの解像度で体験してしまったら、もう元には戻れない。

ウルトラワイドモニターの使い方を学ぶ

新しいコンピューターのパーツはまだすべて揃っていないが、新しいモニターはすでに設置した。すぐに、デスクトップでのウィンドウ管理に新しい戦略が必要だと気づいた。

旧モニターは34インチで、Win+Left / Win+Rightでウィンドウを画面の半分にドッキングさせるのが常だった。新しいモニターは横幅が5120pxもあるので、同時に3つ以上のウィンドウを並べたくなった。

Komorebiを試してみたが、複雑すぎると感じた。そこで見つけたFancy Zonesは、まさに求めていたものだった。GUIでゾーンを定義し、ホットキーやマウスでウィンドウをそのゾーンにドッキングできる。

現在設定している4つのゾーンは次のとおりだ。

1. 1000x1440px - メインのVS Codeウィンドウ
2. 1000x1440px - サブのVS Codeウィンドウ
3. 1560x1440px - メインのウェブブラウザウィンドウ
4. 1560x1440px - サブのウェブブラウザウィンドウ

ドッキングするのは基本的にウェブブラウザとVS Codeのウィンドウだけだ。それ以外は一時的に使うフローティングウィンドウとして扱っている。

VS Codeの幅を1000pxに制限しているのは、編集ペインだけを開いておくためだ。画面に余裕があると、ついファイルエクスプローラーなどのサイドパネルを開いたままにしてしまう。1000pxだと、サイドパネルは必要に応じて開けるものの、幅を取るのですぐに閉じてメインの編集パネルに集中する意識が働く。

有機ELと液晶の鮮明さの違いなど気にしないと思っていたが、実際は違いを実感した。黒がより黒く、映像がよりくっきり感じられる。

同様に、リフレッシュレートも気にしないと思っていたが、60Hzと120Hzの違いははっきり分かった。モニターは240Hzに対応しているが、なぜかWindowsではその選択肢が表示されないので、NixOSに切り替えたら色々いじってみるつもりだ。

まとめ

何ができたか？

• ブログのテンプレートやCSSコードを大幅に整理し、ホームページを再構成した。
• 新しいメインのデスクトップワークステーションの構成を決めて発注した。
• Refactoring Englishのデザイン要素に取り組んだ。
• NixOSでシンプルなサービスを動かす方法についてのクイックチュートリアルを公開した。

学んだこと

• 他のプロジェクトにカスタムパッチを当てられるワークフローは、心地よい自由をもたらしてくれる。
  • 変更が自分にしか影響しないので、何をやっても自由だ。そしてパッチを当てるのが簡単なワークフローがあれば、わざわざ特別なバージョンをビルドする負担も感じずに済む。

来月の目標

• Refactoring Englishを2章分完成させる。
• デザイナーと協力してRefactoring Englishの表紙デザインを完成させる。