Università degli Studi di Padova - SIAGAS
←
→
Trascrizione del contenuto della pagina
Se il tuo browser non visualizza correttamente la pagina, ti preghiamo di leggere il contenuto della pagina quaggiù
Università degli Studi di Padova
Dipartimento di Matematica
"Tullio Levi-Civita"
Corso di Laurea in Informatica
Progettazione e realizzazione di una Web
App per un dispositivo IoT
Tesi di laurea triennale
Relatore
Prof. Francesco Ranzato
Laureando
Riccardo Dalla Via
Anno Accademico 2018-2019
Riccardo Dalla Via: Progettazione e realizzazione di una Web App per un dispositivo IoT, Tesi di laurea triennale, c Luglio 2019.
Sommario
In questo documento viene descritto il lavoro svolto durante l’attività di stage
dal laureando Riccardo Dalla Via presso l’azienda M31 Italia di Padova, sotto la
supervisione del tutor aziendale Luca Cossaro.
L’attività è stata svolta al termine della Laurea Triennale, nel periodo compreso
tra l’8 Maggio 2019 ed il 28 Giugno 2019, per una durata complessiva di 320 ore.
Lo scopo dello stage è stato la progettazione e l’implementazione di un’applicazione
web che permettesse all’utente di interagire con un dispositivo IoT progettato
dall’azienda M31.
Il documento è stato suddiviso in cinque capitoli:
• Il primo capitolo descrive il contesto aziendale nel quale ho svolto l’attività
di stage, nello specifico la storia dell’azienda, la struttura interna ed i metodi
di sviluppo utilizzati;
• Il secondo capitolo descrive lo scopo dello stage, ovvero il progetto a cui
ho lavorato in questo periodo, oltre agli obiettivi aziendali e personali;
• Il terzo capitolo descrive le tecnologie utilizzate per l’implementazione del
progetto;
• Il quarto capitolo descrive le fasi che hanno composto l’attività di stage,
partendo dalle fasi di pianificazione e progettazione fino all’implementazione
vera e propria della piattaforma. Verrà infine discussa l’attività di verifica e
validazione, valutando la copertura dei requisiti elencati nel piano di lavoro;
• Il quinto capitolo, infine, contiene una valutazione retrospettiva sull’espe-
rienza di stage svolta.
iii
“When something is important enough, you do it
even if the odds are not in your favor.”
— Elon Musk
Ringraziamenti
Innanzitutto, vorrei ringraziare la mia famiglia per aver sempre creduto in me e per
essermi stati vicini in ogni momento in questi anni di studio. Siete sopravvissuti a
22 anni con me, siete forti!
Un grazie anche a Sonia per essermi stata vicina nei momenti difficili, per avermi
supportato (e sopportato) in questi tre lunghi anni di Università: non so come hai
fatto, ma ti meriti 1 punto (in meno) per il coraggio.
Ringrazio anche il Prof. Ranzato per il sostegno datomi durante la stesura di questa
tesi.
Vorrei infine ringraziare l’azienda M31, in particolare il Prof. Ruggero Frezza, Fabio
D’Alessi ed il mio tutor Luca Cossaro per avermi permesso di svolgere questo stage.
Un grazie anche a Vincenzo e Marco per gli utili consigli lavorativi (e non solo), e
per aver dato colore alle mie giornate: grazie ragazzi, -1 punto!
Padova, Luglio 2019 Riccardo Dalla Via
v
Indice
1 Dominio aziendale 1
1.1 Storia dell’azienda . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Profilo aziendale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3 Struttura aziendale . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4 Metodologia di sviluppo . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Progetto di stage 7
2.1 Il progetto: Narrow Board . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Obiettivi aziendali . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3 Obiettivi personali . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3 Tecnologie utilizzate 13
3.1 Node.js . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2 TypeScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3 Socket.io . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.4 Front end . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.4.1 Angular 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.4.2 Angular Material . . . . . . . . . . . . . . . . . . . . . . . . 17
3.4.3 RxJS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.4.4 Leaflet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.4.5 Chart.js . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.4.6 HTML5 e Sass . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.4.7 Jasmine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.5 Back end . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.5.1 Express . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.6 Tecnologie di supporto . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.6.1 Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.6.2 Kubernetes . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.6.3 Git e GitLab . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4 Stage 27
4.1 Pianificazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.2 Progettazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.2.1 Progettazione front end . . . . . . . . . . . . . . . . . . . . . 28
4.2.2 Progettazione back end . . . . . . . . . . . . . . . . . . . . . 30
4.3 Implementazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.3.1 Implementazione front end . . . . . . . . . . . . . . . . . . . 33
viiviii INDICE
4.3.2 Implementazione back end . . . . . . . . . . . . . . . . . . . 39
4.4 Verifica e validazione . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.5 Copertura dei requisiti . . . . . . . . . . . . . . . . . . . . . . . . . 40
5 Conclusioni 43
5.1 Conoscenze acquisite . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.2 Valutazione retrospettiva . . . . . . . . . . . . . . . . . . . . . . . . 43
Acronimi 45
Glossario 47
Bibliografia 51Elenco delle figure
1.1 Loghi delle aziende M31 e Si14 . . . . . . . . . . . . . . . . . . . . . 1
1.2 Rappresentazione del modello a cascata . . . . . . . . . . . . . . . . 4
1.3 Rappresentazione del framework Scrum . . . . . . . . . . . . . . . . 5
2.1 Una vista dell’applicazione Narrow Board . . . . . . . . . . . . . . . 7
3.1 Logo del runtime Node.js . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2 Logo del linguaggio di programmazione TypeScript . . . . . . . . . 15
3.3 Logo della libreria Socket.io . . . . . . . . . . . . . . . . . . . . . . 15
3.4 Logo del framework Angular . . . . . . . . . . . . . . . . . . . . . . 17
3.5 Logo di Material Design . . . . . . . . . . . . . . . . . . . . . . . . 17
3.6 Logo del toolkit RxJS . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.7 Logo della libreria Leaflet . . . . . . . . . . . . . . . . . . . . . . . 18
3.8 Esempio di implementazione delle mappe con la libreria Leaflet . . 19
3.9 Logo della libreria Chart.js . . . . . . . . . . . . . . . . . . . . . . . 19
3.10 Esempio di implementazione di un grafico con la libreria Chart.js . 20
3.11 Logo del linguaggio di markup HTML . . . . . . . . . . . . . . . . . 20
3.12 Logo del linguaggio di stile SCSS . . . . . . . . . . . . . . . . . . . 21
3.13 Logo del framework di testing Jasmine . . . . . . . . . . . . . . . . 22
3.14 Logo del framework Express . . . . . . . . . . . . . . . . . . . . . . 22
3.15 Logo del sistema di deployment Docker . . . . . . . . . . . . . . . . 23
3.16 Logo del sistema di orchestrazione Kubernetes . . . . . . . . . . . . 24
3.17 Logo del sistema di controllo di versione Git . . . . . . . . . . . . . 25
3.18 Logo della piattaforma GitLab . . . . . . . . . . . . . . . . . . . . . 25
4.1 Struttura del modulo back end . . . . . . . . . . . . . . . . . . . . . 31
4.2 Struttura delle API REST . . . . . . . . . . . . . . . . . . . . . . . 32
4.3 Interfaccia della pagina di login . . . . . . . . . . . . . . . . . . . . 33
4.4 Interfaccia della pagina di registrazione . . . . . . . . . . . . . . . . 34
4.5 Interfaccia della pagina di impostazioni utente . . . . . . . . . . . . 34
4.6 Interfaccia della pagina di visualizzazione dispositivi in lista . . . . 35
4.7 Interfaccia della pagina di visualizzazione dispositivi su mappa . . . 35
4.8 Interfaccia della pagina di aggiunta dispositivo . . . . . . . . . . . . 36
4.9 Bottone per l’aggiunta di un dispositivo . . . . . . . . . . . . . . . . 36
4.10 Interfaccia della pagina di dettaglio dispositivo . . . . . . . . . . . . 37
4.11 Interfaccia della pagina di impostazioni dispositivo . . . . . . . . . . 37
4.12 Struttura dei file del modulo front end . . . . . . . . . . . . . . . . 38
ixx ELENCO DELLE TABELLE
Elenco delle tabelle
2.1 Tracciamento degli obiettivi . . . . . . . . . . . . . . . . . . . . . . 10
4.1 Ripartizione delle ore lavorative . . . . . . . . . . . . . . . . . . . . 28
4.2 Lista degli endpoint definiti per gestire l’autenticazione . . . . . . . 32
4.3 Esito della copertura dei requisiti . . . . . . . . . . . . . . . . . . . 40Capitolo 1
Dominio aziendale
1.1 Storia dell’azienda
M31 nasce nel 2007 a partire da un professore dell’Università di Padova, Ruggero
Frezza, ed alcuni suoi studenti, con l’obiettivo di formare un’azienda che fosse in
grado di sviluppare prodotti per conto di terzi. L’idea di questa azienda nasce in
seguito al costante impegno da parte del Professor Frezza a lanciare i suoi studenti
neolaureati in progetti innovativi, che portassero alla creazione di nuove aziende.
Nel 2009 l’azienda viene divisa in due: M31, incubatore di start-up, e Si14, la quale
forniva lo sviluppo hardware dei prodotti.
Figura 1.1: Loghi delle aziende M31 e Si14
Si14 è cresciuta nel tempo allargando il suo team fino a fornire, oltre all’hardware,
anche lo sviluppo firmware, software e il design industriale dei prodotti stessi. In
questo modo, essa poteva essere definita come un acceleratore di prodotto, in quanto
aveva la capacità di sviluppare un prodotto nel suo completo.
Dal 2018, Si14 viene reintegrata in M31: quest’ultima, ad oggi, fornisce sia il servizio
di acceleratore ed incubatore di start-up che la produzione di prodotti per conto
delle start-up stesse e di aziende esterne.
1.2 Profilo aziendale
Attualmente M31 si presenta come un’azienda fortemente orientata all’innovazione
ed al trasferimento tecnologico, capace di fornire prodotti partendo da un’idea di
business passando attraverso diversi step, che comprendono: l’indagine del mercato
a cui è rivolto il prodotto, al fine di delineare le caratteristiche che deve avere; lo
sviluppo di un Minimum Viable Product (MVP)[g] per sondare il comportamento dei
potenziali clienti nei confronti del prodotto; ed infine la realizzazione del prodotto
finale, il quale dovrà apportare eventuali modifiche sulla base dei feedback ricevuti
12 CAPITOLO 1. DOMINIO AZIENDALE
con l’MVP.
Da quest’anno, inoltre, l’azienda ha iniziato a progettare e sviluppare progetti che
nascono da idee interne, ampliando ulteriormente i propri orizzonti.
Gli ambiti su cui investe l’azienda sono molteplici, partendo da quelli medici, fino a
quelli sportivi e industriali. Diversi sono i progetti sviluppati all’interno dell’azienda
sotto forma di spin-off[g] , dei quali cito:
• Wearit: spin-off che ha progettato UpSki, dispositivo indossabile che permette
di analizzare, con l’ausilio di una serie di sensori e dell’intelligenza artificiale,
le abilità di uno sciatore, fornendo feedback tramite un applicativo installabile
nel proprio smartphone;
• D-Eye: ha realizzato un dispositivo portatile per smartphone che permette,
grazie all’applicazione dell’intelligenza artificiale ai fotogrammi catturati,
l’analisi diretta tramite screening delle patologie dell’occhio;
• Uqido: azienda leader nel settore della realtà virtuale, disegna e realizza
applicazioni di calcolo immersivo applicabili in diversi ambiti, dalla formazione
all’impresa manifatturiera.
Tra i progetti più recenti sono da citare anche: Adaptica, Adant, CenterVue, Mogees
e Zehus.
1.3 Struttura aziendale
L’organico aziendale è composto di circa 40 persone, divise in diversi reparti, la
maggior parte dei quali si occupano dello sviluppo di un prodotto, dall’hardware
fino a firmware, software e design.
Reparti
Di seguito vengono elencati i reparti che compongono l’azienda, incluso il team di
sviluppo con cui ho lavorato nel mio periodo di stage.
• Amministrazione, che ha il ruolo di gestione aziendale, soprattutto dal
punto di vista economico;
• Finanza, che stabilisce le decisioni finanziare che l’azienda deve prendere;
• Controllo, che verifica il corretto conseguimento degli obiettivi da parte di
tutti i reparti dell’azienda;
• Produzione, si occupa di controllare e migliorare tutte le attività di logistica
dell’azienda, quali la gestione degli ordini necessari per lo sviluppo di un
prodotto, la loro catalogazione e la gestione della catena di distribuzione;
• Research and Development, reparto chiave dell’azienda per la sua natura,
si occupa della ricerca e dello sviluppo dell’innovazione tecnologica sotto forma
di prodotti, e può essere ulteriormente suddiviso in:1.4. METODOLOGIA DI SVILUPPO 3
– Hardware, il cui team si occupa della progettazione e sviluppo delle
schede elettroniche che compongono un nuovo prodotto;
– Firmware, il cui team realizza il codice più a basso livello che permette
di tradurre gli impulsi elettrici delle schede implementando un protocollo
di comunicazione. Si tratta quindi della parte di codice che permette al
software di interfacciarsi con l’hardware;
– Software, il cui team sviluppa database, Application Programming
Interface (API)[g] e interfaccia grafica, ovvero la parte di prodotto con
cui il cliente finale interagisce effettivamente. È il team con cui ho avuto
maggiormente a che fare nel mio periodo di stage;
– Design, il cui team determina e realizza ergonomia ed estetica del
prodotto;
• Sales, si occupa della gestione delle vendite individuando di volta in volta la
strategia più adatta.
Gestione comunicazioni
I reparti comunicano tra loro utilizzando principalmente la posta elettronica azienda-
le. Per le comunicazioni più informali si utilizza invece il software Microsoft Teams,
che fornisce un sistema di messaggistica in tempo reale, oltre a videochiamate
e condivisione di file. Inoltre, qualora necessario, per comunicazioni importanti
ed urgenti vengono convocate riunioni presso una delle tante sale a disposizione
dall’azienda.
Gestione aziendale
Per la gestione aziendale viene invece utilizzato Bytes, un software sviluppato
internamente che permette la gestione dell’organico, potendo ad esempio verificare
la disponibilità di un collega tramite un calendario, oltre a gestire la rendicontazione
oraria, dando la possibilità ad ognuno di segnare ora per ora il lavoro svolto nell’arco
della giornata. In questo modo, è possibile verificare il corretto conseguimento
degli obiettivi stabiliti per lo sviluppo di un prodotto, oltre al rispetto delle relative
scadenze.
Il software fornisce ulteriori funzionalità, come la gestione delle diverse sale riunioni,
permettendo di verificarne la disponibilità ed eventualmente prenotarle.
1.4 Metodologia di sviluppo
Il team non adotta un metodo di sviluppo ben preciso: vorrebbe infatti utilizzare
un approccio Agile, seguendo il framework[g] Scrum, ma diventa difficile vista la
maggior parte dei clienti con cui collabora, i quali solitamente non riescono a gestirlo.4 CAPITOLO 1. DOMINIO AZIENDALE
Modello a cascata
Normalmente viene quindi utilizzato il modello a cascata (comunemente chiamato
Waterfall model ), il quale segue il modello di sviluppo tradizionale: il progetto viene
suddiviso in più fasi sequenziali senza possibilità di modifica del prodotto delle fasi
precedenti. Le fasi in questione sono le seguenti:
• Analisi dei requisiti, dove viene stabilito cosa farà il sistema sulla base
delle richieste da parte del cliente;
• Progetto, dove viene stabilito come il sistema soddisferà i requisiti preceden-
temente analizzati;
• Sviluppo, dove viene effettivamente realizzato il sistema con il supporto dei
linguaggi di programmazione;
• Collaudo, dove vengono eseguiti test di supporto che verifichino la correttezza
del sistema rispetto ai requisiti prestabiliti;
• Manutenzione, successiva alla consegna del prodotto, prevede il migliora-
mento del sistema e l’eventuale correzione di errori.
Si tratta del primo modello adottato nello sviluppo del software, ancora in uso
nelle più tradizionali industrie (motivo per cui è più adatto ai clienti di M31),
mentre è stato progressivamente abbandonato dall’industria software a favore della
metodologia Agile.
Figura 1.2: Rappresentazione del modello a cascata
Fonte: Wikimedia.org1.4. METODOLOGIA DI SVILUPPO 5
Metodologia Agile
Internamente, in particolare nella fase di sviluppo, viene invece adottata la metodo-
logia Agile, nata a partire dagli anni 2000 in seguito al Manifesto Agile1 , il quale
riassume i principi fondamentali da seguire:
• 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.
In particolare, il framework adottato è Scrum, la cui gestione del ciclo di sviluppo
del software può essere riassunta come in figura 1.3. Lo sviluppo viene diviso in più
iterazioni, chiamate sprint, di durata fissa (compresa tra una e quattro settimane),
che stabiliscono di volta in volta la base di sviluppo su cui effettuare le successive
iterazioni. Precedentemente ad ogni sprint viene organizzato un meeting (lo sprint
planning meeting) durante il quale vengono definite le funzionalità che dovranno
essere implementate sulla base dei requisiti definiti nel cosiddetto product backlog.
Tali funzionalità formano lo sprint backlog e possono essere stabilite dal team di
sviluppo, a seconda di ciò che ritengono di riuscire ad implementare nella fase
successiva, e devono essere contestualmente approvate dal Product Owner, che
rappresenta gli stakeholder[g] del progetto; una volta definite, non potranno più
essere modificate.
Infine, ogni giorno viene organizzato un meeting, chiamato daily scrum, durante il
quale tutto il team di sviluppo si riunisce per riportare i progressi raggiunti rispetto
all’ultimo incontro, evidenziando eventuali problemi riscontrati al fine di risolverli
tempestivamente.
Figura 1.3: Rappresentazione del framework Scrum
Fonte: Yanado.com
1
Manifesto Agile. url: http://agilemanifesto.org/iso/it/manifesto.html.6 CAPITOLO 1. DOMINIO AZIENDALE Nel mio caso, avendo lavorato ad un progetto interno, ho seguito il framework Scrum, con sprint della durata di una settimana, cui seguivano una revisione ed una valutazione retrospettiva e la pianificazione delle attività da svolgere nello sprint successivo. La breve durata dello sprint è stata decisa per la mia inesperienza in ambito lavorativo e per la breve durata del periodo di stage, permettendomi così di ricevere un riscontro in tempi più brevi, evitando di protrarre troppo a lungo eventuali errori di produzione.
Capitolo 2
Progetto di stage
2.1 Il progetto: Narrow Board
Lo scopo dello stage è stato la realizzazione di un’applicazione web che permette la
visualizzazione di dati provenienti da sensori di un dispositivo Internet of Things
(IoT)[g] precedentemente aggiunto, sotto forma di grafici in tempo reale o storico.
I dispositivi in questione sono stati progettati dal team hardware dell’azienda, e
contengono al loro interno diversi sensori, tra cui il sensore di temperatura, umidità,
rumore, luce ed un giroscopio. Essi, inoltre, dispongono di una batteria interna
per permetterne il funzionamento anche in assenza di altre fonti energetiche. I
dispositivi, infine, utilizzano una nuova tecnologia, denominata Narrowband Internet
of Things (NB-IoT)[g] : un protocollo di comunicazione a basso consumo in termini
energetici ed economici che permette un’ottima copertura cellulare anche all’interno
degli edifici utilizzando bande ridotte e limitando la quantità di dati trasferita.
Si tratta dunque di una tecnologia perfettamente in linea con le necessità di un
dispositivo IoT, la cui implementazione è ancora poco utilizzata: l’azienda si è
quindi trovata di fronte ad un grosso potenziale con pochi competitori, decidendo
così di investire in un prodotto analogo.
Figura 2.1: Una vista dell’applicazione Narrow Board
78 CAPITOLO 2. PROGETTO DI STAGE Inoltre, tramite l’applicazione è possibile definire delle azioni da eseguire al verificarsi di alcune condizioni. Ad esempio, è possibile far sì che, al superamento di una soglia del valore registrato dal sensore di temperatura, il dispositivo invii una email al cliente e attivi o disattivi il relè collegato alla scheda. Si tratta di un prodotto dalle grosse potenzialità, che permette facilmente di coprire una grossa fetta di mercato, dalle piccole realtà (come le singole abitazioni) fino alle piccole e medie industrie di qualunque tipo (farmaceutiche ed alimentari solo per citarne alcune). Struttura del progetto La realizzazione dell’applicazione web ha compreso lo sviluppo dei moduli front end, ovvero i moduli che stabiliscono come essa deve apparire all’utente, ma anche dei moduli di logica, che permettono l’implementazione delle pagine dinamiche, ovvero pagine il cui contenuto viene generato all’istante di caricamento a seconda dell’utente che le visualizza. Infine, è stata necessaria anche l’implementazione dei moduli back end, ovvero le API con cui l’applicazione deve interfacciarsi per richiedere i dati che si vogliono visualizzare (come, ad esempio, la lista dei dispositivi associati ad un utente e le preferenze di visualizzazione) e per svolgere alcune azioni su richiesta dell’uten- te (come l’aggiunta di un nuovo dispositivo o la dissociazione di un dispositivo precedentemente aggiunto). Vincoli temporali Lo stage è stato svolto per una durata complessiva di 320 ore, 16 in più rispetto a quelle previste dal piano di lavoro in quanto nel mese di giugno si è tenuta una fiera ad Amsterdam, denominata IoT Tech Expo, alla quale l’azienda ha partecipato presentando un prototipo del prodotto a cui ho lavorato. Ho quindi volutamente deciso di fermarmi più a lungo al fine di finalizzare i dettagli dell’applicazione. Le ore sono state effettuate nell’arco di due mesi, ovvero 8 settimane lavorative da 40 ore ciascuna (con una media di 8 ore al giorno). Gli orari effettuati coincidevano con quelli dei colleghi dell’azienda, in accordo con il responsabile risorse umane, al fine di permettermi di vivere un’esperienza il più possibile simile a quella reale lavorativa: dalle ore 9:00 alle 13:00 e dalle ore 14:00 alle 18:00. Come anticipato, prima dell’inizio dell’attività di stage ho redatto il piano di lavoro, il quale riporta la suddivisione temporale delle attività da svolgere. Si trattava comunque di una stima in quanto, vista la natura stessa dell’azienda (che adotta un approccio lavorativo fortemente dinamico), non era possibile determinare a priori il tempo necessario a raggiungere i singoli obiettivi descritti nella sezione 2.2. 2.2 Obiettivi aziendali L’azienda M31, come descritto nel capitolo 1, viene fondata a partire da un professore e da alcuni suoi studenti, quindi in ambito completamente universitario. Per questo motivo, è costantemente alla ricerca di studenti su cui investire, mantenendo un forte legame con questo ambito, consapevole dell’innovazione tecnologica a cui ciò
2.2. OBIETTIVI AZIENDALI 9
può portare vista la somiglianza nella linea di pensiero: una ricerca ed uno sviluppo
costanti.
Questo è il motivo principale per cui l’azienda accoglie studenti e neolaureati
per attività di stage e lavorative, cavalcando l’onda dell’innovazione proveniente
dall’ambito universitario.
Obiettivi minimi e massimi
Durante gli incontri antecedenti allo stage sono inoltre stati definiti gli obiettivi
minimi e massimi che dovevo raggiungere, come descritto nella tabella 2.1. Per
permettere di definire il loro grado di importanza, gli obiettivi vengono distinti
tramite un prefisso identificativo:
• OB, che indica gli obiettivi che devono essere conseguiti obbligatoriamente;
• DE, che indica gli obiettivi desiderabili;
• FA, che indica gli obiettivi facoltativi.
Obiettivo Descrizione
OB 1 Progettazione dei moduli di logica
OB 2 Progettazione dei moduli API
OB 3 Progettazione dei moduli front end
OB 4 Sviluppo dei moduli di logica
OB 5 Sviluppo dei moduli API
OB 6 Sviluppo del modulo di registrazione e autenticazione
OB 7 Sviluppo del modulo di aggiunta di un nuovo dispositivo
OB 8 Sviluppo del modulo di inserimento del metodo di pagamento
OB 9 Sviluppo del modulo di visualizzazione dei grafici relativi ai dati
registrati dal dispositivo
DE 1 Sviluppo del modulo di attivazione e disattivazione dei relè presenti
nel dispositivo
DE 2 Sviluppo del modulo di definizione di regole che automatizzino
comandi inviati al dispositivo
FA 1 Ampliamento dei moduli di logica e API per implementare la
comunicazione tra diversi dispositivi10 CAPITOLO 2. PROGETTO DI STAGE
Obiettivo Descrizione
FA 2 Ampliamento del modulo front end per permettere la definizione di
regole che automatizzino comandi inviati a dispositivi terzi
Tabella 2.1: Tracciamento degli obiettivi
2.3 Obiettivi personali
Durante l’ultimo anno del mio percorso di studi ho frequentato il corso "Start-up in
ICT" tenuto dal Professor Frezza e da Fabio D’Alessi, co-fondatori dell’azienda M31.
Grazie a questo corso ho avuto modo di vedere da vicino il mondo delle start-up,
con diversi esempi reali portati direttamente dalle loro spin-off, come Uquido e
Wearit. Il corso prevedeva inoltre la realizzazione di un progetto volto a simulare
le fasi di progettazione di una start-up, dall’individuazione del problema, fino alla
proposta di una possibile soluzione e all’indagine di mercato.
Ho quindi avuto modo di apprezzare fino in fondo l’approccio lavorativo dell’azien-
da, che corrisponde a ciò che cerco nel mondo lavorativo: la costante ricerca di
innovazione e l’utilizzo di tecnologie di ultima generazione con l’obiettivo primario
di generare prodotti innovativi per il mercato.
Nonostante avessi già puntato su questa azienda, ho comunque deciso di partecipare
all’iniziativa proposta da Assindustria Venetocentro denominata Stage-IT, dove
diverse aziende hanno proposto attività di stage su più ambiti.
Le aziende presenti all’evento erano molteplici; le più interessanti sono state:
• Moku, spin-off dell’incubatore H-FARM, con sede a Roncade, crea prodotti su
richiesta dei propri clienti, spaziando tra applicazioni web, applicazioni mobile
e sviluppo API. L’azienda ha proposto diversi progetti, che comprendevano
lo sviluppo back end o front end di un’applicazione web e lo sviluppo di
un’applicazione mobile nativa;
• H-FARM, incubatore di start-up con sede a Roncade, che proponeva lo
sviluppo di un’applicazione web per la gestione di progetti e risorse al fine di
semplificare l’attività di supervisione di un progetto. Il problema, in questo
caso, è stata la richiesta da parte loro di svolgere un’attività di stage di almeno
6 mesi, con il conseguente slittamento della laurea;
• AzzurroDigitale, giovane start-up padovana che proponeva lo sviluppo di
applicazioni web, mobile e cloud in ambito Industria 4.0. In questo caso non
ho posto ulteriore interesse in quanto le tecnologie richieste per la realizzazione
dei progetti sono abbastanza obsolete (come AngularJS, prima versione del
framework per lo sviluppo di applicazioni web, largamente soppiantato da
Angular).
Ciò nonostante, tra tutti ho trovato più interessante il progetto proposto da M31, il
quale richiedeva l’utilizzo di diverse tecnologie moderne che mi avrebbero permesso2.3. OBIETTIVI PERSONALI 11
di arricchire il mio bagaglio personale, potendo eventualmente entrare nel mondo
del lavoro con una conoscenza base delle tecnologie necessarie nell’ambito di mio
interesse, ovvero il web. Gli obiettivi che mi ero prefissato sono i seguenti:
• Lavorare ad un progetto innovativo, possibilmente in ambito IoT;
• Lavorare con un team eterogeneo e dinamico;
• Studiare ed implementare dei pattern per una buona struttura delle API;
• Studiare ed implementare un’applicazione web mediante un framework inno-
vativo.
Tutti questi obiettivi sono effettivamente stati raggiunti con la mia esperienza, della
quale mi ritengo pienamente soddisfatto.Capitolo 3
Tecnologie utilizzate
Una parte fondamentale dell’attività di stage è stata lo studio dei diversi framework
e librerie che avrei dovuto utilizzare per sviluppare l’applicazione web Narrow
Board. In questo capitolo andrò ad introdurre le tecnologie di riferimento che
ho approfondito ed utilizzato per la realizzazione dell’applicazione, fornendo una
descrizione e valutando i vantaggi e gli svantaggi rispetto ad eventuali alternative
disponibili.
3.1 Node.js
Node.js è un runtime open source[g] per JavaScript, sviluppato da Ryan Dahl e
rilasciato come prima versione a Maggio 2009. Uno dei tanti punti di forza di questo
runtime è l’essere orientato agli eventi, rendendo di fatto possibile l’esecuzione di
codice asincrono.
Questo runtime si è rivelato fin da subito rivoluzionario in quanto permette l’esecu-
zione di codice JavaScript non più solo client-side (limite invece rappresentato da
JavaScript nativo), ma anche server-side: così facendo dà la possibilità agli svilup-
patori di generare pagine dinamiche prima ancora di essere inviate al browser in uso
dall’utente. Node.js ha pertanto introdotto la possibilità di sviluppare applicazioni
web utilizzando lo stesso linguaggio di programmazione (JavaScript, per l’appunto)
sia per i moduli front end che per quelli back end, garantendo omogeneità all’interno
di uno stesso progetto.
Nel progetto di stage ho utilizzato questo runtime per lo sviluppo del modulo back
end che fornisce le API necessarie all’applicazione: il modulo in questione, come
descritto nella sezione 4.2.2, espone un indirizzo IP su cui è possibile inviare richieste
con i metodi POST, GET, PATCH e DELETE a seconda delle azioni che si vogliono
eseguire (come ad esempio l’aggiunta di un nuovo dispositivo, la dissociazione di
un dispositivo precedentemente aggiunto e la modifica delle preferenze utente). Il
runtime viene inoltre utilizzato da Angular per gestire le dipendenze e le fasi di
build e test del progetto, traducendo il codice in JavaScript nativo, permettendo
così la sua esecuzione nel browser web.
Il vantaggio nell’utilizzo di Node.js sta, come descritto sopra, nella possibilità di
sviluppare il back end di un’applicazione utilizzando lo stesso linguaggio del front
end, ovvero JavaScript. Un ulteriore beneficio è dato dalla gestione delle risorse
1314 CAPITOLO 3. TECNOLOGIE UTILIZZATE
da parte di Node.js: esso è stato infatti sviluppato per processi single thread, al
contrario delle alternative disponibili, con notevoli vantaggi nella gestione della
memoria, la quale viene occupata in quantità minore a parità di richieste gestite.
Alcune alternative a di Node.js sono:
• Ruby, un linguaggio di programmazione open source sviluppato da Yukihiro
Matsumoto e rilasciato nella sua prima versione nel 1993. Si tratta di un
linguaggio di programmazione orientato agli oggetti, ma con un’impronta
molto diversa rispetto ai comuni linguaggi di programmazione utilizzati (quali
C++, TypeScript, ecc), in quanto cambia il concetto di oggetto, che può
variare anche durante l’esecuzione del programma. Il suo utilizzo avrebbe
quindi richiesto non poco studio preliminare, motivo per cui è stato deciso di
scartarlo;
• Go, un linguaggio di programmazione moderno e open source sviluppato da
Google e rilasciato nel 2009, in forte diffusione negli ultimi anni. Si tratta
però di un linguaggio ancora poco usato e carente in termini di librerie e
documentazione: per questo motivo è stato deciso di non utilizzarlo.
In seguito ad un’attenta analisi delle alternative sopra descritte, e tenendo conto
della mia conoscenza preliminare allo stage di Node.js, abbiamo deciso, insieme al
tutor interno, l’utilizzo di quest’ultimo, con il supporto di TypeScript, linguaggio
di programmazione descritto nella sezione 3.2.
Figura 3.1: Logo del runtime Node.js
Fonte: Wikimedia.org
3.2 TypeScript
TypeScript è un linguaggio di programmazione open source sviluppato da Microsoft
e rilasciato nella sua prima versione in Ottobre 2012. Esso può essere definito un
super-set di JavaScript, in quanto il codice, nella fase di compilazione, viene tradotto
in JavaScript nativo per permetterne l’interpretazione ai browser web. La differenza
rispetto a quest’ultimo è l’introduzione del concetto di programmazione orientata
agli oggetti, comune ad altri linguaggi come Java e C++, con l’implementazione di
interfacce, classi e tipi di dato. Interessante è il fatto che qualunque programma
sviluppato in JavaScript è valido anche per TypeScript, permettendo di fatto la
portabilità verso quest’ultimo linguaggio senza sforzo alcuno.
Questo linguaggio è stato utilizzato nello sviluppo dei moduli front end e back end
dell’applicazione, in quanto rende il codice più comprensibile e meglio mantenibile
per un programmatore esterno. Inoltre, il suo utilizzo aiuta ad evitare l’introduzione
di errori nel codice come invece potrebbe succedere con JavaScript: il tutto grazie
all’introduzione della tipizzazione, che permette, ad esempio, di definire il tipo di
un parametro richiesto da un metodo.3.3. SOCKET.IO 15
Figura 3.2: Logo del linguaggio di programmazione TypeScript
Fonte: Wikimedia.org
3.3 Socket.io
Socket.io è una libreria JavaScript open source sviluppata da Guillermo Rauch e
Automattic e rilasciata a Maggio 2018, la quale implementa le funzionalità offerte
dai WebSocket, permettendo così lo sviluppo di applicazioni web in tempo reale.
La libreria è divisa in due parti: una per gestire la comunicazione lato client,
implementata dal modulo front end dell’applicazione; l’altra per la comunicazione
lato server, implementata dal modulo back end, basato su Node.js. In entrambi
i casi, viene fornita la stessa struttura API, così da evitare un’implementazione
differente nei due moduli.
La libreria è stata largamente utilizzata durante lo sviluppo del progetto per la
ricezione dei dati inviati dai sensori dei dispositivi in tempo reale, permettendo
l’implementazione dei grafici analoghi.
Alcune alternative a Socket.io sono ws e sockjs, entrambe con una struttura ed un
funzionamento molto simili, ma scartate fin da subito in quanto, considerando che
la maggior parte dei progetti sviluppati dall’azienda utilizzano questa libreria, è
stato deciso di utilizzare la stessa tecnologia a favore del team di sviluppo.
Figura 3.3: Logo della libreria Socket.io
Fonte: Medium.com
3.4 Front end
In questa sezione vengono descritte le tecnologie utilizzate nel modulo front end
dell’applicazione, ovvero la parte di codice che viene effettivamente interpretata dal
browser web al momento della richiesta di visualizzazione di una specifica pagina.
3.4.1 Angular 7
Angular è un framework open source sviluppato da Google e rilasciato inizialmente a
Settembre 2016. Precedentemente ad Angular è stato sviluppato un altro framework,
denominato AngularJS, il quale risulta attualmente inattivo per lo scarso successo e
l’elevata complessità nel suo utilizzo. Per questo motivo, Angular prese inizialmente
il nome di Angular2+ ad indicare tutte le versioni successive ad AngularJS, mentre
ora viene semplicemente chiamato Angular.16 CAPITOLO 3. TECNOLOGIE UTILIZZATE
Si tratta dunque di un framework per lo sviluppo di applicazioni web che utilizza,
oltre ai classici linguaggi HTML e CSS, il linguaggio TypeScript descritto nella
sezione 3.2. L’utilizzo di TypeScript lo rende incompatibile con AngularJS, il quale
è stato sviluppato in JavaScript.
Questo particolare framework permette lo sviluppo di applicazioni web Single Page
Application (SPA)[g] , ovvero applicazioni che rendono disponibile all’utente una sola
pagina HTML, mentre la navigazione tra i contenuti viene gestita direttamente da
JavaScript. In particolare, le applicazioni vengono gestite ed eseguite direttamente
dal browser web, evitando così lo spreco di risorse all’invio di richieste al server web
per il caricamento di una pagina.
Il framework permette inoltre la creazione di una struttura interna ben definita
e facilmente mantenibile, seguendo i principi SOLID[g] , i cosiddetti "primi cinque
principi" da seguire per un corretto sviluppo di software orientato agli oggetti.
Un esempio lampante è dato dall’introduzione del concetto di componente: esso
rappresenta infatti una porzione della pagina web che racchiude tutto il codice
necessario per rappresentare una singola funzionalità (come un menù, la navbar e
così via).
Ogni componente è suddiviso in più parti: una per definire lo stile (utilizzando CSS
o SASS); una per definire il template (utilizzando il linguaggio di markup HTML,
descritto nella sezione 3.4.6); una per definire la logica di business (utilizzando
TypeScript), ovvero quella parte che gestisce le azioni eseguite dall’utente; una, non
obbligatoria, per definire i test da eseguire sul codice relativo alla logica, al fine di
verificarne la correttezza. Per ogni componente è possibile definire un selettore che
verrà utilizzato per includerlo all’interno di altri componenti. Infine, il framework
permette la comunicazione tra i diversi componenti (come la condivisione di uno
stesso oggetto) con l’ausilio di diversi strumenti messi a disposizione, come RxJS,
descritto nella sezione 3.4.3.
Com’è facilmente intuibile, questo approccio si appoggia al primo principio SOLID,
il principio Single Responsibility Principle (SRP)[g] , il quale afferma che ogni classe
dovrebbe avere una sola responsabilità: in questo caso la classe viene rappresentata
dal componente.
La versione del framework che ho utilizzato per lo svolgimento del progetto è la 7.0.
I vantaggi nell’utilizzo di Angular sono facilmente intuibili da quanto descritto
sopra: permette infatti la definizione di una struttura facilmente mantenibile ed
un codice pulito e riutilizzabile, con la separazione delle responsabilità su più
componenti, oltre a tutti i vantaggi offerti dallo stesso JavaScript su cui si basa,
come l’implementazione di pagine dinamiche.
Alcune alternative ad Angular sono:
• React, framework open source sviluppato da Facebook ed inizialmente rila-
sciato nel 2013. Si tratta di un framework basato su JavaScript e sfrutta lo
stesso metodo di sviluppo di Angular, con il principio SPA ed il concetto di
componente;
• Vue.js, framework open source sviluppato da Evan You ed inizialmente
rilasciato nel 2014. Anche in questo caso si tratta di un framework basato su
JavaScript che utilizza il principio SPA ed il concetto di componente.3.4. FRONT END 17
Entrambe le alternative sono state scartante in quanto tutti i progetti sviluppati
dall’azienda utilizzano il framework Angular. È stato dunque deciso di continuare
con la stessa tecnologia, a favore del team di sviluppo.
Figura 3.4: Logo del framework Angular
Fonte: Wikimedia.org
3.4.2 Angular Material
Angular Material è un toolkit sviluppato dal team di Angular al fine di facilitare
lo sviluppo di applicazioni web basate sul framework Angular e che utilizzano il
Material Design, introdotto da Google nel 2014. Il toolkit è costituito nei fatti da
una serie di componenti precostruiti a disposizione dello sviluppatore, permettendo-
gli così di seguire una linea guida per lo sviluppo di applicazioni che applicano i
principi di design suggeriti da Material. Esso è un design volto a definire gli oggetti
di una pagina web come fossero materiali realmente esistenti (da cui la dicitura
"Material"), imitandone la capacità di adeguarsi alle varie situazioni, restringendosi
ed espandendosi in base alle necessità.
Una valida alternativa all’utilizzo di Angular Material è Bootstrap, un altro toolkit
progettato per definire lo stile di una pagina web. Quest’ultimo è stato scartato
in quanto Angular Material è un toolkit nativo per le applicazioni web sviluppate
in Angular, risultando quindi più appropriato. Inoltre, il design Material è gene-
ralmente preferito da parte dell’azienda, in quanto in linea con gli altri prodotti
offerti.
Figura 3.5: Logo di Material Design
Fonte: Wikimedia.org
3.4.3 RxJS
RxJS (Reactive Extensions for JavaScript) è un toolkit che permette al codice
sviluppato in JavaScript di operare su sequenze di dati in modo asincrono, facilitan-
done la gestione. Il toolkit si trova in modo predefinito in Angular a partire dalla
versione 4.0.18 CAPITOLO 3. TECNOLOGIE UTILIZZATE
Grazie a RxJS è quindi possibile implementare facilmente il design pattern Obser-
ver[g] , assente in Angular e JavaScript, trasformando qualsiasi tipo di dato definito
mediante il linguaggio TypeScript in un Subject, dando la possibilità ad attori
esterni (definiti osservatori) di rilevare in qualsiasi istante eventuali modifiche.
Nel contesto relativo al progetto di stage, il toolkit è stato ampiamente utilizzato
soprattutto per effettuare le chiamate asincrone tramite API al back end, il cui
tempo di risposta non è immediato, in quanto il programma in esecuzione si trova
fisicamente su un’altra macchina (il server aziendale).
Non sono state analizzate eventuali alternative in quando il toolkit è una dipenden-
za del framework Angular, fornendo pertanto un maggior supporto e garantendo
stabilità in caso di eventuali futuri aggiornamenti di Angular.
Figura 3.6: Logo del toolkit RxJS
Fonte: FirebaseApp.com
3.4.4 Leaflet
Leaflet è una libreria JavaScript open source sviluppata da Vladimir Agafonkin
e rilasciata a partire da Maggio 2011, la quale permette lo sviluppo di mappe
geografiche interattive. La libreria supporta la maggior parte dei browser web, in
quanto utilizza i classici linguaggi utilizzati per la programmazione web, HTML5 e
CSS3.
La libreria in questione è stata utilizzata all’interno del progetto per visualizzare
i dispositivi in base alla posizione su mappa. Le API messe a disposizione dalla
libreria hanno inoltre facilitato l’implementazione dei filtri, grazie ai quali è possibile,
una volta selezionato un filtro (temperatura o umidità), visualizzare i dispositivi
con un’icona colorata in base all’ultimo valore registrato dal sensore corrispondente.
Viene fornito un esempio in figura 3.8.
Una valida alternativa a Leaflet che ho analizzato è Google Maps, il quale è stato
scartato fin da subito in quanto impone un limite di 25.000 visualizzazioni al giorno
delle mappe presenti nelle pagine, a cui segue il pagamento di una somma ogni
1.000 visualizzazioni.
Figura 3.7: Logo della libreria Leaflet
Fonte: Wikimedia.org3.4. FRONT END 19
Figura 3.8: Esempio di implementazione delle mappe con la libreria Leaflet
3.4.5 Chart.js
Chart.js è una libreria open source sviluppata in JavaScript che semplifica l’imple-
mentazione di grafici nell’applicazione web, esponendo classi ben documentate e di
facile utilizzo per la visualizzazione di grafici di diverso tipo (lineari, a torta, ecc).
La libreria è stata utilizzata durante lo sviluppo del progetto per permettere la
visualizzazione dei dati relativi ai sensori dei dispositivi, i quali rappresentano
il fulcro del progetto. Nel particolare, sono stati implementati grafici sia per la
visualizzazione dello storico dei dati relativi ai sensori, sia per la loro visualizzazione
in tempo reale.
Un’alternativa a Chart.js che era stata inizialmente presa in considerazione è Ma-
terial Charts: si tratta di una libreria dalle funzionalità simili, ma scartata fin da
subito in quanto ancora poco matura e con scarsa documentazione di supporto per
la sua implementazione.
Figura 3.9: Logo della libreria Chart.js
Fonte: Chartjs.org20 CAPITOLO 3. TECNOLOGIE UTILIZZATE
Figura 3.10: Esempio di implementazione di un grafico con la libreria Chart.js
3.4.6 HTML5 e Sass
HTML5
HTML5 (HyperText Markup Language) è un linguaggio di markup utilizzato per
definire il template di una pagina web, ovvero la logica strutturale del modulo
front end dell’applicazione web. Un vantaggio nell’utilizzo di Angular rispetto ad
altri framework sta nella possibilità di implementare la struttura utilizzando codice
HTML puro, separando invece la logica su file diversi. HTML è un linguaggio
supportato da tutti i browser web esistenti, con un conseguente vantaggio notevole.
Figura 3.11: Logo del linguaggio di markup HTML
Fonte: W3.org
Sass
Sass è invece un’estensione del linguaggio CSS (Cascading Style Sheets), il quale
introduce la possibilità di utilizzare variabili, funzioni e di suddividere il codice
su più file. Si tratta pertanto di un linguaggio che viene comunemente utilizzato
per definire lo stile di una pagina web. Sass può inoltre essere definito come un
preprocessore di CSS in quanto il codice, in fase di compilazione, viene tradotto in
codice CSS nativo ed ottimizzato.3.4. FRONT END 21
Figura 3.12: Logo del linguaggio di stile SCSS
Fonte: sass-lang.com
3.4.7 Jasmine
Jasmine è un framework open source di testing sviluppato per JavaScript e Ty-
peScript. Si tratta di un framework che permette l’esecuzione di test di unità
sul codice sviluppato, con lo scopo di verificarne la correttezza confrontando il
comportamento con quello atteso. Questo tipo di test è molto importante nello
sviluppo di applicazioni di medie e grandi dimensioni, in quanto rappresentano
l’unico modo per certificare la correttezza del codice: in questo tipo di progetti
risulta infatti molto difficile scovare le cause di un malfunzionamento del codice
se non attraverso l’esecuzione di test. Alcune delle funzionalità offerte da Jasmine
sono:
• Supporto all’esecuzione di test asincroni, particolarmente utile in seguito
all’implementazione di codice che utilizza il toolkit RxJS;
• Supporto all’esecuzione di test con l’ausilio dei test double, comunemente
chiamati anche mock, ovvero oggetti creati staticamente che simulano oggetti
reali presenti all’interno dell’applicazione web quando è in esecuzione. I test
double sono particolarmente utili per simulare oggetti creati in seguito ad
una chiamata al back end, come ad esempio le informazioni relative ad un
dispositivo;
• Supporto all’esecuzione di test sul codice relativo al template delle pagine
web, utilizzando un’estensione denominata Jasmine-jQuery.
Jasmine è il framework di testing presente in modo predefinito in Angular. Per
questo motivo, come nel caso di RxJS, si è deciso di utilizzarlo per il maggior
supporto fornito e per la garanzia di un suo corretto funzionamento in caso di futuri
aggiornamenti di Angular.
Il framework è stato tuttavia scelto solamente per l’esecuzione dei testi nei moduli
front end. mentre per il back end si è deciso di utilizzare Jest, framework che non
ho avuto modo di approfondire in quanto lo sviluppo dei test nei moduli back end
non era di mia competenza.
Purtroppo non ho avuto modo di approfondire l’argomento e sviluppare i test di
unità durante l’attività di stage a causa del poco tempo a disposizione.22 CAPITOLO 3. TECNOLOGIE UTILIZZATE
Figura 3.13: Logo del framework di testing Jasmine
Fonte: Wikimedia.org
3.5 Back end
In questa sezione vengono descritte le tecnologie utilizzate nel modulo back end
dell’applicazione, ovvero la parte di codice che gestisce la logica ed espone le API
attraverso le quali il modulo front end si deve interfacciare per richiedere i dati che
si vogliono visualizzare in una determinata pagina web.
Le tecnologie maggiormente utilizzate per lo sviluppo del modulo back end sono
state Node.js, descritta nella sezione 3.1, e Socket.io, descritto nella sezione 3.3.
3.5.1 Express
Express.js (comunemente chiamato Express) è un framework open source sviluppato
da TJ Holowaychuk, StrongLoop ed altri e rilasciato a partire da Novembre 2010.
Viene utilizzato per lo sviluppo di applicazioni web che utilizzano il runtime Node.js.
Si tratta infatti di una sua estensione, spesso utilizzata per lo sviluppo del back
end di un’applicazione web per definire gli endpoint[g] delle API. Questo particolare
framework è stato ormai definito uno standard per lo sviluppo di applicazioni web
con Node.js.
In questo progetto Express è stato utilizzato proprio per definire le routing delle
API del modulo back end, ovvero gli endpoint attraverso i quali vengono inviate
richieste a fronte dell’esecuzione di una particolare azione da parte dell’utente, come
la dissociazione di un dispositivo precedentemente aggiunto.
Il progetto prevedeva, tra le altre cose, che il dispositivo potesse essere utilizzato
anche senza l’ausilio dell’applicazione web, permettendo l’utilizzo delle API per
definire eventualmente un’interfaccia proprietaria. Per questo motivo, è stata
necessaria la definizione di una struttura che fosse il più possibile "atomica", ovvero
che fornisse degli endpoint utilizzabili in qualunque contesto.
Ad oggi le alternative al framework Express non sono molte: si tratta infatti di
framework troppo acerbi nello sviluppo o con una documentazione poco esaustiva.
Non sono pertanto stati analizzati vantaggi e svantaggi rispetto ad essi.
Figura 3.14: Logo del framework Express
Fonte: GitHub.com3.6. TECNOLOGIE DI SUPPORTO 23
3.6 Tecnologie di supporto
In questa sezione vengono descritte le tecnologie di supporto utilizzate per lo
sviluppo del progetto Narrow Board, tra cui le tecnologie necessarie per lo sviluppo
all’interno di un team, come Git e GitLab, e per la simulazione del contesto
all’interno del quale viene eseguito il codice, come Docker.
3.6.1 Docker
Docker è un sistema open source sviluppato da Docker Inc e rilasciato nel 2013,
volto ad automatizzare il deployment, vale a dire la consegna ed il rilascio di
un’applicazione o un software all’interno di un sistema informatico aziendale. In
particolare, Docker automatizza il deployment fornendo un sistema di virtualizzazio-
ne del sistema, simulando l’ambiente Linux (basandosi sul kernel Linux) qualunque
sia il sistema operativo presente nella macchina, senza la necessità di istanziare
una macchina virtuale. Così facendo, tutti i membri del team di sviluppo possono
eseguire l’applicazione o software direttamente nel proprio computer, qualunque
siano le sue caratteristiche, simulando di fatto l’ambiente reale dove verrà realmente
rilasciato.
Docker basa il suo modo di operare sul concetto di container[g] : mentre le macchi-
ne virtuali vengono create per virtualizzare i server hardware, allo stesso modo i
container vengono creati per virtualizzare il sistema operativo installato nel ser-
ver. I container, infatti, sono isolati tra loro e contengono al loro interno tutti i
software, le librerie ed i file di configurazione necessari per una corretta esecuzione
del programma. Essi vengono creati a partire da un file, chiamato Dockerfile, dove
vengono specificate le configurazioni necessarie per l’esecuzione, rendendoli di fatto
molto più leggeri rispetto ad un’immagine di una macchina virtuale, la quale deve
contenere anche il sistema operativo.
Questo particolare sistema, grazie alle sue caratteristiche che lo rendono di semplice
utilizzo e molto performante, permette una distribuzione più rapida del software,
ottimizzando in termini di tempo eventuali trasferimenti di applicazioni e software
da un server all’altro (e da un sistema operativo all’altro) e standardizzando l’am-
biente di sviluppo dei produttori, qualunque sia il computer che essi utilizzano.
Per i motivi sopra descritti, l’azienda M31 utilizza questo sistema per gestire tutti
i suoi progetti, compreso quello a cui ho lavorato. Il suo utilizzo non è risultato
particolarmente difficoltoso, permettendomi inoltre di simulare l’ambiente nel quale
il prodotto doveva essere rilasciato, limitando le risorse disponibili (come CPU e
RAM) per verificarne le performance.
Figura 3.15: Logo del sistema di deployment Docker
Fonte: Docker.com24 CAPITOLO 3. TECNOLOGIE UTILIZZATE
3.6.2 Kubernetes
Kubernetes è un software open source sviluppato inizialmente da Google e mantenuto
da Cloud Native Computing Foundation, il cui scopo è permettere la distribuzione
e la gestione di applicazioni sotto forma di container in modo scalabile. Grazie
a questo software è infatti possibile generare e distruggere automaticamente più
istanze di una stessa applicazione o software in base al carico di utenti in un
dato istante, evitando così di sovraccaricare una singola istanza a discapito della
UX (User Experience) dell’utente. Così facendo, una volta che l’utente accede
all’applicazione web tramite browser web, esso viene automaticamente reindirizzato
all’istanza meno sovraccaricata e con latenza più bassa, sfruttando il principio del
load balancing (ovvero il bilanciamento del carico).
Il software permette la gestione di diversi tipi di container, tra cui quelli di Docker,
descritti nella sezione 3.6.1.
L’azienda utilizza questo software per la gestione di tutte le applicazioni web da
loro prodotte, compresa quindi la piattaforma Narrow Board a cui ho lavorato.
Per questo motivo, non sono state analizzate eventuali alternative, mantenendo
continuità con gli altri progetti.
Figura 3.16: Logo del sistema di orchestrazione Kubernetes
Fonte: Kubernetes.io
3.6.3 Git e GitLab
Git
Git è un software open source di controllo versione distribuito, sviluppato da Linus
Torvalds (ovvero il fondatore di Linux) e rilasciato nella sua prima versione a
partire da Aprile 2005. Si tratta del sistema di versionamento più diffuso nel
mondo. Esso viene utilizzato principalmente da interfaccia a riga di comando, ma
esistono anche diversi software di terze parti che hanno implementato un’interfaccia
semplificandone il suo utilizzo (come Sourcetree e GitKraken). Git, come tutti i
software di controllo versione presenti sul mercato, basa il suo utilizzo sul concetto
di repository, che può essere definito come un ambiente all’interno del quale vengono
immagazzinati i metadati che possono essere recuperati ed aggiornati da chiunque
ne abbia accesso. Infatti, il grande potenziale dei software di controllo versione
sta nella possibilità di tenere traccia delle modifiche effettuate ad un insieme di
file, dando la possibilità di ripristinare versioni precedenti e di aggiornare l’ultima
versione tramite commit con un messaggio che introduce i cambiamenti effettuati.
In un team di sviluppo software come Git permettono di collaborare in modo
efficiente al codice di uno stesso progetto, facilitando la condivisione di commenti e
documentazione oltre all’individuazione e la risoluzione di eventuali conflitti. Al
giorno d’oggi, la quasi totalità delle aziende che hanno un team di sviluppo utilizza
Git, compresa M31.3.6. TECNOLOGIE DI SUPPORTO 25
Figura 3.17: Logo del sistema di controllo di versione Git
Fonte: git-scm.com
GitLab
GitLab è una piattaforma web open source sviluppata da GitLab Inc e rilasciata nel
2011. Essa permette la gestione di repository che utilizzano il software di controllo
di versione Git, dando la possibilità di creare repository pubblici, quindi visibili da
chiunque, o privati, condividendoli con il proprio team di sviluppo. Come descritto
sopra, in questi repository è possibile caricare le proprie modifiche e visualizzare
quelle effettuate dagli altri membri del team.
GitLab può dunque essere immaginata come la piattaforma contenente i repository
relativi ai propri progetti, disponibili online, e quindi accessibili attraverso la rete
da chiunque abbia l’accesso.
Nel particolare, l’azienda M31 utilizza un server locale di sua proprietà su cui è stata
installata la piattaforma GitLab, rendendo così possibile un controllo completo sugli
accessi ai repository dei vari progetti, oltre ad assicurarsi l’accesso anche qualora si
verificassero problemi di connessione.
Figura 3.18: Logo della piattaforma GitLab
Fonte: GitLab.comPuoi anche leggere
