www.webmess.it: nuovo dominio

7 10 2008

WebMess ha finalmente un nome a dominio dedicato: www.webmess.it.

Purtroppo non mi è possibile attivare una funzione di redirect automatico sul vecchio blog verso il nuovo spazio, invito quindi tutti a visitare direttamente il nuovo sito a questo indirizzo:

http://www.webmess.it

I nuovi post compariranno unicamente su quest’ultimo sito.

Per chi invece avesse sottoscritto il feed RSS del blog, questo è il nuovo indirizzo da utilizzare per la sottoscrizione:

http://www.webmess.it/feed

Infine, un ringraziamento particolare a Matteo che, non rendendosi conto di tutte le pedanti richieste che presto lo sommergeranno, mi ha concesso gratuitamente lo spazio sul server. Grazie!





Qui, qui e qui

30 09 2008

Non ci sono buoni motivi per scrivere “qui” come contenuto di un link. Quante volte vi sarà capitato di leggere articoli e di trovare frasi come: per approfondimenti si veda qui, il prodotto si trova qui, per scaricare andate qui…

Non fatelo, astenetevi.

Purtroppo anche siti importanti come Punto Informatico adottano questa pratica, ma è completamente da sconsigliare.

Il contenuto di un link (il testo compreso tra i due tag <a> e </a>) dovrebbe infatti essere il più possibile indipendente dal suo contesto, si dovrebbe capirne lo scopo ed intuirne la destinazione semplicemente analizzando il testo associato, senza dover necessariamente leggere l’intera frase in cui appare.

Non si tratta soltanto di un problema stilistico, ci sono anche importanti questioni tecniche a vantaggio di questa scelta:

Indicizzazione: i motori di ricerca utilizzano il testo associato ad un link per individuare le parole chiave da associare ad una pagina web. Questo meccanismo è così importante che viene addirittura utilizzato per effettuare il cosiddetto Google bomb (famosissimo il caso di miserable failure associato alla biografia di Bush, che tra l’altro è ancora visibile nei risultati di Yahoo!)

Accessibilità: nell’utilizzo di dispositivi non standard oppure nel caso di utenti con disabilità, può capitare che ci si sposti da un link all’altro semplicemente premendo il tasto TAB della tastiera. Si arriverebbe quindi su di un link senza aver letto la frase che lo precede.

Usabilità: capita molto spesso, più spesso di quanto si possa pensare, che un utente che visiti un sito non ne legga in modo sistematico il contenuto ma si limiti a guardare velocemente le varie parti che lo compongono cercando quelle di maggiore interesse. È quindi importante che un link ed il suo scopo possano essere identificati in modo immediato.

Questi argomenti dovrebbero essere più che sufficienti: bandite la parola “qui” dai vostri link.





Statistiche sui click in uscita

21 09 2008

Guardando le statistiche di questo blog, sono rimasto incuriosito da una particolare sezione: quella riguardante i link che hanno ricevuto più click dai visitatori.

Statistiche dei click sui link in WordPress

Statistiche dei click sui link in WordPress

Mi chiedevo infatti come facesse WordPress ad avere questo tipo di informazioni. Per le altre sezioni ottenere i risultati è relativamente facile, i link utilizzati per arrivare verso questo blog ed i termini utilizzati sui motori di ricerca si ottengono semplicemente analizzando il campo Referer HTTP. Ma quando si fa click su di un link, il browser effettua soltanto una connessione verso il server che ospita la nuova pagina, senza segnalare nulla a quella che si sta per lasciare.

La risposta a questo dubbio è data da quella piccolissima immagine a forma di smile, che si trova in fondo ad alcuni blog WordPress, compreso questo:

Immagine utilizzata per le statistiche sui click in uscita

Immagine utilizzata per le statistiche sui click in uscita

Scendendo in dettagli tecnici, ogni volta che si visita una di queste pagine, viene caricato il file JavaScript w.js dal server delle statistiche di WordPress. Questo script definisce una serie di funzioni (scritte per la verità in modo un po’ criptico e con uno stile non del tutto chiaro ed uniforme) che costituiranno il meccanismo con cui segnalare i click in uscita.

Una di queste è linktracker_init(), eseguita al caricamento della pagina aggiunge un listener sul body in modo da intercettare ogni click effettuato all’interno di quanto visualizzato. Ad ogni click verrà così eseguita la funzione linktrack() che, dopo aver verificato che questo sia avvenuto su di un link diretto verso un indirizzo esterno al proprio blog, costruirà un URL destinato verso il server delle statistiche e contenente l’indirizzo del link che si sta per visitare, per poi eseguire queste istruzioni:

var x=new Image(1,1);
x.src = src;

Lo script quindi creerà una nuova immagine che corrisponde proprio allo smile visualizzato sopra, la cui richiesta di caricamento permetterà l’invio delle informazioni necessarie al server delle statistiche.

L’utilizzo di un’immagine come meccanismo per l’invio di informazioni ad un server può sembrare in apparenza una tecnica un po’ esotica, soprattutto se confrontata con le ben più comuni richieste AJAX. Purtroppo però la limitazione di same origin policy, che si applica alle richieste AJAX, non avrebbe permesso di contattare un server con un hostname differente da quello associato al proprio blog. Ecco perché probabilmente hanno scelto di caricare un’immagine.





CSS transform in Firefox 3.1

17 09 2008

Per gli sviluppatori web, Firefox 3.1 sembra riservare sorprese decisamente interessanti, nonostante l’incremento del solo minor number della versione.

Una di queste consiste nella nuova proprietà CSS transform che per il momento sarà utilizzabile con il nome proprietario -moz-transform. Mutuata da WebKit, questa proprietà permetterà di applicare trasformazioni come rotazioni, traslazioni o variazioni di scala agli elementi delle proprie pagine web.

Mi sembra il modo giusto di procedere, da convinto sostenitore della separazione tra presentazione e contenuto credo che il potenziamento delle funzionalità fornite dai fogli di stile CSS sia il modo migliore per poter realizzare interfacce accattivanti, senza dover ricorrere ad un uso eccessivo di immagini o, peggio ancora, a prodotti proprietari.





Elemento video in Firefox 3.1

12 09 2008

Pochi giorni fa è stata rilasciata la seconda versione alfa di Firefox 3.1. Questa introduce, oltre ad altre novità che varrà la pena di analizzare in futuro, il supporto preliminare all’elemento <video> previsto dalla bozza di standard di HTML 5.

L’elemento <video> ha lo scopo di semplificare decisamente l’inclusione di filmati all’interno delle proprie pagine web, rendendone l’inserimento facile come l’utilizzo di immagini attraverso il tag <img>.

In dettaglio, l’inserimento del video avviene utilizzando codice HTML di questo tipo:

<video controls="controls" src="URL filmato"></video>

L’elemento potrà inoltre contenenere altro codice HTML, come testo o immagini, che saranno visualizzati dai browser non compatibili, al posto del filmato.

In Firefox 3.1 l’unico formato supportato sarà Ogg Theora con audio Ogg Vorbis e per la decodifica non verrà utilizzato alcun tipo di plugin. All’interno dei sorgenti sono state infatti direttamente incluse le librerie sviluppate dalla fondazione Xiph.Org.

Presso il blog degli sviluppatori del browser Opera, è possibile trovare alcune pagine di esempio che utilizzano questo nuovo elemento HTML. Visitandole con la nuova versione alfa di Firefox, si potrà verificare direttamente quali risultati si possano ottenere:

Elemento <video> in Firefox 3.1 alfa 2

Elemento <video> in Firefox 3.1 alfa 2

Rimane soltanto da fare un’ultima considerazione: la creazione di nuovi elementi come <audio> e <video> delinea una filosofia alla base dello sviluppo del nuovo standard HTML 5 che non ritengo completamente condivisibile. Per la visualizzazione di filmati o audio, escludendo il diffusissimo ricorso ad appositi player in Flash, era già disponibile l’elemento <object>, che ha il vantaggio di essere generico e quindi adatto a qualsiasi utilizzo non inizialmente previsto. Il rischio che si corre è infatti quello di abbandonare la strada intrapresa dal W3C che aveva portato alla differenziazione tra documenti HTML Transitional e documenti HTML Strict.

I nuovi elementi presentano comunque dei vantaggi, come ad esempio la disponibilità di un’API JavaScript studiata appositamente per la gestione di oggetti multimediali. Inoltre si potrebbe addirittura ottenere come effetto collaterale la diffusione e l’eventuale successo di un formato video standard e libero da royalty, se solo il working group di HTML 5 riuscisse a raggiungere un consenso al riguardo…





WordPress hacker

3 09 2008

Sono stato piuttosto indeciso sull’opportunità o meno di pubblicare questo post, ma visto che altri prima di me ne hanno già parlato, ho pensato che in fondo non fosse più un grande segreto.

Ecco infatti cosa compare tra gli header HTTP delle pagine ospitate su wordpress.com:

X-hacker: If you're reading this, you should visit automattic.com/jobs and apply to join the fun, mention this header.

Non c’è che dire, è decisamente un modo molto originale e simpatico per offrire un posto di lavoro.





Google Chrome, yet another browser?

3 09 2008

La notizia del giorno è senza alcun dubbio la presentazione del browser Chrome da parte di Google, una notizia che giunge decisamente inaspettata considerando gli stretti legami che intercorrono tra BigG e Mozilla.

Vale sicuramente la pena di approfondire la questione per vedere se questo nuovo browser presentato possa portare innovazioni e miglioramenti oppure se non si tratti che di un ulteriore altro browser, in aggiunta a Internet Explorer, Firefox, Safari e Opera, e con il quale noi sviluppatori web dovremo fare i conti.

La prima considerazione da fare riguarda l’eventuale successo che potrà avere Chrome: sono piuttosto scettico sulla possibilità che possa guadagnarsi una discreta quota di mercato. Il caso di Safari 3 insegna, si tratta di un browser dalle ottime caratteristiche tecniche ma la sua diffusione è praticamente irrilevante.

Google non è Microsoft che distribuisce Windows con Internet Explorer pre-installato su quasi ogni nuovo computer venduto, sarà difficile superare questa inerzia e convincere gli utenti ad installare un programma nuovo. Firefox ha impiegato anni per ritagliarsi la propria nicchia di mercato ed ha potuto contare sul supporto dell’intera community open source ed importanti campagne pubblicitarie.

Difficile quindi che Google Chrome possa contastare lo strapotere di Internet Explorer.

Detto questo, passiamo alle sue caratteristiche tecniche.

Chorme adotta il motore di rending Webkit, si tratta di un’ottima scelta. Webkit è un ottimo progetto, dalle prestazioni eccellenti.

A mio parere la novità più importante consiste nell’utilizzo di un processo separato per ogni tab aperto nel browser. Si tratta di una soluzione definitiva e che avremmo dovuto vedere implementata in qualsiasi browser esistente, non bisogna infatti mai dimenticare la lezione di Eric Raymond sull’utilizzo dei thread al posto di processi separati. I crash dell’intero browser, con tutti i suoi tab e le sue finestre aperte, a causa di un semplice bug di un qualsiasi oggetto flash è un’esperienza purtroppo nota ad ogni utente. Riguardo ai thread, Raymond ricorda che: “… These are a recent import from elsewhere, … the idea of threads is native to operating systems with expensive process-spawning and weak IPC facilities. …”. Con elsewhere ci si riferiva molto probabilmente a Windows, ne deriva quindi un’ulteriore perplessità, oltre a quelle già esposte in altri blog, sulla scelta di rendere disponibile Google Chrome soltanto per questa piattaforma.

Infine una nota riguardante l’implementazione dell’interprete JavaScript. Non c’è alcun dubbio sul fatto che in futuro le applicazioni web renderanno necessarie prestazioni elevate anche nell’esecuzione di codice JavaScript. Google Chrome risponde a quest’esigenza con l’utilizzo della macchina virtuale V8. Viene definita la più rapida tra quelle in circolazione, ma in realtà il confronto vero dovrebbe avvenire con SquirrelFish di Safari e TraceMonkey per Firefox. Sarà interessante vedere come si evolverà la situazione.

Update: Wayne Pan e John Resig hanno pubblicato alcuni benchmark confrontando le prestazioni degli interpreti JavaScript esistenti. V8 di Chrome è il più performante nella maggior parte di questi test, il dato più importante mi sembra comunque il grande aumento di prestazioni portato dalla nuova generazione di interpeti.