giovedì 20 dicembre 2007

Wanted



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
    Depa
P.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.

[... continua ...] Leggi tutto

sabato 15 dicembre 2007

Libbertà



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
    Depa
P.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]


[... continua ...] Leggi tutto

martedì 27 novembre 2007

Come un bambino



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.

[... continua ...] Leggi tutto

martedì 13 novembre 2007

Osservando distaccatamente babeli mediatiche



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

[... continua ...] Leggi tutto

giovedì 8 novembre 2007

CRUDeli variazioni


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

    Depa
P.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...

[... continua ...] Leggi tutto

sabato 20 ottobre 2007

Oggi scricchiolo



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


[... continua ...] Leggi tutto

lunedì 3 settembre 2007

Bentornati


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
    Depa
P.S.: non chiedetemi nulla riguardo all'ultima frase, risolvetevela per conto vostro.

[... continua ...] Leggi tutto

giovedì 19 luglio 2007

Narciso Yepes e la chiave del quindici



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
SI
  • 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
    Depa
P.S.: poi magari salta fuori che avete ragione voi
P.P.S.: per quanto improbabile, intendo... ;)

[... continua ...] Leggi tutto