Rails 3.0 è uscito nel 2010 e il merge con Merb è stato un successo. Oggi Rails è alla versione 8.x, ha integrato tutto quello che qui si auspicava (modularità, API stabili, engines come cittadini di prima classe) e molto di più. Lighthouse è stato dismesso, therubymine.com non esiste più, e molti dei link in questo articolo sono morti — ma le idee di fondo restano valide.
Tutti (o quasi) gli sviluppatori web conoscono o hanno sentito almeno parlare di Ruby on Rails, un framework full-stack per la creazione di applicazioni web utilizzando il linguaggio di programmazione Ruby.
Qualora non abbiate mai sentito parlare nè di Rails, nè di web application, sulla wikipedia italiana è presente una brevissima panoramica su di esso, in cui è impossibile non essere colpiti dalla sua Filosofia. Rails è infatti definito dall’autore David Heinemeier Hansson “opinionated software”, cioè un software che impone determinati approcci e workflow durante la progettazione e la stesura di un progetto, con i vantaggi e svantaggi che questo può portare.
Altra caratteristica che ha contraddistinto le prime evoluzioni di Rails (2003-2007) è stata la mancanza di interfacce robuste per la sua estensione attraverso plug-in esterni, complice anche una controversa caratteristica di Ruby: il monkeypatching. In Ruby le classi non sono chiuse: è possibile modificarne il funzionamento in qualsiasi punto del programma, e questo vale anche per le classi base (ad es. String, Integer, …). Ciò ha portato al proliferare di plug-in ed estensioni al framework che facevano leva su dettagli implementativi privati, la cui stabilità nel tempo non è garantita, con tutti i problemi di manutenibilità che ne derivano: chi ha seguito le prime fasi del rilascio di Rails non può non ricordare il lungo dibattito che seguì dall’implementazione dei Rails Engines.
In seguito, gli engines sono stati rivalutati, tanto da venir presentati all’edizione 2009 di RailsConf, come una via funzionale per la realizzazione di componenti software riutilizzabili e completi, poichè possiedono dei Model, View, Controller, e delle Route che connettono gli URI a cui risponde l’applicazione al codice che ne implementa la logica.
Questo cambio di visione da parte di DHH è stato determinato dalla sua esperienza di trovarsi a reimplementare diverse applicazioni che sarebbero potute essere racchiuse in un engine e successivamente riutilizzate.
Simili considerazioni sono state anche espresse in proposito al forte carattere opinionated di Rails, i cui approcci imposti non riguardano solo l’utilizzo di un certo pattern, ma anche l’imposizione di uno specifico “pezzo di software” che lo implementi. Ad esempio, per accedere ad un database in Rails viene utilizzato ActiveRecord, un’implementazione del pattern di Object-Relational Mapping che permette di avvicinare il modello relazionale dei database attualmente diffusi sul mercato al modello object oriented utilizzato da Ruby e pervasivamente ereditato da Rails.
Il contesto Open Source¶
In un contesto open source, però, tale restrizione è vista come castrante da tanti developer. Nonostante ActiveRecord faccia bene il suo lavoro, è importante poter scegliere il componente più adatto ad un determinato scopo: è un concetto che qualsiasi sviluppatore esperto fa suo, tralasciando le inutili guerre di religione :).
La modularità, estendibilità e la presenza di un’interfaccia ragionata e soprattutto stabile sono i principi fondanti di Merb, un altro framework Ruby-based per la creazione di applicazioni web database-backed, la cui headline è “Looking for a hacker framework?”. Merb consiste in un piccolo core di funzionalità ben organizzate, su cui una serie di plug-in costruiscono e realizzano l’impianto completo su cui poi realizzare la propria applicazione.
Con Merb è possibile utilizzare il preferito degli ORM, template engine, mailer e testing frameworks disponibili, in quanto tutti si appoggiano al medesimo core. Inoltre è semplice realizzarne di nuovi per soddisfare le esigenze più disparate: è una filosofia molto simile a quella UNIX, in cui ogni singolo tool software implementa limitate funzionalità (ma bene), dove per risolvere problemi più complessi è sufficiente l’utilizzo in cascata di diversi tool.
Dati i numerosi vantaggi di questo approccio, completamente opposto a quello iniziale di Rails, anche un Rated R individual dalle strong opinions ha deciso di cambiare idea ancora una volta, e annunciare al mondo la notizia che nessuno si aspettava di ricevere: rails e merb diventeranno un unico progetto!
Il risultato di questo merge si concretizzerà nella prossima major release di Rails, la 3.0, che è stata oggetto di un consistente talk a RailsConf 2009, e le cui caratteristiche saranno:
Meno “opinionated”: non più una singola “Rails Way”, bensì multiple “Rails Ways”, data la possibilità di scegliere tra differenti ORM (AR, Sequel, DataMapper, CouchRest, …), templating engines (ERb, HAML, Liquid, Markaby, …) Javascript libraries (Prototype, jQuery, MooTools, Dojo, …) e testing frameworks (Test::Unit, RSpec, Mocha, …).
Più veloce: il team di sviluppo di Merb è sempre stato attento alle performance, cercando di evitare la scrittura di software con troppa “magic” (e.g. abuso di method_missing) e che seguisse la sua filosofia di modularità e circoscrizione ad di un componente ad un singolo dominio applicativo. Rails3 erediterà questi approcci al design garantendo migliori performance. In quest’ottica è avvenuto anche l’inserimento di Metal in Rails 2.3.
Una public API: Sbagliando, s’impara. Se è vero che non è possibile immaginare l’uso che un utente finale fà di un software, allo stesso modo sono molteplici e imprevedibili gli usi che uno sviluppatore può fare di un framework, e tali diventano anche evil se non gli è fornita una API e delle linee guida per la sua estensione. Il lungo dibattito riguardo i Rails Engines ha fatto storia, e non è il caso di ripetere gli stessi errori.
Più modulare e più agnostico, dirette conseguenze dell’introduzione di una API, e che permettono quindi la realizzazione di applicazioni “componibili”, essendo il framework non una singola torre, ma più un set di strumenti a-la lego technic (bei ricordi :). Una funzionalità che conferma questo approccio, già disponibile in Rails 2.3, sono i Rails templates: essi offrono una DSL per automatizzare l’inizializzazione di una nuova applicazione, attraverso la scrittura dei requisiti in un file .rb da passare come argomento del parametro -m al comando rails. Questo blogpost di lifo contiene tutte le informazioni per un quickstart.
Più evolvibile: diretta conseguenza della maggiore modularità e di un cambio di vision. In Rails3 non ci saranno più “Vacche sacre”, bensì qualsiasi aspetto del framework potrà essere soggetto a cambiamento. Non spaventatevi: a patto che la API rimanga stabile e ci sia un definito processo di deprecation per le API marcate come obsolete, per lo sviluppatore non ci sarà alcun mal di testa. Molti più ce ne sono stati in passato a causa dell’assenza di API, dove ognuno implementava come meglio credeva le feature di cui aveva bisogno.
Live from the stage¶
Uno (dei tantissimi) esempi di come realizzare questo grande merge è possibile vederlo direttamente su github, nello specifico due commit su ActionController. Esso è stato completamente ristrutturato, e la nuova implementazione è stata riposta in una nuova directory, new_base, nel primo commit introdotta la Rails2Compatibility e rimossi i fixture template.
Successivamente, nel secondo commit, è avvenuto lo switch dalla vecchia ActionController::Base alla nuova, inserendo anche qualche hack temporaneo per far sì che i test continuassero a funzionare.
Seguire un merge di questa portata operato da professionisti affermati è un ottimo esercizio, soprattutto per chi si è da poco affacciato all’ingegneria del software, e vuole imparare sul campo le best practices che portano le big rewrite al successo.
Il futuro?¶
Rails3 sarà un notevole passo avanti nella storia di questo framework, che si lascerà dietro le parti più controverse della sua filosofia, e permetterà alla community di farlo evolvere in maniere prima impossibili. È auspicabile per ogni sviluppatore seguirne il suo sviluppo, poichè è anche possibile imparare processi e approcci al project management, oltre che allo sviluppo di software. La gestione del progetto rails con relative milestone è gestita attraverso lighthouse, mentre tutto il codice sorgente è conservato su github. Data la natura di git (e github), chiunque può, in qualsiasi momento, effettuare un fork di rails e modificarlo come più gli piace. È una possibilità che poche altre piattaforme per lo sviluppo di software opensource permettono.
Inoltre, è possibile seguire il Rails Core Team su twitter, mantenersi aggiornati sugli sviluppi ad alto livello seguendo il blog di Ryan Daigle, seguire le discussioni attorno a Rails3 attraverso il mail-to-web gateway presente su ruby-forum.com e, ovviamente, aggiungere therubymine.com ai propri bookmark poichè su queste pagine riparleremo presto di Rails3 :).
A presto!
Nota: Questo articolo è stato originariamente pubblicato su therubymine.com, un blog collettivo italiano su Ruby e Rails che non esiste più. Lo ripubblico qui per preservarlo.