I dati di palinsesto che utilizzo arrivano dirattamente da RaiSat (che ringrazio) e sono ultra precisi. Il sistema che ho sviluppato immagazzina le informazioni aggiornate e, di tanto in tanto, applica le eventuali variazioni sulla programmazione.

Ovviamente, se ovvio non fosse, per me si tratta di un passatempo e di un’attività perfettamente indipendente; è — come scrissi — il tentativo di rendere accessibili le informazioni dei palinsesti delle vecchie e nuove reti televisive che popolano e popoleranno il digitale terrestre italiano.

Tutto qui.

aggiornamento 1 luglio: ripristino della versione mobile

aggiornamento 29 settembre: deploy del nuovo modulo

meet the parser

Questa mattina grazie alle bischerate di Y Combinator ho trovato un parser monadico (per chi vede monadi dentro a JavaScript — il passo dopo è vederle dappertutto, ma lasciamo stare) p4js che ha fatto emergere ricordi legati alle buone parti client-side. Così l’ho preso, modificato (aggiungendo un paio di cosette basilari) e inserito come nucleo di un pre-prototipo di interfaccia per il sistema di inserimento di date molto umano che sto sviluppando (vedi link sotto a “Dimmi quando…”).

Potete provarlo qui…

kill the parser

update: Dati i problemi riscontrati con alcuni browser, e un’innata curiosità, ho rimpiazzato il Parser con un effettivo parser potenziale (perché in modo chiaro afferma di non essere un “vero” parser e di funzionare solo per culo merito di un trucco — dice animisticamente così, che ci posso fare?!) implementato from scratch, (vagamente) adatto allo scopo.

Potete provare il (nuovo) tutto in quasi_quando >>>

testato in Firefox 2 / 3, IE 7 / 8, Opera 9, Safari 3, Chrome

Il mio tempo libero non ha lo stesso potere espressivo dell’attuale attività dei Mozilla Labs (il mio sguardo, qui, si rivolge al progetto Ubiquity), chiedo venia. A proposito di poteri, quello di p4js usato “bene” non è nemmeno paragonabile a quello dell’analizzatore sintattico di Dimmi quando….

enjoy your life

La traccia è finita. Il post (la) segue.

Questi, di solito, sono i momenti prima di un inizio…

Nota: ironia a parte trovo che il Parser che ho scartato — per farmi del male — rappresenti un mini-progetto interessante.

Evito excursus sull’imminente rilascio di Wolfram|Alpha, sull’esperimento Watson di IBM che presto si cimenterà con i “trivia” di Jeopardy! (il punto esclamantivo non è mio, giuro!) o sulle future semantiche latenti di Mountain View. Vi propongo invece un semplice prototipo di interfaccia naturale — sempre in tema di cose cool.

Permette di esprimere dei quando: Dimmi quando… >>>

E’ il frutto di pochissimi ritagli di tempo libero.

Non è completo. Completarlo è “difficile”.

-

aggiornamento, alcuni esempi:

l’output è in <em> / ** dipendono dal contesto temporale

il 24 ottobre alle 23 e 59 minuti ==> sabato 24/10/2009 alle 23:59

tra due giorni alle 21 ** ==> giovedì 07/05/2009 alle 21:00

nove settimane fa alle 15 ** ==> martedì 03/03/2009 alle 15:00

alle 16 del 15 agosto ==> sabato 15/08/2009 alle 16:00

il 10/9 ==> sabato 10/09/2009 (alle 00:00)

-

Okay, adesso posso tornare a ri-leggere L’istinto del linguaggio :P

Le emittenti aggregate sono: le 4 reti Rai (la quarta è Rai 4), le 5 reti Mediaset (con Iris e Boing), LA7, MTV e All Music. Le informazioni vengono aggiornate in modo automatico (/semi-automatico) ogni mattina. I titoli dei film sono grassettati.

Sia l’aspetto della pagina che le tecniche per elaborare i contenuti sono in evoluzione.

aggiornamento 14 maggio: aggiunto il palinsesto serale di Boing

aggiornamento 8 giugno: il nuovo obiettivo è “salvare” dall’oblio (i dati de) il palinsesto di Rai 4

aggiornamento 8 luglio: revisione dei moduli di Boing e Iris

Nei risultati — vicino al titolo delle entry — troverete il corrispondente numero di save ottenuto in Delicious. Nulla di eclatante. Se vi va potete provarlo >>>

Il post sull’introduzione di java in App Engine espone solo una delle implicazioni (per giunta marginale) di questa “rivoluzione”, non è completo — non chiude il cerchio.

Per farlo (dimostrare, chiudere o completare, a vostra scelta) comincerò col parlarvi di due delle cose che riescono sempre a stupirmi quando — circa ogni giorno — mi immergo nel mondo legato allo sviluppo di applicazioni web:

• la quantità di tempo che viene speso nell’implementazione di algoritmi di validazione dell’input
• gli sprechi e le inconsistenze che emergono dal doverli implementare sia lato server che lato client

Spiego meglio la seconda. La user experience è — giustamente — considerata sacra, per questo è d’obbligo fornire un feedback immediato agli utenti che stanno inserendo dati potenzialmente non corretti. Pensate alle form di registrazione dei moderni social cosi.

Questo porta ad avere la stessa logica espressa, per esempio, in JavaScript (client side) e in PHP (server side). A volte una parte del lavoro implementativo viene riutilizzata: il riapplicare le stesse espressioni regolari, per esempio. Molto spesso il lavoro si sdoppia e raddoppia.

Come proof of concept di “nuove” possibilità di riuso e come esempio di utilizzo smart (spero) della nuova incarnazione di App Engine, ho creato un semplicissimo validatore di codice fiscale.

La peculiarità di questa applicazione sta proprio nel suo essere 100% DRY-compliant. Il codice di validazione (una funzione JavaScript che avevo scaricato un po’ di tempo fa — accetto hint riguardo ai credit) viene usato si lato client (dai velocissimi JavaScript engine dei vostri browser) che lato server (da java su App Engine via Rhino).

Lo trovate qui: http://ditloids.appspot.com/

come potete osservare il riuso si applica anche ai dominii :P chi non sapesse cosa sono i ditloidi può sbirciare qui.

Se avete bisogno di un codice fiscale di test potete usare questo: PPPPLT80R10M082K (preso qui)

Come dicevo si tratta solo di una delle implicazioni, per giunta marginale…

I più perversi si orienteranno verso Quercus (PHP in Java).

aggiornamento: Lord of the REPLs

** per intenderci JavaScript 1.7 è la versione introdotta in Firefox 2

Ricordatevi che javax.script.* (vedi JSR 223) è vostro amico.

update: il non essere (il) solo mi rincuora

var runtime = java.lang.Runtime.getRuntime(); runtime.availableProcessors() -> 4

segue: JavaScript lato server con Google App Engine - parte 2

Adobe ha deciso di offrire una licenza gratuita di Flex Builder 3 Professional — uno dei suoi prodotti di punta — a tutti gli sviluppatori attualmente disoccupati, con l’impegno a non usare questo potente strumento con finalità commerciali (trovate tutti i dettagli nella pagina che riporta i termini). L’obiettivo dichiarato è didascalico; la cosa in sé non troppo sorprendente.

Ulteriori informazioni le potete trovare nella pagina di accettazione dei termini.

Per questo ho deciso — con semplice tinkering — di mettere insieme un esempio di estensione un po’ più utile. Dopo aver scartato alcune idee troppo complesse credo di aver trovato quello che fa al caso nostro. Proverò a trasformare AdSweep in una vera e propria estensione del browser di Mountain View, in modo tale da creare un “perfetto” surrogato di Adblock Plus.

Il procedimento da seguire per costruirla è davvero semplice.

Innanzitutto dovete mettere in Sleep il vostro Mac, o in standby la vostra (distro GNU/Linux) Fedora, o la vostra Ubuntu, perché questo interessantissimo browser — per il momento — gira nativamente solo su Windows.

Create una nuova cartella da qualche parte; come nel Chrome Extension HOWTO assumiamo che abbiate creato c:\myextension, ma è solo un esempio perché potete davvero posizionarla in ogniddove nel vostro filesystem.

In c:\myextension create un nuovo file di testo chiamato manifest.json e riempitelo con le info seguenti:

{
  "format_version": 1,
  "id": "CAFFEBABECAFFEBABECAFFEBABECAFFEBABECAFE",
  "version": "1.0",
  "name": "AdSweep Test",
  "description": "A real Chrome extension.",
  "content_scripts": [
    {
      "matches": ["http://*/*", "https://*/*"],
      "js": ["AdSweep.js"]
    }
  ]
}

Una volta salvato sarete a metà dell’opera. Se il manifest vi sembra criptico vi consiglio di leggere attentamente l’HOWTO linkato sopra insieme al resto della documentazione sparsa per dev.chromium.org. La parte più interessante in questo caso è la direttiva matches che fa si che il codice JavaScript presente in AdSweep.js venga eseguito in ogni pagina.

Non resta che scaricare la release più recente di AdSweep e da quell’archivio estrarre AdSweep.js e copiarlo in c:\myextension. Il risultato ottenuto apparirà circa così:

Okay, ora dobbiamo installare la versione giusta di Chrome.

Per avere il supporto per le estensioni, come dicevo, abbiamo bisogno di una versione recente di questo browser. Le istruzioni per ottenerla si trovano in getting-involved/dev-channel; in realtà la procedura è semplicissima, basta 1) installare Google Chrome 2) scaricare, lanciare Google Chrome Channel Changer, e da lì selezionare beta o dev. Il passo successivo è l’aggiornamento di Chrome, per portarlo alla versione 2.0.X.Y (attualmente sto usando una 2.0.170.0).

Una volta fatto ciò ri-avviamo Chrome indicando(gli) la directory in cui è presente l’estensione:

chrome.exe --enable-extensions --load-extension="c:\myextension"

nota: è necessario avere la directory in cui risiede chrome.exe in PATH

Se il browser parte senza lamentarsi tutto dovrebbe essere andato a buon fine.

Possiamo controllare la presenza dell’estensione “visitando”:

chrome-ui://extensions/

Da questo momento buona parte delle pubblictà verranno nascoste (vedi screenshot degli effetti) da AdSweep integrato in Chrome. Come avete visto la procedura per la creazione delle estensioni per questo browser is a piece of cake.

Quella che potrebbe essere una scena pre-climax hanekiana è invece il
video di un’incredibile (o imperdibile) performance urbana datata 2007.

Mimesi essenziale. Ho i brividi.

Esistono altre varianti, ma questa di certo è la più grezza.

peccato per i piedi.

nello screenshot uno dei sacrileghi sacrilegi

update delle 16.20: tutto è tornato alla normalità.

Adesso i tecnocosi hanno-di-che-parlare… Yaaaaaaaaawn.

Se solo lo avessero inventato prima.

Ammetto di essere spesso scettico nei confronti delle creazioni degli ingegneri di Google (che in genere costruiscono sulla sabbia, come direbbe un uomo molto ricco che non conosco bene), ma questa gemma dei Labs — da incastonare in Gmail — è a dir poco indispensabile.

Non è possibile credere che sia superflua, marginale o, addirittura, futile.

Concepita da Jon Perlow (genio) seguendo un rigido processo di design e sviluppo improntato sul modello eat your own dog food Mail Goggles (è un lui — cambio genere) porrà fine a molti dei nostri quotidiani rimpianti e ci renderà, quasi certamente, persone migliori.

Di post come questo ne vedrete mille, quindi non vi farò perdere tempo descrivendo i casi d’uso (alcolici, romantici e forse anche un po’ emo) che lo hanno forgiato e i complicati meccanismi che lo regolano. Attivatelo; lasciate che la vostra vita cambi grazie ad esso.

Data — come dicevo — l’estrema ridondanza dell’argomento, per decenza eviterò di embeddare lo screenshot in cui al posto di un telematico invio mi viene consigliata una bella dormita.

I settaggi invece sono interessanti. Questi sono i miei…

Nel frattempo cosa accadrà?

Una risposta incoraggiante ci viene fornita da James Graham, sul blog del WHATWG:

Quello che davvero conta è quando i browser implementeranno le feature di HTML5. Dato che questo sta già accadendo, non c’è alcuna ragione per allarmarsi. Entro il 2022 ci auguriamo di avere una testsuite [una collezione di test case] e un paio di implementazioni complete, ma quando verrà quel giorno ci attendiamo di poter vedere uscire prodotti con feature di HTML 6.

Chi ha avuto modo di provare una versione recente di WebKit, di Firefox 3.1 (Minefield rules!), di Opera 9 e di IE 8, sa che in queste parole c’è Verità. E’ probabile che in un paio d’anni (magari tre) i principali web browser saranno già in grado di consumare e presentare informazioni descritte in HTML5.

approfondimenti: Google Tech Talk - HTML5 demos

Gli iPhone * e i telefonini costruiti su Android sono “entrambi” equipaggiati con web browser basati sull’engine di rendering WebKit. Questo significa che le applicazioni web progettate per uno si visualizzeranno quasi identicamente sull’altro. Le stesse applicazioni si potranno visualizzare correttamente anche sui browser desktop che wrappano WebKit, come Safari, Google Chrome ecc [ quest’ultimo fattore, agli occhi di uno sviluppatore, rappresenta un enorme vantaggio nei contesti di testing e debugging delle applicazioni ].

E poi…

Google isn’t getting into the mobile phone market to be a developer tools vendor. It’s hoping that it can advance the mobile web platform far enough that it will become a viable stream of advertising revenue.

Se fossi 1) un imprenditore 2) italiano 3) lungimirante (credo invece di non [poter, in questo spesso agro paese] essere il primo, di essere il secondo e quanto basta del terzo) inizierei facendomi — o meglio facendo fare ai miei dipendenti, magari sostenuti da chi già possiede il know-how relativo a questi nuovi device — le ossa su quello che per il momento viene offerto dal mercato, ovvero gli iPhone (e gli smartphone che non ho menzionato).

* iPhone / iPod touch

aggiornamento: Altro che guru di Rails, quelli sono solo spammer di Delicious (screenshot)!!

Qui ci sarebbe da aprire un discorso sul deterioramento inesorabile di quello che era il gioiello del social bookmarking (quando si chiamava del.icio.us ed era curato da Joshua Schachter)… La morale è che bisogna stare molto attenti a ciò che trova nelle pagine pupular del nuovo Delicious di Yahoo!, che attualmente è vulnerabile allo spamming.

via wharfinger