While playing with it, I was wondering, which is the coolest feature introduced in this new release? Well, if you are a user, it should be the full screen support for native HTML5 video. If you are a developer, it may be the new CSS enhancements. But, what if you are a Macbook user?

If you are a Macbook user, it will surely be the detection of the notebook orientation using its integrated accelerometer.

There are a bunch of demo showing this new functionality, they were so exciting I wanted to build one on my own. So, here it is a brand new orientation bookmarklet:

SteerMe

Simply drag and drop the SteerMe button into the bookmarks toolbar of Firefox, or copy its link and manually create a new bookmark. Then, go to a new web page, press the newly created bookmark and begin to rotate your Macbook.

You will see the page still vertical while you rotate the notebook on the left and on the right, you will see it stretched and tightened while you move the keyboard up and down. And you will see the page bounce when, ehm…, you drop your precious notebook!

Tablet-like visualization with Macbook rotated on the left

Stretched page with keyboard upside down

How does it work? This is the bookmarklet code with extra spaces:

1
2
3
4
5
6
7
8
9
10
11
12

window.addEventListener &&
window.addEventListener("MozOrientation", function(e) {
    var h = innerHeight,
        ox = scrollX + innerWidth / 2,
        oy = scrollY + h / 2,
        bs = document.body.style;
    bs.MozTransformOrigin = ox + "px " + oy + "px";
    bs.MozTransform = "rotate(" + (90 * e.x) + "deg) " +
                      "scaleY(" + (e.y + 1) + ") " +
                      "translateY(" + (-h * (e.z + 1)) + "px)";
}, true);
void(0);

As with every bookmarklet, its Javascript code must be as short as possible and tends to be quite obfuscated, but it is very simple. First of all, we will listen to the new MozOrientation event on the window object. Then we will apply a CSS transform to the body of the page using the event orientation data.

Poi però ho guardato bene l’email… e poi mi è tornato in mente un episodio…

L’anno scorso avevo provato ad iscrivermi a Facebook, dopo l’inserimento iniziale dei dati sono rimasto in attesa dell’email di conferma registrazione. Ho atteso minuti, ho atteso ore e poi giorni… l’email non è mai arrivata. Tutto questo lo scorso settembre, settembre 2008.

Allora riguardo bene l’email, eccola qui:

Email di conferma registrazione di Facebook

L’email è originale! È stata generata proprio a seguito della mia registrazione.

Ma allora a chi è dovuto tutto questo ritardo? Non ci resta che dare un’occhiata agli header del messaggio:

Received: from [10.18.255.137] ([10.18.255.137:39141]) by
  mta003.snc1.facebook.com (envelope-from <update+pfvglef@facebookmail.com>)
  (ecelerity 2.2.2.37 r(28805/28844)) with ECSTREAM id A3/82-29819-179B5AA4;
  Mon, 07 Sep 2009 18:54:57 -0700

Il primo degli header Received indica chiaramente che il messaggio veniva smistato dal sistema di posta di Facebook solo qualche giorno fa, la colpa sembra quindi essere proprio del grande social network.

Non c’è che dire, gli anni passano, caro Facebook…

È per una buona causa, spendete 15 minuti per compilarlo, c’è tempo ancora per pochi giorni.

Notizia su OpenID sul Corriere della Sera

C’è una buona notizia sul Corriere di oggi.

Non si tratta di una notizia intesa nel senso comune di pubblicazione di un avvenimento di cronaca o attualità, ma di un episodio molto positivo che riguarda l’edizione web del Corriere della Sera e più in generale l’approccio alla rete dei principali media mainstream.

Nella rubrica Zapping News del Corriere di oggi, la colonna centrale azzurra solitamente dedicata a notizie morbose come la pubblicazione dell’ultimo calendario, grottesche come la premiazione degli addominali di Beckham e l’ultima cura contro il raffreddore, o bizzarre come la scimmia inafferrabile a Tokyo, troviamo un bell’articolo a firma Lavinia Hanay Raja che ci parla della controversa adozione di OpenID da parte di Google e Microsoft.

La perizia e la competenza con cui l’articolo è stato scritto lasciano felicemente sorpresi: descrizione puntuale e precisa, contestualizzazione della tecnologia ed analisi pienamente condivisibili.

Siamo probabilmente e fortunatamente ormai lontani dal tristemente noto articolo di Luca Panerai apparso anni fa su Panorama Next, ma il rischio di ritrovare titoli a piena pagina ed articoli su fantomatici hacker che bucano sistemi della CIA e diventano milionari con la loro doppia vita trascorsa nell’oscurità è purtroppo ancora alto.

Per questo motivo, l’articolo di Hanay, ultimo di una serie di collaborazioni con il Corriere, lascia ben sperare che, un po’ alla volta, anche sui grandi giornali la situazione migliori.

Android is the first free, open source, and fully customizable mobile platform.

Eppure, nei Terms of Service dell’Android Market, si legge:

Google may discover a product that violates the developer distribution agreement … in such an instance, Google retains the right to remotely remove those applications from your device at its sole discretion

Sembra piuttosto contraddittorio, non credete?

“Open source” non è un’etichetta da applicare al proprio software per attirare l’attenzione e riempire qualche titolo di giornale. O il software è libero, oppure hai il controllo sul software.

Sbaglio o dalla tastiera dei nuovi MacBook è scomparso il simbolo della mela?

Update: Giulio nei commenti fa giustamente notare che il simbolo era scomparso dalle tastiere Apple già da qualche mese. La tastiera dei MacBook appena usciti è comunque nuova, sono infatti scomparsi tutti i simboli ad eccezione di quello del punto di interesse, niente simboli per Shift, Caps Lock, Tab e Delete e addirittura per il tasto Enter!

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!

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

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.

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.

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

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…

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.

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.

In questo blog, cerco di analizzare le caratteristiche di nuovi siti, per valutare come un semplice utente interagisca con essi.

Inoltre, descrivo nuovi strumenti e tecniche di programmazione, per presentare le novità nell’ambito dello sviluppo web.

Buona lettura!