Posts | 2007

29/10/07

Open Sourcing a Saturday Project

Alcune interessanti riflessioni sulla tematica dell’open-source: quando un progetto realizzato nel tempo libero può diventare un progetto open-source da proporre alla comunità degli sviluppatori?

Geertjan Wielenga, sviluppatore del NetBeans Team, racconta la sua esperienza spiegando i passi che hanno portato il suo JFugue Music NotePad (un editor musicale scritto utilizzando la NetBeans Platform e JFugue API, una potente API per la gestione dei file midi) a diventare un progetto open-source.

In sintesi, secondo la sua opinione occorre:

  • disporre di un progetto che abbia raggiungo almeno un certo livello di coerenza (ovvero che possa attrarre l’interesse di altri sviluppatori)
  • rilasciare un prototipo, anche non completo, alla comunità
  • attendere che qualcuno si interessi al progetto (nel frattempo lo sviluppo da parte dell’autore non si arresta)
  • se qualcuno si interessa al progetto ed ha una conoscenza specifica del dominio maggiore di quella dell’autore diviene “contributor”
  • altri utenti sono semplici utilizzatori, “observers”
  • negli anni il progetto può evolvere raggiungendo buoni livelli, addirittura oltre le aspettative dell’autore stesso!

Ecco l’articolo completo: http://www.javalobby.org/articles/sat-open-source/

10/10/07

Is Java ready for use in safety critical systems?

Java è nato come linguaggio general-pourpose, ma al giorno d’oggi il campo di utilizzo più vasto è sicuramente il Web/Enterprise. Che dire dei sistemi safety critical o cosiddetti real-time? Questo è storicamente il mondo delle applicazioni C++, ma qualcosa sta cambiando e anche Java sta per dire la sua. Un esempio? Le specifiche Real-Time per Java RTSJ e la loro relativa implementazione Java SE Real-Time Edition, o le implementazioni alternative (ed ottimizzate) delle classi Sun di base come Javolution o Joda rendono davvero realistica l’applicazione di Java nei contesti cosiddetti real-time.
L’articolo mette a confronto alcuni aspetti della programmazione C++ vs Java come:

  • Segmentation Fault vs Runtime Exception
  • Deallocazione della memoria vs Garbage Collection
  • Stabilità della piattaforma (open bugs)
  • Testabilità e scalabilità delle applicazioni (JVM multiple)

Molto interessante a mio giudizio, e l’attenzione dimostrata alla recente Space 2007 Conference sembrerebbe dimostrarlo…

27/09/07

7 Top Tips for Quality Java Software

Alcuni accorgimenti che possono rendere un programmatore più efficiente nello scrivere un codice di migliore qualità. Poche regole semplici, ma a mio parere azzeccate:

  1. Eliminare il codice non utilizzato
  2. Non documentare codice complesso, piuttosto scrivere codice semplice
  3. Non scrivere tanti commenti, ma migliorare il log
  4. Applicare la legge di Demeter per mantere il codice semplice
  5. Non ripetersi (non duplicare codice)
  6. Marcare volutamente le porzioni di codice incomplete
  7. Controllare le assunzioni nel codice (rilevare subito il fallimento)

L’articolo completo si trova al seguente indirizzo: http://www.javalobby.org/java/forums/t101755.html

25/06/07

Windows Vista vs Linux

L’acquisto di un nuovo pc portatile, immancabilmente corredato da Windows Vista, invoglia ormai sempre più utenti, specialmente quelli che utilizzano il pc in modo professionale, ad installare una distribuzione Linux e configurare il sistema in dual boot mode.

Io stesso mi sono comportato così: Windows Vista per gestire le applicazioni multimediali (soprattutto quelle che richiedono i driver più recenti), Linux per programmare e sviluppare in Java, più (almeno) una partizione dati condivisa.

Ormai esistono moltissime distribuzioni linux per il desktop, tutte molto valide e adatte ai vari sistemi, dai più moderni a quelli più datati. Ne segnalo alcune, scelte in base alla mia asperienza e alle mie preferenze personali:

Insomma ce n’è per ogni esigenza, esiste pure una piccolissima distro antagonista del Windows Media Center, la GeeXBox, forse ancora un po’ “acerba” ma sicuramente promettente. La comunità Linux è sempre più attiva e in crescita…

27/04/07

Are JSPs dead?

L’ennesima critica a JSP: sono da considerasi ufficialmente morte? Ehm… personalmente non credo che la loro scomparsa sarà poi così imminente. JSP fa parte delle specifiche JavaEE di Sun e ormai sono utilizzate praticamente in ogni contesto Java Web. E’ vero, consentono molta libertà in chi sviluppa (difatti sono nate come “antagoniste” di ASP!) e in pratica sono quanto di più “sbagliato” si possa utilizzare in un paradigma ad oggetti, ma per fortuna… esistono i framework!

Solito discorso: Struts in primis ha ricollocato le JSP quasi esclusivamente nello strato V del paradigma MVC (mentre il ruolo di controller è lasciato alle Servlet o meglio a Servlet specializzate dette Actions). Poi ci sono le taglib, gli include e JSTL… con questi strumenti JSP diventa utilizzabile e, addirittura, come qualcuno osserva, riusabile (anche se lo strato V è chiaramente il meno riusabile fra tutti). Il problema se mai è quello di non farne un uso improprio.

Poi è chiaro che le alternative esistono: Velocity, Freemarker, XML/XSLT, JSF (con Facelets) per citarne alcune. La mia personale esperienza con JSF non è stata delle più entusiasmanti, credo che siano ancora un po’ “acerbe” e tra le pecche, direi che hanno un pessimo livello di debugging.

Concludendo: JSP promosse, purchè usate con tutti i criteri. Consentono di essere molto produttivi, possono essere facilmente precompilate in Servlets e, entro certi limiti, possono essere riutilizzate. Il resto si trova nel post:

23/04/07

Why resist change to Java?

Con le versioni 5 e 6, Java ha introdotto diverse modifiche al linguaggio.
Oltre ai già noti (e a volte criticati) generics, boxing/outboxing, annotations, enums, static imports ora si parla di closures. In alcuni casi si tratta di zucchero sintattico o poco più, in altri casi di importanti modifiche al linguaggio, nel costante sforzo di rendere Java sempre competitivo nei confronti degli altri moderni linguaggi (C++, C#, Smalltalk, Ruby o Groovy…).

Ma ci sono anche delle “resistenze” ad accettare queste modifiche al linguaggio e spesso, come si osserva in questo post di TSS, sono proprio i “senior” a sembrare più restii ai cambiamenti. Forse per timore di perdere quel vantaggio che hanno acquisito con anni di esperienza, i senior sembrano in qualche modo spaventati dalle novità o semplificazioni recentemente introdotte nel linguaggio. Ma quel che spaventa di più forse è l’incompatibilità dei binari generati e così molti “preferiscono” ancora lo stile 1.4.

L’aspetto che mi sembra più interessante tuttavia è la possibilità di poter utilizzare altri linguaggi nella JVM come JRuby o Groovy ad esempio, il che rende meno “indispensabili” le continue estensioni del linguaggio Java vero e proprio. Non dimentichiamo infatti che Java è molto di più di un linguaggio: è una VM, un insieme di librerie ed API molto ricche, un mondo di framework open-source e molto altro… l’articolo è interessante e offre diversi spunti…

16/03/07

Revision of history and J2EE

Ancora una volta si parla di J2EE vs Spring, ovvero di “heavyweight” vs “lightweight”, ovvero di Sun vs mondo open in senso più stretto. Secondo l’opinione ormai diffusa, viene associato un concetto di pesantezza allo standard J2EE (o JavaEE che dir si voglia).

Ma occorre fare un po’ di chiarezza. Stiamo parlando di due tecnologie (J2EE e Spring) quindi un punto è certamente vero: prima di tutto è una questione di scelta. Non esiste tecnologia vincente in assenza di un buon software architect e la scelta di quale tecnologia adottare dipende anche (e soprattutto) dal team di sviluppatori di cui si dispone.

Tutte le tecnologie richiedono una “learning curve” iniziale, ovvero un certo costo per l’apprendimento. Disponendo di programmatori Junior ad esempio l’approccio di Spring, POJO-oriented, è in qualche modo più immediato. Ma ciò non toglie che Spring sia comunque molto ricco e che occorre molto tempo per “dominare” tutte le tecnologie e i concetti in esso contenuti. Per contro J2EE costringe lo sviluppatore a conoscere abbastanza bene i dettagli del container (ad esempio il ciclo di vita degli EJB) e per tanto richiede sviluppatori più esperti.

In ogni caso non bisogna dimenticare che J2EE non è solo EJB ma anche altre importanti API come JTA, JMS and JMX. D’altra parte Spring sposa ovviamente le tecnologie open, come Hibernate, JDO per la persistenza o Burlan e Hessian per le comunicazioni remote.

Ma dato che lo sviluppo di un’applicazione web “vera” può richiedere ad esempio l’utilizzo di Struts/Spring/Hibernate o JSF/Spring/Hibernate o Struts/EJB perchè non unire il meglio delle varie tecnologie? Spring + JMS, JMX and JTA?
Insomma, meglio collaborare che farsi la guerra 🙂

16/01/07

Spring 2.0 Intro

Un’ottima introduzione a Spring 2.0, l’attuale release di quel che è, ad oggi, probabilmente il miglior Framework open-source disponibilile in ambito Java… molto ricco, completo, configurabile, estensibile e soprattutto a differenza di molti altri non destinato solo allo sviluppo di web applications. Quantomeno da provare…