{"id":150,"date":"2011-03-08T11:17:26","date_gmt":"2011-03-08T10:17:26","guid":{"rendered":"https:\/\/alistapart.com\/it\/article\/rapid-prototyping-con-sinatra\/"},"modified":"2011-03-08T11:17:26","modified_gmt":"2011-03-08T10:17:26","slug":"rapid-prototyping-con-sinatra","status":"publish","type":"article","link":"https:\/\/alistapart.com\/it\/article\/rapid-prototyping-con-sinatra\/","title":{"rendered":"Rapid prototyping con Sinatra"},"content":{"rendered":"

Se siete web designer o web developer, avete sicuramente familiarit\u00e0 con il prototyping. Dai grezzi wireframe alla creazione di interfacce in Photoshop, i progettisti fanno la mappatura di come funzioneranno i siti prima di crearli. Negli scorsi anni, il processo di prototipazione \u00e8 cambiato in maniera significativa. Con i produttori di browser che in generale sono d’accordo sugli standard web e con l’avvento di tool quali Firebug e web inspector di WebKit, possiamo a volte evitare Photoshop in toto<\/a> e andare direttamente nel browser. Inoltre, i framework JavaScript come jQuery ci permettono di giocare con gli eventi del browser con poche righe di codice. Ma cosa succede se abbiamo bisogno di fare qualcosa in pi\u00f9? Man mano che i siti web diventano applicazioni<\/em> web, abbiamo bisogno di fare dei prototipi che implementino anche le funzionalit\u00e0 di back-end.<\/p>\n

Questo articolo introduce Sinatra, un cosiddetto \u201cmicro\u201d framework web che ci aiuta nella creazione di web app reali (sebbene semplici) in modo estremamente rapido, permettendoci di fare prototipi dei flussi e dei comportamenti che vorreste integrare nel prodotto finale. Sinatra \u00e8 scritto in Ruby, ma per i nostri obiettivi lo useremo come il \u201ccollante\u201d tra il nostro HTML\/CSS e le funzioni del dominio specifico di Sinatra, cos\u00ec non dovrete imparare pi\u00f9 di qualche semplice metodo per ottenere \u201cHello world.\u201d. In questo articolo, il nostro esempio sar\u00e0 una semplicissima app per Twitter, che prende due username e dice se uno segue l’altro.<\/p>\n

Rendere indistinti \u201cfront end\u201d e \u201cback end\u201d e la soglia dell’\u201cappness\u201d<\/h3>\n

Sebbene si parli molto di \u201capp\u201d ultimamente, metterei dei paletti tra sito internet ed applicazione web nel punto in cui il contributo di un singolo utente determina il corso degli eventi sullo schermo. Sulle prime, le app potrebbero sembrare semplici da prototipare come successioni di schermate, ma quando si ha effettivamente un app funzionante, saltano sempre fuori delle situazioni impredicibili. Ci potrebbero ad esempio essere diverse homepage per gli utenti loggati e per i nuovi utenti. Un utente potrebbe dover saltare ad un sito di terze parti per l’autenticazione prima di ritornarvi. Come rendereste tale esperienza il pi\u00f9 invisibile possibile? Una feature must-have potrebbe apparire mentre voi (in qualit\u00e0 di first user) siete frustrati cercando di fare qualcosa. Cominciare a giocare con queste azioni in Sinatra vi permette di esplorare questi problemi fin da subito, riducendo il gap tra il back end ed il front end. Se la vostra app attinge ad API di terze parti piuttosto che da un database, il \u201cback end\u201d diventa essenzialmente un blocco fisso e potete effettivamente usare dei dati reali<\/em> nel vostro mockup invece che fare \u201chard coding<\/a>\u201d (in cui \u00e8 sempre presente la tentazione di creare gli scenari migliori).<\/p>\n

Le app di Sinatra creano delle ottime proof of concept<\/a> e dei Minimum Viable Products<\/a>, che a volte possono perfino sbocciare in applicazioni complete. Sono fantastiche anche per abbozzare qualcosa in maniera estremamente rapida durante il notiziario o nelle situazioni virali. Passo spesso alcuni giorni su una rapida app di Sinatra per vedere se una determinata cosa pu\u00f2 essere fatta con una certa tecnologia o se un dato concetto \u00e8 valido prima di buttarmici a tempo pieno. In due parole, Sinatra \u00e8 il coltellino svizzero del web designer. Non ci vuole molto per imparare ad usarlo e risulta comodo per fare prototipi di grossi progetti. Inoltre, va bene quando si ha bisogno di avere una web app funzionante in maniera rapida, senza soffermarsi troppo sul back-end.<\/p>\n

\n

Primi passi<\/h2>\n

Per questo tutorial \u00e8 necessario avere installato Ruby. Se siete su un Mac, ecco un’ottima guida<\/a> di Dan Benjamin su come configurare Ruby e RubyGems per Snow Leopard. Su Windows, provate RubyInstaller<\/a> e su Ubuntu Linux lanciate sudo apt-get install ruby-full<\/code>. Dovrete anche installare RubyGems, il Ruby package manager. RubyGems distribuisce Sinatra e la Twitter gem (una libreria che ci permette di lavorare con le API di Twitter). Dovremo anche usare un po’ la linea di comando, ma solo per installare le librerie e poi per avviare ed arrestare la nostra app, quindi non preoccupatevi se non sapete usare il terminale (tuttavia, se volete un corso accelerato, vi raccomando caldamente lo screencast Meet the Command Line<\/a> di PeepCode). Giusto per sapere dove si trova su Mac OS X: \u00e8 Terminal.app nella cartelletta Utilities all’interno di Applications. Per gli scopi di questo articolo, denoter\u00f2 il prompt della linea di comando con prompt><\/code>. Scrivete semplicemente il comando dopo il prompt e premete invio. Qualunque cosa appaia sotto a prompt><\/code> \u00e8 l’output di quel comando nel terminale.<\/p>\n

Una volta installati Ruby e RubyGems, dovrete aprire Terminal e far partire:<\/p>\n

prompt> sudo gem install sinatra twitter\n<\/code><\/pre>\n
Ora abbiamo tutte le librerie che ci servono. Una volta fatto ci\u00f2, potete chiudere Terminal.<\/p>\n<\/div>\n
\n
Organizzare una app Sinatra<\/h2>\n
Adesso siamo pronti per scrivere la nostra app. Ma prima, qualche parola su come funziona Sinatra. Il framework si basa sul pattern MVC<\/a>, in cui un controller si interpone tra un \u201cmodel\u201d ossia un rappresentazione dei dati con cui state lavorando, e la view, che \u00e8 come i dati appaiono nel front-end. Un model \u00e8 solitamente un database, ma pu\u00f2 essere qualunque fonte di dati, come una API o un input dall’utente memorizzato in un cookie. La cosa importante, tuttavia, \u00e8 che non \u00e8 collegato alla sua rappresentazione sullo schermo (o, nel gergo MVC, la \u201cview\u201d). Un controller parla sia al mode sia alla view per determinare quali dati vengono inviati e dove.<\/p>\n
Nel contesto del prototyping, fare un mockup in HTML\/CSS standard costituirebbe la V in MVC, con i dati \u201chardcoded\u201d per scopi dimostrativi. Cominciando a pensare a come il model ed il controller influenzino la view vuol dire arrivare al cuore di cosa rende la vostra nuova cosa una \u201capp\u201d. Il vostro controller pu\u00f2 prendere dei segnali da entrambe i lati e determinare in che modo il dato \u00e8 rappresentato nella view o aggiornato nel model.<\/p>\n
Dal momento che Sinatra \u00e8 un \u201cmicro-framework,\u201d in realt\u00e0 fornisce solo la \u201cC\u201d e \u201cV\u201d in MVC. E’ agnostico riguardo a come vi portate il vostro model. I web framework che hanno molte pi\u00f9 funzioni come Ruby on Rails forniscono tutte e tre, perfino con un pesante database layer. Dal momento che prenderemo tutti i nostri dati dalla API di Twitter, il nostro model saranno i dati che ritorner\u00e0: avremo solo bisogno di qualche metodo per richiedere i dati che vogliamo e mandarli al nostro controller.<\/p>\n
Come funziona un controller? In Sinatra, \u00e8 semplicemente una lista di verbi HTTP<\/a> con istruzioni su cosa fare in risposta a questi verbi. Quando il vostro browser inoltra un comando GET<\/code> ad una app Sinatra con un certo pattern URL, quest’ultima far\u00e0 qualunque cosa c’\u00e8 all’interno del blocco che corrisponde a quel pattern.<\/p>\n
Ecco un esempio dell’app Sinatra pi\u00f9 semplice del mondo.<\/p>\n
In testa ad ogni file della app mettiamo le seguenti due righe per far s\u00ec che Ruby sappia che si tratta di una app Sinatra:<\/p>\n
require 'rubygems'\nrequire 'sinatra'\n<\/code><\/pre>\n
Quindi, la nostra semplice app:<\/p>\n
get '\/hello' do\n  \"Hello\"\nend\n<\/code><\/pre>\n
Tutto quello che c’\u00e8 tra il do<\/code> e l’end<\/code> \u00e8 quello che Sinatra eseguir\u00e0 quando il browser chieder\u00e0 quello specifico URL. In questo caso, se un browser naviga fino a \/hello, mostrer\u00e0 il testo \u201cHello\u201d nel browser. Ecco un esempio un po’ pi\u00f9 interessante:<\/p>\n
get '\/hello' do\n  user = params[:user]\n\n  \"Hello \" + user + \"!\"\nend\n<\/code><\/pre>\n
In questo esempio stiamo catturando i parametri della query GET per passarli alla nostra app. Se navigate su \/hello?user=Al in questa app, la pagina mostrer\u00e0 \u201cHello Al!\u201d<\/p>\n
In alternativa, per URL pi\u00f9 carini, l’esempio pu\u00f2 essere scritto cos\u00ec:<\/p>\n
get '\/hello\/:user' do\n  user = params[:user]\n\n  \"Hello \" + user + \"!\"\nend\n<\/code><\/pre>\n
Quindi, navigare su \/hello\/Al vi dar\u00e0 lo stesso risultato. Per far partire questa app, cambiate la sua directory nel Terminal (potete chiamare la app \u201cmyapp.rb\u201d per ora) e poi farla partire:<\/p>\n
prompt> ruby myapp.rb\n== Sinatra\/1.0 has taken the stage on 4567 for development with \nbackup from Thin\n>> Thin web server (v1.2.7 codename No Hup)\n>> Maximum connections set to 1024\n>> Listening on 0.0.0.0:4567, CTRL+C to stop\n<\/code><\/pre>\n
Ora che il server locale sta andando, provatela facendo puntare il vostro browser all’indirizzo  http:\/\/localhost:4567\/hello\/Al. Per fermare il server, premete control-C (dovrete fermare e far partire il server se apportate cambiamenti al codice).<\/p>\n<\/div>\n
\n
E la View?<\/h2>\n
Questo \u00e8 tutto riguardo all’aggiunta di un layer di funzionalit\u00e0 ad un mockup statico, quindi come interpoliamo queste cose nell’effettivo HTML? Usiamo le views. Sinatra rende questa operazione molto semplice cercando i file in una cartella views all’interno della root della vostra app. In ogni blocco del verbo, si punta ad una specifica view. Ecco lo stesso esempio con una view:<\/p>\n
get '\/hello' do\n  @user = params[:user]\n\n  erb :hello\nend\n\n<\/code><\/pre>\n
Ora se la vostra app si trova in \/myapp\/myapp.rb nel vostro file system, dovrete mettere la view \u201chello\u201d in \/myapp\/views\/hello.erb. Ecco a cosa assomiglia tale file:<\/p>\n
<h1>Hello <%= @user %>!<\/h1>\n<\/code><\/pre>\n
Ci sono molte cose qui. La prima cosa che potreste notare \u00e8 che mettiamo un @<\/code> prima della nostra variabile utente. Questo la fa diventare una variabile istanza. Le variabili istanza sono importanti in Ruby ma per i nostri scopi, va bene sapere solo che soltanto le variabili istanza possono essere passate alle views. Se avete alcuni dati all’interno di un \u201cverb block\u201d che volete mostrare in una view, memorizzateli in una variabile istanza o non faranno quel salto.<\/p>\n
Per richiamare la nostra view, usiamo il metodo erb<\/code>. ERB sta per \u201cembedded ruby\u201d: \u00e8 il linguaggio di template che usiamo per interpolare Ruby nel nostro HTML. Mettendo erb :hello<\/code> come ultima riga nel nostro \u201cverb block\u201d, diciamo a Sinatra che vogliamo usare ERB per fare il rendering di un template chiamato \u201chello.erb\u201d all’interno della cartella views della nostra app. Quando facciamo ci\u00f2, sapr\u00e0 che deve passare tutte le variabili istanza presenti nel nostro block a quella view.<\/p>\n
Lavorare con dati reali: la API di Twitter<\/h3>\n
Come vedete, Sinatra rende estremamente semplice creare una web app, se la soglia per la  \u201cappness\u201d \u00e8 quella che pu\u00f2 manipolare gli input dell’utente. Per renderla una app reale<\/em>, abbiamo bisogno di alcuni dati con cui lavorare. Per questo, tiriamo fuori la Twitter API tramite la Twitter gem. Dopo questa parte del tutorial, avremo un’ossatura di una app di Twitter che potrete usare per crearvi un bellissimo mockup HTML\/CSS.<\/p>\n
Creiamo una nuova cartella chiamata followapp ed un file al suo interno chiamato followapp.rb. In questo file, possiamo usare le stesse istruzioni \u201crequire\u201d di prima, ma ne aggiungeremo un’altra per includere la libreria Twitter:<\/p>\n
require 'rubygems'\nrequire 'twitter'\nrequire 'sinatra'\n<\/code><\/pre>\n
In questa app avremo due \u201cazioni\u201d: una pagina index che raccoglier\u00e0 gli utenti di cui vorremo controllare lo stato \u201cfollow\u201d e una pagina dei risultati che mostreranno se l’utente A segue l’utente B.<\/p>\n
Ecco com’\u00e8 la nostra azione della index:<\/p>\n
get '\/' do\n\n  erb :index\nend\n<\/code><\/pre>\n
Dal momento che non stiamo facendo nulla nel back end, tutto quello che dobbiamo fare \u00e8 dire a Sinatra di puntare ad una certa view. In quella view avremo una form che raccoglie i dati dell’utente e li manda alla nostra altra azione. Ecco com’\u00e8 il file \/views\/index.erb:<\/p>\n
<h1>Enter two users<\/h1>\n\n<form method=\"get\" action=\"\/follows\">\n  Does <input type=\"text\" name=\"user1\" \/> follow \n  <input type=\"text\" name=\"user2\" \/>? <input type=\"submit\" value=\"Go\" \/>\n\n<\/form>\n<\/code><\/pre>\n
Come potrete immaginare, questo li invia tramite GET, creando un URL che somiglia a questo: \/follows?user1=username&user2=username. Per gestirlo, creiamo un’altra azione nel nostro controller che risponde a tali parametri:<\/p>\n
get '\/follows' do\n  @user1 = params[:user1]\n  @user2 = params[:user2]\n\n  #not implemented yet\n  @following = is_following?(@user1, @user2)\n\n  erb :follows\nend\n<\/code><\/pre>\n
Questa azione gestisce la risposta. Prende i due parametri che gli diamo dalla pagina index e genera una variabile chiamata @following<\/code> che non abbiamo ancora implementato.<\/p>\n<\/div>\n
\n
Ti seguo se mi segui<\/h2>\n
Ecco come implementiamo il core engine della app: il metodo is_following?<\/code>, che scopre se l’utente uno segue l’utente due. Twitter non rende semplice controllare esattamente se un utente ne segue un altro, ma hanno un  followers endpoint<\/a> nella loro API che d\u00e0 come risultato una list di user ID per tutti i follower di un certo account. C’\u00e8 un problemino nell’usare questo ed \u00e8 che abbiamo bisogno di ottenere uno user ID dallo screen name per controllarlo nella lista. Perci\u00f2, useremo solo lo users\/show endpoint<\/a>. E’ semplice con la Twitter gem. Nella nostra app, ecco il metodo che scriveremo:<\/p>\n
def twitter_id(screen_name)\n  Twitter.user(screen_name).id\nend\n<\/code><\/pre>\n
Questo prende uno username e restituisce lo user ID. Cos\u00ec, se dovessi lanciare twitter_id(\"a_l\")<\/code>, otterrei 7865282. Ora, abbiamo bisogno solo di un altro metodo, is_following?<\/code>, per confrontare due ID. Ecco com’\u00e8:<\/p>\n
def is_following?(a,b)\n  followers = Twitter.follower_ids(twitter_id(b)).ids\n  followers.include?(twitter_id(a))\nend\n<\/code><\/pre>\n
Il metodo Twitter.follower_ids<\/code> restituisce un array di user ID con i follower dello user B. Poi usiamo include?<\/code> per controllare se lo user ID dell’utente A \u00e8 presente nell’array. (Per ulteriori dettagli su come funzionano include?<\/code> e gli array, guardate la Array documentation<\/a> di Ruby). Quindi, con solo poche righe di codice, abbiamo adesso il kernel della nostra app. (Notate che il metodo Twitter.follower_ids<\/code> restituisce solo i primi 5000 follower dell’utente. Ci sono modi per ottenerli tutti, ma complicherebbe la app.) Questo ci riporta alla riga nella nostra action:<\/p>\n
@following = is_following?(@user1, @user2)\n<\/code><\/pre>\n
Questa variabile istanza risponder\u00e0 quindi true<\/code> o false<\/code> a seconda che @user1<\/code> segua @user2<\/code>. Come sar\u00e0 la nostra view? (Questa \u00e8 contenuta in \/followapp\/views\/follows.erb.)<\/p>\n
<h2><%= @user1 %> <%= @following ? \"follows\" : \"does not follow\" %> \n<%= @user2 %><\/h2>\n<\/code><\/pre>\n
Ecco fatto! Questa view mostrer\u00e0 \u201cUsername follows Username\u201d o \u201cUsername does not follow Username.\u201d<\/p>\n
\"I<\/p>\n
Il risultato dell’esecuzione della nuova app Twitter.<\/p>\n<\/div>\n
Ecco l’intera \u201capp\u201d:<\/p>\n
require 'rubygems'\nrequire 'twitter'\nrequire 'sinatra'\n\ndef twitter_id(screen_name)\n  Twitter.user(screen_name).id\nend\n\ndef is_following?(a,b)\n  followers = Twitter.follower_ids(twitter_id(b)).ids\n  followers.include?(twitter_id(a))\nend\n\nget '\/' do\n\n  erb :index\nend\n\nget '\/follows' do\n  @user1 = params[:user1]\n  @user2 = params[:user2]\n\n  @following = is_following?(@user1, @user2)\n\n  erb :follows\nend\n<\/code><\/pre>\n
Nota: l’intero codice di questa app \u00e8 disponibile su Github<\/a>.<\/p>\n
In circa 20 righe di codice abbiamo un web app funzionante che pu\u00f2 fungere da prototipo per un progetto a cui stiamo lavorando. Dal momento che Sinatra rende cos\u00ec semplice costruire queste micro app, possiamo ora prototipare la funzionalit\u00e0 nel modo in cui eravamo abituati a prototipare le decisioni di interfaccia. Vedere le funzionalit\u00e0 in azione rende inoltre molto pi\u00f9 semplice decidere se vale la pena continuare un progetto oppure no. Tutto sembra bellissimo nei comp Photoshop o perfino in HTML perfetto, ma quando si usa<\/em> una app, si pu\u00f2 veramente capire se questa \u00e8 la strada giusta su cui proseguire. Con Sinatra queste decisioni possono essere prese prima piuttosto che pi\u00f9 avanti nel corso del progetto, evitando dei dolorosi cambi di direzione.<\/p>\n<\/div>\n
\n
Mostrate e raccontate<\/h2>\n
Una volta che la vostra app \u00e8 \u201cup and running\u201d, vorrete probabilmente condividerla. Ricordatevi come Sinatra parte di default a http:\/\/localhost:4567? Condividere la vostra app all’interno di una rete locale \u00e8 facile come sostituire localhost con il vostro indirizzo IP interno. Solitamente, questo inizia con 10.0 o 192.168 e lo si trova nelle preferenze di rete. Quindi, per far girare la vostra app all’interno del vostro ufficio o della vostra VPN, usate http:\/\/localip:4567.<\/p>\n
Condividere la vostra app con il mondo su Internet \u00e8 un po’ pi\u00f9 complesso, ma non molto. Il modo in assoluto pi\u00f9 semplice per lanciare (\u201cdeploy\u201d) la vostra app \u00e8 con un servizio come  Heroku<\/a> o Engine Yard<\/a>, che sono host web progettati specificamente per far girare le app Ruby (Rails e Sinatra) e vi metteranno la vostra app \u201cup and running\u201d molto rapidamente e con pochissimo sforzo. Heroku \u00e8 gratis per le piccole app, rendendolo l’ideale per condividere prototipi e ha un’interfaccia molto pi\u00f9 semplice. Engine Yard ha pi\u00f9 opzioni, ma \u00e8 abbastanza complesso e non ha piani gratuiti. Sfortunatamente, la maggior parte degli shared hosting al di fuori di questi servizi speciali non sono configurati per ospitare app Ruby, ma \u00e8 possibile che abbiate esperienze diverse.<\/p>\n
Sia che si tratti di un prototipo, di un single serving site o di qualcosa di pi\u00f9 complesso, \u00e8 sempre elettrizzante vedere anche la app pi\u00f9 semplice in internet. Aggiungere quella \u201cappness\u201d porta in vita quello che prima erano solo pagine su un server.<\/p>\n<\/div>\n
\n
Passi successivi<\/h2>\n
C’\u00e8 molto di pi\u00f9 in Sinatra di quello che ho trattato qui. Per saperne di pi\u00f9, guardate queste risorse:<\/p>\n