Posts | 2008

14/06/08

CMS war… finding the right one

Il problema di trovare un buon cms open-source mi ha sempre affascinato. La gestione dei contenuti (e dei documenti) ad oggi è un problema tutt’altro che nuovo. In rete si trovano davvero centinaia, se non migliaia di alternative sviluppate sulla piattafoma LAMP, piuttosto che in Python, Java o .NET e c’è anche un sito che si è preso la briga di catalogarle e confrontarle (quasi) tutte. Ma in tutta questa varietà come si fa ad orientarsi? E perchè tante alternative? E come mai la scelta vincente è spesso il php, tantochè addirittura molti portali che trattano di Java si basano proprio su cms php?

Le alternative sono molteplici ma tra tutte sembrano proprio Mambo, Joomla e Drupal a suscitare il maggiore interesse nella comunity. Perchè sono in effetti davvero facili da usare, user-friendly e potenti al tempo stesso. Richiedono una semplice installazione, c’è una ricchissima dotazione di plugin e il costo di hosting e gestione in molti casi è davvero ridicolo.

Più complesse le soluzioni Java (Alfresco, Magnolia per citarne alcune) che richiedono risorse e tempi di startup più consistenti. Inoltre questi cms sono più orientati alla gestione documentale piuttosto che alla gestione/publicazione dei contenuti sul web. Anche Plone (basato su Python/Zope) richiede competenze maggiori ed è giustificato generalmente in contesti Enterprise.

Alcune alternative che ho trovato interessanti perchè ben si avvicinano ai cms php ma offrono alcune caratteristiche enterprise proprie di Java (supporto multi-db, clustering, versioning, chiara separazione e riuso dei contenuti rispetto alla presentation logic, livelli di autorizzazione sul singolo componente, esportazione dei contenuti in formato xml…) sono dotCMS e OpenCms. Tra l’altro dotCMS è costruito su LifeRay probabilmente il più promettente e potente portlet container sviluppato in Java, che come Riot offre una sorta di framework (c’è da stupirsi?) per lo sviluppo di portali Java. Molti interessanti, se non altro perchè utilizzano al loro interno il meglio della tecnologia Java attualmente disponibile 🙂

22/05/08

Making Java Easier

Ancora una volta si parla della “complessità” di Java, di quella learning curve iniziale che è richiesta a chi si accosta per la prima volta alla tecnologia. E che in genere spaventa, alimentando il mito secondo il quale Java è “difficile”. Non tanto per il linguaggio in sè o per le API (che in alcuni casi risultano a dire il vero un po’ ostiche, si pensi al Calendar o a java.awt.* per fare esempi noti) ma quanto piuttosto per tutto ciò che a Java sta attorno (frameworks, application server, J2EE e via dicendo).

La precisazione è ancora una volta il “target”: Java è pensato per grandi progetti enterprise, portabili, robusti e scalabili. Che non è certo il target di PHP, Ruby o ASP di cui (a volte) si “invidia” la semplicità. Nel dettaglio alcuni punti e alcune risposte:

  • Sistema di deployment: la struttura di JAR/WAR/EAR non è particolarmente immediata, e per piccoli progetti manca la comodità di deployare la singola classe, servlet o JSP (vero in parte). Questa struttura a mio avviso continua a rimanere molto buona per i progetti enterprise
  • Ricaricamento dinamico delle classi: questo sarebbe molto utile, senza il bisogno di effettuare ogni volta il deploy completo dell’applicazione che può richiedere anche molto tempo. Qui una risposta (almeno parziale) al problema c’è già: JavaRebel
  • Una GUI console: non ne esiste una comune ai vari Application Server che consenta di configurare tutto ciò che serve, DataSources, EJB, JNDI, parametri della JRE… data la varietà manca un approccio univoco, però ci sono varie alternative. Ad esempio l’ottimo LambdaProbe per Tomcat (che sostituisce la console nativa, piuttosto scarna invece)
  • Una GUI visuale integrata con le IDE: è sempre stato un punto dolente di Java, ora con Netbeans/Glassfish, Sun ha fatto sicuramente un buon lavoro. Il deploy su altri application server invece risulta ancora abbastanza difficoltoso. E’ inoltre in corso un porting su Eclipse.

Altre risposte a questi quesiti? ProjectZero, Groovy/Grails, Ruby/Scala, OSGi su Glashfish v3…

29/04/08

Open EJB 3.0

Da poco è stata rilasciata da parte di Apache SF un’implementazione leggera delle specifiche EJB 3.0: ciò significa che può essere utilizzata, ad esempio, all’interno di Tomcat, JUnit, TestNG, Eclipse, IntelliJ, Maven, Ant, ogni altra IDE o applicazione Java.

Con l’avvento di Open EJB e Open JPA potremmo finalmente dire addio ai vecchi e pesanti application server in virtù della costante crescita di quelli più “lightweighted” e open source? Magari ancora no, ma è sicuramente un ottimo inizio…

18/04/08

Java, LAMP, .NET…

Allo stato attuale chi vince la “battaglia del web”? E chi ha più chanches per il futuro?
A mio modo di vedere (e in questo condivido gli articoli) bisogna fare distinzione in base al “target”: un conto è il sito web per uso personale, un conto è il blog per il social networking, un conto è il portale basato su CMS, diversa ancora è l’applicazione Enterprise (CRM, ERP, reporting, document management…) che utilizza il web solo come strato di presentation. I contendenti? Java, LAMP, .NET, RoR, Grails e la lista potrebbe proseguire…

Alcuni aspetti secondo me sono essenziali:

  • LAMP e RoR hanno dalla loro parte la facilità d’uso e l’immediatezza; PHP ad esempio é una soluzione C-based. L’approccio è quello di un processo per ogni richiesta differente. Ciò porta a notevole efficienza nelle performances. La facilità nel linguaggio deriva dal fatto che sono orientati allo “scripting” (ma supportano il paradigma OO)
  • Java si basa sul concetto di Virtual Machine (thread piuttosto che processi), non nasce per il web ma aggiunge il supporto web tramite il J2EE e numerosi frameworks: JSF, Struts, Spring MVC… la scelta è vasta è richiede un lungo tempo di apprendimento. I benefici si vedono nelle applicazioni di grandi dimensioni, nella sicurezza, nella portabilità, nell’interoperabilità, nel design…
  • .NET rappresenta una scelta più “organizzata” in quanto alla base vi è un unico produttore. L’approccio della VM nasce con Java nel 1996, .NET lo fa suo in tempi più recenti e sviluppa un buon framework con numerosi componenti (in Java invece le scelte sono molteplici e possono essere anche disorientanti!) che in alcuni casi nascono evidentemente dall’esperienza Java (NHibernate, log4net…)

Alla luce di queste considerazioni non deve stupire più di tanto che quindi molti siti (portali) che promuovano prodotti Java come TheServerSide, JavaLobby o Spring siano sviluppati usando Drupal ovvero un CMS PHP! Oppure che il portale TheServerSide.NET (versione di TheServerSide per il mondo .NET) non sia scritto in .NET 🙂
Per approfondire:

05/03/08

Agile Software Development…

Le Metodologie Agili stanno facendo molto parlare di sè. Recenti sondaggi dimostrano come la popolarita di queste metodologie (XP, Scrum, TDD) dal 2005 ad oggi sia costantemente in ascesa. Ma in quali contesti reali queste metodologie sono applicate con successo? Ovvero.. in quali contesti rappresentano un reale vantaggio (anche economico!) nello sviluppo? Secondo alcuni se il beneficio derivante dall’adozione di queste metodologie era decisamente “sottostimato” fino a qualche anno fa, ora probabilmente è addirittura “sovrasimato”.

E’ sicuramente vero che non si può certo pretendere di ridurre il tutto ad una semplice metodologia, impacchettarla, infiocchetterla ed inserirla in azienda sperando che tutto magicamente funzioni… la vera potenza di tutta la metodologia è il team, ovvero le persone che lo compongono. Ad oggi ci sono aziende che pretendono di essere agili, senza implementare l’essenza dell’approccio. Il consiglio è quello di essere “pratici” e di non accettare la metodologia come un credo religioso ma di utilizzarla sempre con spirito critico. Un esempio:

  • Status Meeting – un incontro mattutino ed una mail serale di riscontro
  • Short Iterations – mantenere i cicli di sviluppo semplici e brevi ed espandere secondo necessità
  • Continuous Integration – test JUnit automatici e altamente parallelizzati
  • Minimal Documentation – può bastare Javadoc…
  • Team Collaboration Tools – wiki e Jira tickets…
  • Strict Coding Guidelines – uniformità nello stile, naming, spacing…
  • Constant Code Reviews – controllare ogni riga di codice che va in produzione!
  • Pair Programming – scegliere oculatamente l’accostamento tra i 2 developers (rotazioni)
  • TDD – nella forma “pura” rischia di essere troppo oneroso, si può valutare un compromesso…

Per approfondimenti:

07/02/08

Web Application: To couple or Not to couple?

Ancora a proposito di web framework… discorso inflazionato è vero ma a quanto pare tutt’altro che concluso! Il topic in questo caso è se in una web application sia meglio codificare tutto in una action oppure separare nettamente la web logic dalla business logic. La risposta parrebbe ovvia, ma non tutti sono dello stesso avviso.
Si possono catalogare fondamentalmente 4 approcci:

  1. Due classi: 1 action basata (*) sul framework e 1 business logic non basata sul framework
  2. Due classi: 1 action non basata sul framework e 1 business logic non basata sul framework
  3. Una classe: action e business logic nella stessa classe basata sul framework
  4. Una classe: action e business logic nella stessa classe non basata sul framework
    (*) si legga “che estende classi del framework”

Tra tutte l’approccio preferito è sicuramente il numero 1, la 2 rappresenta il totale disaccoppiamento (ad esempio in Struts 2 / Webwork le azioni possono essere POJO e quindi totalmente disaccoppiate dal framework), mentre 3 e 4 sono generalmente considerate bad practise. Esistono sicuramente buone ragioni per disaccoppiare la business logic dalla action:

  • Testability: se disaccopiata la business logic può essere testata in maniera indipendente (es. JUnit)
  • Web services: la business logic può essere utilizzata in un web-service o in servizi remoti
  • Caching: riferito alle business facades

Mentawai (un framework ad approccio programmatico con supporto per l’injection di cui esiste anche una versione Ruby) sembra offrire la libertà sufficiente per implementare tutti gli approcci (1,2,3,4). A voi la scelta…

07/02/08

Introducing Apache Wicket

Una lunga discussione sull’ennessimo web framework, Apache Wicket che viene qui paragonato al “fratello” Apache Tapestry, con divagazioni su JSF, GWT e sull’onnipresente Struts ovviamente. Tra i suoi punti di forza e innovazioni rispetto agli altri web framework vi sono:

  • Un eccellente supporto built-in ad AJAX;
  • La capacità di modificare la struttura delle pagine programmaticamente;
  • Perfetta separazione tra codice e templates (i templates non possono contenere codice);
  • Un approccio object-oriented
  • Facile apprendimento (per developers Java-oriented)

Naturalmente ci sono pro e contro, come in ogni cosa. Ma la principale ragione dell’esistenza di Wicket è che non esistono altri web framework programmabili in puro codice Java (quasi tutti seguono piuttosto il classico modello dichiarativo, con file di configurazione XML ad esempio). Naturalmente poi è anche questione di gusti, ma gli impatti più evidenti si hanno nell’ottimizzazione e nella versatilità del codice. In ogni caso anche Wicket, come pure Tapestry, Freemarker, JSF (con Facelets) e gli altri framework component-oriented rappresenta una valida alternativa ai precedenti framework Model 2 tipo Struts, tanto per citarne uno famoso 🙂