Bye, Depa

Come Leonardo

2008-04-30T23:47:00.006+02:00

La nostra cultura si va pian piano specializzando e, parallelamente, inizo un po' un po' a rompermi di dover sapere solo una cosa.

Sono d'accordo con voi: sempre una in più di Socrate. Certo, ma non mi basta più, mi annoio, ecco.

Possiamo puntare a tornare (beh, in senso lato...) ad essere come Leonardo?

Da Vinci, intendo, non la targaruga ninja. No, non con la barba lunga e problemi nell'individuare la corretta direzione di scrittura. Con una cultura non più settoriale, ma globale, interdisciplinare, intendo.

Genii e sognatori che spaziano in ogni campo dello scibile umano (giusto per sentirci appena appena meno inferiori: qualcuno ha notizie riguardo a come se la cavasse con la musica? era da hit parade anche lì o non era neppure in grado di strimpellare neppure una canzone del Festival di Sanremo? un motivetto con l'armonica a bocca?).
Sono impazzito?

Me lo stavo giusto chiedendo l'altro giorno. Ad alta voce, in autobus.

Con tutti che mi guardavano in modo strano. Molto gentili, peraltro: quando siamo arrivati alla fermata si sono fatti da parte con sollecitudine e mi hanno fatto passare molto più in fretta del solito.

Giusto per non farmi alterare, potreste cercare di essere gentili anche voi e di continuare a leggere...

Ok. Stiamo per essere sommersi.

Da una parte dalla spazzatura reale, dall'altra da quella virtuale (per tacer del periodico circo politico appena concluso; se non fosse fuori tema, sarebbe pure da ricordare che qualcuno rischia pure di essere sommerso dall'acqua, causa scioglimento dei ghiacci - oppure da mio figlio, che proprio l'altro giorno si è svegliato, ha aperto l'acqua del bidè, non tralasciando di chiudere accuratamente il tappo, per poi, senza alcuna menzione all'esperimento in atto, venire a farci sapere che si era svegliato, che voleva far merenda e giocare per una mezz'oretta buona; e non c'è nulla da ridere; per tutti i casi citati).

Ogni giorno centinaia di milioni (in rapido aumento) di persone con dei problemi simili ai miei si mettono a scrivere di fatti loro o degli altri o di amenità del tipo più banale o curioso, riempiendo Internet di informazioni, talvolta pure utili.

I social network ci stanno spingendo a dialogare, a raccontarci, a fotografarci, a raccontare le nostre preferenze. Da una parte ci siamo costretti a firmare due volte in calce ad informative che non possiamo evitare di sottoscrivere, dall'altra facciamo fatica a trattenerci dal mettere su un sito per sbandierere le nostre preferenze sessuali, religiose e raccontare delle malattie che ci assillano.

Le enciclopedie e i dizionari si stanno collegando gli uni agli altri e qualcuno si lancia pure in traduzioni automagiche, che faranno pure ridere, ma permettono di raggiungere altre informazioni (dal russo e dal cinese, per esempio, non traducono peggio di quanto potrei fare io: ho già risolto almeno due-tre problemi capitati solo a me e a qualche abitante della Siberia, in questo modo).

Influencer di tutto il mondo, testate giornalistiche e servizi RSS ci tengono ad aiutarci a completare il rumore, cercando ognuno di attirare la nostra attenzione.

Abbiamo alcune scelte (certamente ce ne saranno altre, ma per ora accontentatevi, perchè su questo spazio decido io come perdere il tempo):

soccombere, mandare tutto al diavolo e ritirarci in un bosco a scambiar ghiande con gli scoiattoli
ritirarci in mediatazione (religiosa o meno, fate voi)
annullare la nostra intelligenza nei telefilm, nel calcio, nel sesso, nella musica, nelle scommesse, nei reality (o in quel caspita che più vi piace per farvi del male)
decidere per un solo interesse, affogarci dentro, cercare di seguire almeno quello (ma questa scelta sta diventando sempre più difficile e potremmo presto scoprire che il nostro solo interesse non era abbastanza settoriale, non abbastanza limitato per riuscire a dominarlo)
provare ad unirci, magari anche in qualche social network, per cercare di mettere ordine tutti assieme (è un'ottima soluzione, se manteniamo una finestra temporale di 1-3 mesi)
provare a reagire, a considerare che il mondo là fuori è sempre stato solo una memoria di massa di backup della nostra mente e che tale deve rimanere anche ora che la capacità di indirizzamento è aumentata

Smettetela di tirarvi gomitate, di scambiarvi occhiate d'intesa e di picchiettarvi le tempie con l'indice, vi vedo.

Provo a ridire con altre parole l'ultimo punto.

Quante cose ricordate, senza usare i sensi?

Provate a ricordare un compagno (compagna, se pensate che vi ispiri maggiormente) di classe che non vedete da anni. Nei dettagli della curvatura del naso, della larghezza delle labbra, del colore e lunghezza dei capelli. Ce la fate?

Com'era l'incipit di Sogno di una notte di mezza estate e come si chiamavano i personaggi?

Canticchiate tutto Eskimo di Guccini.

La prova del nove e la radice quadrata, CON PENNA E FOGLIO, come caspita si facevano?

E' più ruvido il tessuto delle poltrone dei treni o la lama di una lima?

Nella testa avete un sacco di informazioni, molte delle quali si riducono a relazioni verso oggetti sfumati.

Un sacco di relazioni. Link. Che necessitano di refresh continui. Più li esperite, meglio li ricordate (questo lo sapevate già, ve l'hanno fatto notare da piccoli, costringendovi ad imparare a memoria Il sabato del villaggio, lo so, lo so,...). Per provarli ancora, c'è fuori il mondo, basta aprire gli occhi, toccare la lima, mettersi in poltrona ed accendere il CD.

Bene, sulla Rete è esattamente la stessa cosa. Solo che abbiamo fatto su un po' di casino. Tanto per cambiare.

Metteremo tutto a posto con il Web Semantico? Chi avrà voglia di compilare a manina tutta quella informazione che serve? Sarà fatto in automatico? Basterà? ...

Qualche altro tentativo di trovare un sentiero per uscirne c'è: aggregatori di RSS, social network che raggruppano social network (è un periodo che vengo bombardato da Plaxo Pulse, NotchUp e simili: prometto che prima o poi mi attivo e accetto i vostri inviti, solo un momento...), motori di ricerca, aggregatori di risultati di motori di ricerca...

Non sentite anche voi il bisogno di qualcosa di meglio?

Che so, un PIM molto evoluto, una MindMap a guida vocale, che memorizzi le ricerche e le metta in relazione, le ripeta da sola periodicamente, evidenziando le novità, proponendo dei riassunti di quello che ha trovato, annullando le ripetizioni inutili e i re-blog, proponendo solo le variazioni più interessanti allo stesso tema e fornendo una indicazione di credibilità (e non solo un page rank) dei vari testi (per esempio basata sulla presenza - e qualità, magari secondo criteri indicati da voi - di fonti e/o sulla quantità di ragionamenti simili, etc. etc.); che, intanto che siete lì a scrivere, suggerisca, nella colonna a destra, link ad argomenti interessanti e pertinenti (o anche solo relazionati) con il vostro testo, che vi avvicini a Leonardo, permettendovi di nuotare sopra e non sotto le onde, che vi picchietti sulle spalle per farvi voltare verso qualcosa di insolito e scrolli il capo se state scrivendo qualcosa che è già stata scritta su più di mille altri blog.

Lo scopo non dovrebbe essere ottenere il massimo dell'informazione (men che meno l'informazione che altri - il Marketing, quello con la M maiuscola - vorrebbero farci ricevere), ma ottenere l'informazione pertinente con un argomento che si definisce via via che procede il pensiero e la navigazione, che deriva, ma non è già incluso nelle chiavi di ricerca iniziali.

Lo scopo potrebbe essere quello di far nascere nuove idee, o anche solo fornire una visione del mondo più completa (stavo per scrivere coerente, ma è evidentemente un aggettivo ingenuo e presuntuoso).

Per raggiungere questi obiettivi è necessario, a mio parere, possedere una cultura multidisciplinare, che ci permetta di volare più in alto e di cogliere disegni più estesi.

E possedere è (in questo solo senso, per carità, non voglio fare un discorso classista!) un verbo il cui significato, con la tecnologia attuale, a mio parere oggi possiamo e dobbiamo estendere a recuperare molto velocemente, oltre che dalla cache di primo livello (memoria a breve termine) o dalla RAM (cervello) anche dalla memoria di massa (mondo esterno).

Forse è uno dei prossimi inevitabili sbocchi dell'informatica.

E, pensate, so cosa sto dicendo, capisco perfettamente le implicazioni di carico, di capacità elaborativa necessaria, di mancanza (ma siamo davvero sicuri?) di algoritmi adeguati e fondi (qui siamo, temo, davvero sicuri, a meno di qualche simpatica sorpresa, che potrebbe derivare da un lavoro di dimensioni significative, concertato e distribuito sulla rete) per raggiungere quanto proposto.

Rispetto a 10 anni fa, però, stiamo per superare un problema cardine, che apparentemente sembrava fuori portata in tempi così brevi: quello di creare una enorme base di conoscenza da cui partire.

Certo, Internet non è strutturata. Certo, non è coerente come l'ontologia di Cyc. Ma è molto più grossa.

E qualcuno ha suggerito altre strade, più informali, ma che, nonostante tutto, potrebbero portare a grandi risultati. Ne parleremo in qualche prossimo articolo (sì, lo so che vi rimando sempre a prossimi articoli, dopo avervi provocato, senza mai arrivare al nocciolo, ma non riesco a parlare di tutto e subito, soprattutto su argomenti sui quali non è così naturale condividere le idee di fondo... e, certo, non posso ora dimostrarvi di avere la risposta... anzi, ok, lo confesso, non ho la risposta, ma ho delle proposte e delle provocazioni, va bene? ... e sì, certo, mi servono parecchio i vostri feedback e mi serve che evitiate di crogiolarvi nel solito "ma, Depa, una cosa è un sogno, una cosa è la realtà: non è assolutamente possibile che un computer possa pensare o aiutarci a pensare... e poi sarebbe terribile, il computer controllerebbe le nostre vite, ... se fosse il computer a fornirti le idee, non saresti più tu, perderesti la tua identità..." . Fatemi capire che posso parlare davvero con Leonardo di macchine impossibili, che volano e vanno sott'acqua. Smettetela di ammirare solo lo scrittore che ha pensato che si potesse fare un "Giro del mondo in 80 giorni" e andare "Dalla terra alla luna", ma pensate un bel viaggio impossibile anche voi - ok, questo è Verne, non Leonardo, ma non attacchiamoci a cavilli, cerchiamo di seguire il ragionamento... -. E, soprattutto, smettetela di pensare che l'identità di chicchessia - si dice ancora 'chicchessia'? - si possa perdere con la stessa facilità di un mazzo di chiavi semplicemente scambiando due idee con altri - più o meno umani che siano. Trovo che, al contrario, anche se l'interlocutore dovesse essere più intelligente di noi - più o meno umano che sia - tali scambi non possono che arricchirci).

Una nota pratica: non sarebbe male se, una volta realizzato lo strumento di cui parlavo sopra, all'occorrenza fosse pure in grado di seguirmi anche nel bosco, mentre, coricato sul ramo di un albero su cui salivo da bambino, scambio le ghiande (e magari due idee) con gli scoiattoli e nessuno mi può telefonare...

Bye

DepaP.S.: smettetela di inarcare sopracciglia con aria di sufficienza: come fate ad essere certi che io sia solo capace di inserire smile nelle mail e non di dipingere sorrisi imperscrutabili in grado di attraversare la storia?
P.P.S.: chi ha detto, perchè ti conosciamo?

Modi di lavorare (framework - 1)

2008-04-21T23:57:00.012+02:00

Why "re-invent the wheel?"
One snappy comeback to that old saw is:
because this time we could make it rounder!
Apache Wicket - Introduction

No, non si tratta di reinventare nulla: framework è un termine abbastanza generale da essere applicabile a molti contesti, anche molto differenti.
Inoltre, quando con un framework riusciamo ad ottimizzare una operazione, ci si aprono nuovi orizzonti e, per raggiungerli, bisogna estendere o rivedere i nostri precedenti framework.

Non è reinventare la ruota. E' prendere quella a rullo dell'auto dei Flinstones e trasformarla in quella per la bici, per l'auto (anche da corsa), per lo skateboard o anche per far girare il mulino.

E' pensare di poterla agganciare su un supporto retrattile (sì, carrello, ma non banalizziamo sempre), perchè stiamo aggiungedo uno scafo per navigare e le ali per volare.

E' un estenderne ancora l'utilità e semplicità di utilizzo, aggiungendo anche dell'intelligenza alla guida.

Sapendo che su questo argomento non potrei essere sintetico come al solito, per una volta sarete contenti di sapere che ho deciso di spezzarlo in più parti. Questo non vuol dire necessariamente che proseguire con questo post sarà una passeggiata.

Una delle più interessanti spiegazioni di cosa sia un framework l'ho letta qualche anno fa. Diceva che un framework è qualcosa di più di un toolkit.

Se un toolkit è un insieme di oggetti che possiamo usare per semplificarci la vita (che so, un insieme di librerie, più o meno in relazione tra di loro), un framework è un toolkit integrato, che induce, in modo più o meno guidato, un modo di lavorare.

Se vi sembra sottointeso che tale modo di lavorare debba essere utile, operativo, effettivo ed economico (in una parola, forse ingenuamente troppo sintetica, produttivo), è possibile che non abbiate giocato abbastanza con i diversi framework del mercato, non vi siate abbastanza immersi in decine di file di configurazione più o meno inutili, ridondanti e logorroici (meno di questo post, lo so, ma è anche ora che la smettiate con questa unica battuta, cercate di rinnovarvi con un po' di fantasia...), non abbiate ancora abbastanza provato a farvi guidare su modalità perverse di complicazione di interazioni potenzialmente semplici (perifrasi autoreferenziante, molto vicina all'ermetismo... oramai l'ho scritta, che ci posso fare? ...di che tasto 'canc' state parlando?).

Un framework è sempre diverso da un altro, si tratta di una classe di software non ben definita, non di rado specializzata in una certa area.

Il loro scopo è supportare una specifica attività, suggerendo una strada, spesso con obiettivi diversi (infatti - semplicione io, che mi aspetto che produttivo debba essere la parola chiave, in questo ambito... - non tutti condividono che produttivo sia la parola chiave, per altri è sufficiente fermarsi a flessibile, per altri ancora non si deve neppure prendere in considerazione, se non è completo ed integrabile, etc. etc.).

Sono sistemi sempre esistiti e che sempre esisteranno, proprio per la loro natura di supporto nel raggiungere nuove mete. Fino a meno di 10 anni fa era frequente che ogni azienda costruisse il suo, partendo da un particolare ambiente di sviluppo. Talvolta evoluti naturalmente da alcune librerie, altre creati anche con un barlume di consapevolezza, costituivano un asset per l'azienda, le permettevano di proporsi sul mercato a costi inferiori rispetto alla concorrenza, talvolta di differenziarsi in termini di innovazione.

La mia personalissima impressione è che il termine sia oggi usato, principalmente, per indicare una ben specifico sottoinsieme di framework, quelli progettati per supportare applicazioni Web (la mia personalissima impressione potrebbe essere leggermente forzata ed indotta dal fatto che vivo ed opero nel Web, ma, come è accaduto in altri articoli precedenti, non mi importa molto approfondire la statistica, dal momento che, comunque sia, è su questa macro tipologia di sistemi che mi vorrei soffermare, nella parte restante di questo post).

Si tratta, oggi, di software di alta diffusione, i cui principali player stanno sempre più diventando prodotti Open Source (a proposito: nel seguito ci concentreremo su Java, ma se ne conoscete - sempre Open Source - su tecnologia Microsoft .NET, per favore, lasciate un commento, con breve descrizione sul tipo di quelle riportate più avanti).

Sto lavorando alla revisione del mio framework (quale framework? ovviamente il mio terzo framework Java, quello che sto cercando di trasformare nel mio quarto framework; va beh, per ora lasciamo stare: un giorno o l'altro vi faccio sapere qualcosa di più... ) e, proprio mentre sono immerso in documentazioni e comparazioni dei vari player di questo strano mercato, esce, su onJava.com un articolo intitolato Spring MVC, JavaFX , Google Web Toolkit and Struts2 - State of the (dis)Union.
E' un post di spunti, non di approfondimenti, che parte dalle proposte più interessanti, più di successo e, in alcuni casi, anche più discutibili degli ultimi 2 anni (ovviamente, visto il sito, con un occhio di parte Java):

Spring
Flex/OpenLaszlo
JavaFX
JSF
Google Web Toolkit (GWT)
[Struts 2 - implicito in tutto l'articolo]

Aggiungiamo che, per poter confrontare correttamente gli strati di presentation, l'autore non si dimentica che è necessario considerare, in certi casi, l'apporto di librerie AJAX (le più note: jQuery, Scriptaculous, etc. etc.).

Come campionario, niente male, proprio una bella accozzaglia di soluzioni architetturali e di tecnologie più o meno eterogenee, più o meno efficaci.

L'articolo finisce con una lacrimuccia di rimpianto per quello che JSF non è mai stato, ma che l'autore spera diventi (magari con un aiuto da parte di Struts2+Spring a traghettare verso una futuribile versione di JSF che smetterà di incasinare la vita degli sviluppatori - speriamo in questa vita, ma non lo dice) ed una forte indecisione che salva, con motivazioni differenti e spesso frivole (con motivazioni tipiche di una età che si nutre di marketing emozionale, il nostro mantiene Struts2 solo perchè figlio di Struts1 e Flex perchè, caspita quanto è carino a vedersi...), tutte le proposte sopra esposte.

Provocatorio o no, sono rimasto deluso dalla lettura, perchè non stavo facendo shopping, ma speravo di cavarne fuori qualcosa di utile.
Ricordo di aver alzato un sopracciglio con la chiara intenzione di far capire alla pagina Web che il mio umore stava variando dal perplesso all'accusatorio, prima di mettermi a leggere i commenti.

Che si sono rivelati decisamente più interessanti e pratici del post stesso: lì sotto si possono trovare ragionamenti basati sulla semplicità di utilizzo e sulla curva di apprendimento e alcune note riguardanti vari ambienti (Wicket, Stripes, Click) che non ho ancora mai provato (colpa mia, certamente, ma alcuni sono molto relativamente recenti e ci devo svelare che tra un test di un sistema e l'altro, talvolta mi capita di seguire dei progetti in cui se ne usa, tipicamente, uno per volta) e che ho dovuto approfondire (se non ero contento di come stavo riuscendo a perdere altro tempo tra notte e week end, evitando le giornate di sole ed il riposo, tralasciando le centinaia di task della mia to-do-list e cercando di incasinarmi ulteriormente...).

Sempre dai commenti viene ripetuta una classificazione da non trascurare: framework "request oriented" vs. framework "component oriented".
E' una modalità di approccio molto differente: nel primo caso si cerca di mantenere evidente allo sviluppatore il paradigma tipico del Web, nel secondo si tende a nasconderglielo, avvicinando la programmazione a quella tipica di un client-server, tipicamente trasformando la request http in eventi gestibili, lato server, come se avessero interessato un particolare componente.
La prima modalità è, tipicamente, preferita da chi ritiene:

che il ciclo request-response dell'http sia molto semplice da gestire
che sia meglio avvicinarsi all'effettiva modalità di comunicazione tra browser e server, per poter avere maggiore controllo e poter intervenire in modo più puntuale (non è raro che sia necessario accedere comunque a questo livello, per aggirare problemi specifici di alcuni framework component oriented)
che non sia il caso di legarsi ad un paradigma tipico di una interfaccia utente (ovvero: la stessa request potrebbe facilmente essere utilizzabile in un dialogo tra sistemi - in modalità REST, per esempio - semplicemente parametrizzando nel modo corretto il pattern MVC, in modo che la presentation possa produrre senza grossi sforzi html, xml, RSS o ad altro ancora; anche rimanendo sulle interfacce grafiche, la stessa response ad una request in ambito AJAX può essere fatta rientrare in simili parametrizzazioni)

La seconda modalità è, invece, preferita quando:

si devono riutilizzare competenze su ambienti client-server basati su eventi (particolarmente vero per la piattaforma .NET dove i componenti possono essere utilizzati con pochissime differenze su Web e in modalità client-server - un po' meno in Java, dove la gestione di GUI complesse lato client richiede, tipicamente, maggiori attenzioni e competenze solitamente differenti da quelle richieste dai framework più diffusi)
si deve utilizzare un team con molte risorse junior (il cronista non può fare a meno di registrare che questa scelta, tipicamente, viene fatta nella speranza che un framework component-oriented possa fornire questo vantaggio, ma, nella pratica non si riscontrano significative differenze, in questo senso, nelle due diverse modalità - è vero che mediamente i framework component-oriented sono più semplici da comprendere, non è altrettanto vero che li siano in modo assoluto, nè che siano sempre più semplici da utilizzare, soprattutto laddove si devono gestire casistiche di interazione non standard)
si devono affrontare progetti con interazioni standard, con una forte componente di ripetitività e modularità nelle pagine
si ritiene che la progettazione a componenti (a partire dall'UML, non solo sulla GUI) sia teoricamente e praticamente più flessibile dell'altro approccio (dopotutto, anche i servizi in una architettura SOA, cosa sono, se non componenti?) e che abbia anche il pregio di nascondere il livello di trasporto, rendendo potenzialmente più portabile, anche nel futuro, la nostra applicazione, casomai volessimo adattarci facilmente a futuri cambiamenti dell'HTTP.

Dal momento che nei commenti sopra riportati sono stato tutt'altro che obiettivo (per fare un esempio non esaustivo: è riduttivo considerare come componenti quelli di front-end: ne esistono, spesso, anche nel back-end - ma lasciatemi dire che vale anche nel paradigma request-oriented...), immagino avrete capito che la mia preferenza personale è fortemente orientata al primo modello. Mi interessa, comunque, un punto di vista differente, fatevi sentire.

Oramai lo sapete, non riesco a trattenermi dal fare una verifica anche sulla Wikipedia (che mi sembra sempre più riduttivo considerare solo come una enciclopedia in senso stretto... è un tema su cui ho intenzione di ritornare, pure in più puntate, temo...): sorvolando sull'utilità e sulla lacunosità del confronto, su cui la stessa voce consultata pone qualche dubbio, si trovano altri criteri: Linguaggio e licenza - Ajax (S/N, attraverso quali librerie) - tipo di MVC (push e pull che, per scegliere una delle molteplici interpretazioni, io tendo a pensare come MVC Model 1 e Model 2 ) - i18N e l18N (sarebbe più interessante che spiegassero la modalità usata per gestirli, più che siano o meno gestiti, no?) - ORM - Testing framework - Migration Framework - Template framework - Caching framework - Form Validation Framework.

Criteri interessanti, se letti un biennio fa (oramai quasi tutti hanno tutte queste caratteristiche, si tratta di bisogni impliciti).

Personalmente trovo che uno dei limiti di tutti questi framework sia lo spiccato orientamento agli aspetti tecnologici, tralasciando quasi completamente quelli più funzionali: tutti presentano caratteristiche interessanti per uno sviluppatore, raramente si trovano spunti che forniscano una visione d'insieme, da sistema aziendale integrato, magari con qualche funzionalità base già realizzata (es. banale e limitato: perchè rifare la gestione di autenticazione ed autorizzazione e l'amministrazione utenti e ruoli ogni volta da capo e non fornire una funzionalità base - sovrascrivibile e/o estendibile, chiaramente - che sia già direttamente utilizzabile, anche lato front-end? Perchè devo ricorrere ad un portlet container/portal system o ad un application server di alto livello per avere una funzionalità pur così elementare ?).

Riguardo gli aspetti tecnologici e funzionali, pensate che, di recente, sto sempre più convincendomi che un framework Web per le aziende di un certo debba comprendere addirittura funzionalità (anche evolute) di CMS, essendo, come già ebbi modo di dire, caratteristche tipiche ed irriununciabili del Web, la condivisione e la collaborazione.

Spostandosi di applicazione e passando da un framework ad un application server di alto livello (mi viene in mente il cruscotto di amministrazione del 'vecchio' ATG Dynamo, uno dei più completi, in questo senso), o da un framework ad un portlet container/portal system, le funzionalità di cui parlo si trovano. Ma un portlet container/portal system non è lui stesso un framework? Beh, da questa analisi li ho esclusi, ma siamo, a mio parere, al limite dell'interpretazione (soprattutto se accettiamo il parallelo anche con GTW e Flex, decisamente più orientati al frontend e meno agli sviluppi nel back-end ).

Il motivo essenziale per l'esclusione è che tali sistemi non inducono veramente un modo di lavorare, ma, solitamente, si limitano a poco più che fornire interfacce applicative: per es., un portlet container è più orientato all'implementazione reale delle specifiche JSR 168 e JSR 286 e va, solitamente, poco oltre, fornendo i minimi necessari meccanismi di cache e di log, più qualche funzionalità minima, per dimostrare l'utilizzo del portal (amministrazione utenti, ruoli, portlet, creazione dinamica di pagine e personalizzazione di stili e poco più); un portal system, invece, non sempre si adatta a standard, realizza, spesso, a modo suo qualche funzionalità alternativa e logicamente corrispondente alle portlet, aggiunge qualche funzionalità ulteriore, spesso più orientata al publishing, tendendo a confondersi con un CMS, spesso più sul front-end che sul back-end.

La considerazione finale, prima di fermarmi in questa introduzione, che mi pare possa bastare, come inizio, è che se un framework induce un modo di lavorare, meglio se ne scegliamo uno che si avvicina al nostro.

In prossime puntate (attenderete oltre un anno come per quelle che devo ancora scrivere a proposito di SOA?) entrerò, per una volta, in commenti di dettaglio di alcuni framework, (ovviamente partendo da quelli sopra citati), cercando di tenermi il più lontano possibile da una recensione o confronto diretto, ma con lo scopo di cercare di estrarre ed individuare elementi fondamentali dell'architettura, sempre nell'ottica che i framework di oggi sono destinati a lasciare presto il posto a quelli di domani, spesso le loro stesse prossime versioni, mentre le soluzioni progettuali veramente interessanti continueranno a rimbalzare tutt'attorno, come delle perle che lasciano il filo di una collana (e cercheremo di fare in modo che non si perdano sotto al mobile).

Nel frattempo potreste dirmi in che modo lavorate voi, o che framework utilizzate o se pensate che ce ne sia qualcuno di ragionevole diffusione (non il vostro, non quello dei vostri amici, please, non sono qui per farvi pubblicità), ma non citato, che vi piacerebbe considerare (e perchè, già che ci siete, via...)
Bye

DepaP.S.: ogni commento sull'ultima similitudine è totalmente inutile, lo capisco da me che è forzata, quasi come una incudine tra le macine di un mulino che sta pestando il grano
P.P.S.: ovviamente quella appena sopra è ancora più fuori luogo, direi come un turista in pantaloncini corti e faccia perplessa nel tentativo di leggere una mappa capovolta, in piena Groenlandia.
P.P.P.S.: ...ahem... doveva essere un articolo serio... ;)

E' ancora Natale?

2008-02-15T22:23:00.013+01:00

Capisco benissimo che siate sconcertati.

Oramai, era inevitabile, basate la vostra esistenza su questo blog ed il fatto che io non stia scrivendo da un po' di tempo vi crea degli scompensi temporali.

In base all'ultimo post siete convinti che sia Natale (via, Capodanno), ma vi ricordate di aver visto, proprio pochi giorni fa, dei bambini vestiti da carnevale e i vostri colleghi stanno già fissando le ferie pasquali (qualcuno accenna pure alle vacanze estive).

Vi devo avvisare: non sto più inserendo articoli con la necessaria costanza, ma il tempo sta andando avanti.
Davvero. Fatevene una ragione.

Vi riporto alla data giusta che, senza alcun dubbio, non avete dimenticato: non è Natale, è la festa di compleanno.
Di questo blog, ovviamente.

Quando finite di regolare gli orologi ed i calendari, potreste aiutarmi a tirare le prime somme?
Senza dimenticare i regali di compleanno.

E potremmo finire senza una torta pantagruelica?

Cercando di evitare una autocelebrazione, è pur necessario che condivida con voi alcune idee, che potrebbero non essere emerse così evidentemente. Devo farlo, capite, anche se non vorrei.

Partiamo dai principi base di questo blog, che ne possono dare una prima chiave di lettura:

non scrivere post troppo legati al momento attuale, ma che possano essere ancora interessanti tra un anno, anche se dovesse mai capitare di parlare di informatica (il che significa, per rimanere su questo esempio quasi assurdo, concentrarsi su architetture, principi e prospettive future e non - troppo - di sviluppi in linguaggi o tecnologie specifiche, di programmi che stanno uscendo, di tendenze, etc. etc.)
i contenuti devono essere sostanziosi e, compatibilmente con le mie possibilità, di alto livello, anche a discapito degli hit
cercare, fin dove riesco, l'interdisciplinarietà, perchè la cultura vera non è nè tecnica, nè umanistica, nè artistica, ma è data dall'insieme di tutti questi aspetti, (e sono molto triste di non essere riuscito a convincere un mio amico, professore di filosofia all'università, a scrivere con me un blog sul tema L'ingegnere e il filosofo, che sarebbe stato interessante, anche per la contrapposizione di vedute - o una sofferenza per i lettori elevata al quadrato rispetto a questo blog, non saprei). Come effetto collaterale si ottiene un taglio completamente diverso, meno ripetitivo, anche su argomenti che si possono trovare, solitamente più frammentati e senza visione generale ed evolutiva, in tutto il resto del mondo virtuale conosciuto.
prevalenza di argomenti informatici (è l'unica cosa in cui ho delle reali competenze, per il resto delle attività umane sono dilettante quando non inetto), ma con una alternanza di argomenti giocosi/curiosi (ma non banalizzati: anche per giocare è necessario farlo bene - sì, ogni tanto bisognerebbe anche lasciarsi andare, ma non su questo blog, che richiede queste impostazioni - ma ne riparlo in fondo)
i link e le fonti devono essere ben selezionati e citati, per poter fornire strumenti per capire ed, eventualmente, stravolgere la mia interpretazione; lo scopo rimane quello di dialogare e porre dei dubbi, soprattutto quando le certezze sembrano più granitiche.
un po' di ironia, perchè salire in cattedra e non prendersi anche in giro sarebbe insostenibile. Per dirla con Vecchioni:

ho appreso dalla vita l'amaro frutto della vanità,
mi sbellico dal ridere per chi ha letto in me la verità:
chiedo clemenza ai giudici come un gesto di carità.
[Tango di rango]

Poi, purtroppo o per fortuna, i principi, almeno per simili argomenti leggeri, si fissano e poi non sempre si rispettano.
Salvo, poi, quando si rileggono i post, trovarsi a storgere il naso e a chiedersi perchè mai l'avrò fatto...

A stampare quanto ho scritto, per circa una trentina di post, ne potrebbe uscire un libercolo di un centinaio di pagine: concedetemi, quindi, almeno fare un sommario (anche per chi fosse appena arrivato, vedi mai che ci possa essere qualcosa di interesse, che si sarebbe altrimenti persa - anche perchè ho scoperto che via feed, oramai, si vedono solo gli ultimi 28 post e non trovo una configurazione per aumentarli).

Gli inizi

Solo auto-ironia e una preview dei contenuti futuri nei primi post Si inizia e Pausa di riflessione. Non sono stati molto letti, ma ci mancherebbe altro. Ciò nonostante uno dei due mi ha generato un link esterno (e altri più interessanti quasi non sono letti)! Lo strano mondo dei blog...

I post su cui siete arrivati, forse per sbaglio, più spesso:

Come forzare un lucchetto : anche da quanto risulta dalle parole chiave di ricerca - nonchè da quanto ipotizzato direttamente nell'abstract del post - il fatto che questo post sia tra i più cliccati è dovuto al fatto che molti cercano di arrotondare lo stipendio in modi che non vogliamo sapere. Comunque ritengo che sia uno dei più interessanti, nonostante non tratti di grimaldelli, ma di Web semantico.

Aeroplani e draghi di carta : non avete idea di quanta gente esegua ricerche sugli areoplani di carta. E qui spero trovino pane per i loro denti (davvero: questa volta non è una trappola come il post precedente). Uno dei miei preferiti, anche perchè si è generato da una sorpresa: l'origami come arte di altissimo livello e non hobby da 4 soldi, come avevo fino a quel momento pensato. Se già non lo avete letto andateci subito e non perdetevi i filmati!

Tra i due sopra citati ed il resto non c'è confronto, gli hits scendono di quasi 5 volte, ma riporto, comunque, gli immediati inseguitori:

Superato il Test di Turing : Anche in questo caso mi sono divertito. Su uno dei miei argomenti preferiti: Intelligenza Artificiale (va beh, si fa per dire, dai chatterbot all'inizio dell'Intelligenza Artificiale, via...).

Non ibernatemi : Sono d'accordo con voi, è un articolo da leggere. Non ho trovato grosse difficoltà a motivare le mie scarse simpatie per l'ORM (Object Relational Mapping). Che continuano ad aumentare nel tempo, man mano che mi capita di ritrovarmelo da tutte le parti. Forse un giorno si riuscirà ad ottenere una tecnologia che metta facilmente in contatto i database relazionali e i linguaggi object oriented. Ma non è oggi.

Di fatto la testa della classifica mi trova completamente d'accordo, nonostante possano aver inciso sul conteggio cause non legate direttamente al contenuto.

I meno letti:

No, questi non ve li dico, ma, al contrario dei 4 sopra citati, non posso che confermarvi che mi trovate d'accordo nel consigliarvi di continuare a non leggerli (potrete capire da soli in quale categoria ve ne parlerò nel seguito).

Gli altri di cui sono molto soddisfatto:

A Betlemme di Giudea : mi è piaciuto scriverlo sia per l'argomento (storia ed apologetica cattolica legata alla nascita di Cristo), che per la profondità della ricerca in cui mi sono dovuto infilare, leggendo testi interessanti, in misura molto maggiore di quanto sia poi riuscito a riportare.

Letteratura Fiabesca Applicata all'Informatica : più che per i contenuti, (tipizzazione forte, debole e duck typing anche in Java e relativi impatti architetturali), comunque, significativi, mi è piaciuto il gioco formale che ne è saltato fuori: partendo dalle fiabe e dalla loro struttura, sono passato all'informatica, per tornare alle fiabe, attraverso analogie e giochi di parole. Mi ha divertito, anche se è stato poco letto. Forse un po' troppo costruito e un po' pesantino, soprattutto nella parte centrale?

Keep In Touch : prima presa di coscienza dei benefici del mettersi in contatto con gli altri attraverso questo mezzo di comunicazione. E' stato bello cambiare il punto di vista (non me l'aspettavo), è diventato ancora meglio per i commenti che sono presto scivolati su argomenti logici e religiosi, mi ha fisicamente provato per la gestione dei commenti extra-blog, che sono stati i più intensi ed interessanti di tutto questo periodo.

Timeo Danaos et dona ferentis : un titolo originalissimo (è venuto in mente, per argomenti differenti, a neppure altri 10000 blogger) per una domanda ancora valida: Web 2.0 o Bubble 2.0 ? Ci guadagnano solo i grandi player di Internet o potrebbe essere utile anche a noi?

Quelli che mi aspettavo leggeste fino a consumarne le pagine...
... e, invece, li avete sorvolati svogliatamente. Ok, forse sono un po' densi, certo non sono tutti brillantissimi, ma come fate a vivere senza? (ah... sapevate già tutto e li avete trovati noiosi... scherzate, vero?... vero?) :

CRUDeli variazioni : sulla generazione automatica di codice, in diverse salse, partendo dalla letteratura e da Queneau. Dove fermarsi e dove usarla a piene mani.

Narciso Yepes e la chiave del quindici : usi e, soprattutto, abusi dell'XML, paragonati a performance straordinarie di un virtuoso della chitarra (da ascoltare).

Reti di parole su CD : introduzione alla comprensione del linguaggio naturale per i computer. Siccome credo in queste tecnologie nel breve-medio periodo, aspettatevi ulteriori approfondimenti tra poco.

Soldi facili : si possono davvero fare i soldi con i blog? anche scrivendoli in italiano?

SOA (1) - Introduzione : primo articolo di 4-5 (almeno nelle intenzioni dichiarate). Introduzione e concetti generali.

SOA (2) - Variazioni Goldberg : Web Services e REST al servizio di SOA e altre basi terminologiche. Primi cenni alla gestione ed agli impatti di questi tipi di progetti. Da leggere con sottofondo musicale embedded (se ce la fate a seguirli contemporaneamente, però, siete molto più intelligenti di me).

I restanti 2-3 articoli sull'argomento sono rimasti un po' indietro, vediamo di riprenderli nei prossimi mesi, se trovo il tempo (ma è anche colpa vostra, che non me lo avete ricordato).

Quando meno te l'aspetti : evoluzioni dell'HTML attese a breve. Mi sembra interessante per approfondimenti non consueti, che poco hanno a che fare con il normale AJAX e company.

Just another brick in the wall- : Mattoncini di Lego, filmati di Star Wars fatti da mattoncini di Lego, robot programmabili in mattoncini di Lego, CAD che usano mattoncini di Lego, ... perchè mai questo post è stato snobbato? ma voi non giocate mai? (se ne faccio altri simili mi tirate mattoncini non di Lego?)

Senza infamia (e, purtroppo, senza lode):

Libbertà : tutto sommato non mi dispiace. Nasce, forse, da una interpretazione troppo stretta della GPL (ma ne sono convinto solo al 90%), dovrebbe essere interessante per la carrellata sui modelli di business Open Source e mostra, comunque, alcuni limiti della licenza su citata. I commenti di questo post sono essenziali - ringrazio Ugo Cei per aver voluto approfondire con me l'argomento - per il raggiungimento di un punto di vista completo. Attendo ancora un intervento conclusivo da parte della FSF italiana (ho cercato di interessarli direttamente, attraverso vie esterne al blog, spero che trovino il tempo)

Oggi scricchiolo : scritto più velocemente del solito, più emotivo del solito (anche se, almeno in questo blog, emotivo è un termine quasi impraticabile). Forse troppo personale, un po' ermetico, con un motivo, un gioco strutturale forse semplice, ma che non mi dispiace neppure rileggendolo ora. Eppure non totalmente incompreso da chi l'ha letto.

Bentornati : spinto da un particolare umore nero, mischio Umberto Eco, il Vangelo, Terry Pratchet, Pitigrilli e Fahrenheit 451 in un calderone orientato ad una crescente (e, ho visto, non solo per me) consapevolezza che 1984 di Orwell possa essere già in atto, meno grigio e meno opprimente, ma con informazioni altrettanto distorte e pre-interpretate del mondo e della storia. Troppo complesso, troppo costruito.

Condivisione e Collaborazione : uno dei miei slogan preferiti per spiegare perchè ci serve il Web, anche per applicazioni Enterprise, nonostante l'operatività intensa sia molto più complessa da ottenere rispetto alle tecnologie client-server preesistenti. Un po' perso in mezzo a citazioni di programmi specifici, eludendo uno dei principi base. E già a distanza di pochi mesi si sente, purtroppo.

Pendolari : quando non se ne può proprio più. Accettabile (secondo i criteri di questo blog: come racconto, in senso assoluto, non mi permetto di giudicarlo), ma non va oltre lo sfogo.

Non ci resta che piangere : divagazioni inutili a spasso nel tempo. Ma ogni tanto bisogna prendersi una pausa.

Il codice dei Wooster : c'è ancora la cavalleria e l'onore? In Internet? Con un ricordo per Wodehouse, uno dei miei autori preferiti.

Giochiamo : Games programming nella vita e in Java. Un po' dispersivo e non così approfondito come mi sarebbe piaciuto. Ma può essere una ragionevole base di partenza, da cui partire per prossimi post.

Kerygma : purtroppo non sono così abile su questioni teologiche, ma ho cercato di fare del mio meglio, su un argomento che ritengo della massima importanza. Segnalo la presenza di un commento molto interessante ed intenso.

Esagoni e carte : Wargames e tattica su fogli e PC.

Crisi di rigetto : letture pessime e ricerca, con Calvino, di qualcosa di meglio. Presa in giro dei miei post, che spero restino meglio dei libri di Dan Brown (il fatto che siano meno letti può far pensare, ma non sopporterei l'idea che sia vero il contrario).

Wanted : un post in cui mi sono solo divertito. Non dice nulla, quello che dice non serve, scienza e fantasia in un misturone, con la speranza che possa aver fatto sorridere anche voi.

Quelli che se anche non li scrivevo, forse era meglio:

Come un bambino : grafica e programmi, fuori da ogni principio (salvo quello dell'approfondimento) di questo blog. A proposito, devo andare a verificare se MakeHuman ora è in grado di generare anche vestiti e capelli.

Uno, nessuno e centomila : questo è piaciuto solo a chi si chiama Depa. Non poteva essere altrimenti. Rileggendolo, almeno ad un Depa non piace più.

Ho, poi, scritto la bellezza (?) di 4 post su una serie di programmi che permettono di rovinarsi le serate con la TV anche su Internet. Si salva vagamente solo Osservando distaccatamente babeli mediatiche, solo perchè mi sono guardato piangermi addosso a proposito delle paranoie sull'essere controllati (il 1984 che citavo sopra) e ho deciso che non ne valeva la pena. Sugli altri, Joost Jump, Adelante, presto, e con un po' meno juicio, A Venezia, 'giust' si scrive Joost- , vorrei evitare, se non vi spiace ogni commento.

Il post che state leggendo, probabilmente, rientrerà in quest'ultima categoria, ma non ho voluto scriverlo, semplicemente dovevo farlo.

Non vi sembrerà vero, ma con questo finisco la carrellata sul passato.

Con qualche considerazione, sulle lezioni imparate:

è giusto scrivere come ci si sente, non lasciarsi prendere dal timore di non essere letti. I miei post sono pesanti, ma tutti, anche i più vecchi, continuano ad essere letti (non tanto, ma . Se avessi scritto due righe copiate,
è interessante mettersi in gioco: all'inizio si ha un po' di timore, dopo un po' si sente il bisogno di confrontarsi, lo si va a cercare (ed è per questo, anche, che ho bisogno di altri spazi, come dirò tra poco)
ho scherzato sulla pesantezza dei post, ma è chiaro che è davvero un problema
sento la necessità di uscire dalle regole autoimposte, di scrivere qualcosa di più impalpabile e incerto

E' chiaro che mi servono altri spazi, tempi diversi.

Di conseguenza vi anticipo la mia intenzione di aprire almeno un altro blog.

Non come questo, più leggero, con post ridotti, idee alla rinfusa, molto meno fissate, meno studiate, più domande e meno risposte.

Non potrei sopravvivere, altrimenti.
E voi, che a vedervi siete già gracilini, men che meno...

Un blog più classico, ma anche più idee da elaborare assieme.

Perchè non inserire direttamente qui quei post? Ma, ovviamente, perchè su questo blog voglio mantenere questo taglio, voglio continuare a proporre qualcosa di significativamente diverso dal solito.

Visto che non riesco a mantenere un giusto ritmo con un blog, è evidente che per aprirne un altro devo, come minimo, dotarmi di mezzi più potenti.

Quindi, come regalo di compleanno per questo blog (e preparando il lieto evento per il prossimo), ho girato un po' su Internet, cercando degli offline editor. Che non sono solo strumenti per scrivere in HTML con un WYSIWYG, ma che permettono di tener traccia dei post, categorizzarli, inserire immagini e tag e poi, quando torna la comunicazione, pubblicarli con un solo click. Molto meglio (questo post l'ho scritto con uno dei due sotto citati - più un po' di lavoro a mano).

Per Google c'è un prodotto free di Microsoft (sì, anch'io non ci credevo, non per il free, ma per il fatto che supportasse Blogger, di fatto importante concorrente - non è che puntavano a comprarsi quello, al posto di Yahoo?), più noto per supportare portali Microsoft, appunto: Live Writer.

Per WordPress (il prossimo blog lo apro sotto questa piattaforma - anche su richiesta pressante di chi mi segue con più frequenza), userò, invece, BlogDesk, che, anche se leggermente più spartano, sembra pure avere più funzionalità. Purtroppo Blogger non è citato tra le piattaforme supportate (ma farò, comunque, una prova, per vedere se non si riesca comunque: due strumenti per fare la stessa cosa mi sembrano un po' tantini...)

Vi faccio sapere, è questione di poco, come vedete mi sto attrezzando...
Bye

Depa P.S.: di che torta state parlando? PantagruCHE?
P.P.S.: avete sopportato fino a qui perchè ne volevate una fetta? ;)

A Betlemme di Giudea

2008-01-01T17:32:00.000+01:00

Natale è appena passato, tra alberi, presepi, doni e pranzi.

Credo non sia necessario essere cristiani per sentire la nausea dovuta all'eccessiva commercializzazione di questa festività, ma certo, per chi ha fede, è ancora più triste pensare che, parallelamente, tendiamo a dimenticarci perchè e cosa festeggiamo.

Cosa ci ricordiamo di ciò che proviene dai Vangeli canonici? Dei quattro, quanti ne parlano?. Quanto di ciò che attribuiamo al Natale deriva dalla tradizione o da altre fonti?

Qualche dubbio ci ha vagamente sfiorati mentre stavamo facendo il presepe?

E' possibile una ricostruzione storica? A che profondità?
Era il 25 dicembre? L'anno zero è calcolato correttamente? (domanda leziosa: tanto non si andrà certo a risincronizzare gli orologi...)

La Natività è avvenuta in una grotta o in una stalla?
C'erano il bue e l'asinello che riscaldavano, ovviamente, anche perchè il Bimbo era in fasce nella mangiatoia, con di fianco Giuseppe e Maria, no?

E pastori e gregge compaiono, nei testi?

Quanti angeli avete messo, nel presepe?
Tra qualche giorno, a seguito della stella dovrebbero arrivare i Magi (portavano davvero oro, incenso e mirra?).

Non è in questi dettagli, ovviamente, il senso proprio del Natale.
Rispetto a quanto sto per dire ci si avvicina di più Dickens con la storia di Scrooge, intendo.

Ci sono persone che sentono e capiscono chiaramente il senso profondo delle parole "Il Verbo si fece carne e venne ad abitare in mezzo a noi", pur senza capire nulla di filosofia e questo gli è sufficiente.

A me, invece, (farei volentieri a cambio) serve ripercorrere ragionamenti freddi e spiegazioni logiche già fornite mille volte nei secoli (ma molto raramente ripetute ai più, quando talvolta servirebbe), per un bisogno di razionalità, derivato dalla società attuale e dalla mia preparazione ed inclinazione personale.
O, peggio, per mia poca fede, rispetto ad una più grande fede di altri (e non è una questione di essere semplici o meno, colti ed intelligenti o meno, perchè nella storia si sono presentate tutte le combinazioni).

Da cui: ricerchina sul Web (e non solo!), per ottenere, tramite copia e incolla, un approfondimento sufficiente, non dico ad avvicinarmi ai livelli di divulgazione di Superquark, ma, almeno, a soddisfarmi come quadro riassuntivo d'insieme.

La santa madre Chiesa ha ritenuto e ritiene con fermezza e con la più grande costanza che i quattro suindicati Vangeli, di cui afferma senza esitazione la storicità, trasmettono fedelmente quanto Gesù Figlio di Dio, durante la sua vita tra gli uomini, effettivamente operò e insegnò per la loro eterna salvezza, fino al giorno in cui fu assunto in cielo [...] E gli autori sacri scrissero i quattro Vangeli, scegliendo alcune cose tra le molte che erano tramandate a voce o già per iscritto, redigendo un riassunto di altre, o spiegandole con riguardo alla situazione delle Chiese, conservando infine il carattere di predicazione, sempre però in modo tale da riferire su Gesù cose vere e sincere.
[Dei Verbum - Costituzione Dogmatica sulla Divina Rivelazione, Capitolo V, par. 19 - l'enfasi è mia]

Vi tolgo subito la suspence con uno schemino iniziale:

dei 4 canonici, solo 2 parlano della Natività, Matteo e Luca
25 dicembre e posizionamento dell'anno zero sono in dubbio, (ovviamente senza alcun problema di fede, che non è basata su questi dati), da
secoli. Esistono, però, alcuni indizi, nel Vangelo di Luca, che permetterebbero, con l'aiuto di recenti scoperte archeologiche, una definizione più accurata.
la grotta deriva dalla tradizione cristiana, non dai Vangeli, ma quella identificata come tale ha una mangiatoia, come dice Luca, scavata nella roccia.
bue ed asino compaiono per la prima volta in un apocrifo dell'VIII-IX sec. (pseudo-Matteo), ma erano già da prima nella tradizione popolare, per il loro significato simbolico e S.Francesco, nel primo presepe, li volle inserire. Quindi non fa male lasciarli, nel presepe, nonostante non ci siano prove della loro presenza.
Luca è il solo a parlare di bimbo in fasce nella mangiatoia, ma nulla in Matteo la esclude. Entrambi parlano sia di Giuseppe che di Maria.
Luca è il solo a parlare di pastori e gregge, così come di angeli
Matteo recupera, parlando, solo lui, di stella e Magi (sì, parla proprio di quei doni...)

E' bene notare fin da subito che non esistono discordanze significative tra i due racconti: semplicemente raccontano aspetti diversi dello stesso evento, in modo più o meno approfondito, senza contraddizioni.

Una nota importante: io NON sono uno studioso biblico, NON sono un esperto di scritture, sono, certamente, un cattolico credente (e questo rende quanto scrivo certamente di parte), ma sono un cattolico pensante, cui piace approfondire i motivi della propria fede e mi piace giocare pulito (se vogliamo, prima di tutto con me stesso).
Quanto ho raccolto e riportato in questo scritto non è farina del mio sacco, ma è una rielaborazione, un approfondimento basato su fonti che ritengo valide (dopo averne lette decine, anche riportanti ipotesi opposte o molto fantasiose), che vi ripropongo e che, quindi, potrete verificare direttamente.

Partiamo dai Vangeli.

Matteo:

Gesù nacque a Betlemme di Giudea, al tempo del re Erode

Betlemme e tempo di re Erode. L'indicazione, fin qui, è un po' scarna: vedremo poi che dal testo di Matteo potrebbero sorgere altri vincoli temporali, legati alle tipologie di fenomeni celesti che, secondo quanto oggi noto, si sarebbero potuti verificare in quel tempo e che potrebbero spiegare la menzione alla stella.
Sul periodo di massima ("al tempo del re Erode") i due Vangeli sono concordi, ma è da Luca possiamo estrarre indizi per provare a definire possibili date. E' importante notare che i Vangeli non ne indicano esplicitamente nessuna, quella solitamente considerata come riferimento è stata scelta a posteriori da Dionigi il Piccolo, intorno al 525 d.C., sulla base di calcoli da lui sviluppati e messi in dubbio parecchi secoli fa. La scelta della data, è bene ricordarlo, pur essendo elemento di interesse, non è un elemento di fede.

Alcuni Magi giunsero da oriente a Gerusalemme e domandavano:

Nota: non sappiamo quanti, non sappiamo i loro nomi, sono 'alcuni', non si parla di re. Si dice solo che provengono da Oriente (genericamente la Transgiordania, per i Palestinesi). L'etimologia riporta a sacerdote oppure grande (e, quindi, poco ci aiuta). Senofonte ed Erodoto li descrivono come casta sacerdotale presso i Medi ed i Persiani, che si occupava di divinazione, astronomia e medicina. Non è comunque necessario immaginare che dovessero arrivare da così lontano, potrebbe bastare fermarsi all'Arabia (anche per il tipo di doni).

Qui si inserisce la tradizione popolare, derivata da diversi apocrifi, in cui i Magi si ritrovano a manciate:

nel Protovangelo di Giacomo, l'apocrifo più antico citato da Origene (+ 254) si parla di Magi senza specificarne il numero.
nel "Vangelo dell'infanzia armeno" (datato tra il 428 e il 431 d.C. ed cui si indica pure una data e ora dell'annunciazione - 4 aprile, mercoledì, alla terza ora e data di arrivo dei Magi - 6 gennaio - fatta coincidere, in questo vangelo, con la nascita di Gesù "giunsero a destinazione nel momento in cui la vergine diveniva madre"), compaiono per la prima volta i titoli regali, il numero ed i nomi dei 3 magi ("erano tre fratelli; il primo, Melkon, regnava sui Persiani, il secondo, Balthasar, regnava sugli Indiani, e il terzo, Gaspar, possedeva il paese degli Arabi"). Essendo descritti come re, vengono seguiti da 12 comandanti e 12.000 cavalieri. Anche riguardo ai doni si esagera a piacere: oltre ad oro incenso e mirra vengono portati aloè, mussolina, porpora, pezze di lino, e i libri scritti e sigillati dalle mani di Dio, nardo prezioso, cannella, cinnamomo, altri profumi,oro, argento, pietre preziose, zaffiri di gran valore e perle fini. Quando la stella che li precede si spegne, loro si accampano e vanno direttamente alla ricerca del bambino. Se dovessimo fare un presepe basato su queste descrizioni, sarebbe il caso di iniziare a lavorare intorno a marzo, facendosi aiutare da esperti modellisti di Warhammer...
nel Vangelo dell'infanzia arabo-siriaco, segnalato da H. Sike nel 1697, che viene fatto risalire almeno al VI secolo : il racconto è più lungo, ma ancora non si parla di numero, nomi e regalità. Si parla, invece, di riti basati sul fuoco (assolutamente inutili per gli scopi di questo post, ma molto folkloristici)

Esistono ulteriori scoperte archeologiche che mostrano che già nel IV secolo la tradizione popolare prevedeva la presenza di un numero di 3 Magi. Come vedremo, il numero - assolutamente non certificabile - viene probabilmente derivato dai doni.

Abbiamo visto sorgere la sua stella, e siamo venuti per adorarlo

NOTA: il riferimento alla stella è molto vago. La stella è stata vista sorgere, ma non è descritta. Più avanti, però:

Ed ecco la stella, che avevano visto nel suo sorgere, li precedeva, finché
giunse e si fermò sopra il luogo dove si trovava il bambino.

Al vedere la stella, essi provarono una grandissima gioia.
Matteo usa una descrizione popolare, secondo la quale la stella sembra muoversi (li precedeva, giunse, si fermò), ma non ne parla come di una cometa. Questa tradizione, infatti, inizia ai tempi di Giotto, che, dopo aver visto direttamente, nel 1301 la cometa di Halley, la utilizzo, fra 1305 e 1310, nell’affrescò nella Cappella degli Scrovegni a Padova. Ma la Halley sarebbe arrivata troppo presto (12 a.C.).

Esistono altri possibili fenomeni storicamente accertati che potrebbero spiegare la descrizione della cometa? A quanto pare (stesso articolo di Cardini sopra citato, ma anche la Wikipedia) parecchi (attenzione alle date, ci torniamo dopo):

Keplero segnalò che nel 7 a. C. i due pianeti Giove e Saturno si congiunsero per ben tre volte, con effetto ottico di straordinaria brillantezza
nel febbraio del 6 a.C. si registrano le congiunzioni di Giove con la Luna e di Marte con Saturno nella costellazione dei Pesci
gli astronomi cinesi segnalarono nel 4-5 a.C. un fenomeno astrale, probabilmente una nova (purtroppo le annotazioni non sono così precise da poterlo stabilire con esattezza), che fu visibile anche in presenza del sole per circa 70 giorni, nelle costellazioni dell’Aquila e del Capricorno. Alcune descrizioni riportate da apocrifi sembrano aderenti a questa ipotesi che, come quella degli eventi del 7 a.C. fu proposta come possibile spiegazione già da Keplero

Le diverse ipotesi (nova, cometa, congiunzione planetaria) sono riprese più approfonditamente in questo testo di Giovanni Pellegri.

Trovo interessante, in questo articolo, la nota finale relativa all'ipotesi della congiunzione astrale di Giove e Saturno:

Se forziamo questa ipotesi fino in fondo si può immaginare che i Magi prepararono la partenza alla data della prima congiunzione (29 maggio del 7 a.C.), giunsero a Gerusalemme dopo un viaggio di circa 900 km durante la seconda congiunzione (29 settembre), e adorarono Gesù appena nato a Betlemme nell'autunno dell'anno 7 a.C. Si può escludere che la nascita di Cristo sia avvenuta in dicembre (data della terza
congiunzione) visto la presenza di pastori e greggi all'aperto.

Sull'ultima frase ritorneremo a breve.

Questa ipotesi, infatti, spiegherebbe la frase "al vedere la stella, essi provarono una grandissima gioia", che, almeno a me, fa pensare che la stella sparisse e ricomparisse (altrimenti perchè avrebbero dovuto provare gioia, se la stavano vedendo e "seguendo" da tempo?). La data del 7 a.c., ed i periodi dell'anno in cui sarebbe stata visibile, poi, ben si sposano con le altre ipotesi di date che vedremo nel seguito.

[i sommi sacerdoti e gli scribi] gli risposero: "A Betlemme di Giudea, perché
così è scritto per mezzo del profeta: ..."

Betlemme, potrebbe sembrare un punto assodato, ma ci torniamo.

Entrati nella casa,

Nota: casa, non stalla, non grotta. Teniamolo presente, anche di questo parleremo dopo.

videro il bambino con Maria sua madre, e prostratisi lo adorarono. Poi aprirono
i loro scrigni e gli offrirono in dono oro, incenso e mirra.

Quindi: oro, incenso e mirra (che è una resina odorifera) derivano direttamente dal Vangelo.
Si tratta di doni ricchi, se è vero che Plutarco narra, nella Vita di Alessandro che Alessandro Magno, dopo la conquista di Gaza, prelevò dal bottino di guerra 500 talenti di incenso e 11 di mirra come dono per il suo precettore Leonida.
Come già accennato, probabilmente la tradizione dei 3 Magi nasce dal fatto che i doni erano 3, ma sarebbe un po' ingenuo considerare valido questo numero, sulla base di queste sole considerazioni.

Per finire, notiamo che Giuseppe (il Giusto, per Matteo) non compare esplicitamente in questo punto (ma non è significativo per poter dire che ci fosse o meno), nonostante sia parte dell'intero racconto della Natività, uno dei destinatari della rivelazione che gli perviene attraverso un angelo, in sogno. Luca e Matteo, (ma questa ce la risparmiamo, in questa sede, perchè è molto lunga e complessa, oltrechè fuori tema), secondo l'interpretazione cattolica, sono concordi nei due testi nell'identificare la verginità di Maria.

Passiamo a Luca che, decisamente più ricco di particolari, ci permetterà di portare avanti i discorsi rimasti in sospeso:

In quei giorni un decreto di Cesare Augusto ordinò che si facesse il
censimento di tutta la terra. Questo primo censimento fu fatto quando era governatore della Siria Quirinio.

Con queste frasi di Luca, introduciamo il problema della possibile identificazione temporale, non solo relativa all'anno, ma, già che ci siamo, anche al periodo dell'anno.

Partiamo proprio da quest'ultimo, premettendo che dovrebbe essere ben chiaro a tutti (lo è, certamente, agli esperti) che, ad oggi, non esiste alcun documento che ci permetta di conoscere con esattezza la data di nascita di Cristo e, di conseguenza, il 25 dicembre deve essere considerato solamente una convenzione.

E' però curioso notare che studi recenti (citati, per es., dal professor Tommaso Federici nel 2000), renderebbero plausibile la data del 25 dicembre come storica e tramandata e non, quindi, come sostituzione (decisa nel IV secolo) della festa pagana del Sol Invictus, come ancora attualmente ritenuto valido dalla grande maggioranza degli esperti. Se volete i dettagli seguite il link, ma giusto per fare un riassuntino:

il Vangelo di Luca dice che Zaccaria, della classe di Abia, il futuro padre di Giovanni Battista, era di turno al tempio quando l'angelo Gabriele gli comunica la nascita del figlio 9 mesi dopo.
uno studioso ebreo (non un cristiano, quindi esente da sospetti), Shemarjahu Talmon, ha ricalcolato, partendo dai rotoli del Mar Morto (notiamo che la scoperta archeologica è degli anni 1947-1956, cosa che spiega come mai questi studi siano così recenti), le tabelle di avvicendamento al tempio delle diverse classi sacerdotali, indicando che una delle due date possibili del turno di interesse poteva essere tra il 24 ed il 30 di settembre (interessante notare che gli ortodossi festeggiano l'annuncio a Zaccaria il 23 settembre, ovvero proprio in corrispondenza del periodo indicato) era una delle due date possibili per il turno di Zaccaria
sempre Luca ci comunica che la differenza d'età tra il Battista e Gesù era di 6 mesi
9 mesi per la nascita del Battista + 6 ancora per la nascita di Gesù: se è buona la data del 23-25 di settembre diventa plausibilissima la data del 25 dicembre.

Attenzione: si parla di plausibilità, che viene un po' meno se si considera che c'erano i pastori con il gregge: con il freddo dei luoghi intorno a dicembre, poteva essere difficile che fossero da quelle parti e pare che anche il Talmud riporti tradizioni di transumanza dalle zone della nascita di Cristo verso aree più elevate, dai primi di novembre fino a fine marzo.

Peraltro, tutte le date fornite sono relative a partire dal turno di Abia, ma ci sono due turni per ogni classe sacerdotale: l'altro turno per Abia era dal giorno 8 al giorno 14 di 5 mesi prima.

Ora, io non conosco i calendari del tempo, quindi non sono in grado di dire se 5 mesi prima corrispondano agli attuali 5 mesi prima (ovvero, non fine dicembre, ma, presumibilmente, fine agosto decisamente più plausibile per le pecore), ma è importante notare che esiste questa alternativa.

Il difetto di questa alternativa è che non coincide con nessuna tradizione storica, mentre la data del 25 dicembre fa filotto con una serie di date utilizzate dalle varie chiese cristiane fin dai primi secoli e, tutto sommato, il solo freddo del gregge è un elemento di dubbio non così logicamente stringente: avrebbero potuto esserci greggi e pastori, eventualmente al coperto: non è in contraddizione con altre esperienze di allevamenti in altre zone del globo.

Veniamo alla questione dell'anno.
Partiamo col ricordare che il calcolo su cui si basa il nostro conteggio delle date, dovuto al monaco Dionigi il Piccolo, risale al 525 d.C., ma solo dal VIII secolo è stata adottata in Europa. Per curiosità, già che siamo qui, ricordiamo che l'anno zero non esiste, ma si parte da 1, per il semplice motivo che... il numero zero viene introdotto nel XIII secolo, prima non era noto!!!

Questo calcolo di Dionigi è stato ritenuto errato fin dal 1500.

Anche riguardo alle frasi di Luca, esistono dei problemi. Infatti, sia Matteo che Luca sono d'accordo nel dire che Gesù è nato sotto Erode il Grande, ma:

dalle Antichità Giudaiche di Giuseppe Flavio e da altre fonti si sa che Erode sarebbe morto nel 4 a.C., mentre lo stesso Giuseppe Flavio cita solo un censimento, nel 6-7 d.C. (11 anni di differenza)
Quirino non era governatore della Siria nell'anno 1 d.C. (ma lo è stato, molto probabilmente, tra il 4 e l'1 a.C. e certamente una seconda volta nel 6-7 d.C.).

Le presunte inconsistenze si spiegherebbero con le seguenti considerazioni:

il calcolo di Dionigi dell'anno 1 è errato
essendo l'anno di morte di Erode il 4 a.C., considerando la sua richiesta (riportata, peraltro, solo dal Vangelo di Matteo, 2,16, ma assolutamente coerente con il personaggio storico di Erode il Grande e plausibilmente non riportata in altre cronache dell'epoca, in quanto evento secondario, per dimensioni - 20/30 bambini -, rispetto ad altri eccidi dello stesso periodo, anche dovuti allo stesso Erode), alla base della Strage degli Innocenti, di uccidere i bambini sotto i due anni, la data di nascita di Gesù potrebbe essere spostata a prima del 6 a.C.
i tipi di censimento all'interno dell'impero romano erano diversi, quello citato da Giuseppe Flavio veniva effettuato ogni 14 anni (i censimenti, ai tempi, venivano effettuati non solo per conteggiare la popolazione, ma anche per determinare le tasse).
quindi, oltre a quello citato nel 6 d.C., ce ne doveva essere stato un altro, non riportato esplicitamente da Giuseppe Flavio, tra il 7-8 a.C., che potrebbe ben essere quello registrato da Cesare Augusto in Res Gestae 8:

Poi feci un secondo censimento con potere consolare, senza collega, sotto il consolato di Gaio Censorio e Gaio Asinio, e in questo censimento furono registrati quattromilioni e duecentotrentamila cittadini romani.
Nel 9-8 a.C.,nella zona erano governatori Saturnino e Volumnio. A Volumnio successe Varo. In questo periodo Quirino era legato in Galazia. Ai tempi di Augusto, al legato di Siria si doveva rivolgere il procuratore della Giudea. Quirino era anche nella posizione di ricoprire, temporaneamente, la carica di Governatore, durante la successione da Volumnio a Varo, nel caso, per esempio, in cui Saturnino fosse in spedizione bellica.
Ai tempi i censimenti duravano fino a 2 anni, per le difficoltà di spostamento. Quindi una data plausibile, che rispetti tutti i vincoli, è tra l'8 ed il 6 a.C.

Notiamo che l'anno 7 a.C., quello in cui sarebbero avvenute le congiunzioni planetarie secondo Keplero, sarebbe assolutamente compatibile con quanto appena individuato.

Secondo la Scuola esegetica di Madrid, peraltro, non ci sarebbe neppure bisogno di ipotizzare una sostituzione temporanea di Saturnino da parte di Quirino (punto debole della precedente serie di considerazioni, in quanto, pur possibile, non sarebbe sostenibile con effettiva documentazione storica - mancante, non discorde) consisterebbe in una errata traduzione al greco dalle fonti originali in aramaico e la frase di Luca andrebbe riletta come:
Questo censimento fu antecedente rispetto a quello tenutosi quando Quirino era governatore di Siria.

Non possiamo, infine, ovviamente, scartare l'ipotesi di un errore di Luca: 'governatore' al posto che 'legato' o 'Quirino' al posto di 'Saturnino' o simili. Non sarebbe impossibile (e non sarebbe contrario a quanto espresso nella Dei Verbum, per la cui interpretazione vi rimando, per esempio, a questo testo rivolto alla formazione dei catechisti).

Semplicemente, prima di accettare l'ipotesi dell'errore conviene prima verificare se non possa essere corretto quanto scrive (cosa possibile, per quanto sopra riportato, quindi non ci sarebbe bisogno di ipotizzare errori).

Ricapitolando: porre la data di nascita di Cristo tra l'8 ed il 6 a.C., (con il 7 a.C. più probabile per diversi motivi), non lascerebbe incongruenze storiche; il periodo dell'anno si gioca tra agosto-settembre o, sorprendentemente e secondo ricerche molto recenti, intorno al 25 dicembre.

Andavano tutti a farsi registrare, ciascuno nella sua città. Anche Giuseppe, che era della casa e della famiglia di Davide,

Notiamo che Giuseppe viene indicato citando Davide, per evidenziare la discendenza regale di Cristo, motivo per cui compare nelle genealogie di Luca e Matteo.

dalla città di Nàzaret e dalla Galilea salì in Giudea alla città di Davide,
chiamata Betlemme,

Quindi, Giuseppe vive a Nazaret (Galilea), ma si deve spostare a Betlemme (Giudea). Dal Vangelo di Matteo si legge anche che, dopo la fuga in Egitto, Giuseppe decide di fermarsi a Nazaret. Quindi, da Nazaret parte, va a Betlemme, fugge in Egitto, a Nazaret ritorna.
Ci soffermiamo su questo punto solo per far notare come la spiegazione del come Cristo sia nato a Betlemme (rispettando le scritture) e poi sia stato chiamato Galileo e Nazareno (a parte ulteriori significati possibili di Nazareno, che non staremo qui ad approfondire), siano chiaramente spiegati nei Vangeli: di fronte a questa chiarezza ed evidenza si resta sempre stupiti quando taluni presunti "esperti" avanzano dubbi interpretativi a questo proposito, dicendo che esistono incongruenze.
Il tutto, a volte, pure partendo dal Vangelo di Giovanni (7,41-42), nel quale vengono riportati i dubbi della folla sull'origine di Gesù:

Altri invece dicevano: "Il Cristo viene forse dalla Galilea? Non dice forse la
Scrittura che il Cristo verrà dalla stirpe di Davide e da Betlemme, il villaggio
di Davide?". E nacque dissenso tra la gente riguardo a lui.

Ma Giovanni non si esprime in modo contrario (sarebbe stato perlomeno strano, dal momento che credeva fortemente che Cristo fosse Dio - non avrebbe messo in dubbio nè la sua origine, nè le scritture) e parla chiaramente della "gente", non esprime (non qui, almeno: altrove - che so, nel prologo - è molto esplicito) ciò in cui lui crede.

Torniamo a Luca:

per farsi registrare insieme con Maria sua sposa, che era incinta. Ora, mentre
si trovavano in quel luogo, si compirono per lei i giorni del parto. Diede alla
luce il suo figlio primogenito,

Qui è necessaria una piccolissima divagazione, perchè questa parola "primogenito" è continuo oggetto di fraintendimenti (un po' come quando si discute dei fratelli di Gesù): "primogenito" è un termine legale (al primo nato spettavano particolari diritti [Dt 21,15-17] e i genitori dovevano presentarlo al tempio e pagare un "riscatto", secondo [Num. 18,15] come spiegato approfonditamente da questa fonte ebraica), non indica il primo di n figli. Ci sono moltissimi esempi nella Bibbia, ma mi sembra significativo un esempio extra-Bibbia: nel 1922 è stata scoperata una iscrizione greca in un cimitero giudaico in Egitto, del V sec. a.C. che dice:

"La sorte mi condusse al termine della vita nel dolore del parto del mio primogenito figlio".

Per semplice logica questo "primogenito" era senza dubbio anche "unigenito" e, quindi, questa frase mostra una volta per tutte come tale termine venisse utilizzato anche nel caso di figli unici.

lo avvolse in fasce e lo depose in una mangiatoia, perché non c'era posto per
loro nell'albergo.

Gesù viene quindi deposto in una mangiatoia, di cui non vengono forniti particolari descrittivi, avvolto in fasce. Non c'era posto nell'albergo, non è che non potessero permetterselo.
Giuseppe, anzi, era un carpentiere e poteva essere anche benestante, secondo alcuni.

Non si parla, almeno non esplicitamente, nè di grotta, nè di stalla, anche se la stalla potrebbe essere indotta dalla presenza di una mangiatoia.

Le prime indicazioni della grotta si hanno in da Giustino (155-160 d.C.) in uno scritto indirizzato all'ebreo Trifone, accompagnate da dettagli che indicavano la grotta del parto.
La tradizione cristiana riprende da Origene (Contra Celsum - 248 d.C.) il fatto che si tratti di una grotta:

A proposito della nascita di Gesù... se qualcuno dopo il vaticinio di Michea, e la storia scritta nel Vangelo dai discepoli di Gesù, desidera altre prove sappia che si mostra a Betlemme la caverna nella quale è nato, e nella caverna la mangiatoia dove fu avvolto in fasce. E quello che si mostra è così conosciuto in questi luoghi, che anche gli estranei sanno come Gesù è nato in una grotta.

La stessa grotta è stata descritta da San Girolamo intorno al 400 d.C.

Quella grotta esiste ancora e la si può visitare. Era vicina al caravanserraglio (con il quale molti identificano l'albergo di Luca) e presenta pure una mangiatoia nel muro. Purtroppo, probabilmente non è la mangiatoia originale, pur essendo nello stesso punto di quella originale.
Grotte simili erano, quindi, usate anche come stalle, oltre che come ricovero per i viandanti.

Alcuni evidenziano una presunta contraddizione tra la casa citata in Matteo e questa tradizione della grotta.
La contraddizione viene aumentata aggiungendo, arbitrariamente (nella mia piccolissima esperienza, dentro e fuori dal Web, di argomenti legati all'interpretazione del Vangelo, non ho mai visto citare altre fonti oltre al Vangelo di Matteo, che, però, non ne parla) che la casa era di proprietà di Giuseppe.
Personalmente fatico a vedere una contraddizione seria tra 'casa' e 'ricovero momentaneo' (sarà che, con 15 traslochi nei primi 30 anni di vita, chiamare 'casa' una foresteria non mi è mai sembrato strano), soprattutto nel contesto considerato e dopo che si elimina l'invenzione della proprietà della casa di Giuseppe. Strano, inoltre, che abbia visto questa obiezione citata solo da commentatori minori (anche autodidatti...) e mai in esegeti, pur protestanti o non credenti, di un certo livello...

Di grotta e stalla, entrambe e distinte, per non farsi mancare nulla, nel solito tentativo di superare le difficoltà dei testi canonici, parla, invece, l'apocrifo di pseudo-Matteo:

l'angelo ordinò di fermare il giumento, [...] e di entrare in una grotta sotto una caverna. Qui generò un maschio, circondata dagli angeli mentre nasceva [...] Tre giorni dopo la nascita del Signore nostro Gesù Cristo, la beatissima Maria uscì dalla grotta ed entrò in una stalla, depose il bambino in una mangiatoia, ove il bue e l'asino l'adorarono.

Come ha fatto notare monsignor Ravasi su Avvenire, pochi giorni fa, è con lo pseudo-Matteo sopra citato che vengono introdotti bue ed asino, ma già nel IV secolo l’arte li aveva presentati nel sarcofago romano del "Museo Pio" e in quello di "Stilicone" della Basilica di Sant’Ambrogio a Milano e già Origene nel III secolo rimandava al passo di Isaia 1,3 (Il bue conosce il proprietario e l'asino la greppia del padrone, ma Israele non conosce e il mio popolo non comprende) con lo scopo, evidenziato anche dalla Wikipedia, di ricordare"il popolo ebreo e chi non ha riconosciuto la venuta del Messia, a differenza dei pastori e dei Magi."

C'erano in quella regione alcuni pastori che vegliavano di notte facendo la
guardia al loro gregge.

Ok anche per i pastori ed il gregge, ne abbiamo parlato prima. Restano aperte le possibilità che si fosse in agosto-settembre (più probabile) o che si fosse in dicembre e ci fossero comunque le pecore (difficile, ma non impossibile).

Resta la questione degli angeli. Non pretendo di verificarne storicamente la presenza, la cito solo per completare il ricordo, con scopo più di supporto alla costruzione di un presepe che altro.

Un angelo del Signore si presentò davanti a loro e la gloria del Signore li avvolse di luce. Essi furono presi da grande spavento, ma l'angelo disse loro: "Non temete, ecco vi annunzio una grande gioia, che sarà di tutto il popolo: oggi vi è nato nella città di Davide un salvatore, che è il Cristo Signore. Questo per voi il segno: troverete un bambino avvolto in fasce, che giace in una mangiatoia. [...] E subito apparve con l'angelo una moltitudine dell'esercito celeste [...] Appena gli angeli si furono allontanati per tornare al cielo, [...]

Quindi, si tratta di più angeli, anzi, di un esercito.

Se volete fare un presepe bello completo, per l'anno prossimo, vi conviene iniziare a pensarlo oggi: tra l'esercito di angeli ed il seguito dei Magi, rischiate di impiegarci un po' di tempo...

Bye

Depa

Wanted

2007-12-20T00:37:00.000+01:00

Lo cercano, lo braccano.

Me lo vedo, affannato a scappare e a nascondersi, al polo. Magari latitante a casa d'altri (probabilmente nella fortezza di ghiaccio di Superman, vicino di casa).

Sarà difficile che lo prendano: bimbi di tutto il mondo hanno provato a stare alzati la sera per coglierlo sul fatto mentre scendeva dal camino e non ci sono riusciti. E i bambini sono testardi, lo sapete.

Nonostante l'evidenza dei doni che arrivano ogni anno in tempo c'è chi inizia (si fa per dire: sono anni che su Internet gira questo testo ignomignoso, sia via e-mail che su post che, pur non spacciandola come farina del proprio sacco, non facevano nulla per evidenziare il lavoro di copiatura) a porre il tarlo del dubbio: Babbo Natale non esiste, e se esisteva è morto.
La cosiddetta dimostrazione si basa sui seguenti macro-punti:
1. difficoltà di reperire renne volanti
2. Carico di lavoro e velocità relativa sproporzionati
3. La massa da spostare, la velocità richiesta e l'attrito vaporizzerebbero mandrie di renne e conducente

Che il testo faccia acqua da tutte le parti è già accennato nel paragrafo di critica della voce riportata della Nonciclopedia, ma sembra fondamentale affrontare la questione seriamente e più approfonditamente, perchè non è accettabile che si possa trattare così una persona anziana, che non fa altro che il suo lavoro e non disturba neppure.
Vorrei vedere come ci rimarreste voi, se qualcuno dicesse che non esistete solo perchè sul mio blog non vedo gli hits.
E finchè non vi vedo, sono autorizzato a pensare che il mondo sia popolato da una ventina di persone.

Nessuna specie conosciuta di renna può volare, d'accordo.
Ma possiamo dire che conosciamo le renne di Babbo Natale? Qualcuno ha delle foto? No, ovviamente, e non perchè si sono vaporizzate, (ci torniamo dopo), ma solo perchè stiamo parlando di professionisti, che non si fanno beccare così facilmente.

I calcoli sui tempi a disposizione per le diverse azioni richieste a Babbo Natale non li ho controllati, ma mi sembrano plausibili.
Sappiamo, peraltro, che, per chi si avvicina alla velocità della luce, il tempo si dilata. Il suo minuto sarà lunghissimo, rapportato ai nostri, ma per lui resterà sempre un minuto. Quindi la relatività sembra non essere adatta per spiegare il tutto: Babbo Natale potrebbe sì spostarsi velocemente da un posto all'altro, ma avrebbe molto meno (del suo) tempo (rispetto al nostro) a disposizione per le diverse azioni, se andasse sempre alla velocità della luce.

La soluzione si potrebbe ottenere per simmetria, però: se un essere andasse così lento, ma così lento, che potesse considerare la nostra velocità paragonabile a quella della luce, beh, ...nessuno lo ha mai provato..., ma niente di più facile che possa vedere una contrazione del tempo, al posto che dilatazione.

Il che non entra in contraddizione con la necessità di spostarsi super-velocemente da un punto all'altro: cosa c'è di meglio, dopo una bella corsa, per riposarsi un momento, che fermarsi ed andare così piano che non si può neppure immaginare quanto sia piano? Andando ad una velocità che sarebbe da moviola anche per Achille nella parte finale della gara contro la Tartaruga, potrebbe riuscire a fare tutte quelle cose, con calma, in un nostro millisecondo (non ho fatto i conti, ho buttato lì un numero, giusto per capirsi).

A nessuno sarà sfuggito che non conviene andare così piano: si riuscirebbero, paradossalmente, a fare un sacco di cose, ma si invecchierebbe in pochissimo tempo, ovvero, esattamente il contrario di chi va alla velocità della luce, che non invecchia rispetto a chi sta in coda in tangenziale (a proposito, non lamentatevi più, pensate a questo lato positivo...).

Come fa a non invecchiare di botto, Babbo Natale? Beh, facile, no? La velocità calcolata che le renne dovrebbero tenere secondo la presunta dimostrazione è ancora troppo bassa rispetto a quella della luce, ma si tratta di un calcolo della velocità minima che dovrebbero mantenere. Ma potrebbero pure andare più veloci, no? Chi glie lo vieta? E quando va così veloce, recupera il tempo perso.

Quindi, ricapitoliamo fino a qui: Babbo Natale si sposta a velocità vicina a quella della luce tra una casa e l'altra, poi rallenta di botto per fare tutte le operazioni necessarie nelle case. Le due velocità estreme (meno dello 0 assoluto e velocità della luce) si bilanciano completamente e Babbo Natale non invecchia troppo in fretta.
Il fatto che sia vecchio, comunque, fa pensare che tenda ad andare più verso il piano che verso il veloce; quindi cerca di godersela un po', di mangiarsi tutti i doni dei bambini, quindi ingrassa; torna tutto, no?

Ora: il calcolo del peso del carico e del numero delle renne della dimostrazione sembra un po' forzato e basato su ipotesi non immediatamente condivisibili. Infatti:

è noto che le renne di Babbo Natale sono effettivamente 8 (non 9 come ipotizza il testo ad un certo punto, ma solo 8: la slitta sarebbe sbilanciata con un numero di renne dispari), tanto che ne sappiamo pure i nomi: Dasher, Dancer, Prancer, Vixen, Comet, Cupid, Donder, Blitzen. [Questo implica una sorta di avvistamento o una fuga di notizie: credo da parte di qualche elfo, ma non insisterei troppo su questa storia delle fonti, non vorrei spaventare i nostri informatori, che talvolta vengono usati anche per cancellare qualche marachella dal registro di Babbo Natale, per riuscire ad essere tra i buoni, ogni tanto]
questo porta a dire che il calcolo del peso, pur corretto a prima vista, debba essere in qualche modo "pesato" (matematicamente parlando e scusate il gioco di parole assolutamente cercato) in modo diverso
il tutto è anche indotto da un'altra considerazione banale: la scatola di Lego cui si fa riferimento, del peso di 1Kg, ha anche una dimensione di qualche decina di centimetri per lato. Non conosco le misure esatte, ma è evidente che, prima del problema del peso, bisognerebbe considerare il problema dell'ingombro e quello di non far cadere questi pacchi fuori dalla slitta.
eppure questi regali arrivano, quindi non cadono dalla slitta e neppure caricano di un peso così elevato le renne
tanto più che, nell'ipotesi sopra riportata di velocità vicine a quella della luce, mentre il tempo si restringe, la massa aumenta e basta un peso infinitesimo a velocità normale, per avere un peso infinito a velocità della luce (cosa che, secondo alcuni, creerebbe un'inerzia così elevata da rallentare la massa quel tanto da non farla arrivare mai alla velocità della luce; e, infatti, il fotone non ha massa, etc. etc.)

Date tutte queste premesse, basta cercare un modo per trasportare una massa così enorme in modo molto semplice. Il che ci fa venire in mente immediatamente almeno due soluzioni (non possiamo escludere che ce ne siano altre, ma di queste abbiamo ampia documentazione, scritta e filmata, alla faccia del CICAP):

la borsa di Mary Poppins
le tasche di Eta Beta

Non credo che sia possibile discutere: sappiamo bene tutti che entrambe queste soluzioni permettono di trasportare senza alcuna difficoltà quantità enormi di oggetti. Evidentemente, per affinità, sarei per sostenere l'ipotesi che il sacco di Babbo Natale si avvicini più alla borsa di Mary Poppins, che alle tasche di Eta Beta. Inutile, in questa sede, scendere in spiegazioni scientifiche oramai di pubblico dominio (dimensioni parallele, l'altro lato del buco nero, etc. etc.) e che potrebbero, semmai, essere oggetto di altri approfondimenti.

Quindi: il carico apparente è quello riportato dalla dimostrazione, ma quello effettivo è molto inferiore, stimabile, a occhio, intorno ai 20Kg massimo.

Il che ci permetterebbe di avere ancora dei dubbi sulla possibilità di avvicinarci alla velocità della luce. Senza contare che, ben prima di quella velocità, le renne si dovrebbero vaporizzare comunque.

Se non fosse per un fatto banale, che sembra sfuggire agli autori dell'abominevole trattato: dove vive Babbo Natale? Al polo. E cosa vive al polo? le foche (anche altri animali, ma ci servono le foche, ora). E cosa si estrae dalle foche? Il grasso di foca. Ovvio: è una delle cose più adatte per ridurre l'attrito, molto molto usato da chiunque viaggi a velocità della luce, per ridurre significativamente i rischi di vaporizzazione. Non basta. Cosa succede quando stai per vaporizzarti? Cresce enormemente la temperatura. Proprio qui vi volevo: perchè credete che parta dal polo, con tutti quei ghiacci e quel freddo?
Non basta ancora. Come ridurre la crescita della massa ad altissima velocità? Non si riduce, quello che resta dell'effetto vaporizzazione, che aumenta con la velocità, riduce la massa che pure aumenta con la velocità, mantenendo stabile il sistema e dando torto a chi fa quei ragionamenti errati che ho riportato sopra riguardanti l'inerzia che cresce al crescere della velocità: quindi, si arriva alla velocità della luce con la stessa massa con cui si era partiti.

Il Presidente (ma sì che ve lo ricordate, è proprio quello citato in un precedente post) che per primo, pur in disaccordo con la dimostrazione medesima, mi ha girato la dimostrazione della non esistenza di Babbo Natale, mi ha fatto notare che - cito - l'iconografia natalizia relativa alla partenza e durante la parte visibile del volo (in effetti occhio umano non può percepire oggetti volanti prossimi alla velocità della luce) vengano emesse scie di stelline, per lo più dai pattini e dagli zoccoli delle renne. Questi in effetti toccando suolo potrebbero avere perso parte della protezione del grasso di foca. Le stelline sembrerebbero essere massa vaporizzata, nota angli esperti come plasma ionizzato, da cui la loro luminescenza.

Spero di essere stato abbastanza chiaro, nonostante l'evidente complessità degli argomenti trattati.

Fossi in voi (quelli sobri, intendo), prima di chiudere sarei indotto ad una o tutte le seguenti osservazioni:

il pusher del Depa fornisce roba proprio buona
per scrivere tutta quella roba bisogna averne, di tempo da buttare, la prossima volta che si lamenta di essere pieno di lavoro...
si potrebbe sprecare inutilmente tempo in almeno una decina di modi più interessanti, compresa la catalogazione delle malattie dei lombrichi
il Depa fa parte dell'ufficio stampa di Babbo Natale e il pezzo lo ha scritto con cognizione di causa (che sia proprio lui l'elfo informatore?)
oramai tutte quelle ore sveglio al computer stanno facendo il loro effetto, la va a pochi...
il Depa avrebbe fatto meglio a fare l'avvocato, al posto che l'ingegnere (sia per le capacità di difesa che per la scarsità di competenze tecnico/scientifiche)
tutto quel tempo perso per scrivere un sacco di cavolate: è evidente che non c'è bisogno di ricorrere alla teoria della relatività per spiegare il tutto, quando è sotto gli occhi di chiunque il fatto (perchè di fatto si tratta) che:
- di Babbo Natale c'è n'è più di uno
- pur essendo in tanti, partono pure prima del tempo
- non sono invisibili, nè super-veloci, anche se sono molto furbi: si fanno passare per addobbi natalizi che ricordano (con ironia, pure, pensate all'umorismo dietro questa palese presa in giro!!) Babbo Natale (a volte anche in cordata, a sottolineare ancora più il loro spregio alla nostra intelligenza) calati giù dai balconi e dai tetti
non si può conoscere nulla e possiamo solo sapere di non sapere, etc. etc.
...

Vi risparmio il resto, siamo quasi sotto Natale, siamo tutti un po' più buoni.

Resto, comunque, a disposizione per eventuali approfondimenti, non lasciatevi ingannare da falsi ragionamenti: Babbo Natale è vivo e sta bene.

Bye

DepaP.S.: Potrei prendere un Nobel per i contenuti scientifici di questo post, ma non fatene troppa pubblicità, ve ne prego, perchè nel periodo in cui consegnano i Nobel avrei intenzione di andare in ferie.

Libbertà

2007-12-15T22:20:00.000+01:00

Quanno m’accorsi d’esse prigioniero
Cor laccio ar piede in mano a un regazzino
Non c’ebbi che n’pensiero, de rivolà in giardino
[Er grillo zoppo - Trilussa]

Una volta, purtroppo, era più facile definire cosa fosse la libertà.
Forse perchè, quando si ha un piede straniero sopra il cuore, il peso si sente anche senza stare a pensarci.
Poi la situazione è migliorata e si è potuto distinguere tra la libertà da (beneficiario un popolo) e la libertà di (beneficiario il singolo).

Ci sta una libertà anche un po' più egoistica, un po' meno quando si usa lo stesso termine per scopi marketing, o per gridare il diritto di poter fotografare la privacy altrui, o per difendere la libertà di opprimere.

Tra gli estremi si posiziona, a mio modo di vedere, il software libero.

Il che ci riconduce (con un salto triplo degno del peggior telegiornalista che cerca di passare da un crudo fatto di cronaca nera alla rubrica settimanale di gastronomia) alla fine del post precedente, in cui accennavo al modello di business di un software libero come Daz Studio.

Ricordate che vi avevo minacciati di parlare di licenze Open Source e modelli di business?
Ricordate il finale di Hotel California, You can check out any time you like, but you can never leave? Fino a che punto siete veramente liberi di non cliccare sul link Leggi Tutto?

Credete che io possa riuscire mai ad annichilire ulteriormente la mia già scarsa immagine di scrittore, continuando con queste penosissime introduzioni?

Ricorderete certamente (non metto il link al post precedente perchè dovreste vergognarvi anche al solo pensiero di scherzare sulla possibilità di non averlo ancora letto) che il modello di business di Daz Studio e compagnia bella si basa sulla rivendita di modelli grafici 3D pre-realizzati (più o meno come qualche altro migliaio di siti di grafica, con la differenza che, essendosi creati loro il programma sono in vantaggio, perchè posseggono un forte catalizzatore e una forte leva marketing).

Diventa interessante, confrontarlo, molto brevissimamente, con altri modelli di business basati sull'Open Source (free as freedom, not price, ci rammentano fin da piccoli dalla Free Software Foundation (FSF)):

pubblicità/marketing (personale e per terzi - sempre basato sui grandi numeri)
consulenza/servizi/corsi sui propri ed altri prodotti (cross-selling, tenendo presente che, con l'Open Source si abilitano alcuni mercati - es.: le linee strategiche per l'e-government prevedono, al punto 6, un incremento la diffusione e la utilizzazione di soluzioni Open Source e da tempo esiste un osservatorio Open Source; per certi versi è come se l'Open Source venga a costituire una sorta di certificazione, simile a quelle della qualità - su quest'onda nasce il marchietto dell'OSI, che si propone internazionalmente per censire le varie licenze open source). Tra i vari modi di far pagare i servizi trovo interessante la proposta di proporre un supporto a contributo volontario, che potrebbe anche portare ad uno sviluppo Open Source ben più orientato e goal-driven (variante come minimo da indagare, direi - l'ho vista usare, almeno, da ATutor, un sistema per l'e-learning basato su GPL) [Consulting e Subscription Strategy]
dual licencing: per scopi commerciali, una licenza commerciale affianca quella open (così si 'vende' anche il prodotto e non solo i servizi collegati, da un lato risparmiando in marketing e sulla rete commerciale, rispetto ad un prodotto 'classico') [Dual Licence Strategy]
vendita di estensioni, moduli o, comunque, feature a valore aggiunto non presenti nella parte Open Source del prodotto (up-selling); facilitato dalla natura elettronico/informatica (non fisica) del prodotto
vendita di accessori o prodotti correlati: non solo libri, manuali e CD sull'argomento, ma anche magliette, tazze ed altri accessori di questo tipo
supporto volontario al servizio (particolarmente efficace per servizi di altissimo livello e con grandissimo seguito come quelli forniti da Sourceforge o dalla Wikipedia)

Casomai dovesse interessarvi approfondire questo primo riassunto, sopra, tra parentesi quadre ho indicato nomi di strategie utilizzati in un bellissimo (anche se un po' datato) articolo di IT Manager's Journal, che aggiunge anche le strategie di Optimization, Patronage, Hosted ed Embedded, decisamente più adatte (soprattutto la seconda) ad aziende di una certa dimensione e brand. Se vi avanza tempo, potrebbe interessarvi anche la presentazione di Tim O'Reilly relativa ai design pattern nei business model Open Source (non così fondamentale come altri testi dello stesso autore, peraltro).

Di fatto, il modello di business utilizzato da Daz si configura quasi come una vendita di estensioni: solo, mentre i moduli aggiuntivi di un prodotto si venderanno a pochi clienti selezionati, con costi relativamente elevati, le estensioni di questo tipo avranno come target la massa e potranno mantenere un prezzo basso.

Da notare che una variante interessante (non facilissima da applicare a prodotti impalpabili come quelli informatici e, in particolare ai modelli grafici, almeno in prima istanza) può essere quella di far leva sulla mania di collezionismo: si comprano pacchetti chiusi e si trovano, con diversa probabilità, oggetti 'confezionati' randomicamente (per chi avesse giocato a Magic the Gatheringo simili dovrebbe essere molto chiaro). Non ho esempi a questo proposito, non ne ho trovati, se ne conoscente segnalatemeli.

Con un modello di business basato sulla vendita di gadget o librerie, si evita pure il problema che mi sta capitando nel cercare di trovare un modo di affibbiare ad un mio sistema una licenza Open Source GPL v3 (la GPL è la licenza che più di tutte permette di supportare il dual licencing affiancando una licenza commerciale ad una Open Source e la versione 3 è particolarmente interessante per la compatibilità con altre licenze libere, Apache 2.0 in particolare e per la protezione nei confronti di chi volesse tentare di imporre eventuali brevetti su quanto è stato realizzato).

Forse vi sto per dire una banalità e vi annoierete (ma spero, invece, che vi cada la mascella per lo stupore come è capitato a me), ma mi è recentemente capitato di notare con disappunto che, sotto certe condizioni e pur utilizzando parti di software libero, è più facile rilasciare un prodotto software con una licenza commerciale che con la GPL.

Infatti le licenze, anche quelle libere, in quanto oggetti legali possono essere incompatibili tra loro, come ci ricordano i tipi della GNU (abbastanza ovviamente il link precedente è un approfondimento GPL-centrico: sarebbe interessante avere una sorta di matrice, tra le licenze più diffuse, ma non l'ho trovata).

Lo stupore cresce quando vi accorgete che le licenze di SUN non sono compatibili con la GPL.

Lo ridico in un altro modo: Java (di SUN - spiego dopo questa apparentemente curiosa precisazione) e GPL (fino al 13/11/2007) non potevano convivere.

Lo ridico ancora: Stallman si è espresso almeno due volte a proposito di quella che lui chiama Java Trap, tra il 2004 ed il 2006, evidenziando come programmi basati su Java (di SUN) non possano essere legalmente anche licenziati con la GPL.

Perchè la precisazione di prima (Java di SUN)? ne esistono altre? Certo, Java come specifica non pone vincoli, li pone la licenza con cui viene rilasciata l'implementazione. E la licenza di SUN, per quanto riconosciuta dalla fsf come libera, non è compatibile con GPL.

Le implementazioni alternative sono almeno 2: GNU Classpath, suggerito da Stallman ed il più recente Apache Harmony. Essendo implementazioni basate su licenze Open Source compatibili con la GPL, se riuscite a compilare il vostro sistema usando le loro librerie e compilatori, ok, siete salvi, potete rilasciare il vostro programma Java sotto GPL.

Purtroppo, allo stato attuale, sono implementazioni ancora parziali (per fare un esempio, il mio sistema non è ancora compilabile con questi due pacchetti - sto verificando come sostituire i metodi non implementati con altri, ma devo ancora capire bene se il gioco valga la candela).

Una breve parentesi: GNU Classpath si ferma alle specifiche della JDK 1.4, mentre Apache Harmony parte dalla compatibilità con la 1.5. Vedete voi cosa più vi serve (spero per voi che sia la 1.5 o la 1.6, ovviamente).
Inoltre con Apache Harmony potete farci sostanzialmente ciò che vi pare (licenza Apache 2.0), compreso commercializzare il vostro prodotto; con GNU Classpath, invece, non ne sono sicurissimo (il testo è ambiguo, la spiegazione sembra più possibilista - se riuscite a capirlo voi, con un ragionevole livello di certezza, fatemi un fischio): si basa su GPL (quindi, tutto ciò che tocca dovrebbe diventare GPL), ma con una eccezione che permette di linkare altri moduli, senza farli diventare GPL.

Certamente, lo so, l'ho detto prima, è inutile che continuiate a bisbigliare: esiste un'altra possibilità, dal 13/11/2007 Java è stato annunciato con licenza GPL (qualche commento di Goslin a questo proposito). Ne hanno parlato tutti, ci mancherebbe altro che fosse sfuggito un particolare così importante.

Purtroppo, almeno per i miei scopi, non va mica tanto bene. La scelta di SUN riguarda la licenza GPL v2, non la GPL v3. Ci sono, almeno, le seguenti controindicazioni:
- GPL v2 e GPL v3 sono incompatibili tra loro: quindi, tutta la parte relativa ai brevetti non sarebbe applicabile
- molto peggio, GPL V2 e licenza Apache non sono compatibili tra loro (mentre GPL v3 e Apache, sì): quindi non potrei utilizzare, nel mio sistema, tutte quelle belle librerie che uso
- ancora peggio: usando Java licenziato GPL v2 il vostro sistema diventerebbe GPL v2 anche lui e non sarebbe applicabile il dual licencing con licenza commerciale, non essendo il primo della cordata

Acc.... ma scusate, non ci sono programmi Java licenziati sotto GPL?
E come fanno? Ricevono lettere di cause dalla FSF in continuazione?
O so basano su zone grigie di interpretazione (tipo quella per cui, secondo l'Apache Foundation già la GPLv2 era compatibile con la licenza Apache 2.0, mentre secondo la FSF no)?

Vi devo chiedere di smetterla di deviare continuamente in parentesi inutili, e di cercare di concentrarvi sul punto fondamentale: come faccio a risolvere il mio problema?

Con lincenze BSD o MPL? No, troppo libere, io sono uno di quelli che 'non sopportano l'idea che altri possano vendere il mio sistema': anche un commerciale normodotato (cosa che io non sono, io sono la versione seria del signor Spock di Star Trek) potrebbe piazzare nel tempo libero il mio sistema e questo non mi potrebbe mai andare giù, dopo i miei inutili tentativi.
Prendendo spunto dalla GPL e aggiungendo varianti che permettano l'uso di librerie free? No, potrebbe essere complesso, non sono un legale, diventa un casino, ci vuole un attimo a sbagliarsi e a renderla troppo o troppo poco flessibile (pensate solo a quanto tempo e risorse ci hanno messo a variare la GPLv2 per farla diventare GPLv3).

Queste cose le dico per voi, per evitare che vi troviate con un bellissimo sistema (il più bello di tutti, ovviamente), basato su librerie Open Source, senza poter sfruttare la distribuzione free, perchè potreste rischiare di infrangere una o più delle licenze.
Non voglio che rischiate di dover rivedere le librerie di base del vostro sistema e di dover adattare parti del codice con ulteriore effort, a fronte di nessuna aggiunta in funzionalità (ulteriori costi, per voi), solo perchè non siete stati abbastanza lungimiranti all'inizio del progetto.
Non voglio rischiare io di rompermi le balle a leggere un lamento lungo un post sul vostro blog, scritto per sfogare il vostro disappunto e per chiedere inutilmente a Stallman e compagni se non sia il caso di ripensare un po' i vincoli della libertà, come già suggerito diverso tempo fa dallo stesso poeta con cui abbiamo iniziato questo post:

La libbertà [...]
se c'è chi la guida e la riduce
e l'incanala verso l'officina,
appena arriva smove la turbina,
diventa forza e se trasforma in luce.
[...]
Ma quanno l'acqua ha smosso ner cammino
una centrale elettrica o un mulino,
se canta o se barbotta, nun è male
lassaje un pò de sfogo naturale!
[La libbertà - Trilussa]

Bye

DepaP.S.: le mie scuse a Trilussa, per la leggera forzatura ed anacronismo dell'ultima citazione. Non credo di averne invertito o travisato completamente il senso, ma sono conscio di averlo allontantato un po' dall'originale intenzione.
P.P.S.: a Stallman e compagni: tranquilli, non sentitevi in obbligo di affrettarvi con un commento a questo post, la risposta la capisco da solo e comprendo la posizione, anche se la condivido solo parzialmente.
P.P.P.S.: prometto che smetto, ma non potevo non ricordare anche questa strofa, perchè su questo argomento non può che farmi bene anche un po' di autocritica:
La libertà non è star sopra un albero,
non è neanche il volo di un moscone,
la libertà non è uno spazio libero,
libertà è partecipazione
[La libertà - Gaber]

Come un bambino

2007-11-27T00:47:00.000+01:00

Come un bambino ho iniziato e come un bambino mi sono velocemente annoiato.

Avete mai provato a cercare su Internet un presepe in grafica 3D (meglio se navigabile - e esageriamo? - con i personaggi che si muovono, l'acqua che scorre etc. etc.), da installare sul PC?
Beh, io non sono riuscito a trovarne neppure uno.

Ma se non ti arrendi al primo ostacolo, il minimo che puoi fare è provare a vedere se riesci a farlo tu (per giocare, non come attività commerciale).
Voglio dire: ci sarà pure un programma (free, ovviamente!), per quanto elementare, che sia in grado di stilizzare delle figure che, almeno da lontano, sembrino umane e poi sia in grado di scambiarle con altri programmi in grado di fare il resto del paesaggio, - lasciamo stare le animazioni etc. etc. per il momento. No?

Beh, sì e no.
No: non c'è un (solo) programma che in grado di stilizzare figure che sembrino umane almeno da lontano.
Sì: ce ne sono diversi in grado di modellarne che sembrino umane anche da vicino.
E anche con le animazioni.

Vi anticipo il finale, rovinandovi la sorpresa e la voglia di continuare: come nella più dozzinale commedia di Hollywood, non ci si può esimere dalla considerazione che un presepe vero è molto meglio, che serve arte, spirito e fuoco, non bit.

Ai pochi che saranno ancora interessati suggerirei di non escludere a priori che nel corpo del post si possano approfondire alcuni aspetti dei programmi sopra citati.

La ricerca di programmi per animazioni di modelli umani può riservare delle sorprese e fornire una vaga idea di come potrebbero essere quelli usati per realizzare film di successo.

L'occhio di Google cade subito su MakeHuman (plugin di Blender) e DAZ Studio.
Li ho trovati in questo ordine e mi sono fiondato sul primo, ben sapendo che Blender è un prodotto Open Source di altissimo livello. Una volta ho pure provato ad impararlo, ma ha una plancia comandi che neppure l'Enterprise e certamente io non sono un artista tale da giustificare uno sforzo di qualche giorno per iniziare a fare qualche scena in 3D: l'ho tenuto installato e poi mi sono limitato ad un decisamente più semplice e comunque per me più che adeguato anim8or.

MakeHuman è impressionante. Nella documentazione si legge che per realizzarlo hanno dovuto studiare anatomia in dettaglio e c'è da credergli. Partite da una figura umana base e vi trovate a cercare di modificarla, come fosse di gomma, in ogni suo più piccolo aspetto.

Volete la bocca un po' storta, un taglietto sul labbro, le narici più larghe? Vi serve un'espressione con gli occhi un po' infossati e stanchi? Per il vostro prossimo vampiro vi serve poter decidere la lunghezza dei denti? No, oggi modello un alieno con la testa come ET...
Alcuni volti base caratteristici sono già impostati, così come alcune strutture corporee, non vi resta che applicare il modello predefinito e usarlo come base per rilavorarlo di fino.
Chiaramente volete anche che l'uomo che avete disegnato cammini, raccolga oggetti da terra, salti, cerchi di prendere a pugni qualcuno, ci mancherebbe altro. E non potete sopportare che, girando la testa, i muscoli del collo non si tendano come nella vita reale.
Potete controllare tutto e poi renderizzarlo sfruttando Blender.

Ora che ci penso... tutto no... ci sono due icone che, accidenti, sono disabilitate: si tratta di quella che permette di disegnare anche i capelli e, molto peggio, di quella che permetterà di vestire i nostri personaggi (personalmente trovo inaccettabile inserire dei personaggi nudi nel presepe, escluso, al più, Gesù bambino...).

Beh, la versione che ho provato è una 0.9, queste caratteristiche sono promesse per la 1.0.
Personalmente l'attendo con ansia e sto già iniziando a lavorare alla sceneggiatura del mio film di animazione.

Facciamo un salto anche su Daz Studio 3D.

Vi serve un attimo per capire che il sito non mostra foto, ma personaggi renderizzati.
Qui hanno lavorato più a fondo sui materiali e sulle texture della pelle, delle iridi e per rendere particolari come la screpolatura delle labbra.

Qui i personaggi (i modelli base hanno dei nomi e sono proposti come attori e star - alcuni free, altri, molto più definiti, a pagamento) possono avere capelli (che si possono allungare ed accorciare) e vestiti (anche questi si possono adattare, rendere più o meno stretti).
Sono previste espressioni e posture predefinite, basta applicarle al personaggio e non sarà necessario fargli muovere il singolo muscolo: si posizionerà come da esempio.
Una curiosità: i modelli base non sono limitati solo ad umani nel vero senso della parola, ma anche anime e manga giapponesi: se avevate sempre sospettato che quei cartoni fossero un po' troppo uguali e precisi, giocando con questo programma ne potrete avere tutte le conferme.

Essendo un prodotto con fini commerciali (almeno, più espliciti di MakeHuman, nonostante dichiari di essere Tell-ware - sono contenti se ne indicate l'esistenza ad almeno due persone: con questo articolo dovrei andare pari, almeno spero), presta anche più attenzione alla compatibilità con i formati di file di altri sistemi più noti e di più alto livello (soprattutto Poser, riferimento essenziale, a quanto pare, per questo tipo di programmi).

Molto più user-friendly di MakeHuman, risulta anche meno flessibile, un po' troppo predefinito, forse un poco più asettico: i modelli presentano meno gradi di libertà, superati dai tanti elementi aggiuntivi precotti che si possono comprare: di diverse pettinature e abiti ne abbiamo già parlato, ma si possono comprare (e da altri siti anche scaricare gratuitamente) oggetti 3D di tutti i tipi per costruire mondi per i nostri personaggi: sedie, armadi, case, scudi e armature, animali e piante, etc. etc.

Il prezzo del singolo oggetto è abbastanza basso, perchè target è la massa.

Il presepe sarebbe una nicchia di mercato scoperta? Pensateci: si potrebbero vendere personaggi digitali, pastori e pecore, alberi etc. etc. per completarlo: strano che non ci abbiano ancora pensato.

Adesso ringraziatemi, perchè vi risparmio: originariamente avevo intenzione di continuare sulla strada indicata dalle ultime due frasi ed imbastire tutto un discorso su licenze Open Source e modelli di business, (mi sarei lasciato prendere la mano, sarei leggermente uscito fuori tema, ma quando mai non lo faccio? e poi, almeno su questo blog, lo svolgimento lo decido io...), che, in questo momento, mi stanno un po' assillando; ho, invece, deciso di fermarmi qui e, udite udite, di rimandare ad altro post quest'altro argomento.

Deve essere l'effetto dell'avvicinarsi del Natale: è bastato citare il presepe e sono diventato più buono

Bye

Depa
P.S.: oltre ai programmi che gestiscono figure simil-umane, a partire da questi siti (o in questi stessi siti) si possono trovare anche programmi per realizzare paesaggi realistici ed animati (cito solo, come esempio Bryce e Terragen). Volevo ricordarvelo, ma, casomai, ne parleremo un'altra volta.
P.P.S.: per i più curiosi e giocosi, esiste anche un programma che genera volti in grafica 3D a partire da foto: si chiama FaceGen, se ne può scaricare una versione (ridotta e con scritte sopra alla testa) free.

Osservando distaccatamente babeli mediatiche

2007-11-13T23:43:00.000+01:00

Miro, osservo, imparo. Se sto in ascolto posso migliorare. Se sono aperto ai suggerimenti posso cambiare.
A volte, per ricominciare è necessario cambiare nome.

Su queste basi si presenta, pirandellianamente, il Fu Democracy Player. Nome cambiato, appunto, in Miro e proprio oggi esce dalla preview pubblica e rilascia la versione 1.0

Cambiamento non impressionante, ma significativo, al punto da indurmi a questo nuovo post dopo la stroncatura di qualche mese fa.

Due al prezzo di uno: già che siamo in argomento proviamo anche a chiederci dove sia finito il tanto annunciato Babelgum, presunto concorrente di origini italiche di Joost.

Chiedendoci sempre, se non sia meglio uscire a farsi un giro, al posto che stare davanti alla TV ed al PC contemporaneamente.
Ai tempi del mio precedente approfondimento, il tempo era clemente, invitante, i dubbi erano ridotti.

In questi giorni, invece, fa freddo e tira vento. Bisogna pure cercare di sopravvivere allo sciopero dei mezzi e cercare di tornare a casina nonostante la natura si opponga, con gli alberi che si immolano tranciando le linee del tram, finendo di mettere in ginocchio il traffico di una Milano che Milano non è, che sgomita per cercare di tornarsene sul lago, in campagna, ma anche appena fuori dalla tangenziale, ovunque purchè non in strada, ferma.

Anche davanti alla TV o al PC.

Anche i pochi che viaggiano con (uno stupendo) Le mie italiane di Pennac in una mano e la sbarra del tram nell'altra, non appena arrivati in scompartimento lo ripongono nella borsa del portatile e si mettono a parlare con notepad, per allacciare dialoghi lontani nel tempo e nello spazio, lontani dall'adesso, dall'odore di bruciato dei freni del treno.

Sperando che siano i freni del treno e non la ventola del PC rotta che sta abbrustolendo la CPU, intendo.
Scartando a priori la possibilità che a fumare sia il cervello, oramai ai minimi termini per il poco sforzo critico che ci viene lasciato.
Perchè, forse, scrivere un blog è un modo per sforzarsi di parlare e pensare e non subire solo le informazioni che ci vengono iniettate dritte nella memoria a medio-breve termine, giusto il tempo di ricordarci cosa comprare domani al supermercato, prima di svanire per lasciare il posto a ciò che certamente vorremo desiderare dopodomani.

Avete DAVVERO selezionato Leggi tutto?
Grazie mille, anche se, al vostro posto, me ne sarei andato altrove perchè l'abstract era, oggettivamente, un po' consunto, un po' già visto, piuttosto banale.

Forse pensavate che, come al solito, nel body avrei parlato d'altro.

No. Sfortuna. Stavolta si parla davvero di recensioni di player. Noioso e banale (mica posso scrivere sette pagine di roba dense come una tazza di cioccolata tutte le volte), per questo sono riuscito a pubblicarlo a pochi giorni dal post precedente, rovinandomi la recente media di 1 post al mese.

E cercheremo pure di lasciare i lamentosi pianti su noi stessi e le paranoie sull'essere controllati fuori da questo approfondimento. Se vogliamo pensare, pensiamo, non è vero che non siamo liberi di farlo, e dovremmo anche iniziare a riconoscere il trucco.
Dovremmo sapere che i consigli della regia ci porteranno inevitabilmente a volere qualcosa che non ci passava neppure per la mente fino a qualche secondo fa.
Tra i diversi modi di uscirne, se è almeno in parte ancora vero che chiodo scaccia chiodo, possiamo provare a girarci, giocare coi figli, prendere un libro, girare per Internet, fare del sesso, vivere con le persone che amiamo, chiamare un amico, cercare Dio, fare una camminata in montagna, etc. etc.

E' veramente difficile la scelta tra essere cintura nera sulle puntate dell'ultima serie del Dr. House e cercare di migliorare la propria vita?

Se trovate che sia complicato riuscirci, meglio che lasciate subito questo post, perchè siete già conciati abbastanza male per conto vostro, ma se pensate di poter stare senza TV per una settimana senza gravi effetti collaterali, ok, andate avanti, parleremo di questa cosa di cui potete fare a meno e su cui, quindi, potete ancora fare delle scelte.

Visto che si tratta di un argomento interessante, ma neanche troppo, vediamo di chiuderlo in due parole.

Finalmente:
- hanno aggiunto permalink: si può scaricare un video, ma lo si può anche vedere, intanto che si scarica (dal sito originale, via browser, non ancora in Miro stesso)
- i filmati ripartono da dove avevate smesso di guardare (io lo trovo comodo)
- le ricerche non sono più così lente e la possibilità di estendere la lista dei siti su cui cercare è interessante (come il tentativo,

che non riesce spesso, peraltro, di catturare i video anche da siti non noti)
- non rischiate più il blocco del download se, intanto che scarica, potete girare tra gli altri canali ed impostare delle ricerche
- cancellazione dei download in sospeso e memo di download in corso quando si esce (ma ci voleva tanto?)
- presenza di canali in HD (bella risoluz... ah, già, ma l'ho downloadato, non è in stream...)

Problemi:
- ancora non legge/scarica da expertvillage (se non, ovviamente, per quei video che ExpertVillage trasmette anche via YouTube)
- paginazione risultati ricerche mancante: potete vedere un max di circa 20 risultati, anche se ce ne sono centinaia.
- appena installato parte con un tocco (unità di misura tecnica, corrispondente a 15,4 badilate irlandesi) di download predefiniti (a meno che non li abbia ripresi da una non completa deinstallazione di Democracy Player)

Inizia a diventare un tool da downloadare o, almeno, da tenere sotto controllo.

Da segnalare, en-passant, il tentativo di spingere gli utenti a realizzare la propria TV.

Un invito alla non passività, come il mio, o semplicemente una spinta a creare contenuti gratuiti? Comunque sia, interessante, quindi giocateci.

Su Babelgum, invece, c'è ancora meno da dire:
- sembra la copia di Joost, con piccole differenze grafiche (il telecomando è l'unica invenzione nella GUI, ma ha veramente poche funzionalità)
- ancora pochi (quasi nulli) i gadget
- ancora troppo pochi canali
- video di qualità, a prima vista, leggermente inferiore a quella di Joost (soprattutto a full screen)
- molto veloce lo spostamento (rewind, fast forward) all'interno del filmato che si sta visualizzando.

C'è ancora un bel po' di strada da fare, a quanto sembra e, nonostante sia italiano, c'è ben poco di italiano.

Ci sarebbe Vcast, se oltre a Mediaset non lo spengono anche gli altri, ma già come superamento della TV, con il videoregistratore. Che, se non altro, mostra fantasia nell'interpretazione limite delle licenze.

Bye

Depa

CRUDeli variazioni

2007-11-08T22:55:00.000+01:00

In Centomila miliardi di poesie, Queneau prende 10 sonetti, con le stesse rime, fa una striscia per verso e li impagina come in un gioco di identikit per bambini, in modo che si possano combinare fino a produrre quanto promesso dal titolo.

Facile notare che è la struttura formale dei sonetti e le regole che Queneau si è imposto che gli permettono di raggiungere il risultato. Ed è lo stesso scrittore ad evidenziare che:
"Il classico che scrive la sua tragedia osservando un certo numero di regole che conosce è più libero del poeta che scrive quel che gli passa per la testa ed è schiavo di altre regole che ignora." [Che cosa è l'arte? - 1938 - Raymond Queneau]

Chi mi conosce sa che, se vi sto parlando di letteratura che si compone dinamicamente, in realtà, niente di più facile che stia per propinarvi quelle due righe indispensabili per l'introduzione a, che so, la generazione automatica di codice.

Chi mi conosce potrebbe pure immaginare che, se mai qualcuno potesse azzardare un assurdo paragone tra una metodologia informatica ed una medicina (cosa che mai faremo), io cercherei di portare l'attenzione sul fatto che le buone medicine vanno prese, ma meglio se dopo consultazione con uno specialista, sempre solo dopo aver ben letto le istruzioni per l'uso, capito che davvero curano il nostro male e stabilito che non contengano controindicazioni anche gravi.

Infatti, se certe regole le applica Queneau, il divertimento potrebbe anche diventare arte, ma con autori meno accorti si potrebbe rimanere fermi al generatore automatico di poesie della mutua, perdendosi anche il gusto dello scherzo.

Come spesso in altri casi, la mia vita virtuale e quella reale si confondono, si intrecciano lavoro e interventi sui blog (ancora su quello di Isadora, in un post già citato, anche se oramai un po' perso nel passato) e anche spiaggie e montagne le vedo da tempo solo renderizzate.

Non posso, invece, girarmi senza sbattere contro qualche progetto che si basa sulla generazione automatica di codice.

Dopo 8-10 volte, dopo aver escluso di essere coinvolto in una candid camera, mi ha sfiorato il dubbio che il senso di dejavu fosse accompato anche da un senso di disagio, dalla domanda se e quando questo processo nel mio passato si sia dimostrato effettivamente parte di una metodologia produttiva o fosse solo un modo di automatizzare il cut&paste (da non intendersi necessariamente in senso negativo: chi è senza peccato...).

Sourceforge, ad oggi, anagrafa tra i 2700 e i 2800 progetti nella categoria Code Generators: tra i primi 10 ci sono almeno 4-5 compilatori o estensioni, 1 progetto ERP (che, contrariamente a quanto potreste immaginare, ha davvero a che fare con questo post), 1 progetto per generazione di codice partendo dall'UML e 3-4 generatori generici template-based.

Per mancanza di tempo cercheremo di escludere almeno i compilatori, che richiedono ben altra teoria, per concentrarci su casistiche più semplici, tipicamente quelle rappresentate da un modello dati che viene trasformato in un generico output (visivo, su file, come vi pare) sulla falsariga di un template elaborato da un qualsivoglia motore, possibilmente in modo più dichiarativo possibile e senza ricompilare, al fine di produrre nuove righe di codice leggibile ed, eventualmente, modificabile e riusabile.
Uno dei tanti pratici e quasi classici utilizzi del classico pattern MVC, insomma. Estenderemo appena questo ambito, giusto perchè non ha senso limitare la fantasia (anzi, se volete poi segnalare altri curiosi impieghi e approcci, siete, al solito, benvenuti).

Diamo per scontato che abbiate già visto e/o usato generazioni automatiche, almeno una volta, per esempio per creare automaticamente codice e form di CRUD (per i 2 che non lo sanno, è l'acronimo con cui si indicano le operazioni alla base della gestione di dati: Create Read Update Delete). Magari con successo. Le stesse due-tre formettine, sempre uguali per l'intera applicazione, di semplice gestione di dati piatti, con pochi bottoni, sono spesso rese con strumenti simili, partendo dal reverse del database (e qualche altra informazione minore riguardante resa grafica, lookup, etc. etc. Approccio convincente, in fondo. Sembra funzionare.
Vien da chiedersi se non sia possibile estendere la tecnica ad altre casistiche.

L'utilità nel generare codice da compilare per le interfacce, soprattutto quando sia richiesta grande velocità non raggiungibile con sole generalizzazioni ottenibili componendo dinamicamente le pagine è indiscutibile. Tecniche simili sono utilizzate da molti CMS per per produrre siti Web con numero elevatissimo di accessi e ridotta richiesta di personalizzazione della navigazione da parte dell'utente): si creano tutte le pagine in html, al posto che passare da jsp, che, fossero pure basate su grandi cache, su numeri enormi possono far sentire il loro peso (beh, nei siti più importanti, dove viene richiesta una fortissima interazione user-centrica, comunque, l'approccio a pagine statiche non è praticabile e bisogna scalare aumentando l'hardware).

Sulle interfacce grafiche viene bene, anche perchè la generazione automatica supplisce, in parte, alla ridotta o non disponibile ereditarietà di implementazione tipica di tecnologie di front-end (jsp, aspx, etc. etc.).
[Che poi sia un bene non esagerare, in generale, con l'ereditarietà di implementazione e che sia poco sensato e/o mal definito pensare non solo di riusare componenti, ma anche di far ereditare posizioni e presentazione a pagine diverse, è altra questione che non vorrei tirare in ballo in questo post].

Non per nulla gli ambienti di sviluppo e progettazione visuali sono uno dei modi più comuni per produrre codice senza scriverlo direttamente, in una continua interazione tra utente ed IDE (particolarmente continua e interessante laddove venga gestito anche il roundtrip e relative difficoltà di riallineamento tra il codice scritto manualmente e quello generato - risolto, il più delle volte, con aggiunta di commenti, placeholder e dichiarazioni varie nel codice da parte del generatore + richiesta di scrivere, gentilmente, appena fuori dalla zona riservata).

Altro caso classico di generazione del codice è quello fornito da strumenti ORM, che, partendo da un reverse del DB generano le classi nel linguaggio di vostra elezione, per supportare il pattern DAO. Non insisto ad approfondire un argomento che mi piace molto poco, come già sapete, ma dovevamo citarlo, non fosse altro che per evitare accuse di averlo appositamente escluso.

Uscendo dagli esempi e cercando di generalizzare, inizio a segnalarvi che su SoftwareReality si trova una bellisima serie di articoli, completi e approfonditi, sull'argomento.

Può qui giovare riprendere e commentare almeno la pagina che tratta di vantaggi e svantaggi dei generatori di codice.

Vantaggi:

Ultra-consistenti: perchè generati proceduralmente
Maggior pulizia e semplicità del codice: portano il programmatore a ridurre le attività di generalizzazione, concentrandosi su cosa serve ora; ogni modifica potrà essere aggiunta sul template del generatore, riproducendo il codice (a meno di modifiche intervenute sulla prima generazione e/o a meno di necessità di gestione - solitamente complessa - del roundtrip, ovviamente)
Stabile e bug-free (il debugging si concentra PRIMA dell'inizio del progetto): verissimo, ma non è trascurabile il fatto che, se il debug del motore di generazione (tipicamente costoso/molto costoso) avviene PRIMA dell'inizio del progetto, non lo paga il cliente, ma qualcun altro (noi, se siamo noi ad aver progettato il generatore di codice, è un nostro investimento). E' certamente vero, comunque, che in presenza di poche modifiche in corso d'opera a motore e template, ogni generazione successiva può essere eseguita automaticamente o eventualmente con solo piccola supervisione.
Produce molto velocemente una nuova API aggiornata e garantita, partendo da una descrizione del dominio del problema: anche questo verissimo, ma la sua potenza e flessibilità dipende dalla flessibilità con cui abbiamo generalizzato il nostro generatore ed il relativo dizionario dati (più è flessibile più sarà probabile un significativo investimento iniziale). Qualcuno ritiene che sia questa la forza di alcuni degli ERP/CRM Open Source di maggior successo.
Customizzabile: inoltre non necessariamente serve il codice del generatore come dice l'articolo da cui siamo partiti, se possiamo agire su template, dizionario dati, regole (a meno, ovviamente, di non considerare come codice anche questi tre elementi)
I cambiamenti di generatori/template, codice generato e progetto vanno di pari passo: se è necessario un cambiamento strutturale lo si fa sul generatore/template e si propaga ovunque . Non bisogna, però, perdere di vista il problema del roundtrip di cui parlavamo sopra. Non di rado, dopo la prima generazione, si rischia di non riuscire a stare dietro ai cambiamenti. Ovviamente la nostra generazione dovrà prevedere una architettura che separi le personalizzazioni dal codice generato. Lo si può fare con righe di codice "riservate", come i tool visuali di cui parlavamo, o (meglio, ma non sempre così facile) separando il codice generato dal codice modificabile in classi diverse e legandoli con qualche pattern.
I programmatori sono liberi di concentrarsi su aree di sviluppo di maggior rilievo (il morale migliora, la produttività cresce): è forse uno dei punti di maggior interesse... se la generazione del codice non vincola troppo e non richiede troppo (altrimenti si ottiene il risultato opposto). Questo vantaggio è particolarmente vero se gli sviluppatori in questione non sono quelli che devono gestire anche il generatore, dizionario dati e relativi template, ovviamente.
Insegnano a scrivere codice: solitamente ci si attende che il codice generato sia ben scritto e consistente al 100% (ma tra teoria e pratica ce ne passa) e i programmatori (junior) possono imparare dallo stile del codice generato. Vero solo se confrontato con metodologie che prevedono documentazione da leggere per le style guide e solo se il codice viene veramente letto. Nella pratica mi capita di vedere che non venga letto (e/o applicato) nè il documento degli standard, nè il codice scritto da altri (anche senza generarlo automaticamente, tra codice prodotto in-house da senior e codice esterno, disponibile in centinaia di migliaia di progetti open source ce ne sarebbe a sufficienza, anche senza generatori; senza considerare che il codice generato, solitamente, riguarda parti concettualmente più semplici, da cui si può imparare meno)

Svantaggi:

Prima bisogna scrivere il generatore: lo abbiamo detto sopra, i costi si spostano sull'investimento. Inizia ad aver senso quando lo stesso generatore si può riusare su più progetti, perchè, a quel punto, i costi si abbattono e si è più competitivi della concorrenza. E' un po' come scrivere librerie o framework aziendali (ma questo punto lo approfondiremo - non so se oggi o quando, ma lo faremo)
Applicabile solo all'interno di ambiti e condizioni specifici (almeno fino alla realizzazione del primo generatore basato sulla comprensione del linguaggio naturale: poi sostituiremo il dizionario dati con le specifiche e sarà libero di interpretare a modo suo e fare lo stesso casino di un programmatore umano). Anche l'articolo citato suggerisce che il codice generato sia da considerare un supporto per le parti aggiuntive, scritte manualmente, una sorta di API
Se il codice generato deve trattare con database, questi devono essere progettati e normalizzati bene, perchè i generatori solitamente non si comportano bene con database con caratteristiche particolari: vero, a questo riguardo possiamo solo aggiungere che non è raro che il database stesso (o, almeno, parte di esso) siano parte del codice generato. Generatori che si adattano a database esistenti sono solo generatori più flessibili, che estrapolano parte del loro dizionario dati dai metadati, dal reverse del db.

Mi sembrano necessarie alcune considerazioni aggiuntive:

di fatto, per generare il codice, è necessario operare una sorta di generalizzazione. Spesso conviene, a mio parere, chiedersi se non ci sia l'alternativa di progettare una soluzione generale, al posto che generare il codice, per gestire direttamente la problematica. Pro: potrebbe essere più manutenibile (una sola/poche classi al posto delle decine/centinaia/migliaia generate + quelle del generatore che sarebbero, comunque, da manutenere). Contro: un comportamento generale può girare più lentamente di uno generato in modo specifico, in fase di esecuzione (ricordate l'esempio dei CMS all'inizio di questo post?)
vale la pena di considerare, a seconda dei casi, modalità di generazione progressiva, prodotta dall'interazione uomo/macchina. Vantaggi: flessibilità e velocità. Svantaggi: maggior rischio di complessità per gestione roundtrip. Laddove questa generazione sia nascosta all'utente (non programmatore, ma utente finale), potrebbe essere pericolosa e pesante. Per fare un esempio di una simile casistica, conviene pensare a strumenti di data mining o di interrogazioni dei database semplificate per gli utenti finali: da una semplice interfaccia si generano query SQL, senza che l'utente debba conoscere SQL (il caso più semplice è il QBE, Query By Example). A parte il fatto che, solitamente, in questi casi, si perde molta della potenza del linguaggio sottostante, mi viene sempre in mente il drag&relate visto nel 2001 su Top Tier (oggi inglobato in Sap Portal - che, tra l'altro, non vedendolo dal 2004, non so se mantenga ancora questa caratteristica, che già tendeva a nascondere): metteva facilmente in relazione entità anche complesse di database (anche alla base di ERP come SAP e BaaN, ai tempi), generando output in base al fatto che l'utente poteva trascinare righe di una entità su un'altra entità e le join ed i filtri li applicava lui secondo regole dedotte dai metadati e corrette/integrate manualmente sul suo dizionario dati. Bellissimo strumento demo (almeno per i tempi), aveva il piccolissimo difetto che, al terzo-quarto drag&relate poteva anche riuscire a mettere in ginocchio il server, dal momento che generava continue subquery di complessità arbitraria, come i vedeva bene dai log degli ODBC. Attenzione a problematiche simili generabili dai constraint di Hibernate, nel caso il programmatore non conosca bene la struttura del DB sottostante (e se lo conosce, forse ci siamo persi parte dei vantaggi di Hibernate stesso e dell'ORM... siccome ho già detto che non insisto, non insisterò...)
Esistono, oggi, sistemi anche molto complessi che utilizzano la generazione di codice a partire da dizionari dati di dimensioni e obiettivi importanti: Compiere ERP e i suoi figli ADempiere e OpenBravo (era lui, ad essere indicato tra i primi 10 Code Generators in sourceforge) costituiscono uno degli esempi più eclatanti: una buona parte dell'ERP si rigenera sulla base di regole e descrizioni di relazioni tra entità. Magari ne parliamo meglio in qualche prossimo post, riguardo a strumenti OpenSource per le aziende. Fossero solo gli unici esempi (anche in caso di funzionamento parziale rispetto al dichiarato), sarebbero sufficienti per rendere questa metodologia come degna di considerazione, ben al di sopra dell'automatizzazione del cut&paste di codice.

Oltre ad annoiarsi con le considerazioni di cui sopra, con la generazione di codice ci si può anche giocare (anche perchè generazione è una parola piena di significati, anche importanti, non vogliamo mica lasciarla passare senza far nulla, vero?).

Non so se abbiate presente CRobots. Si tratta di un gioco per programmatori: si programma il comportamento di un robot e lo si manda a combattere in un'arena con altri robot e, ovviamente, ne rimarrà soltanto uno.

Per un esame universitario misi assieme CRobots e algoritmi genetici (voglio dire: se parliamo di generazione, parliamone fino in fondo) per far evolvere programmi in grado di giocare a CRobot (per superare i limiti di potenza di un 8086, non potendo permettermi un algoritmo di selezione effettivamente basato sul combattimento in arena, troppo lento - ogni partita richiedeva minuti, tempo non compatibile con la durata attesa della mia vita -, dovetti pensare ad un modo di 'far leggere' il codice all'algoritmo di selezione, con delle euristiche per valutarne la bontà - via il dito dal tasto sinistro del mouse, ve ne parlo un'altra sera...).

In termini evolutivi non ho passato di molto il brodo primordiale, ma è bastato per vedere robot immobili trasformarsi in quelli dotati di un ridotto movimento (troppo movimento era dannoso: finivano a suicidarsi contro il muro), fino ad arrivare a quelli che vendevano cara la pelle sparando qua e là a caso.

Generazione automatica ed evolutiva di bug, in fondo, pur all'interno di un codice stilisticamente accettabile e sintatticamente corretto, perchè preimpostato (provate a rileggervi vantaggi e svantaggi, in questa ottica, potrebbero assumere un altro aspetto).

In ambiti più complessi la generazione di codice può fermarsi un attimo prima, ad una proposta di generazione (la differenza sta solo nell'applicare o meno il risultato), richiedendo una più esplicita e forzata interazione tra uomo e macchina.

Essendo parecchio malati potrebbe pure capitare di laurearsi con una tesi (di Artificial Intelligence, ovviamente, che so, intitolata Sistemi basati su conoscenza che analizzano il proprio ragionamento) impostata su un sistema esperto che si limiti (con la modestia che mi contraddistingue) a proporre le modifiche alla propria base dati, senza modificarla, partendo dall'analisi della base dati stessa, dai risultati forniti e da quelli attesi e interagendo con l'esperto di dominio.

Siccome dopo aver giocato con la parola generazione ora stiamo sforando nel giocare anche con la parola codice, possiamo estenderne appena appena il concetto e chiudere il giro (sempre per passi e per vie traverse e contorte, si intende e ci mancherebbe altro) tornando dall'informatica alla letteratura da cui eravamo partiti, citando una serie di generatori di codice molto particolare, di linguaggio, in modo da arrivare a generatori di storie, il cui capostipite, se la memoria non mi inganna, dovrebbe essere Storyteller, del già più volte citato Shank.

In questo caso la generazione deve passare da un motore che conosca, tra l'altro:
- i principi minimi di base di semiotica che chiunque impara da bambino leggendo Eco o, almeno, le già citate classificazione di Aarne e Thompson e schema di Propp, per estrarre alcune conoscenze relative alla struttura dei racconti
- due o tre concetti di come si susseguono le azioni nel mondo reale (script basati su Conceptual Dependency nel caso di Shank)
- qualche (minima) capacità semantica (di fatto, compresa nel punto precendente)

Per evitare che pensiate che mi stia inventando, appunto, delle storie, vi cito qualche link d'esempio, che parta da un significativo elenco di link a generatori di storie (di diverso livello e diversi argomenti), per passare ad una introduzione, schemino (con altri link) e qualche modello per raccontare storie più evoluto ed accademico, che, magari, sia in grado di sottolineare le emozioni dei personaggi, per finire giocando su qualche narratore online (dal generatore di trame per il cinema, ad esperimenti che si spingono anche a cercare foto coerenti con il testo fino a cercare di far soldi, sfruttando i generatori automatici per diventare ricchi scrivendo un romanzo).

Approfondire anche questo argomento ci riporterebbe su un discorso già più volte sfiorato e mai intrapreso.
Che non abbiamo tempo e spazio di iniziare neppure stavolta.
Peccato...

Bye

DepaP.S.: potrebbe venirvi in mente anche di costruire post automaticamente, che contengano le parole più cercate, per far salire il ranking e gli hits sul proprio blog. Curiosamente l'esito può anche non risultare così insopportabile da leggere rispetto a molti articoli di blog scritti appositamente per l'ottimizzazione nei motori di ricerca. Anzi, talvolta mi sorge pure il dubbio che, con la generazione automatica, certi programmatori e romanzieri si siano già spinti più avanti di quanto io sappia e vi abbia raccontato...

Oggi scricchiolo

2007-10-20T22:32:00.000+02:00

Hanno iniziato le mie scarpe. Apparentemente.
Almeno, mia moglie mi ha fatto notare che le mie scarpe cigolavano, alla frizione con il terreno (non si è espressa così, io sto scrivendo, lei stava parlando). E l'ha sentito nel casino del supermercato.
Da quel momento ho iniziato progressivamente a notare che non era uno stridio o un cigolio (neppure un pigolio), ma, appunto, uno scricchiolio.
E che non erano le scarpe, ma io.
Mi sento come una diga con un inizio di crepa. E l'acqua, dietro, che spinge.
Siccome sono una diga pensante e in fondo ci sono un po' di paesi, cerco di tenere.
Devo trovare un modo di tenere.
Forse somatizzo, ma mi fa pure un po' male la schiena...

Questo post avrebbe dovuto trattare di generazione automatica del codice. Sarà per una delle prossime volte.
Ora ho problemi più seri.

Quindi, per la prima volta dall'inizio di questo blog (non so quante altre volte l'ho scritto in post precedenti, non serve che controlliate) sto usando questo strumento come diario, come sfogo reale.
E scrivo di getto, senza pensare.
(anche questo rischia di non essere del tutto vero: sto scrivendo una bozza, poi la rileggerò, cancellerò qua e là, cercherò di essere più diretto, cancellerò tutto, riscriverò da capo, etc. etc., ma è l'approccio più di getto che possiamo sperare di ottenere da me in questo momento: diciamo che, semplicemente, cercherò di non correggermi troppo)

La speranza è che un giorno rileggerò il tutto e mi farò una grossa e grassa risata. Ovviamente è più probabile che la rilettura porti a trovare tutto molto infantile e banale, come spesso mi capita quando mi azzardo a farlo, ma proviamo a puntare, comunque, sulla grassa risata. (Mi viene da sorridere al solo pensarci, guarda come sono rilassato, lì, nel futuro...)

Ma ora la pressione è forte: lavorativa, informatica (in sè, slegata dal lavoro), nella mia interpretazione del mondo.
Tiene la vita privata. Il che, tutto sommato, comunque, non è male.

Il lavoro pressa, non è inusuale.
Lo ha sempre fatto, è il suo mestiere, in fondo. E' solo che lo fa in modo insolito, curioso e poco elegante. Ulteriori approfondimenti, in questo momento non sono molto affari vostri (o dovrei dire tuoi, caro diario, che sei il solo che non può scappare e sei costretto a sorbirti il tutto, correzioni comprese). Anzi, non avrei neppure dovuto iniziare a parlarne, non insistete. Quasi quasi cancello questo paragrafo. Ma no, vah, leggetevelo lo stesso...

L'informatica mi opprime con il suo immobilismo (curioso, la scienza che non si ferma mai, quella che faccio fatica a starle dietro, che ogni 6 mesi passano 3 anni...).
Oggi mi sembra che non ci siano state novità sensibili da oltre 5-6 anni. Spero di sbagliarmi, spero che voi le vediate, io vedo solo nomi marketing che cercano di vendere vecchie tecnologie ed approcci - in particolare, non mi parlate di SOA, AJAX, Flex e varianti varie, per favore, non c'è nulla che non ci fosse già nel 2000 e forse prima! - e soffro per non essere io stesso a riuscire a trovare qualche punto di appoggio per la leva che crei il movimento. Mi hanno chiesto, recentemente, se non vado allo SMAU. E che ci vado a fare?
Sto aspettando un computer da indossare e sempre connesso di cui ho già parlato, o anche solo un programma che capisca cosa gli dico, che traduca correttamente, faccia per me ricerche su internet e scriva almeno parte dei miei allegati tecnici: se non c'è nulla di ciò, per favore, non svegliatemi. Va anche bene un robot che sappia stirare (seriamente, intendo!), se non avete altro da propormi e proprio non sopportate che resti apatico in questo angolo.

La mia interpretazione del mondo sta cambiando.
Non in meglio o in peggio, semplicemente sta cambiando: apparentemente tutto è più chiaro e completo, ma è sempre così, arriva un momento in cui, per folgorazione o erosione lenta, arrivi a percepire i dintorni in modo differente e ti sembra pure di cogliere i contorni e i dettagli e non solo delle macchie in movimento. L'esperienza insegna che dura un momento, ma pazienza. Per ora va bene così, non possiamo escludere a priori che questa volta possa essere effettivamente quella buona, manca solo il coraggio di cambiare per adeguarsi a queste nuove lenti.
Perchè, non so se è evidente anche per voi o è solo una questione di punti di osservazione differenti, ma se non mi sposto da qui, difficilmente riuscirò a raggiungere la mia meta.

Ed è con questo bagaglio di nuove certezze granitiche che nutro i miei dubbi, ancora una volta.
Depa a due velocità: quella mentale, a km da qui e quella di azione, anche lei a km da qui, ma alle spalle.
In mezzo la diga.
Lo scricchiolio.

Un rapido checksum, se non altro, sembra permettere di escludere azioni da un giorno di ordinaria follia: hardware e firmware sembrano al loro posto.
Troppi, come sempre, invece, i dati e come sempre in ordine e da organizzare. Mancano dei link, è ovvio.
Altri sono broken.

Scricchiolio.

Puntatori aperti, nella mia testa.
Alcuni sono cose da fare, quasi dimenticate, ma con un segnale luminoso che lampeggia.
Altri sono cose dimenticate del tutto. Forse importanti.

Cigolio. Questa volta erano le scarpe, però.
Mi metto in ascolto, per uno scricchiolio.
Niente.
Basta che non sia come il singhiozzo, quando sembra che stia per passare, ma forse è ancora lì.

Mi spiacerebbe scoprire che i link e i puntatori appesi riguardassero aspetti importanti della vita, diventati momentaneamente meno importanti e ora tornati come dovevano essere.
Già mi è capitato una volta. Mi ero quasi completamente perso, vagavo per zone deserte, ma mi rallegravo per la spiaggia ed il sole.
Per fortuna è arrivato un apparente momento difficile, seguito poi dai figli, che un po' prendendomi in braccio e un po' con la manina mi hanno riportato a casa. Priorità dei valori rovesciata, tornata a posto.
Ma ti spiace per il tempo perduto, resti deluso perchè ti ricordi cosa pensavi di te quando eri tu il bambino, per esserti accorto che la lista dei valori la dichiaravi in un modo e la vivevi nell'altro.

Scricchiolio. Visto? Che vi avevo detto?

Perchè i bambini la vedono molto più chiara? Perchè fanno domande, se sanno già le risposte? Maieutica?
Perchè dobbiamo rassegnarci a scambiare il nostro destino da imperatori del mondo conosciuto con quello da impiegatino asburgico?

Non vi viene da pensare, a volte, che quello scricchiolio, a pensarci bene, è un po' che si sente, ma guarda che l'acqua non c'entra nulla, deve essere il vento tra i rami degli alberi?

E questo pensiero vi rassicura davvero o vi preoccupa di più?

Bye

Depa

Bentornati

2007-09-03T23:23:00.000+02:00

Siete tornati, dunque, voi e i vostri hits.
Vi ho visti in forma di istogrammi.

Mentre eravate in ferie io ho lavorato (solo il blog si è fermato completamente).
Non è neppure una consolazione sapere che sono in vantaggio su di voi, che vi state alterando solo ora per la rarità dei tram non soppressi, che hanno cambiato percorso e non si capisce più come fare ad arrivare alla meta (in tempo sarebbe troppo anche in situazioni normali).

Non ditelo a me che ho colto la situazione nella sua completa chiarezza sotto ad una grandinata il 16 agosto sera, in area totalmente scoperta (neppure un cornicione nel raggio di 500 metri) di fronte al Cimitero Maggiore. Con autobus sostitutivo in ritardo. E vento che girava l'ombrello. Un assaggio del terzo e quarto girone dell'inferno messi assieme per dieci minuti. Senza neppure essere stato troppo lussurioso o goloso.

Eppure, nonostante i diversi cataclismi, il mio problema principale in questo periodo è stato quello di cercare di riposarmi in qualche modo, di trovare una qualche distrazione (ed il tempo per goderne), senza intaccare la necessità di lavorare.
Alla fine l'unica evasione, in queste settimane, me l'hanno fornita i libri (va beh, un po' di montagna nel week-end, moglie e figli, qualche cena fuori, ... ma che c'entra? non distraetemi e lasciate che mi pianga addosso inutilmente e per i motivi più futili almeno per una riga).

Libri anche attraverso aNobii (quanto tempo mi porta via? servirà a qualcosa? per ora ho inserito solo ISBN di due scaffali - ne ho diversi, non finirò mai... - e qualche tag: appena inizierò a commentarli, vedrete comparire una colonnina a questo blog).

Il problema (?) è che non trovo più libri che mi distraggano o mi interessino (soprattutto delle dimensioni da poter portare dietro in treno e tram) che non siano seri e pesanti.

Per questo ora sto leggendo Eco (neppure i romanzi, i saggi!) e argomenti di religione.

Se, date queste premesse (ed avendo letto le parole di colore oscuro al sommo della porta) trovate ancora il coraggio di andare oltre l'abstract...

Se son d'umore nero allora scrivo
frugando dentro alle nostre miserie:
di solito ho da far cose più serie, costruire su macerie
o mantenermi vivo
(Guccini - Avvelenata)

Per farvi entrare subito nel clima mentale da me vissuto in questo periodo, parto con alcuni estratti da 'Il superuomo di massa' di Eco:

Sappiamo benissimo che c'è un modo di vedere le strutture narrative come elementi neutri di una combinatoria assolutamente formalizzata, che non riesce a dare ragione dell'insieme di significazioni che la storia e la società attribuiranno poi all'opera.
[...]
Sappiamo d'altra parte che ogni sforzo di definire una forma significante senza investirla già di un senso è vano e illusorio, così come ogni formalismo assoluto non è altro che un contenutismo mascherato.
[...]
Tanto più che infine si prospetta un'altra serie, la serie delle interpretazioni, talora discordanti che, sulla base di motivazioni diverse e a diversi livelli di classe e di cultura, una udienza dà del messaggio che le perviene.

Incertezze interpretative, quindi, dovute alla difficoltà di dividere le strutture narrative dalla società e dai punti di partenza e dai pregiudizi di chi dovrà, in un dato momento, eseguire l'interpretazione.

Per quanto riguarda gli argomenti di religione, mi interessa molto approfondire questioni legate alla storicità di Cristo. Ovviamente Messori e Ratzinger (sono cattolico, ricordate?), ma anche le posizioni opposte (non si può essere obiettivi su questi argomenti, ma mi interessano comunque i diversi punti di vista), come Odifreddi (l'ultimo suo testo è un best seller del momento, facile che lo abbiate letto anche voi) o UAAR (Unione degli Atei e degli Agnostici Razionalisti, in cui troverete ancora Odifreddi e altri personaggi famosi e schierati contro la religione come la Hack), mediando un po' con Wikipedia ed altre fonti più o meno di parte prese da Internet (alcune pure buone).

Come già in altri miei post mi trovo a sottolineare la presenza di problemi dovuti a troppe e non certificate informazioni, che non possono fare altro che creare incertezze (o, come minimo, quel relativismo che preoccupa tanto Ratzinger).

Se il dubbio può essere anche sano, positivo e molla per successivi approfondimenti o fonte di profonde riflessioni e dolorosi combattimenti interiori, la difficoltà di distinguere le frasi buttate a caso da quelle ragionate, l'indeterminatezza fine a sè stessa o dovuta a tentativi di alzare polveroni o alla ripetizione acritica e non validata di altre fonti, alla stupidità, all'incomprensione, alla scarsa profondità o al fatto di dover comunque dire qualcosa è solo negativa e irritante.

A volte si sparpagliano le carte per nascondere la strada corretta, talvota, semplicemente, perchè non sappiamo fare altro che crearci casino da soli:

... non c`è nulla fuori dell`uomo che, entrando in lui, possa contaminarlo; sono invece le cose che escono dall`uomo a contaminarlo... " (Vangelo di Marco, 7,1-23)

Per rimanere più terra terra, non sembra un caso che Terry Pratchet e Gaiman Neil, in Buona apocalisse a tutti (va beh, ho letto anche qualcosa di non seriosissimo, in seguito ad un ottimo consiglio che faccio che girarvi, sottolineando, però, che non si tratta di un libro normale, pur essendo tutt'altro che serio e pesante) fanno pensare al demone Crowley, riguardo agli umani:

non c'è nulla che possiamo fargli che non si facciano da soli e loro fanno cose che non noi non avremmo nemmeno mai pensato, spesso utilizzando elettrodi

In questo campo possiamo trovare molti altri esempi di incertezza (da che parte sta il tentativo di misdirection?), come per esempio, quando si parla di Inquisizione e Galileo: si tratta di esagerazioni e leggenda nera o realtà storica? Abbiamo dei mezzi per capirlo, magari nel tempo? Possiamo risalire alla verità storica o siamo incatenati in quello che mi ostino a ritenere un gran brutto luogo comune, secondo il quale la storia la scrivono i vincitori?

L'incertezza delle fonti, l'immersione in una società che ci bombarda di fattoidi sono stati anche oggetto di una serie di interventi in un post nel blog di Isadora cui non ho potuto fare a meno di intervenire, che partiva dall'attualità di Fahrenheit 451 (ai tempi non lo avevo letto, nel frattempo ho corretto questa mancanza, bel suggerimento, grazie - ok, ok, so che state pensando che ho cercato di farmi passare per un lettore incontentabile e seriamente colto, per poi mostrare che mi basta un testo di fantascienza di diversi anni fa e un titolo di fantasy-umoristico-demenzial-filosofico, ma rendetevi conto che siete voi che pensate in modo molto malizioso e che non è colpa mia se oggi vi è andato tutto male).

E' evidente che il problema della qualità dell'informazione, sotto diversi aspetti, è molto sentito.

E' un po' come se fossimo arrivati al superamento del giornalismo:
- prima: mancava l'informazione, il giornalista la trovava e, almeno idealmente, la doveva validare prima di fornirla.
- ora: chiunque vi darà informazione (e relativa opinione, ci mancherebbe, lo sto facendo pure io), ma il problema è individuare le informazioni buone

Le cause e gli ambiti in cui si possono trovare cattive informazioni sono troppe, quindi non è facile correggere a monte il problema.

E' questa, a mio modo di vedere, la vera sfida dell'informatica del post-inizio-internet:
- estrarre le informazioni dal mucchio, con primo filtro sulla spazzatura e sulle 'distrazioni', evitando le ridondanze
- validarle con fonti controllabili

Il tutto il più dinamicamente possibile, perchè ogni operazione che facciamo su queste informazioni le cambia ancora e dobbiamo riuscire a sfruttarne la continua evoluzione, smettendo di raccogliere solo montagne di dati, ma iniziando ad usarli per davvero.

Chiuderei ancora con il già citato testo di Eco, che cita Dino Segre, che a sua volta cita molti altri autori, per aforismi, in Dizionario antiballistico (anche a voi l'iterazione di ipse dixit, al posto che rassicurare fa pizzicare il vostro senso di ragno?), mostrando come Pitigrilli avesse acutamente notato che l'aforisma (di cui lui faceva grande uso) possa essere rovesciato senza perdere forza (mostrando chiaramente quanta vuota conoscenza sia contenuta in tali espressioni e nella cultura che su di esse si basa - ce li avete anche voi, a casa, gli aforismi di Oscar Wilde?):

Talora Pitigrilli si è divertito ad allineare aforismi di autori diversi, l'uno che negava l'altro, entrambi autorevolissimi, sotto la voce "facciamoci un'opinione":

Non ci si inganna che per ottimismo (Hervieu) Si è più spesso fregati dalla diffidenza che dalla fiducia (Rivarol)
I popoli sarebbero felici se i re filosofassero e se i filosofi regnassero (Plutarco) Il giorno che vorrò castigare una provincia la farò governare da un filosofo (Federico II)

Ed è così che, un po' marzullescamente rischiamo di accorgerci che gli aforismi stanno diventando la fonte della nostra conoscenza quando, addirittura, non ci viene richiesto di condensare la nostra conoscenza in aforismi.

Bye

DepaP.S.: non chiedetemi nulla riguardo all'ultima frase, risolvetevela per conto vostro.

Narciso Yepes e la chiave del quindici

2007-07-19T23:36:00.000+02:00

Narciso Yepes, diventato noto al grande pubblico per aver suonato con la sua chitarra classica il pezzo centrale della colonna sonora di Giochi Proibiti, soleva ricordare di aver imparato le basi da un grande maestro che, però, non era un chitarrista, ma un pianista, Vincente Asencio.
Asencio gli faceva sentire al pianoforte cosa doveva suonare. Quando lui gli diceva che non era possibile ripeterlo con la chitarra, Asencio gli rispondeva che, se non poteva fare nulla con quello strumento, avrebbe fatto meglio a cambiarlo. Così Yepes studiò nuove tecniche, riuscì a ripetere gli esercizi proposti, diventò uno dei massimi virtuosi del mondo, arrivando a tenere concerti con la chitarra estesa da 6 a 10 corde dal liutaio Ramirez secondo i suoi suggerimenti.

Questo aneddoto deve essere molto noto perchè è facile incontrare persone che si immedesimano in Yepes.
Qualche virtuoso esiste anche, ma non è raro vedere usare strumenti sbagliati nei modi e momenti sbagliati, con tentativi di estensione ed estremizzazione, ma senza prima averne approfondito i limiti.

Come chi cerca di usare la chiave del quindici su un bullone da 12 o un martello per svitare un dado, talvolta i risultati possono non essere quelli sperati (ben vengano le eccezioni, ovviamente!).

In questo senso, uno degli esempi più comuni nell'informatica è quello di considerare l'XML come ingrediente fondamentale e irrinunciabile. Non importa per cosa, l'importante è usarlo.

Qualcuno di voi sarà anche saltato sulla sedia, ma l'XML, che mi conosce, sa che non deve prendersela, dal momento che gli è ben noto che lo uso con quotidiana assiduità.

Ci frequentiamo almeno dal ~~1996~~ 1998 e non se la prende se continuo a sottolineare l'ovvio, ovvero che continuare ad evidenziare che è uno standard è utile quanto confondere Java con la sua sintassi di base.

Perchè di standard, nell'XML c'è solo quello: la sintassi.
La semantica bisogna sempre implementarla, come credo sia ben noto.

Dtd o Xml Schema servono per rafforzare la sintassi, anche se a diversi livelli, ma per usare quei dati incastrati tra un tag e l'altro, serve sempre un programmatore.

Spero, infatti, sia a tutti palese che, anche usando l'xsl(t), anche se dichiarativamente, anche se tra mille limiti e salti tripli per fare cose banali in altri ambienti, stiamo sempre scrivendo regole, filtri, semplici trasformazioni, qualche controllo, ovvero: programmando.
A questo proposito, giusto per fare un esempio che mi piace sempre sottolineare, progettare una architettura multilivello, separando bene la presentation dalle business rules e poi decidere coscientemente di buttare la possibilità di usare competenze e strumenti specifici del front-end (esperti di html e javascript, grafici che costano tipicamente meno di programmatori e strumenti WYSIWYG che permettono un disegno rapido) usando xml ed xslt per generare il layout e manutenerlo è veramente un peccato.

Senza considerare che il carico (sia in termini di heap che di cpu) per il parsing ed applicazione delle regole rischia spesso di essere significativo rispetto all'utilizzo di altre tecniche (magari compilate, come una buona vecchia JSP).

Comunque, se il fatto che si debba fornire la semantica programmandola e che sia ragionevolmente sconsigliato sfruttare l'XML come base di un template engine/layout manager fossero gli unici problemi non avrei scritto questo articolo. Si tratterebbe di peccati veniali.

Ciò che mi preme sottolineare è la tendenza all'esagerazione nell'utilizzo di questo seppur utile e versatile strumento.

Per esempio, come strumento per memorizzare dati, in ambiti complessi.
Per fare un esempio pratico: non mi direte che non avete mai visto un CMS xml-based, vero?
Io ho anche visto citare questa feature come elemento distintivo di certi sistemi, laddove il pubblico (e talvolta l'oratore) non era in grado di cogliere che:

la stessa flessibilità descrittiva si può ottenere anche con un bel database, con la stessa facilità (i casi cui mi riferisco riguardano progetti di una certa dimensione, dove non è neppure messo in dubbio che esistano altre funzionalità per cui è necessario ed irrinunciabile un bel RDBMS)
ricercare valori di tag in XML salvati sul filesystem non è operazione propriamente performante: per risolvere questo tipo di problema è solitamente necessario ricorrere ad altre strutture architetturali (es: estrazione preventiva dei metadati e loro indicizzazione - non di rado appoggiandosi ad un RDBMS, o, talvolta, addirittura riscrivendo da capo funzionalità che sono oramai consolidate e super-performanti da anni in quei sistemi -, cache multilivello, etc. etc.)
come sopra citato, per la famosa estensibilità garantita dall'XML bisogna programmare: lo so bene che non è sempre necessario farlo all'aggiunta di un nuovo campo in un CMS, - a patto di rimanere entro certi limiti, beninteso -, ma per quello che mi è capitato di verificare nella pratica o si rientra in situazioni quasi banali e gestibili anche più facilmente su DB, o si devono comunque battere quelle costose 10 benedette dita sui tasti.

Un altro caso tipico è la generalizzazione "hand made", tipicamente in fase di configurazione di un sistema: il costo dell'interprete vale il vantaggio della generalizzazione? ci lamentiamo della reflection e aggiungiamo un intero interprete? anzi, a volte aggiungiamo pure la reflection come modalità di costruzione di oggetti generalizzati nell'xml, da far richiamare in una Factory e/o in un Singleton allo startup?

Non so se vi siete resi conto delle risorse richieste per l'elaborazione, soprattutto usando DOM - a proposito, su .NET c'è il parser SAX, o si va solo di DOM? io non sono riuscito a trovarlo...:

tempi per il parsing (SAX e DOM)
tempi per costruirsi gli oggetti (automaticamente nel DOM, spesso 'a mano', più leggeri, con parser SAX based)
heap che si riempie facilmente (che so: mai provato un out of memory in Java per import dati massivo via XML, passando da un parser DOM?)

Vediamo di esaminare anche i vantaggi, per capire dove ha senso usarlo, almeno IMHO (in italiano verrebbe IMMP, fa schifo, spero lo capiate, senza considerare che la 'M' di 'Modesto' poco mi si addice):

la standardizzazione di questa sintassi aiuta nell'avere dei parser e ci sono molti casi in cui un parser bell'e pronto è proprio ciò che ha ordinato il dottore (per esempio, per estendere un linguaggio con tag libraries/web controls)
esistono casi - rari e semplici, purtroppo - in cui una bella trasformazione xslt è comunque decisamente più semplice da scrivere di un programma (es.: per creare dei pdf - xsl-fo - magari a partire da un html: bisogna lavorare un po' sull'xsl, ma fare uno spider che si naviga il sito in un certo ordine e ne produce un libercolo in pdf è alla portata - mi dicono che il Mac lo faccia di default, è vero? per PC, tra gli open source, di decente ho trovato solo HTMLDOC, anche se non si naviga da solo gli url delle pagine - ; ancora: nel passaggio di dati da un sistema ad un altro, spesso è utile trasformare un XML proveniente dall'esterno in un XML in formato già gestito dal nostro sistema, per rielaborarlo senza ulteriori sviluppi e un filtro di questo tipo scritto in xsl è la morte sua).
laddove le descrizioni dei dati (dai tracciati record alle immagini SVG) sono complesse e questi dati devono essere scambiati tra sistemi o essere alla base di programmi per cui ha poco senso aggiungere un database, l'XML è decisamente più adatto di altri formalismi (es, il vecchio EDI), essendo potenzialmente molto più ricco, espressivo e permettendo di condividere e validare la sintassi in modo più mirato.

Proviamo un piccolo riassunto di casi pratici, relativo ai punti su cui solitamente mi sento o non mi sento di usarlo:

NO

in generale, per evitare di gestire documenti su DB (es. del CMS) o come modalità di estensione dei campi nel database: non posso fare ricerche e join in modo performante, devo parsare ed intepretare il mio file ogni volta (a meno di pre-parsing ed indicizzazioni di cui si è già parlato - ma come gestite l'indicizzazione? la delegate al DB o la gestite a mano? vi siete ricordati di indicizzare tutti gli elementi e lasciare il testo ad un motore di ricerca full-text? i valori dei tag sono codificati o si tratta di stringhe, pure inserite manualmente?). Indizi del fatto che non va così bene: a parte i tempi di sviluppo di eventuali indicizzazioni e recupero dei dati, dovete usare uno o più livelli di cache e, in caso di miss, la relativa interpretazione porta via 2 ordini di grandezza o più del tempo necessario per recuperare il dato pre-interpretato dalla cache (2 ordini di grandezza è troppo: sarebbe bene che le cache correggano 1 ordine di grandezza, altrimenti è indice di seri problemi nell'operazione fuori cache: se non ci sono alternative, fate bene ad usarle, ma se le alternative ve le siete precluse da soli...).
XML per memorizzare oggetti:

non vi piaceva la serializzazione nativa di Java e davvero pensate che questa sia più veloce? provate a fare un profiling e non dimenticate la gestione del versioning delle classi).
la versione in xml potete passarla come risultato di un Web Service? in linea di principio va bene, ma usare qualcosa di già pronto - es: SOAP - e passare direttamente l'oggetto era troppo standard?
vi serve per estendere il DB? v. sopra.
Volete farvi da soli il vostro OODBMS? Forse è il caso di considerare qualcosa di già pronto (ma non prima di aver considerato che, comunque, si tratta di tecnologie ancora molto discusse e, come minimo, un po' immature)

XML alla base dello strato di presentation: in questo caso si ha la perdita di performance per interpretazione vs. compilazione di cui ho già parlato; vi sentite più flessibili nel definire le zone del sito e le pagine? avete contato bene il costo di manutenzione, la flessibilità e quanto vi è costato realizzare un Template Manager di quel tipo, fuori da ogni standard?.

NI [situazioni da pesare, caso per caso: personalmente non ho ancora trovato una regola]

XML come file di configurazione [rischio: overdesign (in molti casi basta un file di properties) - possibile vantaggio: flessibilità ed espressività (soprattutto quando servono diversi livelli di approfondimento)]
XML come metadato (es.: base per Xlink o, più in generale, per il Web semantico ed RDF) [rischio: performance povere per mancanza indicizzazione o indicizzazione manuale, difficoltà nell'eseguire query, difficoltà di documentazione - possibile vantaggio: distribuibilità, laddove le performance non sono importanti, maggiore disponibilità di ambienti per eseguire parsing xml rispetto ad installare un RDBMS

XML per trasferire dati ed aumentare l'interoperabilità tra applicazioni (in tanti sostengono che sia nato per questo ;) ):

Web Services
base per Web 2.0, a partire da RSS/ATOM
come sorgente dati remota (in particolare come RE in REST)
in generale, per disaccoppiare i sistemi

XML come base per il formato di memorizzazione di una applicazione standalone laddove usare un DB sarebbe un po' eccessivo (es: state scrivendo Open Office e decidete di salvare in dati in locale, in formato portabile, aperto e facilmente trasformabile; i vostri dati, in questo caso, tipicamente non richiedono ricerche cross tra i diversi xml, al più solo all'interno di uno stesso documento
come base per definire nuovi linguaggi che richiedano interpretazione ed esecuzione: Apache Ant docet e certamente ha senso, dal momento che, in questi casi, comunque bisogna scrivere un parser ed un interprete e trovarsi con metà del lavoro fatto (e anche bene) non può che far piacere; altri esempi sono linguaggi che descrivono regole inferenziali (es: XML Rule Language in JBoss Rules - ex. Drools - ma, attenzione, nel manuale anche loro stessi dicono: 'There are several scenarios that XML is desirable. However, we recommend that it is not a default choice ...') o linguaggi che descrivono comportamenti che necessitano di un controllo di esecuzione (es: per definire dei workflow o - con un salto di fantasia di un centimetro e mezzo - come base per il governo di un ESB, come nel caso di BPEL).

Avete altri esempi? Avete elenchi di altri metodi architetturali usati malamente?
Non siete d'accordo su quanto ho detto dell'XML e ne volete parlare?
Beh, provate a darmi un feedback, prometto che se ne ho voglia ci penso su...

Bye

DepaP.S.: poi magari salta fuori che avete ragione voi
P.P.S.: per quanto improbabile, intendo... ;)

Uno, nessuno e centomila

2007-07-14T23:46:00.000+02:00

Inizia tutto dal dover approvare un commento del Depa. Siccome sapevo (via, diciamo che ne ero ragionevolmente convinto) di non essere io (sto invecchiando, ma non ancora così tanto da non ricordarmi di aver messo un commento al mio blog 5 minuti prima), evidentemente doveva essere un altro (un passaggio logico un po' complesso, spero siate riusciti a seguirlo - magari potete leggerlo ancora una o due volte, finchè non vi convince).

Leggendo il testo del commento si chiariva, infatti, che si trattava di omo-nick-nimia.

Sapete bene che già mi ero accorto di non essere il solo Depa. Oggi posso dire di aver passato serenamente e definitivamente quel brutto contraccolpo psicologico e, anzi, trovo che possano nascere dei possibili sviluppi interessanti.

Certamente questo post nasce all'insegna del titolo di Pirandello.
E certo l'estratto che riporto sotto della Wikipedia su questo argomento non aiuta ad alleggerire il senso di inevitabilità che incombe sul post (e sulla necessità di non arrivare alla follia del personaggio principale, ovvero io):

Dal punto di vista formale, stilistico, si può vedere la forte inclinazione al monologo del protagonista, che molto spesso si rivolge al lettore, ponendogli interrogativi e problemi in modo da coinvolgerlo direttamente nella vicenda, che è senza dubbio di portata universale. La lunga gestazione dell'opera potrebbe far pensare che essa sia frammentaria e disorganizzata. Al contrario essa può essere considerata come l'apice della carriera dell'autore e della sua tensione narrativa.

Dovrebbe essere ovvio a chiunque che chi l'ha scritto non si stava riferendo a Pirandello, ma al sottoscritto e a questi post, in cui vi tiro in ballo continuamente, in mezzo a testi lunghissimi, elaborati e (non avrei saputo esprimermi meglio) di portata universale.

Ma torniamo a noi, per vedere se si possa riuscire a cogliere dei risultati utili, nonostante le premesse.

Il Depa che mi ha scritto è un disegnatore di professione (lui tende a minimizzare, ma non dategli retta) e ha un suo blog in cui pubblica alcune sue creazioni. Oltre a piacermi i disegni, (i fumetti non li ho ancora letti), apprezzo moltissimo il fatto che usi il blog in un modo completamente diverso dal mio - così non mi fa concorrenza ;) - e che si possa, comunque, riconoscere un gran bel lavoro ed impegno sottostante. Gli rinnovo i complimenti.

A questo punto sono stato stimolato a cercare altri blog di altri Depa. Brevemente i primissimi risultati:

- Il Depa: Blog variabile, non intensissimo, ma con alcune perle (cercando bene). Ovviamente questo commento è soggettivo ed alterato dal risentimento (acc... lo psicologo non mi aveva detto che era passata?), perchè è quello che mi ha preceduto sul titolo del blog.
- Depa Campeon: Il suo sottotitolo riporta 'il depa come non lo avreste mai voluto vedere'. Blog con argomenti molto (troppo?) vari, forse come le sue professioni ('un sacco', dice) con leggero orientamento verso il calcio.
- Depa (89): il più giovane, di quelli che ho trovato, che, finora, si è espresso solo in giugno e che cerca di parlare con i suoi amici (ma ci tiene a far vedere che gli piace di più incontrare le sue amiche) e usa troppe 'K' per i miei gusti. Frequenta l'agraria a Voghera, da quanto si capisce dai 3 post e ha circa 18 anni. Alla sua età (20 anni fa! acc...) abitavo anch'io a Voghera e mia sorella faceva l'agraria. Il che non vuole dire nulla, concordo.
- Un Depa laziale: Curiosamente il 17 giugno pubblica lo stesso test che il Depa vogherese (sono quasi coscritti, al più si mancano di pochi mesi) aveva postato il 12 giugno. Si conoscono?
- Siccome non possiamo lasciarci sfuggire le altre arti, di fila un Depa musicista ed uno attore (sui blog mi astengo dal commento).

Immagino che con questo elenco voi possiate capire almeno chi io non sia. Forse credavate o avete creduto che io fossi uno di quelli. Quando ho iniziato il mio blog, un mio amico è finito in uno degli altri e mi ha fatto un commento che non capivo.
Fa pensare. Gente che mi conosce da tanto tempo ha seriamente creduto che io fossi un altro.

Sappiamo tutti che su Internet è facile non essere riconoscibile, nascondersi dietro ad un nickname, cambiare identità come Mattia Pascal e diventare un altro. E non impazziremo come Vitangelo Moscarda, perchè possiamo scegliere chi vogliamo essere. O annientare la nostra personalità quando vogliamo, per farla rinascere diversa su un altro blog.

Sembra il superamento di Pirandello, eppure l'impressione è che, se dovessi pensarci ancora un po', non so se riuscirei ad evitare il finale già scritto. E, comunque, sembra difficile tirarci fuori qualcosa di utile.

La soluzione potrebbe essere quella di spingersi ancora oltre: creare una comunità di Depa (non di recupero, una comunità virtuale, una community). Tutti i Depa ci si ritrovano e, rappresentando persone che sono o non sono, con diverse - tutte, potenzialmente - caratteristiche e le competenze, possono vivere tutte le vite virtuali che vogliono.
Il nome o il nick diventerebbe l'unico punto fermo comune tra tutti questi Depa.
Con enormi vantaggi:
- aumento delle visite sui rispettivi blog
- scambio di competenze
- possibilità di conoscere altre persone (senza sbagliare mai il nome, per giunta)
- marketing del proprio nome (che tende a diventare un brand)

Chiaramente potrebbe anche diventare una moda e dilagare: altri potrebbero voler variare il proprio nome in Depa (o semplicemente fingere di essere Depa - tanto su Internet...). Tempo qualche mese e si potrebbero avere milioni di Depa registrati.

Lo vedete anche voi, il business? Certo, ci vorrebbe un testimonial famoso. Esiste una risposta già pronta: Depa Billaba, maestra Jedi.

Tutto torna.

Esiste solo il rischio di essere sopraffatti dal fatto che la stessa idea possa essere utilizzata da chi si chiama Rossi...

Bye

Depa

Letteratura Fiabesca Applicata all'Informatica

2007-06-12T22:31:00.000+02:00

Suppongo siate in pochi ad essere a conoscenza del fatto che le fiabe e, più in generale, i racconti del folclore, sono classificabili secondo un sistema analitico, definito da Aarne e Thompson, che si sono presi la briga di leggersi migliaia di fiabe e di appiccicargli etichette tipo: AT 425A “Il mostro o animale come sposo”, o AT 0151 "Lezioni di musica da animali selvaggi".

Sarà anche probabile che non possa fregarvene di meno di questa notizia e che stiate già per cambiare blog, borbottando che cercherete di fare del vostro meglio per dimenticarvi queste inutili nozioni, come Sherlock Holmes quando Watson gli fece notare che la terra gira attorno al sole ("Uno studio in rosso").

Se decideste davvero di farlo sarebbe solo l'n-esima triste conferma che la scuola non prepara più come una volta, che stiamo perdendo l'interdisciplinarietà e potenziali Leonardo e Galileo, appiattiti in una bruttura informatico-virtuale, per la quale non dovrete stupirvi se incontrerete a breve qualcuno che, usando espressioni care al Manzoni, potrà giustamente apostrofarvi con nel mezzo, vile meccanico.
(se siete riusciti a sopravvivere alle contorsioni e forzature della frase precedente - n-esima triste conferma del fatto che la scuola non sa più insegnare a scrivere in italiano -, forse avrete anche speranze di salvarvi culturalmente, ma dovreste certamente preoccuparvi per potenziali problemi mentali latenti).

Quelli tra voi più illuminati ed abituati a ragionamenti elastici, invece, non si saranno certo fatti sfuggire l'evidente parallelismo tra questo tipo di tipizzazione e quella presente nei linguaggi di programmazione (converrete senza dubbio, invece, che sarebbe un po' forzato trovare somiglianze con i Design Pattern, per i quali potremmo, invece, spingerci a considerare lo Schema di Propp).

Sarà inoltre evidente a tutti che gli spunti provenienti da un umanesimo di alto livello adatti ad introdurre il mio contributo nell'arena della tipizzazione forte o debole nell'informatica avrebbero potuto essere molteplici (dal 'sono un tipo, anzi un topo' di Geronimo Stilton, ad approfondimenti su grammatiche e licenze poetiche, etc. etc.), ad ulteriore dimostrazione che non si tratta di un argomento ormai consunto, ma di parte integrante delle esigenze culturali fondamentali dell'uomo e, pertanto, degno di essere ancora una volta approfondito...

(per il mio e vostro bene, qualcuno mi tolga dalla testa lo scrittore barocco che sta suggerendo queste ultime righe, prima di continuare la lettura)

Prima di iniziare la tesi di laurea, pur conoscendo (ovviamente! spero non vi abbia neppure sfiorato il dubbio!) la differenza tra tipizzazione forte e debole (strong and weak o static and dynamic typing), avevo sempre affrontato il problema procedendo per istinto.

Esattamente al contrario del mio tutor, che usava il Common Lisp ricercando strutture e controlli sui tipi di dati come se stesse usando il C, io tendevo a programmare in modo volontariamente non tipizzato.

Quando due uomini forti si scontrano su argomenti così decisivi per il bene della comunità è quasi inevitabile che nasca una discussione (animata, ma divertente): io difendevo la flessibilità che un simile approccio poteva fornire (soprattutto in lisp e, caspita, se non si cerca il massimo della flessibilità proprio nell'AI...) e lui difendeva la correttezza formale ed il controllo a compile-time, necessario, in particolar modo, in caso di sistemi particolarmente complessi (e ulteriormente utile, nel caso si debba lavorare con risorse alle prime armi o quasi, per ridurre significativamente le probabilità di errori).

Ancora oggi, di fatto, mi piace ridurre al minimo i vincoli, soprattutto se posso fidarmi degli sviluppatori del team.
Mi piacciono e ritengo fondamentali i Generics, ma se programmo per mio divertimento (sia per attività AI-related che non), tendo a saltarli apposta e mi gioco con reflection, metadati, valutazione dinamica di espressioni e, in genere, di codice (e perchè no, generato automaticamente) ed ignoro i warning di non tipizzazione delle collection che rischiano di ridurre la flessibilità del mio sistema (ovviamente, il cast automatico delle classi è due volte essenziale).

Cerco la genericità anche a livello di database, nei pochi spazi concessi (se c'è un sistema giustamente tipizzato quello è il DB, converrete). Che so: quanto è meglio poter dire varchar2, al posto che varchar2(20)? oppure, e questo viene condiviso praticamente da tutti, quanto è bella la sintassi che permette di definire, in PL/SQL, una variabile come di tipo tabella.campo%TYPE? E, nonostante il rischio di ridotte performance (ma dipende dai casi) e la complessità nel costruire query dinamiche che siano anche solide, non posso evitare di essere attratto anche da questa ulteriore non tipizzazione.

Senza esagerare, chiaramente: non proponetemi campi di testo o LOB per contenere informazioni aggiuntive, neppure se state pensando di strutturarle in XML (anzi, peggio, se sono strutturate in XML - ma ne parlo un'altra volta, perchè i motivi non c'entrano con questo argomento).

Non sono un estremista, in questo senso: semplicemente ritengo, come in altri casi, che sia essenziale conoscere i pro e i contro di ogni approccio e che, evidentemente, le regole informatiche sono fatte per essere infrante, anche se solo quando si sa esattamente cosa si sta facendo, comprendendone appieno gli effetti collaterali.

Dobbiamo tener presente che siamo comunque costretti a trattare con la tipizzazione dinamica, anche perchè ne siamo circondati. Per esempio:

http: tutto è stringa (siamo noi che le riportiamo a tipi, una volta che estrapoliamo dalla request, cercando un mapping e binding più o meno esplicito, ma il protocollo non prevede altro)
Javascript: le dichiarazioni di tipo non esistono e possiamo cambiare allegramente il tipo dati (e nessuno dice che sia corretto o consigliabile o facilmente debuggabile - anzi, già che ci siamo: vi anticipo che ritengo che, laddove si usi Javascript lato client, sia veramente pericoloso ed inutile, per la povertà dell'ambiente di esecuzione, utilizzare coscientemente questa possibilità)
polimorfismo: nasce per migliorare il riutilizzo di codice: è una sorta di via di mezzo tra tipizzazione forte e debole, no? (tipizzate pure fortemente, tanto io vi referenzio ad un livello più astratto, meno caratterizzato, anche se proprio nelle vostre particolarità...). In realtà tende così tanto alla tipizzazione dinamica che non pochi linguaggi di ampio uso permettono quello che viene chiamato Duck Typing. Che ha un po' a che fare con l'induzione (ricado sempre nell'AI, non c'è verso...). Vi consiglio di approfondire in particolare l'estratto del precedente link riguardante il duck typing in Java e, in particolare, l'articolo di David Orme (il papà di Visual Editor Project di Eclipse) che riporta il pattern e i suoi dettagli implementativi
etc. etc.

Spingendo all'estremo l'interpretazione del concetto in esame fino alle generiche strutture dati, saltano agli occhi anche le seguenti alternative (da considerarsi come esempi non esaustivi):

ResultSet vs. Bean ORM: i ResultSet con i loro metadati sono una sorta di interfaccia non tipizzata (che, curiosamente, wrappa dati fortemente tipizzati), con ottimizzazioni basate sulla presenza di metadati, in contrapposizione ad un classico (da Hibernate, per intenderci) mapping tra tabelle e Java Bean
Bean vs. HashMap: si tratta di una alternativa simile alla precedente, che si può porre laddove preferiate non ricompilare, ma, piuttosto, gestire una configurazione, perdendo in controlli compile-time

Proviamo a ricordare, prendendo spunto dalla solita Wikipedia, le funzionalità principali che sono sostenute dalla tipizzazione forte:

sicurezza: il compilatore può già identificare codice errato, riducendo i costi di debugging. Posizioni estremiste arrivano a dire che una tipizzazione molto forte potrebbe evitare la gran parte degli errori del codice, nonostante l'esperienza insegni che, pur essendo indubbio il vantaggio fornito in questo senso, solitamente i bug più insidiosi non potranno mai essere individuati dal compilatore (anche perchè, nella maggioranza dei casi si tratterà di interpretazioni di business)
ottimizzazione: un controllo di tipo statico fornisce al compilatore informazioni fondamentali per creare codice più efficiente. Il vantaggio viene in parte compensato dal fatto che, mentre è innegabile che la generalizzazione implichi solitamente esecuzioni più complesse (quindi più lente - es.: reflection), è anche vero che richiede minori controlli per verificare che i tipi siano o meno rispettati. Inoltre, tipicamente, la tipizzazione debole richiede meno righe di codice sorgente, meno codice da rivisitare, cicli di edit-compile-test-debug ridotti.
documentazione: i tipi sicuramente aiutano ad indicare chiaramente le intenzioni del programmatore, migliorando complessivamente il passaggio di informazioni
astrazione e/o modularità: tipi complessi permettono ai programmatori di progettare ad un livello più elevato (es: stringhe e non array di bytes), semplificando la definizione delle interfacce tra componenti e sistemi. Migliorare la definizione delle interfacce è, ovviamente, particolarmente utile (meglio: fondamentale, inevitabile, basilare, essenziale, ...) nell'ambito della progettazione ad oggetti e nel caso di integrazioni con sistemi gestiti da altri team (con contratti chiari e fortemente tipizzati è più facile definire precisamente le responsabilità e ridurre i tempi complessivi, aumentando l'interoperabilità e riducendo le inconsistenze tra i sistemi).

Sempre la stessa voce della Wikipedia ricorda anche, però, che la tipizzazione dinamica si trova spesso nei linguaggi di scripting e nei linguaggi per il RAD (Rapid Application Development)

Per quanto riguarda i linguaggi di scripting, rimanderei alla conversazione tra Bill Venners e Guido van Rossum (il creatore d Python), veramente interessante sia da un punto di vista di progettazione software che da un punto di vista di gestione tecnica di progetto, un must sull'argomento, anche se, come me, non userete mai Python in vita vostra (a meno che non vi paghino bene, intendo...) e non sarete completamente d'accordo con Van Rossum: casomai non lo aveste già capito, personalmente sono per lo strong typing (soprattutto per progetti grossi, team giovani e laddove ci siano molte integrazioni), ma con tante scappatoie per poter lavorare in modo veloce e flessibile, tipiche di un weak o duck typing - leggermente più dinamico rispetto alla posizione espressa da alcuni esponenti di Microsoft, ma non troppo.

Per quanto concerne il RAD: qualcuno potrebbe sostenere che dire 'se volete programmare velocemente, usate dynamic typing' sia una visione errata dello sviluppo veloce, perchè si basa su una ipotesi di partenza che non considera la manutenzione, ma, sostanzialmente, si ferma alla prototipazione e/o primissimi rilasci, senza considerare che, quando cresce la complessità del sistema, è molto facile che si creino errori.
Questa considerazione è vera solo fino al punto in cui si presuppone che chi sta usando il sistema non si accorga del pericolo e non sappia cosa sta facendo. Cosa che può capitare, come già anticipato, se il progetto è grande e composto da molte risorse junior.
Certo che, se si riesce ad impostare un ragionevole modo di lavorare e un controllo appena decente, si possono ottenere tutti i vantaggi della R di RAD e ridurre a quasi nulla i possibili svantaggi.
Non è vero che i costi di controllo sono il prezzo da pagare: quelli fatti bene, con caratteristiche simili a quelli che servono in questo caso, dovrebbero esistere comunque (altrimenti i problemi non tarderanno a farsi vedere, con o senza strong typing).

Ovvero, per dirla con Bruce Eckel (che da anni, oramai, cerca di farci diventare poliglotti informatici), non abbiamo bisogno tanto di una forte tipizzazione, quanto di forti test.
Sorvolando sul fatto che, evidentemente, in Italia la parola test non è facile da tradurre e che, quindi, la frase precedente potrebbe non essere capita da tutti... ;)

La stessa dicotomia non può che porsi anche ad un livello architetturale più alto, come ben evidenziato dalla diatriba tra SOA e REST. Riporterò solo un interessante pezzo tradotto a braccio da un famoso articolo di Steve Vinoski:

Ironicamente, il fatto che SOA prescriva specifici contratti per le interfacce, di fatto insidia il suo obiettivo di separare l'interfaccia dall'implementazione, perchè interfacce specifiche tendono a rivelare più della sottostante implementazione di quanto facciano le interfacce generiche. Inoltre, interfacce specifiche - per definizione - vincolano la loro implementazione perchè modificarle spesso richiede dei cambiamenti nell'interfaccia. [...]
Stranamente, alcuni degli architetti e sviluppatori che conosco che lavorano su grandi sistemi SOA (come quelli di aziende nel campo delle telecomunicazioni e della finanza) si sono inventati per conto proprio i vincoli dell'interfaccia uniforme, senza aver mai sentito parlare del REST. Sfortunatamente l'hanno fatto nel modo più complesso, sviluppando e consegnando dapprima interfacce specifiche per un servizio e poi notando cosa si rompeva quando i loro sistemi crescevano in scala.

Direi che, per ora, mi sembra sufficiente, per farci meditare ancora sull'infinita saggezza popolare nascosta da secoli nella fiaba (della tipizzazione) del (brutto) anatroccolo...

Bye

Depa

Condivisione e Collaborazione

2007-06-06T00:23:00.000+02:00

I commenti relativi alla mancanza di rete durante i viaggi che ho letto (almeno io) su questo blog mi hanno fatto pensare.

Forse ha ragione chi sostiene che stiamo andando verso una società Web centrica, in cui l'accesso ad Internet sarà importante come l'energia elettrica?

A parte il fatto che, tolta l'energia elettrica, salta anche l'accesso ad Internet, mentre non vale (ancora) il viceversa, a parte il fatto che chi legge questo blog si sta preparando anche alla mancanza di corrente, effettivamente il fatto di non poter usufruire di Internet ovunque si fa già sentire (problemi da fighetti, peraltro, se ci scappa il pensiero, tra un click e l'altro, che non si può usufruire ovunque di cibo e pace).

Certamente è corretta la nota di James Fallows che ci ricorda come ancora non si viva online e che, quando manca la connessione, smettiamo di essere Homo Conexus e, per tutti gli scopi pratici, il Web 2.0 diventa Web 0.0.

Possiamo metterci una patch?
Ma soprattutto, ci serve davvero virtualizzare le nostre applicazioni sul Web?
Perchè?

Sempre a far domande, quando basta selezionare 'Leggi tutto'...

Da due giorni sto usando il blocco note di Google.
E' un simpatico oggetto che esiste su Web, ma rende meglio se viene anche installato sul PC come estensione di IE o Firefox.
Permette di prendere appunti mentre si naviga: basta selezionare il testo che interessa, tasto destro del mouse, invia al blocco note di Google.
Il testo selezionato e relativa url della pagina compaiono in una finestrella in popup. Possiamo aggiungere inostri commenti e catalogare il tutto.
Con vari livelli di sicurezza e/o condivisione con il resto del sistema solare ed altre galassie, che possiamo controllare da preferenze.

Ovviamente non è l'unico strumento del genere (questo post ne riporta altri - tra cui Zoho notebook che sembra dare un paglione a tutti, in quanto a feature e che cercherò di valutare nei prossimi giorni).
La scelta tra tutti, però, potrebbe anche essere guidata dal fatto che forse avete già la Google toolbar, forse avete già qualche account in GMail, etc. etc.

Ora, tutti quegli appunti mi servirebbero anche off-line (per esempio, per aiutarmi a scrivere un post come questo).
Mi servirebbe anche poterne scrivere altri in treno, dove non ho la connessione (potete scriverne anche a manina, non siete obbligati a ritagliarli dal Web).
Il primo problema sarebbe anche apparentemente banale da risolvere: basta andare sul block notes e salvare la pagina in locale. E se le pagine iniziano a salire in numero e dimensione? E se voleste farci su una ricerchina?
Off-line ho spesso anche bisogno del mio blog o di quello di altri, da consultare: per gestire diverse pagine di informazioni, con ragionevoli dimensioni e pur mantenendo la possibilità di fare una ricerca, ci pensa già il mio feed reader (oramai IE 7, per semplificare la selva di programmi che popolano il mio PC) a gestire tutte queste caratteristiche.
Ma se non posso tradurre la mia applicazione in feed?
E resta sempre aperto il problema di inserire e modificare off-line.

Beh, Google, come per tutti gli altri suoi prodotti, fornisce delle API (Java e non solo) per interagire programmaticamente con il blocco note (tra i suoi concorrenti, solo il su citato Zoho mantiene una marcatura stretta, fornendo non solo una suite alternativa per l'office, ma anche API per molti prodotti - non ancora per il suo blocco note, però...).

Questa è una possibile strada per patchare il problema del Web0.0: se non fossimo pigri (come al solito aspetteremo che lo faccia qualcun altro, così poi lo downloadiamo), potremmo farci il nostro client per lavorare off-line, sincronizzarci periodicamente, etc. etc.

Un po' come è già in grado di fare Calgoo con Google Calendar: mantenete scrupolosamente i vostri impegni su Google, ma avete un appuntamento nel deserto o in Siberia? Dovete ripassare gli impegni in treno? Avete dimenticato il cellulare (!!!! questo davvero non può più capitare, la prossima volta lascerete a casa la testa? cosa le fanno a fare tutte quelle pubblicità, se poi non vi ricordate neppure di spendere?) o comunque rischiate di non ricevere l'SMS che aspettate?
Sincronizzatevi.

E c'è qualcosa anche per Blogger? Giusto per rispondere a quelli che continuano a parlare di Wordpress e Splinder...
Ci sarà anche, ma io ho trovato solo le API, le solite API, che certamente già conoscete (fatemi sapere, se trovate dei tool decenti per amministrarlo da scollegati).

E, per continuare con gli esempi: YouTube? C'è modo di vedere i filmati offline? Ci sarebbe Democracy Player, ma siccome già sapete cosa ne penso, vi suggerisco di leggervi questo post. Se non vi fidate di siti intermedi, ci sono anche procedure manuali e script...

Vorrei scaricarmi anche la Wikipedia, ma c'è qualche giga di XML da importare... magari conviene aspettare la prossima release del Web, al posto che applicare la patch, in questo caso...

E comunque non avremo ancora bisogno di queste pezze per molto, no? Voglio dire: quanto ancora mancherà al poter usare ovunque Internet? Anche in metrò, intendo.
Ad essere onesti, per una fruibilità completa in metrò servirebbe anche qualcosa in più della connessione Web: es. PC grossi come un lettore di MP3 (o, comunque, indossabili), meglio se con Virtual Retinal Display o altri simili wearable display e riconoscimento vocale al posto della tastiera, perchè sulla verde non si riesce ad aprire un notebook, senza rischiare di farselo rompere alla prima frenata in ore di punta. Ma questo è un altro discorso...

Eppure, non sono così sicuro di voler lasciare anche le mie informazioni private su Google: mi va bene dipendere dal Web, inteso come insieme di siti e servizi, ma (se e) quando il servizio diventerà a pagamento, mi piacerebbe poter scegliere di far tornare l'informazione sul mio PC.

Anche perchè faccio fatica a capire perchè un foglio elettronico dovrebbe stare su Web, se non deve essere condiviso ed elaborato in collaborazione. Certo, possiamo pensare ai vantaggi della virtualizzazione, ad una architettura a stella in cui il Web è il centro, raggiungibile da tutti i nostri PC e palmari.

Personalmente credo poco a questa esigenza, che mi sembra più legata a difficoltà di sincronizzazione, che alla reale necessità di centralizzazione.
Senza aggiungere le considerazioni architetturali:

single point of failure nel centro della stella: siccome non stiamo parlando dell'intero Web (che nasce proprio, fin dai tempi di ARPANET per sopperire a simili problemi, distribuendo l'informazione e ridondandola, per evitare che un attacco nucleare potesse fermare le attività), ma di una applicazione specifica, non è inusuale che il servizio non sia garantito

per raggiungere il centro della stella serve il collegamento: se questo non è disponibile, non accediamo a nessuna delle nostre risorse

Questi motivi si aggiungono ai precedenti per suggerire backup e sincronizzazioni periodiche (non vi sto dicendo di non virtualizzarvi, sto dicendo di prestare attenzione e non fidarvi troppo).
Senza considerare che oggi potete ben spostare facilmente il vostro backup su una chiavetta, che basta inserire nel PC su cui andrete a lavorare.
Inoltre ci sarebbe da chiedersi perchè si usano tanti PC. Essenzialmente si tratta di limiti di risorse (alternativamente di distinzione tra lavoro e casa, ma è quasi lo stesso problema, scavando bene). Non è che, all'aumentare delle risorse, tornerà a scomparire l'esigenza di avere certe applicazioni online?

Certo, ha più senso se la vediamo dal punto di vista dell'erogatore, che può usare il servizio pubblico come pubblicità per i tool facilmente utilizzabili anche all'interno di Intranet (quindi rivendibili alle aziende), dove la collaborazione e la condivisione dei documenti è, semmai, un problema in quanto difficile da realizzare. E i vari office online coprono bene questa esigenza (oltre a quella di una riduzione dei costi dei vari pacchetti e loro installazioni).

Forse conviene, per avere un quadro complessivo, tornare ai fondamentali e richiedersi, per l'n-esima volta (perchè non impariamo mai), cosa porta in più la tecnologia Web, rispetto a quelle precedenti:

Unica installazione centralizzata e facilità di manutenzione (e riduzione complessiva dei costi, sia di manutenzione che di licenza): a parte il fatto che i tool di cui stiamo parlando (es: blocchi note vari) rendono meglio con una installazione sul browser (quindi, lato client, perdendo parte del vantaggio), dobbiamo notare che, nella maggioranza delle applicazioni professionali, anche in un paradigma client-server i client verifica(vano) l'esistenza di upgrade centralizzati e si re-installa(va)no (le parentesi sui tempi dei verbi sono, ovviamente, dovute al fatto che Internet non ha eliminato queste esigenze: molti programmi ancora oggi si comportano in questo modo, aggiornandosi da soli).

Interfaccia utente (GUI) standard e intuitiva: siccome siamo grandi, abbiamo già capito da alcuni anni che 'zero training' era solo l'n-esimo slogan marketing e che questo vantaggio, in gran parte legato alla specifica progettazione/realizzazione, non era impossibile da ottenere con altre tecnologie; inutile negare, poi, che in gran parte, deve il suo reale successo ad una pratica mancanza di alternative (Flex, Java FX e altre simili proposte RIA (Rich Internet Application), porteranno effettivi vantaggi? Meglio cambiare, no? ...no...? meglio, almeno, poter scegliere? se ne sta parlando molto, l'approfondiremo una delle prossime volte....

Trasferimento lungo reti con banda limitata e connessione non garantita: vantaggio indubbio dell'http, con effetti che ancora oggi si fa fatica a spiegare ad alcuni clienti e che si cerca di bypassare con AJAX e simili approcci (ma, se è vero che possiamo dare una maggiore interazione, l'effetto è sempre quello di non trasferire tutti i dati tutti assieme, ma di paginarli - eventualmente nascondendo tale paginazione all'utente - e di aumentare il numero delle richieste al server - con relativo aumento di carico e necessità di hardware centrali relativamente potenti -, per fare le stesse cose)

Condivisione e collaborazione: e questa la commento dopo, visto che sono anni che la ripeto e che ritengo che sia il reale plus aggiunto dalla rete, quello che basterebbe da solo a renderla vincente

Nella condivisione e collaborazione possiamo far entrare, giusto per esemplificare, non solo i social network, ma l'intero concetto di Intranet ed Extranet, la stessa virtualizzazione del proprio posto di lavoro (condividi con te stesso, ma sempre condividi), la possibilità di collaborazioni distribuite di elaborazione (Web Services, architetture SOA, Web 2.0, relativi mashup e compagnia bella) e anche tool oramai parte della vita di tutti i giorni, quali i motori di ricerca e la loro capacità di integrare le diverse fonti.

Tutti i progetti di successo su tecnologia Web-like degli ultimi anni si basano su questi concetti e tutte le volte che si è usata una simile tecnologia per realizzare una applicazione gestionale classica, senza puntare verso questi obiettivi aggiuntivi, si è solo riscontrato quanto fosse più facile e meno costoso usare PowerBuilder ed il vecchio VB. E pensare che, come dicevo sopra, la mancanza di collaborazione e condivisione di Know-how, almeno per la mia personale esperienza, è forse uno dei problemi principali di ogni azienda (con ripercussioni in costi più o meno evidenti in ogni fase del processo produttivo, nella retention del personale e al momento dell'ingresso di nuove risorse).

Tornando alle nostre applicazioni virtualizzate, provando ad analizzarle secondo i vantaggi sopra elencati, talvolta mi viene da pensare: se penso ad un Calendar online non mi convince la sola fruibilità da più PC, perchè basterebbe EssentialPim o Calgoo su una chiavetta. Anche la condivisione del calendario con altri utenti l'aveva già Outlook (o Lotus Notes) una decina di anni fa.

La differenza è nella mancanza (per il momento) del costo di licenza e nel fatto che il server è fruibile su Internet, portando a vantaggi quando si debba collaborare e condividere informazioni a grande distanza (che so, io viaggio e la mia segretaria aggiorna i miei impegni, poi quando arrivo vedo il Calendar aggiornato, ma lo consulto anche in aereo, nel frattempo, se l'ho sincronizzato in locale, mentre il resto del mio team sa che oggi non sarà in ufficio - ora non mi resta che trovare una segretaria...). Distanze grosse (ovvero, reti non affidabili e con poca banda) non possono essere coperte da Outlook o Notes, ma le basi logiche si trovano già in quei prodotti.

I veri vantaggi, però, li si vedono ancora quando i servizi permettono un completo sharing:
- i motori di ricerca mi mettono in relazione con il resto del mondo (e le traduzioni integrate, che certamente devono migliorare, mi permettono anche, tra una risata e l'altra, di comprendere il senso di siti in russo, che, altrimenti, mi sarebbe totalmente oscuro)
- i social network permettono di condividere risorse (testi, presentazioni, video, link, contatti, competenze, etc. etc.), conoscenze ed opinioni, in modo molto diverso dagli altri media
- le aziende possono ricevere immediati feedback impliciti ed espliciti dai loro clienti finali, dai loro collaboratori e dai loro partner, condividendo know-how e riducendo i costi di produzione, migliorando l'efficienza delle comunicazioni interne
- repository centralizzati permettono di far evolvere insieme (e trovare) prodotti ed iniziative (es: Wikipedia) così interessanti da diventare indispensabili
- etc. etc.

La condivisione e la collaborazione con gli altri (non la virtualizzazione di noi stessi) è la vera differenza.

Bye

Depa

Pendolari

2007-05-28T23:51:00.000+02:00

Non capisco, forse abbiamo forato.
Un meccanico è chino vicino alle ruote del locomotore, prima di rimontarle.
Un altro sta scuotendo la testa.
Ora guarda per terra.
Noi guardiamo verso il cielo, invece.

Quando inizia il caldo capita che un locomotore salti.
E' questione di fortuna e questa settimana siamo stati fortunati più di una volta.

Forse la ventola di raffreddamento della CPU non è sufficiente per raffreddare il motore?

Non si sa quanto potrà ritardare, ovviamente.
Non lo dicono fino ai primi 30 minuti.
Quando sono passati da un po' scrivono che il treno ritarderà di 30 minuti.

Inoltre rischio di entrare in crisi di astinenza: perchè i treni in Italia non hanno Internet come in Giappone?
Ah, già, aumenterebbe la necessità di dissipazione...

Si dice che Douglas Adams, l'autore della trilogia in 5 parti (Fondamentalmente innocuo era presentato come: 'un libro che da un senso completamente nuovo alla parola trilogia') della Guida Galattica per gli Autostoppisti scrivesse spesso in areoporto.
O era Terry Pratchett , il suo corrispondente nel mondo fantasy, autore del ciclo del Mondo Disco? (carina la H2G2, quasi la uso al posto della Wikipedia).

Hemingway era sempre in giro.
Noi grandi scrittori siamo tutti pendolari.
Prendete Dante, ad esempio: la Divina Commedia l'ha finita girando di tavola in tavola, - come sa di sale lo pane altrui -, anticipando di secoli i commentatori gastronomici.

Dove vado a parare? Continuate a leggere...

Non ho finito gli argomenti (vi piacerebbe...) e non ho neppure un finale a sorpresa.
Semplicemente la scorsa settimana lavorativa si è distinta per due viaggi allucinanti da far rivedere gli aggettivi ad Otto Klement ed Asimov e volevo che anche voi ne subiste gli effetti nefandi.

L'abstract, ovviamente, non era parte della cronaca, ma una rivisitazione psicologica.
O forse un riassunto logico.
Fate un po' voi...

Primo giorno:

in biglietteria non possono farmi il supplemento, perchè il computer non glie lo permette:
'forse perchè il suo treno viene da Firenze e oggi hanno fatto sciopero, in Toscana...'
'veramente viene da Venezia'
'allora deve essere cambiato il materiale, da qui non possiamo farglielo, chieda al capotreno...'
primo capotreno: 'no, è solo che ci sono 3 carrozze che non hanno l'aria condizionata...' (il treno in questione è svizzero e non prevede che non funzioni l'aria condizionata: i finestrini sono sigillati, il calore è insopportabile)
Secondo capotreno: 'spostatevi alla 9, che là funziona' (in realtà anche la carrozza in questione seguiva gli standard dell'intero treno)
si parte... ci si ferma alla prima stazione... il locomotore tira gli ultimi, treno soppresso
aspettiamo quello successivo (ma quelli che dovevano raggiungere Ginevra? Saranno più fortunati, visto che il treno, secondo l'altoparlante, è soppresso da Milano a Domodossola? a Domo si trasferisce con il teletrasporto?)

Secondo giorno:

questa volta il biglietto ce lo fanno
ma il treno non vuole partire, almeno finchè non è passata un'ora e ci si sta per trasferire sul successivo (arriverà, stavolta?)
suspence: ci si ferma in mezzo alla campagna. Annuncio: 'questo treno subirà un ulteriore ritardo di 20 minuti perchè a non-mi-ricordo-più-dove-caspita-era si è rotto un locomotore e non si può passare'
secondo giorno alle 22:45, al posto che alle 20:30 (sono io che non so contare o 22:45-20:30 >> 1 ora + 20 minuti? Mi sono perso qualcosa?)

Poi vi chiedete perchè sono sempre arrabbiato.
Ci sarà la vita su altri pianeti, o solo ferrovie?

Bye

Depa

Non ci resta che piangere

2007-05-17T00:07:00.000+02:00

Iniziamo subito con ringraziamenti al Presidente per aver ispirato questo post in tutti i suoi punti essenziali.

Ovviamente non parlo di Napolitano, ma del Presidente di una squadra di basket che non citerò apposta.

Con il Presidente si parla dei due suoi sport preferiti e di viaggi.
Potrebbe anche cercare di parlare di vela, ma, datemi retta, se vi capita, portatelo sul basket: fin da piccolo mi hanno insegnato l'importanza della passione per uno sport e la potreste vedere personificata ed alimentata indipendentemente da ogni possibile risultato.

Lo so che cito sempre Wodehouse (il genio è genio e se può dire la sua su ogni argomento, è bene che ne siate resi partecipi), ma è necessario che leggiate dei suoi personaggi che cercano di ridurre l'handicap a golf, per capire cosa io stia intendendo (suggerisco The heart of a Goof, per iniziare su questo argomento).

I viaggi oggetto dei nostri discorsi, solitamente, sono di due tipi: quello che facciamo quasi quotidianamente in treno e quelli veri, da vacanza (lui può godere di una consulenza professionale, a questo proposito, io, solitamente, decido un po' dopo il last minute).

Ma questa volta si è parlato di viaggi nel tempo e della nostra capacità di infrangere legalmente ogni brevetto, casomai ci si dovesse trovare nella situazione proposta dal ben noto film.

Il che fornisce solo un'altra prova del fatto che il mio Anonimo amico del post del Codice dei Wooster avesse ragione sul mio stato mentale. Per quello del Presidente, garantisco io.

A me sono venute subito in mente le patate. Se abbiamo passato il 1500, allora Colombo aveva già scoperto l'America e le aveva già portate.
E' vero, il film si concentra su tempi immediatamente precedenti alla partenza di Colombo, ma basta aspettare qualche anno e, intanto, preparare gli strumenti fondamentali per utilizzarle.

A parte la possibilità di mettere su una rete commerciale con i tedeschi e l'opportunità di battere McDonald sul tempo, le patate mi sono venute in mente grazie agli studi fatti da piccolo: il 'Manuale di Archimede', come ben sapranno tutti quelli che hanno solide basi teorico-pratiche, insegnava, infatti, che è possibile produrre elettricità collegando 12 (o erano 7?) patate con del filo di rame e dei morsetti infilati nei tuberi in questione. Ora, è evidente che nel 1500 il rame esisteva: ancora oggi lo si può estrarre dalle pentole dei nostri nonni. Serve solo qualcuno che sia in grado di ridurlo ad un filo. E il fabbro c'era già, nel 1500. Basta trovarne uno sveglio, convincerlo con un business plan fatto bene...

Il Presidente, però, mi ha distrutto in 3 secondi, mostrandomi la mia scarsa attitudine all'industrializzazione: anche se stiamo aspettando il ritorno di Colombo possiamo comunque produrre elettricità, e molta di più di quella ottenibile nel modo precedente: basta costruirsi un generatore eolico.

Se avete fatto un salto sulla poltroncina del treno, come è capitato a me, evidentemente non avete letto questo articolo (fornito, ovviamente, dal Presidente, come prova di non millantare conoscenze inesistenti).

Oppure non siete in treno. Il funzionamento è ovvio, quasi non vi serve portarvi il pdf nel 1500, basta usare l'induzione elettromagnetica: i magneti c'erano già, il vento pure, il filo di rame lo costruisce il solito fabbro, il rotore un falegname (bisognerà dividere in 3, ma i guadagni saranno molto superiori, rispetto alle patate).
Fate attenzione, si tratta di un oggetto piuttosto pericoloso per persone e cose, costruitelo solo se sapete cosa state facendo. Conoscendovi, peraltro, vi suggerirei di procedere solo se vi trovate improvvisamente nel 1400 quasi 1500 e volete far vedere chi siete - ma attenti a non essere incriminati per stregoneria.

Ora che avete la vostra corrente elettrica, a parte il cercare di costruire lampadine (ma sarà necessario creare il vuoto, attorno al filamento? qualcuno sa come fare?), potete più facilmente iniziare la vostra attività di venditori di hamburger, con piastre e friggitrici elettriche.

Chiaramente il Presidente, con una trovata simile, vince a mani basse. Inutile cercare di ricordare il capitano J.T.Kirk e la sua capacità di trovare sempre una via d'uscita, con particolare riferimento all'episodio in cui costruisce un cannone e polvere da sparo, ricordando studi elementari di chimica.
A noi, a chimica, anche all'Università, non hanno insegnato a preparare la polvere da sparo, ma ricordo che si era parlato di pile e che non sembrava difficile costruirne una. Siamo in grado di rifare la polvere da sparo? Qualcuno ricorda se c'era già, nel periodo considerato? Vi rispondo io (anzi, la Wikipedia, al solito): non pensateci neppure, era conosciuta già dal XIV sec., in Europa (in Cina dal 1100-1200).
A parte questo, vorrei proprio vedere se, lasciati a voi stessi, sareste in grado di riconoscere il nitrato di potassio (posso ancora capire lo zolfo e il carbone...).

Una pila avrebbe la possibilità di generare corrente continua e stabilizzata in modo più semplice rispetto al generatore eolico.
Ma davvero, ha notato subito il Presidente, difendendo la sua inattaccabile vittoria, vogliamo iniziare a portare indietro energie non rinnovabili? E cosa volete rispondergli? Quando uno ha ragione, ha ragione.

Sono certo che esistono altre idee semplicemente realizzabili anche con quella tecnologia di base, che sarebbe possibile portare indietro.

Visto che c'è il Giro d'Italia, viene facilmente in mente che reinventare la bici dovrebbe essere più facile che inventare il treno: probabilmente non avremmo neppure bisogno di Leonardo.
Cercate di seguirmi, perchè qui si fanno i soldi: fatto partire il Giro d'Italia, potreste anche inventare la pubblicità da mettere sulle magliette. Da qui al marketing è un passo (gli facciamo più male con le pile, o con questi concetti?)

Visto che faremo un sacco di soldi, potremmo inventare le banche? Acc... no, già presenti nel 1406...forse gli mancavano le assicurazioni (certo che potrebbe non convenire puntare troppo sulle assicurazioni sulla vita in quel periodo e anche l'RC Auto è difficilmente applicabile alle carrozze).

Che ne dite di partecipare anche voi, fornendo a tutti, tramite commenti, altri possibili link e suggerimenti relativi alla costruzione di manufatti, per ogni evenienza?
Che so:
- qualcuno di voi sa come fare la plastica e la gomma? (potrebbero servire per proporre dei servizi di raccolta differenziata dei rifiuti, tra l'altro).
- sapreste come rifare il ferro da stiro? (pensate a quei poveretti che, nel passato non avendo il loro bel ferro a vapore, non potevano impegnarsi in questa simpatica operazione ed uscivano tutti sgualciti, con l'effetto collaterale di... quale caspita di problema c'è ad uscire con i vestiti spiegazzati? non ci saremo mica creati un problema da soli?)

Ah, già, poi non ci resterebbe che trovare il modo di viaggiare nel tempo, sapendo che Dr.Who è solo un telefilm.
Potremmo ottenere informazioni su esperimenti in questo senso al NIAC, se non rischiasse la chiusura...
Bye

Depa
P.S.: ma davvero li pagavano anche per studiare i viaggi nel tempo? E poi ci alzano le tasse...

Reti di parole su CD

2007-05-09T23:53:00.000+02:00

Oggi vi parlerò di CD.
No, non di musica. Nemmeno del supporto di memorizzazione: sono un informatico ma non devo parlare continuamente di tracciati record e simili.

CD sta per Conceptual Dependency ed è una delle tecnologie dell'Intelligenza Artificiale alla base della comprensione del linguaggio (NLP = Natural Language Processing).

Hey, ma dove andate? Se rimanete vi parlo anche di Wordnet. Fermi...

E adesso? Scrivo lo stesso, anche se sono rimasto solo?
Ma sì, dai, tanto prima o poi qualcuno arriva per sbaglio e legge anche questo.

Anche se stavolta sarò noiosissimo, così imparate a non stare qui ad interagire con me, per mantenermi su binari ragionevoli.

E non vi chiederete più perchè c'è voluto così tanto tempo dall'ultimo post.

Tu prova ad avere un mondo nel cuore
e non riesci ad esprimerlo con le parole
[...]
E sì, anche tu andresti a cercare
le parole sicure per farti ascoltare:
per stupire mezz'ora basta un libro di storia,
io cercai di imparare la Treccani a memoria,
[...]
[Il matto - De Andrè - Da Non al denaro, non all'amore, nè al cielo]

Alla fine degli anni '60, più o meno quando io stavo nascendo, Roger C. Schank e suoi collaboratori della Stanford University iniziarono a pubblicare i loro lavori riguardo alla Conceptual Dependency (CD), sostanzialmente mostrando come si poteva costruire un parser per il linguaggio naturale, in grado di elaborare frasi fornite in input, disambiguandone i concetti e generando una rappresentazione del significato, utilizzando una grammatica che mettesse in evidenza la semantica.

Schank partiva dal concetto che si potesse analizzare il modo di comprendere tipico degli esseri umani per trovare algoritmi e rappresentazioni indipendenti dal linguaggio per la comprensione dei computer.
CD come analogia di rappresentazione mentale.

Uno dei vantaggi di un approccio simile è che una stessa rappresentazione può anche riassumere diverse rappresentazioni sintattiche (in italiano: frasi diverse con lo stesso significato avrebbero la stessa rappresentazione), con ovvie conseguenze nella semplificazione dell'elaborazione dei concetti espressi e, più in generale, per operare delle inferenze.

Tra l'altro, una volta ottenuta una rappresentazione non ambigua e semantica di una frase o di un testo più complesso ci si trova nella posizione giusta per poter ottenere anche una parafrasi della frase stessa, eventuali riassunti e anche per cercare di operare traduzioni in altre lingue. O, al contrario, sarebbe possibile partire dai concetti, per generare storie.

La potenza dell'approccio proposto è stata mostrata attraverso parecchie applicazioni, negli anni seguenti, ma, nonostante siano passati quasi 40 anni non troverete molti traduttori commerciali basati su questa tecnologia.

Troverete, invece, tecnologie ancora precedenti, decisamente più semplici (per esempio basate sulla frequenza di comparsa delle parole nelle frasi), ma significativamente potenziate dall'attuale potenza di calcolo.

Ma se la CD potrebbe permettere di ottenere risultati decisamente superiori a quella della maggior parte dei più comuni traduttori automatici, che non hanno la pretesa di capire alcunchè, come mai questa tecnologia non si è diffusa nei prodotti commerciali?
Essenzialmente perchè implica la presenza di una notevole base di conoscenza che sia in grado di definire, data una parola, una serie di attese sulle parole precedenti e quelle seguenti, di cancellare tali pretese quando non si trovano corrispondenze e di confermarle nel caso siano logicamente coerenti con il resto della frase o del testo.

Per fare un veloce esempio di parte della conoscenza necessaria, consideriamo la seguente frase (presa da uno degli articoli e volutamente semplice e semplificata: tenete presente che la CD si applica anche a frasi complesse con coordinate e subordinate - diverse fonti su Internet vi permetteranno di ottenere approfondimenti e introduzioni riguardo alle primitive della CD ed esistono anche esempi di come venivano memorizzate in lisp le strutture dati nei primi programmi alla base della CD):
Il grande uomo ruba il libro rosso alla ragazza

Il: può servire per connettere frasi, per esempio potrebbe essere che la prarola cui si riferisce trovi una corrispondenza in una frase precedente

grande: si riferisce ad un concetto che potrebbe necessitare di ulteriori approfondimenti concettuali (come aggettivo, potrebbe presupporre l'esistenza di un sostantivo seguente - situazione che, di fatto, viene confermata dalla continuazione della frase)

uomo: può esistere da solo e viene completato dalle parole precedenti, quindi è possibile costruire un aggregato basato su questo termine

ruba: individua una azione e ha bisogno di un soggetto e di un complemento. Legandola al concetto precedente (possibile perchè sul piano grammaticale concorda), permette di costruire una proposizione riguardo ad un attore: esiste una dipendenza bidirezionale tra 'ruba' e 'uomo', che stanno sullo stesso piano (almeno, questo è quanto dice Schank nei primi articoli, ma ne riparliamo)

il-libro-rosso: senza ripercorrere le singole parole, devono esistere regole sintattiche, grammaticali ed attese semantiche che permettano di legarli per creare un concetto, secondo quanto visto prima e una attesa generata dal verbo 'ruba' prevede che ci sia un oggetto da rubare e questo concetto è coerente con questa attesa

alla-ragazza: qui si trova un ulteriore tipo di relazione, che non staremo qui a dettagliare, ma che lega questi termini al libro rosso, attraverso attese generate sempre dal verbo rubare (si ruba qualcosa a qualcuno)

Fino a questo punto le competenze sembrano essere, come sopra indicato, grammaticali, sintattiche e, solo parzialmente, semantiche.
Una analisi ulteriore della stessa frase, e da un approfondimento dell'algoritmo alla base del parser (come, per esempio, in uno dei primi articoli, ma, meglio, in "Inside Computer Understanding: Five Programs Plus Miniatures" - Roger C. Schank e Christopher K. Riesbeck - 1981) si vede che, almeno per questa
frase, il tutto si potrebbe anche ridurre ad una sorta di analisi logica, basata su posizioni relative delle parole e preposizioni più o meno articolate. Almeno nel contesto ridotto su cui Schank lavorava ai tempi (poche centinaia di parole).

E, comunque, ricordatemi di proporvi di realizzare un programma in grado di elaborare una analisi logica, alla fine di questo post...

La semantica, al di là dell'ultra-semplificato-esempio-sopra-riportato, è necessaria per identificare stranezze nella frase:
La casa volava da Milano a Roma
rispetto a
L'aereo volava da Milano a Roma
E i programmi di Schank potevano anche notare queste stranezze e operare ulteriori inferenze.

Ma la CD è solo la partenza, solo il substrato: per disambiguare servono anche altri concetti, serve una conoscenza del mondo e della sequenzialità delle operazioni standard (script, per Schank - es: se il Depa va al ristorante, ordina una bistecca, più tardi paga ed esce soddisfatto, come fate a sapere che ha mangiato la
bistecca, dal momento che non ve l'ho detto? Perchè avete delle attese sui comportamenti e sulla sequenzialità degli stessi, in situazioni standard) che ci si attendono in certi ambiti, una conoscenza degli obiettivi (goal) e una identificazione dei piani per raggiungere tali obiettivi, etc. etc.

Serve un po' di senso comune, insomma. Tutt'altro che banale, visto che ne sembra spesso sprovvista anche la maggior parte degli umani.

Uno dei limiti degli approcci di Schank, ai tempi, era la dimensione della base dati (certamente dettata dalle ridotte capacità elaborative di 40 anni fa, ma anche dalla mancanza quasi totale di progetti volti a generare simili tipologie di informazioni).
E' estremamente dispendioso codificare tutta la competenza necessaria per una comprensione soddisfacente, ma certo potrebbe già essere utile riuscire a gestire un primo livello di relazioni tra le parole, adatto per evitare di cadere in traduzioni automatiche orrende come quelle in cui si incorrerebbe passando questo testo sotto il filtro di Babelfish o compagnia bella.

Basterebbe una rete semantica, che gestisca le principali relazioni tra le parole, senza necessità di scendere al livello della fisica quantistica. Per esempio, il cane è un animale è una relazione tra un iponimo (cane) ed un iperonimo (animale). Una relazione IS-A o, in termini più comprensibili per chiunque sappia vagamente programmare, si potrebbe dire che 'cane' eredita da 'animale'. (O ne implementa l'interfaccia, che sarebbe meglio, per evitare il fragile base class problem e simili). E le parole sono correlate tra loro
anche in altri modi (sinonimi, meronimi, etc. etc.).

Particolarmente interessante è la sinonimia, che deve essere considerata nella sua accezione semantica corretta.

Per es., il lemma prova può significare:
- evidenza, riscontro
- test, esame
- concorso
- compito
- cimento, impresa
- assaggio
etc. etc.

Notiamo che ho usato dei sinonimi (scelti a caso, senza pretesa di completezza e correttezza) per illustrare, almeno con una prima approssimazione, i diversi significati, le possibili semantiche della parola presa in considerazione. Il che ci porta a pensare che i sinonimi siano un buon punto di partenza per poi disambiguare.

Questi stessi sinonimi, se messi uno di fila all'altro (come fa Sinonimi Master, forse il più completo ed utilizzabile insieme di sinonimi italiani che mi è capitato di trovare su Internet), sarebbero stati molto meno utili.
Li ho, invece, raggruppati in insiemi di sinonimi (cui dovremmo aggiungere il lemma di partenza), non a caso: si parla di synset (contrazione di synonyms set) e questo concetto è alla base di reti semantiche come Wordnet.

Quest'ultimo sì, è sicuramente free e di elevatissimo livello.
Sarebbe bello averne uno anche per l'italiano e per altre lingue, certo sarebbe ancora meglio se fosse possibile averlo già in relazione con la versione inglese.

Beh, la buona notizia è che ce ne sono almeno 2: EuroWordNet e MultiWordNet (dovesse interessarvi un semplice confronto tra le due...). La cattiva è che non sono free, neppure per scopi personali, nè Open Source.

Ora, sarebbe interessante continuare, parlando di:
- come CD e (Euro)WordNet possano convergere verso un sistema che possa, almeno, cercare di fare una prima analisi dei testi, con migliori speranze di prenderci rispetto alla maggior parte dei sistemi di larga diffusione
- come alcuni abbiano già fatto qualcosa di simile, se non altro in ambito più ristretto (che so: vi siete resi conto che una grande parte della Knowledge Base di Microsoft in italiano risulta tradotta automaticamente? Il risultato non è malissimo - non perfetto, ma non male - e si basa su concetti simili a quelli indicati, almeno per la costruzione di MindNet una rete semantica simile a Wordnet, ottenuta, tra l'altro, automaticamente, attraverso parsing di vocabolari ed enciclopedie elettroniche)
- come sia possibile cercare di costruire una simile rete semantica, in modo pseudo-automatico
- come non sia così facile mettere in relazione diretta i synset di linguaggi differenti (per esempio, a causa dei gap lessicali)

Sarebbe interessante, ma mi avete lasciato solo.
Volete conoscere l'assassino? Gli accessi a questo articolo devono essere tanti e differenziati...

Bye

Depa

Il codice dei Wooster

2007-04-24T09:03:00.000+02:00

Scusate se mi sono assentato ancora per lungo tempo.
Questa volta non è stato per lavoro, nè per distrazione.
E' stata una moderazione di un commento, che ha prosciugato le mie ore rimanenti. Non lo vedrete pubblicato per il tono, non per le idee - ho chiesto che venisse cambiato il primo, mantenendo le seconde, ma non c'è stato verso.

Mi dovrei sentire come un vecchio e rompiballe Catone?
Ma no, si tratta di far valere dei codici di comportamento, come è capitato già in altri momenti nella storia dell'umanità, importanti almeno quanto questo blog.

I cavalieri (almeno quelli della letteratura) avevano un codice d'onore, per esempio.
Non possono essere descritti senza caratterizzarli sulla base del loro impegno in questo senso.
Non è un caso che in AD&D i paladini debbano essere lawful good.
Qualcuno potrebbe citare il comportamento non immacolato di Lancillotto, ma sarebbe troppo facile ricordare che basterebbe l'estrema purezza di Galahad per bilanciare quello scivolone.

E non taceremo certo Cyrano (guascone e non cavaliere, ma è di codici di comportamento che stiamo parlando) e la sua limpidezza:

E quando a sera entrerò in quel di Dio, spazzerà il mio saluto l'azzurro
sfavillìo e offrirò, con l'orgoglio che mai macchiai né macchio, l'indomita
purezza del…
[ROSSANA: Del...?]
... mio pennacchio [Muore]
(dalla traduzione di Oreste Lionello, usata per doppiare un grandissimo Gerard Depardieu).

Per non parlare del codice dei Wooster.
Via, davvero non sapete cosa sia? Mi prendete in giro?
Al contrario, conoscete tutto del codice di condotta dei blogger a cui sta lavorando Tim O'Reilly? E stavate pensando che è a quello che mi volevo riferire? (ma per chi mi prendete?)

Non penserete di poter andare avanti così ancora per molto, vero?
Se volete parlarne, prima che sia troppo tardi, continuate a leggere e usate i commenti, che sono sempre abilitati, per farvi sentire.

Fu allora che madonna gli disse: "Hai gli occhi belli
vorrei che accarezzassi stanotte i miei capelli"
Fu allora che rispose: "Grazie madonna no!
Io sono un cavaliere e il re non tradirò"
E a lei non valse niente comprare la memoria
di sentinelle e servi mandati a far baldoria
[...]
E a lui non valse a niente il sangue sui castelli
Rocroi, la spada e il sole sul viso nei duelli
quando sentì di dire di dover dire sì
con un cavallo e l'acqua fu cacciato di lì.
[Vecchioni, La leggenda di Olaf]

Vecchioni scrive di cavalieri, sogni e valore, e li contrappone ad ubriachi, realtà e comportamenti discutibili.
Li interpreta con straziante ironia: come Petrarca, è lacerato da questi (e altri) dualismi interni.
Ma il codice morale è per lui comunque prioritario e irrinunciabile, alla fine.

Come lo è per il Cavaliere inesistente di Calvino, animato dalla volontà e dalla purezza rappresentata dalla sua armatura tutta bianca; solo una righina nera correva torno torno ai bordi (la righina nera è una piccola macchia sul comportamento immacolato o è il confine oltre il quale il bianco non riesce a spingersi?)

Che dire del comportamento impeccabile dei cavalieri Jedi? (non quelli che abbracciano il lato oscuro, ovviamente). Anche se mi piacciono molto, non sono un tale fan della serie cinematografica da ricordare le battute a memoria: posso solo avanzare vaghe rimembranze di un codice quasi filosofico/religioso, ma non ricordo accenni espliciti a mantenere un certo tipo di comportamento. Credo, comunque, che se immaginassimo un codice di cavalleria anche per i Jedi non ci attireremo sguardi oscuri e perplessi da parte di nessuno.

Anche le persone normali, spesso, ne seguono uno.

Bertie Wilberforce Wooster non è una persona normale.
A partire dal secondo nome (Wilberforce: ho sempre pensato che Wodehouse si vendicasse sui suoi personaggi per essere stato chiamato Pelham Grenville: non deve essere stato facile a scuola, da piccolo).

Bertie è un signorotto che vive di rendita, ma è anche un discendente di un cavaliere che ha fatto la sua parte alle Crociate.
E si sente fortemente vincolato dal codice d'onore cavalleresco che gli deriva dal suo antenato.
Al punto di non poter rifiutare una richiesta di matrimonio (in realtà, solitamente svariate richieste di matrimonio, tipicamente tutte assieme) generata da giovani bellissime insopportabili donne che gli chiedono di sposarle solo per ripicca nei confronti del loro ex.

Vorrebbe rimanere un eterno scapolo, ma il codice è il codice e non si può fare soffrire una ragazza.

Quando segui simili regole, sei costretto ad accettare anche se il loro ex, chiaramente almeno pugile dilettante della dimensione di un armadio a quattro ante, ti farà a pezzi, per poi camminare sui resti con gli scarponi chiodati.
E fortuna che c'è Jeeves, il maggiordomo per antonomasia (quello che ha dato il nome al motore di ricerca Ask Jeeves). Jeeves sa tutto, cita Shakespeare, la Bibbia ed altri classici come se piovesse, sempre in modo appropriato e senza bisogno di Internet per avere conferme. E sa usare tutta la sua brillante intelligenza per togliere dagli impicci il povero Bertie.

Visto che non lo conoscevate, vi tocca pure, dopo la spiegazione data sopra, sentire cosa vi siete persi finora, non leggendo Wodehouse, dalla viva voce (?) di due grandi autori:

Quella di Wodehouse è pura musica in parole [...] Non ha bisogno di essere serio, perchè è al di sopra di queste distinzioni. E' nella stratosfera delle grandi creazioni umane, al di sopra della tragedia e del pensiero forte; è la dove troviamo Bach, Mozart, Einstein, Feynman e Louis Amstrong: nel regno del puro gioco creativo.[Douglas Adams - Dall'introduzione a Sunset at Blandings, leggibile, in italiano, ne Il salmone del dubbio di Douglas Adams - a proposito, mi hanno detto che quando Windows Vista si spegne, cita un libro dell'autore della Guida Galattica]

Cosa si può dire di Wodehouse? Esaurisce i superlativi. Non sono il solo a credere che lui sia arrivato più di ogni altro scrittore inglese ad avvicinare la completa padronanza e trascendenza del linguaggio di Shakespeare.[Stephen Fry]

Ora che lo sapete non potete perdervelo: iniziate da qualche libro su Jeeves, o da Zio Fred in primavera (che è il mio preferito, anche se non parla di Jeeves, ma del Castello di Blandings).
Fermi lì, dove state andando? Era ovvio che dovrete iniziare dopo aver finito di leggere questo post.

Pochi sono gli esempi di cavalleria che potremmo citare nei nostri giorni (i TG parlano spesso del cavaliere, ma non è usato nel senso inteso in questo post).

Ma ecco che, quando da tempo, come il Don Chisciotte di Guccini, potremmo dire che di eroici cavalieri non abbiamo più notizia, Aramis (guardate la foto piccola a sinistra sul suo blog e ditemi se sono io che me lo immagino perchè sono troppo immerso in questo testo o se non è davvero lui, come tutti lo avete sempre immaginato - ma che razza di obiezione è ma che Aramis, non vedi che è in t-shirt?, scusate?) arriva a proporre questo suo codice.

E' ancora in Draft, in piena discussione.
Pensando al recente impegno di questo novello campione della morale, non riesco a fare a meno di immaginarmi i Templari, che discutono il draft del loro codice di cavalleria, dopo aver passato il giusto periodo di pubblicazione sul W3C: 'no, dai, il suo cuore conosce solo la virtù no... suona un po' troppo enfatico, rimaniamo sui fatti, la spada che difende i bisognosi, l'ira che si abbatte sui malvagi...').

Va beh. Già che ci siamo diciamo due parole su questa proposta e sulle prime lezioni che dice di aver imparato.
Intanto chiariamo subito che, come a molti di voi, non mi piace la stella dello sceriffo (ma non ho ben capito se sia già stata cassata: poteva risparmiarsela e l'ha capito da solo). Dietro ai loghi di questo tipo ci sono valorizzazioni marketing e commerciali, che possono sfociare in creazioni di nuovi bisogni e corrispondenti servizi, simili, per fare un esempio, alle certificazioni di qualità. Insopportabile, comunque, almeno per me, che insista (forse anche perchè penso che cerchi di vendermi qualcosa che non esiste, come se fosse un pezzo di terra in Second Life).

Una cosa è gradire qualcosa, un'altra è addirittura indignarsi per simili stemmini, come dice sia emerso dai commenti che ha ricevuto: si indigna giustamente anche lui, di rimando: che senso ha? stelle di sceriffo ne mettiamo tutti, con disclaimer e con meccanismi di moderazione vari...

Concordo, invece, sul bel suggerimento del meccanismo di voto per indicare un commento inappropriato, che lo nasconde, ma non lo cancella (ci sono piattaforme per i blog che già lo fanno? Voi che usate splinder o wordpress...). Sarebbe stata la mia scelta preferita, nel caso citato nell'abstract di questo articolo.

Qui credo finisca la mia empatia con O'Reilly su questo discorso. Proviamo, comunque a riassumere i vari punti della proposta iniziale:

Responsabilità per le proprie parole e per quelle che permettiamo nei commenti del blog: elenca alcune casistiche e su una parte non si può che essere d'accordo (comuque dovrebbero essere comportamenti già sanciti per legge, almeno in Italia - diffamazioni, infrangimenti di copyright, obblighi di segretezza violati, violazioni di privacy). Ma il contenuto inaccettabile, nonostante la lista, è fin troppo poco chiaro e destinato ad una interpretazione soggettiva. Come formalizzare in un codice tali aspetti? Inoltre il contenuto e la sua forma sono due cose differenti: le idee, almeno a parer mio, non dovrebbero essere fermate, ma solo espresse civilmente: quelle a noi opposte non potranno che farci crescere
Non diremo nulla online che non diremo di persona: è un po' eccessivo. Se lo si fa rientrare nel punto precedente (ma allora diventa inutile), potrebbe anche essere sensato, ma in senso assoluto impedisce certi tipi di approcci che sono proprio tipici del mezzo.
Senza esagerazioni.
Ci metteremo in contatto privatamente, prima di rispondere di persona: e come caspita si fa? A parte il non conoscere le info di contatto dell'interlocutore, nella maggioranza dei casi, ma che razza di carico ci si rischia di sobbarcare? O'Reilly avrà anche una redazione di supporto, ma voi e io, che già impegnamo le nostre nottate per poter scrivere queste due righe? (smettetela di fare ironia sul conteggio dei miei accessi, l'impegno sarebbe notevolissimo). Ben volentieri laddove sia importante, interessante e possibile (come nel caso che mi ha impegnato così tanto e che citavo), ma un impegno così profondo non è alla portata di tutti. Tim, hai forse paura della mia concorrenza?
Prenderemo delle azioni se qualcuno attacca un altro in modo ingiusto: qui potremmo dargli anche ragione - la spada che difende i bisognosi, l'ira che si abbatte sui malvagi. Resterebbe sempre il dubbio della definizione di un attacco ingiusto, ma è quanto facciamo con le moderazioni ai commenti. Solo che, con la stella dello sceriffo sul petto, potremmo essere apostrofati per non aver fatto il nostro dovere da chi ha una visione diversa dalla nostra. E aumenterebbero ancora di più gli sforzi di moderazione, in un loop che potrebbe non finire.
Non ammetteremo commenti anonimi: o bella, perchè mai? Una volta attivata la moderazione, perchè non permettere i commenti anonimi? Ne parla anche lui nelle 'lezioni imparate', ma insiste... A mio modo di vedere servono per permettere ai più timidi ed insicuri di far sentire la propria voce: rientrano, quindi, nella difesa dei deboli
Ignoreremo i trolls: sarà anche un metodo per liberarsene, ma personalmente ritengo che sia meglio parlarci. Non necessariamente direttamente sul blog. Non lasciando via libera agli insulti. Uno svantaggio: aumento dell'impegno necessario, come in un punto precedente. Vero, allora cogliamo il suggerimento e lasciamoci aperta la possibilità di ignorarli quando siamo sommersi dal lavoro.

Il vero punto, a mio parere, è che un codice non va scritto e condiviso, ma va vissuto, sentito, interiorizzato.
Come il codice dei Wooster: non troveremo mai il foglio con l'elenco dei punti da seguire, perchè è un modo di vivere e di comportarsi (l'esistenza dell'antenato, solo una scusa).
O, al limite, come l'Olaf di Vecchioni, che supera il vincolo formale facendolo proprio.

Mettere le stelline sul proprio blog sarebbe come scrivere da soli il proprio nome nella lista dei buoni, alla lavagna: non serve a nulla se non li siamo davvero, anzi.

Bye

Depa

Giochiamo

2007-04-17T23:15:00.000+02:00

Second Life. Vita alternativa. Fuga dalla realtà. Realtà ricostruita. Nowhere place in cui abbiamo il coraggio di rischiare, perchè non perdiamo nulla. Nowhere man. Incontri. Giochi.
L'homo ludens ha bisogno di estraniarsi. Recupera tempo al lavoro e, al posto che spenderlo nella vita, gioca.
Un po' come me, con questo blog, quanto sto giocando?
Avremmo ben altre cose più importanti da fare.
Esistono obiettivi assoluti e, invece, perdiamo tempo a giocare.

Siccome continuo ad essere adamantino nella mia ricerca di tali obiettivi e non mi lascio distrarre da nulla, non gioco mica, io.

Mi diverto di più a programmarli, i videogiochi.
Dopo il lavoro, per estraniarmi dall'informatica.

Da piccolino, correva l'anno (scolastico) 1982-1983, iniziai a programmare.
Seguii un corso, consigliato da un compagno di classe.
Ai tempi i PC non erano diffusi. Quasi non esistevano.
Infatti, io immaginavo di trovarmi di fronte ad una specie di armadio, con tante lucine colorate, bocche metalliche da cui doveva uscire un rotolo di carta, nastri che continuavano ad avvolgersi ininterrottamente.
Un po' come il computer di Spazio 1999 (mi piaceva, l'ho visto di recente, che tristezza...).

Invece no. Un VIC 20. 1,5K di RAM.
Un corso impostato molto bene: flow-chart fin dal primo giorno (e che altro volevate, con 1,5K? Più si sta lontani dal televisore - non monitor, televisore -, meno se ne vedono i limiti).

Alla fine ero convinto di saper programmare.
I miei cedettero e mi comprarono uno Spectrum (ma davvero, chiesi ai miei insegnanti, può arrivare a 48K? Con 8 colori e con i suoni? E il controllo sul singolo pixel? Beh, se c'è scritto su Byte, sarà vero).

Cosa fa un ragazzino che sa programmare, con il suo nuovo PC? Si programma Pac-Man, ovviamente.
Scoprii che non sapevo programmare.
Ci persi dietro tutta l'estate, per imparare a farlo (beh, insomma...).
Ben prima della fine dell'estate il mio Pac-Man aveva 5 livelli e 1 fantasma che mi inseguiva con cattiveria inusitata (al livello 5 mi mangiava in 7 secondi, alla faccia della giocabilità).

Programmai anche un gioco di una rana che stava su una foglia e doveva cercare di saltare, mangiarsi gli insetti che passavano, senza essere divorata da un improbabile uccello (rappresentato da 3 asterischi, lo ricordo ancora) e senza cadere in acqua.

Tradussi un bellissimo gioco che trovai su un giornale (in inglese) scritto per lo ZX81.
Mi insegnò che si possono creare n stanze, completamente differenti ogni volta che si gioca, completamente identiche ogni volta che si entra e si esce all'interno della stessa partita, dovendo memorizzare un solo byte di informazione.
Il seed della funzione random, ovviamente.

L'anno dopo, per riuscire a programmare un videogioco di corse di automobili, con scrolling verticale della strada, fui costretto ad imparare l'assembler dello Z80.

L'anno dopo lessi il famoso testo di Hofstadter sull'AI e persi la testa (ma questa è un'altra storia).

Non ho mai smesso, però, di programmare videogiochi, per divertimento.

E solo perchè non mi lasciano farlo per lavoro: non avete idea di quanto mi piacerebbe poter essere responsabile di un progetto simile, della durata di 5 anni, con un team di 20 persone, con background culturali e talenti totalmente differenti.

E, marketing o non marketing, se funziona o no, se piace o no, lo si capisce.
Perchè la programmazione di videogiochi, ha dentro grandi complessità.
Enormi complessità logiche.
E' una sfida continua. (il fatto che la vincano sempre loro è un'altra questione).

Ovvio che, ancora oggi, sia interessato dalla notizia dell'uscita dalla beta di uno YouTube per i videogiochi, che si chiama Kongregate.
Ovvio che sia deluso: ma si può, accettare solo videogiochi in Flash? I primi in cui mi sono imbattuto avevano pure una grafica da sito.
Che tristezza.

Tanto per tanto, quasi mi divertirebbe di più partecipare alla comunità di GameMaker.
GameMaker, oggi arrivato alla versione 7, è un simpatico strumento, creato da un professore universitario (o dalle tesi dei suoi studenti?), che permette di sviluppare giochi semplici in modo semplice, senza programmare (seguendo un modello ad eventi e utilizzando delle iconcine, come comandi), e giochi più complessi programmando (ad oggetti, con qualche limitazione).
Ne esiste una versione free, con un po' di funzionalità disabilitate, ma con quelle abilitate si possono già fare cose serie.
E tra quelle abilitate ne troverete una che permette di postare il vostro gioco sul sito della community.

E' famoso, GameMaker. Mi ha fatto divertire, fin dalla versione 5. Se programmare con lui è un po' come giocare a Tetris, a me serve qualcosa di rapportabile ad Oblivion (per la mia rabbia enorme mi servono giganti avrebbe detto Cyrano - va beh, Oblivion forse è un po' troppo, non ho così tanto tempo libero da dedicare alla programmazione di videogiochi, ma spero abbiate capito il concetto).

Fortuna che c'è Java e, soprattutto, che c'è un altro professore, Andrew Davison, che ha pubblicato online le primissime versioni di un suo bellissimo libro: Killer Game Programming in Java.

Che inizia spiegando che è ora di piantarla di dire che serve per forza il C, per andar veloci.
Che scrive una appendice che spiega cosa cercare, quando si scava nella Garbage Collection.
Che prosegue spiegandovi tutto sui timer di Java (con fare universitario, quindi esagera pure).
Che vi porta a fare, passo passo, in nemmeno 12 capitoli, giochi in 2D, come applicazioni (full screen e windowed), applet e Java Web Start.
Con una pretesa di framework (termine un po' eccessivo, nel caso specifico), con musica, side scrolling, Sprite.
Fino ai giochi isometrici tile-based.
Il tutto condito con diagrammi UML, così se non sapete progettare e programmare, lo imparate (scherzo: se non sapete programmare e progettare non riuscite neppure a leggerlo, questo libro).

Per chi sopravvive ai primi capitoli (non dovrebbe essere impossibile), ce ne sono molti di più sulla programmazione con Java3D (con chicca sulla generazione di alberi che crescono).
Per chi regge anche questi (non è da tutti), ci sono i capitoli sui controlli di input non standard (dalla Webcam, al Gamepad, al controllo del braccio dell'omino del videogioco con il nostro braccio destro, al guanto per la realtà virtuale, che certamente avrete tutti a casa).
E poi, JOGL (wrapper attorno ad OpenGL), giochi in rete, J2ME, Bluetooth, Mobile3D.
Serve altro?

Consigliato a chi pensa di conoscere Java.
Me compreso.

Bye

Depa
P.S.: comunque potrebbe essere interessante mettersi a fare un framework che frulli assieme dei tool simil-GameMaker con le possibilità evidenziate dal testo di Davison...

Soldi facili

2007-04-11T23:59:00.000+02:00

E' un periodo che continuo ad inciampare in articoli che spiegano come far rendere economicamente un blog. C'è un tale Pavlina che sostiene di essere riuscito a monetizzare circa $4 al giorno dopo 6 mesi, $3000 al mese dopo 15 mesi e, in un crescendo wagneriano, fino a $1000 al giorno dopo 19 mesi.

Chi, come voi, mi segue assiduamente, sarà leggermente frastornato dopo le posizioni prese in Keep in Touch.
Il Depa, vi starete dicendo, dopo aver colto i veri valori della vita, sta decadendo verso argomenti vili e materiali.
Ancora domenica, insistete, parlava di religione e oggi cosa mi fa?
Non si possono seguire due padroni, no? Alla faccia della coerenza.

Calma, calma. Il grillo parlante ce l'ho già, nella mia testa, senza che vi mettiate in fila pure voi.
A spingere, pure.

Facciamo così: io, come al solito, scrivo, di seguito, il corpo di questo post.
Voi e la mia coscienza, se ne avete voglia, continuate a leggere e, se avete qualcosa da ribattere, scrivetela nei commenti, al posto che borbottare come fate sempre.

Se state leggendo queste righe vuol dire che le mie toccanti parole dell'abstract hanno fatto breccia nei vostri cuoricini. Lo si capisce perchè gli occhi sono lo specchio dell'anima e sulle vostre iridi vedo ancora stampata la scritta $1000 al giorno (al giorno va a capo, perchè non ci sta, su una sola riga, sull'occhio, ammesso che non siate cinesi).

Immagino che i più attenti di voi abbiano anche considerato che un blog è attivo per 365 giorni all'anno. Quelli più saggi avranno anche impostato la tara e, sapendo che nei weekend l'accesso è circa la metà rispetto ai giorni feriali (chi gestisce una azienda si tranquillizzi, ci sono dei picchi al mattino presto e prima e dopo il pasto, durante le altre ore lavorative è decisamente ridotto - va beh, qualche pausa caffè...), avranno calcolato che non è che sia poi così male un ricavo di $300.000 (trecentomila) circa, all'anno...

E come caspita si fa?

Beh, intanto, certo non con gli accessi che ho io al momento...

Poi, probabilmente, siccome è evidente che esisterà una qualche proporzionalità con il numero di unique visitor, sarebbe utile scrivere in inglese: facendo le dovute proporzioni tra lettori inglesi e italiani a quanti euro potrei puntare? Mi converrà rimettermi a studiare inglese (lo conosco e ho anche gestito progetti in inglese, ma certo non penserete che sia in grado di scrivere simili proposizioni ipotattiche anche in altre lingue, vero?) o contattare uno che mi traduca i post in inglese? Oppure basterà mettere su la traduzione automatica? (fermi tutti, di traduzioni parleremo in prossimi post, non distraetemi con altri argomenti...)

Cerchiamo di approfondire i possibili modelli di business e i calcoli reali, poi ci pensiamo...

Possibili ingressi:
- pubblicità (AD)
- affiliate
- richiesta di donazioni
- vendita di prodotti
- richieste di consulenza
- [c'è altro?...]

Piccola digressione sulla pubblicità: pare ci sia chi si lamenta, se sul blog compaiono gli AD. Ma stiamo scherzando? E che, a casa mia non posso fare quello che voglio? Non avete pensato a quanto sarebbe più piacevole la vostra lettura, se avessi il tempo di limare questi testi, al posto che scriverli in tutta fretta, offline, in treno? Non avete pensato che se avessi dei soldini da investire sul blog potrei fornirvi informazioni straordinarie, sia per il vostro business che per i vostri momenti liberi? Calmatevi, intanto non li ho ancora messi, poi continuate a leggere, che ne riparleremo...

Il nobiluomo citato nell'abstract si chiede se tutti sono in grado di guadagnare altrettanto, dai blog. Si risponde che non ci riesce il 99% dei blogger. La mette sul piano del ci riescono solo quelli che sono in gamba (usa smart, non ho voluto infierire, con la traduzione).

Pare, inoltre, che la condizione essenziale sia quella di capire i principali meccanismi del Web (leggeteveli, non ripeterò la lista).

Interessante che non si fermi a solo quelli più semplici, noti a quasi ogni Web Designer, ma vengano citati anche database e sistemi di pagamento on-line. Chissà quanti soldi potrebbe fare chi dovesse conoscere qualche modalità di utilizzo in più di Java e architetture multilayer basate su WS, Web 2.0 e Web semantico? In effetti, tutti gli autori in lingua inglese sembrano chiarire che più si sa dei mezzi a disposizione, più è facile fare soldi... a differenza di molti manager delle nostre aziende, che sono in grado di sostenere che conoscere la materia è notoriamente un impedimento al business, - non voglio addentrarmi in questo argomento, me lo lascio per un altro giorno, quando avrò voglia di tirare un po' di scherma.

Bisogna anche fare un piano. Di business o strategico. Un piano è qualcosa che sembra che tutti vogliono evitare, di recente (per esempio, provate a nominare questa parola ad un sostenitore dei metodi di produzione di software agyle... fermiamoci ancora, sembra che non riesca a fare a meno che fare un sommario di prossimi argomenti di post, oggi).
Eppure, per quanto sia facile che un piano fallisca, come diceva qualcuno che non ricordo, è sempre meglio avere un piano che non averlo.
Almeno si prende una direzione e si vede se la si sta seguendo o se si sta andando alla deriva. E poi si cerca di cambiare il piano ed adeguarlo.

Prima di redigere il nostro, partiamo dal traffico.
Il tipo che guadagna $1000 al giorno, dichiara anche di aver avuto, al mese 1,1 milioni di visitatori e 2,4 milioni di page views.
Ovvero, circa 1 dollaro ogni 1000 visitatori o ogni 2400 page view.
Al momento il mio sito riporta un po' più di 850 visitatori al mese, se riuscissi a farlo rendere in proporzione al suo (ma sicuramente renderebbe meno, perchè il suo è certamente ottimizzato), potrei già portare a casina circa un caffè senza brioche al mese. No, a ripensarci, ci dovrei pagare le tasse, mi resta una rotella di liquirizia (dimezzeranno anche i suoi 1000 dollaroni, come capiterebbe qui, in USA?)
Acc... bisognerà fare qualcosa per migliorare...

Per cercare di capire se possiamo migliorare, iniziamo a vedere se sono numeri sensati, in Italia.

Secondo Alexa (per quello che vale, lo sappiamo, certamente misura meglio siti USA, non misura tutto, etc. etc., ma è quanto di meglio abbiamo a disposizione free - fornitemi altri indirizzi, se ne conoscete), il sito di StevePavlina, a spanne, fa dalle 6 alle 12 volte le page view di Beppe Grillo (e dalle 12 alle 24 volte quelle di Pandemia e Macchianera).
Acc... bisognerà passare ad una traduzione all'inglese? Possiamo solo sperare in un massimo intorno ai 100 euro al giorno? (che poi sarebbero tagliati a 50 dalle solite tasse?) Perdiamo 900 dollari al giorno solo perchè non sappiamo l'inglese? Credo che, se dovesse crescere il traffico, converrebbe seguirlo, quel corso (costava meno di 900 dollari al giorno, o ricordo male?)

I dati di Pavlina sono compatibili con i CPC (Cost Per Click)? Beh, abbastanza. Se immaginiamo che ci siano 10 impression per pagina, considerato che un rapporto sensato tra click e impression potrebbe essere del 2%, potremmo calcolare, su 2,4 milioni di pagine, 24 milioni di impression, 480.000 click. I CPC (pagati a chi li eroga, non a chi ne ospita la pubblicazione sul proprio blog) variano tra 0,01 a 0,5 euro circa, secondo il link sopra riportato. Stiamo parlando di un range di 4800-24000 dollari al giorno (sempre per l'erogatore). Se un 20-25% viene pagato all'autore del blog, otteniamo circa i valori che dice Pavlina). Siccome credo che le percentuali siano inferiori, per bilanciare la differenza servirà ottenere il fatturato da modalità diverse dal solo advertising. Credo.

Qualcuno mi sa dare informazioni più precise?

Secondo Pavlina il fatturato è proporzionale al traffico. Ci tocca inventare modi diversi per guadagnare con il blog?
Acc... (dobbiamo sperare nella richiesta di consulenza?)

Comunque sia, per fare traffico e guadagnarci i nostri 50 euro al giorno netti (che sono sempre 15000 netti all'anno, che, se non bastano per arricchirsi e convincerci a lasciare il lavoro, comunque potrebbero aiutare), bisogna partire creando valore. Come per ogni tipologia di vendita.
Se aveste letto, per fare un esempio, Il libretto rosso del grande venditore di Jeffrey Gitomer, ne sareste convinti e, come sto facendo io, stareste cercando di cambiare la vostra figura professionale, da tecnicaccio puro a qualcosa di vicino ad un venditore o ad un uomo marketing, cercando di regalare valore. Perchè regalando valore si ottiene valore in cambio.
E' il solito libro fuffa per i soliti creduloni? Sarà, ma a me è riuscito a vendere l'idea e quasi me ne compravo un altro, se non avessi capito che, se già riuscissi a mettere in fila i suggerimenti di quello, sarebbe comunque un buon inizio.
E non è facile, sono proprio negato per farlo, non è nel mio DNA. Ma mi hanno detto che l'homo sapiens sapiens impara, quindi cercherò di continuare a sbatterci la testa fino a che non otterrò qualcosa o mi convincerò definitivamente di non riuscirci. Per ora sono ancora convinto che sia alla mia portata. Sono il solito presuntuoso.
E comunque mi sto divertendo.

In più, a quanto pare, le impostazioni di un grande venditore, sono fortemente improntate all'etica, e questo mi piace: non sopporto quelli che cercano di vendere fumo, ammiro chi sa valorizzare le cose di valore.

Tornando al valore, credo di poter raccontare qualcosa di utile. Un po' troppa roba per ogni articolo, ma se cercate bene, vedrete che troverete anche qualcosa che vi può servire. Come in soffitta.

Su, vediamo cosa ci suggerisce il nostro amico Pavlina per incrementare il traffico: all'inizio, potrebbe essere d'aiuto un Blog Carnival. E che caspita è? Avevo sentito parlare di Blog rings, ma blog carnival... forse bisogna andare in Brasile? Ce ne saranno anche in Italia? Da una ricerca su Google non ne ho trovati (in inglese sì, in italiano no). Acc...

Ragazzi, torniamo alla considerazione di prima: se non si diventa inglesi, non si fanno i soldi.

Questo post mi ha richiesto 4 ore. Per ora può rendere qualche centesimo al mese.

Soldi facili.

Se attivassi gli AD farei contento chi sta spingendo il Web 2.0 per ottenere i vantaggi della coda lunga di cui ho già parlato, ma, salvo che abbia sbagliato i conti (niente di più facile, peraltro) anche teoricamente non mi sembra che possa essermi utile, al momento.
Non mi resta che continuare per divertimento, poi ne riparleremo tra qualche mese.

Bye

Depa
P.S.: coscienza mia, hai ancora qualcosa da dire? Certo, lo so anch'io che se leggessi Dante sarebbe meglio di Gitomer, ma... insomma, mi lasci parlare, almeno per una volta?

Kerygma

2007-04-08T22:22:00.000+02:00

Prima di tutto vi ho trasmesso l'insegnamento che anch'io ho ricevuto, Cristo è
morto per i nostri peccati, come è scritto nella Bibbia, ed è stato sepolto. E'
resuscitato il terzo giorno, come è scritto nella Bibbia.
[San Paolo, prima lettera ai Corinzi - 15,3-4]

La prima lettera ai Corinzi è stata scritta tra il 54 ed il 57 d.C., ma i versetti (in tutto il post uso la traduzione interconfessionale, ovvero accolta da tutte le diverse confessioni cristiane, tratta da La Bibbia in lingua corrente) fanno riferimento ad una precedente predicazione di Paolo, probabilmente avvenuta intorno al 51 d.C.

L'estratto riportato è una delle forme di Kerygma, parola con la quale gli studiosi indicano quel messaggio sintetico ed essenziale che i primi apostoli usarono per diffondere la buona notizia che avevano ricevuto da Cristo. Un messaggio semplice, se rapportato al dogma, ma fondamentale per chiarezza e contenuto.

Non sono io la persona più adatta ad approfondire il senso di queste parole: semplicemente io credo in questa testimonianza e voglio qui ricordarla.

Data la mia ignoranza in materia, mi baserò parecchio su alcuni testi.
Tra questi, ovviamente, quelli di Messori (consiglio veramente a tutti, anche ai non credenti, Ipotesi su Gesù, Patì sotto Ponzio Pilato? e Dicono che è risorto), ma anche altri approfondimenti reperibili in rete, tra cui vi segnalo, in particolare, una serie di pdf, che citano estratti di documenti molto interessanti.
Si tratta, in entrambi i casi, di approfondimenti seri e logici, senza prese di posizione enfatiche, retoriche o acritiche come se ne trovano talvolta in altri testi cattolici - pur importanti per chi crede, ingenerano spesso l'impressione di estremismo, ingenuità e forzatura in chi ha dei dubbi o negli scettici.

Un simile annuncio, individuato dagli studiosi perchè lingua e stile utilizzate non corrispondono al contesto, è ripetuto anche in altri punti del nuovo testamento, (es.: prima lettera ai Tessalonicesi, lo scritto più antico del cristianesimo, - non successivo al 52 d.C., che tramanda formule risalenti anche a 5-10 anni dopo la morte di Gesù; discorsi kerigmatici degli Atti degli apostoli: 2,14-36; 3,12-26; 4,8-12; 5,29-32; 10,34-43; 13,16-41; 17,18-31). E' segno di una testimonianza collettiva, con espressioni probabilmente concordate per una azione più corale ed efficace.

E' la testimonianza immediata (le date sopra fornite sono condivise oramai dalla quasi totalità degli studiosi, anche quelli non credenti - anzi, in alcuni casi nascono proprio dai loro studi) della resurrezione di Cristo, è, fin da subito, la base fondante del cristianesimo.

Testimonianza rilasciata all'interno della società ebraica, in una cultura ed un periodo storico che mettono in grossa difficoltà chi ritiene che la figura di Cristo sia stata totalmente inventata (scuola mitica) o, comunque, divinizzata posteriormente, a partire da una vicenda storica (scuola critica).
In breve, la difficoltà nasce dal fatto che non ci sarebbero i tempi minimi perchè si possano, storicamente e logicamente, creare i presupposti previsti dalle due scuole - non per nulla sia la scuola critica che quella mitica cercano di posizionare il più possibile lontano dalla data della crocefissione ogni testo cristiano.

Ribadisco ancora, apposta, - non sto facendo ripetizioni per errore, è voluto - il fatto che di testimonianza si parla.

Su questo, infatti, Paolo di Tarso insiste ancora nei versetti seguenti:

ed è apparso a Pietro. Poi è apparso ai dodici apostoli, quindi a più di cinquecento discepoli riuniti insieme. La maggior parte di essi è ancora in vita, mentre alcuni sono già morti. In seguito è apparso a Giacomo, e poi a tutti gli apostoli. Dopo essere apparso a tutti, alla fine è apparso anche a me
[San Paolo, prima lettera ai Corinzi - 15, 5-8]

Paolo sta cercando di evidenziare questo aspetto di testimonianza, enumerando i possibili testi a favore. Non uno o due, ma centinaia.
La maggior parte di essi vive ancora, potete chiederglielo direttamente.

Cristo (l'unto scelto da Dio per una missione per il popolo, il messia atteso dagli Ebrei) è morto ed è risorto.

Ed è apparso a Kefa, poi ai Dodici, poi ad altri 500, poi a Giacomo, agli altri apostoli (oltre ai dodici, quanti erano?), poi a Paolo (e certamente omette o non conosce altre possibili testimonianze, come, per es., quella di Cleopa e dell'altro discepolo di Emmaus - Luca: 24, 13-35).
Si noti che apparve è usato in senso di comparsa oggettiva, non nel senso di visione, in questo testo.

Noi accettiamo le testimonianze come prove giuridiche.
In questo caso le apparizioni si sarebbero ripetute in tempi diversi, su persone diverse (poi... poi... poi...) e avrebbero interessato lo stesso Paolo, che, pure, prima aveva partecipato alla persecuzione dei cristiani e, in particolare, al martirio di S.Stefano (Atti degli apostoli - 7, 54-60; 8,1-3; 9,1-2), tanto che i cristiani non si fidarono subito di lui (Atti - 9,13-14; 9,21; 9,26-27).
Un testimone scomodo.

Il kerygma è la base della testimonianza della resurrezione (Amore più forte della morte, più forte del male, come ha ricordato il papa nella veglia pasquale) dell'Uomo che aveva il potere di accettare di prendere su di sè i nostri peccati, pagarli per noi con la propria sofferenza e con la propria vita, per poi riprendersela, essendo anche Dio.

Bye

Depa

Joost Jump

2007-04-06T22:11:00.000+02:00

Forse quelli di Babelgum hanno paura di una recensione come quella di qualche giorno fa su Democracy Player, visto che hanno completamente finto di ignorare la mia richiesta di partecipare alla beta. Forse pensavano che un giudizio tecnico di livello, come quello già fornito per Joost fosse ancora troppo prematuro. Forse volevano solo evitare un confronto?

Tutti quelli tra voi che hanno detto che semplicemente non si saranno accorti della mia esistenza (e figurarsi se hanno letto i post) possono anche fare il favore di andarsene subito, tanto non siamo mai stati amici.

Per gli altri fornirò un ulteriore approfondimento su Joost, assolutamente necessario dopo l'uscita, 3-4 giorni fa, della beta 0.9, seguita immediatamente dalla 0.9.1: nonostante abbiano peggiorato l'accesso al sito, che ora si riesce a non utilizzare in 3 modi differenti a seconda che usiate IE, Firefox o Opera, dal client si ottengono nuovi contenuti e funzionalità migliorate.

Hanno fornito anche informazioni aggiuntive, molto interessanti, relative a quali canali sono al momento previsti in quali paesi.

Un bel salto, qualcosa che giustifica veramente il cambiamento di numerazione nella release.

Iniziamo col dire che lo so da me che non va mica bene passare troppo tempo di fronte alla TV e che sarebbe meglio andare a fare dei giri, soprattutto potendo sfruttare una residenza tra le Alpi ed il lago Maggiore.
A mia parziale discolpa (o forse, al contrario, a peggiorare la situazione), lo sapete anche voi che quando torno a casa, non riesco a fare a meno di completare le 12 ore di lavoro con altre 4 a vagolare tra la programmazione ed la navigazione sul Web, probabilmente a causa di qualche virus che ha risparmiato il mio PC, ma non me.

Quindi, torniamo a Joost.
La prima e fondamentale nota riguarda il numero di canali, che sono passati da 38, a 37 nei giorni immediatamente successivi al mio precedente post, ai 67 negli ultimi due giorni. E' comparso, chi mai avrebbe potuto immaginarlo, anche un canale di calcio (ve lo dico anche se a me non interessa, perchè so che c'è gente che lo segue).

Soprattutto ora ci sono anche contenuti che mi interessano decisamente di più, dagli hobby (chitarra, disegno, etc.), alla fantascienza, alla cucina.

Anzi, dopo aver finito questo post, ricordatemi che devo finire il programma che spiega alcuni giochi di prestigio, che ho iniziato ieri e ho dovuto lasciare subito perchè dovevo finire un lavoro.
Ho potuto farlo a cuor leggero perchè, finalmente, è possibile saltare i pezzi già visti, spostando avanti un cursorino. Raggiungere il punto di interesse non è immediato, dicono che ci stanno lavorando, ma è già buono, quando si arriva a metà di un programma di due ore e non si vuole rivedere la prima. Cursore a parte, in realtà, secondo quanto ho letto, dovrebbe ripartire addirittura da dove ho spento. Sperem...

Anche l'organizzazione è migliorata, con comparsa di categorie e guide maggiormente configurabili.

Rispetto alle prove di qualche settimana fa, però, ieri sera, a mezzanotte, era quasi inguardabile per quanto andava a scatti e una volta ho dovuto agire con la forza (taskmanager). Stasera riprovo per capire se si trattava di problema della nuova 0.9.1 o semplicemente di orario - forse troppe persone collegate? a mezzanotte da noi, negli USA intorno delle 17:00: potevano essere sotto stress i server. Sarebbe anche possibile se tutti hanno ricevuto, come me, 5 inviti da dare in giro agli amici: partendo dai precedenti 80.000 beta tester, si arriverebbe a 400.000 ed inizia ad essere un bello stress-test.

Sempre un po' deludente, anche se un filo meglio della volta scorsa, l'aspetto widget. Questa è l'area su cui mi sembra stiano annunciando future evoluzioni.
E, da bravi informatici, attendiamo di vedere cosa si potrà fare con le API che dovrebbero pubblicare a breve.

Nel frattempo, più lo guardo più lo vedo come concorrente della TV tradizionale e non scambierei la libertà (fin troppa, a volte) e la freschezza di YouTube con la qualità offerta da Joost, ma secondo schemi troppo consueti.

Bye

Depa
P.S.: qualcuno di voi ha un invito per Babelgum? A me non interessano veramente i programmi: mi piace giocare con le novità.

Esagoni e carte

2007-04-04T17:31:00.000+02:00

Il 29 maggio 1848 la ritirata strategica piemontese nella battaglia di Curtatone Montanara è stata il presupposto per la seguente più importante vittoria nei pressi di Goito. Grazie anche al valore degli Universitari delle università di Bologna, Ferrara, Modena, Padova, Parma, Pavia, Pisa, Siena e Trieste (ho studiato a Pavia e l'Università chiude per commemorare i caduti in quella battaglia, ricordati anche con una gara di canottaggio tra Pavia e Pisa).

Ovviamente state giustamente pensando che la mia immensa cultura non ha limiti ed anche sulla storia me la cavo mica male.
Farò finta di non sentire il borbottio di fondo dei soliti pochi riguardo a fantomatiche mie ricerche a caso sulla Wikipedia e conseguente ricamarci sopra per scrivere un post (è inutile che neghiate, quando non avete neppure il coraggio di guardarmi negli occhi).

Siccome tengo molto alla vostra educazione, vi risponderò con i fatti, fornendovi qualche informazione aggiuntiva e dimostrandovi le mie solidissime basi.
Condivise, peraltro, anche da personaggi illustri come Leopardi (e ogni critico onesto non potrà che convenire) quando associava gli studi leggiadri alle sudate carte, riferendosi, come sto per fare io, proprio al tempo passato a giocare ai wargame.

Giocare o imparare?
Finchè si è piccoli il primo è propedeutico al secondo.
Crescendo, il secondo fornisce una buona scusa al primo (quando, ovviamente, non ci si aliena su Second Life per garantire una decente vita sociale al nostro avatar e con il solo illusorio conforto che anche lì si parli di cultura, quando il marketing pensa di tirare in ballo personaggi risorgimentali).

Quelli tra noi che, diventando più grandicelli, hanno cercato ancora di giocare con i soldatini, infatti, hanno pensato bene di confermare le teorie evolutive relative all'homo ludens mettendosi a studiare la storia, le evoluzioni delle divise (competenza immancabile nel bagaglio di ogni grande artista che voglia dipingere personalmente i propri modellini), le tattiche di guerra.

Arrivando pure a leggere quel von Clausewitz che mio padre, generale dell'esercito italiano, ricordava con terrore dai tempi della Scuola di Guerra, sostenendo che, come mattone, Della Guerra nulla avesse da invidiare alla Critica della ragion pura di Kant. Per completezza di cronaca e onestà intellettuale non possiamo dimenticare che quelli che cercavano le proprie radici filosofiche nell'estremo oriente, preferivano, invece, i famosi detti di Sun Tzu.

Entrambi, tra l'altro, riutilizzabili nella seguente (o parallela) vita lavorativa, come citazioni da giocarsi quando si parla di mercati da conquistare o azioni di marketing (disciplina che desume molta della propria terminologia proprio da quella militare) o quando si deve definire un piano di progetto di emergenza.
L'evoluzione delle divise continua e credo che sia quasi banale sostenere che le cravatte e le giacche debbano rientrare a giusto titolo in questo elenco.

Si può giocare ad un wargame anche senza preoccuparsi della storia (quando, addirittura, non si devia, come con Warhammer, sul fantasy: bisogna studiare meno, i testi di riferimento sono più facili, per puro caso richiamano vagamente i film ed i gadget che si stanno vendendo su altri canali, etc. etc.).

Ma se non ti crei un background solido (e questo vale anche per ambientazioni fantasy), non sarai mai un vero giocatore e smetterai certamente alle prime difficoltà (a pag. 10 del manuale di istruzioni, dove iniziano a comparire le tabelle dei costi di movimento ed i concetti di ZOC - ZOna di Controllo - o simili).
Nascondere il tedio del calcolo e della continua consultazione sostituendo le tabelle con dei videogame non serve a molto per continuare, se non studiate anche l'ambientazione, le circostanze di contorno alla battaglia. E il suo esito, ovviamente, per cercare di ribaltarlo: se vinciamo a Waterloo nei panni di Napoleone, non battiamo solo il duca di Wellington, ma, ben più importante, lo stratega per eccellenza stesso, ancora una volta, sul quello stesso campo - il fatto che lui non vedesse il tavolo dall'alto, che non potesse ripetere 10 volte la battaglia prima di vincerla e che si trovasse di fronte un altro vero generale e non il nostro amico, notoriamente un inetto a questo gioco, sono solo scuse meschine che da una persona del livello di Napoleone, davvero, non ci saremmo mai aspettati di sentire).

Chi riesce a darsi delle motivazioni in questo senso diventa un grognard (ovvero un giocatore di wargame, in una accezione che tende a sottolineare una certa esperienza): non un guerrafondaio, ma un giocherellone serio e colto, sostenitore della sostanza.
Se fosse un amante della forma gli sarebbe inacettabile poter passare le giornate davanti a quadratini di cartone di mezzo centimetro di lato, con simboli elementari al posto di disegni e numerini sopra e sotto (è accettabile sostituire i quadratini di cartone con delle figure tridimensionali colorate, ma solo per maggior rigore storico o per rendere più realistica la ricostruzione).

Il grognard è anche un tipo preciso: le unità si muovono su esagoni, nelle 6 direzioni indicate dai lati, perchè con questi poligoni è possibile riempire completamente un'area (il tavolo da gioco) senza lasciare buchi e garantendo che dal centro di un esagono al centro dell'altro sia costante la distanza. Per simulare maggiormente alla realtà è possibile permettere alle unità di muoversi in ogni direzione solo laddove ci si accordi per procurarsi un metro flessibile per controllare inflessibilmente le distanze misurate.

Un hobby a tutto tondo, quindi, che permette non solo di crescere nella cultura della storia e dell'arte, ma di bilanciarle con la precisione di matematica e geometria.

Chiaramente, se ora non vi raccontassi che anche Internet deve essere considerato terreno di conquista e fonte di ulteriore conoscenza dovreste controllare bene il titolo del blog per verificare di non essere stati rediretti altrove.

E' facile, partendo da Web Grognard, trovare i link che permettono di fornire le basi per gestire combattimenti navali nell'800, per poi trovarsi ad approfondire i dettagli storici su Line of Fire di History Channel per ricordare l'ingegno, il coraggio e l'estremo saluto di Nelson nella battaglia di Trafalgar, che chiarì a tutti cosa voleva dire la supremazia inglese sui mari per quasi un secolo.

Potete sfruttare la macchina del tempo e rispolverare il valore degli antichi, prima della polvere da sparo, recuperando le regole classiche di Ancients, basate su esagoni, ed i diversi scenari (mai venuta voglia di evitare che Orlando cerchi di spezzare Durlindana alla fine della battaglia di Roncisvalle, prima di morire?).

Ce ne sono tanti altri, di link simili (quasi tutti reperibili da Web Gognard), ma il punto è che da anni, oramai, vivo in una città diversa da quella in cui risiedono gli amici che mi piaceva affrontare su questi campi.
Ma, ancora una volta, il Web, la piattaforma che, di mestiere, mette in contatto persone lontane, potrebbe venire in aiuto. Per esempio con Vassal, sistema che permette di ridefinire un intero board game su PC e trasmettere i nostri spostamenti sugli esagoni via email (no, non in diretta: stiamo giocando con tempi lunghi, le mosse possono richiedere anche mezz'ora, la mail è lo strumento corretto).

Certo, oltre alla lontananza non ho più neppure tutto tutto il tempo che avevo ai tempi del liceo o dell'Università. Leopardi, da suo pari, già aveva capito la risposta al problema: è, infatti possibile ricorrere a wargame più rapidi e facilmente trasportabili, usando, come il poeta rimembrava a Silvia, (mazzi di) carte (che sarebbe meglio non fossero sudate, perchè rischierebbero di essere riconoscibili come se fossero segnate, come potrebbe notare subito qualche giocatore più esperto).

Anche in questo caso esiste uno specifico programma che ci permette di giocare via Internet, Thoth, con carte predefinite o regole facilmente rintracciabili (es: Hoplites) dalle quali lasciarsi ispirare per disegnarne di nostre.

Ci sono battaglie perse in partenza e anche questo espediente delle carte non basta più per i miei pochi istanti di libertà.
Forse, sintetizzando un po' questi post potrei tornare a giocare...

Chi di voi ha detto che prima sarebbe meglio vivere che giocare?

Bye

Depa
P.S.: se siete in viaggio e non sapete cosa fare, esistono anche carta e penna e un altro po' di regole che potrete trovare, per es., presso il sito di Warp Spawn Games.

SOA (2) - Variazioni Goldberg

2007-03-30T11:35:00.000+02:00

[...] 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

Non ci si inganna che per ottimismo (Hervieu)	Si è più spesso fregati dalla diffidenza che dalla fiducia (Rivarol)
I popoli sarebbero felici se i re filosofassero e se i filosofi regnassero (Plutarco)	Il giorno che vorrò castigare una provincia la farò governare da un filosofo (Federico II)