Una birra con Ruby e Drupal

Torna il nostro appuntamento con il Ruby Social Club, con una grande novità! Durante lo stesso evento si darà il via al Primo Drupal Social Club, cercando di mescolare due comunità tra loro diverse, ma con la stessa forte passione.

Come già testato negli ultimi incontri partiremo con dei Lightning Talk e demo in live coding in ufficio della durata di 10 minuti ciascuno. Attualmente ci manca ancora una presentazione “Ruby” related ed una “Drupal” related, quindi chiunque voglia fare una presentazione può mandare una mail ad andrew@mikamai.com. Ricordiamo che non serve nulla di difficile. Basta anche la presentazione di un lavoro su cui si è passato del tempo o di qualche trick che si vuole condividere con la community.

La data è stata fissata per mercoledì prossimo, il 17 giugno 2009, a Mikamai, in Via Ceradini 12 a Milano alle ore 18.45 per poi continuare alle 20.30 con un aperitivo al Blender.

Si parlerà di come fare deploy di applicazioni Drupal attraverso Capistrano, di come sviluppare applicazioni Facebook con Drupal e molto molto altro. Per registrarsi basta accedere a questa pagina del Wiki. Non mancate, questa volta se ne vedranno delle belle!

UPDATE: Sono stati trovati i due presentatori mancanti. Sandro Paganotti ci parlerà di Riconoscimento di oggetti (volti) con Ruby ed OpenCV, mentre Francesco Moretto ci illustrerà come sia possibile integrare CiviCRM (piattaforma open-source per la gestione di associazioni / ONG) e Drupal. A me solo i titoli suonano a dir poco interessanti !!

Rails3: Better, Faster, Stronger

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 utilizzatoActiveRecord, 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 toolsoftware 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 dideprecation 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 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!

L’autore

Marcello Barnaba, Software Engineer per lavoro e per passione, seguo quotidianamente l’evolversi di Internet che sta cambiando sia la vita di milioni di persone che la società in cui si relazionano l’un l’altro. Ho un blog e cinguetto quotidianamente, cercando di non spendere tutto lo stipendio in Sushi ;).

RailsWayCon 2009 – Un free ticket per te !

Il Berliner Congress Center di Berlino ospiterà, dal 25 al 27 Maggio, uno degli eventi di maggior risonanza per la comunità di Ruby: la RailsWayCon 2009. La capitale tedesca ospiterà una tre giorni di conferenze ed incontri con la grande community di una delle tecnologie web più innovative dei nostri tempi. Gli incontri sono aperti ad un pubblico trasversale: dai basics fino alle session da veri esperti. Con il claim Ruby ti semplifica la vita! numerosi guru di fama internazionale incontreranno gli sviluppatori: Ola Bini, Steven Bristol, Yehuda Katz, Michael Koziarski e molti altri ancora illustreranno tecniche e novità del nostro framework preferito.

Ma eccoci arrivare alla parte più interessante: la RailsWayCon mette a disposizione un free pass alla comunity italiana!. Partecipare all’estrazione che permetterà di seguire le tre giornate dell’evento è molto semplice. Sarà sufficiente inviare un email entro il 10 maggio all’inidirizzo italia AT railswaycon DOT com ed attendere l’estrazione del fortunato vincitore che sarà fatta il giorno dopo - 11 maggio. Per chi volesse saperne di più il programma e gli speaker sono a disposizione nel sito web ufficiale www.railswaycon.com, quindi non aspettate oltre!

Vinca il più fortunato!

UPDATE: la fortunata vincitrice è Alice Avallone, una delle new entry nel mondo Ruby e Rails che tra un paio di settimane avrà la fortuna di passare ben tre giorni tra conferenze e quartieri berlinesi. Sarà passata perchè è una ragazza?

Ruby Social Club, quarto appuntamento !

Dopo esserci incontrati in circa 30 persone all’ultimo evento, è in arrivo il quarto incontro del Ruby Social Club a Milano, la serata di Giovedì 16 Aprile 2009 a partire dalle 18:45 presso la sede di MIKAMAI (qui un link alla mappa), per poi proseguire al Blender verso le 20, 20:30 per l’aperitivo e per conoscerci meglio fino alle ore piccole davanti a qualche bella birra doppio malto.

Come già testato negli ultimi incontri partiremo con dei Lightning Talk e demo in live coding in ufficio della durata di 10 minuti ciascuno. Chiunque è libero di proporre le proprie idee, ma per motivi di tempo potremo avere al massimo tre presentazioni in modo da non andare a mangiare troppo tardi ! Potete scriverle direttamente nei commenti o mandare una mail ad “andrew AT mikamai DOT com“, così da semplificare l’organizzazione.

Finita la parte di coding si passerà al Blender. Niente wifi durante le bevute, ma ci sarà la possibilità di portare il laptop per far vedere i vostri progetti. Ricordate che non dovete essere per forza rubysti per venire, e non dovete portare demo o talk se non lo volete. Basta solamente la vostra presenza, curiosità e voglia di passare una bella serata tutti assieme.

UPDATE: chiunque pensi di venire può lasciare il suo nome e l’indirizzo mail all’interno del wiki di ruby-it, così da facilitarci l’organizzazione.

A prestissimo !!!

P.S. A MIKAMAI ed al Blender (per chi arriva più tardi) ci si arriva facilmente con la 54, la 60 e 61, la 90,91,92 ed il passante (fermata Dateo). Qui la mappa per maggiori dettagli.

Free your gems to the wild

Capita più spesso di quanto pensiamo di divertirci giocando con il nostro linguaggio preferito, risolvendo un problema che abbiamo incontrato al lavoro, o semplicemente scrivere provando qualche tutorial trovato qui e li. Il problema è che solitamente si dice “ok, adesso lo sistemo un pò, lo metto su un repository pubblico e ci faccio pure un bel articoletto che spiega quanto ho fatto”. Nella realtà, questo succede troppe poche volte.

La conseguenza è che piccole gemme scritte in Ruby o nel proprio linguaggio preferito rimangano chiuse nei nostri “cassetti” ed inizino a far polvere. Dopo un pò di tempo ci saremo dimenticati della loro esistenza, e probabilmente qualcuno che ne aveva bisogno non potrà mai essere a conoscenza del nostro lavoro.

Proprio per cambiare questa abitudine, domenica 29 marzo, negli uffici di Mikamai, ci sarà il quarto Hack Up. Senza andare nei dettagli, l’Hack Up è un incontro informale in cui persone con diverse conoscenze si incontrano, condividono le proprie esperienze e creano dei micro-progetti da rilasciare open source a fine giornata. In questo Hack Up lo scopo sarà duplice, in quanto oltre a sviluppare piccole applicazioni basate su temi caldi come Facebook o Arduino, ci saranno dei gruppi orientati alla discussione di progetti precedentemente creati. Ognuno potrà portare i progetti che aveva chiuso nel cassetto, potrà discutere con altri del lavoro fatto, e cercherà di renderli pubblici creando ad esempio delle gemme o dei repository su github.

Per il piano della giornata, ci troveremo a mezzogiorno al Frida per fare un branch, per poi andare alla sede di Mikamai alle 14 dove inizieremo a divertirci tutti assieme. Ovviamente, chi vuole, può saltare il branch e dormire un pochino di più visto che sempre di domenica si parla :-). Maggiori dettagli sulla giornata la trovate nel wiki dell’Hack Up.

Free your gems to the wild, on a bright sunday.

Novità in Rails 2.3: nested forms

Rails 2.3 presenta una serie di interessanti novità, nessun stravolgimento sia chiaro, ma comunque migliorie degne di nota. Spesso ci capita di avere dei form “scorrelati” da un modello in particolare, ovvero dove ci sono campi che non appartengono ad un unico modello, ma che per questioni di usabilità è meglio presentare insieme.

Supponiamo che il nostro modello dei dati voglia rappresentare una piccola biblioteca, avremo:

• un modello Book (titolo, numero di pagine)
• un modello Author (nome)
• un libro avrà almeno un autore

Volendo presentare un form per l’inserimento di un nuovo libro dovremmo prevedere il seguente flusso:

1. inserimento del libro
2. inserimento dell’autore (se non è già presente nello storico)
3. infine: associazione dell’autore al libro appena inserito (e salvataggio)

E’ molto più naturale presentare il tutto in un unico form. Per esigenze di questo tipo in Rails 2.3 sono stati introdotti i nested forms (a dire la verità è da tempo che se ne parla come dice lo stesso Ryan). Ad ogni modo, riprendendo l’esempio precedente, avremo per i modelli l’aggiunta del metodo accepts_nested_attributes_for:

class Author < ActiveRecord::Base
  has_and_belongs_to_many :books
end
 
class Book < ActiveRecord::Base
  has_and_belongs_to_many :authors
  accepts_nested_attributes_for :authors
end

Mentre per il controller relativo al libro è necessario creare il modello nidificato (nested).

def new
  @book = Book.new
  @book.authors.build
end

La differenza sostanziale sta però nella view views/book/new.html.erb dove grazie all’uso del metodo fields_for è possibile instaziare un form nidificato per il modello indicato.

  ...
  <% form_for @book do |book_form| %>
  <%= book_form.error_messages %>
 
    <p>
        <%= book_form.label :title, 'Title:' %>
        <%= book_form.text_field :title %>
    </p>
 
    <p>
        <%= book_form.label :pages_number, 'Pages:' %>
        <%= book_form.text_field :pages_number, :size => 5 %>
    </p>
 
    <strong>authors</strong>
    <p>
        <% book_form.fields_for :authors do |author_form| %>
            <%= author_form.label :name, 'Name:' %>
            <%= author_form.text_field :name, :size => 30 %>
        <% end %>
    </p>
    ...

Giusto per chiarirci le idee vediamo come apparirebbe il form.

Inoltre vediamone il corretto funzionamento.

A questo punto per salvare correttamente i dati nel controller non è necessario fare assolutamente nulla. Il modello Book si preoccuperà di creare una nuova istanza per l’author inserito, di salvarla e linkarla opportunamente ad esso. Potremmo chiederci: e se questa catena di salvataggi si spezzasse per un qualsiasi motivo? Nessun problema: le operazione di salvataggio sono atomiche in questo caso.

Inoltre, se un oggetto figlio (author nel nostro esempio) non fosse valido (es: nel sottoform abbiamo omesso qualche dato indispensabile) questo rientrerebbe nel normale flusso di salvataggio dell’oggetto padre. Infatti, gli errori per gli oggetti figli vengono aggiunti all’oggetto padre. Ovviamente è anche possibile specificare di permettere la cancellazione degli oggetti figli.

Dopo aver dato una scorsa veloce ai nested forms, ecco alcuni link per chiunque desiderasse approfondire l’argomento. Prima di tutto segnaliamo l’ annuncio ufficiale sul blog di RubyOnRails.org, per poi passare all’ ottimo esempio di Eloy Duran (la persona che ha sottoposto questa feature al core team) e concludere in bellezza con l’articolo di Ryan Daigle che espone questa nuova funzionalità.

Come ultima cosa, per chi l’avvesse “persa”, vi segnaliamo la versione in italiano (gratuita!) del libro “RubyOnRails 2.2 - What’s new?” contenente le novità dell’attuale (2.2) versione di Rails. Buon divertimento a tutti!