venerdì 30 marzo 2007

SOA (2) - Variazioni Goldberg


[...] l'opera è stata concepita come un'architettura modulare di 32 brani, disposti seguendo schemi matematici e simmetrie che le conferiscono tanta coesione e continuità da non avere eguali nella storia della musica [...]. Così la Wikipedia, riguardo alle Variazioni Goldberg di Bach.

Anche con SOA abbiamo il problema di mettere assieme una architettura modulare, i nostri brani sono i servizi, la coesione e la continuità sono fornite da schemi di processo definiti in un workflow...

Come sarebbe a dire che non sapete cosa sia SOA? A questo punto dovreste, come minimo, avete già letto il mio precedente post introduttivo e la maggior parte di voi saranno stati lì come avvoltoi aspettando che pubblicassi quello sul Web 2.0.
Come sarebbe che non ricordate? (Chi ha detto 'ho rimosso'?)

Capisco che possiate non aver sentito parlare di WOA, SOD e SOR...
Pensate che stia tirando sigle a caso? (Non potete immaginare neppure cosa vi aspetta nel dettaglio di questo post, allora - vendicherò il mio orso dell'altro mio recente articolo sul Web Semantico).

Se non le conoscete perchè leggete solo il mio blog e non vi fidate di nessun altro, certamente non posso biasimarvi...

Però ricordate che a dire bugie vi cresce il naso.
E a non studiare anche le altre fonti, pure le orecchie.



Riassunto delle puntate precedenti: abbiamo visto che SOA è una architettura per servizi remoti(zzabili), tipicamente resi disponibili sotto forma di Web Services, prodotti all'interno dell'azienda, ma anche da fonti su Internet.
Abbiamo dato un'occhiata all'architettura, dall'alto di un dirigibile, e abbiamo visto come, di fatto, sia un modo per ripensare il sistema aziendale basandosi su componenti (siccome non è certo una novità, gli cambiamo nome e li chiamiamo servizi), mettendoli in fila con un sistema che è un incrocio tra un motore di workflow ed un EAI (Enterprise Application Integration), chiamato Service Bus o Orchestrator, a seconda dei casi.
Abbiamo anche notato che qualcuno propone servizi già pronti da usare su Web e da essere integrati nei vostri siti e li pubblicizza sotto il nome di Web 2.0.

Abbiamo omesso, (apposta, ma ci torneremo, se non quest'anno, nel prossimo), di dire che il SOA Service Bus potrebbe non esistere, potendosi incastrare i vari servizi in una bella pipe, in cui uno dei servizi usa l'output dell'altro come suo input.

In un modo o nell'altro i servizi si mettono assieme, il risultato delle loro elaborazioni viene presentato in modo uniforme e l'applicazione che ne risulta viene chiamata mashup. A prescindere da tutti i significati e le derivazioni che troverete nel link appena riportato, non so perchè a me viene sempre da tradurlo 'pastrocchio'.

Che alla fine lo sia o meno, al solito, dipende da quanto siamo bravi e attenti nel fare il nostro lavoro, da quanto tempo abbiamo e da quanto era basso il budget o l'offerta: se le fonti sono tante, le API messe a disposizione attraverso i web services (ws, da qui in avanti, se no si fa lunga) potranno seguire differenti filosofie di progettazione, potranno essere più o meno semplici, potranno funzionare o meno, seguendo più o meno fedelmente le rispettive documentazioni (sempre che esista qualcosa cui poter ragionevolmente dare un simile nome).
L'esperienza insegna che l'integrazione di sistemi differenti è, tranne che per operazioni banali, sempre uno dei punti più critici di ogni progetto, è sempre uno dei punti in cui è facile sbagliare le stime. E' sempre bene ricordarlo, quando si progetta un bel mashup. Non tutti sono in grado di mettere assieme tanti moduli come Bach e non subire il severo giudizio della storia...

E' bene notare che, solitamente, si parla di mashup quando più ci si avvicina a servizi destinati ad una presentazione, (più Web 2.0, per intendersi), piuttosto che quando si parla di servizi aziendali in architettura SOA, con tanto di Service Bus, ma non ci stupiremo più di tanto se da qui in avanti le terminologie si mischieranno un po', dal momento che i due approcci tendono a convergere fortissimamente.
Anche per motivi legati alla consumabilità dei servizi (ovvero alla loro utilizzabilità anche da parte dei client più semplici), e in parallelo alla diffusione di interfacce grafiche più ricche su Web (si parla di RIA - Rich Internet Applications), la sigla SOA, con un facile morphing, cambia in WOA (Web Oriented Architecture).

WOA implica maggiore flessibilità e velocità di adattamento, utilizzo di tecnologie più semplici: HTTP, XML più piatto, chiamate ad URI; contrapposte alle complessità di SOAP (peraltro oggi discretamente nascoste da ottimi tool e librerie) come base dei Web Services. Hinchcliffe, nel post sopra citato, nota come l'attuale lista degli standard WS-* sia ormai quasi incomprensibile per il semplice mortale e supporta fortemente (come in quasi tutto il resto dei suoi post) queste tecnologie più alla portata di tutti(anche quando parla di SOA, tende sempre ad omettere l'orchestrator e a far convergere SOA, WOA e Web 2.0 verso lo stesso significato). Il rovescio della medaglia è che, in situazioni con molte differenti fonti di servizi provenienti, bisogna reinventarsi l'interpretazione dell'XML, scambiarsi le specifiche a più basso livello, laddove SOA ci permette di concentrarci sulle interfacce (intese nel senso della progettazione ad oggetti, non nel senso del layer di presentation) e basta.

Siccome questo è il post delle sigle, qualcuno di voi - tra quelli più forti fisicamente, s'intende o, alternativamente, oramai così malridotti che tanto peggio non può andare - si starà chiedendo perchè abbia tirato in ballo alcuni aspetti di REST senza citarlo. Lo faccio ora, così quelli che non hanno capito nulla fino a qui, si confonderanno quel bit in più e non torneranno mai più.

REST sta per REpresentational State Transfer e, in due parole e ben conscio di sminuire alquanto il tutto (ma non potete chiedermi di essere sintetico e di spiegarvi i dettagli: vi fornisco i link apposta), vuol dire che noi abbiamo i dati e, quando ce li chiedono, al posto che creare direttamente una presentazione specifica o inviare interamente dati, inviamo una rappresentazione intermedia, filtrata, dei dati stessi, in modo che il client possa decidere di costruirsi la sua rappresentazione da solo (lasciando aperta la possibilità che la nostra rappresentazione sia già presentabile senza ulteriori engine).
E' più semplice con un esempio: voi puntate ad un URL per avere un feed RSS, vi viene inviato un XML e il vostro client (browser o feed aggregator) mette assieme il tutto e ve lo presenta.
Consiglio, comunque, di seguire il link fornito, non solo perchè il suo autore, Roy T. Fielding, è stato uno dei principali autori e architetti dell'HTTP, ma anche perchè mostra una interpretazione della crescita logica delle principali architetture nel tempo. Non ci stupiremo se Fielding parla di REST come di una architettura e non come una serie di tecniche (quelle che sopra ho contrapposto a SOAP) per supportare l'architettura stessa.

Non si può dire se sia meglio SOAP o REST a priori, è la situazione specifica che decide cosa sia meglio: in un caso siamo più completi e formali, esistono delle librerie di supporto per semplificarci la vita, i protocolli sono già definiti, ci sono modi per gestire sicurezza, attachment, transazionalità ed altro, ma abbiamo la necessità di considerare i client, che dovranno essere compatibili con la nostra specifica e dovremo condividere le interfacce, secondo modalità tipiche dell'OOP, che richiedono un livello di competenza eccessivo, laddove sia sufficiente chiamare un'URL, ottenere un XML e, poniamo, filtrarlo con un semplice XSL o, addirittura, presentarlo direttamente senza rielaborarlo. Normalmente, come accennavo, più andiamo sul front-end più è facile avvicinarsi a REST, più andiamo sul back-end, più ci avviciniamo a WS-SOAP-based.
Inutile dire che, quando i servizi arrivano da Internet, laddove la sicurezza sarebbe da considerare maggiormente, è più facile trovare interazioni più semplici, più basate su REST, che quelle più formali e studiate di SOAP e la gestione di questa delicata problematica è spesso lasciata in secondo piano o trattata puntualmente e differentemente a seconda dei casi.

Ancora, tipicamente avrà più senso parlare di architetture SOA, basate su WS SOAP, laddove l'aspetto aziendale (Intranet/Extranet in senso lato, comprendendo la gestione delle attività operative dell'azienda) sia prevalente e di WOA e REST per architetture che prevedono forti interazioni con l'esterno.

Il che ci porta a fare un passettino indietro: non ci sono solo SOAP e REST, ma, nel caso di integrazioni con sistemi alla base dell'operatività, l'avevo già accennato la prima volta, dovremo accentuare le capacità di EAI dell'Orchestrator o di moduli collegati, con la possibilità di agganciare servizi forniti da un ERP, un CRM o altri sistemi esterni (in altri casi esistono tool che si installano sul sistema esterno e permettono di trasformare - per es., traducendo le API già a disposizione o mediante screen-scraping - i suoi servizi legacy in WS SOAP-based e, quindi, si riesce a far ricadere il tutto nelle casistiche più standard).

Per completare il glossario, restano SOD e SOR. Che sono quasi uno scherzo (non credo che siano termini usati veramente, ritengo siano stati inventati per uno specifico blog, unico punto sul quale li ho trovati citati - e che vi consiglio: un po' ripetitivo, ma solido) che, però, mi serve per introdurre un argomento basilare.

Mentre SOA, (sto rubando l'intera frase dal blog citato), ha a che fare con il fatto di far guidare l'IT dalla visione di business, qualcuno ha trasformato quella visione in bit e bytes e questo è il motivo per cui SOD (Service Oriented Delivery) e SOR (Service Oriented Realisation) sono veramente importanti.

Ovvero: dopo tanto parlare e disegnare macro-architetture, basate su macro-principi, arriva il momento di tirarsi su le maniche e iniziare a pensare ad organizzare il nostro progetto basato su SOA. Basterà utilizzare i task tipici di un progetto Internet/Intranet a cui siamo abituati?
Per finire questo post, mi limiterò ad accennare ad alcuni aspetti importanti di gestione:

  • analisi dei processi: è fondamentale (perchè SOA è guidato, come dicevamo, dai principi di business) e deve essere antecedente, il più possibile, all'inizio degli sviluppi: meglio ridurre anche i parallelismi con la fase di analisi tecnica di dettaglio. Conoscere i processi serve, infatti, per identificare le funzionalità atomiche che compongono i processi stessi, cercare di separarle e componentizzarle al fine del riuso. Fin qui niente di diverso rispetto a quanto siamo stati tutti abituati. La differenza sta nell'intensità con cui dovrebbe essere seguito questo approccio, sta nel ricercare la possibilità di creare servizi utilizzabili anche fuori dal sequence diagram in cui li abbiamo disegnati per la prima volta. Questo perchè, altrimenti, il motore di workflow centrale e la gestione a servizi introdurrà solo layer che appesantiranno la struttura, ma i vantaggi che ci resteranno si limiteranno a poco più che una riduzione del carico su un server, perdendoci il vero motivo dell'utilizzo di questa architettura, che è la grandissima flessibilità offerta

  • analisi tecnica di dettaglio: l'architettura SOA richiede una maggiore complessità e definizione, quindi sappiate che, nel prendere questa strada, dovete alzare quelle benedette stime relative a questo task. La flessibilità si paga sempre in termini di aumento dei tempi di sviluppo (è un dolore doverlo ricordare, ma sembra quasi che sia vietato considerare stime significative per le analisi tecniche, soprattutto se bisogna metterci una risorsa senior, che costa, nelle stime di progetto - il che porta, inevitabilmente, a trovarsi con il fiato corto e ad un aumento dei costi di sviluppo).

  • maggior parallelismo: attenzione a questa ipotesi. E' verissimo che, in una architettura a servizi, ognuno di questi servizi, soprattutto se sono stateless, come spesso suggerito, è, potenzialmente, parallelizzabile. Bisogna, però, tener conto della necessità di integrarli e, quindi, del lavoro da prevedersi sull'orchestrator e in fase di definizione delle interfacce. Inutile ricordare che più aumenta il parallelismo, più aumenta la dimensione del team e il carico di gestione del progetto. Inutile ricordare che, anche procedendo percentualmente, l'ingegneria del software insegna che esiste un limite oltre il quale la gestione salirebbe esponenzialmente e conviene comunque mettere i task in serie, perchè i costa molto meno. Per chiudere l'elenco delle cose che è certamente inutile ricordarvi, permettetemi anche di farvi notare che l'ipotesi di poter fare servizi stateless implica centralizzare parte dell'intelligenza dell'applicazione ed un appesantimento degli sviluppi per continuo passaggio di parametri. Senza considerare che, in un disegno pulito, la gestione della sessione non dovrebbe stare negli strati più alti dell'Application Server, ma tra i servizi e recuperarla potrebbe richiedere ulteriori overhead.

  • rework inatteso: se pensate di integrare servizi esposti su Internet, iniziate a mettere in conto un bel po' di contingency, perchè questi servizi possono cambiare senza preavviso. E' facile usarli, solitamente, se ci limitiamo a servizi che impattano solo sulla presentation (widget e compagnia bella), ma se doveste trovare un servizio da integrare per fare qualcosa di serio, pensateci due volte e confrontatelo bene con le stime di cosa comporterebbe rifarlo internamente, tenendo presente queste possibilità di rework

  • test: saranno più complessi. Non tanto, come sento suggerire da tutte le parti, per la necessità di automatizzare i test (attività dispendiosa e utile, a mio parere, solo se prevedete di avere potenzialmente molte regressioni, altrimenti costa meno farli fare a qualche umano), quanto per la necessità di testare una ad una tutte le integrazioni con i diversi servizi, soprattutto se ce ne sono di esterni

Pensate che abbia esagerato? Che non dovevo necessariamente raccontare tutto in questo solo post?
Ma se abbiamo solo iniziato, riuscendo a malapena a condividere le basi terminologiche...

Bye
    Depa

[... continua ...] Leggi tutto

lunedì 26 marzo 2007

Adelante, presto, e con un po' meno juicio


Ne ho letto bene altrove da utenti famosi e anche da un punto di vista tecnico, per non parlare della voce più autorevole del lifestyle tecnologico: anche Wired gli dà il suo voto. Se vince queste elezioni, vorrà dire che andrò all'opposizione.

Oggi ho installato Democracy Player e ne sono rimasto profondamente deluso.

Ne ha giovato, però, il mio lavoro, perchè l'ho trovato improvvisamente decisamente più interessante.
E pure la lunghezza di questo post, uno dei più corti delle ultime settimane.
Mi rifiuto pure di aggiungere un'immagine a mo' di protesta sindacale.



Se avete tempo 15 minuti per vedere qualcosa nella pausa pranzo, non perdeteli con Democracy Player.
A meno che non l'abbiate lasciato acceso tutta la mattina, per scaricarvi un unico file.

E' lento nel permettervi di usufruire dei video.
E' mortalmente lento nel fare le ricerche.

E' una sorta di download manager e video player, con alcune (poche e banali) pretese social.
Stream come quelli a cui ci stiamo abituando con Joost e YouTube, neanche a parlarne.
Potete cercare su più fonti video (YouTube, Yahoo e Google Video e altri 3 o 4), ma se dai siti originali li potete vedere durante il download, qui dovete aspettare che finisca. Quindi, un filmato di 15 minuti, che avreste visto in 15 minuti con YouTube, ve lo potete vedere in 15 minuti più altri 10 di download.

Assurdo.

Se, per caso, vi sbagliate e cliccate su un altro link qualunque all'interno del programma, dovete ripartire da capo. Davvero non è proponibile una ripresa del download, che già si usava 5 anni fa? I filmati occupano spazio? Ma se una delle caratteristiche del player è quella di salvare i filmati in locale per rivederli (con expire in 5 giorni, di default) anche off-line... (saremo mai off-line, nei prossimi anni?).

E comunque, basterebbe aggiungere una funzionalità per decidere quali di quelli in sospeso cancellare, magari con reminder prima di uscire dal player.

Come tipologia di contenuti trovate quelli delle fonti che avete già nei bookmark, più qualche vblog (video blog).

Stessa qualità video e audio, ovviamente.
No, in realtà avete anche qualche canale in più con la possibilità di accedere a video di altissima qualità.
Fatelo voi, però, perchè io ci ho provato, ma ci volevano oltre 45 minuti, per scaricarli a 4Mbit.

La televisione del futuro?
Effettivamente, se andiamo avanti con i reality che ci propinano, nel futuro potremmo anche arrivare a farci altrettanto male anche con la TV, ma non vedo un solo motivo per anticipare i tempi.

Non posso ottenere lo stream di YouTube, Yahoo e Google e mi vengono filtrate, riducendole di parecchio rispetto ai siti, le funzionalità.
Non posso avere la qualità di Joost.
Se faccio una ricerca devo aspettare un sacco di tempo.
I bookmark posso averli anche nel mio browser.

Qualcuno, per favore, mi spieghi a cosa serve questo oggetto, mi devo essere perso qualche voce di menù.
Come ha fatto a diventare così famoso?

Voglio essere positivo a tutti i costi, però:
- è in grado di gestire un elevatissimo numero di formati video
- è GPL, quindi si può leggere il codice ed imparare come è fatto. Sempre che serva a qualcuno, ovviamente.
- siamo alla versione 0.9.5: prima di arrivare alla 1.0 potrebbero (ma ci sono pochi numeri di release ancora disponibili!) anche riuscire a correggere il tiro qui e là.

Bye
    Depa

P.S.: volevo dargli una seconda possibilità, l'ho ricliccato, forse mi sono perso delle preferences (a parte il fatto che scegliere dei comportamenti di default come quelli impostati sarebbe persino peggio).
Ottengo:
XML Parsing Error: undefined entity
Location: chrome://dtv/content/main.xul
Line Number 8, Column 1:<window id="main" title="&main.title;"
^

Si è eliminato da solo. Ha fatto bene. Questa volta sì, che mi ha fatto risparmiare tempo.

[... continua ...] Leggi tutto

domenica 25 marzo 2007

Keep In Touch



Poco fa ho aggiunto i link al mio blog.
Cosa aspettavo a farlo?
Forse attendevo di capire gli altri blogger e non solo di pensare a scrivere qualche post.

Sì, perchè i meccanismi di questa strana vetrina mi erano del tutto ignoti, fino a circa 2 mesi fa.
Ovviamente sapevo cosa fosse un blog da un punto di vista tecnico e di obiettivi macro.

Avevo pensato di usarlo come marketing personale, come un modo per pubblicare le mie idee, anche senza avere un editore alle spalle.
L'ho sempre pensato come una comunicazione prevalentemente one-way, con qualche feedback, ma essenzialmente cattedratica.
Pensavo che fosse necessario verificare i meccanismi di promozione che ci girano intorno (blog ring, motori di ricerca, Technorati, analisi degli argomenti di nicchia, etc. etc.).

Una sorta di estensione, per altri canali, del freddo (e potente, per scopi professionali e non, per mantenere il contatto) LinkedIn.

Non avevo capito nulla.
Vah beh, poco.
Ok, mi erano sfuggiti solo alcuni aspetti, ma importanti.



Quello che avevo totalmente sottovalutato era la capacità di creare dei dialoghi off-line, di imparare dagli altri e di imparare qualcosa in più su di me.

Non avrei pensato, per esempio, agli effetti collaterali in cui sarei incorso andando a vedere chi caspita fosse quella Isadora che mi stava referenziando.
Per scoprire che ci sono tanti modi di dire veramente qualcosa, di raccontare. Ero abituato a vedere blog stereotipati, con post di una decina di righe, inutili sia per chi li scriveva che per chi ci atterrava. Reblogger, per lo più.
Ma alla casa di Isa ho visto che ci si può infuriare con dolcezza e che possono essere interessanti anche i casi ed i problemi della vita di tutti i giorni degli altri.

Si può essere eleganti, seri, commoventi parlando di una smart card da abilitare.
Si possono trovare dei legami a distanza, pur trattando argomenti diversi.
Ci si può contattare via e-mail e scoprire altri punti di contatto.
Ci si può soffermare a pensare che la casa virtuale, che ti unisce al tuo paese d'origine, possa essere accogliente come dovrebbero essere le mura domestiche e che la nostalgia possa essere raffreddata, immergendola in caldi approfondimenti della propria ed altrui esperienza.

Si possono scoprire link che portano su blog scritti così bene da essere imbarazzati nel trovarsi citati lì in mezzo.
Ti puoi trovare incastrato nel parlare di argomenti troppo grossi per te, perchè, comunque, è un rilassante salotto (anche se in mezzo alla neve) in cui esprimersi.

Potresti conoscere Sgrignapola e salutare il suo maggiordomo Alfred, (ma solo quando ha problemi di personalità - virtuali - multiple), dimenticandoti di chiedergli di estendere i saluti anche al suo collega Jeeves.

Si trascura il fatto che ti possano scrivere persone che non senti da tempo e si possano intraprendere discorsi a distanza, quando credevi che gli auguri ed i saluti e come stanno i bimbi, guarda come sono cresciuti, incontrandosi per caso, fossero il tipo di contatto standard.

Così è capitato che il blog di riuriuchiu, (apparentemente sito di stile letterario della mamma di Elmo, certamente interessante per tutti gli spunti di lettura e altrettanto imbarazzante, come i link su citati, in termini di ricerca della comunicatività ed espressività, con approfondimenti formali, tecnici e multimediali, con le passioni appena lasciate apparire in superficie e subito trattenute e nascoste da una poesia o una domanda ai lettori), abbia portato ad un rinnovato incontro e approfondimenti diversi da quelli dei tempi in cui ci si trovava con gli amici, ai tempi dell'università.
E, di nuovo, scoprire che attraverso il blog si cerca anche supporto psicologico, compagnia, amicizia.
Per capire che si possono imparare utilizzi dell'informatica anche dalla prof. di lettere.

E poi, lrkwz... quante cose ha insegnato a me e ad altri che abbiamo avuto la fortuna di lavorarci assieme.
E, attraverso il blog, mostra ancora una volta che è possibile estendere sia in ampiezza che profondità le proprie conoscenze informatiche, che è necessario essere leggeri nel raccontare problematiche tecniche e, sorpresa (? mica tanto, conoscendolo), che si possono tenere i contatti umani anche tra una riga e l'altra di codice. E non sto parlando dei link che puntano qui, ma del fatto che, tra un post e l'altro, si possa - ma è solo un esempio - anche rendere onore ad un collega. C'è chi insegna senza farlo pesare, perchè è nella sua natura. Io non ci sono mai riuscito e mi fa pensare parecchio.

Agylen, l'ho già citato più volte. Perchè bisogna mostrare il carattere e l'intelligenza, avere il coraggio delle proprie idee in modo anche esagerato. Talvolta un po' sopra le righe, per me spesso irritante sui post scettici, (sono cattolico - lo vedrete presto in qualche post - e qualche primo approfondimento storico, scientifico e teologico mi porta ad esserlo ancora di più, non sopportando le prese di posizione banalizzanti ed aprioristiche), talvolta molto complesso da leggere. Ma oltre l'intelligenza è interessante anche la fonte di energia, mascherata sotto i bit e qualche snapshot. Una dei motivi per cui ho iniziato a scrivere un blog. Un riferimento informatico importante. Una personalità complessa. Forse il più vicino alla mia prima idea di blog, ma comunque parecchio oltre la semplice esposizione.

In raeazione allo scetticismo appena citato, segnalo anche Kattoliko Pensiero (che, per ora, leggo e basta, neanche troppo spesso). Nonostante siano anche necessarie posizioni così forti, preferirei qualcosa di meno 'politicamente scorretto', più tecnico, più storico, più vicino alla comprensione dei molti (alla mia, in particolare).
Più Messori, se potessi chiedergli un blog e non solo il sito.
Siamo in un momento in cui è più facile nascondersi nel pensiero dell'opinione pubblica, opportunistica e personale, circondati da presunte modernizzazioni, che ripetono, spesso banalizzandoli, problemi già approfonditamente discussi nei secoli (quindi, tutt'altro che moderni). Le stesse pretese spesso rinascono in noi stessi ed è sempre utile avere (anche su Internet e nonostante i grandi problmemi per individuare fonti affidabili, all'interno del marasma delle informazioni di ogni tipo) chi ti ricorda che restiamo sempre nani, ma troppo pigri e distratti da mille sciocchezze per aver voglia di salire sulle spalle dei giganti, come sapevano di dover fare i nostri antenati.

Gli altri link che ho aggiunto non rientrano in qualcosa che mi ha preso di sorpresa nei blog, se non la possibilità di poter dare informazioni esaurienti, qualitativamente elevate, interessanti. Non scritte per caso o (solo) per interesse e vetrina.

Mi raccontano dei miei amici motociclisti che quando si incontrano con altri di questa loro strana specie, si scambiano un gesto di saluto cavalleresco e di rispetto (è sempre stato inutile fargli notare che anche tra automobilisti ci si saluta spesso, sono troppo di parte, negano anche l'evidenza per principio, arrivando persino a sostenere che il medio alzato non è un saluto). Ecco, le prime esperienze che ho avuto scrivendo su Internet mi hanno fatto pensare a diverse forme di simili gesti di cavalleria (come per i motociclisti, intendo, non gli automobilisti).

E non solo da parte dei blogger. La maggior parte delle foto che accompagnano i miei post, arrivano da Stock.XCHNG. Lì sopra un sacco di gente in gamba condivide gratuitamente (per lo più) i propri scatti. Alcuni richiedono di essere avvisati.
E così ho conosciuto juliaf (Concorde, USA, che lavora in un centro per i diritti dei disabili) e jazza (Amsterdam, graphic designer). Mi hanno ringraziato. Cioè, loro hanno fatto la foto, io l'ho usata, l'ho notificato e loro hanno ringraziato me (mi sono sentito piccolo così). E abbiamo anche scambiato due parole (con juliaf sull'Italia e gli USA, con jazza su Calvino - ha pure letto un libro che mi manca...).

E' l'isola che non c'è? Dobbiamo usare la maschera dei nickname, per comportarci in modo umano?

Fatevi sentire, ora che mi sono accorto che sono io e non il mio blog, che ho bisogno dei vostri feedback.

Bye
    Depa

P.S.: bleah, quanto miele... quanti visitatori non occasionali mi sarò giocato con questo fare patetico?
P.P.S.: se pensate che sia un post patetico e melenso, non avete capito nulla.

[... continua ...] Leggi tutto

giovedì 22 marzo 2007

Quando meno te l'aspetti


Sono stato un po' impegnato, ultimamente, vi ho lasciati senza post per un bel tocco di giorni.

Per evitare che disdiciate l'abbonamento, eccomi, sono tornato.
Ma il titolo non si riferisce a questo, ovviamente.

No, si riferisce alle nuove frontiere dell'HTML, quelle che ci faranno arrivare là, dove nessun uomo è giunto prima.

E anche meno.
Più, più, volevo dire più, voi non sbagliate mai?



Sei pronto?
Io sono nato pronto
Jack Burton - Grosso guaio a Chinatown - 1986
(a sua parziale discolpa, non poteva sapere del WWW)

E voi, siete pronti a cambiare le impostazioni delle vostre applicazioni?

Non sono un Web Designer, ma un architetto software, però è evidente che eventuali modifiche all'HTML interessino un po' tutti, soprattutto se possono cambiare il modo di realizzare le applicazioni e di progettare l'interazione, da un lato con l'utente, dall'altro con gli altri layer del sistema informatico.

In questo post parleremo brevemente (trovate anche voi che la mia interpretazione di questo avverbio sia piuttosto artistica ed elastica?) di cosa si prospetta nel breve (e dai...) periodo.

Come saprete certamente, è dalla vigilia di Natale del 1999 che questo linguaggio non varia di un bit o quasi.
Siamo, da allora, alla versione 4.01. Se avessimo continuato con la velocità con cui si è arrivati a questa quarta versione, oggi potremmo essere quasi alla settima o alla ottava (non conta il fatto che Tim Barners-Lee lo avesse già definito negli anni '80: era rimasto tale e quale fino al 1994, anno in cui è iniziato il WWW con l'uscita di Mosaic, è da lì che bisogna contare).

Invece, (giustamente, perchè non se ne poteva più), il Web decise di prendersi una pausa.

Le evoluzioni erano state guidate più dai singoli produttori di browser che dal W3C, che oggi sarebbe (il condizionale non è un errore) il detentore dello standard.

Di fatto, sono sempre i produttori che si sono pian piano fermati, che hanno smesso di aggiungere tag per farsi dispetto, continuando, al più, con qualche schermaglia sulle varianti di Javascript (per tacer delle vicende legate a Microsoft/SUN e strati inferiori della Java Virtual Machine, ovviamente), fino ai recenti ulteriori adeguamenti in termini di funzionamento di div da una parte e di client http embedded (XMLHTTP*) dall'altra (per le chiamate asincrone di AJAX, per capirsi).

Sembrava quasi tutto calmo, ma poi, da un Safari, nel 2004, è stato tirato un sasso.
Forse sarebbe passato più inosservato, se non fosse stato raccolto da Firefox 1.5, a fine novembre 2005 (per i disattenti ricordo che siamo alla 2.0 e attendiamo la 3, che dovrebbe avere pure un nuovo motore grafico).

Non subito evidenziato (se seguite il link, noterete che non se ne parlava neppure, nel rilascio di Firefox) ci è voluto qualche mesetto perchè qualcuno iniziasse ad utilizzare una parte del proiettile, il tag <canvas>.

Canvas vuol dire tela ed è il nome standard, in quasi qualsiasi linguaggio io conosca, per indicare gli oggetti su cui si può disegnare.
Infatti, sul canvas sono possibili una serie di operazioni, più o meno complesse, dal disegno di semplici forme, all'import di immagini, a trasformazioni varie, fino all'animazione, come visibile dal tutorial di Mozilla. Client light, solo html e javascript. Bello.

Di per sè non sarebbe neppure così rivoluzionario (si poteva usare Java o Flash per gli stessi scopi - vero, non saremmo alla moda, oggi ci vuole AJAX), ma l'aspetto più interessante è che il tag su citato non è solo, ma è parte delle specifiche del nuovo HTML5, nome in codice di Web Application 1.0, del WHATWG.

WHAT che? Chi sono questi signori? Loro dicono:

It is a loose unofficial collaboration of Web browser manufacturers and interested parties who wish to develop new technologies designed to allow authors to write and deploy Applications over the World Wide Web.

Per voi che mi seguite perchè questi post sono in italiano e non capite l'inglese, provo a tradurre, a senso:

Eravamo al bar e così, per caso, ci siamo incontrati e, senza neppure chiederci chi potessero essere quelli seduti al tavolo con noi e quasi senza accorgercene e, comunque, senza impegno, abbiamo deciso di aiutare tutto il WWW a crescere meglio

Cercando su Internet i nomi dei membri (rappresentanti dei produttori di browser), troviamo 4 esponenti di spicco (tra cui il CTO) di Mozilla, 2 (tra cui il CTO) di Opera, uno degli architetti di Safari, precedentemente in Netscape e co-autore di Firefox, uno sviluppatore di librerie per Javascript di IE7 (non di Microsoft, almeno per quanto ne so, ma un guru di Javascript piuttosto noto); ce ne sarebbe un'altro, ma non sono riuscito a trovare informazioni utili, partendo dal solo nome (se le scovate, fatemi sapere).

Come vedete, è esclusa Microsoft che, come percentuale di utenti di browser non è proprio trascurabile.
Non stupisce, quindi, che il tag <canvas> manchi in IE7 e che sia necessario aggirare il problema (librerie varie, tra cui quelle che sta scrivendo Google - seguite il link di Sourceforge, non il tab di download -, essenzialmente basate sulle capacità già presenti in IE - estensioni downloadabili a parte - di interpretare il VML - Vector Markup Language).

Ma torniamo al punto fondamentale: come mai l'html evolve senza W3C? La domanda è, almeno in parte, errata.

Sicuramente il tentativo del WATHWG è quello di forzare la mano e di prendere il controllo di parte delle evoluzioni a breve, ma fin dalle prime specifiche di Web Application 1.0, ovvero dal settembre del 2005 (l'ultimo working draft è aggiornato costantemente), correttamente, il WHATWG faceva riferimento ad un lavoro in corso da parecchio tempo al W3C (parafrafo Relazioni con XHTML2), riconoscendone gli scopi, evidenziandone alcuni limiti e chiudendo con una frase pseudo-pacifista, vagamente interpretabile come: non sono alternativi, possono convivere.

Quindi, il W3C stava lavorando all'XHTML2. Qualunque cosa sia, vi starete dicendo.

Se andate sul sito del W3C, potete scoprire che il 7/3/2007 il W3C ha lanciato il nuovo HTML Working Group e (guarda combinazione) l'XHTML2 Working group. E come caspita facevano, nel 2005, a citare l'XHTML2 nelle specifiche dell'HTML5 quelli del WHATWG, se è nato 2 settimane fa?

Perchè il primo draft dell' XHTML 2.0 è dell'agosto 2002 (l'ultimo, l'ottavo, di metà dell'anno scorso). Semplicemente nessuno se lo era filato seriamente, fino alla fine 2005/inizio 2006 (l'interesse è certamente stato sollevato anche da questi due gran begli articoli sull'HTML5 e sull'introduzione ad XHTML2 di IBM del periodo citato, che, tra l'altro, fanno anche un riassunto dei vari gruppi di lavoro del W3C collegati a questo argomento ed elencano i principali vantaggi delle nuove specifiche in un modo così chiaro e sintetico che sarebbe inutile ripeterle).

Pausa. Un bicchiere d'acqua. Ho la gola secca, a furia di parlare. Inoltre mi devo calmare perchè ho appena ricevuto una telefonata di minacce: devo piantarla di parlare in sigle (già ne hanno abbastanza di parentesi ed incisi vari) e cercare di essere più chiaro, altrimenti o mi uccidono l'orso di peluche o lasciano il blog.

Vah beh, ci sono questi due linguaggi, no?, entrambi evoluzioni di quello che serve per scrivere 'sta roba che state leggendo, cioè, no?, entrambi vogliono descrivere il vostro futuro,...
Basta. Uccidete l'orso di peluche (non lasciate il blog!), non posso mica andare avanti così.

Torniamo a noi. Nonostante diversi blog, siti, forum abbiano già discusso a lungo su queste questioni e abbiano più volte stabilito che non ci sarà un vincitore e non cambierà nulla per un sacco di tempo, la recente posizione del W3C e la continua diffusione di informazioni su questi aspetti fanno pensare. Il fatto che elementi dell'HTML5 siano già disponibili su Safari, Opera e Firefox e loro estensioni su IE, aumenta questa sensazione.

Personalmente trovo che le evoluzioni di cui trattano siano utili. Le strade delineate sembrano avere entrambe punti di forza e di debolezza.

Se non dovessero convergere, potrebbero esserci due linguaggi (o anche di più, ottenuti da misturoni dei due) al posto che uno.
Il vantaggio principale che vedo nell'HTML5 è la sua continuità con il passato e la sua facilità di apprendimento.
XHTML2, invece, ha la forza di una definizione più pulita, tecnica e mi sembra architetturalmente più approfondito e più adeguato ai cambiamenti richiesti anche dal Web Semantico. Sarà che ci stanno lavorando da più tempo?

Ah, già, non stiamo ancora considerando cosa potrebbe fare Microsoft. Al momento sembra non muoversi (un po' come il gatto prima del balzo?). Sono solo terze parti che, tra tag canvas e plugin per xforms (se avete letto i link che vi ho dato sopra, dovreste già sapere che si tratta di una evoluzione delle forms di HTML in ottica MVC - non vi so a spiegare, tanto l'orso è già andato e potete leggere i link), si stanno preoccupando di espandere IE in queste direzioni. Ma il loro ingresso in campo potrebbe alterare parecchio i giochi.

Nel passato avrebbero fatto una scelta zen: nè una nè l'altra specifica... ma una nuova, loro.
Ma ora è come se avessero sostituito la colonna sonora: da My Way al 'I'm not half the man I used to be' di Yesterday. Non ci sono più certezze, stanno pure facendo uscire un sacco di prodotti gratuiti (ho già detto 'Timeo Danaos...' sì, mi pare di sì...).

Bye
    Depa

P.S.: ultimo link, assolutamente necessario. Per me questo approfondimento è partito da una bellissima versione grafica di Wordnet, realizzata in Javascript. Il signore che ha programmato questa roba, dovrebbe esserci riuscito anche senza VML (IE non mi chiede di scaricare il plugin). Come ha fatto, allora, visto che su IE non c'è il canvas? Appena ho tempo apro i file JS, cerco di capirli e vi faccio sapere.

[... continua ...] Leggi tutto

giovedì 15 marzo 2007

Just another brick in the wall?


Siete stanchi voi per aver letto quelle due righe sul Web Semantico?
Cosa dovrei dire io che le ho scritte?

Infatti mi sono preso una pausa.
Ho deciso di giocare con mia figlia con i LEGO.

Mi ricordavo che era divertente, anche se, certamente, non c'erano tutti quei pezzi, quando ero piccolo io.

E' un continuo fare e disfare.
E' quasi piacevole sentire i pezzi che si incastrano. Invece odio doverli separare.
Mia figlia no, a 4 anni le piace di più distruggere. Di solito dopo un quarto d'ora di mie costruzioni.
Oh, guarda, c'è anche un libretto di istruzioni, così si può fare qualcosa di più complicato.

C'è una sigla, 7795 Deluxe Starter Set, ovviamente sono numerati.

Chissà cos'altro ci può essere dopo questo set iniziale.

Non dovevo chiedermelo, vero?
Voi lo sapevate e non mi avete fermato.
Lo avete fatto apposta, dite la verità.



Ci vuole un attimo. Ci si siede di fronte al monitor solo per un momento.
Un istante dopo ci si infila in uno user group.

Ci sono set per tutti gli argomenti.

Ci sarà anche la storia, da qualche parte? No, quella è solo sulla Wikipedia.
Ah, erano falegnami, come Geppetto.

E come lui hanno iniziato a fare giochi che sono in grado di muoversi da soli. Gli hanno messo sensori e motori.
Si chiamano Mindstorms.
Sono programmabili.

Anche in Java.
Ne voglio uno.

Aspetta, vedi mai che su YouTube mi fanno vedere come funziona.

Secondo errore.

Uno dei filmati che ho trovato lo avete visto all'inizio del post.
Sono bellissime le esplosioni con i mattoncini che volano da tutte le parti e le continue ricostruzioni delle astronavi.
Se volete vedere da capo tutto Star Wars, fatto a pezzi ('mattoncini'?) di 2-7 minuti, potete anche riuscirci, secondo me.

Sono convinto che, in termini di contenuti, potrebbe far contento anche l'anonimo che mi ha scritto a proposito di Joost.
Anche se non conosco i suoi gusti, se non altro siamo di fronte a qualcosa che non viene trasmesso spesso.

Un consiglio, però: non andate a cercarne altri, a meno che non vogliate divorziare. O perdere il lavoro.
O perdere la testa.

Però, certo che li hanno animati bene, vero? Belli fluidi, fin troppo morbidi.
Caspita, chissà quanto tempo c'è voluto.
Anche se avessero avuto un CAD, ci potrebbe voler.... ferma tutto. Vuoi mica che ci sia anche un CAD, vero?

Terzo errore.
Mia figlia si lamenta che non gioco mai con lei e lavoro sempre troppo con il computer.
Insomma, non sto ben cercando queste istruzioni per lei?

Vediamo un po' LDraw, MLCad e il suo tutorial (guarda, combinazione, costruiscono proprio un'astronave), scarichiamo, ah, si integra anche a POV-RAY per il rendering,...
Scusate, cosa fate qui? Che c'è da guardare? Tornate a leggere un'altra volta, non vedete che ho da fare?

Bye
    Depa
P.S.: c'è anche un wargame, e il conteggio dei danni fa saltare un corrispondente numero di mattoncini sull'unità...

[... continua ...] Leggi tutto

mercoledì 14 marzo 2007

Come forzare un lucchetto



Sembra incredibile, ma tra le ricerche che ieri hanno portato al mio blog c'è la frase riportata nel titolo.
Quando l'ho visto mi sono chiesto se potevo aver scritto qualcosa in trance e aver svelato anche i segreti del grande Houdini
Ho ripetuto la ricerca e, come vedete dalla foto, è proprio vero: addirittura sono in cima all'elenco!
Fortunatamente sono secondo, anche se si cerca hibernate pro e contro :)

Evidentemente qualcuno cercava di capire come possa essere fuggito Marco Berry in Danger, probabilmente queste ricerche aumenteranno con le puntate del programma.
A pensarci bene poteva pure essere uno scassinatore di cassette di sicurezza. Un professionista, che ha ben chiaro che bisogna prepararsi, prima.
Beh, a quanto pare, sono io che ho rubato uno unique visitor, stavolta.

Comunque, sfruttiamo questa situazione e scriviamo anche questo post: se già ero in cima prima, ora chi mi smuove più? Gli hits sono hits, ragazzi (e lo so che la 's' finale non ci vuole, in italiano: l'ho messa apposta, per accentuare il suono sibilante dell'ultima frase).

C'è un problema in tutto questo: non sarebbe dovuto capitare. Anche per voi, dico, perchè poi vi dovete sorbire questi vaneggiamenti.

C'è forse una soluzione informatica? E' forse il Web Semantico?



Prima di passare alla discussione vera e propria, è necessario che vi segnali anche il secondo risultato dell'elenco (che, intanto che scrivo, è passato primo: forse anche per colpa mia): è un blog di enigmi, ma era inevitabile che a questo dovessi commentare (l'ho fatto, andate a leggervi cosa ho scritto su quel post), dal momento che era evidente che stavano parlando di informatica.

O sembrava solo a me? Davvero non distinguo più vita e informatica?

Torniamo al Web Semantico.
Come introduzione vi consiglio una presentazione della Dott.ssa Mordonini, usato in un seminario nell'Università di Bologna, molto chiaro ed esteso.

Provo giusto a riassumere due o tre punti essenziali, da dilettante dell'argomento e con un occhio, al solito, alle implementazioni pratiche:
  • il Web contiene un numero enorme di informazioni che non sempre riusciamo a raggiungere come vorremmo (e fin qui, lo sapevate già, l'ho riportato solo per vedere se eravate svegli e mi stavate seguendo)

  • il problema è legato al fatto che il Web è oggi costituito solo da legami sintattici (URI) e non semantici. Ovvero, le pagine sono, tipicamente, collegate tra loro senza una spiegazione del significato del link, che possa essere utilizzata da un computer.

  • non basta aggiungere dei tag, simili a quelli che trovate nei vari blog, per aggiungere questo significato: è necessario un maggior formalismo per permettere di applicare algoritmi inferenziali.

Parentesi.
    Le slide chiariscono che Web Semantico non è Intelligenza Artificiale (AI), ma più avanti ricordano che sono necessarie capacità inferenziali (correttamente evidenziando che in questo ambito, ci interessa particolarmente la deduzione e non l'abduzione o l'induzione).

    Probabilmente è corretto, ma solo in senso stretto e formale, e cercando di dare ragione a Douglas Hofstadter che, nel suo oramai-letto-anche-dai-sassi (se non lo avete fatto, è un po' tardi: per quanto sia un libro grandioso - vinse anche il premio Pulitzer - è del 1979, un po' datato, visto l'argomento) Gödel, Escher, Bach - Un'eterna ghirlanda brillante sosteneva che
    l'Intelligenza Artificiale è tutto ciò che non ancora non è stato fatto
    perchè
    tutto ciò che le macchine hanno imparato a fare e che (prima che lo facessero) era ritenuto segno di comportamento intelligente, non viene ritenuto più tale una volta che le macchine lo fanno
Fine Parentesi.

Le slide proseguono con una ben chiara distinzione tra semplici tassonomie, tesauri (es: Wordnet) e ontologie (es: OpenCyc).

Vorrei evitare di appesantire ancora, ma sono costretto a due rapidi pprofondimenti, altrimenti non si capisce più nulla, (rivedremo entrambi gli argomenti in prossimi post in maggior dettaglio):
  • Wordnet è un vocabolario semantico, organizzato in Synset, ovvero insiemi di sinonimi. Ovvero: come certamente sapete le parole (i lemmi) possono avere diversi sinonimi. I dizionari dei sinonimi e dei contrari dei tempi della scuola sono un primo passo in questa direzione, ma hanno la brutta tendenza a mettere assieme sinonimi anche con significati differenti (non tutti, ma quelli che si comportano bene non ci stanno, nella cartella) ed è, comunque, difficile, fare dei controlli incrociati di congruenza senza averli in formato elettronico. I Synset, invece, sono insiemi di sinonimi con lo stesso significato. Per fare un esempio, il lemma prova comparirà in diversi Synset, insieme ai suoi sinonimi. Per es:

    • prova, evidenza, ... (nel senso di prova giudiziaria)
    • prova, esperimento, ...
    • prova, esame, ...
    • etc. etc.
    Ogni Synset rappresenta, quindi, nella pratica, un concetto diverso.

  • Di OpenCyc vi ho già parlato, e ne riparleremo più avanti, è troppo complesso per spiegarlo in 2 righe - spero riuscirete a dormire la sera, nel frattempo. Per ora ci basterà dire (tagliandola spessa) che la principale differenza rispetto a Wordnet sta, soprattutto, nell'aggiunta della capacità inferenziale e di informazioni necessarie a supportarla (Knowledge Base, una base di conoscenza, abbreviata con KB). Peraltro esiste, nella KB di OpenCyc, una esplicita relazione con Wordnet e le relazioni tra i lemmi ed i loro significati (esistono anche relazioni implicite, basate sulla struttura delle informazioni, ma non sono, solitamente, mappabili 1:1 con facilità).

A questo punto del post voi siete stremati, anche se io ho a malapena finito la premessa.
Questa volta, però, non vi grazio, altrimenti non arriveremo mai al punto.
Inoltre non ho ancora sentito suonare la campanella.

Per portare tutte queste considerazioni sul Web, è necessario un linguaggio che permetta di aggiungere informazioni strutturate alle pagine.

La proposta più consolidata, ad oggi, la si trova in un insieme di linguaggi formali (per lo più basati sull'XML) che, a diverso livello, permettono di definire le proprietà che descrivono i documenti (risorse identificabili da un URI) e di ricercarle.
Sempre andandoci giù pesante con le semplificazioni, si tratta di:
  • RDF: attraverso triple [soggetto, predicato, oggetto], anche complesse e composte (es: un oggetto può essere, a sua volta, una tripla - si parla di reificazione), si forniscono proprietà al documento

  • RDFS (RDF Schema): permette di descrivere le classi dell'RDF (ovvero, serve per definire meta-informazioni riguardanti i componenti della tripla di cui sopra), specificandone relazioni e vincoli

  • OWL (Ontology Web Language): siccome la coppia di cui sopra ha solo un limitato potere espressivo, viene proposto (via W3C e sempre nel contesto RDF) questo linguaggio, con l'intento di permettere di eseguire delle inferenze

  • SPARQL: il linguaggio W3C per eseguire query sull'RDF, di fatto una sorta di SQL portato su queste tecnologie

Niente male, come stack (non sono in grado di valutarlo ora, anche per mancanza di tempo, ma pongo lo stesso la domanda per chi fosse in grado di rispondermi: non sarebbe più semplice usare un solo linguaggio come CycL, quello usato per OpenCyc? è veramente più complesso da imparare, o stiamo solo nascondendoci dietro alla sintassi per problemi più seri che interessano la semantica? anche l'espressività ne guadagnerebbe, o no? non piace il fatto che si tratti di una proposta di una sola azienda e che il gap per creare simili motori sia difficile da colmare?)

A questi dobbiamo aggiungere un vocabolario condiviso. Qualcuno suggerisce che URI che puntano alla Wikipedia potrebbero fare al caso, altri (compreso il W3C) propongono vocabolari più specifici.

E' importante notare che non si tratta di sola teoria, ma esistono già tool che trattano queste problematiche (es: Jena, un framework per il Web Semantico in Java, che è in grado di gestire RDF, RDFS, OWL, SPARQL e contiene già un motore inferenziale - realizzato dagli HP Labs, ma presenta licenza apache-like).

Tutto risolto? Veramente no: restano aperti problemi pratici importanti:
  • bisogna comunque partire da informazioni corrette, alla base, altrimenti otterremo ragionamenti non corretti. Ovvero, anche in perfetta buona fede è facile ricadere nelle ambiguità del linguaggio naturale. In generale, per costruire una ontologia in un ambito ristretto, tipico di una Intranet e limitandosi ad argomenti tecnici, ci possono volere mesi/uomo (infatti, sono allo studio classificazioni automatiche). Approfondiremo meglio questi aspetti quando parleremo dell'enorme sforzo portato avanti su OpenCyc (anche se in ambito più complesso ed esteso, ovvero sulla KB alla base del senso comune) e delle best practice che da là sono emerse. Vi anticipo che non è pane per Web Designer, ma per ingegneri della conoscenza. Questa sola considerazione fa parecchio pensare, IMHO, sulla possibilità di utilizzare nel breve le tecniche fin qui descritte su Internet in modo produttivo.

  • anche supponendo che le informazioni siano corrette alla fonte, come possiamo dare all'utente finale degli strumenti semplici da usare che gli permettano di eseguire ricerche mirate? Di fargli usare SPARQL non se ne parla nemmeno (sarebbe come dire: smettiamo di fare interfacce grafiche per i vostri gestionali, imparatevi l'SQL e arrangiatevi a farvi le query da soli). Non è che l'utente finale preferirà
    una risposta potenzialmente errata e sporca (che, tutto sommato, capita più raramente di quanto si voglia far credere, soprattutto in ambiti ristretti, che sono quelli su cui oggi è affrontabile un discorso di ontologie) tipica di un motore di ricerca, che trovarsi di fronte ad interfacce complesse da utilizzare?

  • veridicità ed affidabilità delle informazioni: dovremmo prevedere una sorta di certificatore? quante risorse potrebbero servire per validare tutti i documenti immessi? Serve, comunque, un confronto semantico, altrimenti ricadiamo nella semplice verifica incrociata, già eseguita dai principali motori di ricerca, tra meta tag nell'head dell'HTML con quanto contenuto nel body

L'abbiamo presa da un punto di vista più serio della volta che vi ho parlato dell'AIML, ma i risultati sono quasi gli stessi: forse serve qualcosa di più potente ed automatizzabile. Ancora una volta, è un mio parere personalissimo, rischiamo di dover ricadere verso ambiti più legati all'AI. Quanto siamo lontano dal far comprendere il linguaggio al computer?

Forse meno di quanto pensate.
Forse più di quanto penso io (bisogna ben tenere in conto il teorema di Hofstadter -
Ci vuole sempre di più di quello che ti aspetti, anche se tieni in conto la Legge di Hofstadter
- per tacer di Murphy).

Come già minacciato, per finire quelli che sono sopravvissuti a questo post, torneremo ancora su questi argomenti parlando almeno di Wordnet (e suo figlio, Eurowordnet, che potrebbe tornare utile per le traduzioni - potendo comprare la licenza, s'intende...), Conceptual Dependency di Shank e OpenCyc.

Se un giorno di questi sono di buona magari vi parlo di approcci più leggeri, per iniziare a fare qualcosa, per esempio utilizzando bene Lucene, anche con le nuove funzionalità di stemming recepite da Snowball, ma non contateci troppo.

Bye
    Depa

[... continua ...] Leggi tutto

venerdì 9 marzo 2007

A Venezia, 'giust' si scrive Joost?



Sono un po' meno arrabbiato. Sono riuscito, infatti, ad essere tra i pochi (80.000 a cicca e spanna, non vi dico il casino quando ci si trova al bar) che hanno ricevuto un invito per poter accedere alla fase finale della beta di Joost (grazie, nel mio caso, ad una vecchia conoscenza che, tra l'altro, mi sa che dica meno di quanto sappia).

Per quelli che non sanno di cosa si tratta e che non sono invidiosi (ma anche per gli altri, per i quali scrivo più volentieri questo post), a parte rimandarli sul sito ufficiale, proverò a spiegare perchè mi sono divertito, nella prima prova.



Essenzialmente si tratta di poter vedere la tv su Internet, on demand e in modo interattivo (come YouTube? noooo, smettetela di interrompere, ho appena iniziato, così non si finisce più).

Intanto, si parte con ottime referenze: ho letto qualche blog sull'argomento (sapete, per non riscrivervi cose che avete già letto) e per la storia del nome (che ora non significa nulla, ma prima ha fatto parlare di sè), dei suoi fondatori (Skype lo conosco e lo uso mentre, chiedo venia, non ho mai usato Kazaa...) vi rimando ad altre fonti (va beh, ovviamente esiste anche la solita voce della Wikipedia, che mi sembra colpevolmente fin troppo al corrente dello stato di avanzamento e delle tecnologie alla base di questo prodotto - P2PTV, XULRunner, strumento alla base anche di Firefox e, soprattutto, del player video Democracy, H.264/MPEG-4 AVC digital video codec, etc. etc. ).

I contenuti arrivano principalmente da network televisivi (ma non ci si può far mancare quelli degli utenti, che, però, sono prima visionati dallo staff, per verificarne il livello e cercare di ridurre problemi di copyright) e sono tutti autorizzati.

La qualità è molto elevata (non ancora da TV, ma ci stiamo avvicinando a grandi passettoni), su un altro pianeta rispetto a YouTube (anche in full screen).

La durata dei contenuti è di un altro ordine di grandezza, si arriva fino a film completi, che vi potete vedere quando vi pare (e, pare, circa il 90% dei contenuti saranno gratis).

Siccome lo scopo dichiarato è quello di "combinare il meglio della TV ed il meglio di Internet", sono previsti ulteriori livelli di interazione, tipici di Internet (es: che ne pensate di commentare via chat il video che state vedendo insieme ad un vostro amico? Ci sarebbe solo il problema di sincronizzare i due video, suppongo, ma non sono stato in grado di far prove in questo senso, nell'ultima beta).

Ho provato il client beta (versione 0.8.1 del 28 febb.) da casa, con una connessione flat a 4M (a consumo non è consigliabile: parte 1Gb di banda in 10 ore...), con Windows XP e il primo commento è: WOW!!!

Considerando (anche nel seguito), che si tratta di una beta, direi che allo stato attuale non sembra affatto male e gli annunci di uscita per maggio-giugno, sembrano realistici.

Iniziamo con la qualità del video. Se dovessi basarmi sulla breve descrizione della tecnologia P2PTV della solita Wikipedia dovrei aspettarmi una fluidità non perfetta. Sarò stato fortunato, ma in 2 ore di giri, tra formato windowed e full screen avrò visto massimo tre-quattro salti, nello stream (senza ridimensionare o spostare la finestra: se la ridimensionate, si vedono).

La risoluzione è, a mio parere, decisamente meglio in Joost a full screen che in YouTube a 425x350, anche se da YouTube prendiamo un filmato di una azienda del settore e non quello fatto dal vicino di casa. Al punto che non ha quasi nemmeno senso fare il confronto. I quadretti si vedono anche in formato windowed, ma, spesso, bisogna farci attenzione.

Se spostate appena il mouse, compaiono, in sovraimpressione, i controlli (widget) trasparenti. Sono leggibilissimi e lasciano anche vedere il programma. Se devo proprio trovare un difetto, (soprattutto quelli della sezione My Joost, che permette di far comparire i ticker delle news e la chat, per fare un esempio), occupano un po' troppo spazio, per i miei gusti.
Mi rendo conto, peraltro, che ci sono anche persone meno esperte e questo, certamente, è un prodotto rivolto anche a loro.

Solo una piccola digressione: le funzionalità per l'interattività, i rapporti sociali, condivisione e tutto il rimanente carburante marketing del Web 2.0, sono ancora piuttosto ridotti ed in fase embrionale: probabilmente il loro sviluppo costituirà l'attività principale dei prossimi mesi, insieme alla ricerca di nuovi contenuti (aiuterà avere a disposizione XULRunner?).

L'interfaccia mi è sembrata parecchio intuitiva, credo di aver trovato tutto quello che cercavo entro il secondo tentativo (eppure c'è un tizio che, a quanto pare, non ha visto l'icona che porta da full screen ad una finestra più piccola - la si vede quasi nella foto che apre il post - quindi non si finisce mai di migliorare, in questo senso).

Al momento, ho contato 38 canali, ognuno con qualche decina di programmi. Un post di 6 giorni fa ne riporta circa 27: o uno dei due non sa contare, o stanno aumentando in fretta.
E siamo solo alla beta e mancano ancora circa altri 3 mesi.

Qualcuno sostiene che siano un po' poveri: infatti manca un canale di fantascienza (ce n'è uno a cartoni animati, ma guardateveli voi).

O forse è che sono io che non lo trovo? In effetti la search interna potrebbe migliorare un poco: ora cerca solo sui titoli, se cercasse anche nelle descrizioni di canali e programmi potrebbe aiutare...

Non andrò avanti ancora sul mio primo test: se troverò novità o cose interessanti ve lo farò sapere.

Volevo solo chiudere con una considerazione.
Qualcuno ha accennato, seppur, ritengo, in modo provocatorio, alla fine di YouTube che, tra l'altro, sta affrontando problemi seri. Pare che le alleanze strategiche si stiano, almeno in parte, spostando da YouTube a Joost, in questo campo. Senza contare che sta nascendo una simile esperienza italiana, Babelgum (di cui, magari, parleremo se riuscirò a provare la beta anche di quella).

Non viene citato spesso, ma, per esempio, tra i discendenti di YouTube, a me piace molto Expert Village, che riporta video selezionati di istruttori in diverse materie (cerca cerca, in YouTube trovate anche informazioni più avanzate, ma sono molto meno strutturate e si perde un sacco di tempo).

E' evidente che il panorama di questo tipo di siti è destinato ad espandersi.

Certamente si dovranno spartire la torta, quindi potrebbero perdersi degli utenti. Ma i target indirizzati mi sembrano, al momento, parecchio diversi.
Certamente, se Joost non sarà disponibile anche all'interno del browser, potrebbe incontrare qualche difficoltà di diffusione (non ho notizie in questo senso, ma mi sembra che provi a fare il contrario, a integrare dentro di se le informazioni del Web).

Io ho il satellite, ma giro su YouTube perchè mi fornisce informazioni che non trovo altrove.
Ecco, direi che il concorrente diretto di Joost sono, piuttosto, i canali satellitari, che forniscono contenuti simili a quelli di Joost, ma solo sempre quando non sono in casa (e non provate a suggerirmi di andare a districarmi tra le scart dei vari apparecchi - ancora di meno provate a cercare di vendermi un top box con hard disk per registrarci sopra i film).

Pensierino per la sera
Integrare TV ed internet potrebbe abbattere le barriere generazionali tra la generazione di Internet (l'ultima, io ne sono già escluso) e quella televisiva (la mia).
Se ci fosse anche la possibilità di videogiocare, tutto sullo stesso sito, potremmo riuscire a fare filotto e ad estraniarci completamente dal mondo reale.
E tutto volontariamente, a differenza di quanto succedeva in Matrix.

Adesso vado a spaccare un po' di legna (in senso figurato, come reazione: non penserete mica che ne sia davvero capace, vero?).

Bye
    Depa

[... continua ...] Leggi tutto

martedì 6 marzo 2007

Timeo Danaos et dona ferentis



Oggi non sono di buon umore, quindi cercherò di trasmettervi questa sensazione, possibilmente cercando di farvi arrabbiare.

Parole crociate. 4 orizzontale, 10 lettere. Definizione: SOA senza A.
Beh, facile: "WebDueZero" (Web 2.0).

Ovvero, là fuori c'è un sacco di gente che vuole fornirvi servizi.
Talvolta pure gratis.
E la piattaforma giusta è proprio quella che volete implementare, proprio nel linguaggio che avete sempre sostenuto.
Visto che avevate sempre avuto ragione voi, alla fine?

Perchè, nonostante la provocazione, non vi state alterando?
Non l'avete capita? (l'introduzione a SOA la potete trovate in un mio post di qualche giorno fa, se vi serve).

E perchè anche se alcuni stanno diventando viola in volto, non sto meglio?
Forse aveva ragione un mio amico: 'mal comune, gaudio zero'...



Torniamo a fare i bravi, almeno per un momento.

Partiamo dal primissimo principio che definisce il Web 2.0 (O'Reilly, settembre 2005 - al solito, non starò a ripetervi l'articolo originale: leggetevelo, è importante - dal link sopra trovate anche velocemente una traduzione in italiano): The Web as a Platform.

Ce l'ho solo io, questa sensazione di déjà vu? Non saltano anche a voi in mente i Network Computer?

Era un intorno ragionevolmente stretto del 1994. Il WWW stava nascendo e SUN proponeva Java al mondo. Alcune aziende si riunirono e iniziarono a sostenere che era giunta la fine dei sistemi operativi e che i computer avrebbero trovato tutto ciò che gli serviva, dopo un piccolo boot necessario per far partire browser e JVM.

A me, personalmente, sembra proprio l'evoluzione di quel concetto.
Ora, almeno, abbiamo la banda più o meno necessaria e possiamo connetterci wireless quasi da ovunque o farlo certamente nei prossimi pochi anni.
Il fatto che ora ce la si possa fare deriva dalla certezza che qualcosina già esiste, in questo senso (Google docet).
Il tutto è un po' più realistico, senza dubbio.

Ma Web 2.0 vuol dire un sacco di altre cose.
Soprattutto: cooperazione e collaborazione, condivisione di conoscenza, quello che da anni il Web sta evidenziando come suo peculiare vantaggio rispetto alle tecnologie pregresse, punti che già nel 2000 presentavo come essenziali per il Web ai miei clienti e in conferenze per le PMI (non stupisce che chi ha ideato il Web, avanzi dei dubbi sulla liceità dell'avanzamento del numero di versione alla 2.0).

Questa collaborazione e condivisione, oggi, sta dando origine a nuovi modelli di business (come, ancora? non ci è bastata la prima bolla speculativa?): si parla continuamente di Long Tail, indicando che si possono mettere in gioco quelle forze minuscole e distribuite che, singolarmente non sono in grado di pesare, ma che, se organizzate nel loro insieme, possono essere competitive contro i maggiori player di mercato.

Da cui, la nuova corsa a fornire servizi gratuiti, da parte dei maggiori player, perchè la coda cresca a loro.

Ai tempi della bolla speculativa, si regalavano account di email per contare gli utenti, moltiplicarli per un valore scelto a caso (si sosteneva che ogni utente registrato avrebbe speso, nel breve, da 1000 a 3000 dollari, se non ricordo male), e quindi, dimostrare che la dot-com valeva il corrispondente del prodotto.

Oggi, invece, molto più praticamente, si offrono servizi tecnologici perchè gli utenti possano riempirli con contenuti (pensate a questo blog, come potreste mai farne a meno..) e perchè l'insieme di tutti questi piccoli oggetti possa diventare un enorme fonte di informazioni in grado di veicolare pubblicità o altro (a proposito, facciamo solo di far crescere un po' gli accessi, perchè, allo stato attuale mi negherebbero pure la possibilità di far due euro con l'advertising, su questo blog).

Subito, non tra qualche anno.

E tutti sono contenti: io che faccio i 2 euro, perchè avrei scritto il blog anche gratuitamente e chi mi offre il servizio che ne fa diversi milioni, grazie al lavoro spontaneo di tutti (e senza contare che, magari, oltre al denaro contante, riesce pure ad aggiungere una profilazione dei comportamenti degli utenti, migliorando il database marketing).

Non fraintendetemi, non sono invidioso del fatto che altri facciano più soldi di me: io sto facendo gli affari miei, pubblicando questi post (pensavate lo facessi solo per bisogno di farmi leggere? no: lo scopo è farmi conoscere, così che potrete verificare che, nonostante il discutibile senso dell'umorismo, sono un ottimo consulente e che potrei esservi davvero d'aiuto; l'advertising non c'entra nulla: anche se dovesse mai partire su questo blog - e nutro seri dubbi - non raggiungerebbe mai una dimensione tale, una volta tolte le tasse e lo sbattimento per pagarle, da permettermi di fare una spesa al mese al supermercato).

In effetti, non solo chi pubblica questi servizi (tecnologici o di contenuto), ma un po' tutta la comunità gode dei vantaggi che ne derivano.
Già l'articolo di O'Reilly evidenziava chiaramente la nascita di importanti realtà come Wikipedia (e quanto uso ne faccio, in questi post?), Flickr, del.icio.us., sourceforge. E solo perchè non poteva citare casi più recenti e più sensazionali come YouTube o siti che si sarebbero presto svegliati da una sorta di letargo, come LinkedIn o quelli che sarebbero nati proprio dalla consapevolezza che sarebbe cresciuta una comunità che ha bisogno di servizi di questo tipo per evolvere, come Technorati.

E nascono i widget, piccoli pezzi di tecnologia e di contenuto, che potete integrare nelle vostre pagine, dal blog alla Intranet aziendale (magari in AJAX - cercando di non alzare barriere architettoniche sul Web, laddove possibile, come riportato qui e qui, per fare un esempio - come suggeriscono gli inventori del termine, nonostante io faccia fatica a capire cosa caspita c'entri Ajax in questo discorso: mi sembra come parlare della rivoluzione industriale, sottolineando la fondamentale importanza contestuale dell'invenzione del bullone - serviva per migliorare il marketing?).

Il passo che porta a proporre SOA è breve: se non volete solo dei contenuti via browser e dei widget che vivono per conto loro, ma qualcosa di più professionale ed integrato - magari agganciato anche al vostro backend aziendale preesistente - predisponete i vostri sistemi informativi per tutti i vantaggi di flessibilità e manutenibilità che sono forniti da servizi distribuiti e di indipendenza dalla piattaforma garantita dai Web Services (ah, già, stavamo per dimenticarci, se proprio volete, ci sono anche dei servizi da remoto, gratis e non...).

E comunque, non ci sono alternative: il Web, lo dico da anni, è un male oramai necessario. Quando aprite la vostra azienda, lo sapete che dovrete sostenere il costo degli uffici. Eppure i vostri uffici non sono l'azienda, che, invece, è composta dalle sue risorse. Ma le risorse devono stare dentro a dei muri, al coperto. Così il Web: evolve rapidamente e chiede soldi e continui investimenti. Dovete stargli dietro, per non perdere in competitività. Avrete forse dei vantaggi, ma, più probabilmente, manterrete almeno i muri come tutti gli altri uffici.

Sono di cattivo umore, perchè, sic notus Ulixes, temo i greci, anche quando portano i doni, ma sono incapace, al momento, di vedere il pericolo nel tirarli in cima a la sacrata rocca (e vi rimando ancora all'articolo di O'Reilly per tutti gli altri pro di cui non vi ho parlato e nessun contro).

E vivo la mia schizofrenica vita Web tra questi due contrari in forse in due parti diviso, tra le paure di Lacoonte e la stoltezza dei troiani.

Bye
    Depa

P.S.: ferentis, non ferentes nell'originale: correggiamo la Wikipedia?

[... continua ...] Leggi tutto

lunedì 5 marzo 2007

Crisi di rigetto


Sto leggendo Crypto, di Dan Brown.
Non so perchè l'ho fatto.

Mi sarei dovuto fermare subito dopo il Codice Da Vinci, come ci si attenderebbe da ogni essere pensante.

No, non mi è bastato: un po' mi vergogno, ma devo confessarvi che ho letto, qualche mese e pochi libri dopo, anche Angeli e Demoni (uno dei peggiori che abbia mai affrontato, con tanto di salvataggio finale dopo caduta da un aereo che potrebbe essere giudicato un po' forzato anche dagli autori di Mission Impossible e irrealistico persino per i cartoni animati dello Squadrone Avvoltoi di Dick Dastardly).

Quando si tira troppo la corda, prima o poi si rompe (e io mi sono rotto, casomai non si fosse capito).

Fortuna che esiste la terapia Calvino.



Non è la prima volta che mi capita, ho già fatto cose simili, per esempio, con Valerio Evangelisti e il suo Eymerich o con Frank Herbert e Dune - in quest'ultimo caso, in effetti, il primo libro della saga è proprio bello: sono i successivi, che avrei preferito non conoscere.

A mia parziale discolpa vorrei dire che, almeno nei casi citati, c'è effettivamente qualcosa che ti fa venir voglia di dargli un'altra possibilità, c'è dell'inventiva, della capacità.
Che resta una promessa, purtroppo, al reiterarsi dei tentativi.

E così, eccomi cercare qualcosa che tolga questo gusto di amaro.

Se vedete qualcosa che sembra un saggio scritto da Italo Calvino e che non ho ancora letto, avvisatemi, per favore: non riesco a resistere, è quasi più godibile che sui racconti e sui romanzi.

Se lo leggete per Palomar o per le Cosmicomiche, non abbiamo, evidentemente, gli stessi gusti: anzi, dopo un po', pur essendo dei giochi straordinari, li trovo pure un po' noiosi.

Già il Castello dei destini incrociati è su un'altro livello, pur partendo da principi simili.

Il primo libro di questo autore che ho letto è il primo che lui ha scritto: Il sentiero dei nidi di ragno.

Ero ai tempi del liceo e mi stavano bombardando con la Resistenza. Mi avevano fatto partecipare a conferenze sull'argomento, non potevo girarmi senza vedere un partigiano, ci facevano pure fare dei concorsi letterari.
Arrivano le vacanze estive: la prof. di lettere ci affibia quel testo come compitino, anticipandoci che è la lettura di quel periodo con gli occhi di un bambino.

L'ho guardato per giorni, da lontano, prima di avere il coraggio di avvicinarmi.
L'ho aperto e ho letto l'introduzione scritta da non ricordo chi e sono tornato alle mie vacanze.

L'ho iniziato e l'ho finito in poche ore, tutto d'un fiato. Bellissimo.

Pochi giorni dopo compravo Il cavaliere inesistente. Fortunatissima scelta, anche rispetto agli altri antenati. Un breve romanzo quasi perfetto e in totale armonia, a mio parere, con quanto espresso nelle Lezioni Americane, nonostante tutti gli anni di distanza.

Ma, come dicevo, è quando diventa serio che il suo genio si esprime, forse, al meglio.

Non ho potuto resistere alla sua rilettura dell'Orlando Furioso.
Certamente sa il fatto suo, quando ci spiega Perchè leggere i classici.
Ho dovuto comprare la sua raccolta di Fiabe Italiane(cofanetto in 3 volumi, con la scusa che mi sarebbero serviti per i miei bimbi), dopo essermi sbranato Sulla Fiaba.

Ma le Lezioni Americane ve le consiglio in diretta antitesi alla paranoia da cospirazioni globali di Dan Brown.

Parla di valori da salvare nella letteratura del nostro millenio.

Ora, è meglio che non stiate scrivendo un blog, quando vi rileggete questo saggio.
Perchè è facile criticare gli altri, ma come la mettiamo quando cercate di verificare se i vostri post saranno ricordati nelle antologie scolastiche dei prossimi secoli?

Dunque, vediamo...

LEGGEREZZA
E', evidentemente,
sottrazione di peso [...] alla struttura del racconto e al linguaggio.

L'intervento cita pure il software, per farmi capire che l'ha scritto proprio per me
Le macchine ci sono ancora, ma obbediscono a bit senza peso.

Voi che non vi perdete neppure uno dei miei post sapete bene che non ho chances, in questa direzione: mettiamoci Una pietra sopra (altro titolo di altra opera di Calvino: sarà un caso?).

RAPIDITA'

Nello
scarno riassunto [...] tutto è lasciato all'immaginazione e la rapidità della successione dei fatti dà un senso di ineluttabilità.

Fortunatamente per me aggiunge:
non voglio dire che la rapidità sia un valore in sè: il tempo narrativo può essere anche ritardante o cuclico o immobile.

Poi, però, rincara la dose:
Un ragionamento veloce non è necessariamente migliore d'un ragionamento ponderato; tutt'altro, ma comunica qualcosa di speciale che sta proprio nella sua sveltezza.

Ma mi salva ancora:
La rapidità dello stile e del pensiero vuol dire soprattutto agilità, mobilità, disinvoltura: tutte qualità che si accordano con una scrittura pronta alla divagazione

e mi fermerei qui, fintanto che pareggio, su questo punto (sapendo di forzare un tantino l'interpretazione...).
Comunque, non poteva sapere, nel 1985, che avremmo sentito l'urgente bisogno di promuovere la prima giornata mondiale della lentezza, lo scorso 19 febbraio.

ESATTEZZA
State certamente pensando che su questo punto me la caverò, perchè sono un preciso (mi pare di aver sentito qualcuno di voi dire 'rompiballe', mentre scrivevo 'preciso', ma mi sono certo sbagliato).
Temo di dovervi deludere, perchè si tratta di:
1. disegno dell'opera ben definito e calcolato

E fin qui: questi post, in realtà, sono più studiati di quanto possa sembrare
2. l'evocazione di immagini visuali nitide, incisive, memorabili

Temo non valga considerare le foto e i filmati allegati, purtroppo (che, tra l'altro, non sono neppure miei)
3. un linguaggio il più preciso possibile come lessico e come resa delle sfumature del pensiero e dell'immaginazione
Dovrei evitare varianti dagli argomenti tecnici, voi che ne pensate?

VISIBILITA'
facoltà umana fondamentale: il potere di mettere a fuoco visioni a occhi chiusi, di far scaturire colori e forme dall'alineamento di caratteri alfabetici neri su una pagina bianca, di pensare per immagini.
Beh, qui dovete dirmelo voi: senza considerare i jpg che illustrano i miei post, la loro lettura vi ispira immagini? "Vedete solo rosso, con gli occhi iniettati di sangue"? ... ahem ...

MOLTEPLICITA'
romanzo contemporaneo come enciclopedia, come metodo di conoscenza, e soprattutto come rete di connessione tra i fatti, tra le persone, tra le cose del mondo

Beh, senza paragonarmi a Gadda, direi che, non per merito mio, ma per come è fatta Internet, grazie alla Wikipedia ed allo stesso concetto di blog, ci siamo (cosa stava leggendo Tim Berners-Lee, al CERN, tra il 1991 ed il 1992?).
O no?
Certo che se mi commentaste qualche post, la connessione tra le persone sarebbe pure meglio.

Riassumendo: dopo questa analisi mi sono autoconvinto che sia giusto continuare a scrivere questo blog, almeno finchè non riuscirete a far smettere di scrivere i suoi libri a Dan Brown (tanto, se io ottengo un 2/5 risicato, nel confronto con le Lezioni, se lui supera l'1/5 inoltro protesta formale).

Bye

    Depa

P.S.: le mie scuse a Calvino, per aver mal citato il suo straordinario lavoro, per averlo interpretato secondo le mie esigenze e per aver qui selezionato solo pochi dei titoli di cui ho veramente molto goduto

[... continua ...] Leggi tutto