Ore 14. Sono in auto e sto tornando a casa per pranzo, in sottofondo Radio 101. La Panicucci legge la lettera di due detenuti del carcere di Opera: uno uscirà  nel 2011, l'altro ha l'ergastolo. Dopo i ringraziamenti, la Panicucci parte con il pistollotto morale sulla reponsabilità  dei deejay nei confronti di "tutte quelle persone che hanno avuto una vita meno fortunata". E gli dedica una canzone degli Jamiroquai: Run away. Giusto per avere un idea, ecco la traduzione. Io sono rimasto un po' attonito.

Nell'ultimo mese mi é capitato di sentire "Mac OS X é basato su Linux": no, niente di più sbagliato. Mac OS X fa parte della grande famiglia dei sistemi operativi Unix, nel dettaglio del ramo che ha preso vita dallo Unix di Berkley: il BSD. Le origini di Mac OS X risalgono a metà  degli anni 80 in quanto erede diretto di NeXT Step. Breve parentesi storica. Nel maggio del 1985 Steve Jobs venne estromesso dalla Apple, l'anno successivo

• acquisì la "The Graphics Group" che chiamo Pixar (da poco venduta a Walt Disney in cambio di un sostanzioso pacchetto azionario) e
• fondò la Next Computer, nuovo tentativo di Jobs sul mercato del computing d'avanguardia.

Il progetto Next prevedeva la realizzazione di computer di fascia alta, delle workstation per intenderci. Il progetto hardware assomigliava ai Mac di quel periodo basati su processori Motorola di classe 680x0. Il sistema operativo NextStep venne realizzato a partire:

• dal kernel Mach, microkernel sviluppato in seno alla Carnegie Mellon University;
• dalla userland dello Unix BSD.

Su questa base vennero sviluppati i contributi orginali del gruppo di ricerca e sviluppo della Next:

• il linguaggio di programmazione Objective-C, per un ambiente integrato ad oggetti con forti caratteristiche di modularità  e riusabilità 
• un'interfaccia grafica basata su un motere di rendering Postscript, quindi vettoriale e indipendente da media.

Entrambe queste due caratteristiche si ritrovano in Mac OS X: Objective-C é tuttora il linguaggio preferenziale per lo sviluppo, l'interfaccia Postscript si é evoluta in Aqua in PDF (variante del PostScript). Anche le linee guida di licensing erano già  definite sul finire degli anni ottanta: la base del sistema operativo (kernel e userland) sono sempre state open source, l'interfaccia grafica proprietaria della Next. Attualmente il progetto Darwin é il rilascio open della base di Mac OS X, da cui sono nati diversi progetti completamente open source come GNU Darwin. NextStep vide la luce nel 1988 e girava specificatamente su hardware Next. Nel 1993 erano pronti i porting per le versioni PowerPC e Intel: questo spiega i tempi di migrazioni quasi istantanei dell'ultima evoluzione in Apple (il porting per Intel era sostanzialmente già  pronto da anni).

Una curiosità  per gli amanti del web. Quando nel 1991 Tim Berners-Lee, ricercatore del CERN, inventò HTML e sviluppo il primo browser lo fece su una workstation NextCube con sistema operativo NextStep. A causa di un grosso calo di vendite e di prodotti sbagliati, nel 1996 Steve Jobs venne richiamato in Apple, che acquisì la Next per 402 milioni di dollari: staff e know-how vennerò integrati e si posero le basi per il futuro sistema operativo della mela che venne rilasciato nel 1999 in versione server, nel 2001 la prima é più conosciuta versione desktop (Mac OS X 10.0 Cheetah). I tentativi precendenti al ritorno di Jobs nel rinnovare il sistema operativo furono fallimentari e abbandonati: Taligent e Copland. Jobs impose l'uso di NextStep come fondazione del nuovo sistema operativo (nome in codice del progetto Rhapsody). L'evoluzione da NextStep a Mac OS X fu sostanziosa:

• il nuovo kernel XNU, basato sull'originale Mach, venne integrato di alcune funzionalità  monolitiche dall'ambiente BSD per ridurre i tempi di latenza classici dei micro-kernel;
• l'interfaccia raffinata dal punto di vista grafico per il palato degli utenti Apple e portata da PostScript a PDF.

Ma la fondazione del sistema operativo resta ancora oggi di chiara derivazione NextStep: la maggior parte delle classi e delle interfacce portano un prefisso NS_ che ne indica chiaramente l'origine.

Un paio di giorni da mi sono sentito abbastanza incosciente da aggiornare Wordpress: e 2.1 fu! In generale l'esperimento é andato bene, il grosso del lavoro é stato verificare ogni plugin ed eventualmente aggiornare a versioni più recenti. I cambiamenti più evidenti sono stati: la maggior velocità  di risposta dovuta al tuning del database, i raffinamenti dell'interfaccia di contribuzione. L'unico problema in cui sono incappato é stato con FAlbum, per scoprire poi che era un difetto del tema.

Ore 14 abbondanti riesco a strapparmi dall'ufficio per andare a mangiare qualcosa. A casa, rigorosamente a casa.

Si, faccio parte di quella classe di privilegiati, a mio avviso, che lavorano in provincia, abitano a cinque minuti dal proprio domicilio e possono tornare a casa un'ora e pranzare con calma.

Stacchi la spina un'ora, ti allontani dal brusio dell'ufficio, dalla convulsione delle telefonate, dalle email che ti guardano frettolose attraverso i cristalli liquidi.

Non male vero?

Chiaramente alle 14 abbondanti mangio da solo, anche a casa. Ma non mi dispiace per nulla.

Oggi mi servo, mi siedo, accendo la tele, breve zapping e... i campionati europei di pattinaggio artistico! Nella mie mente l'esclamazione se n'é uscita tutta in maiuscolo: adoro il pattinaggio, la grazia e la destrezza che esprime, il controllo di potenza, fluidità  ed equilibrio.

Ogni volta é come assistere ad un miracolo.

La perfetta pausa pranzo.

Avevamo bisogno di applicare i tag anche alle pagine? Ultimate Tag Warrior per quanto sia un plugin eccellente assegnava i tag solo ai post.

Christine deve aver sentito il nostro urlo disperato fino in Nuova Zelanda, perché la nuova versione di UTW implementa i tag nelle pages di Wordpress!

Può essere interessante integrare Wordpress con le social web application per arricchire i contenuti del proprio blog o per sperimentare formule di marketing integrato. L'obiettivo di questo esperimento é utilizzare Flickr in modo da avere una gallery contestuale ai contenuti del post. La denotazione contestuale la ricaviamo attraverso il tagging. Abbiamo bisogno di installare e attivare due plugin di Wordpress:

• Ultimate Tag Warrior, é quanto ci serve per il tagging dei post,
• flickrRSS, utile a recuperare feed da Flickr sulla base anche di più tag.

Vi rimando alla documentazione dei rispettivi plugin per le procedure d'installazione e configurazione. Una volta che siete certi che Ultimate Tag Warrior funziona ed avete taggato qualche post, si procede in questo modo. E' necessario modificare il file ultimate-tag-warrior.php che trovate nella cartella /plugins/UltimateTagWarrior aggiungendo in coda la seguente funzione. function UTW_GetTagsForCurrentPost() { global $utw, $post; $myTags = $utw->GetTagsForPost($post->ID); $r = array (); $i = 0; foreach ($myTags as $myTag) { $r[$i] = $myTag->tag; $i++; } return $r; } UTW_GetTagsForCurrentPost() ha il semplicissimo compito di estrarre l'array di tags che abbiamo assegnato ad un post. Fatto questo modifichiamo i nostri template. L'idea é che nel loop di Wordpress, vicino a post e tag, vengano estratte le immagini contestuali tratte da Flickr attraverso il plugin flickrRSS. Ecco l'esempio di codice. <?php if(count(UTW_GetTagsForCurrentPost()) > 0) { $myTags = implode(",", UTW_GetTagsForCurrentPost()); get_flickrrss(6, "user", $myTags, "square", "", "", "IL_VOSTRO_ID_FLICKR"); get_flickrrss(6, "public", $myTags, "square", "", "", ""); } ?> Il funzionamento anche in questo caso é semplice:

• innanzi tutto verifico che il post abbia effettivamente dei tags,
• poi concateno i tag delimitandoli con le virgole (come richiesto da flickrRSS,)
• infine richiamo flickrRSS per stampare le immagini.

Vi rimando al sito di flickrRSS per la documentazione e le possibilità  della funzione.

A proposito dell'integrazione con le social web application. Stiamo lavorando sull'integrazione dinamica di post+tags+Flickr in Wordpress: l'obiettivo é fare in modo che post e page possano avere una propria gallery dinamica sulla base dei tag inseriti. Il motivo é sfruttare al meglio il modello blog marketing + social. I plugins di base sono:

• Ultimate Tag Warrior,
• FAlbum.

Ho fatto notare a Matteo che, da esperimenti precedenti, non mi risultava fosse possibile estrarre una ricerca utilizzando più di un tag: solo uno, limitazione delle API di Flickr. Un modo per aggirare la limitazione é utilizzare il plugin flickrRSS, che in realtà  non si appoggia alle API ma richiede un feed. Non l'avessi mai detto, "Non é possibile!": Matteo si é vestito del sacro furore dello sviluppatore e si é messo a dar craniate alla rete, alle API di Flickr, ai feed, a Wordpress... a tutto quello di PHPoso gli passasse sottomano.

Per poter accedere alla API di YouTube é necessario ottenere un Developer ID e la documentazione é abbastanza completa, anche se mi aspettavo qualche metodo in più. Le metodologie di accesso sono due: REST e XML-RPC.

Obiettivo del post é fare una panoramica di come implementare una classe Java che, dati DEV_ID e una lista di VIDEO_ID, acceda alle API di YouTube, ne scarichi i dettagli, provveda a costruire una cache su filesystem. Non entrerò in dettagli che uno sviluppatore Java conosce sicuramente meglio di me.

Metologie di caching:

• la più semplice in Java é serializzare l'oggetto ottenuto dall'XML su filesystem;
• per palati più raffinati, si possono utilizzare ottime librerie open source come
  • EHCache oppure
  • OSCache.

REST Interface

Interfaccia estremamente semplice si basa su una chiamata http che come risultato restituisce un file xml. Un esempio.

http://www.youtube.com/api2_rest?
method=youtube.videos.get_details&dev_id=YOUR_DEV_ID
&video_id=YOUR_VIDEO_ID

dove:

• method é il parametro in cui si indica il metodo delle API YouTube a cui si vuole accedere;
• dev_id il proprio id di sviluppo;
• video_id é l'id univoco del filmato su YouTube.

La nostra classe:

1. scorre la lista di VIDEO_ID;
2. verifica se esiste già  una cache per quel video (o verificando su filesystem se esiste l'oggetto serializzato o interroganto EHCache/OScache);
3. se non esiste una cache:
   • farà  la chiamata http alle API di YouTube
   • riceverà  l'xml di dettaglio del video per quel determinato VIDEO_ID
   • elaborerà  l'xml trasformandolo in un oggetto strutturato nel modo che ci viene più comodo e utile
   • creerà  la cache per quell'oggetto
4. se esiste l'oggetto cachato, la classe si preoccuperà  soltanto di recuperarlo;
5. viene restituita una lista di oggetti contenenti i dettagli dei nostri video.

Per effettuare una chiamata http é necessaria una libreria che implementi un client http, va benissimo l'HttpClient del progetto Jakarta Commons. La chiamata può essere fatta in GET o in POST: in questo senso la documentazione di YouTube non dice nulla (l'esempio sopra simula una GET) ma penso che l'API accetti entrambi i metodi (preferibile il POST).

Il codice (plausibilmente un metodo privato della classe) dovrà  essere strutturato più o meno così:

HttpClient client = new HttpClient();
PostMethod method = new PostMethod("http://www.youtube.com/api2_rest");
method.addParameter("method", "youtube.videos.get_details");
method.addParameter("dev_id", YOUR_DEV_ID);
method.addParameter("video_id", YOUR_VIDEO_ID);
try {
// eseguo la chiamata
int statusCode = client.executeMethod(method);
if (statusCode != HttpStatus.SC_OK) {
System.err.println("Method failed: " + method.getStatusLine());
}
// leggo la risposta
byte[] responseBody = method.getResponseBody();
// utilizzo la response.
// Attenzione: assicurarsi che l'encoding sia corretto ne non siano dati binari
String myXML = new String(responseBody));
} catch (HttpException e) {
... // gestione dell'eccezione
} catch (IOException e) {
... // gestione dell'eccezione
} finally {
// chiudo la connessione.
method.releaseConnection();
}

Le possibilità  di ottimizzazione sono svariate, come per esempio creare un unico client e sfruttare un'unica connessione per evitare overhead inutili: a voi la scelta. La response che si otterrà  sarà  simile a questa.

Per elaborare l'xml e trasformarlo in un più comodo oggetto, possiamo utilizzare uno dei moltissimi parser a disposizione della piattaforma Java. La scelta in questo caso é più orientata su considerazioni di gusto (riguardo l'API del parser), di leggerezza del parser e della sua velocità  di elaboarzione.

Per un utilizzo leggero e snello consiglio di utilizzare un pull-parser anche senza feature di validazione (che in questo caso servono a poco e non avremmo comunque il DTD su cui lavorare). Un elenco veloce di alcuni:

• Woodstox
• XP
• kXML 2
• VTD-XML

Alla prossima puntata farò una panoramica su come può funzionare l'approccio via interfaccia XML-RPC.

Prendetevi la rivincita e friggetela! Inaugurata oggi alla Galleria Aus18 la mostra "Fritto Misto". L'artista Mirko Credito si accanisce su pad, console, pistole e modellini friggendoli: una veloce impanata, una bella pentola d'olio caldo e l'arte é pronta da servire.

Ieri la mia commercialista mi ha notificato l'avvenuta apertura della mia partita iva personale. E' stata una piccola emozione.

Il motivo é una nuova avventura lavorativa, che si svolgerà  parallelamente a quanto già  faccio ora: un nuovo traguardo e punto di partenza professionale.