Quando uno strumento non esiste come lo vorresti, finisci per costruirtelo

Tutto comincia da un foglio di carta

Ci sono quelle giornate nelle quali il problema informatico più fastidioso non è un server che non risponde, un disco che rifiuta di lavorare, un database che decide di prendersi una vacanza o una rete che si comporta come un impianto elettrico realizzato da un apprendista stregone.

È un foglio di carta.

Magari una ricevuta da allegare a una nota spese, uno scontrino termico che sta già sbiadendo, un documento da inserire in un fascicolo/perizia oppure, come accade spesso nel mio lavoro, un piccolo oggetto da fotografare e repertare.

Sembra un problema risolto da almeno trent'anni. Esistono scanner piani, alimentatori automatici, stampanti multifunzione, applicazioni per smartphone e sistemi documentali capaci di archiviare quantità impressionanti di informazioni.

Eppure, quando si tratta di acquisire cinque ricevute, due pagine di un verbale e magari la fotografia di un dispositivo elettronico oggetto di analisi forense, qualche volta sembra di dover organizzare una spedizione scientifica.

Per anni ho utilizzato, come tanti, lo scanner piano. Si apre il coperchio, si posiziona il documento sul vetro, si richiude, si avvia l'acquisizione, si attende che la lampada e il sensore completino il loro viaggio. Poi si apre nuovamente, si cambia pagina e si ricomincia.

Quando il documento è piccolo, bisogna anche posizionarlo correttamente, magari correggere l'orientamento, ritagliare l'immagine e controllare che il risultato sia leggibile.

Una pagina non è un problema.

Nemmeno due.

Ma quando le pagine diventano venti, oppure devi acquisire una serie di ricevute di dimensioni differenti, la faccenda cambia. Ogni operazione richiede pochi secondi, che moltiplicati per decine di documenti diventano minuti. E quei minuti, sommati nel corso delle settimane, finiscono per trasformarsi in ore sottratte al lavoro vero.

Senza contare la concentrazione.

Perché il problema non è soltanto quanto tempo impieghi. È quante volte devi interrompere ciò che stavi facendo per occuparti di una procedura meccanica che dovrebbe richiedere il minimo intervento possibile.

Nel lavoro professionale, soprattutto quando si affrontano analisi complesse, il costo di un'interruzione non coincide necessariamente con la sua durata. Uscire mentalmente da un ragionamento e rientrarci può costare più tempo dell'operazione che ti ha distratto.

Lo scanner piano, insomma, svolgeva correttamente il suo mestiere. Ma non sempre rispettava il mio.

Quando arriva l'automazione. E porta con sé altri problemi.

Naturalmente esistono le multifunzione con alimentatore automatico dei documenti, comunemente indicato come ADF.

Ne possiedo una, collegata alla rete locale tramite Wi-Fi, di marca blasonata. Stampante, scanner e altri servizi riuniti in un unico apparecchio.

La soluzione ideale, almeno nelle intenzioni.

In teoria basta caricare i fogli, avviare l'acquisizione e ritirare il documento digitale.

In pratica, ogni tanto la macchina decide di intrattenere con me un rapporto più personale.

Un foglio viene trascinato male, due pagine cercano di attraversare insieme il caricatore, una ricevuta troppo piccola o troppo leggera non è gradita alla meccanica. Oppure la periferica, pur essendo accesa e apparentemente operativa, smette di collaborare attraverso la rete.

Comincia allora il repertorio delle verifiche: collegamento, indirizzo IP, servizi, driver, alimentazione, rulli, sensori, stato della periferica. Talvolta basta un riavvio. Altre volte la diagnosi richiede più attenzione.

Il paradosso è che sono perfettamente in grado di affrontare questi problemi. Mi occupo di informatica professionalmente da decenni. Ma essere capaci di risolvere un guasto non significa avere piacere di farlo ogni volta che si deve acquisire una ricevuta.

È un po' come essere un bravo meccanico e dover smontare il carburatore ogni mattina prima di andare a comprare il pane.

La competenza è utile. La pazienza ha un limite.

C'è poi un'altra questione: uno scanner, piano o alimentato automaticamente, nasce per acquisire fogli.

Nel mio lavoro capita invece di dover documentare un oggetto, una chiavetta USB, un disco rigido, un'etichetta, un componente o qualcosa che semplicemente non può attraversare un alimentatore automatico e non è comodo sistemare sotto il coperchio di uno scanner.

In questi casi serve un'acquisizione fotografica.

E così, dopo aver utilizzato strumenti differenti per necessità sostanzialmente affini, ho cominciato a chiedermi se non fosse possibile semplificare l'intero processo.

Non cercavo una tecnologia rivoluzionaria.

Cercavo di perdere meno tempo.

Che, per un professionista, è già un obiettivo piuttosto ambizioso.

La soluzione c'era già. Più o meno.

Ho quindi cominciato a utilizzare una videocamera USB, inserita in un supporto da tavolo, per acquisire documenti e piccoli oggetti. Vista, piaciuta, presa!

Il principio è semplice: si posiziona ciò che si vuole riprendere, si controlla l'inquadratura e si acquisisce l'immagine.

Niente coperchi da sollevare, carrelli da aspettare o fogli che devono superare una prova di compatibilità meccanica. Un oggetto può essere ruotato, spostato o ripreso da un'altra angolazione senza dover modificare l'intera procedura.

Naturalmente la videocamera disponeva del proprio software a corredo.

Un'applicazione con parecchie funzioni, automatismi e possibilità di acquisizione. Non necessariamente inutili, ma organizzati secondo esigenze che evidentemente non coincidevano con le mie.

Alcune operazioni risultavano poco intuitive; altre richiedevano passaggi che avrei preferito evitare. Per determinati risultati dovevo ricorrere a ulteriori elaborazioni.

Non sostengo che quel software fosse intrinsecamente scadente. Potrebbe soddisfare benissimo le esigenze di moltissimi utilizzatori. Semplicemente, non soddisfaceva le mie e chi ha sviluppato quel programma evidentemente non conosce le particolarità del mio lavoro ed ovviamente del mio modo di lavorare.

È un problema ricorrente nel mondo informatico: un programma può fare moltissime cose e, contemporaneamente, non fare bene proprio quella che ti interessa.

L'industria del software tende talvolta a misurare il valore di un prodotto in base alla quantità delle funzioni disponibili. Io, dopo anni trascorsi a risolvere problemi informatici, tendo a misurarlo in base alla quantità di problemi che mi evita.

Avrei potuto continuare a cercare alternative, adattare le procedure, costruire qualche soluzione provvisoria.

Poi mi sono posto una domanda: perché continuare ad adattare il lavoro agli strumenti, quando posso progettare uno strumento che si adatti al lavoro?

Una domanda pericolosa, soprattutto quando sai programmare.

Perché la risposta può trasformare una mezz'ora di irritazione in settimane di sviluppo.

E infatti...

Un nome, una videocamera e qualche idea

Così è nato PaperCam. Il nome non nasconde particolari strategie di marketing. Mi serviva semplicemente qualcosa con cui identificare il progetto fra le utility e gli esperimenti informatici che popolano il mio laboratorio.

Un nome corto, riconoscibile e facile da ritrovare.

L'idea iniziale era altrettanto semplice: utilizzare una comune videocamera USB compatibile con GNU/Linux per acquisire documenti e immagini, correggerli quando necessario e produrre file utilizzabili nel mio lavoro.

Una ricevuta. Una pagina contrattuale. Un foglio di garanzia. Un componente elettronico. Una chiavetta USB da documentare fotograficamente. Un disco rigido del quale registrare etichette, condizioni e caratteristiche visibili.

Oggetti molto diversi, ma accomunati dalla necessità di essere acquisiti in modo pratico, leggibile e controllabile.

Per un consulente tecnico, soprattutto quando lavora con materiale destinato a fascicoli o attività peritali, questa distinzione conta.

Non tutto può essere infilato in uno scanner. E non tutto ciò che viene fotografato deve essere trattato come una pagina di testo.

PaperCam ha cominciato a prendere forma proprio attorno a questa differenza.

Con il tempo, quello che doveva essere un piccolo strumento per acquisire immagini è diventato un progetto più articolato, con gestione delle riprese, correzioni e produzione di documenti anche multipagina.

Oggi sono arrivato dopo mesi di sviluppo ad una prima versione Alpha realmente utilizzabile.

Non è una rivoluzione tecnologica. Non pretende di esserlo.

Per me è qualcosa di più concreto: una piccola comodità quotidiana, come una birra fresca dopo una giornata estiva particolarmente calda o il calore del camino quando fuori si ghiaccia.

Non cambia il mondo. Ma quando serve, fa esattamente la differenza che cercavo.

Il controllo non è un difetto dell'interfaccia

Uno dei principi che ho seguito nello sviluppo riguarda il controllo.

Mi piacciono gli automatismi. Quando funzionano bene, sono una conquista straordinaria. Ma non mi piace essere costretto ad accettare decisioni che un programma prende al mio posto senza permettermi di comprenderle o modificarle.

Se una videocamera supporta determinate risoluzioni, modalità di acquisizione e regolazioni, voglio poterle conoscere e utilizzare. Se devo correggere luminosità, contrasto, gamma o ritaglio, voglio vedere cosa succede all'immagine e poter intervenire.

Al tempo stesso non desidero trasformare l'acquisizione di uno scontrino in una sessione di laboratorio fotografico.

Per questo con PaperCam ho cercato di conciliare due esigenze apparentemente opposte: rendere immediate le operazioni comuni e mantenere disponibili controlli più approfonditi.

L'applicazione interroga la videocamera e presenta le possibilità effettivamente supportate dal dispositivo selezionato. L'anteprima in tempo reale permette di sistemare il documento o l'oggetto, verificare l'inquadratura e scegliere il momento migliore per acquisirlo.

Successivamente si può intervenire sull'immagine, senza dover necessariamente passare attraverso altri programmi.

La difficoltà progettuale sta proprio qui: semplificare il lavoro senza semplificare artificialmente lo strumento.

Una funzione nascosta non diventa automaticamente inutile. E un'interfaccia con pochi pulsanti non è necessariamente più efficiente di una con molte regolazioni.

L'equilibrio si trova lavorando, provando, sbagliando e soprattutto utilizzando personalmente ciò che si costruisce.

Mi piace pensare a PaperCam come a un banco da lavoro ben attrezzato: gli strumenti che servono ogni giorno sono a portata di mano; quelli specialistici restano disponibili quando occorrono.

Non è necessario utilizzare ogni attrezzo per eseguire ogni operazione.

Ma è rassicurante sapere che c'è, quando serve.

Il mio computer, i miei documenti

Un'altra scelta è stata quasi naturale: PaperCam lavora localmente.

Non ho bisogno che una ricevuta, un documento riservato o la fotografia di un reperto attraversino Internet per essere elaborati.

Non mi occorrono account remoti, servizi cloud obbligatori o sistemi di telemetria incaricati di raccontare a qualcun altro come utilizzo il mio programma.

Non ho nulla contro i servizi online quando offrono un vantaggio concreto. Li utilizzo quando servono.

Ma se un'elaborazione può essere eseguita interamente sul mio computer, aggiungere un'infrastruttura remota senza una necessità tecnica significa introdurre dipendenze, complessità e possibili punti di criticità.

PaperCam nasce su GNU/Linux, utilizzando strumenti di sviluppo e interfacce disponibili in quell'ambiente. Una scelta coerente con il mio modo di lavorare: conoscere ciò che utilizzo, poterlo analizzare e non dipendere inutilmente dalle decisioni commerciali di un produttore.

D'altra parte, dopo tanti anni trascorsi a occuparmi anche di sistemi Wind*ws, ho sviluppato una certa diffidenza verso l'idea che ogni miglioramento debba necessariamente comportare un nuovo requisito hardware, un account aggiuntivo o qualche autorizzazione da concedere.

In PaperCam ho previsto anche informazioni tecniche e metadati associati ai documenti prodotti, con la possibilità di accompagnare determinati file con impronte crittografiche.

Sono elementi utili alla documentazione e alla tracciabilità tecnica.

Non trasformano però automaticamente un'immagine in una prova autentica o incontestabile. In ambito forense la validità di un'acquisizione dipende anche dalle procedure, dal contesto, dalla documentazione delle operazioni e dalla possibilità di ricostruire ciò che è stato fatto.

Un software può aiutare il professionista. Non può sostituirne il metodo e la responsabilità.

Quando il programma esce dal laboratorio

Finché un'applicazione funziona sul computer dello sviluppatore, la soddisfazione è comprensibile.

Ma è anche prematura.

La vera prova comincia quando il programma deve funzionare altrove.

PaperCam l'ho sviluppato con Free Pascal e Lazarus, nell'ambiente GNU/Linux che utilizzo abitualmente. Il lavoro non si è limitato alla scrittura delle funzioni di acquisizione: è stato necessario affrontare la gestione dei dispositivi video, dei formati delle immagini, delle risorse, delle interfacce grafiche e dei comportamenti differenti delle videocamere.

Un dispositivo può funzionare perfettamente alla prima connessione e comportarsi diversamente dopo essere stato scollegato e ricollegato.

Una modalità video dichiarata disponibile può rivelarsi problematica nell'utilizzo concreto.

Un'anteprima può apparire corretta mentre l'immagine acquisita presenta risultati inattesi.

E quando tutto sembra finalmente sistemato, si scopre che una modifica all'interfaccia ha introdotto un problema in una parte del programma che fino al giorno prima funzionava.

Il software ha questa simpatica abitudine: non considera mai definitivamente conclusa una discussione.

Negli ultimi giorni sono passato anche alla distribuzione mediante un pacchetto Debian (.deb) e al collaudo su computer differenti, con installazioni e configurazioni diverse.

Il programma ha superato le prime prove pratiche anche fuori dalla macchina di sviluppo.

È un passaggio importante, perché distingue un esperimento interessante da uno strumento che comincia ad avere una propria consistenza operativa.

Naturalmente sono ancora in Alpha.

Ci sono aspetti da migliorare, funzionalità da completare, verifiche da ripetere e scelte progettuali da consolidare.

Preferisco chiamare le cose con il loro nome. Un'Alpha è un'Alpha, anche quando funziona bene.

L'esperienza non si installa da un pacchetto

Durante lo sviluppo mi sono ritrovato a riflettere su un aspetto che va oltre PaperCam.

Oggi disponiamo di strumenti di programmazione assistita sempre più potenti, capaci di generare codice, suggerire soluzioni e accelerare attività che un tempo richiedevano molto più lavoro manuale.

Li considero strumenti interessanti e li utilizzo.

Ma c'è una differenza sostanziale fra produrre codice e progettare una soluzione.

Occorre comprendere il problema, decidere quali funzioni servono realmente, individuare le dipendenze, riconoscere gli errori, valutare le alternative e stabilire quando un risultato è accettabile.

E prima ancora bisogna avere un'idea sufficientemente chiara di ciò che si vuole ottenere. Non necessariamente di come ottenerlo: quello è parte del lavoro di ricerca, analisi e progettazione.

La difficoltà, spesso, non consiste nello scrivere una funzione, ma nel decidere se quella funzione debba esistere, come debba interagire con le altre e quali conseguenze possa introdurre nel funzionamento complessivo.

È qui che gli anni di esperienza aiutano. Permettono di riconoscere situazioni già incontrate, intuire possibili criticità e distinguere un problema reale da uno soltanto apparente.

Non significa avere sempre la risposta giusta. Significa, più modestamente, sapere quali domande conviene porsi prima di cominciare.

Anche quando si utilizzano strumenti di intelligenza artificiale, qualcuno deve stabilire la direzione, valutare le proposte, controllare i risultati e decidere quando una soluzione non è soddisfacente.

L'intelligenza artificiale può produrre codice in pochi secondi. Può persino suggerire una soluzione tecnicamente elegante a un problema che non avevi.

Il difficile, qualche volta, è accorgersene prima di averci costruito intorno il resto del programma.

Queste capacità non si acquisiscono semplicemente installando un ambiente di sviluppo. E nemmeno collezionando attestati.

Le certificazioni possono documentare conoscenze specifiche, talvolta anche molto importanti. Ma non sono un sostituto automatico dell'esperienza, del giudizio e della capacità di affrontare situazioni che non rientrano perfettamente nel programma di un corso.

Dopo decenni di informatica, continuo a studiare, sperimentare e commettere errori. La differenza è che oggi, almeno qualche volta, riconosco prima quelli che sto per commettere.

E quando non ci riesco, ho imparato a considerarli parte del costo della ricerca, purché producano conoscenza e non diventino abitudini.

PaperCam è anche il risultato di questo approccio: partire da un problema, immaginare una soluzione, progettarla, costruirla, verificarla e correggerla finché non comincia a comportarsi come previsto.

Non sempre ci si riesce al primo tentativo. Talvolta nemmeno al decimo.

Ma la capacità di guidare questo processo, assumendosi la responsabilità delle scelte e dei risultati, vale molto più della semplice disponibilità degli strumenti utilizzati.

In fondo, un buon attrezzo può rendere più veloce il lavoro di un artigiano. Non gli insegna automaticamente il mestiere.

Piccoli strumenti, grandi esigenze

Non so ancora quale sarà il percorso futuro di PaperCam.

Per ora è uno strumento nato per il mio lavoro, cresciuto attraverso prove, modifiche e qualche inevitabile imprecazione davanti al monitor.

Ma il suo sviluppo mi ha confermato un'idea che accompagna da tempo il mio modo di intendere l'informatica professionale.

Esistono esigenze troppo specifiche per essere soddisfatte bene da prodotti generalisti e troppo concrete per essere liquidate come problemi marginali.

Ne incontro continuamente nel lavoro con consulenti tecnici, professionisti e studi legali.

Non richiedono necessariamente piattaforme monumentali, architetture distribuite o abbonamenti a servizi che promettono di fare tutto.

Talvolta richiedono un piccolo programma progettato con attenzione, conoscenza del contesto e rispetto per chi dovrà utilizzarlo.

Un software non deve necessariamente impressionare. Deve funzionare, essere comprensibile e permettere al professionista di svolgere il proprio lavoro. E soprattutto non devo sostituirlo se cambia l'hardware.

Ripensandoci, c'è qualcosa di vagamente paradossale nell'aver dedicato tante ore di progettazione e sviluppo per risparmiarne qualcuna davanti a uno scanner.

Ma sarebbe riduttivo misurare il risultato soltanto con il cronometro.

Nel frattempo ho approfondito tecnologie, sperimentato soluzioni, affrontato problemi nuovi e costruito una base di conoscenze e componenti che potrà tornarmi utile anche per altri progetti.

E ho imparato ancora qualcosa. Che, dopo tanti anni di professione, continua a essere una delle soddisfazioni maggiori.

Naturalmente non ogni piccolo inconveniente merita un programma scritto appositamente. Altrimenti finiremmo per trascorrere le giornate a costruire strumenti per risparmiare il tempo che non avremmo più a disposizione per utilizzarli.

Anche capire quando conviene sviluppare qualcosa, quando adattare una soluzione esistente e quando lasciare le cose come stanno fa parte dell'esperienza.

Alla fine, il punto di partenza era molto semplice: un foglio da acquisire, una ricevuta da archiviare, un oggetto da documentare. Operazioni quotidiane che non dovrebbero trasformarsi in esercizi di pazienza o sottrarre inutilmente tempo e concentrazione.

È da queste piccole necessità che possono nascere idee interessanti.

Non sempre occorre inventare qualcosa di completamente nuovo. A volte basta osservare un problema conosciuto da una prospettiva diversa e avere la possibilità, la curiosità e la competenza per affrontarlo.

Non sempre l'innovazione consiste nell'aggiungere funzioni. A volte consiste nel restituire al professionista il controllo dei propri strumenti.

E magari lasciargli anche il tempo per occuparsi di qualcosa di più interessante che convincere una stampante a prendere un foglio.