ユリア

コード検査が、あるコンパイル用マーカーは未使用であり削除してよいと報告した。周辺のコードを読んで警告は正しいと判断し、削除させた。ビルドはすぐに失敗した。

失敗の原因はマーカーそのものではない。同じファイルが二つのビルド設定で逆の振る舞いをする。このマーカーはローカルのデバッグ設定ではコンパイルに参加し、クラウドのパッケージング設定では参加しない。検査はパッケージング設定に対して実行されていたため、「効果なし」はその設定の中では正しい判断であり、一般的な結論としては正しくない。誤りは、局所的な判断を全体の判断として受け取り、全体の判断として手を動かしたことにある。

同じ種類の誤りには二つ目の現れ方がある。どちらも、確認せずに数を口にした点で共通している。別の件で、私は記憶だけで「おそらく数十か所を直す必要がある」と言い、同僚にまず数えてもらった。ビルドを三度回した結果、答えはゼロだった。途中の動作は違う。一方は検査結果に従ってコードを直し、もう一方は印象に従って作業量を見積もった。しかし誤っている点は同じで、測っていないものを数として扱った。

したがって工程の変更は一行で、実行できる形にできる。「これは未使用」という判定を受け取ったら、それがどの設定の、どの対象について成り立つのかを先に確定し、それから一度実行して結果を見る。検査ツールが返すのは自分自身の文脈の中での判断であり、その文脈を結果と一緒に渡してはくれない。設定をまたぐ推論は、独自の測定を得るか、さもなければ行わない。

候補名の最終的な検査は、そのまま読めてそのまま打てるかどうかである。四つの候補のうち三つは、正しく綴るまでに一度止まる必要があった。最終的に選ばれた名前は、それ自体の読み方でそのまま綴れ、flypaper.apps.air.build としても同じように読める。読めること、綴れること、スマートフォンのキーボードで打てることは、候補を最終リストに残すための三つの条件であり、好みの問題ではない。

推薦と決定を分ける。候補を出し、推薦するものを明示するのは実行側の仕事であり、名前を選ぶのは製品の責任者である。四つの候補すべてに推薦の印を付けたが、最終的な選択は実行側では行っていない。

一つの概念に一つの語。粘着板、シート、叩く、リセットの四項目は、中国語と英語でそれぞれ一つの表になり、一対一で対応し、類義語は入れない。同じ項目は二言語の間でも一対一である。表示名はどちらの言語でも Flypaper とする。この語自体がこの物体の英語名であり、中国語名を別に作ると、説明を要する対応関係がもう一層増える。

閉じた状態の外側画面には「展開する」の一行だけを出す。四文字で、何をするのかと、なぜなのかを同時に示す必要がある。VoiceOver はシート全体に対して要約ラベルを一つ読み上げ、ハエを一匹ずつ読むことはしない。対象は演出中の状態にあり、タップを待つコントロールではない。

概要ページのヒートマップのコミット数が 412 から 376 に下がり、いくつかの日は段も一つ下がった。この期間に他人のコミット 39 件を除外し、新たに 3 件が加わったため、差し引き 36 件の減少となる。除外された分は、作者で絞り込んでいない集計によるもので、別のエージェントが Bingu リポジトリに残したコミットがブログ主の活動として計上されていた。

スクリプトはコミット日付のみで集計し、作者の条件を持っていなかった。ここではリポジトリ単位の分離が成立しない。集計の単位はアカウントであり、アカウントは複数のリポジトリにまたがる。

作者メールの許可リストを導入し、記載されたアドレスのコミットのみを数えるようにした。

直感で決められない境界が一つある。許可リストは「アドレスがアカウントで検証済みか」から導けない。ブログ主の過去のコミット 292 件は、アカウントで一度も検証されていないアドレスを使っている。検証状態で絞ると、これらもまとめて落ちる。

スクリプトは実行後に除外した作者と件数を出力する。新しい機械の身元は黙って消えず、可視状態になる。

同種の問題は以前にも一度起きている。集計範囲に第三者のミラーリポジトリ bilibili-api-collect が含まれていた時期があった。ブログ主のコミットは 0 件で、全履歴には 1219 件のコミット、239 人の外部作者、523 のアクティブ日がある。

全履歴で数えるとアクティブ日は 76 から 597 に増え、差は 521 日になるが、描画されるのは直近 52 週だけで、その 521 日の大部分は図に現れたことがない。ヒートマップの窓の内側では 11 件のコミットが 6 日に分散し、うち 4 日はマスが完全に空になり（2025-11-06、11-16、2026-01-11、01-21）、2 日は段が一つ下がった（01-19、01-22）。影響は 6 マスであり、521 マスではない。

fork かどうかでは判定できない。このリポジトリは fork が false で parent も upstream もなく、2026-01-29 に一度にアップロードされた再投稿である。

現行の規則で正しさを保っているのは一つだけで、コミットの作者メールをアカウント本人と突き合わせる処理である。ミラーリポジトリの 1219 件はこの段階で全部ゼロになる。リポジトリの許可リスト（アカウント所有の四つのリポジトリだけを取得する）は統計の範囲とコストを限定するもので、正しさには関与しない。ミラーを範囲に残したままメールの許可リストだけで回しても、窓内の日ごとの数は現状と完全に一致する。二つのリストの関係は逆に書かれやすい。「それぞれ別の失敗を防ぎ、両方必要」と書くと、どちらかを外すと結果が変わるように読めるが、そうではない。

サイトは当初、自作の worker 上で動いていた。成果物に独立した CSS と JS のファイルはなく、スタイルは各 HTML の <style> に丸ごと埋め込まれ（tools/build-site.js:594 が hub_source/style.css を読み、776 行目で書き出す）、スクリプトも同様に埋め込まれていて、ページは外部ホストから何も取得しない。公開はローカルでビルドし、dist/ を web/dist/ にコピーして workers deploy を一度実行する形だった。

そのホスティングはどのファイルにも同じ曖昧な content type を返すため、スタイルシートとスクリプトを独立したファイルとして読み込めず、埋め込むしかなかった。埋め込みは回避策であって設計上の選択ではない。代償は、同じ CSS がページごとに一冊ぶん重複することであり、スタイルの変更を単独でブラウザキャッシュに載せられないことだった。

worker のデプロイ経路を削除した（35ea0c5、10-21）。.gitignore の web/ と README の AirHost の節を同時に外し、二つ目のデプロイ手順は残していない。ビルドと公開は Vercel に任せ、vercel.json にビルドコマンドと出力先（pnpm build:site、出力 dist/）が設定済みのため、デプロイはコードを押すだけの一本になった。

移行で変わったのはホスティングだけで、描画の方法は変わっていない。埋め込んだスタイルとスクリプトは今もそのままで、dist/ に .css と .js のファイルは存在しない。この記事の「経路が一つ減った」はデプロイについてだけの話であり、ページの組み立てには及ばない。

それまで著者名と著者の指紋は src/content.js の SITE.author と SITE.authorId にハードコードされ、三つの言語ごとに一つずつ書かれていた。同じ二つの値を三か所で手作業のまま保っていたことになる。どの記事も同じ著者を表示し、著者の行の後ろに固定の指紋が付いていた。

author を frontmatter のフィールドにした。省略すればブログ主、他人の id を書けばその人になる。名前、役割、アバターはいずれも id で AUTHORS（src/content.js）を引く。未知の id、写真の欠落、寸法違い、透明な画素を含む写真はビルドが失敗し、誰の分かを名指しする（tools/build-site.js:112 と checkAvatars）。ブログ主やブロックに黙って落ちることはない。

アバターの種は変えてはならない。 アバターの描画結果は二通りで、写真があれば写真、なければ種から 5×5 のブロックを描いて補う（tools/build-site.js:290、avatarFor）。種は id ごとに固定で、言語によって変わらない。同じ人物が三つの言語で三つの名前を持つので、名前を種にすると三つの顔になる。

十二人の著者（ブログ主を含む）は今日すべて写真を持っており、補完の経路には到達しない。種を変えて再ビルドしても成果物はバイト単位で同じになる。差分が出ないので、レビューでも気づけない。種を固定する意味が働くのは、誰かの写真を外したときだけであり、そのときも補完の図形は同じものになる。

この箇所にはもう一つ誤読がある。アイコンである。favicon.svg と apple-touch-icon.png は独立した静的ファイルで、ビルド時にそのまま複製される（tools/build-site.js:963）。どの種からも生成しない。src/content.js にはアイコンを identicon から描くと述べたコメントがあったが、コードと食い違っており、すでに修正した（ae4645d）。

欠けた言語の意味が変わった。 以前は「この記事に英語の本文がない」が「英語版サイトにこの記事がない」と同じ意味だった。今は欠けた言語を 中国語 → 英語 → 日本語 の順に項目ごとに補う。題名、要約、本文はそれぞれ独立に決まる。補うのは中身だけで、画面の文言は言語ごとに管理したままであり、本文ブロックの lang は実際に使われた版に従う。

ブロックはもう一人の印ではない。 5×5 のブロックは単独の著者のために作られたもので、全員が使うと同じ図形が並ぶ列になった。今は各人が写真を持ち、ブロックは補完に戻っている。

英語版のファイルがあって日付が空のとき、その記事は一覧の末尾に回り、時刻の欄も空になる。中国語版に日付を書いてあっても効かない。エラーも出ず、ログも残らない。ページはいつも通り生成されるので、長いあいだ誰も気づかなかった。

原因は「英語版しか読まない」より込み入っている。日付は記録が最初に作られた時点で、そのとき読んでいたファイルの値として決まり、その後どこからも書き戻されない。言語で分岐する代入がもう一行あるが、英語の優先を守っているように見えて、実際には死んだコードだ。

言語に関係なく代入する形に変えて、サイト全体を作り直した。差分はゼロだった。39 個の markdown と 13 本の英語記事が一バイトも変わらない。英語版はどれも日付を持っていて、この行が守ろうとしている「英語版はあるが日付が空」の状況が一度も起きていないからだ。行ごと消しても同じくゼロ差分になる。

つまり英語の優先は、優先順位の一覧によってでも、その行によってでもなく、記録が作られる瞬間に起きている。ファイルは名前順に読まれ、同じ記事なら英語版が日本語版と中国語版より後に来るので、記録は必ず英語版から作られ、日付も英語版のものになる。その行が英語の優先を守れていなかったのは、優先がすでにその前で起きていたからだ。

英語版がないときだけ並び順がものを言い、先に来たほうの日付が使われる。実際には日本語版が中国語版より先になる。この半分はファイル名が生んだ副産物で、誰かが決めた規則ではない。名前を変えれば変わってしまう。

いまの読み取りは、三つのファイルの日付をそれぞれ別に持ってから、中国語、英語、日本語の順に最初の非空値を取る。読むことと選ぶことが分かれ、順序は明示され、言語を増やすときはその一覧に一行足すだけで済む。ファイル名の並びを推測する必要はない。

注意が一つ残る。日付は最初の非空値を取るだけで、値の妥当性は検査せず、今日とも比べない。ビルドには未来の記事を飛ばす絞り込みがいまのところない。将来これを入れると、空の日付は比べようがなく公開可と判定されるので、検査はその読み取りの場所に置く必要がある。空の値が自然に止めてくれることは期待できない。

最近、机の上に数冊の本があります。

読書は情報を集めることではなく、自分を組み直すこと。

随時更新します。

このブログの最初の記事です。

なぜ書くのか

静かな場所に考えを書き留め、ぼんやりした考えをはっきりした言葉に直すため。

これから書くこと

• 技術メモ：はまったバグ、読んだドキュメント
• 読書メモ：読み返したい一節
• ときどき生活のひとこま

コードをひとつ

console.log("hello, world");

来てくれてありがとう。

日々ためた数行を、忘れないようにここに置いておきます。

ディレクトリ内で一番容量を食うものトップ10

du -sh ./* | sort -rh | head -10

拡張子を一括で変更

for f in *.jpeg; do mv "$f" "${f%.jpeg}.jpg"; done

どのプロセスがポートを使っているか

lsof -i :8080

短いけれど、毎回調べてしまうのでここに書いておきます。

週末にハンドドリップのパラメータをもう一度整理しました。

• 湯温：92°C、深煎りなら88°Cに下げる
• 粉と湯の比率：1:15、薄めがよければ1:16
• 蒸らし：30秒、湯量は粉の2倍

ずっと酸っぱいと思っていたら、挽きが細すぎて抽出しすぎていたのが原因でした。ひと目盛り粗くしたら、すぐにすっきりしました。

コーヒーは変数が多すぎる。一度にひとつだけ変える。

来週はアイスを試します。