Websocket Notifier

Università degli Studi di Padova

Dipartimento di Matematica

Corso di Laurea in Informatica

WebSocket Notiﬁer: una RubyGem basata su WebSocket

Tesi di laurea triennale

Relatore Prof. Tullio Vardanega

Laureando Federico Gobbo

Anno Accademico 2015–2016 Federico Gobbo: WebSocket Notiﬁer: una RubyGem basata su WebSocket, Tesi di laurea triennale, c Oct 2016. Sommario

Il presente documento rappresenta la relazione ﬁnale dell’esperienza di stage condotta nell’azienda Si14 Spa. Esso è organizzato in quattro capitoli:

1. Descrizione dell’azienda: le origini, la natura, il mercato, i processi aziendali;

2. Le motivazioni alla base dell’esperienza di stage: i punti di vista dei portatori di interesse, ovvero l’azienda, l’università e il sottoscritto;

3. Presentazione del progetto di stage: processi e prodotti;

4. Valutazione retrospettiva sull’esperienza di stage.

Convenzioni tipograﬁche

Nel testo vengono utilizzate delle convenzioni tipograﬁche col seguente signiﬁcato:

• Corsivo: termine in lingua inglese;

• Grassetto: termine rilevante;

• Verbatim: nomi di ﬁle, codice;

• Glossario|g|: termine presente nel glossario;

• Riferimento1: termine associato a un riferimento bibliograﬁco.

iii

“Make the best of the situation” — Eric Clapton

Ringraziamenti

Vorrei ringraziare il Prof. Tullio Vardanega, relatore della mia tesi, per l’aiuto, i buoni consigli e la disponibilità che ha dimostrato nei miei confronti.

Ringrazio la mia famiglia, la mia ragazza e i miei amici per avermi permesso, col loro sostegno, di raggiungere questo traguardo.

Padova, Oct 2016 Federico Gobbo

Indice

1 L’azienda: Si141 1.1 Storia ...... 1 1.2 Contesto aziendale ...... 1 1.2.1 I vantaggi dell’ecosistema M31 ...... 2 1.2.2 Tecnologia e innovazione ...... 2 1.2.3 Spin-oﬀ aziendali ...... 2 1.3 Struttura interna ...... 3 1.3.1 I reparti ...... 3 1.3.2 Coordinamento e comunicazione ...... 4 1.4 Processi aziendali ...... 5 1.4.1 Acquisizione e fornitura ...... 5 1.4.2 Gestione ...... 5 1.4.3 Sviluppo ...... 6

2 Le motivazioni 11 2.1 L’interesse dell’azienda ...... 11 2.1.1 Gli stage nella strategia aziendale ...... 11 2.1.2 Il progetto assegnato ...... 12 2.1.3 Valutazioni sulla tipologia di progetto ...... 13 2.2 La scelta personale ...... 13 2.2.1 L’azienda ...... 13 2.2.2 Il progetto ...... 13 2.3 Il ﬁne dell’università ...... 14

3 Il progetto: WebSocket Notiﬁer 15 3.1 Lo scopo ...... 15 3.2 Il dominio ...... 15 3.2.1 Applicazioni web e servizi cloud ...... 15 3.2.2 Le tecnologie utilizzate ...... 16 3.3 Le due fasi ...... 18 3.3.1 Fase 1: studio delle tecnologie ...... 18 3.3.2 Fase 2: sviluppo del modulo WebSocket ...... 22 3.4 Creazione della RubyGem ...... 23

vii viii INDICE

3.4.1 Presentazione delle speciﬁche ...... 23 3.4.2 Pianiﬁcazione ...... 23 3.4.3 Analisi dei requisiti ...... 26 3.4.4 Progettazione ...... 27 3.4.5 Sviluppo ...... 29 3.4.6 Documentazione ...... 32 3.4.7 Testing ...... 34 3.4.8 Validazione ...... 34

4 Valutazione retrospettiva 37 4.1 Bilancio dei risultati ...... 37 4.1.1 Diﬃcoltà incontrate ...... 37 4.2 Bilancio formativo ...... 38 4.2.1 Conoscenze ...... 38 4.2.2 Abilità ...... 39 4.2.3 Competenze ...... 39 4.3 Il gap formativo ...... 39

Glossario 41

Acronimi 45

Bibliograﬁa 47 Elenco delle ﬁgure

1.1 Logo dell’azienda Si14 e dell’incubatore M31 ...... 1 1.2 Organigramma aziendale di Si14 ...... 4 1.3 Ciclo di iterazione della metodologia Agile ...... 6 1.4 Workﬂow GitFlow ...... 8 3.1 Diagramma di Gantt per la Pianiﬁcazione ...... 25 3.2 Prima architettura della RubyGem ...... 33

Elenco delle tabelle

3.1 File e cartelle principali di una applicazione Ruby on Rails ...... 19 3.2 Requisiti obbligatori ...... 26 3.3 Requisiti desiderabili ...... 27 3.4 Requisiti opzionali ...... 27 3.5 Soddisfacimento dei requisiti obbligatori ...... 36 3.6 Soddisfacimento dei requisiti desiderabili ...... 36 3.7 Soddisfacimento dei requisiti opzionali ...... 36

Elenco dei codici

3.1 Esempio di migration ...... 20 3.2 File config.ru per web server Faye ...... 29 3.3 Invio messaggi dal Server ...... 30 3.4 Uso del metodo dispatch con le callback di ActiveRecord ...... 30

ix x ELENCO DEI CODICI

3.5 Iscrizione a un canale ...... 31 3.6 LoggerExtension ...... 32 Capitolo 1

L’azienda: Si14

1.1 Storia

Si14 nasce nel 2008 dall’incubatore M31, acceleratore di imprese del territorio veneto. L’azienda ha le sue radici in ambiente universitario: da un professore e un gruppo di studenti di ingegneria ha avuto origine quella che sarebbe stata la prima forma di Si14: un’azienda di ingegneri che progettava e realizzava schede elettroniche per conto di aziende terze.

Figura 1.1: Logo dell’azienda Si14 e dell’incubatore M31

Con il tempo Si14 è cresciuta ad abbracciare un universo tecnologico più ampio, andando ad allargare il suo organico ed espandendo le sue competenze. Sono nati così nuovi reparti dedicati all’hardware, al ﬁrmware e al software che collaborando rendono possibile la creazione di prodotti completi.

1.2 Contesto aziendale

Questa è la forma attuale di Si14: un’azienda ad alto contenuto tecnologico ed innovativo, che partendo da una business idea fornisce soluzioni complete sotto forma di prodotti e servizi. Se M31 è deﬁnito acceleratore di impresa, Si14 può essere deﬁnita acceleratore di prodotto: mantenendo al suo interno tutte le competenze necessarie essa può infatti ridurre il tempo per arrivare a commercializzare un prodotto, ovvero il cosiddetto time to market. Quest’ultimo è un parametro essenziale in un mercato dominato non da chi ha l’idea migliore, ma da chi raggiunge un’ottima realizzazione grazie ad un inserimento precoce nel mercato stesso. A questo scopo si punta alla

1 2 CAPITOLO 1. L’AZIENDA: Si14

produzione di un MVP|g| (Minimum Viable Product) che consenta di raccogliere quanto prima feedback dagli utenti ﬁnali. Gli ambiti di applicazione sono i più disparati: dal biomedicale, sportivo, industriale, ﬁno al militare. In otto anni di attività sono stati numerosi i progetti portati a termine, molti dei quali per aziende di rilevanza nazionale e internazionale. Di seguito ne sono elencati alcuni:

• Luna Rossa: nel giugno del 2014 Si14 è stata Fornitore Uﬃciale del team Luna Rossa per la Coppa America, progettando e realizzando un anemometro, fornendo smartwatch Wearit per il monitoraggio delle performance e un’infrastruttura per la sincronizzazione e la fruizione delle riprese GoPro.

• Sirio Panel (Gruppo Finmeccanica): Si14 ha realizzato un hard disk da elicotteri utilizzabile in ambito civile e militare, un Network Area Storage in grado di memorizzare informazioni sensibili e renderle disponibili agli altri apparati di bordo. Per Sirio Panel Si14 ha inoltre realizzato un tablet da coscia per utilizzo in ambito militare e un sistema ILS (Instrumental Landing System) per l’atterraggio strumentale automatico di un aeromobile.

• Manfrotto: Si14 ha realizzato Digital Director, la prima stazione di regia per iPad nel mondo della fotograﬁa, in grado di controllare da remoto l’intera attrezzatura fotograﬁca.

1.2.1 I vantaggi dell’ecosistema M31

L’incubatore M31 non ha solo lo scopo di investire sulle aziende emergenti. Esso crea un ecosistema di aziende che possono sfruttare l’una le conoscenze e i servizi dell’altra. Lo stesso M31 si occupa di fornire personale o interi reparti per le aziende in formazione, in modo tale che possano concentrarsi completamente sugli aspetti core e raggiungere più velocemente uno stadio maturo.

1.2.2 Tecnologia e innovazione

Per la natura dell’azienda l’innovazione è una componente essenziale: ricercarla mantenendo al contempo standard di qualità elevati è l’unico modo per essere competitivi sul mercato. Si14 trova nell’innovazione lo spirito che la contraddistingue, lo stesso che la spinge ad accettare sempre nuove sﬁde: questo per certi aspetti espone l’azienda a rischi non indiﬀerenti, soprattuto quando il prodotto non è commissionato da altre aziende. Si14 mette quindi in atto tutte le misure precauzionali necessarie nell’analisi e nella gestione dei rischi.

1.2.3 Spin-oﬀ aziendali

Non solo l’azienda accetta e porta a compimento sﬁde tecnologiche e di innovazione nei prodotti che realizza: in alcuni casi questi conducono alla nascita di vere e proprie 1.3. STRUTTURA INTERNA 3 aziende spin-oﬀ, nate a partire da singoli progetti e che diventano per certi aspetti realtà indipendenti. Questo è il caso delle aziende D·Eye e Wearit.

D·Eye

D·Eye nasce nel 2014 grazie all’idea dell’oftalmologo Andrea Russo, che ha saputo vedere nei moderni smartphone uno strumento suﬃcientemente potente e al tempo stesso versatile, per andare ad imitare e in alcuni casi sosituire il classico oftalmoscopio. D·Eye ha infatti sviluppato un dispositivo ottico in grado di eﬀettuare esami della retina sfruttando la telecamera e il sistema di illuminazione di cui ogni smartphone è dotato.

Wearit

Wearit ha dato origine al primo “action watch” in grado di rilevare dati corporei qualitativi, oltre che quantitativi. Wearit rappresenta un sistema per tracciare, registrare ed analizzare ogni tipo di attività sportiva, fornendo un’unica metrica basata sull’aggregazione e l’analisi dei dati provenienti dai sensori dello smartwatch.

1.3 Struttura interna

Come detto, la grande forza di Si14 sta nel poter contare su tutte le competenze di cui necessita direttamente al suo interno. L’organizzazione della azienda rispecchia questa specializzazione dividendo l’organico in reparti e team.

1.3.1 I reparti

Di seguito elenco i reparti aziendali dei quali sono venuto a conoscenza durante l’esperienza di stage. Nella ﬁgura ?? è illustrato l’intero organigramma aziendale.

Ricerca e sviluppo

Il reparto di ricerca e sviluppo è il cuore di Si14, dove i team di sviluppo collaborano nel progettare e realizzare soluzioni innovative.

• Hardware: il team dedicato all’hardware si occupa di progettare le schede elettroniche e in generale la parte ﬁsica di un nuovo prodotto;

• Firmware: le schede elettroniche di per sé non possono comunicare né essere sfruttate dal software: il team dedicato al ﬁrmware si occupa quindi di realizzare codice a basso livello che permetta di interpretare i segnali elettrici e fornire un’interfaccia al livello superiore;

• Software: il team sviluppa il modello dei dati, la business logic, le interfacce graﬁche che si integrano, sfruttano e governano il prodotto stesso. 4 CAPITOLO 1. L’AZIENDA: Si14

CEO Admin & Governance & Finance Legal Deputy CEO

Quality Innovation Business Product mngmn Development Strategic Mkt

Sales Operations HR & HQ Services

R&D Supply Chain

BL BL BL BL Product Engineering Platform Design Logistics Procurement Production

Project MNGMN Software Hardware Firmware Industrial Design

Figura 1.2: Organigramma aziendale di Si14

• Web Development: il team di Web Development gestisce la sezione riguar-

dante i servizi cloud: crea l’interfaccia di utilizzo, la logica lato server e le API|g| REST|g| per la comunicazione con il software integrato e con le applicazioni mobile. Questo è il team in cui ho lavorato durante lo stage;

• Mobile: il team sviluppa applicazioni mobile per sistemi Android e IOs che si interfacciano con i servizi cloud.

Produzione

Il reparto di produzione si occupa della vera propria realizzazione ed assemblaggio del prodotto, attraverso la creazione dei prototipi necessari. Raggiunto lo stadio ﬁnale del prodotto, questo viene fatto produrre su larga scala da aziende terze in tutto il mondo.

1.3.2 Coordinamento e comunicazione I reparti comunicano principalmente via e-mail; per comunicazioni informali è utilizzato il software Skype. Il punto di riferimento per prendere le decisioni e organizzare le attività è il responsabile di reparto. Nel caso del reparto di Ricerca e Sviluppo vi sono anche i Team Leader, che hanno la funzione di coordinamento delle attività speciﬁche. Frequenti sono le riunioni al ﬁne di facilitare il coordinamento tra i reparti. 1.4. PROCESSI AZIENDALI 5

1.4 Processi aziendali

1.4.1 Acquisizione e fornitura

Per quanto riguarda la fornitura di un nuovo progetto solitamente il primo input viene dato dal reparto commerciale. I commerciali si occupano di trovare nuovi clienti o individuare bandi di interesse. Una volta individuata la possibilità di un nuovo incarico, entra in gioco la figura del Key Account, che risulta essenziale per avviare e gestire la trattativa con il potenziale cliente. I Key Account, affiancati dal Project Manager preparano un piano di lavoro con relativo preventivo nel caso si tratti di una commessa, o realizzano una demo per il bando in questione. In caso il piano o la demo vengano accettati e quindi sia attribuito l’incarico, il piano viene inoltrato ai reparti di sviluppo, a cui è richiesto di pianificare il lavoro in dettaglio. Vengono fissate le milestone, gestiti i requisiti, avviata la progettazione e quindi lo sviluppo.

1.4.2 Gestione

Gestione di progetto

La gestione di progetto è eﬀettuata grazie al software Redmine. Esso mette a disposizione un’intera suite di strumenti per far fronte alle attività di gestione di progetto, di cui elenco le principali:

• Pianificazione: Redmine integra uno strumento per la creazione di diagrammi di Gantt; esso permette di allocare attività su giorni di calendario, indicarne le interdipendenze e quindi identificare le possibilità di sviluppo parallelo, confrontare le stime con i tempi effettivi;

• Gestione delle risorse: il Resource Manager è uno strumento che permette l’assegnazione delle attività a persone o team e il bilanciamento del carico di lavoro degli stessi. Esso consente di determinare il carico persona giornaliero, settimanale, mensile;

• Definizione degli obiettivi: il Project Planner consente di definire e fissare a calendario le milestone corrispondenti al raggiungimento di determinati obiettivi.

Gestionale aziendale

Oltre alla gestione di progetto, l’azienda ha sviluppato internamente il software gestionale, attribuendogli il nome di Bytes. Esso consente di eﬀettuare la gestione delle risorse umane (e quindi la disponibilità a calendario) e il rendiconto delle ore di lavoro a progetto. Ogni persona dovrebbe infatti rispettare il monte ore pianiﬁcato a progetto, dunque le attività svolte devono essere segnalate per il rendiconto. 6 CAPITOLO 1. L’AZIENDA: Si14

1.4.3 Sviluppo L’azienda adotta un modello Agile per quanto riguarda il ciclo di vita del prodotto. Per la natura dell’azienda e per la forte componente innovativa e in alcuni casi sperimentale dei progetti, la metodologia Agile si adatta meglio rispetto a modelli più rigidi e meno versatili: essa prevede infatti di iterare numerose volte (in modo incrementale e talvolta distruttivo) durante il ciclo di vita del software. Vengono così ripetute analisi dei requisiti, pianiﬁcazione, progettazione e sviluppo, il tutto con la collaborazione del cliente stesso. Lo scopo è infatti ﬁnalizzare il lavoro verso uno stretto rapporto con il cliente, fornendo quanto prima un prodotto che rispetti le aspettative. Questo aiuta quindi da un lato a velocizzare il rilascio del prodotto, dall’altro a ridurre il rischio di fallimento. La metodologia Agile è basata su un Manifesto1, che ne descrive i principi fondamentali nei seguenti punti:

• “Gli individui e le interazioni più che i processi e gli strumenti”;

• “Il software funzionante più che la documentazione esaustiva”;

• “La collaborazione col cliente più che la negoziazione dei contratti”;

• “Rispondere al cambiamento più che seguire un piano”.

Agile Methodology

t Build t Build t Build es es es T T T D D D e e e w s w s w s ig ig ig ie ie ie n n n v v v

e e e

R R R

P P

Sprint 1 Sprint 2 Sprint 3 P

l l l

a a a

n n n

Launch Launch Launch

Figura 1.3: Ciclo di iterazione della metodologia Agile

Durante la mia esperienza non ho avuto modo di approfondire le esatte procedure interne all’azienda per l’attuazione della metodologia, in quanto ho lavorato in autonomia la maggior parte del tempo. Agile.

Ambiente di sviluppo

Per lo sviluppo il reparto software fa aﬃdamento all’IDE Sublime Text 3: esso ha il vantaggio di essere molto performante e al tempo stesso versatile, rispetto ad

1Manifesto Agile. url: http://agilemanifesto.org/iso/it/. 1.4. PROCESSI AZIENDALI 7 altri ambienti più specializzati. Una delle caratteristiche più interessanti è infatti la presenza di un Package Manager, un componente che permette di aggiungere nuove funzionalità oﬀerte da una vastissima scelta di package. L’azienda fa largo uso di questi pacchetti per personalizzare l’ambiente di sviluppo e renderlo consono alle esigenze. Il reparto di Web Development sfrutta Sublime Text 3 per sviluppare codice nei seguenti (ed altri) linguaggi: • Ruby on Rails;

• HTML;

• CSS|g|; • JavaScript;

• TypeScript. Tutto questo in un unico ambiente: al sorgere dell’esigenza di utilizzo di un nuovo linguaggio è possibile installare il pacchetto corrispondente per sfruttare funzionalità ad esempio di syntax highlighting, autocompletamento, analisi statica o anche di building. Altri pacchetti permettono l’integrazione del sistema di versionamento, l’inserimento di snippet di codice per speciﬁci linguaggi o la gestione della documentazione.

Versionamento

I team di sviluppo software e firmware fanno affidamento sul software Git per quanto riguarda il controllo di versione. Il workflow utilizzato si avvicina per molti aspetti al workflow GitFlow, ed è così definito:

• Il repository è gestito su branch multipli, di cui il principale è il master e contiene tutte le release del prodotto software;

• Il branch di sviluppo è denominato development: qui è presente l’ultima versione in sviluppo e quindi non ancora rilasciata. È buona prassi non creare nuove commit direttamente su questo branch;

• Il vero sviluppo avviene nei branch feature, ovvero quelli dedicati alla realizzazione di nuove funzionalità. Avendo branch separati, le funzionalità sono indipendenti tra loro ﬁno al loro completamento (o alla loro fusione). Una volta completata, la funzionalità viene unita al codice presente nel branch development (previa gestione di eventuali conﬂitti);

• Raggiunto nel development un livello di sviluppo signiﬁcativo ed eﬀettuati tutti i test necessari, viene creata una nuova release nel master alla quale viene attribuito un tag associato al nuovo numero di versione.

• In caso vengano riscontrati dei bug nella versione appena rilasciata, essi vengono corretti in un branch hotfix dedicato allo scopo. 8 CAPITOLO 1. L’AZIENDA: Si14

Figura 1.4: Workﬂow GitFlow

Il numero di versione è così deﬁnito:

X.Y.Z

• X: deﬁnisce un major update, ovvero una modiﬁca di grande rilevanza, potenzialmente non retrocompatibile;

• Y: modiﬁca o aggiunta di funzionalità minori;

• Z: hotﬁx, buﬁx.

Per quanto riguarda l’hosting e la gestione centrale del repository l’azienda utilizza il software GitLab, ospitato su server propri. GitLab ha il vantaggio di essere un software gratuito, al contrario ad esempio di GitHub e Bitbucket, che oﬀrono piani gratuiti non consoni ad un uso aziendale.

Documentazione

Lo sviluppo del codice prevede come prassi la stesura di documentazione sia a livello di commenti, sia come documentazione esterna. Per progetti in ambito medicale è inoltre necessario sottostare alle procedure dello standard HIPAA|g|. In questi casi, per ogni versione rilasciata, viene stilato un documento contenente i risultati di tutti gli unit test e functional test eseguiti, insieme 1.4. PROCESSI AZIENDALI 9 alle app speciﬁcation. È inoltre redatto per modiﬁche incrementali il documento denominato “Software Lifecycle: architecture and validation”

Capitolo 2

Le motivazioni

2.1 L’interesse dell’azienda

Come detto nel Capitolo 1, Si14 trova le sue origini nell’ambiente universitario. L’azienda, così come l’incubatore M31, ha mantenuto questo legame nel tempo e questo ne ha segnato la sua evoluzione e le sue scelte strategiche. Si14 e M31 fanno aﬃdamento sulla ricerca e sono coscienti del fatto che l’università è una risorsa dal valore inestimabile, che continua a produrre nuova conoscenza e scoperte scientiﬁche di grandissima portata. Per questo motivo accoglie studenti e neolaureati per esperienze di stage, nella convinzione che i giovani universitari possano fornire una visione nuova e un apporto considerevole.

2.1.1 Gli stage nella strategia aziendale

In ambito più generale, gli stage sono uno strumento molto utile per l’azienda: essi permettono la valutazione dei canditati nell’ottica di un graduale inserimento all’interno dell’organico. Questa fase solitamente si accompagna alla formazione dello stagista al fine di renderlo partecipe dei processi aziendali e delle tecnologie e degli strumenti utilizzati, in modo tale che al termine dello stesso possa dimostrarsi quanto più autonomo. È altrettanto vero che in un’azienda così dinamica possono verificarsi periodi lavorativi decisamente intensi, durante i quali questo tipo di formazione diventa difficile, se non impossibile da erogare. La mia esperienza si è collocata mio malgrado in uno di questi periodi. Importante è anche l’integrazione a livello sociale: per essere produttivi è fondamentale sentirsi in sintonia con i colleghi e saper prendere parte ad un team. La collaborazione è essenziale in un’azienda come Si14, dove il lavoro del singolo non può che essere inserito in un contesto molto più ampio: i progetti raggiungono dimensioni decisamente importanti e le competenze in gioco sono largamente eterogenee. Un ulteriore vantaggio per l’azienda è rappresentato dall’opportunità di affidare progetti concreti e di effettiva utilità allo stagista. Sebbene sia scarsa la probabilità

11 12 CAPITOLO 2. LE MOTIVAZIONI che il lavoro sia direttamente utilizzabile al termine dell’esperienza, l’azienda potrà avere una base di partenza e un punto di vista potenzialmente alternativo.

2.1.2 Il progetto assegnato

Il progetto di stage si è collocato nell’ambito delle funzionalità offerte dai servizi cloud e dunque di interesse diretto del team di Web Development. Il Piano di Lavoro è stato redatto e fornitomi dall’azienda, dunque non vi è stata collaborazione nella decisione del tema del progetto, né nella definizione degli obiettivi in termini di risultati e tempistiche. L’argomento principale del progetto è stata l’implementazione di un sistema di comunicazione client-server basato sul protocollo WebSocket da utilizzare all’interno di applicazioni web scritte in Ruby on Rails. Queste e le altre tecnologie utilizzate sono descritte in dettaglio in§3.2.2“Le tecnologie utilizzate”. Di seguito elenco obiettivi e vincoli fissati nel Piano di Lavoro.

Obiettivi

Il documento Piano di Lavoro deﬁnisce un obiettivo minimo e un obiettivo massimo per il progetto di stage. Quest’ultimo è stato dunque strutturato a prevedere due fasi che terminassero rispettivamente al raggiungimento dell’obiettivo minimo e dell’obiettivo massimo.

Obiettivo minimo Studio delle tecnologie da utilizzare con creazione di un report ﬁnale che le descriva. Le tecnologie in esame sono:

• framework di programmazione Ruby on Rails e basi di linguaggio Ruby;

• framework BDD|g| (Behaviour Driven Development) RSpec;

• linguaggi JavaScript e TypeScript;

• WebSocket.

Come spiego più in dettaglio in§3“Il progetto: WebSocket Notiﬁer”, le tecnologie studiate e utilizzate sono state in numero maggiore rispetto a quelle elencate nel Piano di Lavoro e nello studio delle stesse ho creato delle applicazioni per mettere in pratica le conoscenze acquisite.

Obiettivo massimo L’obiettivo massimo prevedeva la creazione di un’infrastruttura di comunicazione tra back-end e front-end utilizzando la tecnologia WebSocket. Per i dettagli sulla natura dell’infrastruttura realizzata vedere§3.4“Creazione della RubyGem”. 2.2. LA SCELTA PERSONALE 13

Vincoli

I vincoli imposti dal Piano di Lavoro riguardavano le tecnologie e la sequenzialità delle due fasi. La fase di studio delle tecnologie era propedeutica alla creazione del- l’infrastruttura di comunicazione, dunque l’obiettivo minimo doveva essere raggiunto per soddisfare l’obiettivo massimo.

2.1.3 Valutazioni sulla tipologia di progetto

Una caratteristica essenziale del progetto proposto e affrontato è che non è stato un progetto “didattico”: vi era una effettiva esigenza da parte dell’azienda di realizzare un modulo di comunicazione basato su WebSocket. Non solo, questo modulo doveva essere quanto più configurabile e indipendente dal contesto di utilizzo, in modo tale che potesse essere sfruttato in una qualsiasi applicazione già in sviluppo. Doveva essere quindi realizzata una libreria (nello specifico, una RubyGem, come spiegherò più avanti) che massimizzasse la possibilità di riuso sistematico. La natura pratica di questo progetto mi ha permesso di affrontare problematiche differenti rispetto a un progetto didattico, più vicine a quelle che si affrontano ogni giorno all’interno dell’azienda. Questo mi ha quindi permesso di misurare la mia capacità di gestire il tempo, soprattutto quando le difficoltà rallentavano il progresso rispetto a quanto pianificato.

2.2 La scelta personale

2.2.1 L’azienda

Il percorso che mi ha portato a scegliere questa azienda non è stato breve: sono stati numerosi i colloqui eﬀettuati prima di giungere in Si14. Le motivazioni che mi hanno portato a questa scelta sono numerose ed eterogenee. Di seguito ne elenco alcune:

• La tipologia di azienda, così volta all’innovazione e i progetti quasi futuristici, mi hanno aﬀascinato. Durante il colloquio, è stato molto stimolante ascoltare la descrizione di come prende vita un nuovo prodotto a partire da un’idea ﬁno alla produzione su larga scala, attraverso il lavoro congiunto di tutti i team;

• La vicinanza dell’azienda al luogo in cui vivo e studio è stata sicuramente il fattore meno signiﬁcativo, ma pur sempre da considerare. Nel confronto con altre aziende di interesse più diﬃcili da raggiungere, questo è stato uno dei motivi di scelta.

2.2.2 Il progetto

Riprendendo l’elenco presentando le motivazioni legate nello speciﬁco al progetto:

• Il team al quale sono stato assegnato, ovvero quello di Web Development, è stato un ulteriore motivo di scelta: al momento del colloquio avevo da circa 14 CAPITOLO 2. LE MOTIVAZIONI

un anno aﬀermato il mio interesse personale per lo sviluppo web, studiando alcune tecnologie utili. Da parte mia vi è stato grande entusiasmo all’idea di collaborare a un progetto web in una realtà strutturata, sebbene poi mi sia trovato a lavorare singolarmente per la maggior parte del tempo.

• Apparentemente in contrasto con il punto precedente, un altro motivo a favore è stato il vincolo di utilizzo di tecnologie sconosciute, come ad esempio Ruby on Rails. Avere l’opportunità di apprendere nuove conoscenze in un ambito di mio interesse è stato stimolante. Inoltre sarebbe stato più diﬃcile per me aﬀrontare argomenti come WebSocket per sola scelta personale.

2.3 Il ﬁne dell’università

Il terzo portatore di interesse per l’istituzione degli stage curriculari è inﬁne l’u- niversità. L’Università degli Studi di Padova organizza eventi come StageIt per facilitare l’incontro con le aziende, in modo che gli studenti possano, come primo passo, giungere a concordare l’attività di stage. I vantaggi per lo studente sono piuttosto evidenti:

• Avere un “canale privilegiato” (rispetto ai metodi classici) per l’inserimento nelle aziende;

• Poter apprendere e sperimentare la vita aziendale, conoscendo i processi, le prassi e approfondendo il rapporto con i colleghi;

• Avere una maggiore possibilità di essere assunti al termine dell’esperienza, usufruendo in molti casi della formazione erogata.

È proprio per questo motivo che il Corso di Laurea in Informatica prevede che lo stage sia obbligatorio e che si collochi al termine del corso di studi: questo permette allo stage di non un’esperienza fine a se stessa ma l’inizio di una proficua collaborazione. Questo è quanto l’università può offrire ai suoi studenti, ma il valore degli stage si evidenzia anche in relazione alle informazioni che essa ne può ricavare. L’incontro tra aziende e studenti genera da un lato opportunità per entrambe le parti, dall’altro permette di conoscere il divario esistente tra le aspettative e la realtà effettiva. L’università lavora per ridurre questo gap e ogni esperienza di stage è utile in questo senso. Essa può infatti modellare il corso di studi cercando di andare a colmare le lacune che emergono. Le considerazioni sul gap sono riprese in§4.3“Il gap formativo”. Capitolo 3

Il progetto: WebSocket Notiﬁer

3.1 Lo scopo

Come detto precedentemente, il progetto di stage nasce dall’esigenza dell’azienda di integrare un modulo di comunicazione real-time nei servizi cloud in sviluppo. Nel contesto di un’architettura di tipo client-server, uno degli utilizzi principali del protocollo WebSocket è fornire al server la capacità di iniziare una nuova comunicazione con i client, dato che l’architettura di per sé non lo consente. In questo modo possono essere implementate le cosiddette notiﬁche push, inviate dal server contestualmente all’aggiornamento di dati, contrapposte alla richiesta (pull) di informazioni dai client.

3.2 Il dominio

Facendo un passo indietro, fornisco una descrizione del dominio applicativo.

3.2.1 Applicazioni web e servizi cloud

Le applicazioni web (web-app) sono software distribuiti basati sull’architettura client- server, accessibili attraverso la rete per mezzo di browser. Esse possono essere sviluppate con numerosi linguaggi e framework dedicati. Essendo basate sull’architettura client-server, l’applicazione si divide in due parti dedicate:

• Il front end rappresenta la parte client. Essa comprende la creazione dell’interfaccia utente e della gestione dell’interazione con l’utente stesso: i linguaggi utilizzati sono HTML per la struttura e i contenuti delle pagine web, CSS per la presentazione, ovvero l’aspetto, JavaScript per il comportamento.

• Il back end rappresenta la parte server: contiene il modello dei dati e la business logic.

Le due componenti devono essere in grado di scambiarsi informazioni, di comunicare. Questo avviene attraverso interfacce che permettono di sfruttare il protocollo

15 16 CAPITOLO 3. IL PROGETTO: WEBSOCKET NOTIFIER

HTTP|g| (HyperText Transfer Protocol). Esso si basa su un meccanismo di richiesta del client e risposta del server: esistono diversi metodi di richiesta, i due principali sono GET per la richiesta di lettura dati, e POST per una richiesta di scrittura dati (ad esempio conseguente alla compilazione di un form). Le applicazioni web possono essere sfruttate per qualsiasi utilizzo pratico e contesto. Si14 crea applicazioni web per oﬀrire servizi cloud legati ai prodotti sviluppati. Esempi possono essere un’interfaccia web per la gestione remota di un macchinario industriale o una dashboard contenente le informazioni legate ai progressi in ambito sportivo. È quindi questo il contesto generale in cui il team di Web Development ha riscontrato l’esigenza di inviare notiﬁche push in tempo reale.

3.2.2 Le tecnologie utilizzate Il framework Ruby on Rails

Come detto, lo sviluppo di applicazioni web può essere condotto con diversi framework e linguaggi. In Si14 il team di Web Development utilizza Ruby on Rails. Esso è un framework open source full-stack basato sul paradigma MVC|g| (Model View Controller). I principi base di Ruby on Rails sono:

• DRY (Don’t Repeat Yourself): prescrive di ridurre al minimo la ripetizione del codice, un antipattern con considerevoli eﬀetti negativi sulla manutenibilità e il riuso sistematico;

• Convention over Configuration: considera conveniente strutturare il framework in modo tale che sia minima la configurazione esplicita: le convenzioni di nomenclatura dei file e delle classi, della struttura di directory e altro, permettono di fornire al framework stesso le informazioni necessarie in modo implicito.

Il protocollo WebSocket

WebSocket è un protocollo (standard IETF|g| dal 2011) che fornisce un canale di comunicazione full-duplex attraverso una singola connessione TCP|g|. Si contrappone al protocollo HTTP che consente solo connessioni unidirezionali sui singoli socket: per creare una comunicazione bidirezionale sono necessari due canali. WebSocket presenta numerosi vantaggi, di seguito elencati:

• connessione full-duplex;

• riduzione dell’overhead dei pacchetti, riducendo le informazioni a contorno da dimensioni dell’ordine dei kilobyte a 2 byte;

• riduzione della latenza di comunicazione.

Il principale vantaggio di WebSocket è la possibilità da parte del server di iniziare la comunicazione con i client al momento del bisogno (solitamente al variare di un 3.2. IL DOMINIO 17 qualche valore osservato). Per simulare questo comportamento le alternative HTTP sono tendenzialmente tre:

• Polling: il client invia le richieste al server a intervalli regolari, ricevendo immediatamente una risposta ad ogni richiesta;

• Long polling: il client invia una richiesta al server, il quale la mantiene aperta per un determinato periodo; se una notiﬁca viene generata in quel periodo, viene inviata direttamente al client, altrimenti il server manda una risposta per concludere la richiesta attiva;

• Streaming: il client invia una richiesta completa, ma il server manda una risposta che viene mantenuta aperta per un tempo indeﬁnito. Quando una notiﬁca è generata la risposta viene aggiornata, ma il server non segnala completata la risposta, in modo tale da tenere la connessione aperta per altri messaggi.

Tutte queste soluzioni presentano degli svantaggi considerevoli:

• Nel caso del polling e long polling si ha un aumento del carico computazionale del server per la risposta a richieste multiple, il più delle volte senza eﬀettivo trasferimento di informazioni utili;

• Lo streaming può risultare in un aumento della latenza causata da proxy e ﬁrewall;

• In tutti i casi il problema nasce dal fatto che l’azione parte dal client, che non è a conoscenza del momento esatto in cui l’informazione cercata è reperibile.

WebSocket risolve questi problemi e consente di stabilire una comunicazione bidirezionale a bassa latenza e basso overhead, aperta a tempo indeﬁnito. Queste caratteristiche lo rendono utile per molti contesti. Alcuni di questi possono essere:

• Videogiochi: essi richiedono una comunicazione in tempo reale con latenza minima;

• Applicazioni di borsa: applicazioni che monitorano l’andamento delle quo- tazioni di borsa in tempo reale;

• Instant messaging: scambio di messaggi tra client in real-time.

Dire che WebSocket sia la soluzione giusta da adottare in tutte le occasioni non sarebbe giusto: vi sono ancora contesti e condizioni per le quali le tecniche sopra descritte sono suﬃcienti o anche preferibili. 18 CAPITOLO 3. IL PROGETTO: WEBSOCKET NOTIFIER

3.3 Le due fasi

Questa sezione indica come si sono svolte le due fasi del progetto, introdotte in§2.1.2 “Il progetto assegnato”, corrispondenti agli obiettivi minimo e massimo.

3.3.1 Fase 1: studio delle tecnologie La prima fase dello stage, con carico di lavoro pari a 180 ore stabilito dal Piano di Lavoro, è stata dedicata a fornire le basi di conoscenza necessarie per aﬀrontare la creazione del modulo di comunicazione real-time.

Struttura di una applicazione Ruby on Rails

La preparazione in questo senso ha avuto inizio con il framework Ruby on Rails. Nello specifico è stata affrontata la guida introduttiva ufficiale che spiega come creare una prima web app per la gestione di un blog con funzionalità minimali. L’utente del blog doveva essere in grado effettuare le azioni CRUD|g| (Create, Read, Update, Delete) che si mappano sulle richieste HTTP, ovvero:

• Create: creare una nuova risorsa, nel caso speciﬁco un nuovo articolo; la funzionalità si mappa su una richiesta POST

• Read: visualizzare gli articoli presenti; si mappa su una richiesta GET;

• Update: aggiornare le informazioni relative ad un articolo; si mappa su una richiesta PUT;

• Delete: rimuovere un articolo presente nel database; si mappa su una richiesta DELETE.

La guida comincia con la descrizione della struttura di un’applicazione Ruby on Rails. Come detto uno dei principi sottostanti è “Convention over Configuration” e in base a tale principio nel creare una nuova applicazione Rails genera una struttura predefinita di directory, nella quale ognuna ha un compito specifico. Tale struttura rispecchia l’architettura MVC, che prescrive la separazione tra modello dei dati, viste e logica di interazione. La tabella 3.1 descrive le cartelle e i file principali.

Models

I modelli sono classi che rappresentano le entità dei dati. La convenzione prescrive che il nome dei modelli sia al singolare in camel case (ad esempio LineItem), mentre il nome del file sia in snake case (ad esempio line_item.rb). A differenza di altri framework, il file dei modelli non contengono la dichiarazione del nome e del tipo degli attributi. Esiste infatti una associazione uno a uno tra le classi di modello e le tabelle del database. Al momento della creazione di un modello, viene infatti generata (o creata manualmente) una migration per la creazione della tabella corrispondente nel database, che avrà lo stesso nome al plurale (ad esempio line_items). Definire 3.3. LE DUE FASI 19

Nome Descrizione app/ Contiene i modelli, le viste, i controller e gli asset, oltre ad altre cartelle come helpers e mailers config/ Contiene i file routes.rb per l’instradamento (ovvero associare azioni di un controller ad un URL), database.yml per la configurazione del database e altri file di configurazione db/ Contiene lo schema del database e tutte le migrations effettuate o da effettuare Gemfile Permette di specificare le RubyGem da aggiungere all’applicazione lib/ Contiene file di componenti non strettamente legati alla specifica applicazione, che potrebbero in futuro essere aggregati ed incapsulati in una RubyGem public È l’unica cartella visibile dall’utente finale. Contiene file statici come le immagini, e gli asset compilati test/ Contiene i file di testing vendor/ Contiene codice di terze parti Tabella 3.1: File e cartelle principali di una applicazione Ruby on Rails

gli attributi nel ﬁle di modello sarebbe un’inutile ripetizione che andrebbe contro il principio DRY. Le classi modello estendono la classe ActiveRecord, che fornisce le seguenti funzionalità:

• Rappresentare il modello dei dati;

• Rappresentare le associazioni tra i modelli;

• Validare i modelli prima di essere salvati nel database;

• Eﬀettuare operazioni sul database in un approccio object-oriented.

Views

I file di vista descrivono la struttura e i contenuti delle pagine web dell’applicazione. Il formato di questi file è .html.erb, dove erb sta per Embedded Ruby. Essi infatti sono file HTML in cui sono integrate porzioni di codice Ruby, al fine di renderle dinamiche nei contenuti.

Controllers

I controller rappresentano la logica di connessione tra le viste e il modello dei dati. Ad esempio, una volta compilato il form di una pagina, l’azione associata a tale form è definita in un controller associato, solitamente per la creazione di un oggetto 20 CAPITOLO 3. IL PROGETTO: WEBSOCKET NOTIFIER a partire dai dati forniti. Più in generale questa associazione viene effettuata nel file routes.rb, che serve a mappare un dato URL ad una determinata azione. La convenzione prescrive che il nome del controller sia lo stesso del modello associato, al plurale, con suffisso ‘Controller’ (ad esempio LineItemsController). I controller estendono la classe ApplicationController. Le azioni principali di un controller sono quelle legate alle operazioni CRUD.

Assets

Gli asset sono risorse che comprendono immagini, file CSS e file JavaScript. Gli ultimi due possono essere definiti anche in linguaggi che necessitano di essere precompilati, come ad esempio Sass|g| o SCSS|g| che aggiungono funzionalità al CSS o TypeScript e CoffeeScript che compilano in JavaScript.

Asset Pipeline L’Asset Pipeline è una componente che si occupa di concatenare in un unico ﬁle e comprimere gli asset per renderli disponibili all’utilizzo da parte dell’applicazione Rails. È l’Asset Pipeline che si occupa di precompilare i ﬁle che necessitano di tale passaggio.

Migrations

Le migration sono un meccanismo di Rails che permette di operare a livello di database astraendo dalla specifica implementazione dello stesso. Sono delle classi che estendono ActiveRecord::Migration e dispongono di metodi che effettuano le classiche operazioni offerte da un DBMS|g|. È all’interno delle migration che vengono definiti gli attributi di una tabella con il relativo tipo di dato. Il codice1 3.1 illustra un’esempio di migration per la creazione di una tabella Products.

1 class CreateProducts < ActiveRecord::Migration 2 def change 3 create_table :products do |t| 4 t.string :name 5 t.text :description

7 t.timestamps 8 end

9 end

10 end

Codice 3.1: Esempio di migration

Routes

Il ﬁle config/routes.rb mappa indirizzi ad azioni di un qualche controller.

1Active Record Migrations. url: http://guides.rubyonrails.org/active_record_migrations. html. 3.3. LE DUE FASI 21

Gemﬁle

Le RubyGem sono un’insieme di classi e file che concorrono ad uno stesso specifico scopo ed hanno la caratteristica di essere, nel loro complesso, indipendenti dalla specifica applicazione in cui sono integrate. In altre parole le RubyGem sono delle librerie che possono essere integrate in ogni progetto qualora le funzionalità da esse offerte siano richieste. Le RubyGem sono sviluppate e versionate in progetti a se stanti e sono spesso rilasciate pubblicamente; il sito ufficiale dove trovare le RubyGem pubblicate è https://rubygems.org/. Il Gemfile è il file che ha la responsabilità di elencare quali RubyGem integrare e le relative versioni. Un software dedicato, Bundler, richiamato attraverso il comando ‘bundle install’ provvederà a scaricare ed installare le RubyGem indicate nel Gemfile, verificando inoltre la compatibilità delle stesse.

Espansione della web app Blog

Una volta completata la guida introduttiva, il passo successivo è stato personalizzare il blog realizzato, aggiungendo nuove funzionalità:

• Ho implementato un sistema di autenticazione e autorizzazione attraverso le tre RubyGem Devise, Rolify e CanCanCan:

Devise consente di sempliﬁcare l’implementazione dell’autenticazione, fornendo le tabelle necessarie nel database, generando automaticamente i modelli, le viste e i controller relativi a login e registrazione, e fornendo altre funzionalità; Rolify si occupa di generare una tabella relativa ai ruoli ed aggiungere l’associazione con gli utenti. In questo modo ad ogni utente può essere associato un ruolo, come ad esempio Amministratore; CanCanCan inﬁne associa ad ogni ruolo determinate “ability”, ovvero capacità, autorizzazioni a compiere o meno determinate azioni.

• Ho ridisegnato l’interfaccia graﬁca sfruttando il framework Bootstrap per CSS e JavaScript. Bootstrap utilizza un layout a griglia per la disposizione dinamica degli elementi e disegna l’interfaccia con un approccio mobile-ﬁrst: permette in questo modo di realizzare pagine web responsive; fornisce inoltre una versione personalizzata di tutte le componenti comuni come pulsanti, form, testi;

• Integrando il framework CSS FontAwesome ho aggiunto all’interfaccia icone basate su font. Esse hanno il vantaggio avere tutte le caratteristiche del testo e quindi le stesse possibilità di manipolazione: essendo vettoriali cambiare la dimensione non è un problema, così come il colore, cosa che risulta diﬃcile con icone basate su ﬁle di immagine; 22 CAPITOLO 3. IL PROGETTO: WEBSOCKET NOTIFIER

• Ho creato un foglio di stile SCSS per rideﬁnire parte dello stile. Ad esempio ho applicato delle transizioni di posizione e colore al passaggio del mouse al di sopra delle icone aggiunte al punto precedente;

• Ho aﬀrontato l’internazionalizzazione della applicazione con l’utilizzo della

RubyGem i18n-rails. Essa permette di creare dei ﬁle YAML|g| di traduzione dei testi presenti per ogni singola lingua, assegnando una variabile per ogni porzione di testo da tradurre e fornendo la traduzione;

• Ho modiﬁcato le azioni di rimozione di un articolo in modo tale che fosse

eﬀettuata attraverso una chiamata AJAX|g|. Le richieste AJAX permettono di richiedere un’elaborazione al server e ricevere una risposta senza necessità di aggiornare la pagina;

• Ho cominciato ad integrare nell’applicazione le funzionalità offerte da WebSocket attraverso la RubyGem Faye, cercando di mettere in pratica le conoscenze acquisite in merito. Questo è stato il primo passo verso la seconda fase, ovvero la progettazione e realizzazione della RubyGem WebSocket Notifier. Non sono state poche le difficoltà nel comprendere il corretto funzionamento del meccanismo di comunicazione basato su un web server dedicato, e il giusto metodo per configurarlo e implementarlo nell’applicazione. Al termine di questa fase sono comunque riuscito ad ottenere un’implementazione funzionante dello scambio di messaggi tramite WebSocket.

3.3.2 Fase 2: sviluppo del modulo WebSocket La seconda fase dello stage, che da Piano di Lavoro doveva durare 140 ore, è stata dedicata alla produzione del modulo di comunicazione WebSocket. Mentre inizialmente era stata prevista una separazione netta tra la prima fase di studio e la seconda riservata allo sviluppo, aver anticipato l’inizio del progetto di circa una settimana e mezza ha causato una sovrapposizione delle due. Questo si è rivelato in realtà utile e in qualche modo necessario per focalizzare lo studio nella giusta direzione. 3.4. CREAZIONE DELLA RUBYGEM 23

3.4 Creazione della RubyGem

Nella realizzazione della RubyGem WebSocket Notifier ho avuto la necessità di iterare numerose volte le attività del processo di sviluppo. Questo a causa della mia inesperienza nell’ambito in questione, che ha portato ad alternare fasi di ricerca e studio a quelle di sviluppo. Per questo motivo più volte ho adattato la pianificazione e aggiornato l’analisi dei requisiti, e più volte ho modificato la progettazione.

3.4.1 Presentazione delle speciﬁche L’assegnazione del progetto ha avuto inizio a circa tre settimane dall’inizio dello stage. La presentazione delle richieste è avvenuta per mezzo di una riunione che ha coinvolto il mio tutor aziendale e il collega che ha formulato le speciﬁche del progetto. Questo è stato necessario sopratutto a causa del basso livello di dettaglio tenuto nel Piano di Lavoro. Elenco di seguito le richieste relative al prodotto desiderato:

• Il prodotto Software doveva consentire di:

Inviare notiﬁche push dal server ai client in real-time; Eﬀettuare streaming di dati in real-time; Inviare messaggi tra client, in real-time; nei contesti considerati questa funzionalità era ritenuta non fondamentale;

• Il prodotto Software doveva rispettare i seguenti vincoli:

La comunicazione doveva essere aﬃdabile: doveva essere garantita la ricezione del 100% dei messaggi inviati; La comunicazione doveva essere real-time: la latenza massima consentita era pari a 1 secondo; La comunicazione doveva essere multicanale; La comunicazione doveva essere multiutente; Il prodotto doveva essere conﬁgurabile; Il prodotto doveva essere riutilizzabile;

• Opzionalmente è stato suggerito lo studio della tecnologia RXJS (Reactive Extension for JavaScript) per valutarne l’utilità nello sviluppo;

• Sebbene delineati, non enuncio i contesti di utilizzo del prodotto, in quanto relativi a progetti privati dell’azienda;

3.4.2 Pianificazione La pianificazione è stata realizzata sfruttando gli strumenti messi a disposizione dal software Asana. Asana è una web app per la gestione di progetto, con diversi strumenti integrati. Personalmente ho fatto uso della funzionalità di gestione dei task 24 CAPITOLO 3. IL PROGETTO: WEBSOCKET NOTIFIER associata ad un’ulteriore web app, Instagantt, che si integra con Asana e consente la produzione di diagrammi di Gantt a partire dalle attività presenti nel progetto. Al netto di quanto detto riguardo le iterazioni compiute, la pianificazione ha dato una prima stima dei tempi necessari per le attività, fissando delle milestone per il raggiungimento di determinati obiettivi. Elenco di seguito i punti chiave della Pianificazione:

• La prima fase è stata riservata all’Analisi dei requisiti, durante la quale ho studiato il problema, cercando riferimenti a quanto emerso dalla riunione di presentazione del progetto e esplicitando i requisiti;

• L’attività di Progettazione è stata iniziata in parallelo a quella di studio e di analisi, in modo da adattare entrambe le parti in base alle informazioni che man mano emergevano;

• Ho ritenuto utile procedere quanto prima alla realizzazione di un prototipo usa e getta per comprendere come realizzare le funzionalità core richieste;

• Successivamente ho riservato del tempo per occuparmi della riorganizzazione del codice del prototipo, in modo da poter apportare le giuste modiﬁche alla prima progettazione architetturale. In questa fase ho anche provveduto alla parametrizzazione del codice;

• L’ultima fase di sviluppo era riservata alla realizzazione della RubyGem, a partire dall’implementazione fatta;

• La documentazione del codice è stata pianiﬁcata per la parte ﬁnale dello sviluppo, ma in realtà è stata portata avanti di pari passo;

• La pianiﬁcazione prevedeva di eﬀettuare i test solo a codice ultimato, in contrasto con i principi del modello BDD (Behaviour Driven Deveolpment),

derivato dal TDD|g| (Test Driven Development), che prevedono di scrivere prima i test al ﬁne di guidare lo sviluppo.

Il diagramma di Gantt in ﬁgura 3.1 riassume quanto elencato sopra. 3.4. CREAZIONE DELLA RUBYGEM 25

Figura 3.1: Diagramma di Gantt per la Pianiﬁcazione 26 CAPITOLO 3. IL PROGETTO: WEBSOCKET NOTIFIER

3.4.3 Analisi dei requisiti In questa fase ho formalizzato i requisiti del prodotto da sviluppare, annotando quelli enunciati e cercando di identificare quelli impliciti. Non ho effettuato un vero e proprio tracciamento dei requisiti con il supporto di un database e strumenti dedicati; ho solo provveduto ad elencarli, sfruttando Asana, per poi essere in grado man mano di annotare quali fossero soddisfatti. Questa mancanza di formalità ho ritenuto fosse giustificata dal numero ridotto di requisiti e casi d’uso emersi e dal fatto che non si trattava di un progetto di gruppo, nel quale il giusto livello di formalità aiuta ad evitare problemi nella collaborazione. La tabella ?? elenca i requisiti identificati. Il codice identificativo dei requisiti rispetta la forma R(F/Q/V)(N/D/O); il significato di ogni lettera e descritto nella seguente legenda:

R Requisito F Funzionale Q Qualitativo V Di Vincolo N Obbligatorio (necessario) D Desiderabile Z Opzionale Numero incrementale

Requisito Descrizione RFN1 Il modulo deve consentire al Server di inviare notifiche ai Client in modalità push RFN2 Il modulo deve consentire lo streaming continuo di dati RFN3 La comunicazione deve essere multicanale RFN4 La comunicazione deve essere multiutente RFN5 Il modulo deve essere configurabile RFN6 Il modulo deve essere riusabile RVN7 La comunicazione deve essere affidabile: il 100% dei messaggi inviati deve arrivare a destinazione RVN8 La comunicazione deve essere real-time: è ammesso un ritardo massimo di 1 secondo nella trasmissione Tabella 3.2: Requisiti obbligatori 3.4. CREAZIONE DELLA RUBYGEM 27

Requisito Descrizione RFD9 Il modulo deve consentire l’invio di messaggi tra Client RFD10 Deve essere creata una RubyGem RFD11 Il formato dei messaggi deve essere JSON RFD12 I messaggi inviati devono comprendere il timestamp del momento di creazione RFD13 I messaggi devono devono comprendere un token univoco RQD14 Deve essere creata una suite di test RSpec per il codice Ruby on Rails RQD15 Deve essere creata una suite di test Jasmine per il codice TypeScript Tabella 3.3: Requisiti desiderabili

Requisito Descrizione RFZ16 Deve essere utilizzato il linguaggio RXJS Tabella 3.4: Requisiti opzionali

3.4.4 Progettazione

Scelta dell’implementazione di WebSocket

Considerando da una parte il tempo a disposizione e soprattutto il principio di riuso sistematico del codice, era impensabile che il progetto partisse dall’implementazione del protocollo WebSocket senza avere alcuna base di partenza. Fortunatamente numerose sono le implementazioni disponibili in ambiente Rails, anche se altri framework rendono il compito meno complicato. Prima di giungere alla scelta ho analizzato le diverse possibilità:

• ActionCable è la soluzione integrata in Rails 5: poteva essere una buona scelta, ma ho dovuto scartarla in quanto la conﬁgurazione di sviluppo in azienda utilizza Rails 4;

• Vi sono alcune RubyGem che forniscono diverse implementazioni di WebSocket per Rails, ma non erano adatte al progetto specifico: l’implementazione troppo a basso livello lasciava l’onere allo sviluppatore di effettuare controlli e stabilire protocolli per assicurare la qualità e l’affidabilità della connessione, o il recupero da stati di failure del server o di un client;

• Un’alternativa era utilizzare un server Node.js esterno e sfruttare una implementazione di WebSocket come Socket.IO o Engine.IO.

• Una possibilità era sfruttare faye-websocket, ovvero solo il modulo WebSocket di Faye; 28 CAPITOLO 3. IL PROGETTO: WEBSOCKET NOTIFIER

• Altre implementazioni comprendevano nell’architettura un’ulteriore componente server, Redis; per mantenere più semplice l’architettura seguendo i consigli ricevuti, ho scartato anche queste possibilità;

• Inﬁne la soluzione scelta: Faye.

Faye

Faye2 è un sistema di messaggistica di tipo publish-subscribe (pubblicazione- sottoscrizione), basata sul protocollo Bayeux. Fornisce sia un’implementazione per Node.js, sia una per Ruby; il mio progetto ha sfruttato la versione per Ruby. Per la più semplice implementazione e la maggiore presenza di documentazione online ho aﬃancato a Faye il server Thin, basato su EventMachine. Questa scelta si è rivelata poi non la migliore per i seguenti motivi: • Sia Faye, sia Thin sfruttano EventMachine, una libreria di event-processing basata sul pattern Reactor. Questo durante lo sviluppo ha causato problemi perché l’interazione tra le due parti creava interferenza durante l’invio dei messaggi da server.

• Come spiegherò in§3.4.8“Validazione”, la configurazione server in azienda è Phusion Passenger su Apache: una combinazione particolarmente sfortunata poiché presenta problemi nell’uso del protocollo WebSocket; la soluzione al problema non è ancora stata trovata dopo un paio d’anni di discussioni online. Una volta riscontrato il problema, in accordo con il tutor aziendale, ho posticipato la ricerca di una soluzione, affidandomi per lo sviluppo al server Thin. Dopo la validazione ho effettuato delle modifiche insieme al collega che ha assegnato il progetto, di fatto aggirando il problema ed ottenendo le funzionalità richieste senza apportare modifiche alla configurazione esistente.

Architettura

L’architettura prevedeva due sottosistemi separati e comunicanti grazie all’utilizzo della RubyGem di integrazione con Faye. Essa permette di avviare un web server dedicato alla comunicazione basata (in questo caso) su WebSocket. I due sottosistemi sono relativi alla parte Server e alla parte Client. La ﬁgura 3.2 evidenzia tale architettura. A livello concettuale si identiﬁcano tre parti: • La funzione di Server è rappresentata dal server Faye: esso è responsabile di inoltrare messaggi in broadcast su un dato canale ai Browser Client;

• Il Server-Side Client è la componente back end che invia i messaggi al server Faye aﬃnché lo recapiti ai Browser Client;

• I Browser Client, ovvero i client JavaScript che ricevono le notiﬁche push dal server.

2Faye. url: https://faye.jcoglan.com/. 3.4. CREAZIONE DELLA RUBYGEM 29

Publish/Subscribe Il meccanismo che sta dietro allo scambio di messaggi è il seguente:

• Subscribe: i Browser Client devono iscriversi ad un determinato canale: questo signiﬁca che sono pronti a ricevere eventuali notiﬁche push provenienti dal Server;

• Publish: il Server-Side Client (o un Browser Client) può pubblicare un messaggio su un dato canale: la richiesta di pubblicazione giungerà al server Faye, il quale si occuperà di inoltrare il messaggio in broadcast a tutti i client iscritti a quel canale.

3.4.5 Sviluppo

Il processo di sviluppo è stato suddiviso in tre fasi:

1. Creazione di un prototipo basato sulla prima idea di architettura: esso doveva implementare le funzionalità core all’interno di una delle applicazioni in sviluppo in Si14. Durante questa fase ho proseguito contestualmente con con lo studio delle tecnologie e l’adattamento dell’architettura;

2. Riorganizzazione del codice e generalizzazione dell’implementazione: questa fase è stata propedeutica alla successiva creazione della RubyGem;

3. Creazione della RubyGem.

Lato Server

Lo sviluppo lato Server ha presentato diverse problematiche. La prima è stata comprendere il giusto funzionamento della RubyGem Faye e come integrarla nel- l’applicazione. La soluzione stava nel creare un ﬁle di conﬁgurazione (config.ru, 3.2), richiamato dalla componente Rack di Rails, in modo che l’applicazione avesse le informazioni necessarie per avviare il web server di Faye e montarlo sul punto di mount fornito.

1 require’faye’ 2 bayeux = Faye::RackAdapter.new(:mount =>’/faye’, :timeout => 25) 3 run bayeux

Codice 3.2: File config.ru per web server Faye

Una volta avviato il server Thin e separatamente il server Faye, quest’ultimo era raggiungibile all’indirizzo di mount. Il server Faye, oltre a gestire la comunicazione, mette a disposizione il ﬁle faye.js che contiene il codice di comportamento dei Browser Client e che deve quindi essere importato nel template delle pagine HTML. Successivamente, valutando se ci fosse un metodo per avviare il server Faye contestualmente all’avvio del server Thin, ho deciso di utilizzare un’ulteriore Ruby- 30 CAPITOLO 3. IL PROGETTO: WEBSOCKET NOTIFIER

Gem: Faye-Rails3. Quest’ultima, tra le altre cose, permette di integrare Faye come middleware, e quindi di avviarlo automaticamente insieme al server HTTP.

Invio messaggi dal Server

Non potendo illustrare l’implementazione a livello di codice della classe Notifier, ne mostro un contesto di utilizzo. Notifier rappresenta il Server-Side Client. Il metodo dispatch (vedi Codice 3.3) prende un messaggio e un canale sul quale pubblicarlo.

1 # Get the notifier singleton instance 2 notifier = WebSocketNotifier::Notifier.instance# Notifier is the server-side Faye client 3 notifier.dispatch(’/example/channel’,’Example message’)

Codice 3.3: Invio messaggi dal Server

Un utilizzo comune è quello di associare la pubblicazione di un messaggio contestualmente al veriﬁcarsi di un certo evento che coinvolge un modello. A tal ﬁne tornano utili le funzioni callback di ActiveRecord, quali after_create o before_update. Esse permettono di eseguire determinate azioni quando ad esempio viene creato un nuovo record nel database, o quando viene aggiornato, o rimosso. Il Codice 3.4 illustra un esempio di utilizzo.

1 # model.rb 2 class Model < ActiveRecord::Base 3 after_create :notify

5 #...

7 private

9 def notify 10 notifier = WebSocketNotifier::Notifier.instance

12 # Senda simple plain text message 13 notifier.dispatch(’/models/new’,"Model #{self.id} created")

15 # Send the instance of model created in JSON format for further manipulation 16 json_data = self.to_json 17 notifier.dispatch(’/models/new’, json_data) 18 end

19 end

Codice 3.4: Uso del metodo dispatch con le callback di ActiveRecord

3Faye-Rails. url: https://github.com/jamesotron/faye-rails. 3.4. CREAZIONE DELLA RUBYGEM 31

Lato Client

L’implementazione lato client è avvenuta sfruttando il linguaggio TypeScript. Esso si basa su JavaScript e lo estende attribuendogli caratteristiche come il controllo dei tipi, classi e moduli, proprie di un linguaggio Object Oriented. TypeScript eﬀettua questi controlli solo a compile-time, in quanto il risultato della compilazione è nuovamente codice JavaScript.

Iscrizione a un canale

I Browser Client usano il metodo subscribe per iscriversi a un canale. Il metodo accetta il canale e una funzione callback da eseguire ogni qual volta un si riceva un messaggio.

1 var wsc= WebsocketClient; 2 wsc.subscribe("/example/channel", function(data){ 3 /* here goes the logic to execute on message receiving 4 * example: 5 * alert(data); 6 */ 7 });

Codice 3.5: Iscrizione a un canale

Pubblicazione lato Client

Sebbene non fosse una funzionalità di grande interesse nel contesto aziendale, anche i Browser Client possono fare richiesta di pubblicazione chiamando il metodo publish, simile a dispatch lato server.

Le classi Extension

Le classi Extension servono per manipolare i messaggi in entrata e in uscita. Sono deﬁnite classi estensione sia lato server, sia lato client. Esempi di utilizzo possono essere:

• Aggiungere un timestamp del momento della pubblicazione;

• Aggiungere un token univoco;

• Aggiungere un token di autorizzazione al momento della pubblicazione: il Server provvederà a veriﬁcarlo (e rimuoverlo) prima di inoltrarlo agli altri Browser Client;

• Fornire funzionalità di logging (lato server e lato client), mostrando le informazioni relative ai messaggi in entrata e in uscita.

Relativamente all’ultimo punto, il Codice 3.6 illustra il codice della classe estensione LoggerExtension. 32 CAPITOLO 3. IL PROGETTO: WEBSOCKET NOTIFIER

1 # The class representsa Faye server extension for logging incoming and outgoing 2 # messages on the server console in development. It only logs the messages which 3 # do not start with ’/meta’, which are used by Faye for operating. 4 class LoggerExtension 5 def incoming(message, callback) 6 if message[’channel’] !~ %r{^/meta/} 7 puts’INCOMING:’ + message.to _json 8 end 9 callback.call(message) 10 end

12 def outgoing(message, callback) 13 if message[’channel’] !~ %r{^/meta/} 14 puts’OUTGOING:’ + message.to _json 15 end 16 callback.call(message) 17 end

18 end

Codice 3.6: LoggerExtension

3.4.6 Documentazione

La documentazione fornita è stata quella a corredo del codice e un breve documento esterno riguardante l’installazione, la conﬁgurazione, l’utilizzo e l’estensione della RubyGemprodotta.

RDoc

Per quanto riguarda i commenti di documentazione del codice, è stata inizialmente usata la sintassi RDoc, in modo tale che potesse essere generata la documentazione esterna sulle classi.

YARD

YARD è un generatore di documentazione, superset di RDoc. Ho pensato di adattare la documentazione già realizzata come commenti YARD in quanto ho ritenuto che fosse maggiormente esplicativa e disciplinata rispetto a RDoc. YARD sfrutta le annotazioni ed è più simile a software come JavaDoc: permette di riferire e descrivere parametri, attributi, ritorno di metodi e aggiungere informazioni alla descrizione delle classi. 3.4. CREAZIONE DELLA RUBYGEM 33

Figura 3.2: Prima architettura della RubyGem 34 CAPITOLO 3. IL PROGETTO: WEBSOCKET NOTIFIER

3.4.7 Testing

A causa della inesperienza nelle tecnologie e nell’ambito del progetto, ho reputato in accordo con il tutor aziendale che fosse opportuno lasciare la creazione dei test al termine dello sviluppo. Questo va contro i principi del BDD, ma scrivere test senza avere l’esperienza necessaria avrebbe rallentato tutto lo sviluppo del progetto.

RSpec

RSpec è un framework di testing basato sul modello BDD. Consente di creare “specification” (abbreviato in “spec”) che descrivono il comportamento di una determinata unità. L’ultima settimana è stata dedicata alla integrazione di RSpec nell’applicazione e alla definizione dei test di unità. Purtroppo questo si è rivelato un compito più difficile del previsto a causa della natura dell’applicazione. Per verificare il funzionamento dei singoli metodi lato server doveva essere avviato e terminato automaticamente il server Thin. Non solo, per testare l’invio e la ricezione dei messaggi (separatamente), era necessario che fosse attivo anche il web server Faye e che EventMachine fosse attiva. Infine c’è da sottolineare che testare una RubyGem non è semplice come testare una qualsiasi applicazione Ruby on Rails. Configurare l’avvio automatico dei server è stata per questo un’attivià dispendiosa, che ha ridotto il tempo a disposizione per la scrittura dei test. Per questo e per l’inesperienza nell’utilizzo del framework RSpec non sono riuscito a portare a termine la realizzazione della suite di test: solo alcune funzionalità sono state testate.

Jasmine

Jasmine è un framework di testing per Javascript ed è stata la tecnologia scelta per compiere i test lato client. Purtroppo, per quanto detto, non ho completato i test lato server, dunque non ho aﬀrontato il testing lato client.

3.4.8 Validazione

La validazione, avvenuta il giorno prima della conclusione dello stage, ha confermato il raggiungimento di quasi tutti gli obiettivi, escluso, come detto, quello relativo alla suite di test a corredo. Essa ha però evidenziato il problema relativo alla conﬁgu- razione del server dell’azienda, presentato in§3.4.4“Scelta dell’implementazione di WebSocket”: la RubyGem, basata su server Thin, non poteva funzionare su Phusion Passenger. Inoltre, usare Passenger su Apache non consentiva di utilizzare appieno la tecnologia WebSocket. 3.4. CREAZIONE DELLA RUBYGEM 35

Adattamento della RubyGem

Per questo motivo l’ultimo giorno di stage ho collaborato per apportare le modiﬁche necessarie per adattare la RubyGem all’uso in azienda. Elenco brevemente le modiﬁche apportate:

• Abbiamo sostituito l’implementazione in Ruby di Faye con quella in Node.js; usare un server Node esterno ha consentito di sgravare Passenger dai compiti che causavano il suddetto problema con Apache;

• Sono stati creati degli script conﬁgurabili per avviare il server Node sull’endpoint desiderato.

Copertura dei requisiti

Nel Piano di Lavoro erano stati deﬁniti inizialmente due obiettivi di massima, riportati di seguito.

Obiettivo minimo Prevedeva lo studio propedeutico delle tecnologie da utilizzare nella seconda fase. La lista delle tecnologie è la seguente

• framework di programmazione Ruby on Rails e basi di linguaggio Ruby;

• framework BDD (Behaviour Driven Development) RSpec;

• linguaggi JavaScript e TypeScript;

• WebSocket.

L’obiettivo minimo è stato raggiunto pienamente.

Obiettivo massimo Prevedeva la creazione di un’infrastruttura di comunicazione tra back-end e front-end utilizzando la tecnologia WebSocket, comprendente una suite di test. Riporto di seguito i requisiti emersi durante lo stage dalla presentazione del progetto. Come si può vedere dalle tabelle i requisiti obbligatori (tabella 3.5) sono stati soddisfatti nella loro totalità. Per quanto riguarda i requisiti desiderabili (tabella 3.6), i due relativi al testing della RubyGem non sono stati soddisfatti. Il requisito opzionale (tabella 3.7) sull’utilizzo di RXJS non è stato soddisfatto. 36 CAPITOLO 3. IL PROGETTO: WEBSOCKET NOTIFIER

Requisito Descrizione Soddisfatto RFN1 Il modulo deve consentire al Server di inviare X notifiche ai Client in modalità push RFN2 Il modulo deve consentire lo streaming X continuo di dati RFN3 La comunicazione deve essere multicanale X RFN4 La comunicazione deve essere multiutente X RFN5 Il modulo deve essere configurabile X RFN6 Il modulo deve essere riusabile X RVN7 La comunicazione deve essere affidabile: il X 100% dei messaggi inviati deve arrivare a destinazione RVN8 La comunicazione deve essere real-time: è X ammesso un ritardo massimo di 1 secondo nella trasmissione Tabella 3.5: Soddisfacimento dei requisiti obbligatori

Requisito Descrizione Soddisfatto RFD9 Il modulo deve consentire l’invio di messaggi X tra Client RFD10 Deve essere creata una RubyGem X RFD11 Il formato dei messaggi deve essere JSON X RFD12 I messaggi inviati devono comprendere il X timestamp del momento di creazione RFD13 I messaggi devono devono comprendere un X token univoco RQD14 Deve essere creata una suite di test RSpec per il codice Ruby on Rails RQD15 Deve essere creata una suite di test Jasmine per il codice TypeScript Tabella 3.6: Soddisfacimento dei requisiti desiderabili

Requisito Descrizione Soddisfatto RFZ16 Deve essere utilizzato il linguaggio RXJS Tabella 3.7: Soddisfacimento dei requisiti opzionali Capitolo 4

Valutazione retrospettiva

4.1 Bilancio dei risultati

Parlando di risultati, posso dire che lo stage in Si14 è stato un’esperienza sicuramente positiva, per i seguenti motivi:

• Gli obiettivi ﬁssati dal Piano di Lavoro sono stati soddisfatti, escludendo la scrittura della suite di test;

• La RubyGem creata, debitamente modiﬁcata al termine dello stage è stata integrata con esito positivo in una applicazione in sviluppo. Le notiﬁche push e lo streaming di dati hanno funzionato senza problemi, con le caratteristiche prestazionali desiderate;

Aldilà degli obiettivi di progetto, è stata un’esperienza utile sotto molti altri aspetti:

• Essendo la mia prima esperienza lavorativa, mi è stata utile in quanto ha permesso di farmi un’idea più chiara dei meccanismi e della vita aziendali.

• Le aspettative che avevo inizialmente erano certamente lontane dalla realtà. Per questo motivo l’entusiasmo provato è andato scemando, man mano che le difficoltà affioravano: l’idea di essere guidato in un percorso formativo ha trovato solo parzialmente riscontro. La difficoltà che l’azienda ha trovato nel fornirmi assistenza dedicata è del tutto giustificata dalla sua natura che prevede periodi di lavoro molto intensi e scadenze sfidanti. Il lato positivo è che questa condizione mi ha forzato a mettermi alla prova in un contesto nuovo, affrontando da solo argomenti a me perfettamente sconosciuti. Per questo il successo dell’esperienza ha un valore ancora più grande, dal punto di vista personale.

4.1.1 Diﬃcoltà incontrate

Il non soddisfacimento di alcuni requisiti desiderabili e opzionali non è stato valutato in modo negativo, in quanto questa mancanza è stata giustiﬁcata dalle condizioni

37 38 CAPITOLO 4. VALUTAZIONE RETROSPETTIVA sotto le quali lo stage è stato condotto: le difficoltà incontrate sono state numerose e spesso ho dovuto affrontarle in autonomia. Queste difficoltà sono state di diversa natura e riguardavano:

• L’ambientazione nel contesto aziendale;

• Le tecnologie da apprendere;

• Il rapporto con i colleghi;

• La conﬁdenza di saper aﬀrontare e potare a termine il progetto assegnato;

• La gestione del tempo. Per risolvere le problematiche relative a un determinato task è capitato di dedicare troppo tempo rispetto a quanto calcolato. Essen- do per me nozioni nuove, ogni passo avanti richiedeva una fase di studio e comprensione, che in alcuni casi si è spinta più in là del dovuto.

Tutte le diﬃcoltà sopra elencate sono state risolte durante il corso dello stage; da qui è nato il giudizio positivo sull’esperienza complessiva.

4.2 Bilancio formativo

Uno dei punti di maggiore rilevanza è da ricercare nella crescita personale conseguente all’esperienza fatta. Dal punto di vista prettamente formativo, la quantità di informazioni apprese è stata per me signiﬁcativa. Segue un’elenco non esaustivo di quanto ho appreso durante lo stage, individuando conoscenze, abilità e competenze.

4.2.1 Conoscenze

Dallo studio e dalle ricerche condotte ho appreso informazioni riguardo le seguenti tecnologie a me sconosciute:

• Ruby on Rails;

• WebSocket;

• RSpec;

• WebRTC;

• TypeScript;

• SCSS;

• Editor Vim;

• EventMachine, Reactor Pattern e Deferrable;

• Sicurezza e attacchi (XSS); 4.3. IL GAP FORMATIVO 39

• Web server (Thin, Puma, Passenger, Apache);

• Faye;

Ho inoltre approfondito la mia conoscenza in:

• JavaScript;

• Bootstrap;

• Internazionalizzazione;

• Autenticazione e autorizzazione;

• Protocollo HTTP;

• Sublime Text 3;

4.2.2 Abilità Ciò che deriva dall’esperienza pratica, a prescindere da quanto studiato, è elencato di seguito:

• La capacità di gestire meglio il tempo a disposizione, dando diversa priorità ai task da portare a termine;

• L’interazione con i colleghi, capire come e quando richiedere il loro intervento, collaborare, socializzare;

• Rispetto delle procedure aziendali.

4.2.3 Competenze A partire dalle conoscenze apprese ho sviluppato le seguenti competenze:

• Creare un’applicazione web sfruttando il framework Ruby on Rails;

• Realizzare una RubyGem e rilasciarla pubblicamente;

• Sfruttare il protocollo WebSocket per l’invio di notiﬁche push e per streaming di dati;

4.3 Il gap formativo

Sebbene l’esperienza sia andata a buon fine e gli obiettivi siano stati quasi tutti raggiunti, il percorso non è stato facile. A mio modo di vedere il progetto affidato è stato sottovalutato nella sua complessità, o forse non ben calibrato sulle conoscenze e capacità che ha in media un laureando in Informatica. L’aspetto di cui si avverte maggiormente la carenza è l’esperienza pratica: per interesse personale ho approfondito le tematiche relative al Web Development nell’ultimo anno e nonostante questo 40 CAPITOLO 4. VALUTAZIONE RETROSPETTIVA l’esperienza di stage è stata sfidante. L’università ha lo scopo di formare le basi teoriche e l’approccio mentale giusto: insieme rappresentano la risorsa più grande per affrontare qualsiasi sfida. Credo però che misurarsi con progetti concreti anche durante il periodo accademico possa fornire nel tempo la consapevolezza che giunge solo con l’esperienza. Credo sia proprio la consapevolezza dunque, il nocciolo della questione: ci si aspetta che uno studente universitario abbia già formato nel tempo un proprio metodo di studio efficace, che abbia le idee chiare su qual è il suo percorso, sul perché delle sue scelte e dove queste lo porteranno, ma ho avuto modo di verificare che spesso non è così. Se l’università (e la scuola in generale) vuole dare più opportunità ai suoi studenti, dovrebbe puntare a creare in essi una profonda consapevolezza, fin dal principio. Da questo ne deriva che il corso di studi, che a livello di contenuti ritengo decisamente ben organizzato e di alto livello, potrebbe ottenere qualcosa di più lavorando sugli studenti stessi, aiutandoli a formare un solido metodo. Il divario che c’è tra le aspettative delle aziende e quello che gli studenti hanno da offrire penso che trovi quindi in questo una spiegazione. Ragionando invece a livello nozioni che mi sono mancate penso che il corso di Informatica possa puntare maggiormente sui seminari tecnologici: questo non per apprendere la specifica tecnologia, ma per abituare lo studente a restare sempre aggiornato ad affrontare il cambiamento che in questo settore è costante e velocissimo. Allo stesso tempo dovrebbe continuare il percorso intrapreso per avvicinare studenti e aziende: lo sforzo compiuto dall’Università di Padova in questo senso è davvero apprezzabile, un sforzo ricompensato dai risultati che diventano sempre più concreti. In conclusione credo quindi che questa sia la strada giusta da percorrere per arrivare a una collaborazione sistematica con le aziende del territorio che possa dare ottimi frutti per gli studenti, le aziende stesse e l’università. Glossario

AJAX in informatica con il termine AJAX, Asynchronous JavaScript and XML si indica una tecnica di sviluppo software per la realizzazione di applicazioni web interattive (Rich Internet Application). Lo sviluppo di applicazioni HTML con AJAX si basa su uno scambio di dati in background fra web browser e server, che consente l’aggiornamento dinamico di una pagina web senza esplicito ricaricamento da parte dell’utente. 22, 47

API in informatica con il termine API, Application Programming Interface si indica un insieme di procedure per la produzione di software. Solitamente sono raggruppati a formare un set di strumenti specifici per l’espletamento di un determinato compito all’interno di programma. La finalità è ottenere un’a- strazione che nasconda al programmatore la complessità dei livelli inferiori, semplificando così la programmazione.4, 47

BDD nell’ambito dell’ingegneria del software il behaviour-driven development (BDD) è una metodologia di sviluppo del software basata sul test-driven development (TDD). Il BDD prescrive di definire delle specifiche di comportamento delle componenti software in sviluppo, quindi produrre una suite di test che le verifichino. Definiti i test lo sviluppo delle componenti sarà guidato dagli stessi e volto al loro superamento. 12, 47

CRUD in informatica create, read, update e delete (CRUD) sono quattro funzioni di base relative alla gestione di un database. Esse si rappresentano infatti la creazione, lettura, modiﬁca e cancellazione di record. 18, 20, 47

CSS in informatica il Cascading Style Sheets (CSS) è un linguaggio usato per deﬁnire la formattazione di documenti HTML. Il CSS è deputato alla gestione dello stile graﬁco e quindi alla presentazione delle pagine di un sito web.7, 15, 47

DBMS in informatica un Database Management System (DBMS) è un sistema software progettato per consentire la creazione, la manipolazione e l’interrogazione eﬃciente di database. 20, 47

HIPAA l’Health Insurance Portability and Accountability Act (HIPAA) è un atto promulgato nel 1996 dal 104◦ Congresso degli Stati Uniti d’America che ﬁssa

41 42 Glossario

gli standard per proteggere i dati sentibili dei pazienti. Ogni azienda che tratta informazioni protette sulla salute dei pazienti deve assicurare di disporre delle necessarie misure di sicurezza, e che queste siano rispettate.8, 47

HTTP l’HyperText Transfer Protocol (HTTP) è un protocollo a livello applicativo usato come principale sistema per la trasmissione di informazioni sul web in un’architettura tipica client-server. 16–18, 30, 40, 47

IETF l’Internet Engineering Task Force (IETF) è un organismo internazionale, libero, composto da tecnici, specialisti e ricercatori interessati all’evoluzione tecnica e tecnologica di Internet. Si occupa di sviluppare e promuovere standard Internet, in stretta cooperazione con il World Wide Web Consortium e ISO/IEC . 16, 47

MVC in informatica il Model-View-Controller (MVC) è un pattern archiettturale molto diﬀuso nello sviluppo di sistemi software, che mira a separare la logica di presentazione dei dati dalla logica di business e dal modello dei dati. 16, 18, 47

MVP nello sviluppo di un prodotto innovativo, il prodotto minimo funzionante (Minimum Viable Product, MVP) è il prodotto con il più alto ritorno sugli investimenti rispetto al rischio. Il metodo prevede l’interazione con il mercato fin dalla fase di idea al fine di ricevere quanto prima feedback dagli utenti finali e adattare lo sviluppo del prodotto in base ad essi.2, 47

REST REpresentational State Transfer (REST) o servizi web RESTful sono un modo di fornire interoperabilità tra sistemi in Internet. Servizi web REST permettono al sistema richiedente di accedere e manipolare una rappresentazione testuale di una risorsa web utilizzando un insieme di operazioni stateless.4, 47

Sass Syntactically Awesome Stylesheets (Sass) è un’estensione del linguaggio CSS che permette di utilizzare variabili, di creare funzioni e di organizzare il foglio di stile in più ﬁle. 20, 47

SCSS Sassy CSS (SCSS) è una sintassi alternativa e più comune del linguaggio Sass, ed è un superset della sintassi CSS3. Questo signiﬁca che ogni valido documento CSS è un valido documento SCSS. 20, 22, 40, 47

TCP in informatica il Transmission Control Protocol (TCP) è un protocollo di rete a pacchetto di livello di trasporto appartenente alla suite di protocolli Internet. Esso fornisce una connessione aﬃdabile e con controllo degli errori tra host comunicanti attraverso una rete IP. 16, 47

TDD il test-driven development (TDD) è un modello di sviluppo del software che prevede che la stesura dei test automatici avvenga prima di quella del software che deve essere sottoposto ai test stessi, e che lo sviluppo dell’applicativo sia orientato esclusivamente al soddisfacimento dei test predisposti. 24, 47 Glossario 43

URL in informatica l’Uniform Resource Locator (URL) è una sequenza di caratteri che identiﬁca univocamente l’indirizzo di una risorsa in Internet. 19, 20, 47

YAML YAML è un formato per la serializzazione di dati utilizzabile da esseri umani. 22, 47

Acronimi e abbreviazioni

AJAX Asynchronous JavaScript and XML. 22, 43

API Application Programming Interface.4, 43

BDD Behaviour Driven Development. 12, 43

CRUD Create, Read, Update, Delete. 18, 20, 43

CSS Cascading Style Sheets.7, 15, 43

DBMS Database Management System. 20, 43

HIPAA Health Insurance Portability and Accountability Act.8, 43

HTTP HyperText Transfer Protocol. 16–18, 30, 40, 44

IETF Internet Engineering Task Force. 16, 44

MVC Model-View-Controller. 16, 18, 44

MVP Minimum Viable Product.2, 44

REST REpresentational State Transfer.4, 44

Sass Syntactically Awesome Stylesheets. 20, 44

SCSS Sassy CSS. 20, 22, 40, 44

TCP Transmission Control Protocol. 16, 44

TCP Test Driven Development. 24, 44

URL Uniform Resource Locator. 19, 20, 45

YAML YAML Ain’t a Markup Language. 22, 45

Bibliograﬁa

Siti Web consultati

Active Record Migrations. url: http://guides.rubyonrails.org/active_record_ migrations.html (cit. a p. 20).

Faye. url: https://faye.jcoglan.com/ (cit. a p. 28).

Faye-Rails. url: https://github.com/jamesotron/faye-rails (cit. a p. 30).

Manifesto Agile. url: http://agilemanifesto.org/iso/it/ (cit. a p.6).