Il Padrino (no, non Berlusconi…)

godfather

Prima o poi doveva succedere: il segretario nazionale di un’associazione che si chiama “Partito Pirata” (cioè me) doveva mettersi a trafficare con un framework Ruby che si chiama “Padrino”. C’è un’ironia nello sviluppo web…

Perché non (più) Java?

Nell’ultimo anno ho fatto diverse cose con Java, usando Spring, Wicket, Tapestry, Hibernate, TopLink, AspectJ e diversi altri framework. Francamente, è difficile lavorare per qualche tempo con Eclispe o NetBeans, Ant, Maven e con tutta la panoplia di strumenti che Java rende disponibili senza restarne in qualche modo affascinati. In questo momento, l’ecosistema Java è quasi certamente quello più completo, coerente e solido che sia presente sul mercato dello sviluppo web (e, più in generale, sul mercato di tutto ciò che ha a che fare con Internet e le reti). Francamente, per certe applicazioni “enterprise” (banche, finanza, grandi aziende, ERP, etc.) è forse l’unico ambiente veramente in grado di fornire il giusto livello di controllabilità del processo produttivo e di manutenibilità del codice.

Ma, allora, come mai mi sono messo a guardare Ruby (ma anche Groovy, Scala e ad altri ambienti che giù conoscevo, come Python e PHP)?

Perché Java è veramente pesante per certe cose. Lo è, ad esempio, dal punto di vista del carico di lavoro sui server. Come saprete, infatti, il codice Java viene abitualmente eseguito da appositi application server (come Glassfish, WebSphere, JBoss e via dicendo) che forniscono una lunga serie di servizi (tra cui la gestione delle transazioni, la gestione degli accessi, il loading e l’istanziazione di oggetti e via dicendo). L’uso di questi application server libera lo sviluppatore da molte incombenze ma risulta pesante per il server e spesso si rivela un overkill.

Inoltre Java in alcuni punti rivela tutta la sua età. La gestione dei “generics” ne è un esempio. In alcuni casi, per ottenere gli stessi risultati sintattici e semantici che con Python o Ruby (o persino con PHP) si possono ottenere in due righe di codice è necessario scrivere mezza pagina di roba. Dopo un po’ viene male alle mani… Anche il Collections Framework fatica a risultare simpatico, ad essere onesti.

Groovy e Scala hanno permesso di superare molti degli acciacchi di vecchiaia di Java ma, in realtà, non hanno ancora dato vita a nulla di veramente nuovo e diverso.

Perché Sinatra?

Prima di poter rispondere alla domanda “Perchè Padrino?” è necessario spiegare perché ci si dovrebbe interessare a Sinatra, che è il framework su cui Padrino si basa. In altri termini: “Perché non semplicemente Ruby (from scratch)?” e “Perché non semplicemente Ruby on Rails?”

Scrivere una qualunque applicazione reale, al giorno d’oggi, è un processo lungo e complesso. Bisogna fornire una lunga serie di servizi come la gestione degli accessi (authentication and authorization), la gestione di un database (ORM e connettività), la gestione della posta (verifica della mail alla registrazione, notifiche, etc.), la gestione delle form, quella di un profilo utente e la gestione di una sezione di amministrazione del sistema. Insomma: ci vuole un sacco di tempo, si deve scrivere un sacco di codice e ci sono tutte le occasioni per combinare un sacco di casini.

Per queste ragioni, non è quasi mai una buona idea scrivere un’applicazione partendo da zero, a meno che l’obiettivo finale non sia proprio un framework (magari commerciale…). Di solito è meglio partire da un framework e nel mondo Ruby il framework per eccellenza è Ruby on Rails.

Personalmente, però, trovo Ruby on Rails un po’ antipatico. In realtà, non è colpa di RoR ma piuttosto della documentazione che ho studiato quando ho avuto bisogno di usarlo qualche anno fa: troppo “tutorialistica”. A quel tempo non ho avuto modo di capire bene la struttura interna di RoR e quindi mi sono fatto l’impressione che fosse un aggeggio molto basato su script generatori di codice usati per assistere lo sviluppatore. In altri termini, un arnese pericolosamente simile a MS Frontpage ed a Dreamweaver (li odio entrambi…) e difficilmente gestibile in un ambiente complesso (molti progetti e molti sviluppatori). In seguito ho capito che non è così: RoR è un framework come molti altri, anche se molto diverso in molti punti cruciali, e risulta perfettamente gestibile anche in quei contesti complessi. Tuttavia, la prima impressione negativa è rimasta e non ho mai smesso di cercare qualcosa di meglio e di diverso.

Sinatra, da molti punti di vista, è quel qualcosa. È un “arnese” molto piccolo ed essenziale, basato su un linguaggio molto elegante (Ruby) e che svolge soprattutto la funzione di “collante” tra i diversi componenti tipici di un sistema web basato su Ruby. O, in altri termini, fornisce i pilastri essenziali dell’applicazione e gli strumenti di base per svilupparla. In realtà, non è un framework ma un vero DSL (Domain Specific Language), cioè un linguaggio di programmazione specifico per quel dominio applicativo, costruito sulla base che offre Ruby grazie alle sue raffinate capacità di metaprogrammazione.

Questa sua natura lo rende molto snello, molto moderno e molto accattivante. Per molti aspetti, Sinatra fa sembrare concettualmente vecchi e pesanti persino gioielli come RoR, Grails (basato su Groovy) e Lift (basato su Scala).

Tra l’altro, come quasi tutti i framework Ruby, anche Sinatra e Padrino sono concepiti per essere eseguiti come semplici programmi Ruby, direttamente dall’interprete. L’istanza dell’interprete che esegue il framework viene poi resa visibile su Internet usando un apposito adapter come Mongrel e/o un server web proxy come Apache. Questa soluzione, a mio modesto avviso, è molto più snella, veloce e facile da gestire delle soluzioni abituali basate su Apache e PHP o su Java.

Com’è fatto Sinatra?

Come ho detto, Sinatra è in realtà un DSL costruito su Ruby. Cioè si tratta di un nuovo linguaggio (uno “small language”) costruito ad hoc per le esigenze dello sviluppo web estendendo Ruby. Di conseguenza, per creare un’applicazione web è sufficiente scrivere un normale programma in questo particolare linguaggio. È questo linguaggio a fornire le funzionalità specifiche per lo sviluppo web. Il programmatore non ha bisogno di sapere nulla dei dettagli interni.

Ad esempio, il seguente programma (preso dal tutorial ufficiale) crea e visualizza una pagina web:

  # myapp.rb
  require 'sinatra'

  get '/' do
    'Hello world!'
  end

Come potete vedere, non c’è bisogno di caricare altri framework, di istanziare oggetti o di compiere altre operazioni legate all’infrastruttura del sistema. Basta dichiarare cosa si vuol fare.

In particolare, “get” cattura la URL secondo uno schema prestabilito (in questo caso, viene catturata qualunque chiamata al server HTTP). Ciò che segue il “do” è l’azione che viene eseguita in risposta a questa chiamata (in questo caso, si stampa un messaggio di benvenuto).

Perché Padrino?

Sinatra, tuttavia, fornisce veramente il minimo indispensabile. Non appena si tenta di costruire qualcosa di ragionevolmente complesso, si ritorna alla situazione iniziale: bisogna scegliersi alcuni framework ed alcuni tool di supporto ed inserirli all’interno del progetto facendo uso degli strumenti forniti da Sinatra. Insomma: molto tempo, molto codice e molti potenziali casini.

Padrino fornisce appunto molte delle funzionalità che mancano a Sinatra. Ad esempio:

Generatori di codice: Padrino fornisce vari strumenti che permettono di creare intere applicazioni, modelli e controller in modo automatico ed affidabile.

Routing: Padrino fornisce un completo e raffinato sistema di routing che permette di gestire anche situazioni insolite. Tra le altre cose, gestisce anche dei filtri after/before.

Form: Padrino offre una lunga serie di strumenti per la gestione delle Form (ed anche del testo, dell’HTML e di varie altre cose).

Mailer: Padrino offre il supporto necessario per l’invio di messaggi di posta elettronica attraverso uno strumento simile ad ActionMailer di RoR.

Admin Section: Padrino fornisce una interfaccia di amministrazione che viene generata automaticamente, più o meno come avviene con Django nel mondo Python. Questo risparmia una notevole mole di lavoro allo sviluppatore.

Authentication: Padrino fornisce le funzionalità necessarie ad autenticare ed autorizzare gli utenti. Questa funzionalità è indispensabile in qualunque applicazioni reale e da sola giustifica l’adozione di un framework come questo.

Logging: Padrino fornisce anche dei raffinati strumenti di logging.

Localization: Padrino fornisce gli strumenti necessari per la localizzazione e la internazionalizzazione.

Tutto questo, senza parlare del fatto che Padrino è completamente agnostico, cioè permette di utilizzare qualunque libreria per il testing, per la gestione dei template e per la gestione dei database (anche ORM). Inoltre, Padrino provvede automaticamente al reloading delle classi durante lo sviluppo.

Per questo, a mio modestissimo avviso, è meglio usare Padrino per sviluppare una web application in Ruby piuttosto di limitarsi al solo Sinatra.

Perchè non Ramaze?

A questo punto, chi bazzica un po’ l’ambiente Ruby si starà sicuramente chiedendo perché non usare Ramaze, allora. Rispondere a questa domanda, francamente, è difficile. Non c’è una vera ragione per preferire uno di questi due sistemi all’altro, se non il gusto personale. Si tratta infatti di due piattaforme molto simili ed estremamente eleganti. Tra l’altro, Ramaze è anche molto ben documentato. Questo che segue, ad esempio, è il solito “hello world” in versione Ramaze.

require 'rubygems'
require 'ramaze'
class MainController < Ramaze::Controller
  def index
    'Hello, World!'
  end
end
Ramaze.start

Come potete vedere, non si tratta di uno “small language” (DSL) concepito ad hoc per lo sviluppo web. Non è presente la coppia get/do che caratterizza l’analogo esempio realizzato con Sinatra. In questo caso, si creano “manualmente” un controller ed un metodo. Si tratta quindi di una soluzione molto più classica di Sinatra. Tuttavia, è veramente difficile dire che sia una soluzione pesante od inelegante (specialmente se si proviene da Python/Zope o da Java/Spring…).

A questo punto posso solo dire che Sinatra e Padrino mi risultano più simpatici, forse perché sono più eleganti. In questo, forse, gioca il suo ruolo anche la grafica accattivante dei loro due siti web.

Che mi dici di Nesta?

Su Sinatra è basato anche un CMS, Nesta, che fornisce molte, se non tutte le funzionalità di base di un sistema tipico. Ovviamente, se ciò che si vuole sviluppare è un CMS, o qualcosa di molto simile ad esso, conviene sicuramente partire da Nesta. Se invece si deve sviluppare qualcosa di diverso (ad esempio un sistema di e-procurement od un sistema di social networking) conviene usare Padrino. Sono entrambi ottimi strumenti ma adatti a scopi diversi.

Com’è fatto Padrino?

Dal punto di vista tecnico, Padrino è composto da un Front Controller che gestisce il routing ed il flusso dell’applicazione e da una serie di librerie che forniscono i servizi essenziali, come la security (user authentication/authorization), il logging, il supporto alla localizzazione, etc. Per semplificare i lavori, Padrino fornisce poi una serie di script che provvedono alla generazione meccanica di molte porzioni di codice, tra cui i “template” delle applicazioni, i modelli ed i controller. Si tratta quindi di un framework molto “classico”, come quelli che ho descritto in questo articolo: “L’ambarasgnao”.

Padrino è piuttosto semplice da utilizzare ma, francamente, non mi sembra il caso di ripetere qui quello che potete trovare direttamente sul sito ufficiale. Se volete farvi un’idea di come si sviluppa una web application con Padrino, date un’occhiata a questi due articoli:

http://www.padrinorb.com/guides/basic-projects

http://www.padrinorb.com/guides/blog-tutorial

Cosa manca a Padrino?

A Padrino, comunque, mancano ancora molte funzionalità che sono normalmente necessarie ad un sistema destinato alla produzione, ad esempio:

  1. Non è disponibile un sistema preconfezionato per inviare un messaggio di posta ad un utente al momento della registrazione con lo scopo di verificare che l’indirizzo sia effettivamente raggiungibile.
  2. Non è disponibile un sistema preconfezionato per la creazione e gestione di un profilo utente personale. Meno che mai è disponibile un sistema che permetta ad un utente di gestire le sue pagine personali. Questa è una funzionalità sempre più spesso necessaria, a causa del social networking ma anche della moda dei siti di vendita tra privati e di annunci personali e commerciali.
  3. Non c’è il supporto per l’autenticazione a due o tre componenti (password + token hardware o password + token + biometria).

Queste, però, sono funzionalità di livello superiore, che è lecito aspettarsi semmai da un CMS come Nesta, non da un framework come Padrino.

Conclusioni

Insomma, se state cercando un framework per lo sviluppo web che vi faccia sentire una brezza di aria fresca, provate a dare un’occhiata a Padrino. Sono sicuro che lo troverete interessante.

Alessandro Bottoni

L’immagine è un grazioso ASCII-art che proviene da Flickr: flickr.com/photos/amit-agarwal/1096144644/

Comments
2 Responses to “Il Padrino (no, non Berlusconi…)”
  1. kingofgng scrive:

    Interessante. Prima o poi mi metterò a trafficare con Ruby….

  2. lordmax scrive:

    Non so, a me ruby continua a non piacere. Io preferisco di gran lunga l’accoppiata python-perl per lo sviluppo web. Semplice, lineare ed abbastanza elegante… e soprattutto ti taglia fuori tutte le phporcate che ci sono in giro. ^__^

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: