Pietro Bonanno does blogs

Adoro lo spam/3

2010-01-29T11:45:00.001+01:00

Adoro lo spam/3, inserito originariamente da Pietro Bonanno.

Cosa vorranno da me?

Broken

2009-11-26T14:24:00.000+01:00

Inequivocabilmente rotto.
Addio, compagno di lunghe letture.

Il tecnofilo era inquieto...

2009-11-16T12:09:00.005+01:00

...per mancanza di nuovi gingilli. Così, per il proprio compleanno, ha chiesto alla propria moglie rassegnata di regalargli questo gioiello (almeno sulla carta) di tecnologia: il Parrot RKi 8400.
Lo ha trovato mentre si informava sulle caratteristiche del Clarion FB289RBT, rivelatosi invece una clamorosa occasione mancata da parte di Clarion.
Entrambi sono delle autoradio prive di lettore CD, e dedicate unicamente all'uso tramite SD card o USB, che è quello che cercavo. Altra priorità era la funzionalità vivavoce, che entrambi supportano, con il Parrot che chiaramente svetta per la quantità di funzioni.
Quello che mi ha deluso del Clarion però è:

Un solo ingresso di tipo SD, e neanche SDHC! Supporta al massimo le schede da 2 GB. Assolutamente ridicolo, fra qualche mese sarà pure difficile trovarle sul mercato.
Non può scorrere all'interno di un brano, si può solo saltare da un brano all'altro
Se arriva una chiamata in vivavoce, interrompe il brano e, alla fine, lo fa ripartire dall'inizio.
Apparentemente, il firmware non è aggiornabile

Sono tutti difetti che in un dispositivo prevalentemente software, come questo, dovrebbero essere assenti by design. I 2 GB di limite, poi sono veramente ingiustificati.

Il Parrot RKi 8400 invece ha 4 ingressi: SD, USB, iPod/iPhone (qualsiasi modello di iPod!), e AUX esterno (retrò, ma a qualcuno potrebbe servire). Il manuale dice esplicitamente che le schede SD/SDHC possono avere qualsiasi dimensione.
Prende le copertine se presenti nella cartella, permette (dai!!) di scorrere il brano, e la Parrot rilascia periodicamente nuove versioni del firmware.
Pare, a onor del vero, che soffra anche di vari bug, ma mi è arrivato solo oggi e devo verificare.

Acquistato a € 278,95, spedizione inclusa, presso i gentilissimi venditori del sito http://www.oikka.it.

Spero anche di potere scrivere una recensione, appena l'avrò spremuto un pò.

Javaday 2009

2009-05-13T17:43:00.005+02:00

Venerdì 8 ho fatto una presentazione al JavaDay svolto a Palermo, parlando di Groovy, Grails e, un pelino, di Griffon.
Per l'occasione ho realizzato da zero una semplice piattaforma di blog con Grails. In mezz'ora (naturalmente avevo già le idee chiare e un pò di codice pronto).
E posso assicurare che non sono affatto un guru, né Groovy né Grails.
Il codice è disponibile qui, come repository Subversion.

Update del 20/05/2009: Includo anche le slide, create con Google Documents. Assolutamente superflue però mi piaceva usare la funzione di pubblicazione :)...

Un lettore di feed in un riga di codice

2009-05-07T15:39:00.003+02:00

Ok, l'esperienza utente sarà carente ma è notevole comunque:

new XmlSlurper().parse('http://www.corriere.it/rss/ultimora.xml').channel.item.each {println "${it.pubDate}: ${it.title}"}

Se poi uno ha bisogno di fare una ricerca all'interno dei titoli:


new XmlSlurper().parse('http://www.corriere.it/rss/ultimora.xml').channel.item.findAll({it.title =~ 'napolitano'}).each {println "${it.pubDate}: ${it.title}"}

Groovy è veramente sensazionale.

Perchè Hibernate scrive nel mio DB?

2009-04-08T17:52:00.003+02:00

Ora, farsi una domanda del genere denota una certa confusione sugli strumenti che si stanno usando, ma questo bel post dice ben altro: Hibernate gestisce ottimamente la persistenza automatica dei propri dati, però ci sono dei casi in cui la scrittura avviene inaspettatamente. Per esempio il punto 2 dell'articolo, ovvero quando si esegue una query (in HQL chiaramente). In tal caso, se Hibernate si rende conto che la query coinvolge tabelle le cui modifiche sono ancora in cache, la scarica, ovvero la scrive.
E' ovvio, ma sono di quelle cose che diventano ovvie solo dopo esserci passato (e io lo fui).
Un concetto sottinteso che mi sento di ribadire è: Hibernate è una bestia, chi si lamenta perchè tenta di utilizzarlo in una rubrica telefonica dovrebbe capire che sta solo subendo gli svantaggi senza fruirne i vantaggi.
Gli ORM cominciano a diventare vantaggiosi quando il dominio raggiunge il centinaio di entità, giusto per dare un'idea.

Per problematiche più piccole, io mi sono trovato bene con BeanKeeper, ma ce ne sono altri (che non conosco).

E quanto sarà stato fatturato al cliente?

2009-01-21T09:53:00.007+01:00

Questo é quanto appare aprendo il sito Rai per il rinnovo del Canone TV. Chi non mastica ASPX, sappia che BANKPASS non è più un metodo consentito di pagamento del Canone.

update del 11/02/2009: l'errore è ancora lì, in bella vista. Nessuno di Rai, BANKPASS, o dei sistemisti/sviluppatori ha dato un'occhiata a questa pagina da almeno 20 giorni. E' assurdo.

update del 01/04/2009: nulla di nuovo sotto il sole. E non è un pesce d'aprile.

update del 13/05/2009: indovinate?

update del 29/01/2010: Toh! Hanno sistemato un pò la pagina e tolto l'insignificante dimenticanza. Vedete che serve, pagare il canone?

Java è morto, viva Java

2008-12-11T12:52:00.002+01:00

C'era una volta il C++. Un linguaggio complesso, nato in un periodo in cui la OOP era in gran parte materia accademica. Il C++ (in gran parte) ha consentito di traghettare il mondo professionale dall'approccio procedurale a quello ad oggetti. Con il tempo, e con l'accumulo dei casi d'uso, il C++ è diventato sempre più ingombrante. La sua sintassi è troppo ricca di costrutti legati ad una visione a basso livello del sistema operativo, ma se devo implementare un sistema informativo e non una libreria grafica, non voglio preoccuparmi di tenere a bada allocazioni, indirizzi di memoria, buffer di file.
Così (banalizzando molto...) nacquero gli ambienti RAD, come Visual Basic e Delphi, che portarono anche importanti evoluzioni nei linguaggi. Soprattutto Delphi (derivato dal Turbo Pascal, ok) creò forse il primo vero ambiente di sviluppo per applicazioni commerciali con una visione moderna e ricca delle esperienze accumulate negli anni.
Da lì poi si passò a Java (da cui Microsoft si ispirò per il C#) che ripulì ancora di più la sintassi creando il primo vero linguaggio ad oggetti puro (non strettamente accademico).

Il C++ però non è affatto sparito, anzi. Se ci si basa sulle richieste di lavoro, il C++ arranca ma è ancora tra i primi 10. Questo perchè, in ogni caso, il C++ è ancora la crosta immediatamente successiva alle API di basso livello di quasi tutti i sistemi operativi. Fornisce le spalle solide su cui appoggiarsi con altri strumenti più adatti alle esigenze degli utenti finali.
Mi ha meravigliato scoprire quanto Python leghi bene al C++. Un linguaggio semplice, interpretato, in simbiosi con un mostro della sintassi. XBMC, un frontend per mediacenter che mi ha quasi fatto dimenticare Meedio, è scritto in C++, ma si appoggia a Python per i plugin. Un'idea semplice ed efficace, che permette a chi vuole contribuire di lavorare con un editor di testo e qualche nozione di programmazione non troppo sofisticata.

Dove voglio arrivare con tutto questo pippone? A me sembra che anche per Java sia arrivato il momento di diventare una solida spalla. Esistono ormai centinaia di piattaforme software scritte in Java e molte sono diventate ormai imprenscindibili per realizzare applicazioni data-oriented. Spring e Hibernate sono i casi più eclatanti.
Ma forse Java è diventato anche lui troppo "a basso livello" per le applicazioni moderne. Ormai quasi ogni specifica funzionale può essere soddisfatta assemblando mattoncini già esistenti. Un esempio è XML, che per anni è stato un surrogato a Java per questi scopi. Si assemblavano mattoni utilizzando XML. Però la relativa semplicità di XML ha fatto sì che assemblare mattoni sia diventato più difficile che scriverne di nuovi.
Io ho la sensazione (molto a naso, non sono un guru o un analista di mercato), che i tempi siano maturi perchè Groovy possa diventare il linguaggio della prossima generazione di applicazioni, almeno nell'ambito dei sistemi a prevalenza open source e multipiattaforma. La semplicità di Groovy unita all'efficienza (computazionale) di Java. Grails ne è l'esempio più riuscito.
Chi ha pensato a JavaFX, lasci perdere. Su quel terreno Java prenderà batoste dolorose.
Da parte mia, per l'anno nuovo mi sono prefisso di convertire a Groovy il più possibile delle mie attività (vincoli aziendali permettendo). Un primo passo potrebbe essere la scrittura dei test case di applicazioni Java, che mi permetterebbe di valutare senza rischi le sue caratteristiche di performance. Un secondo passo potrebbe essere, giusto un esempio, una portlet in Groovy.
Se poi ci fosse qualcosa di disponibile per Eclipse RCP, non sarebbe male...

Un tuffo in un'altra quintalata di framework

2008-11-10T17:08:00.002+01:00

Ho avuto la felice idea di approfondire il tema delle applicazioni client (sì, proprio quelle che non richiedono un browser per girare) su Java, perchè voglio scrivere una semplice applicazione per uso personale. Nonostante le mie competenze attuali si siano spostate sui sistemi backend, ho da sempre una passione per le interfacce utente e la loro usabilità.

Da studente realizzavo qualche semplice applicazione usando Delphi di Borland, e oggi mi viene un pò da sorridere leggendo di discussioni su come realizzare bind, action, riusabilità delle interfacce, roba che già 10 anni fa Delphi gestiva in maniera egregia.

Ormai uso Java e mi trovo bene, ma la ricerca di un framework per applicazioni client non è tanto diversa che per le applicazioni web. Si trovano decine di alternative, se ne scartano altrettante per manifesto abbandono del creatore, e quelle che rimangono fanno tante cose benino, ma poche benone.
Uno dei miei punti fermi è stata la produttività: posso anche rinunciare all'editor visuale, ma il tool che cerco non si perdere in inizializzazioni inutili, o paginate XML nel tentativo di essere sempre sufficientemente generico. Ormai i pattern tipici delle interfacce utente sono assodati, al limite il lavoro in più dovrebbe essere legato a particolari esigenze.

Intanto ho dovuto affrontare la scelta ideologica tra Swing e SWT: il primo è il framework storico di Sun, da qualche anno rinnovato dall'introduzione di Swing Application Framework, che completa la creazione di interfacce con un modello MVC. Il suo punto di forza è sicuramente Netbeans, con Matisse, un editor visuale che spacca. La sua debolezza (ma per molti è un punto di forza) è il fatto di essere renderizzato in maniera indipendente dal sistema ospite. Io la considero una debolezza perché è più pesante, ma sopratutto perchè risulta alieno nel sistema ospite, anche se JGoodies ha dimostrato che non è necessariamente così.

SWT è invece la libreria su cui è basato Eclipse. E' Java, ma è un wrap sulle API native del sistema ospite per cui, da un certo momento in poi, il rendering è affidato al sistema operativo, e la resa grafica è esattamente quella nativa. Ne beneficiano anche le performance, basta confrontarne lo stack delle chiamate con uno Swing.

C'è da dire che però SWT è molto meno usato di Swing, e questo si riflette nella qualità e quantità di codice. Swing ha, oltre al citato Netbeans/Matisse, anche Spring RCP, un'altra delle perle di Spring Framework, che però mi pare stia languendo. Bene, una scelta in meno :-)

Poi ci sarebbe Groovy SwingBuilder, un'aggeggino molto interessante, oppure Griffon che promette molto bene ma è ancora alla versione 0.0.1(!!).

Sul lato SWT c'è Groovy SWTBuilder ma caliamo un velo pietoso, e JFace. Basta.

JFace non è un vero e proprio framework, ma più che altro una serie di helper class per sveltire i lavori ripetitivi con SWT. Inoltre ha JFace Databinding, per legare in maniera bidirezionale modelli e UI, che sembra fatto molto bene.

Tutti gli indizi portano a scegliere razionalmente Swing. Così ho scelto JFace/SWT :-)

I miei primi esperimenti non mi stanno deludendo, anche se la mancanza di un editor visuale si fa sentire. Però c'è MigLayout, e la sensazione è che forse un tool visuale fa più danni che altro. Basta dare un'occhiata al codice generato da Matisse (non per la qualità, ma per la quantità).

All'inizio si risparmia molto tempo, a lungo andare il codice diventa un papocchio.

Non è finita: per chi ha voglia di emozioni forti ci sono Netbeans Platform e Eclipse RCP. In pratica si prendono gli scheletri base dei due ambienti (concepiti alla base per essere contenitori generici di plugin di vario tipo, per capirci l'intero Java IDE di Eclipse è un grosso insieme di plugin) e si arricchiscono con i vari plugin forniti assieme per creare software di qualsiasi livello (non certo i gestionali per la pizzeria, comunque). Entrambi gli ambienti snocciolano esempi di tutto rispetto.

Dietro i già molti prodotti che ho citato ne ho visto almeno altrettanti, alcuni interessanti (Java Builders, UFace) alcuni decaduti.

Non voglio fare il classico reazionario informatico (ah! il Clipper...ah! il Commodore 64...ah! l'Assembler), ma un pò mi manca il buon vecchio Delphi...

Il tecnofilo colpisce ancora

2008-11-10T14:34:00.002+01:00

Approfittando di un viaggio negli Stati Uniti di un mio amico, ho preso il lettore dei lettori: il Cowon A3 con 60 GB di disco.

Grazie al cambio Euro/Dollaro la spesa complessiva è stata di € 270. Non mi dilungo sulle caratteristiche, dato che in giro si trovano recensioni a iosa. Sottolineo solo alcuni punti:

Il display lascia senza fiato
Anche l'audio
Anche la dotazione di cavi (non c'è collegamento che non sia contemplato da uno dei cavi inclusi)
Il software è ridicolmente spartano
La ricarica via USB è una chimera (e il caricabatterie è troppo ciccione per un dispositivo portable)
Però l'USB Host è una figata

Adoro lo spam

2008-09-19T09:31:00.002+02:00

Adoro lo spam, inserito originariamente da Pietro Bonanno.

Alcuni, perlomeno :)

BeanKeeper, si diceva...

2008-09-01T22:58:00.001+02:00

Con questo triste tentativo di riagganciarmi a quanto scritto 3 mesi fa, parlo un pò di BeanKeeper. Si trova poco in rete, e mi spiace. Questa libreria è semplice, razionale, con qualche chicca non facilmente ottenibile con le librerie più blasonate. Faccio qualche esempio: BK gestisce in maniera assolutamente trasparente il versioning del modello, ma anche dei dati (historical data). Ciò vuol dire che BK tiene traccia delle modifiche al modello (es. aggiunta o rimozione di property), ma anche delle modifiche ai dati. Come spiega la documentazione, le operazioni non avvengono mai sovrascrivendo dati esistenti, bensì aggiungendo i nuovi dati assieme ai vecchi. Con una banale sintassi, è possibile poi interrogare il DB nello stato in cui si trovava ad una certa data e ora nel passato. Niente male, anche se, pare, è un meccanismo non disattivabile e quindi sarebbe una ridondanza, dove non richiesto. Poi, gestisce nativamente cluster di webserver con la stessa applicazione che accede ad uno stesso DB:

L'oggetto Store che si occupa della persistenza, in un Web server, gira in un thread separato quindi è esso stesso un servizio raggiungibile dagli altri Store del cluster. Il più vecchio viene assunto a coordinatore del gruppo e gestisce transazioni e lock degli oggetti. Ancora una volta non serve nessun intervento da parte dello sviluppatore. In realtà c'è un piccolo effetto indesiderato: ogni volta che si fa un deploy della web application, si deve intercettare il servizio Store e chiuderlo. Chi usa Spring, può approfittare del ContextLoaderListener, necessario a inizializzare Spring MVC. Io ho definito una classe derivata, e ridefinito il metodo public void contextDestroyed(ServletContextEvent event):

    public void contextDestroyed(ServletContextEvent event) {

       super.contextDestroyed(event);

       XmlWebApplicationContext context = (XmlWebApplicationContext)WebApplicationContextUtils.getWebApplicationContext(servletContext);

       context.refresh();

       // A questo punto si recupera lo Store dal proprio context di Spring
      Store store = ...

       store.close();
   }

L'utilizzo di tutti i giorni è veramente banale: qualsiasi JavaBean può essere salvato su DB con la semplice istruzione

store.save(theBean);

non serve altro. BK si collega al DB, crea le tabelle se non esistono (tra cui un discreto numero di tabelle di supporto), e inserisce i dati. Se il vostro bean contiene una legame 1-M con un altro bean (per esempio una proprietà di tipo List), BK si occupa della persistenza anche di questa (e di tutti i bean contenuti). Al caricamento, la lista verrà gestità come una LazyList, un'implementazione di List che carica gli oggetti a lotti di 30, solo se fisicamente richiesti. Tanta semplicità ha i suoi lati oscuri:

le operazioni di lettura e scrittura in genere coinvolgono più operazioni (dettagliatamente descritte nella documentazione), necessarie a mantenere tutta una serie di metadati
molte funzionalità non sono configurabili (es. il lazy loading, il clustering, ...)
i caricamenti dei bean soffrono del problema N+1 SELECT: se una classe A ha una relazione 1-M con una classe B, il caricamento di un'istanza della classe A comporta 1 SELECT per essa più N SELECT per le N istanze di classe B (totale N+1 SELECT). Se si carica poi una lista di K istanze di classe A, il numero di query diventa K*(N+1) il che diventa rapidamente ingestibile. Hibernate, per esempio, permette di gestire il problema attraverso outer join (un solo gigantesco caricamento). Purtroppo BK non offre alternative...
il supporto è ottimo, ma la comunità è inesistente. La mailing list conta una decina di post al mese. Di conseguenza l'uso in software critici ne viene scoraggiato e qualche baco di tanto in tanto affiora.

Io l'ho usato in un progetto non particolarmente complesso, con piccole esigenze di persistenza. In queste condizioni BK si sta comportando ottimamente, risparmiandomi ore di lavoro senza nessuna reale contropartita. Per progetti Web non vitali e per software client gestionali medio-piccoli è l'ideale. Lo stesso autore Robert Brautigam ne incoraggia l'uso in problematiche semplici, mentre non lo reputa adatto a progetti complessi. Tanto di cappello alla sua onestà intellettuale.

Prova di invio da Google Documenti

2008-09-01T16:11:00.004+02:00

Questo post è scritto su Google Documenti e poi postato attraverso la funzione Pubblica. E' abbastanza semplice: dalla pagina di scrittura del documento, si preme su Condividi>Pubblica come pagina web... Qui, la prima volta che si usa il servizio, bisogna specificare la posizione del proprio blog (sia hosted che sul proprio spazio) e le credenziali di accesso. Le volte successive, basta tornare su Condividi>Pubblica come pagina web... e premere su Pubblica sul blog. Se poi servisse una modifica a livello più basso, ad esempio per modificare il CSS, basta andare sul menù Modifica>Modifica HTML. In questo modo posso abilitare i CSS per i frammenti di codice che pubblico:

<prova>
<di>
<formattazione>
   <XML/>
</formattazione>
</di>
</prova>

Questo potrebbe consentirmi di togliermi dai piedi l'editor di Blogger, scomodo e (almeno mi sembra) bacato.

Update: Qualche ritocco da Blogger serve cmq, a livello di formattazione del testo (molto poco) e di inserimento delle etichette, ma direi che l'esperimento è riuscito :-)

Prêt-à-portlét

2008-05-30T12:46:00.016+02:00

Il progetto su cui sto lavorando adesso prevede un portale B2B da cui un fornitore può offrire dei microservizi ad altre, fornendogli i relativi moduli per la configurazione e l'inserimento dei dati necessari al servizio stesso.
Dopo un giro tra le alternative ho optato per Liferay, un prodotto che conoscevo ma che non immaginavo fosse arrivato al livello a cui è.
Probabilmente è anche sovrabbondante per gli scopi del progetto, però supporta lo standard JSR-168, che consente di scrivere portlet indipendenti dal portale in cui vengono pubblicati.
Per chiarire meglio, un portale JSR-168 consente di ospitare nelle proprie pagine delle portlet, ovvero delle porzioni di pagina Web autonome che implementano un servizio (news, quotazioni di borsa, ma anche un blog, un wiki o un forum).
Un esempio di portlet è questo.

Scelta la tecnologia e il portale, mi mancava ancora il framework per implementare le portlet. Liferay ha un proprio approccio, ma lo trovo pesante e di certo non orientato a produrre portlet indipendenti dal portale.

Così ho scelto Spring MVC Portlet. Non conoscevo Spring MVC, ma conosco Spring. Spring è Il Framework. E' l'infrastruttura più leggera ed elastica che abbia mai provato. Migliora in maniera drastica la produttività e la qualità del codice pur rimanendo leggero e discreto. E' come Alfred per Bruce Wayne :).

Spring MVC Portlet è stata l'ennesima conferma. Dopo una configurazione iniziale non banale, ma logica, scrivere portlet è stata un'esperienza gratificante.
Spring MVC Portlet è organizzato come Spring MVC e ne riutilizza delle parti:

L'immagine è tratta dalla documentazione di Spring MVC, ma per grandi linee descrive bene anche Spring MVC Portlet.
Il gestore di tutto è il Front Controller (chiamato DispatcherPortlet nel framework) che riceve le richieste e le smista ai Controller o alle View.
Le regole di smistamento sono gestite in maniera limpida attraverso la configurazione XML.
Uno dei problemi è stato interagire con Liferay. E' vero che esiste lo standard, ma tanti servizi, come la gestione degli utenti, la fase di autenticazione, ecc sono lasciate ai vendor. Così ho seguito lo Spring-pensiero: ho implementato una interfaccia PortalSupport con le varie richieste di servizio al portale, e poi una sua implementazione LiferaySupport, che è definita nel context della portlet:


<bean id="portalSupport" class="example.theportlet.portal.liferay.LiferayPortalSupport">
</bean>

In questo modo, una classe che deve interagire con il portale dichiara una proprietà di tipo PortalSupport:


private PortalSupport portalSupport;

public PortalSupport getPortalSupport() {
return portalSupport;
}

public void setPortalSupport(PortalSupport portalSupport) {
this.portalSupport = portalSupport;
}

e dal context posso iniettare la particolare implementazione dove serve:


<bean id="baseControllerTemplate" abstract="true">
<property name="portalSupport" ref="portalSupport"/>
</bean>

Semplice, elegante, chiaro. Che è anche l'essenza di Spring.

Infine mi sono occupato della persistenza. Nei tipi di servizi da realizzare, il dominio dei dati è molto semplice, non più di 5-6 entità, con le classiche associazioni una a molti, uno a uno, ecc.
Non mi andava di usare Hibernate, francamente troppo complesso per un problema del genere, ma neanche SQL puro con tutti i suoi problemi di dialetti, script di DDL ecc.
Così, cercando, ho trovato Beankeeper. Signori, che ne dite di una libreria a cui basta dire:


store = new Store("org.hsqldb.jdbcDriver","jdbc:hsqldb:file:testdb");

Person person = new Person();
person.setFirstName(firstName);
person.setLastName(lastName);
store.save(person);

per salvare su DB il bean Person? Nota bene, non c'è codice nascosto né operazioni a priori. Si prende un DB vuoto, si prende il primo bean che passa, lo si passa a BeanKeeper e lui crea le tabelle analizzando il bean e lo salva. Punto. Stop.
Supporta automaticamente relazioni, ereditarietà, caricamento lazy, e ha un semplice linguaggio OQL.

Non è tutto rose e fiori, ma ne scriverò in un post a parte.

Geotagging di una nuvola

2008-05-23T18:47:00.004+02:00

Geotagging di una nuvola, inserito originariamente da Pietro Bonanno.

Questa nuvola è stata geotaggata utilizzando Nokia Location Tagger con il mio Nokia N80 e un ricevitore GPS Bluetooth accoppiato.
L'utilizzo è abbastanza semplice. Si installa il programmino, si esegue e si lascia girare in background. Ogni foto scattata con il normale software della fotocamera verrà completato con le indicazioni di georeferenziazione. Attenzione, non funziona con la fotocamera secondaria.

Purtroppo su Flickr qualcosa sembra non funzionare: le coordinate vengono arrotondate a 38°0' 00" N, 13°0' 00" E. Basta vedere la pagina dei metadati per accorgersi che in realtà sono 38° 9' 27" N, 13° 18' 56" E, per cui l'immagine da Palermo va a finire ad Alcamo!

Nei forum si sostiene che ciò sia dovuto al software di upload Nokia Online Share. Non so neanche cosa sia, io ho usato il normale form di upload di Flickr.

L'assistenza mi ha dato l'improbabile risposta che il problema sia dovuto ad errori nelle mappe, fornite da terzi. E' abbastanza assurdo perchè si vede benissimo l'errore di troncamento.

Infine, la stessa foto su Picasa Web è georeferenziata correttamente.

Eccolo!

2008-04-11T14:18:00.008+02:00

Eccolo qua, la tentazione è stata troppo forte... il cambio Euro-Dollaro ha fatto il resto.

Acquistato a $ 280 + $ 40 di spedizione (UPS, impeccabili) su B&H Photo, al cambio sono poco più di € 200, esattamente il mio punto di rottura per cedere all'acquisto.

E' come me l'aspettavo, un prodotto funzionale, comodo ma non ancora allo stato dell'arte.

Il problema è sopratutto nella tecnologia E-ink, ancora troppo giovane. Il contrasto è perfetto e sembra di leggere una vera pagina cartacea, ma i tempi di refresh sono nell'ordine del secondo.

Questo non rende difficoltosa la lettura, ma le modalità d'interazione. Non ho la certezza, ma da sviluppatore posso pensare che un tempo di refresh così lungo abbia creato non pochi problemi a chi ha concepito l'interfaccia utente. Infatti mancano funzioni come la ricerca testuale (né dei titoli, né all'interno del testo), o segnali visivi di feedback quando premi i vari pulsanti. Invece hanno utilizzato una fila di 10 pulsanti per selezionare l'elemento corrispondente in una lista.

Una soluzione che è un buon compromesso, comoda e intuitiva.

I pulsanti per scorrere le pagine sono sia a destra che a sinistra, quindi è facile leggere un libro nelle più svariate posizioni (con un libro cartaceo servirebbero tutte e due le mani :-) ).

Uso libprs500 come applicazione per caricare e catalogare gli ebook, non ho neanche provato a usare quello fornito da Sony. Questo software è open source, immediato e ricco di funzioni (tra cui l'utilissima conversione nei vari formati per ebook). Indispensabile.

Il problema più grave è il supporto ai PDF. Per dare un'idea, questa è la resa di una pagina in PDF al massimo ingrandimento:

Questo è invece un ebook in formato LRS (un formato proprietario Sony), al minimo ingrandimento:
Il problema dei PDF è noto, ed esiste anche qualche soluzione (che non ho ancora provato).

In ogni caso per € 200 è senza dubbi un buon acquisto.

Perchè il mio tavolo di Google cerca il Internet del contatto?

2008-04-08T17:27:00.006+02:00

Ora, capisco che i traduttori automatici sono un modo semplice ed economico per attirare qualche lettore nel proprio sito. La traduzione è quella che è, ma anche il proprio sito è quello che è.

Ma perché farlo in un blog che parla di programmazione??

Magari perchè vendo un software di traduzione automatica? Spero di farmi pubblicità con traduzioni del genere?

Hai cercato Master-Master replica (bi-direzionale di replica master-slave), per MySQL? Io sono me stesso e trovare una posizione in cui ho bisogno di avere questa replica a sostenere il carico sul mio blog e siti.

Openfire (assistente di Jabber/XMPP) per difetto si lega su orificio 8080 che inoltre è usato da Tomcat. Ciò induce Tomcat a venire a mancare quando il openfire è iniziato prima di esso. (orificio?? NdPB)

La comunicazione fra i Java applei È stata un soggetto interessante dai giorni in anticipo di Java. Ci sono parecchi sensi esoterici comunicare come usando il Javascript come ponticello. Tuttavia esamineremo il metodo attendibile più semplice e della comunicazione del intra-applet.

Usi un codice categoria con i metodi statici degli incastonatori e dei degasatori per passare i dati intorno.

Avete saputo che persino l'adobe Photoshop funziona in Linux usando il vino?
Il vino può eliminare il vostro dolore di espansione da Windows (a Linux).

Ma sanno leggere?

2008-03-28T12:48:00.004+01:00

Ho intenzione di acquistare un EBook Reader Sony PRS-505, un aggeggino che sembra ben riuscito, a leggere i giudizi un pò ovunque.

Purtroppo pare che non sia commercializzato fuori USA, così ho fatto la solita incursione su EBay.

Ora, esiste una logica per cui io dovrei acquistare su EBay a prezzi più alti che nel sito Sony? NB: ci sono dei pezzi a 270$ venduti da un certo hypatiaway, ma gli ho scritto e non ha risposto. Non rischio 300$ così...

Capisco il desiderio di averne uno da chi non abita negli USA, ma l'alternativa c'è eccome...

Evidenziazione della sintassi su Blogger

2008-03-07T12:16:00.006+01:00

Mi sono finalmente deciso a configurare Blogger per visualizzare blocchi di codice formattato. Ho utilizzato SyntaxHighlighter, un ottimo tool javascript che agisce tramite CSS.

Ho seguito le istruzioni sul blog Morten Lyhr e tutto ha funzionato egregiamente. L'unico piccolo problema è individuare lo spazio web dove sistemare gli script da utilizzare poi nei post.

Lui ha preferito utilizzare le directory SVN di Google Code.
Io trovo più naturale utilizzare invece lo spazio dedicato a Google Pages. Con una semplice interfaccia Web si caricano sullo spazio i vari script e si includono poi nel template in maniera diretta (per es. http://piebonanno.googlepages.com/shCore.js).

Per festeggiare, ho riconvertito il mio post su Hibernate e dialetti SQL. Il risultato non è ancora ottimale, ma è già un passo avanti.

update 30/05/2008: Ho sostituito SyntaxHighlighter con Prettify, mi piace di più.

...

2008-03-06T15:19:00.004+01:00

Non ce la faccio. Non ci riesco. Svengo.

Bibliografia essenziale

2008-01-10T11:38:00.001+01:00

Bibliografia essenziale, inserito originariamente da Pietro Bonanno.

Post autoreferenziale

2008-01-08T18:13:00.000+01:00

Con una notevole faccia tosta, dopo un'assenza di settimane da questo blog, pubblico il mio Curriculum Vitae.

Essendo questo (almeno nelle intenzioni) un blog tecnico che riguarda la mia professione, mi sembrava una mancanza non da poco.
Spero anche di scrivere qualcosa, in particolare sulla pratica del continuous integration che vorrei mettere in piedi anche per piccoli progetti (team da 2-4 persone).
Intanto sto assemblando i vari tool che aiutano nel processo: in breve, Maven 2, un server SVN, Continuum e, almeno per i test, un semplice SMTP server. Mi pare non serva altro, a parte i framework di test.
Anzi se qualcuno volesse chiaccherarne (anche in privato), ne sarei lieto.

Adesso é Natale

2007-12-10T14:21:00.001+01:00

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

Work-trash-pop art

2007-11-26T21:04:00.001+01:00

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...

Strano ma vero

2007-11-13T10:17:00.000+01:00

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.

Alla ricerca del Santo Graal - Reprise

2007-11-08T20:58:00.000+01:00

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 :-)

Altro che coltellino svizzero

2007-11-07T21:08:00.000+01:00

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.

Nokia N80 vs Puppy Linux, il segno dei tempi

2007-10-31T23:05:00.000+01:00

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).

SQL indipendente dal dialetto con Hibernate

2007-10-19T19:30:00.015+02:00

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.

Castomer cher

2007-10-09T14:05:00.000+02:00

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?

2007-10-09T12:00:00.000+02:00

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 :-)

Il miio meediacenter con Meedio - Prima parte

2007-10-07T21:29:00.000+02:00

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:

memorizzare in maniera ragionevolmente sicura i miei video (vacanze/feste, ma anche film e serie TV)
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è.

Rails Rumble? Pfui

2007-10-04T15:54:00.000+02:00

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

Yeah, baby, yeah!

2007-09-27T11:42:00.000+02:00

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.

Wicket mumbling

2007-09-25T15:58:00.000+02:00

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.

Umorismo involontario a RGS

2007-09-05T11:29:00.000+02:00

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

Promemoria: monitorare un log da remoto su Unix/Linux

2007-08-30T13:23:00.000+02:00

Il seguente comando:

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

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

Alla ricerca del Santo Graal...

2007-08-20T14:39:00.000+02:00

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

The Big Bang

2007-08-11T12:37:00.000+02:00

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?