ateapick

Unobtrusive JavaScript...& friends

dando76 — Wed, 30 Sep 2009 10:05:00 +0200

Con il termine Unobtrusive JavaScript (JavaScript non intrusivo) si indica un paradigma di programmazione JavaScript che si basa su 3 principi fondamentali:

Senza la pretesa di voler dare una spiegazione esaustiva per ognuno dei precedenti principi, cerchiamo di capire in termini pratici cosa significa e, soprattutto, perchè scrivere JavaScript non intrusivo porta vantaggi concreti nello sviluppo e nella manutenzione di un’applicazione web.

I passi da seguire sono essenzialmente i seguenti:

Scrivere pagine HTML funzionanti senza l’utilizzo di JavaScript
Aggiungere funzioni JavaScript agli elementi del DOM senza modificare l’HTML

Facciamo un semplice esempio per evidenziare la differenza tra l’approccio “classico” e l’approccio non intrusivo. Supponiamo di avere un link di questo tipo:


    <a href="#" onclick="alert('hallo!');">say hallo</a>

E’ evidente come un browser con JavaScript disabilitato non riceverebbe alcun saluto :) Aggiungiamo pertanto un link alla pagina hallo.html:


    <a href="hallo.html" onclick="alert('hallo!'); return false;">say hallo</a>

In questo esempio, migliorato rispetto al precedente, i browser senza JavaScript seguirebbero il link alla pagina hallo.html mentre i browser con JavaScript vedrebbero aprirsi l’alert. Un ulteriore miglioramento all’esempio può essere apportato eliminando ogni riga di codice JavaScript dalla pagina spostandolo in un file esterno (hallo.js):


    <script src="hallo.js" type="text/javascript"></script>
    <a href="hallo.html" id="hallo_link">say hallo</a>

Il file hallo.js conterrà una funzione che, al caricamento della pagina, assegnerà all’evento click dell’elemento identificato da hallo_link la funzione per la generazione dell’alert. In altre parole: abbiamo modificato il nostro link mantenendo la stessa funzionalità ma in modo non intrusivo.

Vantaggi

Questo tipo di sviluppo necessita di una disciplina che può sembrare eccessivamente impegnativa rispetto ai vantaggi concreti che porta. Ammetto che in passato, come molti sviluppatori, ho deciso spesso di sacrificare l’accessibilità delle pagine in virtù della considerazione che oggi la stragrande maggioranza dei browser supporta JavaScript, per cui è accettabile rinunciare ad una completa compatibilità.

In qualità di sviluppatore Rails, inoltre, non ho mai pensato di rinunciare ai comodi helper offerti dal framework per il wrapping delle funzioni di prototype e scriptaculous.

Tutto questo finchè non ho adottato in maniera continuativa una metodologia di sviluppo “Behavior Driven” (BDD) con Cucumber e Webrat ed ho iniziato a considerare seriamente le linee guida dettate dal SEO.

Sia Webrat che i crawler dei motori di ricerca, infatti, possono essere considerati (se pur con delle eccezioni) come browser che non supportano JavaScript. La programmazione non intrusiva, quindi, mi permette di eseguire senza problemi i test di cucumber e di mantenere le pagine ottimizzate per l’indicizzazione. Come “effetto collaterale”, inoltre, le pagine così scritte sono accessibili e sicuramente più leggibili.

Questi vantaggi rappresentano per me una motivazione più che valida per abbandonare il codice intrusivo prodotto dagli helper di Rails in favore dell’alternativa non intrusiva rappresentata dall’ottimo jQuery.

jQuery on Rails

Per utilizzare jQuery con Rails esistono 2 alternative: la prima consiste nell’utlizzare jRails che essenzialmente riscrive (quasi) tutti gli helper di Rails per l’utilizzo con jQuery al posto di prototype e scriptaculous. Questa soluzione a mio avviso non è molto valida, poichè il codice prodotto sarà comunque intrusivo. Non resta quindi che scrivere JavaScript con jQuery senza l’utilizzo di alcun helper. Anche Ryan Bates incoraggia la seconda strada in uno dei suoi preziosi screencast: sarà necessario qualche sforzo in più ma alla fine il tempo impiegato sarà tutt’altro che sprecato.

Login centralizzato tra applicazioni Rails

dando76 — Thu, 18 Jun 2009 00:00:00 +0200

In un articolo precedente ho affrontato la questione del login centralizzato tra più applicazioni attraverso il protocollo CAS (Central Authentication Service). La soluzione presentata risulta una buona scelta nel momento in cui si debba gestire un’autenticazione comune tra applicazioni eternogenee, web o desktop, scritte in Rails, Java, PHP, Python o .NET.

Se però consideriamo una suite di applicazioni sviluppate in Ruby on Rails su uno stesso dominio, possiamo “giocare” con la gestione delle sessioni per condividere le credenziali degli utenti tra le applicazioni della suite.

Tipicamente, infatti, il controllo degli accessi viene implementato attraverso il salvataggio in sessione di un identificativo dell’utente, in seguito all’inserimento da parte di quest’ultimo di username e password validi. La condivisione dell’autenticazione, quindi, si riconduce alla condivisione delle sessioni tra le applicazioni.

Rails e le sessioni

In Rails una sessione è una struttura simile ad un hash (coppie chiave-valore) che permette di rendere persistenti i dati tra una richiesta e l’altra. In sessione può essere salvato ogni tipo di dato, dal momento in cui questi vengono serializzati in una delle seguenti opzioni di storage:

CookieStore (default)
ActiveRecordStore
SQLSessionStore
DRBStore
MemCacheStore

I criteri di scelta del tipo di session storage variano in funzione dei requisiti di spazio, sicurezza e performance. La soluzione basata sui cookie, ad esempio, è caratterizzata da un limite di storage di 4K ma da una velocità molto superiore rispetto alle altre. Questo è il motivo per cui è stata scelta come opzione di default. L’integrità dei dati è supportata dalla crittazione delle informazioni attraverso un algoritmo di digest (SHA1) e una chiave segreta univoca per ogni applicazione. Due applicazioni, quindi, condividono la stessa sessione se condividono la stessa chiave.

Login centralizzato

Consideriamo una suite di applicazioni identificate da sottodomini diversi dello stesso dominio:

app1.example.com
app2.example.com
app3.example.com

Per fare in modo che le applicazioni condividano la sessione, è sufficiente specificare in ogni environment.rb la stessa configurazione:

 1 config.action_controller.session = {
 2 :session_key => '_example_session',
 3 :secret => 'shared_secret_long_string'
 4 }
 5 
 6 # rails 2.3
 7 config.action_controller.session[:domain] = '.example.com'
 8 
 9 # per le versioni di rails precedenti alla 2.3
 10 # ActionController::Base.session_options[:session_domain] = '.example.com'

Supponiamo che app1 contenga il model User e la logica di autenticazione. Una volta effettuato l’accesso, anche app2 e app3 vedono lo stesso user_id in sessione. A questo punto basta definire in app1 e app2 il model User connesso al database di app1:

 1 class User < ActiveRecord::Base
 2 self.abstract_class = true 
 3 establish_connection(
 4 :adapter => "mysql",
 5 :host => "localhost",
 6 :username => "ateapick",
 7 :password => "supersecret",
 8 :database => "app1"
 9 ) 
 10 end

Un caso di studio: formula-brake.com

Di recente abbiamo implementato un’autenticazione centralizzata su una serie di webapp aziendali per Formula, uno dei nostri clienti. In particolare, una delle applicazioni (security.formula-brake.com) ha un’area riservata per la gestione di tutti gli utenti aziendali e dei loro privilegi ed una parte pubblica che funge da gateway di autenticazione per tutte le altre applicazioni.

Per la gestione delle sessioni utente abbiamo utilizzato authlogic, un’ottima gemma realizzata dal bravissimo Ben Johnson di Binary Logic.

Per passare da una webapp all’altra, esiste infine un header condiviso con i link a tutte le applicazioni della suite, sulla falsa riga di quello presente su Google.

Localizzazione URL in Ruby on Rails

dando76 — Sun, 14 Jun 2009 00:00:00 +0200

Quando si parla di internazionalizzazione e localizzazione delle applicazioni web spesso non viene data la giusta importanza alla localizzazione degli indirizzi, aspetto fondamentale in termini di SEO.

A partire da Rails 2.2 è stato aggiunto al framework il supporto nativo a I18n e L10n con una gestione delle traduzioni e delle regole di localizzazione (date, valute etc.) basata su file .yml.

Al supporto nativo mancano ancora 2 aspetti a mio parere importanti:

La localizzazione dei contenuti
La localizzazione degli indirizzi

Per quanto riguarda i contenuti continuo ad usare con soddisfazione il mio Model Localization Plugin riadattato in maniera molto semplice dall’utilizzo di GetText.locale a I18n.locale per l’identificazione della lingua corrente.

Per la localizzazione degli indirizzi ho di recente provato il translate_routes plugin che permette l’internazionalizzazione di tutti gli indirizzi dell’applicazione con una sola riga di codice oltre, ovviamente, alle traduzioni stesse su file .yml.

Localizzazione degli indirizzi

Supponiamo di avere una webapp in lingua inglese ed una risorsa project identificata da indirizzi del tipo:

http://www.example.com/ projects
http://www.example.com/ projects / my-great-project

L’utilizzo del plugin permette di aggiungere le route seguenti:

http://www.example.com/ it / progetti
http://www.example.com/ it / progetti / my-great-project

Per completare la localizzazione basta gestire la traduzione dei permalink sul database (localizzazione dei contenuti) per avere:

http://www.example.com/ it / progetti
http://www.example.com/ it / progetti / il-mio-grande-progetto

Da notare come la linua base (in questo caso l’inglese) non abbia bisogno del prefisso en. Questo significa che nel momento in cui decidiamo di aggiungere il supporto multi-lingua alla nostra applicazione, tutti i “vecchi” indirizzi rimangono inalterati.

Backup incrementali su Amazon Simple Storage Service (Amazon S3)

dando76 — Sat, 28 Mar 2009 00:00:00 +0100

In Informatica il backup dei dati è una buona abitudine da adottare in ambito domestico ed una pratica che diventa assolutamente doverosa quando si passa alla sfera professionale.

Per le nostre applicazioni web abbiamo scelto una soluzione che prevede il backup giornaliero sui Server di Amazon attraverso il servizio denominato Amazon Simple Storage Service o, più semplicemente, Amazon S3.

L’iscrizione al servizio è gratuita e prevede un costo a consumo molto basso a fronte di un’elevata affidabilità.

La scelta di effettuare i backup su server remoti presenta indubbi vantaggi in termini di sicurezza ma ha un’inevitabile controindicazione legata alla lentezza con cui avvengono i processi di copia, soprattutto per grandi quantità di dati. Per ottimizzare le prestazioni (e i costi) effettuiamo backup incrementali, attraverso la sincronizzazione dei dati tra lo storage locale e lo storage remoto.

La scelta del protocollo di sincronizzazione è ricaduta sull’ottimo rsync che, affiancato a s3fs, permette in pochi minuti di configurare il proprio server linux e dormire sonni tranquilli :)

Configurazione del backup

Supponiamo di voler configurare il backup del database e dei dati dell’applicazione myapp secondo il seguente scenario:

i dati risiedono nella directory /var/apps/myapp
il database (mysql) si chiama myapp_db
avete creato una directory per il backup locale in /var/backups/myapp
il vostro userid Amazon è s3uid
la vostra password Amazon è s3pwd
avete creato il bucket myapp_bucket su Amazon
avete creato la directory /mnt/s3 dove verrà montato il bucket

L’idea è quella di sincronizzare i dati ed effettuare il dump del database nella diretory di backup locale, montare il bucket tramite s3fs ed effettuare la sincronizzazione tra /var/backup/myapp e /mnt/s3 tramite rsync.

Il passaggio di sincronizzazione intermedio è utile per minimizzare il tempo di inattività di myapp che dovrà essere opportunamente sospesa durante la prima fase di backup (locale) onde evitare incongruenze sul database.

Creazione dello script

Sulla base dello scenario che abbiamo preso come esempio, lo script di sincronizzazione sarà del tipo seguente:

#!/bin/bash
sospendi myapp
rsync -avzO —delete /var/apps/myapp /var/backups/myapp
mysqldump —user=xxx —password=xxx myapp_db > /var/backups/myapp/dump.sql
riattiva myapp
s3fs myapp_bucket -o accessKeyId=s3uid -o secretAccessKey=s3pwd /mnt/s3
rsync -avzO —delete /var/backups/myapp /mnt/s3
umount /mnt/s3

A questo punto basta automatizzare lo script mettendolo in crontab e il gioco è fatto. Ricordatevi di controllare la correttezza dei permessi su tutti i file e le directory.

Login centralizzato con il protocollo CAS

dando76 — Fri, 30 Jan 2009 20:09:00 +0100

Per “login centralizzato” si intende la condivisione da parte di più applicazioni web di un servizio di autenticazione degli utenti che garantisca l’acesso ad ogni applicazione attraverso un’unica login.

Consideriamo alcuni scenari:

La Intranet di un’azienda è dotata di una serie di applicazioni web ad accesso protetto i cui utenti devono essere autenticati attraverso il servizio di Active Directory con il quale vengono gestiti gli accessi di tutte le altre applicazioni aziendali.
Un’organizzazione vuol pubblicare su Internet alcune applicazioni o siti web ad accesso condiviso (vd. Google Apps ) in modo che un utente, una volta eseguito l’accesso su una qualsiasi delle applicazioni, possa accedere a tutte le altre senza dover inserire nuovamente username e password.
In una SOA (Service-Oriented Architecture) alcuni Web Sevice devono comunicare con gli altri attraverso l’HTTP e condividere le credenziali per poterlo fare.

Come possiamo implementare un sistema di autenticazione centralizzata in questi (eterogenei) scenari? Prendiamo in considerazione una delle possibili soluzioni: l’utilizzo di un servizio basato sul protocollo CAS.

Central Authentication Service (CAS)

Sviluppato dall’Università di Yale e diventato nel 2004 un progetto JA-SIG, CAS è un protocollo divenuto abbastanza maturo ed utilizzato; il suo funzionamento di base prevede un server ed un client ed è rappresentato dallo schema seguente:

L’utente tenta di accedere ad una pagina protetta
Il CAS client reindirizza il browser alla pagina di login sul CAS server
Il CAS server valida username e password su un datasource
Il browser viene rimandato alla pagina richiesta inizialmente con un service ticket
Il service ticket garantisce la persistenza delle credenziali su tutte le altre applicazioni

Datasource

La forza di questo protocollo risiede nella possibilità di utilizzare qualsiasi datasource per la gestione degli utenti. Può essere usato un DBMS, Active Directory, un servizio LDAP, un file XML etc. Gli utenti possono essere addirittura autenticati con i propri account Gmail. Il controllo può essere anche effettuato su più datasource ordinati per priorità: ad esempio possiamo controllare le credenziali dell’utente sul un nostro database e, in caso di autenticazione fallita, proseguire il controllo su Gmail.

Implementazione CAS in Ruby

Esistono implementazioni in Ruby sia del server che del client. Entrambi sono installabili come gemme e permettono di costruire e configurare l’intera infrastruttura. Il server viene fornito con gli authenticator più comuni (SQL, LDAP, ActiveDirectory, Google) che possono essere modificati con poche righe di codice. E’ molto semplice personalizzare anche l’aspetto grafico della pagina di login del server, così da adattarla al look and feel delle applicazioni che ne condividono il servizio.

Posizionamento assoluto e relativo con IE6

dando76 — Fri, 09 Jan 2009 09:22:00 +0100

Attraverso la proprietà position: è possibile controllare in maniera piuttosto precisa il posizionamento all’interno di una pagina web di un elemento di tipo block-level.

In particolare il posizionamento relativo – position: relative – usato in combinazione con una o più proprietà di offset (top:, right:, bottom:, left:) consente di definire lo scostamento dell’elemento rispetto alla posizione originale assunta dall’elemento stesso all’interno del normale flusso di rendering della pagina. Utilizzato ad esempio in combinazione con le proprietà top: 10px e left: 10px, l’elemento verrà disegnato spostato di 10px in alto e a sinistra rispetto alla posizione nella quale si sarebbe dovuto trovare.

Il posizionamento assoluto – position: absolute – consente invece di collocare esattamente un elemento in un qualsiasi punto della pagina, indipendentemente dalla presenza degli altri elementi. Utilizzato ad esempio in combinazione con le proprietà top: 0px e left: 0px, l’elemento verrà disegnato nell’angolo superiore sinistro della pagina.

È importante tener conto che un elemento posizionato in modo assoluto “esce” dal normale flusso e gli altri elementi della pagina si comportano come se l’elemento stesso non esistesse.

Posizionamento assoluto all’interno di un posizionamento relativo

Ciò che si rivela estremamente utile nella realizzazione di template HTML di una certà complessità è l’utilizzo combinato delle due proprietà, in particolare inserendo un elemento posizionato in maniera assoluta all’interno di un altro posizionato in maniera relativa:

 
 
    <div style="position: relative">
        <div style="position: absolute"></div>
    </div>

Così facendo si re-inizializzano le coordinate 0,0 dell’elemento absolute rispetto all’angolo superiore sinistro dell’elemento padre, invece che rispetto all’intera pagina. Quindi dando le proprietà top: 0px e left: 0px l’elemento absolute verrà disegnato nell’angolo superiore sinistro dell’elemento relative che lo contiene.

Internet Explorer 6

Inutile sottolineare come IE6 interpreti in modo del tutto arbitrario questa impaginazione e necessiti di un apposito workaround. Per tutti coloro che pensano che IE6 sia ormai storia, l’ultimo rilevazione di Market Share del Dicembre 2008 lo posiziona al secondo posto tra i browser dopo il fratello maggiore IE7 e subito prima di Firefox 3, con ancora il 20% di quota di installato.

Il problema principale dell’utilizzo di questa tecnica risiede nel fatto che IE6 non sempre inizia a calcolare le coordinate dell’elemento posizionato in maniera assoluta dal nuovo “0,0” originato dall’elemento contenitore. Lo fa solo a volte!

IE6 infatti contiene una proprietà nascosta chiamata “hasLayout” sulla quale non è possibile intervenire attraverso i fogli di stile. É una variabile nascosta che che il “browser dei miracoli” utilizza per tenere traccia di ogni elemento della pagina. Trovate maggiori informazioni qui.

Per risolvere il nostro problema invece è possibile dare al nostro elemento un layout assegnandogli degli attributi come larghezza, altezza, floating o altro ancora. Spesso però, come sarà sicuramente capitato a molti, è impossibile assegnare detti attributi agli elementi senza inficiare il corretto layout della pagina.

Fortunatamente ci viene incontro un fix specifico per IE6:

 
 
    <!--[if IE]><style>
    .ie_layout {
      height: 0;
      he\ight: auto;
      zoom: 1;
    }
    </style><![endif]-->

É sufficiente definire nel foglio di stile la classe .ie_layout secondo la sintassi sopra riportata e assegnarla all’elemento padre, ovvero quello posizionato in maniera assoluta. Il commento condizionale [if IE] è un comando proprietario di Internet Explorer che fa si che questa classe e questi attributi siano interpretati solo da quest’ultimo.

Come personale linea di sviluppo, cerco sempre di non utilizzare i filtri nei CSS per evitare di introdurre istruzioni non richieste e di sporcare il codice. Preferisco piuttosto utilizzare più codice HTML distribuendo gli attributi su vari elementi indentati (ad esempio per ovviare al noto problema del Box Model di IE).

Tuttavia in alcuni casi limite come questo, sono l’unica risorsa per riuscire ad ovviare a tutti quei problemi introdotti da alcuni browser ed in modo particolare dal mai troppo denigrato Internet Explorer 6.

Sviluppare applicazioni Facebook con Ruby on Rails

dando76 — Thu, 08 Jan 2009 00:00:00 +0100

Facebook non ha certo bisogno di presentazioni, soprattutto dopo il successo esponenziale che, da qualche mese a questa parte, ha vissuto anche in Italia.

Come in tutte le storie di successo c‘è chi utilizza morbosamente e chi critica cinicamente l’applicazione del momento; tuttavia nessuno può negare come il fenomeno debba essere degno di considerazione, non solo da un punto di vista sociale ma anche per il potenziale offerto dal bacino di utenti (attualmente più di 170.000.000) che raccoglie.

In qualità di sviluppatore apprezzo molto la presenza di REST API che consentono la realizzazione di applicazioni sulla piattaforma Facebook; una scelta che, a mio avviso, conferma la regola per cui le politiche di “apertura informatica” siano assolutamente vincenti, come già ampiamente dimostrato da realtà del calibro di Google (Maps, Calendar, Youtube etc.), 37Signals e da tutti i loro “discepoli”.

Per iniziare a scrivere applicazioni Facebook con Rails, segnalo 2 risorse interessanti, entrambe firmate “Mike Mangino”, uno dei maggiori esperti al mondo sull’argomento, reperibili da The Pragmatic Bookshelf:

Il primo è un libro, il secondo uno screencast suddiviso in due parti che tratta anche l’utilizzo dei plugin facebooker (un wrapper ruby sulle REST API di Facebook) e facebooker_authentication (per l’autenticazione di utenti Facebook).

Considerato che anche la visionaria Apple annovera l’integrazione di Facebook tra le novità dei iPhoto ’09, può essere che valga la pena approfondire l’argomento.

PDF::Writer vs RGhost per la creazione di pdf in ruby

dando76 — Tue, 18 Nov 2008 00:00:00 +0100

Esistono molti scenari nei quali si rende necessaria la creazione di documenti pdf a partire, ad esempio, dai dati presenti in un datatabse.

Ruby offre varie soluzioni che possano essere di ausilio alla risoluzione di questo tipo di problema. Una di queste è la gemma PDF::Writer, che consente la creazione di PDF attareverso l’utilizzo di librerie native. Potete trovare una buona guida introduttiva in italiano all’interno del blog dei nostri amici di extendi.

Recentemente ho sperimentato un approccio alternativo a pdf-writer utilizzando Rghost, una gemma che utilizza il framework Ghostscript per la conversione tra formati (PDF,PS,GIF,TIF,PNG,JPG,etc) e permette l’utilizzo di template EPS nella creazione dei documenti.

Sulla documentazione ufficiale è disponibile un manuale molto ben fatto. Grazie alla sua sintassi più ruby-like e, soprattutto, alla possibilità di utilizzare dei template (EPS) nella creazione dei documenti, rghost sta decisamente guadagnando un posto privilegiato tra i miei “attrezzi del mestiere”, fermo restando che ritengo siano entrambi ottimi progetti.

Ruby on Rails Menù

dando76 — Mon, 03 Nov 2008 00:00:00 +0100

In molte interfacce viene utilizzato un menù in cui, durante la navigazione, la voce selezionata assume uno stile diverso dalle altre, attraverso l’assegnazione di una classe (es. “selected”) sulla base della pagina corrente.

Questo tipo di effetto può essere ottenuto in vari modi, ad esempio assegnando la classe “selected” in base ai valori assunti dal current_controller e dalla current_action.

Personalmente preferisco un approccio più semplice, pragmatico e flessibile.

Scriviamo un helper di questo tipo:

 1 def menu_item (key, path, type)
 2 if instance_variable_get("@current_#{type}_item") == key
 3 link_to content_tag(:span, key.to_s), path, :class => "selected"
 4 else
 5 link_to content_tag(:span, key.to_s), path 
 6 end
 7 end

Utilizzando l’helper possiamo scrivere un menù nel modo seguente:

 1 <ul>
 2 <li><%=menu_item :home, home_path, 'first_level' %></li>
 3 <li><%=menu_item :about, about_path, 'first_level' %></li>
 4 <li><%=menu_item :projects, projects_path, 'first_level' %></li>
 5 </ul>

A questo punto basterà impostare (ad esempio attraverso un before_filter) la variabile @current_first_level_item con un valore tra :home, :about o :projects nei controller per selezionare la voce corrente. Scegliendo valori diversi del paramentro type il controllo verrà fatto su variabili diverse e sarà quindi molto semplice far convivere con lo stesso sistema menù diversi, ad esempio un menù di primo livello ed uno di secondo livello.

La flessibilità deriva dal fatto che in ogni action siamo “liberi” di selezionare le giuste voci di ogni menù, svincolandoci da sistemi più rigidi basati sull’url.

Macchine a stati finiti (FSM) e il plugin acts_as_state_machine

dando76 — Tue, 21 Oct 2008 00:00:00 +0200

Una macchina a stati finiti (FSM) è un sistema dinamico costituito da un insieme finito di stati e da una funzione di trasferimento che ne specifica il comportamento, ovvero definisce le regole che determinano i passaggi della macchina da uno stato all’altro.

La macchina può essere rappresentata tramite un grafo diretto i cui nodi rappresentano gli stati e gli archi rappresentano le transizioni di stato delle macchina.

Sono molteplici i problemi che possono essere modellati con una FSM e non poteva certo mancare un plugin Rails che ne rendesse agile la codifica: si tratta di acts_as_state_machine, una manciata di righe di codice sicuramente migliorabili ma che tutto sommato assolvono bene al loro compito. Una volta installato il plugin, occorrerà soltanto aggiungere un campo state di tipo string all’oggetto cui vogliamo assegnare le caratteristiche di FSM.

Facciamo un semplice esempio: vogliamo creare un’applicazione web accessibile attraverso iscrizioni a pagamento. Dopo la registrazione, l’iscrizione sarà attiva e, ogni volta che riceveremo un pagamento, dovrà essere generata la fattura commerciale per il cliente. In caso di mancato pagamento l’iscrizione verrà sospesa mentre, se il cliente deciderà di cancellare la sua registrazione, l’iscrizione verrà eliminata. Ad ogni passaggio di stato dovrà essere inviata una notifica e-mail al cliente.

La prima cosa da fare è modellare gli stati e gli eventi che determinano le transizioni di stato: niente di meglio che usare la vecchia accoppiata carta/penna, creando un diagramma simile a quello della figura precedente.

Utilzzando il plugin risulta estremamente semplice tradurre il diagramma nel seguente modello Rails:

 1 class Subscription < ActiveRecord::Base
 2 
 3 acts_as_state_machine :initial => :active
 4 
 5 state :active
 6 state :suspended
 7 
 8 event :payment do
 9 
 10 transitions :from => :active,
 11 :to => :active,
 12 :guard => :get_payment
 13 
 14 transitions :from => :suspended,
 15 :to => :active,
 16 :guard => :notify_reactivation
 17 end
 18 
 19 event :payment_failure do
 20 
 21 transitions :from => :active,
 22 :to => :suspended,
 23 :guard => :notify_suspension
 24 
 25 transitions :from => :suspended,
 26 :to => :suspended,
 27 :guard => :notify_new_payment_failure 
 28 end
 29 
 30 private
 31 def get_payment
 32  # make payment invoice
 33  # send payment email
 34 end
 35 
 36 def notify_reactivation
 37  # send reactivation email 
 38 end
 39 
 40 def notify_suspension
 41  # send suspension email
 42 end
 43 
 44 def notify_new_payment_failure
 45  # send alert for new payment failure
 46 end
 47 end

Nell’esempio, gli eventi possono essere chiamati attraverso i metodi:

@subscription.payment!
@subscription.payment_failure!

Gli eventi signup e cancel del diagramma coincidono invece con l’effettiva creazione e distruzione della subscription e non con delle transizioni di stato.

Il modello è molto semplificato rispetto ad un caso reale, dove dovrebbero essere tenuti in considerazione altri stati ed eventi come la modifica dell’iscrizione o la sospensione definitiva in seguito ad un numero massimo di pagamenti falliti. Quello che conta è l’approccio con cui viene affrontato il problema e la “robustezza” della soluzione che ne scaturisce: un sistema ben modellato è un’ottima base per la scrittura di codice elegante e flessibile e le macchine a stati sono, a mio avviso, uno degli esempi più calzanti di come una buona progettazione porti vantaggi concreti, attribuendo un significato tangibile a quanto raccomandato in tutti i migliori testi di programmazione.

HATBM Checkboxes

dando76 — Wed, 08 Oct 2008 00:00:00 +0200

Un problema molto semplice e ampiamente documentato è l’aggiornamento tramite checkbox delle associazioni tra due model che sono in relazione n:m tra loro:

 1 class Conference < ActiveRecord::Base
 2 has_and_belongs_to_many :speakers
 3 end

 1 class Speaker < ActiveRecord::Base
 2 has_and_belongs_to_many :conferences
 3 end

Per selezionare gli speaker nella form di una conference, tramite l’utilizzo di checkbox, basta scrivere:

 1 <!-- conferences/_form.rhtml -->
 2 <% Speaker.all.each do |speaker| %>
 3 <div>
 4 <%= check_box_tag "conference[speaker_ids][]", speaker.id, @conference.speakers.include?(speaker) %>
 5 <%= speaker.name %>
 6 </div>
 7 <% end %>

e modificare l’update action in modo che l’aggiornamento delle associazioni funzioni correttamente anche nel caso in cui nessuna checkbox sia selezionata:

 1 # conferences_controller.rb
 2 def update
 3 params[:conference][:speaker_ids] ||= []
 4  #...
 5 end

Parametrizzare un'applicazione Rails

dando76 — Mon, 06 Oct 2008 00:00:00 +0200

In molte applicazioni può essere opportuno utilizzare delle costanti con cui parametrizzare alcune funzionalità, eventualmente in base all’environment corrente.

Un esempio calzante è la gestione dei parametri di connessione al database che, in un applicazione Rails, vengono scritti in /config/database.yml.

Seguendo lo stesso approccio, è molto semplice impostare parametri personalizzati. Creiamo il file /config/application.yml e scriviamo i nostri parametri con una struttura del tipo:

 1 development:
 2 key1: value1
 3 key2: value2
 4 key3: value3 
 5 
 6 test:
 7 key1: value1
 8 key2: value2
 9 key3: value3 
 10 
 11 production:
 12 key1: value1
 13 key2: value2
 14 key3: value3

Creiamo poi il file /config/initializers/application.rb:

 1 
 2 APPLICATION = YAML.load_file("#{RAILS_ROOT}/config/application.yml")[RAILS_ENV]
 3

In questo modo avremo a disposizione dell’applicazione il seguente hash:

APPLICATION = {‘key1’ => ‘value1’, ‘key2’ => ‘value2’, ‘key3’ => ‘value3’}

i cui valori saranno quelli che abbiamo impostato per l’ambiente corrente.

Popolare il database di sviluppo in un progetto Rails

dando76 — Tue, 30 Sep 2008 00:00:00 +0200

In un progetto Rails molto spesso è utile popolare il database di sviluppo con dati di test, in modo da simulare l’ambiente di produzione.

Supponiamo di sviluppare un Social Network che preveda l’iscrizione di utenti e la creazione di relazioni di conoscenza tra essi. Per testare le funzionalità del sistema potrebbe essere utile popolare il database in development con un numero sufficientemente grande di iscrizioni e relazioni.

Un’opzione potrebbe essere quella di armarsi di una buona dose di pazienza e fare data entry…bene…passiamo alla seconda opzione: scrivere uno script in ruby (o in qualsiasi altro linguaggio) che crei, con un po’ di fantasia, un buon numero di record sul database.

Un’idea potrebbe essere quella di sfruttare un contatore di record per creare campi distinti:

id name email phone 1 user_1 user_1@example.com 0001 2 user_2 user_1@example.com 0002 3 user_3 user_3@example.com 0003 … … … … 1000 user_1000 user_1000@example.com 1000

Ho seguito questo approccio finchè non ho provato le gemme pupulator e faker, attraverso le quali è molto semplice scrivere un rake task come il seguente:

 1 namespace :db do
 2 desc "Svuota e popola il database con dati di test"
 3 task :populate => :environment do
 4 require 'populator'
 5 require 'faker'
 6 
 7 [User, Link].each(&:delete_all)
 8 
 9 User.populate 1000 do |user|
 10 user.name = Faker::Name.name
 11 user.email = Faker::Internet.email
 12 user.phone = Faker::PhoneNumber.phone_number
 13 end
 14 
 15 Link.populate 10000 do |link|
 16 link.user_id = 1..1000
 17 link.friend_id = 1..1000
 18  # trascuriamo per semplicità il controllo friend_id != user_id
 19 end
 20 end

Il comando rake db:populate popola il database con 1000 utenti e 10000 relazioni casuali tra di essi. La documentazione delle due gemme mostra come sia molto comodo creare dati fittizzi e abbastanza…“realistici” ;)

id name email phone 1 Jack Shephard jack@lost.com 48 15162342 2 Kate Austen kate@lost.com 48 15162342 3 John Locke john@lost.com 48 15162342 … … … … 1000 Mr. Eko eko@lost.com 48 15162342

Ruby on Rails: oggetti multipli nella stessa form

dando76 — Tue, 23 Sep 2008 00:00:00 +0200

Supponiamo di avere 2 model Author e Book in relazione 1:n tra loro: vogliamo scrivere una form per la creazione e la modifica di un author e di uno o più book associati. In particolare vogliamo avere la possibilità di aggiungere e rimuovere un numero qualsiasi di book nella stessa form di author. Il risultato sarà qualcosa di questo tipo:

Cominciamo con l’esprimere la relazione tra i due oggetti:

 1 class Author < ActiveRecord::Base 
 2 has_many :books, :dependent => :destroy 
 3 end

 1 class Book < ActiveRecord::Base 
 2 belongs_to :author
 3 end

Nella action new di /app/controllers/authors_controller.rb costruiamo un’istanza di un author e di 3 book associati nel seguente modo:

 1 def new 
 2 @author = Author.new 
 3 3.times do
 4 @author.books.build
 5 end
 6 end

In /app/views/authors/new.html.erb creiamo la form che contiene i campi dell’autore e dei libri associati (racchiusi nel parziale /app/views/authors/_book.html.erb). Per semplicità consideriamo solo il campo name per l’autore e il campo title per i libri.

 1 <% form_for @author do |f| %> 
 2 <p>Name: <%= f.text_field :name %></p> 
 3 <div id="books"> 
 4 <%= render :partial => 'book', :collection => @author.books %>
 5 </div> 
 6 <p><%= add_book_link "add book" %></p> 
 7 <p><%= f.submit "save" %></p> 
 8 <% end %>

Il codice per add_book_link (riga 6) si trova in /app/helpers/authors_helper.rb e genera un link Ajax che “appende” un nuovo libro alla form:

 1 def add_book_link(name) 
 2 link_to_function name do |page| 
 3 page.insert_html :bottom, :books, :partial => 'book', :object => Book.new 
 4 end 
 5 end

Il codice di /app/views/authors/_book.html.erb è il seguente:

 1 <div class="book"> 
 2 <% new_or_existing = book.new_record? ? 'new' : 'existing' %> 
 3 <% prefix = "author[#{new_or_existing}_book_attributes][]" %> 
 4 <% fields_for prefix, book do |book_form| -%> 
 5 <p> 
 6 Titolo: <%= book_form.text_field :title %> 
 7 <%= link_to_function "remove", "$(this).up('.book').remove()" %> 
 8 </p> 
 9 <% end -%> 
 10 </div>

La chiave sta nell’helper fields_for (riga 4) che si comporta in maniera molto simile a form_for, ovvero renderizza tutti i campi dell’oggetto cui si riferisce ma senza racchiuderli in un tag form.

A questo punto basta definire opportunamente i metodi new_book_attributes e existing_book_attributes, oltre alla callback save_books, in /app/models/author.rb:

 1 after_update :save_books
 2 
 3 def new_book_attributes=(book_attributes) 
 4 book_attributes.each do |attributes| 
 5 books.build(attributes) 
 6 end 
 7 end
 8 
 9 def existing_book_attributes=(book_attributes) 
 10 books.reject(&:new_record?).each do |book| 
 11 attributes = book_attributes[book.id.to_s] 
 12 if attributes 
 13 book.attributes = attributes 
 14 else 
 15 books.delete(book) 
 16 end 
 17 end 
 18 end 
 19 
 20 def save_books 
 21 books.each do |book| 
 22 book.save(false) 
 23 end 
 24 end

Le action edit e create in /app/controllers/authors_controller.rb sono quelle “classiche”. La action update deve essere invece dotata di un accorgimento per fare in modo che tutto funzioni anche nel caso in cui vengano rimossi dalla form tutti i book:

 1 def update 
 2 params[:author][:existing_book_attributes] ||= {} 
 3 
 4  # salvataggio "classico" di @author
 5 end

Questo tutorial è stato riadattato a partire da alcuni screencast di Ryan Bates (episodi 73, 74, 75). Nei nostri progetti abbiamo utilizzato questo sistema per permettere all’utente il caricamento simultaneo di più immagini associate ad un oggetto (utilizzando il plugin attachment_fu), sistema che abbiamo intenzione di evolvere attraverso l’utilizzo di fleximage e swfupload per ottenere la progress bar degli allegati in upload e la loro validazione prima del loro effettivo caricamento.

Google Chrome e le applicazioni web

dando76 — Mon, 08 Sep 2008 00:00:00 +0200

Da pochi giorni è uscito Chrome, il tanto atteso browser del colosso di Mountain View.

Come prevedibile la risonanza mediatica è stata notevole; tra le (più o meno innovative) feature ce n‘è una che ha catturato la mia attenzione più delle altre, ovvero la possibilità di creare delle scorciatoie per applicazioni web.

Questa funzionalità può apparire non così rilevante ma, a mio parere, è molto significativa poichè proviene direttamente dal mondo delle applicazioni desktop.
Le pagine web stanno diventando veri e propri software e, come tali, hanno bisogno di strumenti di nuova concezione.

Gli sviluppatori di Google commentano così:

“Il Web si è evoluto enormemente negli ultimi anni: le semplici pagine di testo hanno lasciato il posto a sofisticate applicazioni interattive, di conseguenza ci siamo subito resi conto che era necessario un ripensamento del concetto stesso di browser. Ciò che avevamo in mente non era semplicemente uno strumento di navigazione, bensì una moderna piattaforma in cui eseguire pagine e applicazioni web. Ed è proprio questo che ci siamo prefissati di realizzare.”

Un'alternativa a Globalize: GetText + Model Localization Plugin

dando76 — Tue, 02 Sep 2008 00:00:00 +0200

Globalize è un ottimo plugin che copre tutti gli aspetti legati all’internazionalizzazione di un’applicazione Rails, tra cui:

Traduzione dei testi “statici” (View Translations)
Traduzione dei testi “dinamici” (Model Translations)
Localizzazione di date, numeri, valute etc…

Il setup del plugin provvede alla crazione di 3 tabelle sul database già popolate con le informazioni di localizzazione relative a 239 paesi e con le traduzioni comuni (es. giorni della settimana) in 186 lingue.

Sia le View Translations che le Model Translations vengono scritte sul database ed è possibile, quindi, creare un’area (riservata) dell’applicazione che si occupi esclusivamente del CRUD delle traduzioni, gestibili quindi in autonomia dall’utente finale.

La necessità di un’alternativa a Globalize è nata col tempo a partire da alcune considerazioni:

“Ho veramente bisogno delle informazioni di localizzazione di 239 paesi e 186 lingue se il mio sito supporterà al massimo le 5 lingue europee più comuni?”
“E’ corretto gestire nello stesso modo la traduzione delle parti statiche e dinamiche di un sito?”
“Sono realmente necessari tutti gli accessi al database effettuati da Globalize per la localizzazione?”

Le risposte, nel mio caso, credo siano a questo punto evidenti; in particolare ritengo che ci sia una sostanziale differenza tra i due tipi di traduzioni che giustifica la ricerca di due soluzioni diverse.

Per le traduzioni statiche ho scelto (ad oggi con soddisfazione) di utilizzare GetText e la sua implementazione in ruby. A questo indirizzo è disponibilie una guida molto chiara da cui iniziare.

Per le traduzioni dinamiche non sono riuscito a trovare niente di adeguato alle mie esigenze per cui ho scritto un plugin per la localizzazione dei modelli che, unito a GetText, completa la soluzione all’internazionalizzazione da me adottata.

Il suo funzionamento è molto semplice. Supponiamo di avere il model Task con un attributo name che vogliamo rendere traducibile in inglese e francese.

Attraverso una migrazione aggiungiamo gli attributi che conterranno le 2 traduzioni:

 1 class AddTranslationsToTaskName < ActiveRecord::Migration
 2 def self.up
 3 add_column :tasks, :name_en, :string
 4 add_column :tasks, :name_fr, :string
 5 end
 6 
 7 def self.down
 8 remove_column :tasks, :name_en
 9 remove_column :tasks, :name_fr
 10 end
 11 end

Il plugin estende ActiveRecord definendo il metodo localize che si usa così:

 1 class Task < ActiveRecord::Base
 2 localize :name
 3 end

A questo punto basterà utilizzare l’attributo preceduto da un underscore (in perfetto stile GetText) sia nelle form, per la modifica (riga 5):

 1 <h1>Editing task</h1>
 2 
 3 <% form_for(@task) do |f| %>
 4 <%= f.error_messages %>
 5 <p><%= f.text_field :_name %></p>
 6 <p>
 7 <%= f.submit "Update" %>
 8 </p>
 9 <% end %>
 10 
 11 <%= link_to 'Show', @task %> |
 12 <%= link_to 'Back', tasks_path %>

che in visualizzazione (riga 3):

 1 <h1>Showing task</h1>
 2 
 3 <p><%=@task._name%></p>
 4 
 5 <%= link_to 'Edit', edit_task_path(@task) %> |
 6 <%= link_to 'Back', tasks_path %>

La lingua in cui viene modificato o visualizzato l’attributo è la lingua corrente.

Chiaramente nel momento in cui dovessi affrontare lo sviluppo di un’applicazione in 20 lingue, tra cui l’arabo e il giapponese, tornerei a prendere in seria considerazione l’adozione di Globalize!

RESTful (Rails) Development

dando76 — Mon, 01 Sep 2008 00:00:00 +0200

REST è un acronimo introdotto nel 2000 da Roy Fielding, uno dei principali autori del protocollo HTTP, che identifica uno stile di architettura per sistemi distribuiti (come il World Wide Web) incentrato sul concetto di risorsa.

Una risorsa è una qualsiasi entità identificabile (univocamente) da un’URL, manipolabile attraverso uno dei 4 verbi dell’http (get, post, put, delete) e indipendente dalla sua rappresentazione. Consideriamo ad esempio la risorsa identificata dall’URL:

http://www.ateapick.com/people/filippo

Attraverso i 4 verbi dell’HTTP posso manipolare (CRUD) la risorsa secondo le seguenti convenzioni:

POST http://www.ateapick.com/people/filippo (C) GET http://www.ateapick.com/people/filippo (R) PUT http://www.ateapick.com/people/filippo (U) DELETE http://www.ateapick.com/people/filippo (D)

Posso inoltre ottenere diverse rappresentazioni della stessa risorsa discriminando la richiesta tramite il mime-type:

GET http://www.ateapick.com/people/filippo (html) GET http://www.ateapick.com/people/filippo.xml GET http://www.ateapick.com/people/filippo.rss GET http://www.ateapick.com/people/filippo.iphone GET http://www.ateapick.com/people/filippo.wii

Rails 1.2 ha introdotto il supporto allo sviluppo REST attraverso un sistema di routing che tiene in considerazione il verbo HTTP utilizzato nella richiesta dell’URL. Le diverse rappresentazioni di una risorsa si possono invece ottenere utilizzando l’instance method respond_to di ActionController::MimeResponds.

Con il rilascio di Rails 2.0 il paradigma REST ha assunto un ruolo ancor più importante nel framework: chiari segnali sono il nuovo scaffolding e il nuovo modo di nominare i file della view che esplicita la creazione di diverse rappresentazioni basate sui mime-type.

Esistono molti documenti che trattano in maniera approfondita l’argomento. Un’ottima guida introduttiva sullo sviluppo RESTful in Rails può essere scaricata a questo indirizzo. Da un po’ di tempo ormai ho fatto mio questo stile di programmazione e, una volta superate le prime difficoltà di “ambientazione”, ho cominciato ad assaporarne tutti i vantaggi: oggi considero le linee guida scelte per il rilascio di Rails2 una consacrazione della qualità e della lungimiranza di questo framework.

Oltre a veicolare lo sviluppo di applicazioni secondo il pattern MVC, il RESTful Rails impone un’ulteriore disciplina nella codifica che garantisce maggiore compattezza, migliore leggibilità, “pretty-urling” e semplicità nella costruzione di API. Pensare ad un’applicazione orientata al CRUD di risorse inizialmente può destare delle perplessità:

“non è un approccio limitato? In una webapp molto spesso ho bisogno di altre azioni rispetto alla semplice creazione, visualizzazione, modifica o cancellazione di una risorsa…”

In realtà dipende da come si interpreta l’applicazione stessa. Un’azione molto comune come la login da parte di un utente, ad esempio, rientra perfettamente nell’approccio REST se pensata piuttosto come la creazione di una sessione; specularmente la logout corrisponde alla distruzione di una sessione; in definitiva il concetto di risorsa è talmente generico che con un minimo di sforzo di astrazione può essere adattato a qualsiasi modello.

Riguardo alla lungimiranza, l’impronta RESTful così marcata del nuovo Rails pone ancor più il framework come scelta azzeccata per chi vuol fare web 2.0 e per chi vuol seguire la cordata di progetti che rappresentano i primi passi verso la costruzione del cosiddetto web semantico. Mi riferisco a progetti come OpenID, un network distribuito e decentralizzato, nel quale la tua identità è un URL e può essere verificata da qualunque server supporti questo protocollo, o come Gravatar secondo il quale è il tuo avatar ad essere identificato da un’URL sull’intero web.

Se poi consideriamo anche le relazioni tra le risorse descritte attraverso XFN e FOAF entriamo nel vasto campo delle Reti Sociali con un’apertura tale per cui perfino Google si accorgerà delle nostre killer webapp… ;-)