Case study
Cosa è stato deciso, e perché
7 analisi di progetti reali su sistemi che avevano già gente dentro. Ogni pezzo parte dal vincolo che ha generato il lavoro, ripercorre le scelte una per una comprese quelle scartate, e dice cosa è rimasto in mano a chi ha pagato.
I nomi dei committenti sono omessi, le decisioni no
Analisi tecnica · software installato presso il cliente
Progettare
Quante versioni del tuo prodotto stai mantenendo davvero?
Ogni «sì, si può fare» detto in trattativa diventa un'installazione diversa da tenere in piedi per sempre. Le abbiamo contate, e poi abbiamo scoperto che i controlli che dovevano coprirle rispondevano verde da mesi senza guardare.
Il vincolo
Il prodotto è lo stesso ovunque. A rompersi è l'installazione, non l'applicazione, e nessuno sapeva quante installazioni diverse esistessero, perché non erano scritte da nessuna parte.
L’esito
Le configurazioni supportate sono diventate un elenco scritto, e «verde» ha smesso di significare tre cose diverse. Il lavoro ha rivelato controlli che dichiaravano successo senza aver verificato nulla e configurazioni senza alcun controllo. Il risultato consegnato è la mappa di dove sono i buchi, e quanto costa ogni riga.
Analisi tecnica · integrazione con un sistema di terzi
Progettare
Il fornitore non ha un'API. Il portale sì.
Come ho ricostruito il protocollo di un cloud industriale per portare i dati delle macchine dentro il gestionale del cliente, e perché mi sono fermato prima dell'ultimo endpoint.
Il vincolo
I dati esistevano, erano completi ed erano perfettamente visibili: su un portale del fornitore, dietro un login. Alla richiesta di un accesso programmatico il costruttore ha risposto allegando il manuale utente del portale.
L’esito
I dati arrivano nel gestionale senza più trascrizioni manuali, e l'integrazione gira ancora: il portale del costruttore è rimasto quello, perché è specifico per quelle macchine e cambiarlo costerebbe troppo. Lungo la strada è emerso che l'endpoint riordinava le risposte, e per due settimane i valori sono finiti nella colonna sbagliata senza produrre un solo errore.
Analisi tecnica · un dimostratore per una richiesta vera
Progettare
Tracking live dei mezzi su mappa
Come ho scelto lo scope, come ho ragionato architettura e test di una companion app .NET MAUI 9 nativa: dalla prima ipotesi al codice verificato.
Il vincolo
Chi sta in cantiere voleva vedere i mezzi sul telefono, non aprire il gestionale d'ufficio. Una richiesta legittima e vaga insieme: nessuno sapeva dire quanto grande fosse il lavoro, né se ne valesse la pena.
L’esito
Una feature portata end-to-end dallo stesso codice, con mappa nativa: eseguita e vista funzionare su iOS, compilata per Android. Ogni bivio è registrato con l'alternativa scartata, e la verifica è dichiarata per intero: cosa è coperto da test, cosa è stato provato a mano, cosa non è verificato e perché.
Case study · osservabilità di un sistema a eventi
Verificare
Dalla cecità alla traccia: strumentare una pipeline esistente
Cosa costa aggiungere l'osservabilità a un sistema costruito senza pensarci: nove servizi, tre linguaggi, un broker in mezzo.
L’esito
Il percorso critico del dato è strumentato senza toccare la logica applicativa: agent e wrapper al posto del codice. Le tracce si sono rivelate già collegate attraverso i topic, quindi sei modifiche pianificate non sono state fatte, non rinviate: dimostrate non necessarie. Il resto del sistema è dichiarato fuori perimetro.
Analisi tecnica · autorizzazione di un sistema in esercizio
Progettare
Il permesso che il sistema non sapeva pronunciare
«Fa vedere il capitolato al subappaltatore, ma non farlo toccare.» Dieci parole che il sistema non aveva il vocabolario per dire. La storia di come si sostituisce l'autorizzazione di un sistema vivo senza migrare un solo record.
L’esito
L'autorizzazione per singola risorsa è diventata esprimibile in OpenFGA: da tre ruoli globali a un'ottantina di relazioni su sei tipi: senza migrare un solo record, e con la possibilità di ricostruire a posteriori chi vedeva cosa. Il percorso vecchio è stato rimosso dopo il periodo di doppia modalita': i permessi vecchi non erano dati, erano condizioni sparse nel codice. Il percorso precedente resta attivo dietro un flag, ed è la parte onesta del risultato.
Analisi tecnica · la consegna come problema di progettazione
Progettare
Software per chi non apre il terminale
L'algoritmo era la parte facile. A tenere in piedi la consegna hanno pensato SmartScreen, una casella in fondo a una schermata di installazione e una libreria da compilare: tutto ciò che sta fra il doppio click e il primo file ridotto.
Il vincolo
Sulla macchina di chi ha scritto il programma funzionava già tutto. Sul computer dell'utente non c'era né Python né il suo PATH, il sistema operativo trattava il launcher come una minaccia, e ogni errore reale arrivava in una lingua che il destinatario non parla.
Analisi tecnica · strumento di misura per lavoro in campo
Progettare
L'app che ho costruito stando fuori da Android
Venti progetti indipendenti, e la piattaforma che compare in uno solo. Come si rifà lo strumento di un tecnico che lavora su un traliccio, quando il sensore che misura non ce l'hai sulla scrivania.
L’esito
La parte che decide, cioè validazione della qualità del segnale, calibrazione, filtri, generazione del rapporto, si verifica senza telefono e senza sensore. Il codice legato alla piattaforma sta in due file su tutto il progetto. Restano scoperte l'integrazione dei venti pezzi e la prova contro il sensore vero.
Hai in mano una situazione simile?
Raccontami com’è fatto il sistema adesso e qual è la decisione che siete fermi a prendere. Mezz’ora per capire se c’è un problema su cui posso essere utile, senza impegno.