Approfondimento Ruby On Rails

Transcript

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. 2. Introduzione .................................................................................................................................... 3 Caratteristiche................................................................................................................................. 5 2.1. Il paradigma MVC .................................................................................................................... 5 Controller ........................................................................................................................ 5 View................................................................................................................................. 6 Model .............................................................................................................................. 6 2.1.1. 2.1.2. 2.1.3. 2.2. Routing delle richieste ............................................................................................................ 6 ReST................................................................................................................................. 7 2.2.1. 2.3. 3. Rappresentazioni dei dati in RoR ............................................................................................ 8 Tools ................................................................................................................................................ 9 3.1. 3.2. Programmare in Rails .............................................................................................................. 9 Testing e Debugging in Rails................................................................................................... 9 4. 5. Documentazione ............................................................................................................................. 9 Progetto realizzato ........................................................................................................................ 10 5.1. Definizione dei requisiti di progetto ..................................................................................... 10 Definizione degli applicativi che dovranno essere realizzati ........................................ 10 Definizione dei requisiti funzionali................................................................................ 11 Definizione dei requisiti non funzionali ........................................................................ 11 5.1.1. 5.1.2. 5.1.3. 5.2. 5.3. 5.4. 5.5. 6. 7. 8. 9. 10. Definizione dei vincoli progettuali e architetturali del sistema ............................................ 12 Progettazione del sistema di teleoperazioni ........................................................................ 12 Realizzazione del progetto .................................................................................................... 13 Realizzazione pratica ............................................................................................................. 15 Licensing e costi ............................................................................................................................ 16 Posizione di mercato e hype ......................................................................................................... 17 Prospettive future ......................................................................................................................... 18 Diffusione ...................................................................................................................................... 18 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. 2. 3. 4. Il browser invia la richiesta (URL) di una risorsa Il Controller interagisce con il Model (e questo con la base di dati) Il Controller invoca la View 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.