lunedì 21 aprile 2008

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... ;)

Nessun commento: