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

sabato 14 luglio 2007

Uno, nessuno e centomila


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

[... continua ...] Leggi tutto