Shops, CMSs e Web Frameworks

lego

Ogni settore ha il suo Santo Graal da cercare. La medicina di oggi cerca la cura per il cancro, l’ingegneria cerca la fusione nucleare ed il nostro settore cerca disperatamente un modo meno “dumb” dei SSI di sviluppare delle applicazioni web. Possibilmente delle applicazioni web che non assomiglino troppo a quello che era il sito web della mutua alla metà degli anni ’90 (senza offesa per le AUSL…). Questa ricerca prende la forma di un incessante lavoro di sviluppo di nuovi framework e di nuovi CMS, sempre più raffinati e sofisticati. Orientarsi in questa selva di offerte è ormai una disciplina in sé. Qui di seguito trovate le mie personalissime riflessioni su questo tema.

Sviluppo Agile e Sviluppo Pesante

C’è molta differenza tra sviluppare qualcosa tra amici (due o tre persone all’opera su un singolo progetto) e farlo in un contesto industriale (da 10 a 200 sviluppatori che si muovono incessantemente tra 10 o 20 progetti, magari lavorando da casa via Internet). Nel primo caso, è necessario un ambiente agile e stimolante, come quello che possono offrire Ruby/Ramaze e Scala/Lift. Nel secondo caso, è necessario un ambiente di sviluppo molto “controllabile”, cioè un ambiente in cui sia possibile imporre delle regole molto precise e sorvegliare con facilità che vengano rispettate. In ambienti del secondo tipo è importante che esiste un vasto set di strumenti di ottima qualità che vanno dal sistema di gestione delle versioni (CVS, Subversion, GIT, Mercurial, Bazaar, etc.), all’editor (Eclipse, Netbeans, etc.), al sistema di testing (JUnit e Selenium), al sistema di controllo del coverage (Cobertura, etc.) fino al sistema di controllo della produzione (Hackystat e simili).

Di conseguenza, molte soluzioni adatte al primo tipo di contesto, per quanto raffinate ed eleganti, potrebbero non essere per niente adatte al secondo. Questo è il caso di molti linguaggi (Scala ed Erlang, per esempio) e molti framework (come Lift, Ramaze e Merb) che, pur eccellenti da molti punti di vista, sono troppo poco “frequentati” dagli sviluppatori e/o troppo poco supportati dagli strumenti di gestione per poter essere usati in molti ambienti industriali (con le solite, fortunate eccezioni).

Una piattaforma per il web

Molto spesso, quando si parla di sviluppo web si pensa automaticamente al linguaggio (Java piuttosto di Ruby) od al framework (Spring piuttosto di Zend) ma raramente la situazione è così semplice. In realtà, quello che è veramente necessario è uno “full-blown stack” di strumenti che permetta di affrontare tutta l’ampia casistica di possibili contratti di sviluppo senza dover cambiare continuamente strumento. Quello che ci vuole è uno stack linguaggio+framework+cms+shop. Questo è quello che avviene, ad esempio, con PHP, Zend Framework, Symfony e Magento. In questo modo, è possibile partire dal prodotto più vicino a quello che si desidera ottenere e limitare costi e tempi di sviluppo al minimo indispensabile. Per costruire un sito che vende eBook, per esempio, basta adattare Magento allo scopo (Magento ha già un suo sistema per vendere “downloadables”, molto vicino a ciò che serve davvero). Per costruire un sistema simile a Webmin, invece, si può partire da Zend e costruire ciò che serve quasi da zero. Tutto questo, senza cambiare linguaggio e librerie di base.

Quello che manca da sempre al web, infatti, è una piattaforma di sviluppo ed un sistema operativo standard, completi ed affidabili, cioè qualcosa di comparabile a Windows+C#+VisualStudio o Linux+KDE+Qt+KDevelop, per capirci. Tutti i framework creati finora possono essere visti come tentativi più o meno riusciti di colmare questa lacuna.

Language matters

Il primo elemento dello stack che viene sottoposto ad analisi è il linguaggio. Al giorno d’oggi praticamente tutti i linguaggi esistenti forniscono, in un modo o nell’altro, tutti gli strumenti necessari allo sviluppo web per cui la scelta del linguaggio non è quasi mai obbligata. Piuttosto, ciò che fa decidere per un linguaggio o per l’altro sono la sua comodità di utilizzo e la sua “controllabilità” in un ambiente di sviluppo complesso (più progetti contemporaneamente attivi e seguiti da più sviluppatori, che spesso si spostano da un progetto all’altro e che possono avere competenze molto diverse tra loro).

Dal punto di vista della gestibilità, Java ed i suoi derivati Scala e Groovy sono effettivamente un passo avanti agli altri. È relativamente facile trovare sviluppatori che conoscono bene questo ambiente ed è possibile organizzare un ambiente di sviluppo uniforme e controllabile usando Ant, Maven, Eclipse (o Netbeans), Hibernate, Spring, JUnit, HackyStat ed altre diavolerie simili.

Dal punto di vista dell’eleganza (intesa come espressività, chiarezza e concisione), sono forse Scala e Ruby a tenere la testa della corsa. In particolare, Ruby (a causa di Ruby on Rails) è probabilmente il linguaggio preferito dagli sviluppatori web che conosco.

Tutti gli altri si trovano a notevole distanza da questi leader. Questo vale anche per linguaggi relativamente moderni e raffinati, come Python, non solo per le vecchie glorie come Perl. Purtroppo Python, pur avendo tutte le carte in regola per farlo, non è mai riuscito ad emergere davvero (come leader) in questo settore. Certi ottimi framework, come Pylons, Web2Py e Django, infatti, sono stati oscurati dal non eccelso Zope/Plone, con effetti negativi sulla credibilità ed appetibilità del linguaggio.

Curiosamente, in coda alla lista c’è il più diffuso dei linguaggi web: PHP. Questo linguaggio, più di ogni altro, mostra i segni di uno sviluppo piuttosto caotico e disorganizzato. Ad esempio, fino alla recentissima versione 5.3 non disponeva di nessun modo per organizzare gli spazi dei nomi e questo ha avuto degli effetti grotteschi su framework altrimenti eccelsi, come Zend. PHP è quasi una scelta obbligata in molti casi, a causa della enorme quantità di applicazioni preconfezionate che può offrire, ma certo non è il linguaggio da prendere ad esempio.

Web Frameworks, Web Toolkits e Generatori di Applicazioni

Sotto l’unico termine “web frameworks” vengono in realtà accatastate almeno tre o quattro tipologie diverse di oggetti. La prima sono i toolkit (o toolbox) come Pylons, Ramaze e Zend. Questi sono semplici insiemi (collezioni) di strumenti che possono essere usati individualmente per assemblare una applicazione web e che di solito impongono pochissimi vincoli sul come debba essere organizzata questa applicazione.

I framework veri e propri, come Zope, Spring e diversi altri, esigono invece che l’applicazione abbia una certa struttura di base per funzionare correttamente anche se, ovviamente, lasciano una notevole libertà di interpretazione allo sviluppatore riguardo ai dettagli. Va da se che la linea di confine tra toolkit e framework è molto sfumata ed è soggetta ad interpretazioni personali che dipendono spesso dall’utilizzo specifico che si fa di questi oggetti.

Strumenti come Ruby-on-Rails e Django, invece, potrebbero (e forse dovrebbero) essere considerati più dei “generatori di applicazioni” o degli “ambienti di sviluppo integrato per applicazioni web” (web IDE). Questo perché provvedono in prima persona alla generazione ed alla gestione di una parte del codice.

Esistono poi i framework basati sulla “continuazione” (http://en.wikipedia.org/wiki/Continuation), come Borges e Wee, che sono nati per permettere un paradigma di sviluppo più lineare in ambito web.

Come si può immaginare, questa confusione terminologica tra oggetti diversi crea non pochi problemi quando si deve scegliere una piattaforma di sviluppo per la prima volta. Se vi trovate a dover scegliere piattaforma per la prima volta, provate a chiedervi “fin dove voglio che la piattaforma mi guidi nello sviluppo?”

Se siete molto sicuri delle vostre intenzioni e delle vostre capacità, probabilmente è meglio che usiate un toolkit. Se volete una guida non troppo invasiva, usate un framework. Se volete essere guidati quasi per mano, usate un generatore di applicazioni. Ovviamente, più controllo significa più libertà ma anche più lavoro e più responsabilità.

Comunque, tra i toolkit quelli che si fanno notare per la loro qualità ci sono probabilmente Pylons (Python) ed alcuni toolkit di Ruby, come Ramaze e Merb. Zend (PHP) è un ottimo toolkit in sé ma ha la sfortuna di trascinarsi appresso i limiti di PHP.

Tra i framework, Spring (Java) emerge chiaramente sopra gli altri. Zope (Python), invece, si fa notare solo per il suo processo di sviluppo caotico ed erratico. Personalmente, lo evito.

Tra i generatori di applicazioni possono solo ricordare Ruby-on-Rails e Django, che non hanno certo bisogno di presentazioni. Ce ne sono però moltissimi altri, anche di ottima qualità, per ogni linguaggio.

CMSs e Shops

Una volta che si sia scelto un framework, è spesso necessario controllare che esista anche il resto dello stack, cioè almeno un CMS ed uno “Shop” già confezionati da cui partire quando questo sia possibile.

Da questo punto di vista PHP, che da ogni altro punto di vista si trova nelle ultime posizioni, improvvisamente emerge come protagonista. PHP, infatti, è sulla scena da molto tempo (ma non quanto Perl e Python) e viene usato da talmente tanta gente per sviluppare applicazioni web che è ormai in grado di fornire quasi qualunque cosa sia necessaria. Ad esempio, uno dei migliori “Shop” esistenti, Magento, è basato proprio su PHP e Zend Framework. Come CMS si può usare l’ottimo Symfony, anch’esso basato su Zend.

Come ho detto, è piuttosto difficile trovare uno stack così ampio e completo per altri linguaggi. Per fortuna, nel mondo Java si possono usare, ad esempio, Spring, Wicket e HippoCMS (che dispone anche di un modulo “Shop”) e nell’ambiente Python forse si può usare Zope/Plone più qualche modulo per l’ecommerce. Ruby, ovviamente, offre Ruby-on-Rails, Radiant CMS (o Railfrog o Rubricks) e vari “moduli” per l’ecommerce. Da questo punto di vista, Ruby è forse il principale concorrente di PHP.

Add-ons, Plug-ins ed altri animali

Una cosa che accomuna tutti questi sistemi è la loro modularità. Praticamente tutti i moderni CMS e Shop dipendono da una grande quantità di moduli, di add-on e di plug-in per soddisfare le esigenze del mercato. Per questo motivo, è importante che la scelta di moduli sia vasta ed articolata e che la loro installazione (e la successiva gestione) sia semplice ed affidabile.

Da questo punto di vista, Magento (PHP + Zend) è un esempio da seguire. Anche certi Cms e certi Shop basati su Ruby e che fanno uso di Gems sono formidabili. Viceversa, il mondo Python è rimasto un po’ indietro nonostante disponga da anni di soluzioni simili a quelle dei concorrenti.

Conclusioni

Insomma, nonostante siano passati quasi vent’anni dall’apparizione del World Wide Web, siamo ancora lontani dall’aver trovato una soluzione univoca, chiara e gestibile, al problema dello sviluppo web. Dobbiamo ancora esplorare una giungla di soluzioni diverse, a volte insidiose, prima di trovare quella adatta a noi. O, più esattamente, quella più adatta al progetto da affrontare.

Se avete voglia di condividere le vostre (dis)avventure e le vostre opinioni riguardo al mondo dei framework e dei CMS/Shop, usate il sistema dei commenti qui sotto.

Alessandro Bottoni

L’immagine proviene da Flickr: flickr.com/photos/oskay/265899865/ .

Comments
4 Responses to “Shops, CMSs e Web Frameworks”
  1. Enrico Rubboli scrive:

    Direi che sei riuscito a condensare decine di anni di lavoro-uomo in un solo post ;)
    Lavorando da un pò in ambiente ruby posso darti la mia opinione su quello. Se cerchi un prodotto da modificare (CMS, ecommerce ecc..) in ruby non cè niente di comparabile con quanto puoi trovare in PHP o Java, ad esempio Radiant CMS o Typo non sono strumenti pratici come possono essere Plone o WordPress. E non mi risulta ad esempio che ci sia nemmeno niente di simile a vbulletin che è scritto in PHP e pure male, ma fa dannatamente bene il suo lavoro.

    In sostanza se ci si accontenta di un prodotto finito non vedo perchè non sfruttare (quando le caratteristiche sono idonee) uno dei tanti prodotti già in circolazione. Ma se cè da sviluppare qualcosa ex-novo allora le cose cambiano e li i fattori che contano sono altri.
    Non ho la piu pallida idea del perchè PHP abbia preso cosi tanto, forse perchè molti lo considerano un Perl semplificato ed ai tempi le alternative erano java (maledettamente complicato e lento) o perl.

    Per quanto mi riguarda sono passato a ruby dopo quasi 10 anni di java e ti assicuro che non tornerei mai piu indietro (se potessi, ma come ben sai a volte non si può scegliere ;)).
    Ruby è un linguaggio estremamente semplice sia da imparare che da leggere, dammi un’altro linguaggio (che sia andato oltre alla fase ‘accademica’) in grado di costruire un DSL sul linguaggio stesso.. (vedi ad esempio ActiveRecords, cucumber, sinatra)..

    Un’altro fattore importante da decidere quando si va a sviluppare è il metodo, ed anche qui di evoluzioni ce ne sono state parecchie, TDD, BDD, Continuos Integration, Refactoring.. anche qui dipende spesso da quel che si deve fare.. ma per ruby e rails non cè che l’imbarazzo della scelta e si presta a tutti quanti questi approcci.
    Cucumber per BDD ad esempio è eccezzionale e non ha pari (per quanto ne so) su altri linguaggi.

    Non sono completamente d’accordo nel definire Rails un generatore di applicazioni.. non lo credo cosi evoluto, io mi fermerei al framework. Inoltre ora Merb fa parte di Rails.

    m2c ;)

    • Enrico Rubboli scrive:
      “Direi che sei riuscito a condensare decine di anni di lavoro-uomo in un solo post ;)”

      Beh, in effetti sto lavorando ad una versione modificata di SHA-1 che mi dovrebbe permette di condensare l’intera Bibbia in una stringa di 16 caratteri. In modo reversibile, ovviamente. ;-)

      “Non ho la piu pallida idea del perchè PHP abbia preso cosi tanto, forse perchè molti lo considerano un Perl semplificato ed ai tempi le alternative erano java (maledettamente complicato e lento) o perl.”

      Un’idea su questo punto me la sarei fatta: PHP è nato, e soprattutto è cresciuto, insieme ad un’intera generazione di sviluppatori web nella seconda metà degli anni ’90. In un certo senso, li ha seguiti nel cammino, o li ha guidati su di esso, e molti che lavorano nel settore lo conoscono e lo capiscono meglio di ogni altro linguaggio. Questo si riflette anche sui suoi framework. In questo momento sto leggendo un manuale di Zend ed uno di Magento (perchè devo fare un “coso” di e-procurement in fretta…) e, se devo essere sincero, Zend riesce ad essere molto più chiaro ed “intuibile” di moltissimi altri framework per chi, come me, viene originariamente da Perl e CGI (prima di aver adottato altra roba, tra cui Python e java). Voglio dire: Zend parla di HTTP request e response, non di IoC e AOP, come avviene con Spring in Java.

      “Per quanto mi riguarda sono passato a ruby dopo quasi 10 anni di java e ti assicuro che non tornerei mai piu indietro (se potessi, ma come ben sai a volte non si può scegliere ;)).
      Ruby è un linguaggio estremamente semplice sia da imparare che da leggere, dammi un’altro linguaggio (che sia andato oltre alla fase ‘accademica’) in grado di costruire un DSL sul linguaggio stesso.. (vedi ad esempio ActiveRecords, cucumber, sinatra)..”

      Si, concordo pienamente sul rapporto tra Ruby, Java ed altri linguaggi. Ad un certo punto della mia storia professionale sono stato costretto a scegliere un linguaggio per lo sviluppo web che non fosse Perl. Ruby era nella “short list” insieme a Python, Java e a qualcun altro. Alla fine ho scelto Python soprattutto perchè risultava molto leggibile e più leggero di Java. Ruby è stato scartato solo perché in quel momento (eravamo nel 1996 o 1997) non era ancora disponbile una vera documentazione del linguaggio in inglese. Va ben che mi piace studiare le lingue, ma a quel tempo il mio giapponese era ancora un po’ rozzo… ;-)

      “Un’altro fattore importante da decidere quando si va a sviluppare è il metodo, ed anche qui di evoluzioni ce ne sono state parecchie, TDD, BDD, Continuos Integration, Refactoring.. anche qui dipende spesso da quel che si deve fare.. ma per ruby e rails non cè che l’imbarazzo della scelta e si presta a tutti quanti questi approcci.
      Cucumber per BDD ad esempio è eccezzionale e non ha pari (per quanto ne so) su altri linguaggi.”

      Verissimo. In realtà, proprio la gestione del processo di sviluppo è la ragione per cui stiamo utilizzando sempre più spesso java e Ruby. Come dicevo nell’articolo, certi strumenti sono disponbili anche in altri ambienti ma sono rari i casi in cui si possa contare su un ambiente di sviluppo veramente completo e professionale. Da questo punto di vista, però, PHP è nelle prime posizioni.

      “Non sono completamente d’accordo nel definire Rails un generatore di applicazioni.. non lo credo cosi evoluto, io mi fermerei al framework. Inoltre ora Merb fa parte di Rails.”

      Si, capisco. Lo chiamo così, insieme a Django, soprattutto per chiarire che si tratta di un framework molto diverso da Zend, Zope o roba simile. In un certo senso è molto più “interattivo”.

  2. Enrico Rubboli scrive:

    Voglio dire: Zend parla di HTTP request e response, non di IoC e AOP, come avviene con Spring in Java.

    Dev’essere un’abitudine presa dal mondo microsoft.. una volta ho cercato di leggermi un manuale di access.. abituato all’SQL non hai idea della fatica che ho fatto ad adattare la terminologia!! Avrei un’idea cospirazionista a riguardo.. un lock-in linguistico.. (fa molto bispensiero ;))

    Ruby è stato scartato solo perché in quel momento (eravamo nel 1996 o 1997) non era ancora disponbile una vera documentazione del linguaggio in inglese. Va ben che mi piace studiare le lingue, ma a quel tempo il mio giapponese era ancora un po’ rozzo… ;-)

    in effetti, dal 96 di passi avanti ruby ne ha fatti parecchi!! soprattutto per quanto riguarda la documentazione
    .. devo ammatterlo.. non mi studierei mai il giapponese per imparare ruby, piuttosto php ;)

    ER

  3. Marco scrive:

    Ciao, per le concessionarie di recente hanno creato questo gestionale web in ruby on rails http://www.gestionaleveicoli.com ti permette in poco tempo di creare il sito della tua concessionaria, con possibilità di selezionare diversi temi grafici. Il sistema esporta in automatico i tuoi veicoli su diversi portali del settore automobilistico aumentando la visibilità dei tuoi prodotti.

Lascia un commento

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...

%d blogger cliccano Mi Piace per questo: