Enoela

Franz Ferdinand live @Bologna

Bologna, 29 marzo 2009. Estragon.
Arrivano da Glascow i Franz Ferdinand per un prevedibile tutto esaurito all’Estragon di Bologna. Già da più di un mese i biglietti per questo concerto erano introvabili confermandomi l’idea che forse per un gruppo così noto l’Estragon risultasse troppo piccolo.

I Franz Ferdinand esordiscono in modo travolgente con il primo album del 2004 (l’omonimo Franz Ferdinand, 2004, domino records), premiatissimo dalla critica e dal pubblico. Segue nel 2005 il meno convincente You Could Have It So Much Better e dopo lunga attesa un grandissimo ritorno con il terzo album Tonight: Franz Ferdinand, ancor più bello e interessante dell’album di esordio.

Spettacolo straordinario con larghissimo spazio ai brani più “punk” e ritmati. I ragazzi ce l’hanno messa tutta e sono arrivati stremati alla fine dei 70 minuti scarsi di concerto. Acustica ottima. Ogni strumento aveva il suo spazio compresa la voce di Alex Kapranos (voce e chitarra), sfrenatissimo. Più pacato il secondo chitarrista, Nick McCarthy (chitarra e tastiere). Una sfinge come qualsiasi bassista che si rispetti, Bob Hardy (basso). Una furia scatenata (ha suonato a torso nudo) il batterista Paul Thomson.

Insomma un concerto indimenticabile.

Meriterebbe invece un rapido oblio l’organizzazione.
(continua…)

Cross-site XMLHttpRequest

Il W3C ha pubblicato il working draft della versione 2.0 di XMLHttpRequest (la libreria che permette ad Ajax di esistere). Tra le novità di rilievo della nuova versione, la possibilità di eseguire cross-site request, aprendo la possibilità di utilizzare web service e syndication da siti terzi:

11. The previous level of this specification raised a SECURITY_ERR at this place in case of a non same origin stored url. This specification supports non same origin requests and therefore this exception is no longer raised here.

[XMLHttpRequest Level 2 -W3C Working Draft 30 September 2008]

Oggi questa possibilità è negata per motivi di sicurezza. Per visualizzare, per esempio, un feed rss di un sito “terzo” devo effettuare la syndication del contenuto sul server. Devo predisporre uno script server side che processi il feed e generi il codice HTML che il server principale può quindi trasmettere al client.. Il browser dell’utente non mi autorizza a compiere questa operazione direttamente sulla pagina via javascript. XMLHttpRequest, ad oggi, non può comunicare con server diversi da quello che ha trasmesso il documento che desidera effettuare la richiesta. La libreria è nata così e il W3C ne ha acquisito le specifiche nel proprio standard.

La motivazione della sicurezza potrebbe essere accettabile se non fosse permessa la più “audace” esecuzione di  generico codice javascript trasmesso da un sito terzo. Da sempre posso, cioè, caricare sulla pagina script provenienti da server terzi, con conseguenti rischi sulla sicurezza (cross site scripting vulnerabilities) e la privacy. Oggi non possiamo scaricare dati da server terzi all’interno della libreria XMLHttpRequest, ma possiamo eseguire codice javascript arbitrario. Una limitazione decisamente poco sensata.

Ed è decisamente tardi per tornare indietro e limitare l’esecuzione di scripting da siti terzi. E’ grazie ad esso che possiamo inserire con estrema semplicità la pubblicità sulle nostre pagine e possiamo, per esempio, monitorare il clickstream sul nostro sito tramite servizi come google analytics o crazyegg. Insomma, non siamo più disposti a rinunciare allo scripting remoto e quindi la direzione evolutiva è scontata: ben venga, al più presto un consolidamento dello standard W3C (oggi è ancora nello stato di working draft, una bozza) e, soprattutto, la sua implementazione nei browser.

Per inciso, firefox 3, durante la fase finale del processo di beta-testing, aveva rilasciato una versione con cross-site XMLHttpRequest, subito ritirata. Peccato. Forse la sua diffusione ne avrebbe tratto vantaggi.

Ma il fumetto su chrome l’avete almeno sfogliato?

Tra gli eventi della settimana senz’altro possiamo annoverare il rilascio della beta di Chrome, il google-browser. Ho già letto diversi commenti più o meno dettagliati e più o meno appropriati e devo ammettere di condividere solo parzialmente molte delle opinioni espresse.

Molti esprimono dubbi sulla necessità di un altro browser. Perché? Maggiore è il numero di browser utilizzati, minore sarà la rilevanza del singolo, più il web dovrà attenersi agli standard con gioia di chi il web l’ha concepito a tutela della sua apertura e diffusione. Mai più leggeremo “ottimizzato per …”. O ce ne siamo dimenticati?

In diversi si sono soffermati sui dettagli di interfaccia (peraltro l’essenzialità di chrome è tutt’altro che criticabile) sostenendo che c’é poco di innovativo e che quindi potevamo fare a meno dell’ennesimo browser (di nuovo!).

C’è chi ha rinnovato l’accostamento dell’emergente monopolio di google a quello che ha caratterizzato il nostro medioevo informatico (questa è una mia definizione), ma questo è un punto troppo delicato da affrontare tra le pieghe di un post.

Qualcuno ha accennato agli aspetti più interni del browser, parlando di efficienza e affidabilità centrando, a mio parere, il vero scopo di questo progetto.

Dalla veloce (e incompleta) lettura del fumetto mi è sembrato di capire che la motivazione fondamentale, se non l’unica, che ha spinto google a progettare un altro browser sia stata la necessità di supportare meglio le Rich Internet Application (RIA): maggiore velocità e, soprattutto, maggiore affidabilità. Qui parliamo di sostanza, non di meccanismi di anti-aliasing, meccanismi di zoom, supporto di primitive CSS ancora soggette a standardizzazione. No, chrome è innovativo perché si pone l’obiettivo (raggiungerlo sarà un altro problema) di permetterci di usare le RIA senza il timore che l’apertura di un file PDF su uno dei tab aperti blocchi tutte le finestre del browser o che il crash per overflow di memoria causato da uno script ci faccia perdere il contenuto di tutte le finestre attive.

Il ripristino di firefox non ci aiuta. La chiusura inattesa di una RIA spesso comporta la perdita del lavoro fatto (quanti post avete perso perché vi siete dimenticati di salvare il contenuto di una semplice textarea?).

Allora teniamo d’occhio ciò che chrome ci propone di realmente innovativo:

1) una macchina virtuale per javascript con un meccanismo di esecuzione del codice javascript che prevede una precompilazione e non una interpretazione passo passo;

2) un processo separato per ognuno dei tab aperti.

Questo dovrà migliorare le prestazioni nell’esecuzione di script, diminuire la dispersione dello spazio di memoria e, soprattutto, limitare al singolo tab (quindi alla singola applicazione) gli eventuali problemi legati alla cattiva programmazione e alla presenza di bug.

Condivido pienamente la scelta strategica di google, che tanto sta investendo sulle RIA ostinandosi (correttamente) ad usare tecnologie di base e soprattutto standard (AJAX). Per realizzare RIA con AJAX efficienti e affidabili i browser attuali non bastano, serve una nuova generazione e chrome rappresenta il corretto modello evolutivo da seguire.

Oppure preferiamo usare Silverlight?

PS. Il fumetto, va ammesso, non verrà ricordato come espressione artistica, ma l’ho trovato utilissimo per cercare di comprendere  cosa fosse chrome senza addormentarmi alla seconda pagina. Consigliato.

Cito alcune delle letture che mi hanno ispirato il post: chrome-faq di giovy (va comunque letto anche il commento al post di EnricoG); vari post nel blog di html.it, tra cui quello di Lamanna su alcune caratteristiche del rendering HTML e CSS; francesco e paulthewineguy, molto critici; infine giavasan, del quale condivido alla lettera le conclusioni.

Sulle RIA avevo scritto un post tempo fa e l’iniziativa di google conferma la mia preferenza per le soluzioni basate su AJAX.

Firefox Download Day

Ci siamo. Molti server sono “down”. Non era questo lo scopo.
Via email mi è arrivato il link “giusto”:
http://www.mozilla-europe.org/it/firefox/.

Firefox 3 beta 5

E’ disponibile la beta n. 5 della versione 3 di Firefox. L’ultimo passo prima della release finale prevista per giugno. Con grande sollievo la developer bar è già stata aggiornata ed è “sopravvissuta” all’aggiornamento. Nelle note di rilascio troviamo diverse novità rispetto alla beta precedente, soprattutto bug fix. Nel complesso la nuova versione del browser migliorerà nella sicurezza, nella semplicità d’uso, nella gestione del profilo personale, negli strumenti per gli sviluppatori, ma, soprattutto, nelle prestazioni e nell’utilizzo di risorse.

Google desktop è tornato a funzionare. Con la beta 4 aveva problemi (google desktop port conflict 4664) ed ero costretto ad usare … ahime … internet explorer.

Due parole sulle Rich Internet Application (RIA)

Leggo su ComputerWorld che i ricercatori del gruppo Forrester ci svelano che i “power user” sono piuttosto delusi dalle performance delle applicazioni RIA (Rich Internet Application) che utilizzano AJAX. Le applicazioni web si definiscono “rich” quando le funzionalità della pagina web si arricchiscono di componenti “client-side”, eseguite sul browser. Ci allontaniamo dal paradigma originario del web (come semplice ipertesto finalizzato a pubblicare documenti) utilizzandone le tecnologie per realizzare vere e proprie applicazioni.

Most power users are disappointed with the performance of Rich Internet Applications (RIAs) based on Asynchronous JavaScript with XML, or AJAX, according to a new research report from Forrester Research Inc.

Su questo punto sono abbastanza d’accordo. Condivido lo scetticismo verso AJAX: non è la soluzione a tutti i problemi  e la sua diffusione sta “indebolendo” il web. Le pagine si arricchiscono di componenti client-side (script javascript) e diventano nuovamente vulnerabili alle mille combinazioni sistema operativo/browser. Pensiamo che IE7 è ancora lontano dal soppiantare IE6 e già è apparsa la beta di IE8 che sembra rivoluzionare (dovrebbe, forse, interpretare un po’ meglio gli standard) il comportamento della famiglia di browser più diffusa. Firefox, Safari, Opera, …

Non stiamo ragionando su come viene visualizzata una pagina, se il box model CSS è più o meno conforme allo standard, se l’anti-aliasing dei font è più o meno gradevole: se pagine RIA (imbottite di codice javascript) hanno problemi, l’utente non può utilizzarle . L’applicazione non funziona.

Non sono, invece, minimamente d’accordo con il consiglio, da parte dei ricercatori Forrester, a guardare a tecnologie emergenti come Adobe AIR o Microsoft Silverlight.

As a result of the AJAX limitations, the research firm recommended that business users consider emerging next-generation RIA technologies like Adobe AIR from Adobe Systems Inc. and Microsoft Corp.’s Silverlight tool set.

(continua…)

Firefox 3 in arrivo: showModalDialog()

Tra qualche giorno dovrebbe essere rilasciata la versione 3 del mio browser preferito. Sto utilizzando la beta da un paio di settimane e non ho ancora riscontrato problemi (chissà se questo post arriverà in fondo ora che l’ho detto).

Volevo fare dei confronti più scientifici con la versione precedente, ma il vecchio PC l’ho dismesso prima del previsto e la release 2 del browser non è più immediatamente disponibile. Quindi vado un po’ a memoria.

Come annunciato il browser è estremamente meno ingordo di risorse e, anche se ancora in beta, sembra anche più stabile. Devo ammettere che quasi tutte le estensioni installate sono state disabilitate perché ancora non compatibili (ahime’, tra questel’impagabile color picker e la web developer bar) e questo certamente condiziona fame e stabilità.

Diversi dettagli grafici sono stati migliorati ed è ora immediato aggiungere link tra i segnalibri. Un’occhiata alle release notes per pregustare tutte le migliorie.

Tra le novità più interessanti ho notato l’implementazione della funzione window.showModalDialog(), non standard e introdotta da Internet Explorer 4, in grado di aprire un documento HTML in popup in una finestra “modale“. Questa funzione, rispetto all’usuale window.open() ha 3 differenze notevoli:

(continua…)

Buon compleanno XML

Il 12 febbraio 1998 il W3C pubblicava le specifiche per XML 1.0 ( Extensible Markup Language (XML) 1.0).

The Extensible Markup Language (XML) is a subset of SGML that is completely described in this document. Its goal is to enable generic SGML to be served, received, and processed on the Web in the way that is now possible with HTML. XML has been designed for ease of implementation and for interoperability with both SGML and HTML.

(REC-xml-19980210)

Non un linguaggio, ma un nuovo alfabeto in cui ridefinire tutte le grammatiche e i linguaggi del web e non solo. Utilizzato per ridefinire l’HTML nell’XHTML, ha dato forma a decine di linguaggi di markup specializzati. Ma probabilmente l’effetto più dirompente l’abbiamo avuto in un ambito imprevedibile anche per chi lo stava concependo: la rappresentazione e lo scambio di dati. Dai Web service, SOAP, WSDL alla definizione di formati aperti e proprietari per la rappresentazione dei dati.

B asta con tracciati di scambio a spaziatura fissa, ai comma-separated, ai file pseudo-ini. Caratteri speciali, separatore di campo, separatore di record, documentazione fuori linea e obsoleta. L’XML ha spazzato via tutti questi problemi come una tempesta. Con schemi e DTD si documenta in maniera formale e automatizzata la sintassi del file: il documento di specifica alimenta il parser di validazione. Ma dove era stato tenuta nascosta questa panacea fino al 1998?

In fondo è sempre stata lì, come la pennicellina, ma nessuno aveva capito quanto valesse, visto che l’SGML, di cui XML è un sottoinsieme, deriva a sua volta dal GML, ideato in IBM nel 1960 da Charles Goldfarb, Edward Mosher and Raymond Lorie.

(via W3C)

Il PDF sta per diventare uno standard ISO

L’International Standards Organization (ISO) ha recentemente approvato la definizione di un nuovo standard, l’ISO 32000 che descriverà  il formato di documento universalmente noto come Portable Document Format (PDF) introdotto nel 1993 dalla Adobe. Il cammino verso l’approvazione finale è ormai alla conclusione e dovrebbe arrivare in fondo entro i primissimi mesi del 2008. Nella votazione dei membri ISO il nuovo standard è stato approvato quasi all’unanimità con l’eccezione della Russia (astenuta) e della Francia (contraria).

La proposta di rendere il PDF uno standard ISO è stata avanzata dalla Adobe a gennaio 2007, per far fronte all’attacco sferrato da Microsoft con la definizione di un proprio formato concorrente al PDF (XML Paper Specification - XPS) (arstechnica).

La novità, in sostanza, è che sarà l’ISO e non più Adobe, responsabile delle modifiche al formato PDF. Per quanto riguarda la possibilità di sviluppare liberamente applicazioni in grado di leggere e scrivere in questo formato nulla cambia, in quanto la licenza Adobe è diventata, nel tempo, sempre più aperta (history of pdf openness). Quindi cosa c’è di nuovo?

No, il cambio è sostanziale: il fatto che la definizione dello standard passi nelle mani di un organismo come ISO fa venir meno il vantaggio che Adobe aveva rispetto ai potenziali concorrenti: aggiornare lo standard quando, di fatto, erano già pronte le nuove versioni delle proprie applicazioni. In futuro tutti concorreranno a definire lo standard a vantaggio della sua qualità e della concorrenza tra i produttori.