Nello sviluppo di applicazioni web, negli ultimi anni, ho cercato di portare il più alto numero possibili di controlli applicativi verso il server e scaricare il browser (client) da problemi di incompatibilità e fragili funzioni javascript. Questo mio ragionamento mi ha portato a creare design semplici, funzionali e liberi da grafica o funzionalità client più o meno complesse. A rafforzo di questa pratica, c'è sempre stato poi l'annoso discorso delle velocità (o lentezza) di caricamento di una pagina, compromessa dalla quantità di immagini, filmati e flusso di dati (ad esempio se si deve visualizzare una tabella complessa con molte colonne e righe). Con l'invio di un form o il click di un link, si server deve rimandare l'intero contenuto della pagina e questo incide sul design, sulla tecnologia adottata, sulle prestazioni del server, sull'occupazione della banda (hai un contratto a traffico? navighi da un pda? da un cellulare? allora sai di cosa parlo...).
Da qualche hanno è stato introdotto il concetto di richiesta asincrona, ossia l'invio di una richiesta inviata al broswer senza che l'intero contenuto della pagina venga aggiornato (sincronia) con la risposta del server. Questo messaggio di ritorno viene gestito in background e poi manipolato apportunamente per poi essere mostrato all'utente. Questa tecnica è chiamata Ajax.
Nelle ultime settimane mi sto dedicando intensamente allo sviluppo di un'altra applicazione web e questa volta ho deciso di sprerimentare anche io, con le mie mani, Ajax ed introdurre alcune funzionalità di sicuro impatto funzionale e di miglioramento dell'usabilità per l'utente.
(nota tecnica: l'applicazione viene sviluppata utilizzando Java, Struts, Hibernate, Postgresql e Ajax).
La decisione di implemetare Ajax sulle pagine, mi sta portando però ad un uso intenso di javascript, con il risultato che molti controlli però li devo portare verso il client. E' una soluzione che non mi rende felicissimo, ma ne sono in qualche modo obbligato, perchè la non sincronia tra le richieste (e quindi la relativa storia temporale) non è facilmente ricreabile e tracciabile (lo sarebbe, ma non voglio appoggiarmi ancora di più su javascript, ne tanto meno usare i cookies). Per questo devo scendere a compromessi applicativi, ma devo dire che l'esperienza generata dall'uso di un'applicazione web in cui si applica Ajax è veramente superiore al piccolo fastidio nel dover cambiare alcuni paradigmi di sviluppo su cui ho basato nell'ultimi anni lo sviluppo delle mie applicazioni.
Visto che ho citato anche Hibernate, ammetto che anche l'utilizzo di questo ORM mi ha semplificato a livelli astronomici lo sviluppo in java e la gestione dei dati.
Ho completamente rivoluzionato il mio modo di scrivere codice. E ne sono contento. :)
Ajax e le sue implicazioni client
giornate calde...
...e non mi riferisco solo all'afa che attanaglia queste giornate milanesi estive del 2007.
Sono giornate di fuoco anche per il lavoro.
Ho passato lo scorso weekend ancora in ufficio a lavorare per un cliente.
A volte mi domando perchè, alcune società, nonostante abbiamo sul libro paga delle figure "manageriali" (a volte anche tecniche), non si rendono conto che non possono chiedere due giornate di lavoro per integrare delle modifiche su un'applicazione web java vecchia di 4 anni sviluppata da altri. Quelle due giornate mi sevono solo per capire che fà quell'applicazione, per capire quale classe richiama cosa e come potrei inserire le nuove feature richieste.
Ieri sono entrato nell'ufficio di questo cliente alle 8.30 del mattino e ne sono uscito alle 20.15 (bhè..l'aria condizionata a palla è forse la cosa più bella che c'è li dentro).
Nonostante un paio di minuti di sconforto per la complessità di quell'accrocchio applicativo (superato con un pò di caffeina e, in via del tutto eccezionale, con un pò di nicotina), alla sera il codice ha cominciato a fare quello che gli ho chiesto e il mio java-neurone era soddisfatto...con buona pace del cliente e mia.
encoding java da Windows a Linux
Sto migrando tutti i miei progetti java da Windows a Linux. In questi giorni devo fare una modifica su un paio di classi e questa è l'occasione buona per riconfigurare l'ambiente di sviluppo migrandolo da windows a linux.
Installare Eclipse ed Exadel è un giochetto da ragazzi, così come riconfigurare i vari build path necessari ai progetti.
Al primo tentativo di build con Ant però mi sono trovato con una lista infinita di warninigs. Ok, il build è andato a buon fine, ma quei messaggi sono un pò fastidiosi.
il messaggio dice: "warning: unmappable character for encoding UTF8".
Urca! ma che scherziamo?? Io parlo l'iso-8859-15, mica il povero e ridotto utf8 :)
Come mai quando compilavo su Windows questo messaggio non compariva?
Google-izzo il problema e capisco che il problema dipende dall sequenza di byte specifici del set di caratteri iso8859-1 con cui il file è stato scritto e che non trovano una corrispondenza con i caratteri utf8 del nuovo sistema (anche se i pacchetti iso-8859.1 sono stati installati). Ad esempio, i caratteri accentati vengono trasformati con un punto di domanda su sfondo scuro.
La soluzione è molto semplice: specificare ad Ant, anzi, per essere precisi al Javac, l'encoding di riferimento. Nel build.xml si deve indicare l'attributo encoding="iso8859-1". Il mio è:
<javac srcdir="${src.dir}"
destdir="${build.dir}"
debug="on"
deprecation="on"
target="1.5"
encoding="iso8859-1">
<include name="**/*.java">
<classpath refid="project.class.path">
</javac>
Per i curiosi: target="1.5" mi serve per un problema di incompatibilità tra java 1.5 e 1.6...ed essendo il server di produzione ancora 1.5 (magari lo upgrado...) devo dire anche qui a Javac come comportarsi.
