Mi presento
Nasco nel 1957 in una splendida e famosa isola del Mar Mediterraneo. A tre anni di età "emigro" nel Continente e vado a vivere a circa 20 Km da Roma.
Ed è qui, alle porte di Roma, che vivo la mia infanzia e completo i miei studi nell'anno 1976 con il diploma di perito elettrotecnico conseguito con la votazione di 60/60.
Non frequento l'Università e mi iscrivo ad un corso per programmatori. Inizio a programmare su schede meccanografiche in un linguaggio ormai dimenticato: il Gsal.
Nel frattempo studio anche un altro linguaggio: il Cobol, orientato ad applicazioni gestionali, ancora in uso nonostante sia stato uno dei primi linguaggi di programmazione ad essere utilizzato.
Le prime esperienze con le schede meccanografiche che venivano caricate in computer di dimensioni enormi sono quelle che oltre a riempirmi di nostalgia, mi fanno comprendere quanto sia stato veloce il progresso in questo campo.
Allora però la programmazione non forniva molti sbocchi lavorativi essendo ristretta a poche grandi Aziende ed Enti Pubblici e quindi non vi erano grandi possibilità occupazionali.
La mia prima esperienza lavorativa risale al 1978 quando trovo impiego presso una Concessionaria FIAT, sprovvista di una qualsiasi forma di meccanizzazione. Mi occupo del reparto Officina - Magazzino diventando negli anni responsabile gestionale del Settore.
La passione per l'informatica nata qualche anno prima era però sempre presente. Continuo a studiare anche se non trovo la possibilità di poter applicare quanto appreso in teoria.
Nei primi anni 80 sono assunto da una Concessionaria che, al contrario della prima, è completamente automatizzata costituendo una realtà moderna in un'epoca dove ancora non vi era una diffusione massiccia di tecnologia informatica.
Si lavorava su computer IBM S34, come linguaggio di programmazione si utilizzava l' RPG II dell'IBM. Anche se non programmavo in RPG II iniziavo ad avere la possibiiltà, come operatore, di poter utilizzare da vicino ciò che avevo studiato e che non avevo mai potuto vedere praticamente all'opera.
Nel frattempo iniziarono a comparire i primi M24 dell'Olivetti ed all'orizzonte si affacciava un sistema operativo che avrebbe rivoluzionato il mondo informatico: il DOS.
Precedentemente avevo utilizzato anche gli M20 dell'Olivetti che utilizzavano un altro linguaggio, sviluppato da Olivetti e che è quasi subito scomparso: il PCOS.
La comparsa dell'Olivetti M24 fu il trampolino di lancio per utilizzare un linguaggio che iniziava a diffondersi in maniera sempre maggiore: il GWBASIC.
E' questo il linguaggio di
programmazione che mi è più caro perché è stato il primo che mi ha consentito di
poter sviluppare le prime applicazioni da me utilizzate in prima persona,
svolgendo quindi la funzione contemporanea di operatore e programmatore nonché
di analista di ciò che andavo successivamente ad utilizzare.
Con questo linguaggio iniziai quindi a sviluppare i primi progetti di piccola informatizzazione di procedure operative di Officina anche se i programmi principali giravano su un S36 dell'IBM, erede del modello S34, ed era su questo computer che veniva gestita l'attività della Concessionaria.
I miei piccoli "programmini" però suscitavano curiosità perché riuscivano ad elaborare quello che il sistema principale non riusciva a fare. La flessibilità del linguaggio GWBASIC consentiva nonostante venissero elaborate piccole quantità di dati, di fornire, in tempo reale, risultati molto interessanti per la gestione della Concessionaria.
Arriva il momento in cui decido che è ora di iniziare a camminare con le proprie gambe e quindi decido di abbandonare la Concessionaria, che tanto mi aveva dato, e di intraprendere un'attività autonoma portandomi dietro il bagaglio di dieci anni di esperienza lavorativa vissuta in una ambiente, quello del gruppo FIAT, altamente formativo.
La mia prima attività era quella di consulente e non di programmatore in quanto non mi ritenevo ancora pronto a poter sviluppare applicazioni complesse per la gestione di attività assistenziali.
Nella mia attività di consulenza però notavo sempre di più che i programmi di Officina mancavano di quei dati statistici che sarebbe stato necessario elaborare in tempo reale. Tali dati spesso arrivavano dopo molto tempo oppure non arrivavano mai e quindi ero costretto a gestire le elaborazioni manualmente su vecchi registri polverosi.
Iniziavo intanto a conoscere intanto un linguaggio che consentiva di poter gestire una quantità di dati che il GwBasic non riusciva a fare e che permetteva di accedere ai dati con una velocità superiore e nella massima semplicità: il dBase nella sua versione dBase III.
Con questo linguaggio era possibile creare con semplicità maschere di inserimento dati con poche righe di codice. Ma la cosa più sorprendente era che gli indici per la ricerca erano creati velocemente e senza tutti i problemi che si avevano con il GwBasic nella gestione dei dati. Per quei tempi era una rivoluzione. Era arrivato finalmente ciò che si aspettava da tempo. Era possibile andare a gestire i dati in una forma più rapida ed avere a disposizione maschere che consentivano un'interfaccia utente più amichevole e programmabile in una forma più semplice soprattutto per gli spostamenti del cursore fra i vari campi e nelle procedure di controllo dei dati inseriti.
Il dBase aveva però un problema: ogni postazione di lavoro doveva possedere una licenza d'uso e non era possibile gestire un applicativo senza che non fosse presente il pacchetto applicativo dBase sul computer in cui il programma veniva installato. I costi da sostenere erano dunque abbastanza elevati e non tutti erano disposti ad affrontare tale impegno economico.
Ma ecco comparire all'orizzonte colui che aveva la possibilità di poter far 'girare' un programma sviluppato in dBase senza che i componenti dello stesso fossero presenti. Era il compilatore del dBase, era colui che toglieva al programmatore l'assillo di dover effettuare installazioni dispendiose economicamente e nel pieno rispetto delle regole di licenza vigenti: il Clipper!
Il Clipper consentiva di poter generare in un unico file eseguibile il programma che, installato sul proprio computer, non aveva bisogno di altro per essere operativo. Tutto il linguaggio era racchiuso in un floppy disk. Oltre ad essere tutto regolare a livello di licenza d'uso, il Clipper era anche più veloce nell'accesso ai dati rispetto al dBase.
A questo punto era possibile sviluppare procedure più complesse che potevano operare anche in realtà diverse da quelle che prescindevano che un programma potesse girare solamente su un sistema costoso e complesso.
Sempre più programmatori si avvicinavano a questo splendido linguaggio sviluppando interessanti applicazioni efficienti e veloci, anche in rete locale, consentendo a tante piccole realtà di poter informatizzare la propria piccola o media Azienda a costi sicuramente più abbordabili.
Nel succedersi delle varie versioni il Clipper assumeva sempre più i connotati di un linguaggio autonomo e si scrollava di dosso la nomina di essere semplicemente il compilatore del dBase.
Uscirono una quantità innumerevole di librerie, ricche di funzioni già pronte all'utilizzo, che aumentavano considerevolmente le potenzialità di questo splendido linguaggio.
Intanto io non mi staccavo dal mondo autoriparativo al quale ero rimasto legato. Continuavo a sviluppare programmi sempre più complessi ed in forma completamente autonoma, dalle altre applicazioni presenti in Azienda, adattandoli a quello che era stato sempre il mio modo di intendere la gestione di strutture di questo tipo.
Cresceva l'esperienza e crescevano anche coloro che mi davano fiducia affidandomi la gestione dei loro Centri Assistenziali. Il mio obiettivo era quello di avvicinare all'utilizzo del computer il maggior numero di persone, convincendoli che se anche loro provenivano da altre esperienze tutto ciò era alla loro portata.
Meccanici, Carrozzieri che nella loro vita non avevano fatto altro che riparare vetture iniziavano ad introdursi in questo affascinante mondo affrontando questa avventura con la rudezza che a volte li contraddistingue. Quindi fra un impropero e l'altro, fra promesse di abbandono della macchina infernale che a volte veniva minacciata anche di essere distrutta a martellate, in modo da potersi assicurare che non ricomparisse più alla loro visione, iniziava la mia missione.
Non mi sono mai posto nei loro confronti con un linguaggio da esperti e non ho mai tentato di far pesare determinate mie conoscenze che mi avrebbero consentito di potermi porre in una posizione diversa. D'altronde ero e sono uno di loro. Io ho iniziato a lavorare in Officina a venti anni, appena diplomato. Nella mia attività lavorativa ho visto molte realtà aziendali operanti in ambito autoriparativo. Con gli operai vivevo diverse ore al giorno risolvendo comunemente i problemi che quotidianamente eravamo costretti ad affrontare.
Era dunque necessario comunicare nella forma più semplice possibile per evitare che potessero abbandonare per non essere in grado di affrontare le quotidiane difficoltà.
Io non mi ritengo un grande programmatore. Bravi programmatori ce ne sono tanti in giro ed alcuni, da me conosciuti personalmente, sono dei veri geni inarrivabili.
Mi sono convinto però di una cosa: per sviluppare un buon
programma bisogna pensare non con la propria testa ma con la testa di chi su
quel programma ci deve andare a lavorare tutti i giorni e che alla fine lo saprà
usare meglio di te che lo hai creato e che glielo hai proposto.
Il miglioramento di un programma avviene quando il programmatore ascolta gli operatori . Naturalmente è importante che valuti attentamente che quanto gli viene proposto sia valido e non comporti problemi alla gestione complessiva di quanto da lui progettato.
Un programma deve essere qualcosa di flessibile che si adatta nel miglior modo possibile allo scopo per il quale è stato concepito.
Questo vuol dire quindi uscire dalla programmazione di pacchetti applicativi standard dove all'Utente viene imposto il modello di lavoro comune ad altre migliaia di Utenti come lui.
I miei programmi nonostante mantengano una struttura di base comune cercano di adattarsi alle singole esigenze che possono variare anche in presenza dello stesso tipo di attività.
Se l'operatore non collabora al miglioramento del programma e le eventuali modifiche vengono solamente imposte dal programmatore non vi è crescita, sia per il programma che per l'operatore, e si continuerà a lavorare su un prodotto che viene imposto ma che non è il frutto della collaborazione di chi su quel programma ci lavora tutti i giorni.
E' un discorso che potrà sembrare strano a qualcuno, ma non mi pongo il problema perché il mio obiettivo non è quello di una distribuzione di massa dei miei prodotti, ma di puntare su un discorso di qualità e di personalizzazione lasciando spazio ai suggerimenti che provengono da chi opera quotidianamente sul tuo programma.
Il Clipper, nella sua versione 5.2e, è ancora adesso usato nella maggioranza dei miei programmi anche se nel frattempo è stato affiancato da un linguaggio altrettanto potente, operante in ambiente Windows, che prende il nome di Visual Fox Pro.
Un linguaggio, il Visual Fox Pro poco diffuso in Italia ma che abbina ad una grande semplicità di utilizzo, una rapidità di accesso ai dati non riscontrabile in altri linguaggi concorrenti. Un linguaggio che ha avuto poca diffusione nel nostro Paese ma che è molto utilizzato in altre Nazioni dove vi sono addirittura riviste specializzate su questo linguaggio.
Le mie applicazioni sviluppate in Visual Fox Pro sono integrate con quelle sviluppate in Clipper costituendo uno splendido binomio di passato e presente di due linguaggi che sono state pietre miliari nella storia dei linguaggi dedicati ad applicazioni gestionali.
Termino ringraziando coloro che mi hanno seguito fin qui e mi scuso se mi sono dilungato in questa presentazione ma per me è stato piacevole ricordare le mie esperienze e spero sinceramente che la lettura non sia stata faticosa.
