一言でまとめると

先延ばしをやめなければなりません。

ハイライト

• 本を書く作業を先延ばしにする方法を見つけました。
• オープンソースプロジェクトのファジングテストを楽しみました。
• ソフトウェア開発用の新しいハイエンドデスクトップパソコンのパーツを選びました。

目標の採点

毎月の初めに、その月に達成したいことを宣言しています。目標に対してどの程度できたかを振り返ります。

家族との時間を楽しむ

• 結果：引き続き家族との時間を楽しみました。
• 評価：A

自分で予定を管理する育児休業中も、家族と過ごす時間と、個人・仕事上のプロジェクトに取り組む時間のバランスを楽しんでいます。

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

• 結果：章の執筆は進めましたが、何も公開しませんでした。
• 評価：D

この目標を立てたときは、難しさを見誤っていました。何年も前にある章を書き始め、時々思い出したように戻ってきていたのです。記憶の中では、その章はすでに80％完成していました。ところが今回取り組み直してみると、実際には20％程度しか完成していないように感じました。

完成度は約60％まで上がりましたが、もっと集中して取り組めたはずです。

本の先延ばしをやめなければならない

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

本の第1章に取り組み始めましたが、サイトのぱっとしないデザインが気になって、何度も気を散らされました。

本のサイトには、自分で作ったシンプルなデザインテーマを使っています。BootstrapのデフォルトCSSに、少し自分でスタイルを追加しただけです。具体的にどこが問題なのかは指摘できませんでしたが、見た目がどうもしっくりきませんでした。

気に入っているブログやウェブサイトを眺め、そこで使われているフォントを自分のサイトでも試してみました。

• Jonas Hietalaは、ConcourseとCentury Supraを使っています。どちらもMatthew Butterickがデザインした有料フォントです。
• 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言語の字句解析器をファジングしたところ、すぐに大量のクラッシュを見つけました。

クラッシュの一つは、単に閉じられていない二重引用符でした。これは、誰もこのコードをファジングしたことがないという私の推測を裏付けるものでした。

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

最も単純なクラッシュを修正し、その修正を示すユニットテストを追加するプルリクエストを作成しました。ただ、プロジェクトは半ば放棄された状態なので、修正をすべて取り込んでもらえるまでにはしばらくかかるかもしれません。いつか時間を見つけてレビューしてもらえるといいのですが。自分のPRはなかなか良い出来だと思っています。

ファジングなら何をしてもいい

Nixでファジングを行う面白さの一つは、元のプロジェクトを誰にも迷惑をかけずに好きなようにいじれることです。

openc2eをファジングしようとしたとき、リンクしたかったコードが、リンクしにくいオブジェクトにコンパイルされていることに気づきました。どうリンクすればよいか考えていたところ、リポジトリ内で相手のMakefileにパッチを当て、好きな変更を加えればよいと気づきました。

通常、オープンソースプロジェクトに貢献する際、ライブラリを非公開から公開にするといった大きな変更を加えたければ、まずなぜそもそも非公開なのかを理解するために多くの時間を費やし、そのうえでライブラリを公開するのが合理的な理由をメンテナーに説明しなければなりません。でもファジングなら、自分専用のサンドボックスで作業しているだけなので、好きなようにいじれます。

新しい開発用デスクトップを組み立てる

ソフトウェア開発の習慣を大きく変えるつもりです。もう一度、普通の人のようにコードを書くことにします。

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

2017年には、Windowsシステムを再起動するたびにすべてのVMを再起動しなければならないことに嫌気が差し、初めてホームラボ用のVMサーバーを組み立てました。

2019年までには、VS CodeとRemote SSHを使ってすべての開発を行うようになりました。概ねうまく動きますが、やや特殊な構成なので、時々問題が起きます。

そして、この1年で二つの変化がありました。

1. 自分が必要とするソフトウェアのほぼすべてがLinuxで利用できることに気づきました。WindowsにおけるMicrosoftの、ますます侵入的になっているテレメトリや広告にうんざりしてきたので、Linuxへ移行する準備はできています。
2. Nixのプロジェクトごとの環境を知って以来、プロジェクトごとのVMを使うのをやめ、Nixをインストールした単一のDebian VMですべての開発を行っています。

この二つの変化により、VMサーバーもWindowsデスクトップも必要なくなりました。ここ数か月、Framework 13のノートパソコンでNixOSを快適に使っているので、LinuxとNixOSを動かす1台のデスクトップに集約するつもりです。

2台のマシンを1台に減らすのは経済的にも責任ある選択です。そう自分に言い聞かせて、新しいシステムに予算をかけすぎたことを正当化しました。

自分のワークフローでは、ボトルネックになるのはたいていディスクです。贅沢な気もしましたが、そこには最高のものを選びました。データの大半はストレージサーバーに置いているので、OS用のディスクは1台あれば十分です。

CPUは高速ですが、最上位モデルではありません。CPUを買うときはベンチマークを確認し、最も高性能な選択肢の80～90％程度の性能がありながら、最上位価格の半額以下で買えるものを選ぶようにしています。

最大の贅沢はモニターです。49インチの、とんでもなく大きなウルトラワイドOLEDです。

11歳の頃、父がCompUSAから帰ってきて、当時入手できる最大級のモニター、たぶん17インチのCRTが入った箱を渡してくれたときの喜びを、今でもはっきり覚えています。父はこう説明しました。「モニターを見る時間が長いんだから、良いものに投資してもいいだろう」。ちなみに、両親はどちらもプログラマーで、私は幼い頃から自由時間のほとんどをコンピューターの前で過ごしていました。

それ以来、父の論理を高級モニターの購入を正当化するのに使ってきましたが、実際にうまくいっています。私は年間2,500時間をコンピューターの前で過ごします。1時間あたりに換算すれば、高級モニターの費用などほとんど無視できる程度です。

それに、5120x1440pxの解像度でHacker Newsを体験してしまった今、もう元には戻れません。

ウルトラワイドモニターの使い方を覚える

新しいコンピューターのパーツはまだすべて届いていませんが、新しいモニターはすでに設置しました。すると、デスクトップ上のウィンドウを管理する新しい方法が必要だとすぐにわかりました。

以前のモニターは34インチで、デスクトップ上のウィンドウを半分の幅にスナップするため、主にWin+Left／Win+Rightを使っていました。新しいモニターは幅が5120pxあるので、一度に2つ以上のウィンドウをスナップしたいと思いました。

Komorebiを試しましたが、複雑すぎました。その後Fancy Zonesを見つけました。まさに自分が求めていたものです。GUIでゾーンを定義でき、ホットキーまたはマウスでウィンドウをそのゾーンにスナップできます。

私が設定した4つのゾーンは次のとおりです。

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

基本的にスナップするのは、ウェブブラウザーとVS Codeのウィンドウだけです。それ以外は、短時間だけ使うフローティングウィンドウにしています。

VS Codeの幅を1000pxに制限すると便利です。編集ペインだけを開いた状態にしておきたいからです。画面がもっと広いと、ファイルエクスプローラーなどの他のパネルを開いたままにしてしまいます。でも幅が1000pxなら、必要なときにサイドパネルを開くことはできますし、その存在が十分に目立つので、後で閉じてメインの編集パネルに集中し直せます。

OLEDとLEDの鮮明さの違いも気にするとは思っていませんでしたが、実際には違いをありがたく感じています。黒がより黒く見えるので、画像がいっそうくっきりします。

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

まとめ

何ができたか

• ブログのテンプレートとCSSコードを大幅に整理し、ホームページを再構成しました。
• 新しいメインのデスクトップワークステーション用のパーツを選び、注文しました。
• Refactoring Englishのデザイン要素に取り組みました。
• NixOSでシンプルなサービスを実行する方法について、短いチュートリアルを公開しました。

学んだこと

• 他のプロジェクトにカスタムパッチを適用できるワークフローには、心地よい自由があります。
  • 変更の影響を受けるのは自分だけなので、好きなことができます。しかも、パッチを簡単に適用できるワークフローがあれば、コードの特別なバージョンをビルドする負担も感じません。

来月の目標

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