家業の鍵屋サイトのロゴを黄金比で作り直し、改行コードの食い違いを直す

ロゴの線を引き直すだけのつもりだった。 その日のうちに、リポジトリ全部の改行コードを揃える話になった。

この日時点の検索順位

朝いちばんにやったのは、家業の鍵屋のサイトの検索順位を測ることだった。

参考として6本だけ測った記録がすでにあった。 地域ごとのページの本命クエリは、前日から動いていない。 固定している20本の本測定は3日後に置いてある。 それでもその日時点の数字が見たかったので、20本を全数で測らせた。

上がっていた。

名乗る名前をどれにするか

この日、地図側の登録名を変えた。

最初に入れたのは、検索でヒットさせたい地名を頭に並べた長い名前だった。 そのあと、実際に電話で名乗っている短い名前に揃え直した。

途中で一度、地名を入れること自体がまずいのではないかと聞いた。 返ってきた答えは逆だった。 地名を避けたほうがいいのは検索結果に出すサイト名の話で、地図の登録名は別の基準で決める。

名乗りが決まると、今度はサイト側に古い表記が残った。 構造化データの別名が2箇所、変更前のままだった。 両方を登録名に揃えさせて、デプロイまで通した。

名刺も看板もたぶんないだろう、と思っていた。 サイトに載せている店舗写真を拡大させると、右端の縦看板に「合カギ」と読めた。 看板は、最初からそこに立っていた。

地図側には写真を1枚足した。 店舗の外観は二日前に登録済みだったので、ブランクキーが並んだ壁のほうを選んだ。

内容が変わっていないページに、今日の日付が入る

デプロイ前に差分を見ると、おかしなものが混ざっていた。

サイトマップの lastmod が3件動いている。 そのうち2件は、中身をまったく触っていないページだった。

原因は生成側にあった。 lastmod を決めるスクリプトが、git status --porcelain で更新を判定していた。 この見方だと、改行コードの記録差だけでも「更新あり」に数えてしまう。

判定を git diff に変えさせた。 直したあとは、更新なしと出るページの日付が最終コミット日と一致した。

ロゴを幾何学で組み直す

次はロゴだった。 既存のマークは、曲線でできた鍵の絵だった。

出した条件は一つだった。 円で取ったのか黄金比で取ったのか、グリッド線を見れば分かる形にしてほしい。 そこが見えていれば、次に誰が触っても同じ手順で再現できる。

最初に上がってきた案は、2pxのグリッドに乗っているだけだった。 比率は黄金比になっていない。 全寸法をφから導き直させ、作図図面を別に付けさせた。

案Bは線が太すぎて、細部が放射状のトゲに見えていた。 これは作り直させた。 作図図面のほうは、ラベルがビューボックスからはみ出す計算になっていた。 余白ごと直させた。

推しを伏せて聞く

3案が並んだ時点で、A案が良さそうに見えた。

自分の見立ては伏せたまま、判断材料だけを渡して Codex に聞かせた。 返ってきたのはC案だった。

同じ回答の中に、実装の誤りが1件混ざっていた。 そちらは正しかった。 軸の線が弓の中心から始まっていて、丸い穴を突き抜けている。 穴の下端から始まるように直させて、それがA-4になった。

もう一つ、16pxではA案の線が1px未満になるという主張があった。 これは読んで納得する種類の話ではない。 実際に16pxでラスタライズし、それを拡大表示する欄をプレビューに足させた。 自分の目で見てから、A-4に決めた。

そこからファビコン一式の生成、ヘッダーの差し替え、SVG化まで通させた。

メモを作ったら開いて見せる

作業の途中で、あるルールを思い出した。 メモを作ったら必ずChromeで開いて見せる、というものだったはずだ。 確認させた。

あった。 今回は新規作成ではなく既存メモへの追記だったので出していなかった、という説明だった。 追記でも読む側の手間は同じなので、その場で出させた。

改行コードで既存ファイルを壊す

ロゴのアセットを差し替えたところで、共通パーツの照合が全ページ差分と判定した。

作業ツリーの改行はCRLF、リポジトリの中身はLFだった。 LFを前提にしたスクリプトが既存のHTMLを読んで書き戻すと、その時点で全行が変わったことになる。

Windowsだからか、と聞いた。

推測で書いた計画書は使い物にならないので、原因をバイト単位まで実測させてから書かせた。 出てきた答えは、環境の名前ではなかった。 リポジトリが改行を宣言していないところに、書き戻すツールの既定がLFであることが重なって起きている。 2台で触っている以上、放っておけばまた出る。

見積もりが実測と違った

計画書を書かせて、Codexのレビューに投げた。

待っている間に、正規化コミットを使い捨てのクローンで実際に打たせた。 前提のほうを先に潰しておきたかった。

見積もりが違った。 89ファイルが動くと書いてあったが、実際に動いたのは3ファイルだった。 リポジトリの中身は元からLFなので、揃え直しても差分はほとんど出ない。

レビューは2往復して、指摘が7点返ってきた。 うち1点は診断そのものの誤りで、もう1点は計画の前後で矛盾していた箇所だった。 推奨案の説明文に、差し替える前の古い数字が残っているのも見つかった。

判断は2つに絞って出させた。 両方の対策を入れるか、片方だけにするか。 ロゴと正規化の、どちらを先にコミットするか。 どちらも推奨どおりに決めた。

直したのは4か所

.gitattributes を置いて、リポジトリ全体をLFと宣言した。

外部から持ってきたライブラリだけはバイト単位で凍結しようとして、途中でやめている。 -text は作業ツリーのバイトをそのまま記録する動きになるので、Windows側で実行すると逆にCRLFがリポジトリに入る。 例外を作らず全部をLFに倒すほうが一貫する。

改行だけの正規化コミットは、git blame の除外リストに登録した。 これを入れておかないと、行の履歴が全部その日で止まって見える。

生成スクリプトのほうも直させた。 書き戻す先のファイルの改行を読んでから、同じもので書く。 同じ判定を2箇所に書くとずれるので、小さな共有モジュールを1本挟ませた。

効いたかどうかを2通りで確かめる

まず、CRLFが残ったままの手元の作業ツリーで走らせた。

以前はスクリプトを実行するたびに、トップページへLFが6箇所ずつ混ざっていた。 それがゼロになった。

次に、再クローンした側で確かめた。 作業ツリーはLFになり、検証は3本とも通り、走らせても差分は出なかった。 手元のほうは正規化しても書き換わらないので、そちらだけを見ていると直っていないように見える。

最後に、この一連をルールとして書き残させてからデプロイした。

決め方を残す

「これ、毎回ミスってる気がする」から始まった話だった。

実際に毎回ミスっていて、原因はWindowsという環境そのものではなく、書き戻す道具の既定値のほうにあった。

この日やったのは、結局どちらも同じことだった。 ロゴは作図図面で、改行はリポジトリの宣言で、決め方を後から説明できる形に置き換えた。 次に触る人が同じ答えにたどり着けるかどうかは、そこで決まる。