Jso

Dopo quasi due anni di attesa dall’uscita dell’ottima PCLinuxOS 2007, finalmente la nuova release!

Ho effettuato da poco l’upgrade ed è andato tutto liscio 🙂 Del resto, PCLinuxOS nasce come rolling distribution, ovvero come una distro con aggiornamenti continui (via Synaptic) pertanto l’upgrade dalla 2007 alla 2009 in realtà non è un cambio di versione vero e proprio (a parte i nuovi splash screen e alcune modifiche al tema grafico). In pratica eseguendo costantemente gli upgrades il sistema evolve di continuo. E questa è una delle caratteristiche che due anni fa mi ha fatto scegliere proprio questa distro per il mio laptop. Ne riassumo di seguito i principali punti di forza:

• stabilità: PCLinuxOS è una distro abbastanza “conservativa”, nota per essere molto stabile. Nel ciclo di aggiornamenti ho intallato anche la beta1 e la beta2 e anche queste si sono rivelate decisamente stabili!
• semplicità: è una live che si installa e configura davvero in una ventina di minuti
• performance: secondo alcuni test PCLinuxOS 2007 era seconda solo a sidux in quanto a performance. Verosimilmente anche la 2009 lo sarà
• è basata su KDE, il window manager che preferisco (ma esistono “remaster” con Gnome/Xfce/Enlightment…)
• è possibile creare appunto dei “remaster”, ovvero delle nuove distribuzioni, generando una live distro a partire dalla propria installazione. Infatti esistono diverse distro derivate da PCLinuxOS
• unisce “the best of two world”: ad esempio molto comodo è il Control Center derivato da Mandriva, come pure Synaptic per la gestione dei pacchetti rpm derivato da Debian
• i repository sono piuttosto aggiornati: abilitando la sezione “nonfree” si ha accesso anche ai codec, font o driver non strettamente open-source. Quando non si può fare a meno è sicuramente comodo

E da ultimo, ma non ultimo, basta dire che si tratta di Linux. Perciò una distro è solo una base di partenza, e una volta installata la si può personalizare come si vuole 🙂

L’anno 2008 che si è appena concluso rappresenta secondo molti l’anno  della consacrazione di Linux. Una serie di eventi tra cui il lancio tanto contestato di Windows Vista hanno spinto molti utenti a migrare da Windows verso altre piattaforme (Linux, Mac OS X). Personalmente ho sempre utilizzato Linux (affiancandolo a Windows), soprattutto in ambito server. Ma da ormai un paio di anni ritengo che sia maturo anche per il desktop. Stabile, efficiente, performante, con un supporto dell’hardware decisamente migliorato e una ricca dotazione di software, ormai è piuttosto facilile da usare e installare.

Quest’articolo di Distrowatch ne ripercorre la storia a partire dagli arbori nel 1991 quando la prima versione del kernel venne scritta da Linus Torvalds, passando per le principali distribuzioni che ne hanno decretato il successo come Slackware, Debian, Red Hat, SuSE fino a Mandriva, Ubuntu e Fedora (o PCLinuxOS) e via dicendo…
Quindi si parla delle applicazioni Desktop che con KDE o Gnome non hanno ormai nulla da invidiare a Windows o Mac OS X fino all’ambiente mobile, nuovo traguardo recentemente raggiunto da Linux ad esempio con il celebre Google Android. E a mio modo di vedere siamo solo l’inizio…

Leggi anche l’articolo completo.

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 🙂

• http://www.cmsmatrix.org/

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…

Leggi anche l’articolo originale.

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…

Leggi anche l’articolo originale.

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 🙂

Leggi anche gli articoli originali: 1, 2 e 3