Tesina del corso di

Progetto di Sistemi Web

Prof. Alberto Leone

Ruby On Rails

Matteo Canato
Matricola 065788
01/07/2010
2 Ruby On Rails

Sommario
1. Introduzione .................................................................................................................................... 3
2. Caratteristiche................................................................................................................................. 5
2.1. Il paradigma MVC .................................................................................................................... 5
2.1.1. Controller ........................................................................................................................ 5
2.1.2. View................................................................................................................................. 6
2.1.3. Model .............................................................................................................................. 6
2.2. Routing delle richieste ............................................................................................................ 6
2.2.1. ReST................................................................................................................................. 7
2.3. Rappresentazioni dei dati in RoR ............................................................................................ 8
3. Tools ................................................................................................................................................ 9
3.1. Programmare in Rails .............................................................................................................. 9
3.2. Testing e Debugging in Rails................................................................................................... 9
4. Documentazione ............................................................................................................................. 9
5. Progetto realizzato ........................................................................................................................ 10
5.1. Definizione dei requisiti di progetto ..................................................................................... 10
5.1.1. Definizione degli applicativi che dovranno essere realizzati ........................................ 10
5.1.2. Definizione dei requisiti funzionali................................................................................ 11
5.1.3. Definizione dei requisiti non funzionali ........................................................................ 11
5.2. Definizione dei vincoli progettuali e architetturali del sistema ............................................ 12
5.3. Progettazione del sistema di teleoperazioni ........................................................................ 12
5.4. Realizzazione del progetto .................................................................................................... 13
5.5. Realizzazione pratica ............................................................................................................. 15
6. Licensing e costi ............................................................................................................................ 16
7. Posizione di mercato e hype ......................................................................................................... 17
8. Prospettive future ......................................................................................................................... 18
9. Diffusione ...................................................................................................................................... 18
10. Conclusioni ................................................................................................................................ 19
 Introduzione 3

1. Introduzione
Ruby on Rails, o più semplicemente Rails, è un framework server-side che rende più facile lo
sviluppo, l’implementazione e la gestione di applicazioni web database-backed.

Nei mesi che seguirono la sua versione iniziale nel luglio del 2004, Rails è passato da essere un
giocattolo sconosciuto ad essere un fenomeno mondiale e, più importante, è diventato il frame work
scelto per l’implementazione di una vasta gamma di cosiddette applicazioni Web 2.0. Molte società
multinazionali hanno già scelto Rails per le loro applicazioni web, ad esempio:

 Twitter
 YellowPages
 Hulu
 Justin TV
 Scribd.com
 GitHub

Ma da cosa è dovuto il successo di Ruby On Rails? In primo luogo, un gran numero di sviluppatori
erano “frustrati” con le tecnologie che stavano usando per creare applicazioni web.
Indipendentemente dal linguaggio utilizzato, sia esso Java, PHP oppure . NET, c'è stato un crescente
senso che il loro lavoro fosse troppo duro. Con l’arrivo di Rails programmare applicazioni web è
diventato più “facile” in quanto esso coniugava l'agilità del mondo LAMP con la rigorosa
organizzazione del mondo J2EE.

Questa facilità è dovuta, ad esempio, dal fatto che tutte le applicazioni Rails sono implementati
utilizzando il paradigma architetturale Model-View-Controller (MVC) disaccoppiando l'accesso ai dati
e la business logic dalla presentazione dei dati e dall'interazione con l'utente.

Gli sviluppatori Java per poter realizzare un’architettura MVC devono basarsi, previa configurazione
degli stessi, su framework come Arazzi e Struts. Ruby On Rails nasce nativamente con questo
paradigma e và oltre fornendo una serie di funzionalità come un sistema di testing integrato e
automatico all’inserimento di una nuova funzionalità nel codice.

Le applicazioni Rails sono scritte in Ruby, un moderno linguaggio di scripting orientato agli oggetti.
Ruby è conciso, senza essere incomprensibile in modo da poter esprimere pensieri in codice Ruby in
modo naturale e chiaro. Questo porta a sorgenti brevi ma che siano di facile scrittura e (altrettanto
importante) di facile lettura anche mesi e mesi dopo.

Rails porta questa particolarità di Ruby al limite, estendendolo in nuovi modi e con nuovi concetti
che rendono effettivamente più facile la vita ai programmatori. A differenza di altri framework è
possibile anche eseguire operazioni che normalmente vanno fatte in file di configurazione esterni
(come le relazioni tra i campi di una tabella) anziché all'interno del codebase invece. Questo rende
molto più facile vedere cosa sta succedendo. In sostanza Rails consente uno sviluppo estremamente
agile ed incrementale delle applicazioni.
4 Ruby On Rails

A titolo di esempio, si osservi quante informazioni vengono espresse in poche righe di codice per la
definizione della classe del modello per un progetto.
class Project < ActiveRecord::Base
belongs_to :portfolio
has_one :project_manager
has_many :milestones
has_many :deliverables, :through => :milestones

validates_presence_of :name, :description

validates_acceptance_of :non_disclosure_agreement
validates_uniqueness_of :short_name
end

Ma Ruby On Rails si basa su altri due principi fondamentali:

 DRY
 Convention Over Configuration

DRY sta per “Dont-Repeat-Yourself” ovvero “non ripetere se stessi”. Questo principio prevede che
ogni pezzo di conoscenza in un sistema dovrebbe essere espresso in un solo luogo.

Rails usa tutta la Potenza di Ruby per realizzare questo. La duplicazione di codice in un’applicazione
Rails è pressoché assente: si definisce di cosa si ha bisogno in un certo punto (rispettando la
convenzione del paradigma MVC) e si prosegue nella programmazione. Inoltre eventuali modifiche
allo schema dell’applicazione non comportano necessariamente la modifica di molte altre pagine,
come accade con altri web frameworks.

Il principio di “Convention Over Configuration” è un altro concetto essenziale e indica che Rails offre
soluzioni predefinite per quasi tutti gli aspetti che compongono un’applicazione. Attenendosi alle
convenzioni è possibile realizzare un’applicazione Rails con meno codice di quello che occorre per la
configurazione XML di una tipica applicazione web in Java.

Ruby on Rails non vuole imporre un nuovo standard per le tecnologie web ma, al contrario, cerca di
favorirne la definizione e il corretto utilizzo. Rails infine facilita agli sviluppatori l’integrazione di
funzioni quali Ajax e interfacce RESTful nel proprio codice in quanto il supporto a queste è nativo dal
framework stesso.
 Caratteristiche 5

2. Caratteristiche

2.1. Il paradigma MVC

Ruby On Rails è un framework basato sul pattern architetturale Model-View-Controller (MVC) il
quale permette di disaccoppiare l'accesso ai dati (Database) e la business logic (Model) dalla
presentazione dei dati (View) e dall'interazione con l'utente (Controller).

La figura seguente illustra il funzionamento del paradigma MVC, nel quale si possono distinguere 4
fasi:

1. Il browser invia la richiesta (URL) di una risorsa

2. Il Controller interagisce con il Model (e questo con la base di dati)
3. Il Controller invoca la View
4. La View renderizza i risultati su una nuova pagina e la invia al browser

Analizziamo di seguito le singole componenti Model, View e Controller.

2.1.1. Controller
Il controller in Rails è un oggetto ActionController ed è il cuore pulsante di RoR. ActionController è
quel componente che processa e risponde ad eventi (tipicamente interazioni con utente) e può
effettuare cambiamenti sul modello.

In ogni controller si definisce un insieme di azioni che possono essere chiamate dall'utente. Più nel
dettaglio, i controller sono classi Ruby derivate da ActionController::Base che implementano un
metodo pubblico per ogni azione supportata.

Ruby On Rails è in grado di mappare le richieste Web in chiamate a metodi di un particolare

controller. Ad esempio una chiamata all’URL:

http://myhost/pippo/paperino
invoca il metodo paperino del controller PippoController.

Infine per ogni azione si deve definire una View apposita per la rappresentazione dei risultati.
6 Ruby On Rails

2.1.2. View
Le View si basano su ActionView e rappresentano il templating system di RoR. Esse presentano il
modello in una forma adatta per l'interazione con l'utente come (X)HTML.

Per la generazione dinamica di pagine HTML si utilizza ERb, abbandonando RHMTL a partire da Ruby
On Rails 2.0. Ogni View ha accesso alle variabili di istanza del Controller ad essa associato. Inoltre
ActionView prevede alcune funzionalità avanzate quali:

 Supporto alla generazione di XML e JS

 Partials e layouts per il riuso di porzioni di codice e framing comuni
 Helpers per facilitare la visualizzazione di particolari tipi di informazione.

2.1.3. Model
Il Model è la rappresentazione domain-specific delle informazioni su cui l'applicazione opera. I model
si basano su ActiveRecord, un ORM estremamente potente e facilissimo da usare che permette,
attraverso un'interfaccia orientata agli oggetti, tutti i servizi inerenti la persistenza dei dati,
astraendo nel contempo le caratteristiche implementative dello specifico RDBMS utilizzato.

In particolare ActiveRecord fornisce alcune funzionalità non presenti in altri ORM per altri framework
di sviluppo (come J2EE):

 Supporto per praticamente ogni DBMS esistente (da Sqlite a Oracle)

 Meccanismo delle migrations per modifiche incrementali al DB
 Consente la definizione dello schema dei dati direttamente in Ruby anziché in SQL
 Maggiore portabilità e semplicità di utilizzo.

2.2. Routing delle richieste

Il routing è il meccanismo che gestisce l'associazione tra URL e action eseguite. Tutte le route sono
specificate nel file config/routes.rb .

Tradizionalmente, Rails mappa la richiesta Web a http://localhost/pippo/paperino/5 in

una chiamata al metodo paperino del controller PippoController in
app/controllers/pippo_controller.rb, con params[:id] = 5.

È tuttavia possibile cambiare la configurazione del routing di Rails in modo molto flessibile.

Sempre a proposito di routes, Ruby On Rails inoltre è attualmente la migliore piattaforma per lo
sviluppo di applicazioni ReST.
 Caratteristiche 7

2.2.1. ReST
ReST (Representational State Transfer) è uno stile architetturale per la realizzazione di applicazioni
Web. ReST viene originariamente formalizzato da Roy Fielding (uno dei principali architetti di HTTP)
nella sua tesi di dottorato, dopo un'accurata analisi delle caratteristiche che hanno portato al
successo del Web

Il principio alla base di ReST è che lo stato e la funzionalità delle applicazioni vengano suddivisi in
risorse e ogni risorsa è univocamente indirizzabile utilizzando una sintassi universale per l'utilizzo in
link ipermediali.

Per poter manipolare le risorse, client e server comunicano attraverso un'interfaccia standardizzata,
scambiandosi delle “rappresentazioni” delle risorse. Questa interfaccia, in particolare, è costituita
da:

 Un insieme limitato di operazioni ben definite

 Un insieme limitato di “content types”, con supporto opzionale al code-on-demand

2.2.1.1. ReST in pratica

Accedendo ad una pagina Web, l'utente visualizza la rappresentazione corrente della risorsa ad essa
associata. Cliccando su un link, l'utente fa partire una transizione dello stato della risorsa che risulta
nella renderizzazione di una pagina contenente il nuovo stato.

L'interfaccia per manipolare le risorse in REST è semplicemente il protocollo HTTP: come SQL usa
INSERT, SELECT, UPDATE, and DELETE per manipolare dati relazionali, ReST usa i metodi PUT, POST,
GET, e DELETE di HTTP per manipolare le risorse.

Nell’immagine seguente è possibile vedere un esempio di mapping tra URL e risorse in un blog:

Rails è, per sua natura, la migliore piattaforma attualmente esistente per la realizzazione di
applicazioni ReST. L'adozione di ReST semplifica moltissimo il design delle applicazioni in Rails, in
quanto si ha:

 Un controller per ogni tipo di risorsa

8 Ruby On Rails

 Ogni controller deve implementare le stesse identiche action

 Basta identificare su che tipo di risorse un'applicazione si basa e il design è già fatto.

2.2.1.2. Vantaggi
I vantaggi derivati dall’utilizzo di un’interfaccia ReST per la nostra applicazione sono quindi:

 Supporto per il caching

 Facile e maggiore estendibilità
 Scalabilità del server molto migliorata (non si deve mantenere lo stato della comunicazione)
 Il client è enormemente semplificato
 Non richiede un meccanismo di resource discovery separato (uso di hyperlinks nelle
rappresentazioni).

2.3. Rappresentazioni dei dati in RoR

Quello attraverso il quale client e server interagiscono realmente non sono le risorse stesse, ma una
loro particolare rappresentazione. Esistono diverse rappresentazioni delle risorse e i controller
quindi devono, dove necessario, essere sviluppati per lavorare con diverse rappresentazioni delle
risorse.

La rappresentazione da fornire al client viene scelta a seconda del suffisso della URL (es: .xml, .js) o
dello header HTTP Accept (es: “text/javascript”) forniti dal browser.

La discriminazione viene effettuata dal metodo respond_to all’interno della action del controller
indicato dall’URL. Ad esempio è possibile far ritornare:
respond_to do |format|

format.html

format.js { @model.to_json }

format.xml { @model.to_xml }

end
 Tools 9

3. Tools
3.1. Programmare in Rails
E’ possibile programmare praticamente con ogni editor di testo a seconda del sistema operativo in
uso. Tuttavia si consiglia sempre l’utilizzo di editor di testo che permettano di effettuare almeno il
syntax highlighting come vim o TextMate.

Per quanto riguarda gli IDE la versione 6.x di NetBeans offre un ottimo supporto nativo a Rails, con
tanto di funzionalità quali l’autocompletamento dei metodi. Anche Eclipse offre un supporto
decente alla programmazione Rails/Ruby, ma occorre installare i plugin:

 Aptana RadRails - http://www.aptana.com/

 DLTK - http://www.eclipse.org/dltk/

3.2. Testing e Debugging in Rails

Ruby On Rails offre di default un supporto molto avanzato al testing automatico delle applicazioni.
Questo permette alle applicazioni Rails di:

 Migliorare il design della propria applicazione

 Avere un feedback immediato sulla accuratezza del proprio codice durante la fase di
scrittura
 Verificare che il codice continui a funzionare anche dopo nuove modifiche

Rails prevede diversi meccanismi integrati (alcuni un po’ sui generis, altri molto evoluti) per il testing.
Tra questi occorre citare le suite:

 Testing funzionale di modelli e controller

 Integration testing
 Mocks
 RSpec.

4. Documentazione
La documentazione su Rails era, fino a qualche anno fa, tipicamente di pessima qualità. Per fortuna
le cose ora stanno cambiando in fretta, grazie anche alla sempre maggiore diffusione di sviluppatori
Ruby/RoR e al supporto della comunità.

La documentazione cartacea è disponibile solo in lingua inglese e:

 Sam Ruby, Dave Thomas, David Heinemen Hansson “Agile Web Development with Rails”,
Fourth Edition, Pragmatic Bookshelf, June 2010 (considerata “la Bibbia” di RoR, per Rails 3.0)
 Sam Ruby, Dave Thomas, David Heinemen Hansson “Agile Web Development with Rails”,
Third Edition, Pragmatic Bookshelf, December 2008 (per Rails 2.2.2)
 Mike Clark, “Advanced Rails Recipes: 84 New Ways to Build Stunning Rails Apps”,
Pragmatic Bookshelf, May 2008 (per Rails 2.2.0)
 Obie Fernandez, “The Rails Way”, Addison-Wesley, November 2007 (per Rails 2.0)
10 Ruby On Rails

Le edizioni in italiano, che (quando esistono) sono obsolete anche di alcuni anni e per tale motivo
sono caldamente sconsigliate.

La documentazione online sviluppata dalla community (sempre crescente anche in termini di

documentazione), offre numerosi siti e soprattutto screencasts sempre aggiornati dai quali è
possibile attingere quasi ogni tipo di informazione.

 rubyonrails.org (Sito ufficiale)

 railscasts.com (Screencasts sempre aggiornati)
 rubyinside.com
 railsbrain.com
 ruby-it.org
 therubymine.com

5. Progetto realizzato
Il prototipo realizzato è un progetto reale attualmente in produzione presso un’importante azienda
leader nel settore per la produzione di macchine automatiche. Di seguito viene data una descrizione
generica del progetto evitando di divulgare informazioni protette da segreto.

Il progetto realizzato ha come obiettivo lo sviluppo di un sistema di teleoperazioni per le macchine

automatiche. Tale sistema consente il monitoraggio in real time di una qualsiasi macchina da
remoto, l'aggiornamento del software e la riconfigurazione da remoto dei parametri di
funzionamento, la produzione di report sugli eventi interni alla macchina con dati tecnici e gestionali
(con dati riguardanti sia il funzionamento della macchina che le vendite) e infine la diagnostica
remota della macchina.

Il sistema di teleoperazioni è stato realizzato con tecnologie informatiche innovative in modo da

soddisfare tutti i requisiti progettuali con una soluzione che sia scalabile, sicura, facilmente
estendibile e personalizzabile.

5.1. Definizione dei requisiti di progetto

Sono state realizzare alcune applicazioni, caratterizzate da una serie di requisiti funzionali e non
funzionali, come descritto nel seguito.

5.1.1. Definizione degli applicativi che dovranno essere realizzati

Le funzionalità previste per il sistema di tele operazioni sono:

 Telemonitoring. Monitoraggio in real time di una qualsiasi macchina da remoto con

connessione su richiesta (i.e. non always-on);
 Teleassistenza. Aggiornamento software e riconfigurazione da remoto dei parametri di
funzionamento della macchina;
 Telereporting. Report periodici oppure a richiesta sugli eventi interni alla macchina con
possibilità di trattare sia dati tecnici che gestionali (dati riguardanti sia il funzionamento della
macchina che le vendite);
 Progetto realizzato 11

 Telediagnosi. Diagnostica remota della macchina, con integrazione di un sistema intelligente

che informi sulle eventuali soluzioni da adottare per risolvere il problema rilevato.

5.1.2. Definizione dei requisiti funzionali

Il set di applicazioni realizzato è caratterizzato da alcuni requisiti funzionali:

 visualizzazione sinottica dello stato della macchina in tempo reale alcuni parametri della
macchina tra i quali:
o visualizzazione degli stati della macchina registrati nelle ultime 24 ore;
o visualizzazione e modifica dei parametri di funzionamento della macchina e
eventuale ripristino dei valori di default da remoto;
o analisi allarmi, diagnosi dei guasti e visualizzazione dei guasti su immagine della
macchina;
o creazione di watchdog che controlli eventuali mancate connessioni giornaliere da
parte delle macchine;
o gestione e invio SMS. Invio di un SMS ad un numero di cellulare predefinito
(manutentore di zona) a ogni allarme verificatosi sulle macchine;
 autenticazione utenti. L'accesso al sistema dovrà essere controllato tramite una fase di
autenticazione preliminare, che identifica l'utente che accede al sistema e, attraverso una
tabella contenuta nel database, determina il livello e i permessi dell'utente e
conseguentemente il grado di dettaglio nella visualizzazione dei dati a cui ha accesso. Il
sistema deve prevedere diversi livelli di accesso (ad esempio, amministratore, cliente,
operatore tecnico);
 localizzazione delle macchine tramite Google Maps. Si prevede, in futuro, di visualizzare le
macchine a cui si ha accesso attraverso dei mash-up su Google Maps. Per creare il link si
potrebbe utilizzare una tabella statica contenente le coordinate geografiche del luogo di
installazione della macchina;

5.1.3. Definizione dei requisiti non funzionali

Tutte le applicazioni soddisfano anche i seguenti requisiti non funzionali:

 sicurezza. Il sistema deve garantire il massimo livello di sicurezza. Quindi i server sono di
proprietà (niente housing e hosting) e quindi sono configurati e continuamente mantenuti
per evitare possibili attacchi e per prevenire la perdita di dati e informazioni. E’ presente
anche un sistema automatico di backup. Inoltre la comunicazione con il server deve avvenire
attraverso protocolli di comunicazione protetti e su porte standard, sia tra macchine e server
che tra utente e server;
 disponibilità. Il sistema deve essere sempre disponibile e fronteggiare situazioni di guasti
senza presentare perdite di servizio;
 scalabilità. Il sistema deve essere scalabile ed essere in grado di sopperire alle esigenze di
crescita della rete di macchine controllate;
12 Ruby On Rails

 multicanalità di accesso. Le informazioni raccolte sul server dovranno essere disponibili in

modalità multicanale, al fine di poter essere accessibili da qualunque dispositivo di accesso,
ad esempio PC, laptop e smartphone;
 registrazione dati ricevuti in un database. Questa base dati deve contenere i dati ricevuti
dalle macchine e creare una corrispondenza tra esse e gli utenti del sistema. La base dati è il
centro di tutte le applicazioni che si intendono sviluppare. Il formato di rappresentazione
dati deve è standardizzato, come anche il suo dimensionamento (numero di eventi raccolti
per macchina e il numero di eventi disponibili online);
 separazione dati da servizio. E’ presente una distinzione tra raccolta dati provenienti dalle
macchine, presentazione (business logic, autenticazione, etc) e logica di servizio (analisi,
report, data mining);

5.2. Definizione dei vincoli progettuali e architetturali del sistema

I vincoli progettuali e architetturali adottati per il sistema web sono:

 utilizzo di tecnologie Open Source

 sistema operativo Linux
 server Web Apache
 DataBase Management System MySQL 5
 framework per lo sviluppo di applicazioni Web Ruby on Rails 2.x
 utilizzo di standard internazionali di rappresentazioni dei dati (XML).

Il motivo che sta alla base delle scelte è lo sviluppo basato su tecnologie innovative Open Source che
proteggano nel futuro gli investimenti eseguiti e non richiedano di legarsi a fornitori di software
proprietari. Le tecnologie scelte sono già mature (e molto ben supportate) per un impiego di tipo
industriale.

L'infrastruttura del sistema è composta da due elementi principali: una base dati contenente le
informazioni relative alle macchine e agli utenti e un'interfaccia Web che consenta l'accesso a tali
dati.

La base dati è gestita con MySQL mentre l'interfaccia web sarà fornita da un'applicazione sviluppata
con il framework Ruby on Rails. Rails è abbastanza matura come tecnologia in quanto è utilizzata per
la realizzazione di applicazioni per tutte le categorie: finanza, e-commerce, arte, media,
comunicazione, ecc.

5.3. Progettazione del sistema di teleoperazioni

A livello di progetto, sono stati definiti molti aspetti, tra cui:

 progettazione dell'architettura di tutto il sistema;

 formato dei dati nel DB;
 policy di sicurezza per il server;
 policy di sicurezza per l'applicazione Web;
 Progetto realizzato 13

 aggiunta di sistemi di localizzazione e loro utilizzo;

 progetto del sistema dei server disponibile e tollerante ai guasti.

Per quello che riguarda l'architettura del sistema lato server, è rappresentata nella figura di seguito.
Tale architettura prevede l'utilizzo del server Web Apache per il provisioning di contenuti statici e
per il reindirizzamento, in modalità Load Balancing Reverse Proxy, delle richieste di contenuti
dinamici a più istanze di Ruby on Rails tramite interfaccia HTTP con la libreria Mongrel.

Architettura del sistema lato server

5.4. Realizzazione del progetto

La realizzazione dell'intero sistema di monitoraggio è in fase di produzione e di continuo sviluppo. La
fase di progettazione e di implementazione/test ha richiesto circa 3 anni impegnando un team di
sviluppo di 5 elementi.

Di seguito vengono elencate tutte le scelte progettuali adottate, per ogni componente
dell'applicazione, specificandone i dettagli tecnici.

 Modalità di autenticazione: l'autenticazione degli utenti viene controllata attraverso il plugin

restful_authentication (http://agilewebdevelopment.com/plugins/restful_authentication).
Questo plugin, che permette di gestire gli utenti come risorse del sistema, contiene tutti i
metodi necessari per il controllo delle sessioni.
14 Ruby On Rails

 Modalità di autorizzazione per l'accesso ai dati e le operazioni degli utenti: in base ai requisiti
progettuali, la scelta sulla modalità di autorizzazione è caduta sul metodo RBAC (Role-Based
Access Control), e in particolare sul plugin per Rails ACL System2. RBAC consente di
controllare le autorizzazioni mediante la definizione di ruoli che possono effettuare
operazioni specifiche e l'assegnazione di tali ruoli (uno o più) agli utenti del sistema. I ruoli
che sono stati identificati sono i seguenti: ADMIN (può eseguire qualsiasi operazione),
END_USER (lettura dei dati commerciali), TECHNICIAN (lettura dei dati tecnici) e
AFTER_SALES (lettura dati tecnici, connessione macchine).
 Database e interfacce differenziate: ogni macro-area del sistema ha un proprio database e
una propria interfaccia utente. Tale suddivisione è stata pensata in modo da garantire la
sicurezza dei dati memorizzati e prevenire eventuali visualizzazioni accidentali di dati
sensibili da parte della concorrenza (numero di macchine installate, prodotto venduto, ecc.).
La struttura dei database sarà comune a tutti.
Questa modalità di implementazione comporta una divisione per gli utilizzatori che si
devono occupare di più di una macro-area. Ad esempio, un tecnico che si occupa di
macchine di clienti diversi (e concorrenti), non potrà vedere contemporaneamente tutte le
macchine ma dovrà effettuare un login differente a seconda di ciò che vuole visualizzare.
 Tipologia delle tabelle dei database: dal momento che le transazioni non sono necessarie in
questo sistema, le tabelle che comporranno i database sono di tipo myIsam che, tra le altre
cose, sono quelle che vengono create di default da Ruby on Rails.
 Progetto realizzato 15

5.5. Realizzazione pratica

Il sistema è attualmente in produzione ed è possibile accedere all’applicazione solo se si è utenti
registrati. Di seguito vengono mostrati alcuni screenshot dell’applicazione che mostrano,
rispettivamente: la homepage, una delle pagine di reportistica e una pagina di dettaglio di una
macchina.
16 Ruby On Rails

6. Licensing e costi
Tutte le tecnologie utilizzate in questo progetto sono Open Source e quindi il costo di licensing è pari
a zero. Inoltre l’aver scelto tecnologie innovative Open Source che proteggano nel futuro gli
investimenti eseguiti e non richiedono quindi di legarsi a vendor di software proprietari. Le
tecnologie scelte sono già mature (e molto ben supportate) per un impiego industriale. I costi
dunque sono legati alla formazione del personale tecnico per l’utilizzo delle applicazioni e per la,
eventuale, formazione degli sviluppatori alla programmazione in Ruby On Rails.
 Posizione di mercato e hype 17

7. Posizione di mercato e hype

Una ricerca su alcuni siti specializzati nella ricerca di lavoro (come ad esempio
http://www.odesk.com/trends/) mostrano come Rails risulta essere presente nei requisiti richiesti
per un lavoro di web-developer molto più spesso di tecnologie come Perl con un rapporto di 2:1,
mentre altre tecnologie come .NET/PHP/J2EE si presentano più spesso di Ruby con un rapporto di
circa 2:1, 15:1 e 4:1 rispettivamente.

Questo è dovuto al fatto che Rispetto a Java/J2EE/PHP, Rails è una tecnologia abbastanza giovane
quando si tratta di ottenere l'accettazione del mercato sebbene RoR sia tecnologicamente avanzata
pur avendo una curva di apprendimento molto rapida.
18 Ruby On Rails

8. Prospettive future
Il framework Ruby On Rails è stato rilasciato al pubblico nel luglio 2004 e ha iniziato subito ad avere i
primi contributi concreti dalla comunità per il proprio sviluppo. La prima release stabile 1.0 è stata
rilasciata nel dicembre 2005. Due anni più tardi vide la luce Rails 2.x che portava grandi novità quali:
output HTML e XML di default, migliore integrazione per la creazione di servizi web ReST, gestione
time zones, integrazione del framework con le gem dependencies per i plugin, i18n, HTTP valida
tors, miglioramento del caching e della sicurezza dei thread e soprattutto tanta documentazione.

E’ in fase di beta la versione 3.0 di Rails che permette di migliorare la robustezza e la scalabilità delle
applicazioni e di portare la programmazione web-oriented con Ruby su un nuovo livello di standard.

Attualmente il core di sviluppo è di 8 membri (fonte: http://rubyonrails.org/core) mentre si contano

oltre 1400 membri attivi della comunità

9. Diffusione
Molte società multinazionali hanno già scelto Ruby On Rails per le loro applicazioni web, ad esempio:

 Twitter
 YellowPages
 Hulu
 Justin TV
 Scribd.com
 GitHub
 E molte alter disponibili all’indirizzo rubyonrails.org/applications
 Conclusioni 19

10. Conclusioni
Ruby on Rails risulta essere quindi un framework molto versatile e potente. Nelle sue ultime
implementazioni cerca di favorirne la definizione e il corretto utilizzo delle moderne tecnologie web.
Rails infine facilita agli sviluppatori l’integrazione di funzioni quali Ajax e interfacce RESTful nel
proprio codice in quanto il supporto a queste è nativo dal framework stesso. Inoltre la curva di
apprendimento, da parte degli sviluppatori è molto rapida: ciò permette di realizzare anche
complesse applicazioni web in un tempo relativamente ridotto.

Sebbene molte delle più grandi società multinazionali hanno effettuato numerosi investimenti e i
relativi servizi sono interamente basati su RoR (come Twitter), il mercato è ancora scettico su questa
tecnologia ritenendola ancora troppo giovane e immatura anche se Gartner Group lo indica come
tecnologia di riferimento della nuova generazione di applicazioni web.