FlowSharp

Quando un prototipo deve resistere

Sicurezza, isolamento del codice, test e rilasci ripetibili: XFLOW comincia ad affrontare gli errori e gli usi che il prototipo non aveva ancora previsto.

FlowSharp: Quando un prototipo deve resistere. Illustrazione editoriale del Diario.

Questa settimana ho dovuto cambiare domanda. Finora mi ero chiesto soprattutto se XFLOW riuscisse a fare una cosa. Adesso comincio a chiedermi cosa succede quando qualcuno la fa nel modo sbagliato.

È meno gratificante di aggiungere una funzione. Ti costringe a tornare su lavoro che avevi già considerato concluso e ad ammettere che «funziona» era una descrizione un po’ generosa.

Tra la v0.4 e la v0.5 sono arrivati trentatré commit. Una buona parte riguarda proprio questo.

Il divieto deve valere anche senza il bottone

La revisione di sicurezza ha fatto emergere controlli che comunicavano un divieto, senza impedirlo davvero nelle richieste alle API.

Avevo sistemato quello che si vedeva. Non bastava.

Un’interfaccia può nascondere un comando, ma il server deve comunque verificare chi sta facendo la richiesta e con quali permessi. È una distinzione semplice da spiegare. Mentre costruisci velocemente, però, è anche una di quelle che puoi credere di aver già risolto.

Ho lavorato inoltre sull’esecuzione del JavaScript, separandola con isolated-vm. Se permetto a un flusso di eseguire codice, devo stabilire un confine concreto, non affidarmi soltanto alla buona intenzione di chi lo scrive.

Rendere ripetibili le verifiche

Ho impostato la pipeline con GitHub Actions per non dover ricordare ogni volta tutti i controlli prima di un rilascio.

Non mi aspetto che i test trovino qualunque problema. Vorrei almeno che un errore già individuato non torni perché ero concentrato su altro. Con gli agenti di coding il codice cambia in fretta; il bisogno di verifiche ripetibili aumenta di conseguenza.

Nella stessa settimana sono avanzati il versionamento dei flussi e la vista Kanban. Sono due modi diversi di rendere leggibile il lavoro: sapere quale processo si sta usando e vedere dove si trovano le pratiche.

Tornare sulle proprie scelte

Il 28 aprile ho fatto quindici commit. Riguardandoli, il dato che mi interessa è quante volte ho corretto una supposizione fatta nei giorni precedenti.

Sto imparando a lasciare spazio a questo lavoro senza considerarlo un rallentamento imbarazzante. Il prodotto dovrà essere modificato, usato male, aggiornato in ambienti diversi dal mio. Se voglio che duri, devo cominciare a pensarlo anche in quelle condizioni.

Argomentibuild-in-publicflowsharpsicurezzaciversioning