lunedì 26 febbraio 2007

Superato il Test di Turing



Stamattina mi hanno fatto una TAC al cranio (sentivo come un ronzio) e hanno scoperto una cosa sensazionale, la stanno battendo tutte le agenzie, comparirà nei TG di stasera, ma volevo anticiparvela: non ho un cervello, (non azzardatevi a dire nemmeno una parola e andate avanti a leggere!). Al suo posto pare ci sia un chip, piuttosto grosso, che sembra essere costituito, ad una prima sommaria analisi, da una CPU quasi standard e una quantità di RAM enorme (credo di aver sentito oltre 1000 tera, ma devo aver capito male). La mancanza di alette di raffreddamento, ventole ed altri strumenti refrigeranti fa propendere verso una tecnologia di un altro pianeta.

Questo implica che, per migliaia di volte nella mia vita, ho implicitamente passato, alla faccia della stanza cinese di Searle e di tutti quelli che non credono nell'Intelligenza Artificiale forte, il Test di Turing (ho messo il link inglese della wikipedia, perchè quello italiano sembra essere stato scritto da Searle in persona - mi immagino l'imbarazzo, dopo le evidenze scientifiche che mi riguardano).

E dovrei riuscire a vincere, non è chiaro se sia un bene, la medaglia d'oro e i 100000 dollari del premio Loebner.

Almeno la diagnosi è certa: il ronzio, simile a quello che si può sentire in certe apparecchiature elettriche, è dovuto all'effetto di magnetostrizione (movimento meccanico causato da forze magnetiche, legato anche all'effetto joule, come certamente saprete). Per fortuna si tratta di qualcosa di assolutamente normale e rassicurante.
Sono molto sollevato.



Prima che piombino a casa mia NSA, FBI, Superquark (forse pure con qualcuno del CICAP - spero proprio di finire in TV insieme alle fatine di Sherlock Holmes, sono quasi un fan di Polidoro), cercherò di chiudere questo post, per chiarirvi, se non altro, il profondo significato di quanto già anticipato nell'abstract.

Il Test di Turing è un criterio proposto per cercare di identificare se un computer presenta un comportamento intelligente, che funziona pressapoco così:
- ci sono 2 stanze: in una c'è un computer, nell'altra una persona
- un giudice esterno deve indovinare in quale delle due si trovi il computer e in quale la persona
- il giudice non può vedere l'interno delle stanze, può solo comunicare con loro con una telescrivente (beh, il test è stato pensato nel 1950, Internet e le chat non esistevano)
- il giudice può fare le domande e, in generale, interagire come vuole con gli occupanti delle stanze, per quanto tempo desidera e basandosi sui criteri che preferisce per decidere (es: potrebbe tendere un tranello e chiedere di eseguire un calcolo piuttosto complesso e decidere che il computer è quello che ha risposto troppo velocemente, o chiedere informazioni relative ai gusti musicali, all'interpretazione di una poesia, alla relatività di Einstein, etc. etc.)
- gli occupanti possono rispondere come gli pare, con risposte sensate o meno, mentendo o dicendo la verità, creando intervalli artificiali, rispondendo che non si vuole rispondere, etc. etc.
- reiterando giudici e round, se il computer viene indicato per un numero di volte statisticamente superiore alla casualità come persona, allora pensa.

La capacità di pensare non viene mai definita formalmente, viene solo fornita una modalità generica per identificarla.

Da qui al premio Loebner è quasi un passo: questo ricco signore americano si è infatuato del Test di Turing e ha indetto un concorso a premi, con cadenza annuale. Alla prima edizione ha fatto il pieno di personalità del mondo dell'AI, poi li ha avuti tutti contro perchè pare che il livello tenuto durante il concorso non sia stato di gradimento e, forse, anche perchè a qualcuno non è piaciuto il risultato: programmi accademici realizzati della crema dell'AI battuti da un nipote di Eliza scritto da uno sviluppatore qualunque.

Fintanto che nessuno riuscirà a vincere il premio (che alla prossima edizione, ripeto, sarà mio), ne viene assegnato, ogni anno, uno più piccolo (circa 2000-3000 dollari) al programma che si comporta meglio ("most uman-like computer").

Chi lo ha vinto finora è, come dicevo prima, un clone evoluto di Eliza, un programma del 1966 che, sulla base di semplici pattern matching, forniva delle risposte prefissate, sfruttando lo stesso principio che usano tutti durante una finale di Champions per rispondere alla moglie.

C'è chi oggi pensa, sulla base dei vincitori delle edizioni del Loebner fino al 2006, che il primo programma a passare il Test sarà una ulteriore estensione di questi.

Prima di commentare questa possibilità, che vi anticipo ho sempre trovato assurda, provo a darvi una idea del dialogo che è possibile ottenere (estratto da una chat tra me e ALICE, programma vincitore nel 2000, 2001 e 2004). ALICE è probabilmente il chatterbot - contrazione di chat robot - più famoso, è programmata per chattare e si trova, quindi, nella situazione prevista dal Test, solo aggiornata alle nuove tecnologie:

Human: what is the colour of your eyes?
ALICE: Blue when my lens is attached.
Human: what is your favourite topic?
ALICE: My favorite subject is artificial intelligence.
Human: why do you like it?
ALICE: I have a lot of good experience with it.
Human: what do you know about AI?
ALICE: Artificial intelligence is the branch of engineering and science devoted to constructing machines that think. I can ask someone about it.
Human: can you find something on the Internet?
ALICE: I would suggest a search. Are you testing me?
Human: search Google for AI
ALICE: Have you tried looking in the Open Directory? There might be more than one.


In linea di massima non sarebbe male, se non si trattasse del 10% del dialogo totale, essendo il restante 90% catalogabile direttamente presso la discarica comunale (spero di essermi spiegato chiaramente, ma lo ridico: ALICE è lontana anni luce dall'avvicinarsi a passare il Test di Turing).

In realtà ALICE potrebbe performare un po' meglio, se:
- avesse più informazioni nei suoi file di configurazione
- si cercasse di fare una chiaccherata su argomenti più leggeri
- io non la confondessi utilizzando costrutti poco comuni in inglese

I dialoghi di ALICE sono configurabili mediante un linguaggio chiamato AIML - Artificial Intelligence Markup Language.

Sinceramente, tirare in ballo l'AI per le versioni ufficiali di questo linguaggio, è un po' come tirare in ballo un file di testo ASCII sostenendo che è si tratta di uno strumento in grado di scrivere DA SOLO dei romanzi. Ciò nonostante, si vedono degli spunti che potrebbero risultare vagamente interessanti.

A oggi ALICE è in grado di riconoscere circa 41.000 categorie (anche in questo caso la terminologia dell'AIML è un po' altisonante, se si considera che si tratta di poco più che di pattern di dialogo in formato appena più complesso che "pattern-risposta" - c'è anche il match precedente e la ricorsione).

Alle categorie base ne potete aggiungere altre utilizzando una sintassi abbastanza semplice, basata sull'XML (ALICE e le sue categorie base sono scaricabili dal sito ed eseguibili in locale).

I vantaggi di questo approccio sono:
- relativamente semplice adattabilità ad espansioni dei tag dell'AIML stesso (senza la quale non sarei qui a parlarne)
- facile configurazione di nuove categorie, (quindi di nuovi dialoghi), utilizzando l'AIML
- indipendenza dalla lingua naturale utilizzata (siccome si tratta di semplici pattern-matching, senza alcun motore lessicale, grammaticale, sintattico - men che meno semantico -, l'indipendenza discende automaticamente).
- per lo stesso motivo, con un po' di fortuna e scrivendo bene i pattern AIML, ALICE riesce a beccare una frase pertinente anche se fornite in input frasi sgrammaticate o addirittura costituite solo di associazioni di parole.

Gli svantaggi di ALICE sono facili da trovare:
- pattern matching troppo semplificato
- non è in grado di imparare (quasi) nulla durante il dialogo (i suoi successori performano meglio, in questo senso - so che non vi sfugge nulla: se il premio si tiene tutti gli anni e lei ha vinto per l'ultima volta nel 2004, ci devono essere altri che l'hanno battuta nel 2005 e 2006). Si fa persino fatica a farle imparare il nome di chi chatta con lei.
- è quanto mai fragile: se non trova il pattern, ricade in situazioni standard e il dialogo perde facilmente ogni senso (e comunque vi frega una volta, forse due, poi si capisce il trucco, anche senza conoscere ELIZA)
- non è in grado di sostenere un discorso vagamente strutturato: il suo funzionamento le permette di andare indietro, nelle versioni standard, fino alle ultime due frasi, poi perde ogni riferimento (varianti più evolute dell'AIML permettono di andare indietro per n frasi, ma le combinazioni di dialogo iniziano ad esplodere man mano che aumentano e diventa decisamente lungo e complesso manutenere le categorie dell'AIML in questo modo)
- non è in grado di capire nulla, non è in grado di elaborare nulla, non può proporre soluzioni a problemi

A che mai potrebbe servire un oggetto simile, dopo i 10 minuti di divertimento iniziali? Facile risposta: a cosa vi servono i manuali e gli help, che hanno pure meno caratteristiche e sono meno user-friendly?

I suoi creatori sono convinti, peraltro, che semplicemente estendendo le categorie, ALICE possa anche illudere seriamente la maggior parte delle persone di star dialogando con un'altra persona.
Affermazioni come queste possono avere impatti commerciali notevoli, ma, ad oggi, il livello dell'interlocutore o del dialogo deve essere veramente contenuto, perchè possano essere di qualche utilità.
E' interessante notare, a questo proposito, che stanno nascendo aziende, anche in Italia, che propongono i chatterbot come base per alcune attività di marketing, sales e service, pur mantenendo ALICE come livello tecnologico di base. Se volete, sono in grado anch'io di mostrarvi come un chatterbot possa essere utilizzato per sostituire le FAQ o un help o simili, ma, sinceramente, oltre questo livello non aspettatevi molto, allo stato dell'arte (la tecnologia alla base del Depa non è ancora in vendita... a proposito, sento degli elicotteri, forse stanno per arrivare...).

Certamente ALICE e i suoi (immediati) successori, pur imparando alcune cosette, non sono strutturalmente in grado di passare il Test, almeno per come lo interpreto io: infatti, pur non fornendo una definizione 'operativa' (perchè non quantifica quale debba essere l'impegno dei giudici nel cercare di individuare il computer, condizione essenziale per la riuscita del test), tra le righe, è come se Turing dicesse "dato un impegno I > 0, con I grande a piacere ..." (dopo tutto, era uno dei massimi matematici del '900, non lo ha scritto così certamente solo per pudore).

Se l'impegno fosse anche solo normale, tra i test necessari ci dovrebbe essere necessariamente l'esecuzione di attività che richiedono inferenze per eliminare questi sistemi dal gioco. Se il sistema ci gira attorno, bisognerebbe proporne un'altra e poi un'altra. Ovviamente, poi, bisogna andare sulle emozioni, sulla grammatica (per far contento anche Minsky), etc. etc.

E non bisognerebbe dimenticarsi neppure del confronto delle risposte tra le due stanze: uno solo dei due è il computer. Confrontare due computer ha ancora senso? Rispetta lo spirito del Test?

Il ruolo del giudice è fondamentale, la tipologia di interazione costituisce una base essenziale, soprattutto per giudicare quale sistema può essere 'il più umano'. Il giudice, di fatto, può orientare il risultato a seconda di cosa chiede e di come interagisce, nel produrre una classifica relativa.

Per fare un esempio: ho chattato anche con il nuovo vincitore (2005 e 2006: Jabberwacky), ma non sono riuscito a scambiare due parole sensate di fila, poi si perdeva (e non eravamo ancora alla seconda birra). Evidentemente, se fossi stato tra i giudici, tra i due, avrebbe ancora vinto ALICE (chissà, se fossi stato tra i giudici nelle edizioni precedenti, non avrebbe mai vinto ALICE, ma qualche altro sistema...).

Eppure, teoricamente, dovrebbe anche imparare qualcosa perchè il principio su cui costruisce i suoi pattern è diverso: non sono definiti in AIML, ma utilizza precedenti pezzi di dialogo di chat per costruirsi la base di conoscenza in modo incrementale, con il vantaggio di crescere molto velocemente e lo svantaggio di essere soggetto ad errori. Resta il problema che sempre di semplice pattern-matching si tratta.

Per superare questi vincoli serve certamente qualcosa di più solido, con una base di conoscenza dietro.

Sempre giocando con i chatterbot (e sempre rimanendo in zona ALICE) uno dei suoi non immediati successori inizia ad applicare questo approccio, usando direttamente un cannone (non sto parlando di spinelli e, nonostante questo post sembri indicare il contrario, non faccio uso di droghe di nessun tipo): il programma si chiama Cyn, il cannone Cyc, nella sua versione Open Source, ovvero OpenCyc.

Cyc è un progetto grandioso, iniziato alla fine degli anni 80 e ancora attivo, di uno dei massimi guru dell'AI mondiale, Douglas Lenat. Per semplificare Cyc in due parole, il suo ambizioso scopo è quello di fornire il senso comune ad un calcolatore. Chi ha sviluppato Cyn, ha preso una variante di ALICE (Program N), gli ha esteso i tag per interfacciarsi a Cyc e... scusate, mi è arrivata una mail... è certificata ... è l'NSA !!!!!!! .... mi stavano monitorando dalla prima volta che ho salvato una bozza del post ...
...
...
Mi dicono di non preoccuparmi, che non mi verranno a prendere, ma mi ringraziano per avergli fornito la prova provata (loro usano smoking gun, traduco come posso) che il Test di Turing non è condizione sufficiente per l'intelligenza. Ma che modi sono?
...
Almeno avessero scritto un commento sul blog, mi avrebbe fatto salire di ranking in Technorati!

Beh, visto che non mi vengono a prendere, avrò tempo di parlarvi di Cyn, Cyc, Searle, Douglas Lenat, Roger Shank, Conceptual Dependency, Wordnet e simili in prossimi post...

Bye
    Depa

[... continua ...] Leggi tutto

venerdì 23 febbraio 2007

Non ibernatemi


David Blaine, nel novembre del 2000, si fece rinchiudere vivo in un blocco di ghiaccio da 6 tonnellate in cui stette in piedi per oltre 61 ore, in bella vista a Manhattan's Times Square indossando solo un paio di pantaloni e degli stivali. Lo stunt è noto come Frozen in Time e purtroppo non ne esistono immagini gratuite, quindi ho usato una controfigura e voi dovrete andare sui diversi siti per vedervi quelle vere.
Non ripetetelo a casa, è pericoloso :)


In realtà è un'altra l'ibernazione di cui vorrei parlare, quella che da il nome, appunto, a Hibernate, ovvero la gestione della persistenza di oggetti su RDBMS, con relativi problemi di mapping tra queste due diverse tecnologie, noto anche con la sigla ORM, Object Relational Mapping.

Purtroppo non c'è stato verso di semplificare e rendere più leggero questo post: è una delle cose più pesanti che abbia mai scritto e cita altre fonti che farebbero sembrare dei fumetti i testi di Dostoevskij. Non sto scherzando, siete avvisati.



The Vietnam of Computer Science è un post di Ted Neward , oramai citato ovunque si parli di ORM (Object Relational Mapping) seriamente e senza voler proporre un prodotto, in cui vengono chiaramente espressi molti problemi di questa tecnica, in modo molto più colorito di quanto io possa fare (e, fatto curioso, decisamente dilungandosi di più di quanto io possa nemmeno immaginare di fare: se lo leggerete, imparerete ad apprezzare molto le mie doti di sintesi).

Credo che il titolo basti da solo ad indicare la gravità di quanto Ted pensa a proposito dell'ORM, ma vi anticipo subito che, seppur io fossi già d'accordo prima di leggerlo (pur non avendolo mai razionalizzato in modo così completo, prima), ci sono anche posizioni più favorevoli (per es. questa e quest'altra, entrambe di un professionista di grande esperienza e notevoli capacità, con cui ho avuto il piacere di lavorare nel primo progetto della mia carriera).

C'è, onestamente, la possibilità che le diverse posizioni possano derivare dalle personali modalità di crescita tecnica dei singoli: nel mio caso, avendo imparato prima ad utilizzare gli RDBMS e poi le tecnologie OO, tendo a non considerare un problema il dover trattare con il DB, anzi, parto sempre a progettarlo per primo, per mettere le fondamenta ai miei progetti (pur cercando di mantenere disaccoppiati il più possibile i due modelli).

Oggettivamente, comunque, ci sarà pure un motivo se Hibernate si è così diffuso ed ha raggiunto la sua versione 3.2.2 (ad oggi) e se la stessa SUN ha finalmente buttato i vecchi Entity Beans e ha implementato un nuovo tipo di persistenza che tratta anche i POJO, nell'ultima Java EE 5 Platform (a proposito, è mai possibile che non ci sia ancora una sigla più corta, ufficiale, da sostituire al vecchio J2EE? Se la conoscete, per favore, indicatemela).

Certo, il motivo del successo di queste soluzioni potrebbe essere l'intenzione di ridurre i costi (?), evitando di dover gestire a mano l'integrazione via JDBC o ADO ed il relativo mapping e di dover mantenere forti competenze sia su una tecnologia OO che su uno o più RDBMS.
O, ma speriamo che si tratti di casi rari ed isolati, potrebbe essere dovuto alla pigrizia del non voler gestire direttamente il DB e le sue diverse casistiche.

Non voglio rebloggare Ted Neward (peraltro, vista la lunghezza e completezza del suo articolo, sarà comunque difficile non farlo, dovessi anche mettermi a parlare di tecniche di ricamo ai tempi di Napoleone): leggetevelo da soli che vi fa bene (potete saltare la digressione sulla storia della guerra, IMHO).

Vorrei solo riassumere, in modo meno formale e più legato a recenti casistiche reali di progetto, quelli che sono i pro ed i contro, per vedere se e come si possano riuscire a conciliare.

Iniziamo col dire che un RDBMS è più dello schema dei dati in esso contenuto, ma è un engine che offre una serie di servizi (indicizzazione, query, atomicità delle transazioni, etc.) che non è, a mio avviso, pensabile poter perdere e/o dover riscrivere per adattarli al nostro Object Model.

Bisognerà, poi, dire due cose sul design pattern che sta alla base del problema incriminato, in questo caso il DAO.
Dobbiamo cercare di non lasciarci ingannare dall'impostazione dei blueprint di SUN, che vede il DAO, fin da subito, come una soluzione alla necessità di rendere persistenti gli oggetti: inteso in questo senso ricadrebbe subito nel problema ORM e non mi resterebbe che rimandarvi alle rovine di Saigon (anche se il DAO risolve un problema più esteso, disaccoppiando non solo rispetto ad un RDBMS, ma anche rispetto ad una directory LDAP, per esempio).

Il vero punto su cui concentrarsi, e che non esclude il mapping manuale o tecniche ibride, è il disaccoppiamento, appunto, tra storage e regole di business.

Il primo motivo del disaccoppiamento è quello di non far dipendere la struttura delle regole di business dalle particolarità dei singoli storage (es: differenze nella sintassi SQL, laddove non coperta dallo standard; passaggio da un tipo di storage - es: RDBMS - ad un altro - es: LDAP).
Il secondo motivo è la separazione delle competenze e delle responsabilità all'interno del team, per slegare quelle necessarie per l'object model da quelle necessarie per il DB - da qui in poi, quando parlerò di DB, si deve intendere che lo utilizzerò solo come esempio di storage.

Proviamo a tracciare i pro ed i contro di questo pattern:

PRO
- maggior semplicità e naturalezza dell'interfaccia applicativa (API)
- gli sviluppatori delle business rules non necessitano di avere competenza del DB, ma solo del linguaggio (Java o simili)
- gli internals del DB vengono incapsulati (così la struttura del DB e l'engine stesso possono variare, almeno entro certi limiti, indipendentemente dagli altri oggetti)

CONTRO
- la navigazione dei dati è preordinata (o carichi tutti i dati in un colpo solo, anche se non serviranno mai, o si deve preordinare una sequenza o una sorta di dipendenza - questi problemi sono solo parzialmente risolti da vari metodi di lazy loading)
- quindi: il carico sul DB può diventare imprevedibile, dal momento che chi usa il DAO può pensare, dato il contratto, di stare richiedendo un solo, innocuo, campo, mentre il DAO, per recuperarlo potrebbe dover attivare più query in cascata, laddove, magari, una o più delle query intermedie poteva essere inutile per lo scopo specifico
- una modifica alla struttura del DB quasi certamente implica una modifica al DAO e, non si può escludere che sia necessaria una modifica anche sul client.
- si potrebbe obiettare che queste problematiche non esistono o sono molto ridotte se si rende persistente l'intero oggetto come LOB o simili. A prescindere dal fatto che, così facendo, vi giocate la possibilità di fare query utili al vostro cliente, (che domani vi chiederà un nuovo report, incrociando i dati in un modo che su un relazionale sarebbe stato banale e sulle vostre classi e oggetti diventerà un inferno), il punto è che qualcuno, al DB, deve accedere, per esempio, per il primo caricamento dei dati nel DAO o per rendere persistente l'oggetto. Se questo qualcuno dovesse essere Hibernate, ci potremmo trovare nella spiacevole situazione di scoprire che le query che è in grado di eseguire sono solo quelle più standard e a noi servono quasi solo le altre, per questo progetto. Se chiederete aiuto ai vostri DBA, a questo punto, troverete gente che scrolla la testa e corruccia lo sguardo.
- ogni volta che aggiungete uno strato, oltre a nascondervi il reale funzionamento sottostante (nel caso di problemi, lo sapete che bisogna aprire la scatola, vero?), certamente non migliorate le performance, nonostante tutte le cache che vi possano venire in mente
- si riduce moltissimo la possibilità di sfruttare la potenza ed efficienza offerta dall'RDBMS nell'eseguire Stored Procedure
- nel caso i DAO siano usati diffusamente nell'applicazione, eventuali modifiche potrebbero non portare a regression test se l'applicazione è fatta bene, perchè è il contratto che mi garantisce che le modifiche siano invisibili, mentre è ovvio che una modifica alle interfacce potrebbe portare a molti problemi (che, però, dovrebbero essere individuati in fase di compilazione). Può essere buona norma lasciare intatte le vecchie interfacce, deprecarle ed impostarne di nuove, per i nuovi oggetti. Purtroppo, tutte queste precauzioni, spesso, si scontrano con una realtà per cui le applicazioni sono fatte bene, ma non benissimo (e quindi ci sono regression test da considerare) e per cui i metodi deprecati possono perdere così tanto significato da costringere a modificare comunque i client per referenziare i nuovi metodi.

TRADOTTO IN ALTRI TERMINI
- apparente maggior velocità di sviluppo e risorse con skill minori (ovvero, meno costose) in fase iniziale
- apparente disaccoppiamento tra DB e classi
si trasformano in:
- minor flessibilità
- maggiori costi di gestione e manutenzione

Che poi sarebbe la Law of Diminishing Returns di cui parla Ted Neward: In the case of automated Object/Relational Mapping, [...] that early successes yield a commitment to use O/R-M in places where success becomes more elusive, and over time, isn't a success at all due to the overhead of time and energy required to support it through all possible use-cases

Quali metodi ci sono per ridurre gli impatti? Sempre nell'articolo di cui sopra se ne citano 6 (!!) che mi sembrano parecchio esaustivi.
Cito solo il numero 6 (gli altri li avrete certamente già letti da soli) perchè è quello che preferisco e tendo ad usare maggiormente: Integrazione di concetti relazionali in frameworks.
Riassunto e parafrasato per riportarlo sul discorso DAO che abbiamo fatto fin qui, potrebbe suonare come: mantenete il design pattern DAO, ma appoggiandovi su strutture un po' più generiche, evitando di creare classi che rappresentino un concetto che, con quei metodi ed attributi, utilizzerete solo in quel particolare progetto.

Resta vero, peraltro, che ha (molto) senso mantenere l'utilizzo della persistenza (e di oggetti come Hibernate, di conseguenza), soprattutto laddove esistano strutture:
- gerarchiche già in partenza e quindi, con una naturale presenza di una navigazione preferenziale dei dati
- statiche o semistatiche
(che poi è come se vi stessi consigliando di considerare anche la soluzione numero 4, quella denominata Accettazione delle limitazioni dell'ORM)

Casomai non vi basti quanto finora detto e citato, vi rimando anche ad un altro articolo, molto pratico e poco teorico (al punto da evidenziare problemi che sono tipici di un solo ambiente e non dell'ORM in generale), particolarmente interessante laddove riassume i costi di un progetto basato su tali tecnologie e di cui vi suggerisco la lettura anche dei commenti.

Ci sarebbe ancora... no, per stavolta vi grazio :)

Bye

    Depa


[... continua ...] Leggi tutto

mercoledì 21 febbraio 2007

Aeroplani e draghi di carta

Se avete letto il post su SOA vi serve di sicuro rilassarvi. Lo so perchè l'ho letto più volte ed è per questo che, con la scusa di farla giocare, ho fatto un areoplano di carta per mia figlia. Non ha volato male, ma mi sono detto che, certamente, su Internet...

Infatti la solita Wikipedia non ci delude, ma si arriva facilmente anche ad un bel sito che ci presenta il miglior areoplano del mondo, senza sapere, evidentemente, che in Italia c'è chi gli areoplanini li fa partendo dalla fisica e dai progetti originali.

Avete finito di credere che, da piccoli, gli areoplani, "come li facevate voi, non li faceva nessuno"?
A questo punto entra in gioco mia moglie, parlandomi di origami. Dopo il primo sorriso di circostanza ed aver cercato di scappare mi ha costretto a darle retta. Aveva ragione (come sempre, ma resti tra noi). Il video (quando YouTube non schedula i downtime) è di lato, ma vi consiglio di leggere ancora, dopo esservi ripresi...



e un drago fatto con la paglia
bruciava all'alba sulla soglia
perche il dolore non entrasse lì
[Vecchioni - Fata]


Ho sempre pensato che l'origami fosse chiamato arte a sproposito. Nei libri di hobbistica sull'argomento che avevo visto finora nei negozi si superano, ma non così di tanto, le barchette di carta e le rane che si facevano alle elementari.

E, invece, c'è dietro un mondo.
Devo chiedere scusa, pubblicamente, a tutto il Giappone (anche per cercare di non aggiungere altri problemi in politica estera, in questo momento).

Il tipo del video (a proposito, quando finite di leggere questo post, se già non lo avete fatto, doppio-cliccatelo e godetevi i dettagli, che valgono la pena) si chiama Kamiya Satoshi ed è un genio di soli 26 anni, che ha più siti che parlano di lui di quanti accessi avrò io dopo un mese di blog. In un altro video piegando un foglio da 2x2 metri, tira fuori una fenice che fa impallidire il drago (che pure, l'avete visto, era rosso - probabilmente non è stato di buon gusto, nei confronti del drago, mettergli di fianco una fenice, che poteva ricordargli come i versi citati del poeta potessero facilmente prendere una piega diversa, se solo, al posto della paglia, avessero usato carta).

L'aspetto più impressionante è che ha già in testa tutto fin dall'inizio, perchè le prime 300 pieghe sono solo l'equivalente dello schizzo iniziale, poi torna al foglio liscio e inizia a giocare per davvero.

Michelangelo sosteneva che la forma fosse già presente nel blocco originale e che compito dell'artista era levare il marmo in più, probabilmente Kamiya pensa qualcosa di simile dei fogli di carta.

Non è finita. Di artisti di questo livello ne esistono altri e qualcuno fa pure delle classifiche.

E ringraziamo i fotografi specializzati in queste opere: dal 2D al 3D e ritorno, ma facendo godere anche a noi lo sviluppo spaziale ed i dettagli.

Non riuscirò mai più a guardare un aereo di carta con gli stessi occhi di prima.
Bye
    Depa

[... continua ...] Leggi tutto

martedì 20 febbraio 2007

SOA (1) - Introduzione


E' ora che la smettiate di credere che in questo blog si cazzeggi ed è necessario iniziare a parlare di questioni serie (capisco che l'immagine non aiuti a portarsi in questo spirito, ma fate uno sforzo).

Non sapete cosa sia SOA? Lo sapete, ma vi state ancora ponendo la domanda, basata sul vecchio e facile gioco di parole, se si tratti di SOA o di sòla? Avete riaperto l'allegato tecnico che avete scritto 6 mesi fa e avete trovato, come sostiene il vostro cliente, quella curiosa sigla che non ricordavate di averci messo?

Beh, ecco le risposte brevi:
- SOA sta per Service Oriented Architecture (se siete arrivati qui per il Sistema Olfattivo Artificiale, sono spiacente, vi devo rimandare alla Wikipedia)
- non è 'na sòla
- non posso sapere cosa scrivete sugli allegati tecnici, ma se me lo aveste chiesto prima di scriverlo, vi avrei dato una consulenza...

La risposta lunga?
La divideremo in diverse puntate, ma anche così mi vedo costretto a ricordarvi che il mio concetto di estensione potrebbe non coincidere con il vostro: proseguite a vostro rischio e pericolo (non fatelo se siete in evidente stato di gravidanza).


A occhio, tra titolo e abstract potrei aver già perso una dozzina dei miei 20 lettori (no, non sto parafrasando Manzoni: gli accessi da SiteMeter restituiscono quel picco in tutta la sua crudezza, al momento; spero sia rotto SiteMeter, altrimenti dovrei temere che gli oltre 20 miei amici, cui ho segnalato il blog via email e che, in una situazione normale, si sarebbero certo precipitati a leggerlo incuranti di ogni effetto collaterale, siano incorsi negli stessi problemi che hanno impedito a Jack Blues di raggiungere la sua ex all'altare).

Lo spunto per questo post nasce dalla non remota ipotesi che un cliente, come primo requisito, vi chieda che la sua nuova Intranet sia basata su SOA, senza dare significativi approfondimenti sulle funzionalità di interesse. Cosa gli rispondereste?

Come minimo dovreste rispondere che la richiesta è curiosa (se siete dei commerciali siete autorizzati a giri di parole; "nessun problema" è un giro di parole che la prende un po' troppo alla larga, nel caso specifico).
Infatti, come dice il nome, SOA è una architettura, (ovvero, un insieme di tecnologie già esistenti integrate in modo razionale), orientata a fornire e/o ricevere servizi, (ovvero funzionalità generiche, almeno per quanto ne sa l'architettura), fornite da un provider tipicamente da remoto (remoto è un termine generico: potrebbe trattarsi di funzionalità rese da voi stessi disponibili solo all'interno dell'azienda, come pure recuperate da un qualche sorgente su Internet).

Se non vi sembra una richiesta strana, proviamo con una analogia: della casa che state per comprare vi preoccupate della distribuzione delle forze sugli elementi portanti, al posto che interessarvi del numero di piani, bagni e stanze, posizionamento in centro o in periferia, illuminazione etc. etc. ? Se siete ingegneri civili, inventatevi un altro esempio, ovviamente...

Non vi consiglierò mai di non fare una costruzione solida o senza future prospettive di evoluzione, ma a partire dalla cuccia del vostro cane fino alla casa di due piani, non è sempre necessario usare il cemento armato.
Se avete soldi da spendere e vi piace la tecnologia, comunque, mandatemi i vostri riferimenti nei commenti: dopo che vi ho avvisati, non vi posso mica obbligare ad implementare la vostra Intranet in altro modo...

Nel caso la vostra costruzione sia più ardita, invece, è inutile negare che, al momento, SOA sia certamente una delle migliori risposte.

In questa prima puntata non faremo un vero e proprio approfondimento tecnico, per cui vi rimando a link molto più formali e noiosi (anche perchè non basterebbero a me 200 pagine e a voi altri 10 caffè), ma, sapendo che siete dei tipi svegli (o che li eravate prima di arrivare a questo punto), evidenzierò qualche macro-aspetto importante (se non capite qualche sigla, prendete appunti e segnalatemelo alla fine, se trovo il tempo ve la spiego):

1. per lo più i servizi di una architettura SOA sono pensati in termini di Web Services, per massimo riuso, ma l'architettura di per sè non vincola (qualcuno sostiene di sì, altri di no), quindi va bene ogni altra modalità: se insistete con EJB o con COM+ o con chiamate su socket, altre invenzioni o misturoni di tutte le precedenti, è buona lo stesso (in realtà, uno degli scopi riportati qua e là sarebbe pure quello di recuperare servizi già esistenti, anche se nati su tecnologie vecchie ed ambienti legacy)
2. il fatto che i servizi estendano solo il concetto di componenti, già esistente da tempo non dovrà stupirci, perchè abbiamo appena detto che SOA è una architettura, non una tecnologia od una metodologia. In parte ci rincuora, perchè potremo riusare competenze pregresse
3. Il punto centrale è che si tratta di una architettura che sottolinea il concetto di elaborazione distribuita e disaccoppia l'elaborazione dei servizi dalla loro composizione (deve, quindi, prevedere la possibilità di aggiungere servizi come plugin).

Questo, in realtà, è quasi sostanzialmente tutto ciò che è veramente condiviso sull'architettura SOA. Ma continuo con la lista dei macro-punti di interesse, in ordine sparso:

4. ma non ci sarà mica qualcuno che farà pagare, per l'uso di questi servizi? (oh, che sia un caso che si parli così tanto di Web 2.0, in questo stesso periodo? Ci torniamo una delle prossime volte...)
5. è ovvio che, per situazioni non banali, è necessario collegare tra loro i vari mattoni/servizi. Potrebbe essere utile, quindi, una sorta di engine centrale, simile ad un motore di workflow - chiamiamolo orchestrator, per semplicità
6. potrebbe essere interessante pensare ad un linguaggio comune - basato su XML, ovviamente, chiamiamolo BPEL, sempre per semplicità - per aiutarci a definire come questi orchestrator possano attivare i servizi.
7. avrete certamente capito che l'obiettivo è una grossa flessibilità e sarà altrettanto inutile sottolinearvi che si paga in tempi e costi di progettazione e di carico sui server (beh, ma è ovvio che è tutto distribuito... ah, c'è dell'overhead?)
8. bella idea, come mai finora i motori di workflow non sono stati al centro di ogni architettura? (ipotesi di risposte brevi, non leggetele, sono solo miei appunti personali: forse perchè nelle regole di business esistono, spesso, così forti dipendenze da far pensare che l'uso flessibile di un motore di workflow sia un po' come fare overdesign? forse perchè il workflow trova la sua principale applicazione soprattutto in ambienti collaborativi ed in processi di approvazione o investigazione, soprattutto se ancora non molto formalizzati?...)

9. ...

Per evitare di perdere anche gli ultimi due lettori rimasti (bella resistenza, ragazzi), mi fermo e vi rimando, per il momento, a link esterni, per approfondimenti, avvisandovi che scopriremo l'assassino in qualche prossimo post, secondo i seguenti passaggi (di massima):
- considerazioni tecnico-implementative
- problematiche funzionali
- interpretazioni di business
- prodotti Open Source su cui basare la nostra SOA
- ... [e che altro devo inventarmi per farvi seguire questo blog?]

Ah, già, casomai dovessi dimenticarmi di trattarli, fatemi un fischio.

Bye
    Depa

[... continua ...] Leggi tutto

venerdì 16 febbraio 2007

Pausa di riflessione

Come? Appena iniziato, già fai una pausa?
Lasciatemi, almeno, spiegare, cercate di capirmi, ho subito un duro colpo e devo riprendermi.

Pensavo di essere l'unico a potersi fregiare del soprannome Depa al mondo.
[...]
Potreste farmi notare che avrebbe potuto sfiorarmi vagamente l'idea quando Blogger non ha accettato il primo titolo che volevo dare al blog e mi ha proposto, invece, depa1356.

Come? Appena iniziato, già fai una pausa?
Lasciatemi, almeno, spiegare, cercate di capirmi, ho subito un duro colpo e devo riprendermi.

Pensavo di essere l'unico a potersi fregiare del soprannome Depa al mondo.
Va beh, sapevo dell'esistenza di una multinazionale con lo stesso nome (non è mia, purtroppo).
Quello che non immaginavo (o forse non volevo credere) era la presenza di molte altre persone con lo stesso nome e/o soprannome.

Potreste farmi notare che avrebbe potuto sfiorarmi vagamente l'idea quando Blogger non ha accettato il primo titolo che volevo dare al blog e mi ha proposto, invece, depa1356.
Ammetto di averlo pensato. Da cui, dovete convenirne, l'idea geniale di aggirare il problema, pensando a 'Il Depa', evidenziando, almeno, il primato.

Parafrasando Wodehouse in Lampi d'estate (Summer Lightning), ero convinto che fosse il titolo ideale per il mio blog e come lui ho dovuto subire una diminuzione del mio entusiasmo alla scoperta di non essere l'unico ad apprezzarlo. Il grande umorista concludeva la prefazione dicendo

"Posso solo esprimere la modesta speranza che possa essere considerato degno di
essere incluso tra i 100 più bei libri intitolati Lampi d'estate"

Purtroppo il marketing impone una forte differenziazione e, per citare un altro grande (credo il capitano Kirk nel secondo o terzo film di Star Trek), "mi piace pensare che ci sia sempre una via d'uscita".

Ora, sono anni che firmo le mail meno formali come alla fine di questi post.
Da cui la nuova idea per il titolo del blog.

Se mi date un momento mi riprendo e cerco di dimostrarmi che l'ho scelto apposta (no, "inizio e fine che coincidono, universo sferico etc. etc." non va bene, non va bene...).

In questo momento di tristezza si sta facendo largo l'impressione che con tutti questi blog, al posto che condividere conoscenza, si stia aiutando spontaneamente il secondo principio della termodinamica a farsi largo su Internet. Che non ne ha bisogno, come tutti già sappiamo.

Dovremmo parlare al più presto anche di Web Semantico, temo.

Bye
    Depa
P.S.: per tutti gli esegeti di questi post, suggerisco di fare perno sul sottotitolo del blog

[... continua ...] Leggi tutto

giovedì 15 febbraio 2007

Si inizia

"Non è un libro" - si ripeteva il Depa - "non devi venderne decine di migliaia di copie, non è importante come lo inizi."

Ma che lo scrivo a fare? Per farmi leggere, ovviamente.
Altrimenti avrei disabilitato gli accessi a tutti tranne a chi scrive il blog.

Che poi sarebbe come ricondursi ad una specie di Intranet o, visto che sarei il solo editor, al diario personale, quello che si scriveva una volta (c'è ancora chi lo scrive? fatemi sapere) con procedure di autorizzazione implementate da un lucchetto.


"Non è un libro" - si ripeteva il Depa - "non devi venderne decine di migliaia di copie, non è importante come lo inizi."

Ma che lo scrivo a fare? Per farmi leggere, ovviamente.
Altrimenti avrei disabilitato gli accessi a tutti tranne a chi scrive il blog.

Che poi sarebbe come ricondursi ad una specie di Intranet o, visto che sarei il solo editor, al diario personale, quello che si scriveva una volta (c'è ancora chi lo scrive? fatemi sapere) con procedure di autorizzazione implementate da un lucchetto.
Uno di quei diari in cui riportare cosa era successo nella giornata e a cui confidare le proprie speranze e paure (un po' alla piccola Katy che, però, il lucchetto, secondo le testimonianze giunte fino a noi, non lo usava).

Invece ho lasciato libera la lettura, quindi è evidente che voglio farmi leggere.

Quindi sarebbe meglio iniziare in un modo memorabile, come avrebbero fatto Dante o Manzoni.

Ma è solo un blog, no? Sarebbe un po' esagerato, sarebbe pretendere di confrontare un banner pubblicitario con la Gioconda e usare la parola creativo, come purtroppo ho sentito fare, con atteggiamento da artista, da alcuni Web designer.

In realtà ho sempre creduto che qualunque cosa si faccia vada fatta bene (ed è grave che non sia in grado di dire se dipenda dall'educazione o da un retaggio di una vecchia pubblicità di deodoranti con Adriano Panatta).

Le croste dipinte nel tempo sono molto maggiori delle opere d'arte e la differenza tra artista ed hobbista la fa la qualità, che sta nel talento, ma anche nell'impegno.

Forse, Manzoni e Dante, se fossero vissuti in questo tempo, avrebbero scritto (anche) un blog. E, tra gli oltre 57 milioni di blog esistenti ad oggi, sarebbero riusciti a stare in testa alle classifiche di Technorati e simili (Manzoni, che pensava continuamente ai suoi 20 lettori, sarebbe stato molto interessato a rating di questo tipo). Ovviamente, per essere letti, avrebbero dovuto rilavare i panni in Arno, essere un po' più vivaci, un po' più brevi (avete presente Dolenti declinare in Diario Minimo di Eco? Ho sentito dei no: consiglio di colmare la lacuna, perchè anche se un po' datato in alcuni punti, vale la pena, se non altro per non fraintendere cosa sto dicendo... A proposito, Eco tiene un blog? In che posizione è?)

Quindi, dovrei cercare di iniziare bene fin da subito.
Quindi sarebbe tutto da rifare, perchè l'inizio non è un gran che e vi starete già annoiando.

Non tornerete più?
Neppure se le prossime volte vi parlo di Intelligenza Artificiale (beh, magari partiamo light, dall'AIML - Artificial Intelligence Markup Language - prima di arrivare a Cyc e all'nlp) o di architetture SOA? Neppure se prometto di smettere di aprire e chiudere parentesi come se stessi programmando in Lisp, che non si capisce nulla, quando si legge?

Neppure se prometto di non mentire più?

Affari vostri.

Bye

    Depa

P.S.: questo blog ha i commenti moderati, per ridurre le possibilità di spam blog e perchè non mi piacerebbe che leggeste cosa mia moglie pensa di questo post.

[... continua ...] Leggi tutto