Avere una roadmap, delle linee guida, è senza dubbio importante per realizzare qualsiasi progetto che sia più complesso di “hello, world” (o delle classi Treno e Vagone, vero, compagni informatici della Bicocca?). Il documento in questione può assumere numerose forme: un albero completamente astratto e presente nella testa del progettista, una serie di grafi e schemi su carta o un documento elettronico.

L’ultima forma ha degli evidenti vantaggi sulle prime due. Innanzitutto, esiste fisicamente; inoltre vi si possono memorizzare più cose di quelle che qualcuno possa tenere a mente (a meno che la persona sia un genio, o un folle). Infine, un documento elettronico presenta alcuni vantaggi:

1. Può essere modificato più e più volte, a piacimento, senza per questo diventare un impiastro illeggibile. Anche scrivendo a matita (il che comunque è un ottimo consiglio), il foglio può rovinarsi o perdersi;
2. Può essere istantaneamente copiato e reso disponibile ovunque con un clic. Usando strumenti come Google Documents, inoltre, è possibile collaborare alla stesura e all’aggiornamento della roadmap allo stesso modo in cui si scriverebbe a più mani su un foglio di carta, senza per questo dover essere nello stesso luogo;
3. E’ leggibile! Sembra banale, ma diventa un requisito indispensabile se si è dotati di una scrittura illeggibile come la mia. In questi giorni, a lavoro, mi è stato chiesto di stendere una sintesi dei lavori attuali della società, sottintendendo di scriverla a mano. Inorridisco al solo pensiero. No, no.

Che una roadmap elettronica (o foglio di specifiche, o To-Do list) sia indispensabile per progetti dalle migliaia di righe di codice in su è appurato, ma penso sia quasi indispensabile anche per progetti più semplici e anche se chi li fa pensa “Ho le idee ben chiare, il progetto è tutto nella mia testa e in questi 20 fogli sparsi di schemi”. Perchè i progetti non sono perfetti, cambiano, si evolvono, devono essere modificati ed eventualmente condivisi. Se poi il lavoro non è l’unico da fare in quel periodo, si rischia di cadere nella palude dell’incertezza di percorso: senza un path di sviluppo definito a priori, non ci si ricorda letteralmente più cosa c’è da fare in un dato momento.

Parlo per esperienza. Senza un documento elettronico di percorso, anche se provvisto di molti schemi (molti dei quali superati), mi bloccavo ogni volta che riprendevo in mano il gestionale per caselle di fumetteria. Che avevo fatto fino a quel momento? Può anche darsi che io sia carente di sonno (accidenti agli Steam Weekend Deal), svogliato o quant’altro. Niente di più facile. Ma se anche fosse così, non sarò né il primo né l’ultimo.

Insomma, a chi gestice più di un progetto (anche piccoli) do questo consiglio: scrivete una roadmap o documento di progettazione elettronici, o perlomeno a matita. Vi permetterà di risparmiare molto tempo, anche se potrebbe sembrare una perdita di tempo all’inizio. Anche, datevi tempi ragionevolmente regolari e stretti per organizzare il vostro progetto “libero” con il lavoro fisso (o con gli altri progetti) e con il tempo di svago.

Procedendo nella mia conoscenza e nei lavori con Java, specialmente il progetto di gestione delle caselle, mi sono trovato nella necessità di dover usare un database che si interfacciasse con il linguaggio ed Eclipse.

Dapprima, ho usato MySQL, che non ha bisogno di presentazioni. Ma, specialmente nella seconda iterazione del progetto (sarebbe a dire, archiviare quel poco che avevo fatto e ricominciare da capo), mi sono accorto che usare un DB così complesso e mastodontico sarebbe stato, come dicono gli americani, overkill; ed è uno dei più leggeri tra quelli di largo uso!

Così, ho rivolto la mia attenzione verso i database embedded. Ne esistono di vario tipo, forme e dimensioni, tutti accomunati dall’aver bisogno di un solo driver che il motore di persistenza della vostra applicazione (o Eclipse) deve trovare per connettersi ad un database.

Dovrei dire a questo punto che io, fino a due settimane fa al massimo, sapevo poco o niente di queste cose. Soprattutto di quelle parole, “motore di persistenza”: la persistenza, in questo caso, si riferisce alla trasformazione (qualcosa di mistico?) tra un oggetto Java caricato nella JVM (e quindi in memoria) e una riga, o un insieme di righe, in una tabella di un database, nella maggior parte dei casi saldamente ancorato al disco fisso. Sapevo anche cos’è un database, naturalmente, e quel poco di SQL che mi ha permesso di non cominciare da zero con le query al lavoro (ma che ho già molto migliorato. Le SELECT innestate sono un gran divertimento, vero?).

Come motore di persistenza, ho da subito scelto JPA, per l’ottimo tutorial fornito dalla SUN, che raccomando. Il motore di persistenza è quello che si occupa di trasferire certi comandi da oggetti Java (tra cui find(), persist(), merge(), remove()) alle rispettive query SQL (in questo caso SELECT, INSERT, UPDATE, DELETE). Ricordando che in informatica si parla più che altro per astrazioni, non deve stupire sapere che ci sono più implementazioni di uno stesso motore di persistenza. Queste, per supportare un qualche database, devono conoscere il necessario dialetto (o sottoinsieme) del linguaggio SQL, che, ahimé, non è così uno standard come il suo nome potrebbe suggerire. Dopo un tentativo andato a vuoto con EclipseLink, ho scelto Oracle Toplink Essentials, sempre perchè ben documentato nel tutorial.

A questo punto, il primo database a cui ho rivolto la mia attenzione è stato SQLite. Nome accattivante, piccole dimensioni, documentato: sembrava che avessi trovato ciò che faceva al caso mio, ma al primo tentativo di persistere qualche oggetto mi sono trovato davanti ad errori nella sintassi SQL su query generate da JPA e, quindi, presumibilmente giuste. Il problema era un altro: Toplink non implementa il subset SQL necessario a SQLite (che tra l’altro, come ho imparato più tardi, è in qualche modo limitato) e, perciò, sbaglia. In seguito, sono tornato alle buone abitudini che non sbagliano mai: fare ciò che c’è scritto nei tutorial, prima di lanciarsi nell’ignoto; un po’ come le ricette per torte, che finiscono in catastrofe quando non le seguo. Per cui, sono passato ad Apache Derby Embedded: leggero, ugualmente facile da installare e soprattutto, riconosciuto da Toplink.

Il divertimento maggiore è stato (ed è ancora) definire il mapping tra entità nel database e POJOs, semplici oggetti Java. Questo può avvenire in due modi: mediante annotazioni direttamente sul codice, o mediante il file orm.xml, da inserire nella root del progetto. (Per inciso, questo, come il resto di JPA, fa parte della specifica EJB 3.0, con cui avrò a che fare anche per lavoro). Le annotazioni mi sono sembrate più semplici, per cui le ho scelte. Tutto ciò che si deve fare per definire una classe come entità è aggiungere @Entity prima della definizione di classe; per definire nome e altre proprietà, come vincoli di unicità, in una tabella, si usa l’annotazione @Table(...) e così via. Rimando alla lista completa delle annotazioni Toplink per ulteriori approfondimenti.

Dopo qualche perplessità, sono riuscito a sistemare tutte le dipendenze dal mio progetto e a persistere le mie prime tabelle. Tutto il resto è buona progettazione del database, che oltre ad essere dannatamente complicata, è una storia del tutto diversa.

Ricapitolando:

• Per un’applicazione Java 2 SE che necessiti di salvare POJO‘s (Plain Old Java Objects) su un database, sviluppata sotto Eclipse con motore JPA, ho trovato utili TopLink e il database Derby.
• Toplink è parte del bundle GlassFish: TopLink Essentials è scaricabile dalla pagina di download dell’implementazione di riferimento, il primo nella tabella chiamata GlassFish v2.1 branch. Eseguire il comando suggerito nella pagina porterà ad avere una directory con alcuni jar. Il file da includere è toplink-essentials.jar .
• Derby è scaricabile dalla pagina di download del progetto. Il file .zip contiene una serie di jar, il file da includere per un’applicazione desktop che necessiti del solo DB è lib/derby.jar .
• Ricordare note di copyright e licenze! Anche se entrambe le librerie sono open source, è comunque necessario includere le originali licenze.
• Nel dubbio, seguire i tutorial. Se non aiutano, seguire una delle leggi fondamentali di Internet: qualcuno ha già avuto il tuo stesso problema. Qualcuno lo ha già risolto.

Buona persistenza a tutti.

Ho da poco trovato lavoro presso il Centro Cardiologico Monzino di San Donato, Milano, alle dipendenze della Anemos S.r.l., fornitore di software sanitario a norma internazionale per questo e altri ospedali in tutta Italia. Un ottimo risultato, considerando che mi sono laureato da poco.

San Donato è a più di 50 Km da casa mia. Devo prendere treno, metropolitana, bus, in quest’ordine. Non ho orari proibitivi per fortuna, ma lo stesso sono in viaggio per non meno di due ore, con uno scarto di 5 minuti, per andare e tornare; in tutto, perdo 4 ore al giorno su una giornata lavorativa di 8 ore (includendo la pausa, il contratto a progetto mi permette una certa flessibilità negli orari, nei limiti della decenza ovviamente).

Quattro ore sono tante. Potrei usarne anche una parte (la metà, ad esempio) per rilassarmi, dedicarmi ai miei hobby, cominciare prima la mattina e uscire prima il pomeriggio, ponderare altri progetti, ad esempio un sistema di gestione delle caselle dei fumetti che il gestore della maggiore fumetteria lecchese mi ha chiesto di elaborare.

Il linguaggio Java, con gli strumenti giusti, permette di essere veloci come un treno (o una metropolitana) anche se, come un treno, va solo sui suoi binari. A confronto, un linguaggio come C è un fuoristrada, che però a volte è costretto a procedere più lentamente su terreno insidioso (rogue pointers, vale a dire puntatori “ribelli”, gestione dinamica della memoria). E’ più facile, diciamo. Java mi accompagnerà in questi tempi di pendolarismo, sia al lavoro che fuori; anche se per ora mi “limito” allo studio di infinite specifiche sul protocollo HL7 e sull’integrazione di un sistema sanitario con il SISS Lombardia.

Qual è la ricompensa che chiedo dalla vita per il periodo in cui sono appena entrato? Una conoscenza più approfondita e pratica della programmazione a oggetti, delle fasi dello sviluppo in generale, nonché delle tecnologie particolari che userò. Solo allora sarà un periodo speso bene.

Ricordate sempre, quando sentite di entrare in una fase impegnativa della vostra vita, di stabilire bene qual è la parte che alla fine vi spetta: una specie di contratto con la vostra stessa vita. E via col treno.