lunedì 10 dicembre 2007

Adesso é Natale


Adesso é Natale, inserito originariamente da Pietro Bonanno.

Oggi è una bella giornata: abbiamo ricevuto il libro ordinato nientepopodimeno che il 30/01/2007, direttamente dal sito Manning.
Per la nostra esperienza, mai più: ho scritto diverse volte all'assistenza e non ho mai ricevuto risposta. Credo sia giunto a destinazione con una tecnica simile alla consegna della posta GMail

lunedì 26 novembre 2007

Work-trash-pop art


Work-trash-pop art, inserito originariamente da Pietro Bonanno.

L'altro giorno rovesciai per errore il cestino dei rifiuti. Il tutto mi sembrò assumere un disegno, una certa perfezione. Come se avessi completato un quadro aggiungendo l'ultimo ritocco, così ho deciso di immortalarlo.
Nessun animale è stato maltrattato durante le riprese.


PS: Per i curiosi, l'immagine su Flickr è zeppa di note...

martedì 13 novembre 2007

Strano ma vero

Se vi capite di aprire un video e vederlo capovolto, non girate il monitor, né guardatelo a testa in giù. Semplicemente scaricate l'ultima versione di ffdshow e fategli gestire i formati DivX (Video configuration>Codecs>alle voci DivX il valore va cambiato in libavcodec).
Se vi funziona, accettatelo per fede come ho fatto io.

giovedì 8 novembre 2007

Alla ricerca del Santo Graal - Reprise

Riprendo un argomento che mi interessa molto, e su cui sto facendo un bel pò di ricerche. Chiunque usi Java per realizzare applicazioni web vi dirà che attualmente non esiste Lo Strumento. Esistono decine (sul serio) di framework, e anche filtrando per stabilità, supporto e dimensioni della comunità ne rimangono almeno una decina: Struts, Struts 2 (che è molto diverso), Stripes, RIFE, Click, Tapestry, Echo2, Thinwire, Grails, GWT, ZK, Sitemesh, Cocoon, JSF e sicuramente ne sto dimenticando qualche altro.

Leggendo un pò, ho capito che esistono principalmente due modelli: il classico, celebre, inossidabile MVC (o Model 2) detto anche Action Oriented e il Page Oriented/Component Oriented.
Il commento a una domanda postata su TheServerSide è una dei migliori e più precisi riassunti che abbia letto su questo argomento.

Io paragono il modello MVC a un approccio procedurale del problema: si individuano i flussi dei dati e si realizzano, nei controller, i metodi che li eseguono. Magari poi il modello, i controller eccetera sono realizzati col paradigma OO, però il flusso dell'applicazione è governato dalle action, ovvero da procedure in senso lato.
Il modello Page/Component Oriented invece lo paragono ad un approccio ad oggetti: ogni pagina web è un'oggetto, ha dei metodi ed è essa stessa a governare l'applicazione in base ai metodi invocati (attraverso l'URL).
E la differenza, a mio parere, è analoga a quella tra i due paradigmi di programmazione: il modello MVC (procedurale) è immediato da capire e da imparare, si comporta bene quando l'applicazione è governata da flussi di dati (per esempio l'acquisto di un e-ticket), ma mostra i suoi limiti all'aumentare della complessità del problema. Ad un certo punto diventa ingovernabile.
Il modello Page Oriented, come l'OOP, invece è arduo da governare, richiede una revisione dei processi mentali con cui immaginiamo la soluzione a un problema, però paga sul lungo periodo. Supponiamo di avere un'applicazione ricca di dati, annidati, con diversi casi particolari in base alle configurazioni di questi. Il modello Page Oriented è sicuramente il migliore perchè è un divide and conquere più efficace.
Ho scelto essenzialmente quattro framework che applicano questi due modelli:
  • Grails e Stripes sono action framework
  • Click e Wicket sono Page/Component Oriented
Gli altri non li esclusi perchè siano peggiori, tutt'altro. RIFE, Tapestry, Thinwire, sono anche migliori.
Ma io sono pigro :-)
Di conseguenza voglio strumenti agili, immediati per le cose immediate e capaci in ogni caso di reggere l'aumento di complessità in maniera lineare. RIFE, per esempio, è strepitoso ma date un'occhiata all'esempio del blog. Ad un certo punto non si capisce più nulla, anche se la sensazione è che l'autore abbia sbagliato approccio educativo.

Grails e Stripes sono invece degli ottimi esempi di comunicazione: c'è un approccio graduale alle caratteristiche, molti esempi, molti approfondimenti ben scritti. La sensazione che si ha è che le cose funzionino bene perchè l'idea alla base è semplice e pratica.

Di Click avevo parlato male, ma faccio pubblica ammenda. Utilizzando HTML puro e Velocity, la produttività è enorme. Si può buttare giù un'applicazione mentre ancora si sta imparando il framework.
Il sito è stracolmo di esempi, ben fatti, la documentazione è limpida.

Wicket alle prime stranisce. Sembra quasi che gli autori chiedano un atto di fede a chi vuole iniziare, lasciandolo completamente in balìa del framework. Non rimane che andarsi a guardare gli esempi.
Ma dopo un pò si capisce che il pargolo promette bene. L'approccio è il più puro che abbia mai visto, non una traccia di logica nella presentazione, non una traccia di presentazione nella logica.
Però è facile mettere in piedi la prima applicazione. Non facile quanto Click, ma abbastanza facile.
Andando avanti, si trovano esempi in abbondanza (qui c'è un bel pò di roba). L'unico difetto è la necessità di dovere associare una classe Java a una pagina Web per qualsiasi cosa, fosse pure un semplice messaggio di notifica.

E' stupido ribadirlo, ma non c'è e non può esserci il framework web Java. La scelta dipende innanzitutto dal problema da affrontare, e conseguente scelta dell'approccio (action/component). All'interno dei due possibili, ci sono diverse soluzioni e, per esempio, non opterei Click per una webmail Ajax-based, così come non userei Wicket per il portale dell'agenzia di viaggi.
Grails copre molte esigenze, ma se esiste già del codice Java da usare o se si prevede di interfacciarlo con altre applicazioni in Java, diventa un problema. E' possibile sicuramente, ma si perdono molti dei vantaggi nell'usare Groovy.
Stripes invece sarebbe più adatto, ma se non si hanno questi vincoli è meno "divertente".

Spero comunque che questo post aiuti perlomeno a sfoltire la rosa di scelte. In ogni caso, la discussione è aperta :-)

mercoledì 7 novembre 2007

Altro che coltellino svizzero

Come ho scritto in un altro post, sono assolutamente soddisfatto del mio Nokia N80, a parte il problemi delle prestazioni che tarpa di fatto un prodotto quasi perfetto nel rapporto qualità/prezzo.

Dopo un salutare aggiornamento del software, con l'installazione della versione Internet Edition (in breve, l'ultimo aggiornamento ufficiale di Nokia trasforma i normali N80 in N80 Internet Edition, che gestiscono un pò meglio VOIP e poco altro), ho risistemato i software installati e da installare.
Spippolando un pò in rete sono giunto infine a una configurazione di cui sono fiero, e che quindi sfoggio qui :-) :


Ho installato:
  • Il tema Field Of Colours, freeware, bellissimo
  • Calcium, freeware, una semplice calcolatrice che ha proprio il vantaggio di essere semplice
  • Screenshot 2, freeware, per prendere lo screenshot di cui sopra
  • Mr Lock, freeware, il blocco tastiera automatico che ho sempre bramato. Blocca i tasti dopo una certa pausa con varie opzioni per le eccezioni (per esempio, non si attiva se c'è una certa applicazione in esecuzione, o se non si è nello schermo di standby). Imperdibile.
  • WLan Wizard, freeware, da Nokia per il wardriving estremo :-D
  • GMail, freeware, chi non ha al giorno d'oggi un account GMail? :-)
  • Panoman, shareware, indispensabile per chi vive in Sicilia :-) . Consente di creare panoramiche perfette ruotando la fotocamera attorno a sè stessi. Costa $5,95, un prezzo ridicolo, e ancora più ridicolo se consideriamo il cambio sull'Euro. Alcuni esempi dei risultati nel loro photoblog.
  • Papyrus, shareware, qui il discorso è un pò articolato. Sul Symbian non ho ancora trovato un calendario con gestione degli eventi lontamente paragonabile a quello sul mio Tungsten T3 che ho ormai venduto. Non ho un'esigenza estrema di gestire eventi, appuntamenti, ma tendo a dimenticare così ho preso l'abitudine di segnarmi le scadenze burocratiche, le revisioni delle auto, i compleanni, le ricorrenze ecc.
    Il calendario fornito da Nokia è molto limitato. Tanto per dirne una, non considera i compleanni segnati sulla Rubrica...
    I PIM, ahimé a pagamento, che ho trovato per il Symbian sono Papyrus, Aqua Calendar e Handy Calendar. Mentre i primi due permettono di sincronizzare l'agenda con i compleanni della Rubrica, quest'ultimo non lo fa quindi lo escludo a priori (costa anche $39,95, non ne capisco la ragione). Aqua Calendar è strapieno di funzioni ma è confuso e lento, così alla fine ho scelto Papyrus. Entrambi costano $19,95, al cambio €13,63.
Un suggerimento finale per chi, come me, usa Ubuntu e dispone del Bluetooth sul PC: trasferire file col cavetto non è cosa semplice. Se collegate il cavo USB e selezionate "Archivio di massa" (cioè il normale storage via USB), viene montato il disco ma non si riesce ad aprire. Non ho trovato soluzioni rapide, così mi affido al Bluetooth. Per installare un'applicazione scaricata sul PC, basta selezionare il file .sis, o .sisx, e spedirlo al cellulare tramite Nautilus (occorre installare il pacchetto gnome-bluetooth e poi tasto destro, Invia a, OBEX push). Il cellulare lo riceve come messaggio con allegato e basta selezionarlo per avviare l'installazione.

mercoledì 31 ottobre 2007

Nokia N80 vs Puppy Linux, il segno dei tempi

Sul mio PC portatile, un Toshiba 2450-401 vecchio di 5 anni, ho installato Puppy Linux.
E' una distro Linux leggera nella maniera più intelligente. Carica solo lo stretto indispensabile all'avvio, gira tutta in RAM, gestisce periferiche e configurazioni varie attraverso piccoli, semplici e intelligenti tool. Su questo portatile funziona tutto, compresa la scheda Wifi su slot PCMCIA configurata esclusivamente attraverso un tool visuale.
Puppy Linux mi ha permesso di utilizzare il portatile anche per una semplice occhiata alla posta, cosa che con Windows Xp o con Ubuntu non avrei potuto fare.
Ho anche un cellulare Nokia N80. Un cellulare strepitoso, un coltellino svizzero con cui, per esempio, posso accedere attraverso UPNP allo streaming di Orb dei contenuti del mio HTPC.
C'è GMail, c'è l'upload delle foto su Flickr, c'è VNC.
Però è leeeento.
La fotocamera è il modulo che ne risente di più (è in pratica impossibile utilizzare il flash, pena foto mosse e ritardate rispetto all'inquadratura), ma ne risente anche la Galleria, la Rubrica, lo switch tra fotocamera e videocamera.
Così mi è venuta la curiosità e ho fatto la prova:

Il PC si avvia mezzo secondo prima del cellulare. Magari fra qualche anno i PC non avranno virus e i cellulari sì, i PC non riceveranno spam e l'archivio SMS ne sarà pieno.
Adoro il mio N80, ma non capisco perchè, nei requisiti necessari per l'usabilità, alla Nokia non abbiano pensato alle prestazioni.
O forse ci hanno pensato, ma ciò avrebbe comportato dell'hardware che avrebbe lievitato il costo, e di conseguenza la competitività.
Facendo ciò, hanno tolto appetibilità a un dispositivo che poteva essere (e in parte lo è) uno dei migliori e meglio bilanciati nel suo mercato.

Note: per il test mi sono comportato in modo che risultasse il più oggettivo possibile; avvio il PC e lo tengo fermo sulla schermata di GRUB (il software che permette di scegliere quale sistema operativo avviare), quindi accendo il cellulare un attimo prima per compensare il ritardo "meccanico" del pulsante.
Ad un certo punto premo Invio sul PC, ciò perchè Puppy cerca di acquisire un indirizzo IP tramite il DHCP server della mia rete Wifi. Per saltare questa fase (che non riguarda la velocità del sistema, è puramente un tempo di attesa) occorre appunto premere Invio.
Se si guarda il video, la schermata di Puppy appare un attimo prima della comparsa della schermata del Nokia (che, volendo infierire, si vede benissimo costruirsi sullo schermo a blocchi).

venerdì 19 ottobre 2007

SQL indipendente dal dialetto con Hibernate

L'esigenza che avevamo era di potere scrivere delle classi Java per interrogazioni SQL, mantenendo comunque una certa indipendenza dal server utilizzato. Le ricerche su Google non hanno dato frutti, il che mi sembra strano, dato che mi sembra un'esigenza diffusa.
Comunque, mi è venuto in mente che Hibernate poteva avere delle funzionalità del genere. Le interrogazioni in HQL o tramite Criteria alla fine vengono tradotti in SQL adattabile praticamente a ogni server DB sul mercato.
Il dubbio poteva essere se, trovando le classi che generavano il codice SQL, queste non fossero accoppiate con altre classi Hibernate (per esempio con la sessione), rendendole inutilizzabili.
Siamo stati fortunati: nel package org.hibernate.sql, esiste un insieme di classi per svariati processi di generazione di SQL guidati da una opportuna istanza della classe Dialect.
Quindi, basta usare i package org.hibernate.sql e org.hibernate.dialect per scrivere SQL indipendente dal dialetto. I due package sono semplici, poco strutturati e si possono importare facilmente in un progetto Java qualsiasi. C'è comunque da includere le librerie hibernate-3-x.x.jar e commons-logging-x.x.jar (e naturalmente log4j, ma già lo usate vero? :-) ), che pesano alcuni Mb.
Purtroppo non sono tutte rose e fiori. Queste classi sono puramente utility, concepite per essere utilizzate all'interno delle procedure di conversione delle interrogazioni di Hibernate, non per vivere di vita propria.
Sono mal documentate, poco coerenti, alcune parti sembrano messe e mai utilizzate e la procedura di scrittura di una query è per nulla strutturata.
Però quando si vuole scrivere una query che potrebbe girare su server DB diversi, possono venire utili.

Spippolando un pò, ho capito che le classi utili sono essenzialmente due:
  • org.hibernate.sql.SimpleSelect, utile se si vuole fare una query senza join, su una sola tabella. In questo caso è più difficile incontrare differenze tra i dialetti, e infatti la sola cosa che viene gestita è la clausola FOR UPDATE per mettere un lock sulle righe.
  • org.hibernate.sql.QuerySelect, qui è possibile fare di tutto. Come scrivevo prima, la gestione è raffazzonata, non propriamente object-oriented. E' una classe da battaglia, scritta per risolvere un problema specifico, tuttavia può essere utile.
A titolo di esempio, ho provato a creare una query con una inner join e una outer join, facendola generare con i dialetti MySql e Oracle. Non ho scelto a caso, perchè con Oracle le outer join hanno una sintassi che più proprietaria non si può :-)

Supponiamo di avere un metodo del genere:

public static QuerySelect buildASelectExample(Dialect dialect) {
QuerySelect theQueryThing = new QuerySelect(dialect);
SelectFragment selectFragment = new SelectFragment();
String[] columns = {"id", "firstname||' '||lastname", "address||', '||state"};
String[] aliases = {"id", "name", "address"};
selectFragment.addColumns("p", columns, aliases);
selectFragment.addColumn("o", "plant");
JoinFragment joinFragment = dialect.createOuterJoinFragment();

String[] fks1 = {"user_fk"};
String[] pks1 = {"id"};
String[] fks2 = {"office_fk"};
String[] pks2 = {"id"};
theQueryThing.addSelectFragmentString(selectFragment.toFragmentString());
theQueryThing.prependWhereConditions(" p.age between 18 and 35 ");
theQueryThing.getJoinFragment().addJoin("person",
"p", fks2, pks2, JoinFragment.INNER_JOIN);
theQueryThing.getJoinFragment().addJoin("person",
"p", fks1, pks1, JoinFragment.LEFT_OUTER_JOIN, " x = y");
theQueryThing.getJoinFragment().addCondition(" id = ? ");

return theQueryThing;
}

Invocando il metodo passando come dialect un'istanza di org.hibernate.dialect.MySQLDialect, questo è il risultato:

select p.id as id, p.firstname||' '||lastname as name, 
p.address||', '||state as address,
o.plant as plant from person p on office_fk=p.id
left outer join person p on user_fk=p.id
and x = y
where id = ? and (p.age between 18 and 35)


Utilizzando invece il dialetto org.hibernate.dialect.OracleDialect:

select p.id as id, p.firstname||' '||lastname as name, 
p.address||', '||state as address,
o.plant as plant from person p, person p
where office_fk=p.id
and user_fk=p.id(+) and x (+)= y
and id = ? and (p.age between 18 and 35)


C'è da dire che un uso ancora più proficuo può essere quello delle DDL, dove effettivamente i server si differenziano un pò di più, sopratutto sui tipi. Per questo è meglio invece vedere direttamente la classe org.hibernate.dialect.Dialect, con tutte le sue specializzazioni.

martedì 9 ottobre 2007

Castomer cher

Diciamoci la verità: quanti sono in Italia che, gestendo un'assistenza clienti, si sarebbero posti un dubbio del genere, e quanti avrebbero risposto così?

Programmazione 0.2?

Mi sono imbattuto in questo interessante articolo di Tim O'Reilly a proposito di una lista di cambiamenti dalla programmazione 1.0 alla 2.0, che rispecchia volutamente quella Web 1.0 -> Web 2.0:

La lista proviene, manco a dirlo, da un gruppo di appassionati di Ruby:


Molto interessanti i commenti, tra cui concordo con questo:

"I suspect that the author of the list is relatively new to programming and is consequently commenting only on changes from recent practices. For instance, there is an emerging rejection of the massive class libraries used with Java (among others) because they’re too big for most people to have a handle on. But such excessive libraries are only a recent phenomenon. I believe that much of what is happening now is simply a retreat from excessive complication, something that happens periodically in the programming world. I personally am thrilled that many “new” practices resemble those that my colleagues and I used in the 1970s and that today would be termed “agile”. And “modular” has been considered good programming practice since the 1950s. Perhaps the shift he describes would be better characterized as from Programming 2.0 back to Programming 1.0."

Chiunque si occupi di programmazione da un pò di anni ha la stessa sensazione, credo.
Qui non sta succedendo niente di nuovo.
Java e le sue quintalate di framework hanno generato il classico e tutto sommato prevedibile rigetto e il ritorno nostalgico alla buona vecchia programmazione fatta di creatività piuttosto che assemblaggio di roba precotta.

L'innovazione però c'è, secondo me: sono cambiate le piattaforme, e in maniera radicale anche. Non si lavora più sull'applicazione client chiusa nel proprio mondo, e si tende piuttosto a contribuire a una nuvola di microapplicazioni web collaborative.

Mi immagino il desktop fra qualche anno sempre più dominato dal browser e il web come una sorta di sistema operativo diffuso su cui risiederanno gran parte delle proprie applicazioni.

Da tutto ciò mi chiedo se è possibile, allo stato attuale, pensare ad una azienda le cui applicazioni siano tutte residenti sul web (nella intranet o nei vari servizi presenti su Internet).
Già Google Apps fornisce un servizio del genere, con Google Documents, Mail, Chat, e Calendar, e una home page aziendale. Altri servizi che mi vengono in mente potrebbero essere il timesheet, la gestione della contabilità, gli strumenti di sviluppo, ecc.

Se poi tutte queste applicazioni fossero web 2.0, integrabili, provviste di feed (nell'ipotesi che ci sia qualcosa per cui abbia senso fornire un feed), allora comincio a vederci un senso :-)

domenica 7 ottobre 2007

Il miio meediacenter con Meedio - Prima parte

Mi stupisce, per quanto abbia cercato, di non aver trovato articoli su HTPC realizzati con Meedio nella sua ultima (in tutti i sensi) versione.

Descrivo dunque cosa ho fatto io, senza troppi patemi e senza troppi approfondimenti sul genere. In realtà non sono un patito di home theater, dolby surround, HDTV ecc. Volevo semplicemente un sistema per:
  1. memorizzare in maniera ragionevolmente sicura i miei video (vacanze/feste, ma anche film e serie TV)
  2. trovarli e vederli in maniera semplice, per non farli cadere nel dimenticatoio
Ho evidenziato questi due punti perchè, nonostante sembrino dei non-problemi, è stato veramente difficile risolverli nell'ambito di un sistema casalingo, economico e non troppo complesso (vedi anche l'ottimo articolo di Paolo Attivissimo).
La soluzione che ho scelto, e che ritengo un buon compromesso, è di tenere i file su hard disk, ridondato con il RAID che consente il protocollo SATA. L'unico costo "in più" è il secondo hard disk, ma con i prezzi attuali...

Non mi interessa tuttora la funzionalità di PVR, a meno che non faccia l'abbonamento a Sky. Non è nelle mie priorità in ogni caso.

La possibilità più economica sarebbe un box USB con funzionalità di mediaplayer, però ci si ritrova comunque con uno strumento limitato sia nelle funzionalità che nei formati supportati. Idem per quei lettori da tavolo da collegare tramite WiFi al proprio PC (per es. questo della NetGear).
Per un pò avevo buttato un occhio al MacMini, ma non ho letto bene di Front Row (il media center software di Apple) e non ha l'uscita TV analogica.

Così ho provato ad assemblarmi un HTPC, senza spendere troppo e tenendo in mente la facilità d'uso (wife proof).
Quindi utilizzo esclusivamente da telecomando, e software semplice e completo.
Il risultato non è ancora definitivo, ma non è neanche malaccio:
L'hardware è il più micragnoso che abbia trovato: processore AMD Athlon 3800+, mobo Asus M2NPV-VM (non vi fate ingannare, l'ho scelta perchè ha tutto integrato, compresa l'uscita TV analogica e digitale), un disco SATA da 160Gb e 1 Gb di RAM.
Sul case ho investito di più. Se c'è una cosa su cui non risparmiare, negli HTPC, è la silenziosità. Non sono ancora al silenzio nero, ma posso vedere un film senza il sottofondo aeroportuale dei classici case.
Ho scelto un Thermaltake Bach, esteticamente gradevole e molto spazioso, in cui ho montato un alimentatore Zalman da 300W trovato usato su EBay.
I due si difendono bene, però il Thermaltake ha due ventole di ricircolo posteriori che sono la fonte primaria di rumore. Appena ho un pò di tempo vedrò come risolvere.

E siamo infine arrivati a Meedio: quello che si vede nello screenshot è la schermata principale, con i menù tipici di un media center come si deve.
Il PC lo amministro attraverso UltraVNC, soluzione che mi è sembrata più efficiente e versatile del remote desktop di Windows.
Sullo stesso PC ho installato anche un server FTP (Filezilla Server), Orb, che consente di mandare in streaming su extranet i propri contenuti audio e video (dico extranet perchè, essendo server UPNP, Orb è in grado di sfruttare la banda maggiore nel caso si acceda da rete locale).

Meedio, una volta prodotto commerciale, fu acquistato da Yahoo, che ne fece un prodotto chiuso e orientato alla fruizione dei propri contenuti online. Se proprio interessa, si chiama Yahoo! Go TV.
Ma Meedio è molto di più. E' un sistema estremamente modulare che, grazie a una comunità viva e attiva ancora oggi, vanta 376 plugin di varia natura disponibili.

Subito dopo la vendita a Yahoo, Meedio fu reso liberamente scaricabile e nel frattempo nacque l'idea di MeediOS, una versione completamente riscritta e open source di Meedio.
Purtroppo lo sviluppo di MeediOS va a rilento, ma sullo stesso sito è possibile scaricare Meedio e tutti i suoi plugin.
Questa estate è stata pubblicata inoltre una versione bundle di Meedio con gli innumerevoli plugin (solo quelli più gettonati, che sono almeno una trentina) già inclusi e preconfigurati.

Installando questo, si ottiene un media center che dà la polvere (tranne forse sul PVR, che non ho mai provato) a tutti i vari Windows Media Center, Mediaportal, TVedia, GBPVR, xLobby.

Nella prossima parte si vedrà anche il perchè.

giovedì 4 ottobre 2007

Rails Rumble? Pfui

Leggo oggi su downloadblog che si è conclusa la competizione Rails Rumble 2007, che consiste nella sfida tra un centinaio di team di sviluppo per creare un'applicazione web funzionante in 48 ore con Rails.

Casca a fagiolo :-)

Ieri, un pò per scopo didattico un pò per goliardia, ho realizzato un'applicazione web per caricare e in seguito visualizzare i risultati di una votazione (nel nostro caso il pretesto è l'elezione della RSU aziendale).
Bene, l'ho realizzata con Grails in 5 ore. Avete letto bene, 5 ore.
Sono partito da zero assoluto, generando il progetto con grails create-app, e non avendo mai scritto una sola riga in Groovy nè Grails.

Ho fatto generare le pagine CRUD delle mie entità (Sede e Candidato), ho ritoccato le pagine generate per rimuovere elementi indesiderati (tipo l'id), ho aggiunto un tocco di Ajax affinchè nell'elenco dei candidati fosse possibile
incrementare/decrementare il voto a ciascuno (anche di Ajax è la prima volta che faccio uso), ho aggiunto una pagina con i risultati presentati graficamente alla meno peggio e infine ho aggiunto l'autenticazione per modificare i dati (che è possibile solo per lo Scrutatore).

Chiaramente ho lasciato il layout di default, nonchè le varie pagine di edit. Ma il tutto è un'applicazione vera e utilizzabile, che lavora su un DB Hypersonic attraverso Hibernate. L'infrastruttura è gestita da Spring e la presentazione da Sitemesh. Grazie a Grails non li ho nemmeno sfiorati.

Per la cronaca Tasty Planner è l'applicazione che ha vinto la competizione. Non è male, sia graficamente che concettualmente. Il team mi pare fosse di almeno 3 persone. Per cui tre risorse per otto ore al giorno per due giorni fanno 48 ore uomo.
Oltretutto mi sbaglierò ma la tag cloud sulla homepage non funziona.

Grails rulez? No, non lo penso affatto. Rails ormai è strumento consolidato e strapieno di plugin e soluzioni pronte da usare.

Ma Java non si muove più a passo di elefante.

PS: Per i fan di Ruby, il titolo è puramente ironico.

11/09/2007 - Update: La tag cloud di Tasty Planner adesso funziona

giovedì 27 settembre 2007

Yeah, baby, yeah!


Ieri sera ci sono riuscito. Ho fatto funzionare il mio primo progetto Wicket.
Sembra quasi una esclamazione da principiante, ma non è davvero facile partire con questo aggeggio. Inoltre mi sono intestardito a lavorare da subito con la 1.3.0 beta3, che ha alcune modifiche radicali:
  • Il gestore di tutto non è più una servlet ma è un filtro. Rimane comunque la retrocompatibilità
  • Le Commons Logging vengono sostituite da un nuovo gestore di logger, SLF4J
Un ottimo aiuto è stato il post di Jess Sightler, praticamente nei miei stessi guai.

Ad un certo punto mi sono ritrovato anch'io con l'errore di Tomcat:

26-set-2007 18.13.22 org.apache.catalina.core.StandardContext start
GRAVE: Context [/wickettest] startup failed due to previous errors
26-set-2007 18.18.32 org.apache.catalina.startup.HostConfig checkResources
INFO: Undeploying context [/wickettest]

Stesso problema suo...
Dal suo post, ho dedotto che il problema riguarda una qualche libreria mancante. Dopo qualche tentativo ho capito che mi mancavano le librerie base di SLF4J, le ho aggiunte al mio project.xml e...

INFO: Deploying web application archive wickettest.war log4j:WARN No appenders could be found for logger (org.apache.wicket.protocol.http.pagestore.FileChannelPool). log4j:WARN Please initialize the log4j system properly. ******************************************************************** *** WARNING: Wicket is running in DEVELOPMENT mode. *** *** ^^^^^^^^^^^ *** *** Do NOT deploy to your live server(s) without changing this. *** *** See Application#getConfigurationType() for more information. *** ********************************************************************

Mai Warning fu più benvenuto. :-)
In realtà il sistema gira correttamente e l'avviso riguarda la modalità di esecuzione di Wicket. In Development mode, Wicket intercetta le modifiche alle pagine in maniera dinamica, a scapito delle performance.

Nei commenti del post, alcuni membri della comunità Wicket sono intervenuti, in verità un pò aggressivi, fornendo comunque un buon riferimento per una configurazione iniziale della 1.3.

Adesso ho quindi una base iniziale per proseguire lo studio di questo giocattolo, che gestisco con Maven 1.
Per chi fosse interessato, qui c'è uno zip con il progetto. Tenete presente che con maven eclipse vengono generati il .classpath e il .project per l'importazione dentro Eclipse, e con maven war viene generato il WAR da portare su Tomcat. Il progetto è molto embrionale, sia chiaro.

martedì 25 settembre 2007

Wicket mumbling

Da qualche giorno sto studiando Wicket, perchè mi farebbe comodo (e forse mi servirà a tutti gli effetti) un web framework a componenti (o component oriented).

Component oriented significa in soldoni che la pagina si ottiene aggregando blocchi ottenuti lato server attraverso il framework stesso. Un pò come si realizza un software con Delphi o Visual Basic, solo che su Internet è tutto più difficile :-)
Un approccio del genere è utile quando la pagina web è dinamica anche nella struttura e/o i suoi componenti hanno una complessità per cui è utile impacchettarli e rituilizzarli dove servono.

L'ho preferito a Click e ThinWire, perchè Click mi è sembrato portatore sano di cattive pratiche: in teoria si potrebbero scrivere pagine JSP, con blocchi Velocity e classi Java a miscelare il tutto. Sodoma e Gomorra... :-D
ThinWire mi sembra invece orientato ad applicazioni web definitivamente client, basta vedere le demo sul sito...

Wicket impone una scelta radicale. Mai più logica sulla pagina web, un banale foreach, un <%=%> sbarazzino, nulla...
Su questo possiamo essere tutti d'accordo senza troppa fatica, separazione di logica da presentazione pura e dura. Mi proccupa di più invece che ogni singolo intervento di manutenzione richieda la disponibilità di un ambiente Java, compilatore incluso.
Potrebbe anche essere positivo, uno stimolo a curare ogni rilascio nei minimi dettagli, e forse alla lunga questo approccio purista darà i suoi frutti anche in termini di organizzazione del lavoro.

Però, cari amici di Wicket, una mano datela anche voi :-)
Su sito non c'è un articolo introduttivo, la documentazione è un wiki molto poco strutturato e non rimane che cercare articoli in giro o scaricare gli esempi(*).

L'impostazione di default è quantomeno curiosa: la pagina HTML dovrebbe stare nello stesso package della classe che la mappa sul lato server.
Cioè se io realizzo una Login.html, dovrei salvarla nel package com.acme.businessenterpriseapplication assieme alla corrispondente Login.java.

E' vero che questo comportamento è configurabile ma, a parte il fatto che la configurazione cambia con la versione di Wicket, perchè non permettere di default (magari con un parametro nella servlet) di scegliere la posizione in cui tenere le pagine?

Non che stia bocciando Wicket, tutt'altro. Leggendo in giro viene fuori una notevole robustezza delle idee che ci stanno dietro, ma perchè non fornire un bel paragrafo Introduction in cui mettere da subito un codice minimale funzionante?

Sembra quasi un test d'ingresso... :-D

(*) Mi sono espresso male, non che manchino le informazioni. Io però non ho trovato il classico articolo di startup che spieghi, magari superficialmente, come mettere in piedi la prima semplice applicazione. C'è qualcosa, ma legato a Maven 2, ma io uso Maven 1 e poi non è obbligatorio usare Maven con Wicket.
Può darsi che abbia cercato male io, ma anche questo è indice di non perfetta organizzazione del sito. Io mi aspetto (e in genere è così) che nei primissimi link della homepage ci sia quello al classico articolo di Hello World.

mercoledì 5 settembre 2007

Umorismo involontario a RGS

Stamattina a Radio Giornale di Sicilia: "Incursione di hacker cinesi nei sistemi inglesi. Il ministero della Difesa non si pronuncia. Il giallo si infittisce."

giovedì 30 agosto 2007

Promemoria: monitorare un log da remoto su Unix/Linux

Il seguente comando:

tail -f /path/del/log/blablabla.log

permette di visualizzare su console l'ultima porzione di un log, aggiornandola di continuo.

lunedì 20 agosto 2007

Alla ricerca del Santo Graal...

In questo periodo guardo con sempre più interesse a Grails. Tutto è cominciato quando ho deciso di approfondire le mie conoscenze sui web framework di tipo fronted per Java.
Da lì è partita sul serio la ricerca del Santo Graal. Quando cominci a cercare un framework per Java, sai quando cominci ma non sai quando finisci. E soprattutto con cosa finisci.

La mia esperienza attuale è limitata al lato backend dei framework. Ho usato con estrema soddisfazione Andromda e Spring, e Hibernate per l'accesso ai dati.
Anche queste scelte non sono state facili, ma in un certo senso è stato + immediato. Primo, perchè Spring e Hibernate sono standard de facto (e quasi quasi anche per diritto :-) ). Secondo, perchè dovevo cominciare a lavorare su un progetto e mi sono fidato subito del mio istinto.
Per Andromda è stato un caso, uno di quei casi che ti cambiano la vita :-)
Andromda è fenomenale, ha permesso la scrittura e gestione di un framework che supera le 150 entità, persistenti e non, con servizi di tipo J2EE, interfacciamento ai webservice.

Con i framework frontend la cosa è più difficile: ce ne sono una pletora, tutti validi e non c'è una reale direzione della comunità Java. Escludendo naturalmente Struts, che credo abbia fatto il suo tempo:
  • Click, Echo2, ThinWire: tutti ottimi prodotti, ma orientati ad applicazioni rich client piuttosto che generici siti/portali
  • GWT: uuhhmm le RPC mi danno garanzia di scalabilità?
  • OpenLaszlo: è un discorso a parte... ci giochiccherei volentieri, ma il tempo disponibile non me lo consente :P
  • Tapestry, Wicket(*): interessanti, l'idea di avere pagine HTML prive di elementi dinamici (il comportamento dinamico si ottiene con opportuni id nei tag HTML) dovrebbe ridurre le interferenze con i grafici.
    Di Tapestry però ho letto di complessità di configurazione e questo va contro la mia idea di buona progettazione. Un buon framework dovrebbe rendere semplici le cose semplici, e non troppo difficili le cose complesse. Per questo ho escluso Struts a priori.
    Il rischio è l'effetto "Inner-Platform": con lo scopo di rendere estremamente flessibile un componente di un sistema, lo si rende "un sistema dentro il sistema", complesso quanto il problema che si vuole risolvere.
    Il che a mio parere è blasfemo.
  • Stripes, ZK, Struts2, RIFE: andiamo già meglio (di RIFE non sono sicuro), c'è già una discreta applicazione dei principi di convention over configuration. Escluso Struts2 su cui non ho ben capito l'effettiva validità (e la home page che scimmiotta il Web 2.0 senza riuscirci), mi sono orientato su Stripes che mi pare abbia una comunità più ampia di RIFE e ZK. Una comunità più ampia significa bug risolti in fretta, disponibilità di articoli, faq, soluzioni a problemi complessi, tutti aspetti da tenere presente per applicazioni di produzione.
Stripes è quindi il prodotto che mi permetterebbe un approccio più moderno, ma abbastanza conservativo da non rischiare di cacciarmi nei pasticci.
Mi riferisco a portali web tipici, senza particolari richieste di interazione con l'utente. In applicazioni più tipicamente client, guardo con curiosità a ThinWire.
Ma tutto quello che è elencato (meno del 50% di tutto quello che in realtà si trova) non è affatto da scartare. L'ideale è che ogni esigenza venisse risolta con lo strumento più opportuno. In realtà si fa riferimento a quei 2-3 strumenti affermati ognuno per una certa tipologia di prodotto.

Attualmente io mi orienterei così:
  • Portale più o meno complesso, con poca logica applicativa e tipicamente web (per es. il classico sito di ecommerce): Stripes/Struts2/RIFE
  • Portale complesso, molto orientato ai dati (in realtà una trasposizione web delle applicazioni client, per es., la gestione di un magazzino): ThinWire/Click
  • Portale semplice, con logica tipicamente web anche abbastanza complessa (per es., gestione di un calendario online, o uno storage remoto con upload/download): Rails/Grails
Mi fermo qui. Ho vomitato tutto il mio giro mentale che mi ha portato a scoprire questi due progetti e ad intrappolarmi in un bivio: è vero quanto ho scritto alla fine? Rails/Grails sono veramente aggeggini con cui trastullarsi, o possono tranquillamente prendere il posto dei blasonati Stripes e Struts 2?

(*) Ricordavo male: di Wicket non mi aveva lasciato perplesso la complessità di configurazione (effettivamente Wicket è semplice), semmai la sua natura Java-centrica. Non so quanto mi convinca un portale che richieda, per ogni manutenzione, l'intervento su codice Java, con relativa compilazione, deploy ecc

sabato 11 agosto 2007

The Big Bang

Bene, anch'io nella blogosfera. Mi presento: sono un ingegnere informatico, dipendente di una società di IT nella sede di Palermo.

E' un pò strano scrivere il tuo primo post. Sembra di salire su un palco dove un pubblico che non ti conosce ascolta per un attimo ciò che stai per dire. Poichè sullo stesso palco ci sono migliaia di altre persone che già parlano, è probabile che nessuno di accorga di te, ma ti senti lo stesso tutti gli occhi addosso...

Questo blog servirà più a me che ad altri. Raccoglierò le mie idee, pubblicherò link e relativo breve commento, e spero anche di potere chiaccherare con chi condivide la mia passione informatica.

Sono attratto soprattutto dalle architetture software e dalla usabilità delle interfacce utente, non necessariamente in ambito informatico.

E per chiudere con qualcosa di spassoso e attinente, metto un link alla Interface Hall of Shame, una "irriverente" collezione (vecchiotta, per la verità) di ciofeche nelle UI. Scommettiamo che c'è tuttora qualche esempio nelle applicazioni più recenti?