Modi di lavorare (framework - 1)

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

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

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

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

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

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

---

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

La seconda modalità è, invece, preferita quando:

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

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

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

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

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

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

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

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

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

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

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

Depa

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

[... continua ...] Leggi tutto

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

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

Letteratura Fiabesca Applicata all'Informatica

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

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

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

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

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

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

---

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Bye

Depa

[... continua ...] Leggi tutto

SOA (2) - Variazioni Goldberg

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

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

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

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

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

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

---

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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


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


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


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

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

Bye

Depa

[... continua ...] Leggi tutto

Timeo Danaos et dona ferentis

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

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

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

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

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

---

Torniamo a fare i bravi, almeno per un momento.

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

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

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

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

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

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

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

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

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

Subito, non tra qualche anno.

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

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

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

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

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

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

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

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

Bye

Depa

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

[... continua ...] Leggi tutto

Non ibernatemi

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

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

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

---

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Bye

Depa

[... continua ...] Leggi tutto