細かく刻んでも直らなかった、経路を変えたら一度で通った

記事のアイキャッチ画像を、CMSへ入れる作業をしていました。画像を文字列に変換して、少しずつ送り込む方法です。

ところが、ときどき壊れます。送った文字列と、届いた文字列が違う。

対処として分割をどんどん細かくしていきました。7000字で壊れたので2500字にし、それでも壊れたので1750字にしました。1750字なら通る。通ったのですが、1枚の画像を送るのに17回かかる計算になりました。

細かくすれば通る、までは正しかった#

画像をそのまま送れないので、いったん文字の並びに変換します。変換すると元の1.3倍くらいの長さになり、1枚で2万8千字ほどになりました。

これを一度に送ると壊れます。どこで壊れたのかを知るために、分割するたびに短い検査用の値を一緒に送って、届いた側で計算し直して突き合わせました。合わなければその回だけやり直せます。

1750字なら安定して通ります。これで「送れる方法」は確立しました。

細かくするのは、経路を疑っていない証拠だった#

ここで手が止まりました。1750字という数字に、根拠が無いことに気づいたからです。

7000で駄目、2500で駄目、1750で通った。通ったという事実しかありません。なぜ1750なら大丈夫なのかは説明できていません。次に別の環境で同じことをしたら、また試して探すことになります。

そして、そもそもの前提を疑っていませんでした。「この経路で送る」ことは決まったこととして扱い、その中でどう工夫するかだけを考えていました。

ファイルをファイルのまま渡す#

やり直したのは、経路の側です。

文字列に変換して少しずつ流し込むのではなく、画像ファイルをそのままCMSのアップロード欄へ渡しました。ブラウザがファイルを受け取る仕組みは元からあり、CMSにもファイルを受け取る画面が元からあります。使っていなかっただけです。

4枚まとめて、約1.9MBを一度で渡して終わりました。分割そのものが不要になったので、検査値の計算も、やり直しの判断も全部消えました。

細かく刻む対処が要るときもある#

もちろん、分割が悪いわけではありません。

経路がひとつしか無いなら、その中で安定する大きさを探すのは正しい対処です。今回もそれで一度は通しました。壊れたことに気づけるようにした部分は、経路を変えたあとも考え方として残ります。

問題は、そこで止まったことです。「通す方法が見つかった」時点で満足してしまい、「そもそもこの経路でよかったのか」を考えませんでした。

今回の学び#

まず、通った理由を説明できない手順は、まだ解けていないということ。1750字で通ったのは事実ですが、なぜ通るのかは分かっていません。説明できない数字が手順に残っているとき、それは運用でごまかしている合図でした。

次に、工夫が積み上がるほど、前提を疑いにくくなること。分割の仕組みと検査の仕組みを自分で作った後だと、その経路を捨てる判断はしにくくなります。手間をかけたものほど、使い続ける理由になってしまいます。

そして、「どうやってうまくやるか」の前に「この道でいいのか」を1回置くこと。今回は66回を1回にしました。差が出たのは工夫の質ではなく、経路の選び方でした。