Cenni storici sul progetto GAM

Prima c'era un grande foglio di carta, un set di matite e qualche gomma...

Giornalmente qualcuno teneva aggiornato il foglio, cercando di tenere sotto controllo lo svolgimento dei lavori in corso fatto da decine di persone raggruppate in varie squadre. Posticipare l'intervento X di un paio di giorni causa pioggia, oppure Spostare Tizio nella squadra Y sostituendolo con Caio della squadra Z, causa litigio significava sobbarcarsi in un lavoro noioso e difficile...

Era Delphi

Alla fine degli anni 90 è stato introdotto il GamExe, che ha rivoluzionato gradualmente tutta l'attività di programmazione e di gestione dei lavori.

Partita come una semplice applicazione per gestire la sola programmazione (quindi sostanzialmente un planner) si è via via arricchita di tutte le funzionalità ritenute necessarie.

Maturazione

Con il GamExe da poco in produzione, è nato l'ambizioso progetto di riscriverlo completamente basandolo interamente su strumenti liberi.

Il GamExe ha rappresentato la mia personale palestra per approfondire le mie conoscenze di Delphi, che da poco avevo cominciato a usare sul lavoro. Gran parte delle mie applicazioni successive hanno attinto a piene mani da questa esperienza, e di fatto alcune parti di quel codice vivono ancora immerse in applicazioni ben più complesse usate da varie industrie...

Era Firebird

Quando finalmente i miei datori di lavoro del tempo si sono convinti che fare applicazioni complesse e stabili basandole su database Paradox era un ossimoro la scelta è andata sull'ottimo Firebird, allora Interbase versione 5 se non sbaglio, distribuito con Delphi. Una volta acquisita una certa dimestichezza con quell'ambiente, che nel frattempo era diventato Interbase 6.0 e successivamente Firebird 1.0, ho cominciato a tradurre in SQL l'intero database Paradox, affinando via via alcuni [source:/db/tools/ strumenti], in particolare:

• il PatchReSTructured, che consente di costruire e mantenere aggiornato un database descritto in un documento  ReST

• un importer in grado di travasare e di aggiornare i dati dalla base dati Paradox a quella Firebird

Era Postgres

Pur essendo molto contento di Firebird, com'è mio solito ho voluto saggiare la bontà di un database diverso: la scelta è caduta sul Postgres, che ho trovato bello robusto, infinitamente meglio documentato di Firebird (è la pecca numero 1), molto più duttile (c'è Python!-) ma anche più subdolo o strambo: ad esempio gli script pgsql non sono "precompilati", come in Firebird, quindi eventuali errori di sintassi vengono riscontrati solo all'esecuzione. Per contro il sistema dei permessi è decisamente più digeribile, quanto meno per chi è avvezzo a una gestione dei permessi basati su gruppi ala Unix.

In breve, quasi completata la riscrittura della base dati, abbiamo deciso di usare Postgres: non è stato difficile, in quanto a livello di DDL i due sistemi sono molto simili e avendo avuto l'accortezza di usare dei DOMAIN per descrivere i singoli campi si è trattato per lo più di ritocchi qui e là.

Riprovaci Sam!

Grazie alla nomenclatura più regolare e alla rigorosità dei vincoli, il nuovo database ha permesso di evidenziare piccole magagne nei dati presenti nel database Paradox usato in produzione. Le potenzialità si sono da subito espresse quando la compilazione dei cedolini per le paghe è stata basata sul nuovo database, passando da una serie incredibile di query incrociate a una singola e snella procedura: il gioco valeva le svariate iterazioni di importare i nuovi dati - correggere gli errori riscontrati - reimportare i dati..."

A questo punto, mentre molta acqua scorreva sotto i ponti, si è cincischiato con questo o quello strumento, a volte propendendo per un aggancio al mondo Plone, altre provando vari tipi di interfacce grafiche. Abbiamo ad esempio usato  kiwi per costruire l'interfaccia utente per i report delle paghe in uso fino all'arrivo in produzione del PylGam 0.3...

TurboGears

Alcuni anni fa ci siamo avventurati nel mondo web non Zope: con  TurboGears è stato facile cominciare a sperimentare, e Lallo si è fatto le ossa dedicandoci del tempo tra marzo e aprile 2007, arrivando a imbastire una piccola applicazione, sufficiente a coprire le esigenze di immissione e ricerca dei dati a contorno della sezione paghe.

SQLALchemy, Pylons e ExtJS

Consapevoli che una applicazione web tradizionale non sarebbe stata sufficiente a coprire la gamma di funzionalità offerta dal GamExe, in particolare per quella relativa alla programmazione, dopo una lunga serie di ricerche e tentativi abbiamo trovato e gradito  ExtJS. Quando la modellazione della base dati con il superlativo  SQLAlchemy è stata completata, considerate le diverse esigenze si è optato per abbandonare il già allora moribondo TurboGears? preferendogli il più giovane ma ben più malleabile  Pylons. E PylGam fu.