Intervista a Luca Garulli

Inizia questa nuova categoria di articoli su JavaStaff.com con un’intervista ad uno sviluppatore Java di Roma: Luca Garulli

Ciao Luca, cosa ci puoi dire di te?
Luca Garulli Ciao, ho 31 anni e vivo a Roma. Città che adoro e dove sono nato. La mia passione per l’informatica e la programmazione è iniziata quando avevo solo 10 anni e misi le mani su un Commodore 16 appena scartato dal mio vicino di casa il giorno della sua comunione. Fu amore a prima vista. Iniziai subito a fare i programmi proposti sul libro di istruzioni. Ancora oggi non so spiegare il perchè ma la programmazione mi affascinava. Le infinite ed estenuanti implorazioni di un bimbo verso sua madre riuscirono a regalarmi un Commodore 64 tutto mio. 8 bit che spremetti fino all’osso. Dopo qualche anno passai ad Amiga 500. Grande personal computer che non fu capito pienamente all’epoca. Fu lanciato come macchina da gioco ma come sistema operativo e usabilità era più avanti di qualsiasi cosa presente sul mercato. Pensa che aveva già un Multitasking preemptive. Bei ricordi!

Dove lavori attualmente?

Da poco più di un anno ricopro la posizione di Direttore Tecnico in Asset Data, una piccola società IT della capitale. Le cose vanno molto bene, ma quello che più conta per me è instaurare un modo di lavorare diverso da quello che si vede in giro. La maggior parte delle aziende IT italiane si limita a reclutare persone sul mercato per piazzarle dai vari clienti senza nessun valore aggiunto e per giunta abbandonate a loro stessi. Questo non è il nostro business, anche se a volte capita e cerchiamo di farlo nel migliore dei modi.

La nostra principale attività è fare prodotti e soluzioni finite utilizzando lo stato dell’arte della tecnologia. E’ per questo che ci avvaliamo di talenti: tutte persone che fanno della programmazione la loro passione. Ci piace sperimentare e investire sulla ricerca. A tal proposito abbiamo formato un consorzio di aziende e università europee per la ricerca sul Roma Meta Framework. Lo scopo del consorzio è quello di sviluppare plug-ins, documentazione e applicazioni basate su Roma. La Commissione Europea ci crede molto nel progetto e investirà parte dei suoi fondi all’iniziativa. Il Kick Off si terrà a Madrid tra pochi giorni! In Asset si respira un ambiente familiare fatto di tanto lavoro ma anche di partite a biliardo (ne abbiamo uno in sede), di pranzi luculliani (eh si, abbiamo anche una cucina!), di gare sui Kart e di rilasci frenetici della ennesima nuova versione di Roma Meta Framework su Source Forge.

Di quali progetti opensource ti sei occupato?

Togliendo le piccole contribuzioni sono essenzialmente due: Orient ODBMS e Roma Meta Framework. Entrambi ideati da me.

ROMA Framework è un framework interessante per lo sviluppo, vuoi farcene una presentazione?

Molto volentieri! Tutto è iniziato nel 2005, quando un’altra idea mi girava per la testa: perchè non progettare qualcosa che faciliti lo sviluppo sopratutto nelle parti più rognose e ripetitive? Parlo di persistenza, GUI, ecc. Chi non ha sbattuto la testa nella creazione e manutenzione di pagine HTML con decine di campi + qualche Kg di JavaScript, magari condito in salsa Ajax? Ah… ovviamente il tutto servito in ambiente multi-browser. Era il periodo dove subivo influenze DDD (Domain Driven Design) ed ero affascinato dalla promessa, mai mantenuta, dell’MDA (Model Driven Architecture). Cercando nell’iperspazio qualcosa che si avvicinasse alla mia idea non riuscì a trovare niente di concreto. In compenso, però, trovai molte idee e spunti da migliorare. Nacque cosi l’idea di Roma Meta Framework.

Innanzi tutto Roma è un progetto Open Source (licenza Apache 2.0) ed è ospitato su Source Forge. E’ un Meta Framework, ossia qualcosa che orchestra, integra e coordina altri framework. Se ci pensi oggi nel panorama Java ci sono centinaia di strumenti da poter integrare. E’ sicuramente una grande benedizione non dover reinventare la ruota e trovare qualcosa di già bello e fatto. Il problema, semmai, è che ce ne sono davvero tanti. Quale utilizzare? Qual’è il più performante? E quello più scalabile? Se investo risorse e denaro nell’apprendimento e nell’integrazione di uno di essi ne rimango vincolato per sempre? Queste sono alcuni dei dubbi più ricorrenti che infestano gli incubi degli Architetti e Programmatori Java. La risposta è appunto non vincolarsi con nessuno. Ossia parti dalla progettazione del dominio, unico vero patrimonio dell’applicativo, e lascia che Roma faccia il resto. Lo so detto così sembra fantascientifico se non utopistico. Ed era quello che pensavano molti miei ex-colleghi prima di vedere la demo di prototipo sviluppato in meno di un mese. Ad oggi è passato più di un anno e Roma è finalmente un prodotto maturo. Ci lavora un team di sviluppo di 9 persone, di cui 6 lavorano all’interno di AssetData e lo fanno quasi a tempo pieno. Esistono già più di una dozzina di plug-ins pronti all’uso per i bisogni più comuni: persistenza, presentation, i18n, reporting, modulo utenti e profilazione, messagistica/emails, workflow, editor grafico, monitoring JMX, ecc.

In Asset, ovviamente, lo utilizziamo per tutto e riusciamo a creare prototipi per il cliente in poche ore (applicazioni funzionanti con database e non semplici mockup!) e applicazioni finite in pochi giorni. Ovviamente dipende dall’entità del progetto. Questo ci da un vantaggio netto sulla concorrenza: siamo mediamente dalle 2 alle 10 volte più veloci di chiunque. Inoltre la bontà del codice è davvero alta in quanto consiste in POJO già separati in layer e svincolati da tutti i dettagli implementativi. Lo stesso discorso sulla produttività vale ovviamente anche per le altre realtà che utilizzano Roma (sono quasi 100 in tutto il mondo).

Orient ODBMS: cosa è, dove utilizzarlo?

Nel 1997 ebbi la pazza idea di scrivere una libreria di OR Mapping per il povero programmatore C++. L’idea di partire dal DB a progettare tutto e scrivere il mapping con gli oggetti mi stava stretta. Così dopo i primi esperimenti tirai fuori un prototipo con motore di persistenza annesso. Lo chiamai “Orient ODBMS”. Era un DBMS ad oggetti a tutti gli effetti, ossia un DBMS che non utilizza tabelle e record ma classi e oggetti. Per il motore utilizzai un mix di algoritmi presi da varie ricerche e tesi in giro per il mondo. Potenza di Internet.

Dai primi benchmark fui molto sorpreso dalle prestazioni: era fino a 100 volte più veloce del DBMS relazionale più diffuso sul mercato. Il grosso del lavoro è stato implementare il meccanismo adattivo di caching distribuito sui client copiato dalle architetture multi processore e da altri ODBMS presenti sul mercato. In seguito aderì allo standard ODMG e Orient fu la prima implementazione compliant con ODMG versione 3.0. Negli anni successivi dotai il motore di un mapping in Java utilizzando lo standard JDO 1.0 e una GUI in Swing. Il prodotto era commerciale e costava una frazione dei ODBMS commerciali. Vendetti un pò di licenze ma purtroppo il mercato degli ODBMS non esplose mai e il vecchio Relazionale continuava a mietere vittime tra i programmatori che mettevano in pratica l’Object Orientation. La lacuna fu parzialmente colmata dall’avvento dei OR Mapping che danno la sensazione di avere un ODBMS utilizzando, nella realtà, un comune RDBMS. Certo le prestazioni non potevano essere le stesse ma chi se ne preoccupa oggi? E’ lento? Ok, compra più RAM e cacha tutto. Ad oggi il progetto non è più portato avanti per mancanza di tempo e risorse. Le idee di sviluppo sarebbero tante, ma mancano i volontari. Anzi, se qualcuno è interessato si faccia avanti 🙂

Sei uno dei membri degli Expert Groups per JDO 1.0 e 2.0. Quali aspetti possono andare a favore di questa specifica rispetto ad altri framework per la gestione del database (Hibernate, iBatis etc. etc.)?

Reduce dall’esperienza con lo standard ODMG 3.0 entrai a far parte dell’Expert Group della Sun per quanto riguarda la JSR 12 (JDO 1.0) e dopo la JSR 243 (JDO 2.0). JDO nacque proprio dalle ceneri di ODMG 3.0 for Java. Anche qui fu un’esperienza molto interessante: contribuire alla definizione di uno standard per il mondo Java e nel frattempo rendere Orient una sua implementazione. Purtroppo per varie ragioni politiche JDO non conobbe mai il successo che meritava. Anche se attualmente la versione 2.0 è un super-set della JPA di EJB3 pochi lo utilizzano e ne apprezzano i vantaggi rispetto ai più blasonati Hibernate e JPA appunto. E pensare che Gavin King con il suo Hibernate entrò a far parte dell’Expert Group di JDO 1.0 ma per vari motivi si distaccò e continuò per la sua strada. Gli aneddoti da raccontare sarebbero tanti, cosi come le ipotesi di cospirazione da parte di SUN, ma alla fine è, e rimane, puro “Gossip IT”.

Tornando alla domanda posso dire che JDO 2.x è lo strumento più avanzato che esiste oggi sul mercato per la persistenza. Ops.. ho detto strumento ma volevo dire standard. Eggià perchè JDO è uno standard ed esistono una dozzina di implementazioni. Questo permette di utilizzare prodotti diversi senza modificare il codice dell’applicazione. La Reference Implementation è il buon JPOX, totalmente Open Source, giunto alla versione 1.2 che tra l’altro è anche JPA compliant. JDO 2 permette una gestione davvero trasparente ed ortogonale degli oggetti su database, mentre EJB JPA e Hibernate sono prodotti studiati esclusivamente come OR Mapping e quindi portano con sè il concetto di DBMS relazionale. Con JDO puoi usare come backend il filesystem, un database ad oggetti o il classico RDBMS. Inoltre rispetto alla concorrenza più blasonata permette un tuning più spinto. Parlo delle politiche multiple di fetching sul detaching degli oggetti che a volte ti cambiano la vita quando tiri su un nutrito grafo di oggetti connessi.

Come vedi la situazione dei tanti framework per lo sviluppatore Java?

Come dicevo prima è una grande benedizione fino a quando non si ha la responsabilità di sceglierne uno. Questa operazione in genere avviene incrociando le dita e sperando che il tool venga supportato per 100 anni dagli sviluppatori, che sia performante come affermava e sopratutto stabile. Se tutto va bene tocca sperare che i requisiti del cliente non cambino in modo così drastico da doverlo sostituire con qualcos’altro: sarebbe un bagno di sangue proprio perchè nella maggior parte dei casi i tool e framework più diffusi non aderiscono a nessuno standard, o semplicemente nessuno ha pensato a crearlo. Inoltre cambiando tecnologia, tool o framework che sia, parte del know-how diventa non riutilizzabile e tocca ricominciare a studiare l’ennesimo nuovo arrivato. L’obiettivo di Roma è quello di far diventare il tool/framework un dettaglio astraendone completamente o quasi il suo comportamento.

Oltre al lavoro, visti tutti i progetti in cui sei coinvolto attivamente, sembra che la programmazione sia anche un divertimento/hobby oppure no?

Lo è stata da quando avevo 10 anni, lo è tutt’ora e lo sarà sicuramente per molto. Proprio per questo sono contento della continua affermazione delle metodologie Agili perchè hanno finalmente polverizzato la figura del super-architetto-leva-le-mani-dal-codice in favore di un professionista con doti di management, di architettura e di…coder!

Ciao,

Lvc@

Link

Blog di Luca Garulli
Roma Framework
Orient Technologies
AssetData
JDO 1.0 – JSR 12
JDO 2.0 – JSR 243
JPOX

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *