mercoledì 30 aprile 2008

Come Leonardo


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

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

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

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

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

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

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

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



Ok. Stiamo per essere sommersi.

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

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

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

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

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

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

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

Provo a ridire con altre parole l'ultimo punto.

Quante cose ricordate, senza usare i sensi?
    Provate a ricordare un compagno (compagna, se pensate che vi ispiri maggiormente) di classe che non vedete da anni. Nei dettagli della curvatura del naso, della larghezza delle labbra, del colore e lunghezza dei capelli. Ce la fate?
    Com'era l'incipit di Sogno di una notte di mezza estate e come si chiamavano i personaggi?
    Canticchiate tutto Eskimo di Guccini.
    La prova del nove e la radice quadrata, CON PENNA E FOGLIO, come caspita si facevano?
    E' più ruvido il tessuto delle poltrone dei treni o la lama di una lima?

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

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

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

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

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

Non sentite anche voi il bisogno di qualcosa di meglio?

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

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

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

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

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

Forse è uno dei prossimi inevitabili sbocchi dell'informatica.

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

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

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

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

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

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

[... continua ...] Leggi tutto

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

[... continua ...] Leggi tutto