Zero Upgrade

Nel precedente post ho fatto menzione alle comodita' programmative dell'usare una rappresentazione "uno a uno" degli oggetti manipolati ad alto livello con lo schema del proprio database: poco codice che gestisce tutto quanto, logica abbastanza lineare e necessariamente coerente dunque comprensibile, grande flessibilita'...

Qui vorrei fare una rapida menzione ad un ulteriore vantaggio di questa strategia, che ho l'altro giorno implementato e perfezionato nel codice del mio gestionale per gruppi di acquisto: l'aggiornamento automatico e trasparente del database in caso di upgrade dell'applicazione.

Passando dalla release 1.0 alla release 2.0 mi sono posto il problema di rendere l'upgrade di GASdotto semplice, almeno tanto quanto lo e' l'installazione, ma ho sicuramente fatto le cose un po' di fretta e mi son ritrovato un garbuglio di "ALTER TABLE" che certamente non avrei potuto mantenere anche nella futura release 3.0 (dovendo peraltro gestire i casi di migrazione partendo da 1.0 o 2.0). Alche' mi sono ingegnato ed ho deciso di spremere meglio la mia mappatura degli oggetti sul database, implementando l'operazione inversa: costruire il database partendo dalle classi PHP.

La funzione che effettua davvero le query (resa unica in tutto il programma originariamente con l'intento di centralizzare la gestione degli errori) e' stata modificata in modo che, se una richiesta verso il database fallisce, prima di tentare una seconda volta verifica che tutte le tabelle siano al loro posto e che esse abbiano tutte le colonne che descrivono gli attributi dei miei oggetti PHP di alto livello. L'effetto collaterale di tale meccanismo e' ovvio: GASdotto non abbisogna piu' di una procedura esplicita di upgrade, basta decomprimere l'archivio compresso al posto del precedente (magari salvandosi prima il file di configurazione) e al primo login si arrangia da solo nel modificare il database allineandolo alla struttura richiesta con le nuove colonne e le nuove tabelle.

La procedura deve ancora essere testata con cura, ma i primi esperimenti sono stati soddisfacenti: trovandomi adesso ad attuare qualche correzione alla gestione delle notifiche mi trovo a dover aggiungere qualche attributo alla classe Notification, e laddove prima dovevo rimaneggiare la classe PHP, quella Java e lo schema del database, adesso metto mano solo al codice e la prima volta che ricarico l'applicazione nel browser la query fallisce, esegue il controllo, crea le nuove colonne richieste nelle tabelle e tira dritto.

Sebbene il tutto sia ancora migliorabile (manca la definizione dei valori con cui inizializzare le eventuali nuove porzioni di database) posso ritenermi soddisfatto di questa novita': ho eliminato un passaggio richiesto per l'amministrazione dell'applicazione da parte degli utenti (spianando peraltro la strada ad un futuro automatismo per l'aggiornamento trasparente, come quello gia' esistente nell'ottimo Wordpress), ed io ho ridotto la quantita' di cose di cui preoccuparmi durante lo sviluppo.

Regola 1: essere pigro, e far fare alla macchina quello che non si ha voglia di fare a mano.

Il Pallino del Database

Ogniqualvolta mi confronto con un qualche programmatore in merito ad una qualsiasi applicazione che deve gestire un po' di dati, pare che la prima (ed unica?) preoccupazione sia lo schema del database. Mi e' gia' capitato con numerosi personaggi, tra cui un SAPpista, un imprenditore ex-sviluppatore di gestionali, diversi developers freelance, insomma con chiunque abbia anche una vaga idea di come scrivere codice: quando si parla di un programma, la prima cosa che vogliono vedere e' il database.

Saro' un eretico, ma a me non pare che questo componente necessiti di tali particolari attenzioni.

Certamente dallo schema del database adottato dipende la scalabilita', la possibilita' di aggiungere funzionalita' complesse in futuro, ed in parte la performance del sistema completo, ma da quando ho adottato una nuova prospettiva nel processo di sviluppo di GASdotto ho smesso di preoccuparmi particolarmente della cosa.

Sostanzialmente, in GASdotto il database e' la rappresentazione "uno a uno" degli oggetti maneggiati dall'applicazione, e tutte le interazioni con questi oggetti sono formalizzate secondo una manciata di regole.

Ad esempio: l'oggetto "Order" e' un ordine aperto presso un fornitore. All'interno della classe sono iscritte le proprieta' che compongono tale elemento. Sul database, c'e' una tabella che si chiama "Orders" (tipicamente le tabelle si chiamano nello stesso modo della classe di riferimento, ma ho dovuto fare una eccezione poiche' "order" e' una parola chiave di SQL) che riporta esattamente quelle stesse proprieta'. Dove l'oggetto ha una stringa, sul database c'e' un varchar. Dove c'e' un numero, corrisponde un intero. Dov'e' c'e' un riferimento ad un oggetto descritto da un'altra tabella, vi si trova la chiave esterna a quella tabella. Nel caso particolare delle relazioni "uno a molti" (ad esempio: i prodotti contemplati all'interno dell'ordine), si utilizza sempre una tabella di appoggio che si chiama "nomedellaclasse_nomedellattributo" e due colonne, una per l'entita' di riferimento (l'ordine) e l'altra per i sottoelementi (i prodotti).

Lo schema non e' per nulla ponderato o meditato: ogni informazione che serve e' memorizzata secondo una forma definita a priori, senza soffermarsi mai sul caso specifico.

Durante l'implementazione del supporto alle "varianti" dei prodotti in GASdotto 2.0 ho constatato come questo approccio sia facilmente adattabile: alla fine dell'opera mi son ritrovato con numerose nuove tabelle, ma per quanto complessa sia la relazione tra prodotto, variante, prodotto ordinato, varianti ordinate, prodotti consegnati eccetera, in breve sono riuscito a cavarne una definizione sempre coerente e non eccessivamente arzigogolata.

Il vantaggio maggiore di tale strategia e' che, essendo tutto maneggiato con poche regole sempre valide, il codice necessario alla serializzazione, deserializzazione, e reperimento e salvataggio delle informazioni e' unico in tutti i casi. Il guscio piazzato intorno al database e' ridotto a poco piu' dei minimi termini, una unica classe ("FromServer". Nome assai poco fantasioso...) provvede alla stragrande maggioranza del lavoro. Cosa non da poco, in termini di mantenibilita'.

Sicuramente lo schema finale non e' il piu' ottimizzato che si possa pensare, e non dubito che si potrebbe fare molto di meglio in termini di performance e risorse occupate, ma in fin dei conti la differenza non si nota. L'istanza nota piu' grossa di GASdotto conta attualmente 600 diversi prodotti da 30 diversi fornitori, il dump completo (e compresso con l'opzione -Ft di pg_dump) di PostgreSQL e' di quasi 1 megabyte, eppure il tutto pare sufficientemente reattivo ai 170 utenti registrati (a parte quando la componente Javascript inizia a macinare tutti quei dati in un colpo solo nel browser, ma e' un altro discorso).

Insomma: personalmente, ho smesso di dare tanto peso a come e' fatto il database di backend delle applicazioni. Quantomeno delle mie. Qualche microsecondo di elaborazione in piu' val bene tutta questa flessibilita' compressa in una cosi' modesta quantita' di codice.

Informazione Colorata

Nella oramai imminente release 2.0 di GASdotto (stando alla roadmap attuale dovrebbe essere rilasciata entro la fine di agosto) e' stato introdotto un nuovo pannello dedicato ai grafici: per mezzo della Google Visualization API, integrata in GWT, ho aggiunto qualche disegnino che rappresenta graficamente in forma di barre e torte il numero di utenti che hanno ordinato qualcosa presso un fornitore, a quanto ammonta la cifra totale degli ordini effettuati in un dato intervallo di tempo, e quali sono i prodotti piu' richiesti. Credo che sia venuto abbastanza bene, i grafici sono graziosi ed abbastanza ben leggibili.
L'altra sera ero a casa dell'amico che mi da una mano con lo sviluppo, o meglio che mi guida suggerendo features e migliorie: essendo uno dei responsabili di uno dei Gruppi di Acquisto piu' grossi di Torino, il quale gruppo e' peraltro il maggior fruitore "ufficiale" dell'applicazione, ha accesso ad una mole di dati immensa ed estremamente utile per effettuare test piu' che significativi sul software.
Ero a casa sua, dicevo, ed insieme a noi c'era un altro amico, anche lui all'interno dello stesso GAS, e stavamo contemplando lo stato attuale della piattaforma (il cui codice, seppur non rilasciato, e' accessibile a tutti dal repository SVN) su uno snapshot della base dati realmente utilizzata dal gruppo. Quando e' stato aperto il pannello delle statistiche, il grafico a torta rappresentante la spartizione dei quattrini tra i diversi fornitori visualizzava uno spicchio grosso quasi quanto un quarto del totale. "A chi diamo tutti questi soldi?", e' stata la reazione del nostro ospite. Ne e' emerso che, per un motivo o per l'altro, un singolo produttore (su circa 17) assorbiva appunto quasi un quarto delle attenzioni della combriccola, in evidente contrasto con quello che dovrebbe essere lo spirito di equita' e solidarieta' che anima questo genere di iniziative.
Tutto questo fior fior di aneddoto per ribadire qualcosa di non nuovo: una rappresentazione grafica che riassuma in un colpo solo una discreta quantita' di dati fornisce nozioni che sarebbero afferrabili solo analizzando molto attentamente i dati stessi, o per meglio dire nozioni che altrimenti a nessuno verrebbe mai in testa di analizzare.
Coloro che seguono Information is Beautiful, noto blog interamente dedicato agli infographics (nome altisonante per indicare l'arte di far grafici che siano anche belli da vedere), sanno bene a cosa mi riferisco: non e' raro trovarsi dinnanzi a pochi pixel colorati che spiegano una quantita' infinita di cose, cui magari non si e' mai pensato. Nel mio piccolo anche io ho iniziato recentemente ad esplorare questo particolare settore con l'esperienza di Masciap, blog in cui ogni settimana i dataset pubblicati sull'apposito portale della Regione Piemonte vengono tradotti in numeri e grafici, e nonostante la giovane eta' del progetto qualche considerazione significativa e' gia' saltata fuori.
Vorrei nel prossimo futuro includere grafici e tabelle in ogni posto dove sia possibile farlo (gia' tale genere di funzionalita' e' prevista nella roadmap a lungo termine di Maintainr, per riassumere il tempo dedicato ad ogni progetto gestito dal programma), in quanto essi sono un valore aggiunto di inestimabile valore: poche semplici barre possono drasticamente aiutare ad individuare situazioni anomale, e permettere all'utente di agire per correggere il tiro nei confronti dei suoi propri obiettivi, richiedendo del resto uno sforzo minimo da parte di chi implementa l'applicazione.

La Sindrome della Prima Volta

Quando l'altro giorno l'amico Gigi ha pubblicato un post menzionando, tra gli altri, il progetto GASdotto, mi sono posto il problema della visilita' di tale opera sull'Internet. Ed il pensiero si e' acuito quando l'altro giorno ho ricevuto una mail da parte di un certo "Alessandro" del GAS di Rimini, che ha spontaneamente aggiunto una menzione al programma nella pagina Wikipedia dedicata al tema e mi chiede informazioni per una piu' approfondita valutazione.
Sinora ho tentennato, in quanto il software e' in perenne stato di sviluppo e sebbene possa essere dichiarato stabile nuove correzioni ed aggiunte arrivano quasi ogni settimana, ma credo che sarebbe ora di iniziare a promuovere sul campo l'applicazione affinche' venga conosciuta ed eventualmente usata dal pubblico di riferimento, ovvero i Gruppi di Acquisto.
In realta' questa voglia di referenzialita' non deriva dal puro e semplice desiderio di veder usato il proprio software, comune a qualsiasi programmatore che produca qualcosa che si spera essere utile al prossimo, ma per il mio timore nei confronti di quella mai documentata ma ben nota tendenza ad estendere le delusioni personali a tutto cio' che anche solo vagamente concerne la sorgente stessa dell'originale malcontento.

Spiego meglio il concetto, facendo un passo indietro e riesaminando la storia vissuta.
Lo sviluppo di GASdotto e' stato avviato oramai piu' di un anno fa' a fronte della constatazione che l'unica alternativa allora esistente era un obrobrioso ed inusabile programma denominato GestiGAS, open e gratuito ma impossibile da usare ed inguardabile. Poiche' la prima preoccupazione dei miei "committenti", il GAS Roccafranca di Torino, era appunto la prospettiva di riuscire a far usare uno strumento tecnologicamente piu' avanzato dei documenti Excel sino a quel momento scambiati per posta elettronica senza pero' restare impantanati nella naturale e diffusa incompetenza informatica dei membri del gruppo, l'unica scelta e' stata quella di implementare tra noi quanto bastava per svolgere i compiti della combriccola. Da allora numerosi e consistenti progressi sono stati fatti, in termini di stabilita' e funzionalita' offerte, e da piu' di un testimone mi e' arrivata la conferma che tale gestionale sia immensamente piu' facile da usare del sopra menzionato "competitor".
Cio' non basta comunque a vincere l'impietoso gioco del pagerank Google, e se oggi eseguo una query come "software gruppo di acquisto" sul piu' usato dei search engine inevitabilmente tutti o quasi i risultati riconducono a GestiGAS, presente da molto piu' tempo e dunque con una ben piu' ricca e diffusa schiera di utilizzatori e commentatori. Posso immaginare che questa specifica ricerca sia gia' stata condotta da buona parte dei numerosissimi gruppi di acquisto che, stando ad un recente rapporto di Coldiretti, sono spuntati nell'italica penisola, e posso immaginare che molti di questi abbiano scaricato, installato e provato ad usare questo arnese con risultati non sempre positivi.
E veniamo finalmente al perche' di questo post, alla "sindrome della prima volta": arrivati a questo punto, di tutti coloro che hanno visto GestiGAS e ne sono rimasti delusi, quanti vorranno intraprendere una piu' accurata ricerca e tentare nuovamente di procedere alla non sempre banale operazione di installazione di un applicativo web sui loro server per vedere se c'e' qualcosa di meglio? E quanti invece saranno sconsolati ed adotteranno a loro volta l'antidiluviano meccanismo degli ordini via mail, certamente piu' immediato da mettere in opera ma perdendo cosi' l'opportunita' di snellire i processi del gruppo e migliorarne l'efficienza con guadagno di tutti?
Il fatto di aver fallito il primo approccio comporta una perdita di entusiasmo, la paura di vedere un'altra volta vani i propri sforzi, ed in questo come in altri casi il fatto di incappare in una soluzione sub-ottimale fa poco sperare di riuscire a trovarne una valida. Pertanto si preferisce lasciar perdere, ed arrangiarsi con il minimo dispendio di risorse possibile.

Ho gia' osservato lo stesso circolo vizioso di riduzione dello stimolo tecnologico in un ambito assai diverso ma conosciuto da molti miei lettori: l'adozione di Linux. Penso che qualunque utente Linux con sufficiente passione da aver mai parlato di tale sistema ad un amico o conoscente con l'obiettivo di generare interesse abbia ricevuto almeno una volta una risposta del tipo "L'ho gia' provato X anni fa', non funzionava niente, ci ho rinunciato". Non ha la benche' minima importanza il fatto che il software incluso nelle distribuzioni migliori ogni singolo anno (o anche ogni sei mesi), e fra tutte le piattaforme operative Linux abbia il piu' forte afflusso di correzioni e miglioramenti: e' gia' stato provato, e l'impegno di eseguire una nuova installazione (con tutto cio' che ne consegue: ripartizionare, defraggare la partizione Windows per evitare ogni rischio di perdersi dati, verificare il funzionamento dei drivers...) non controbilancia l'esperienza negativa passata.

Per quanto riguarda GASdotto, dietro consiglio della mia ragazza (che lavora per una agenzia di SEO) ho installato sul sito un modulo Drupal per arricchire le pagine con meta-tags descrittivi e strizzare l'occhio al crawler di Google, sebbene ritenga quella del "Search Engine Optimization" una arte voodoo che trascenda la logica e non sia eccessivamente speranzoso nei confronti di questa misura. Parallelamente, vedro' di confezionare la prossima release 1.1 nel piu' breve tempo possibile e metterla a disposizione di chi la vorra' scaricare, ed ancora meglio mi piacerebbe avviare nel prossimo futuro una sorta di campagna di "server sharing" per i GAS che non hanno competenze per mettere in opera un virtual private server ma che vogliano comunque usare codesto software.

Con tutto questo non voglio asserire che GASdotto sia a priori meglio di GestiGAS, e che dunque il fatto di scoprire per primo il mio progetto possa stravolgere l'opinione delle masse, ma il fatto di aver gia' ricevuto un discreto numero di giudizi comparativi volti a mio favore mi fa intuire che qualche risultato in piu' lo si possa ottenere. Per fornire strumenti efficienti a chi ha obiettivi importanti, per dare un supporto tecnologico ad una impresa comune.
La prima volta non si scorda mai. Meglio che sia positiva.