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
Sviluppo di un motore di statistiche e di un
chatbot per monitorare account Instagram
Tesi di laurea triennale
Relatore
Prof.Tullio Vardanega
Laureando
Tommaso Panozzo
Anno Accademico 2017-2018
Tommaso Panozzo: Sviluppo di un motore di statistiche e di un chatbot per monitorare account Instagram, Tesi di laurea triennale, c Dicembre 2017.
Indice
1 Azienda Ospitante 1
1.1 Struttura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1.1 Reparti Tecnici . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Rapporto con l’Innovazione . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Prodotti dell’Area Sviluppo . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Tecnologie Utilizzate . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.5 Gestione di Progetto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2 Progetti di Stage nella Strategia Aziendale 7
2.1 Miriade e i rapporti con l’università . . . . . . . . . . . . . . . . . . . 7
2.2 Proposte di Stage 2017/2018 . . . . . . . . . . . . . . . . . . . . . . . 8
2.3 Proposta di Stage Scelta . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3.1 Obiettivi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.2 Vincoli . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3 Svolgimento del Progetto 13
3.1 Studio delle Piattaforme . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1.1 Caratteristiche delle API di Instagram . . . . . . . . . . . . . . 13
3.1.2 Caratteristiche delle Bot API di Telegram . . . . . . . . . . . . 14
3.1.3 Definizione dei casi d’uso del prodotto . . . . . . . . . . . . . . 15
3.2 Analisi dei requisiti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2.1 Scopo del prodotto . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2.2 Attori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.3 Casi d’uso salienti . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.3 Architettura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.3.1 Business Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.3.2 Persistenza dei Dati . . . . . . . . . . . . . . . . . . . . . . . . 23
3.3.3 Front end . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.4 Progettazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.4.1 Spring Boot e Maven . . . . . . . . . . . . . . . . . . . . . . . . 25
3.4.2 Struttura del codice di routing dei comandi del bot . . . . . . . 26
3.4.3 Gestione di Utenti con Diversa Autenticazione . . . . . . . . . 28
3.4.4 Instagram Subscriptions . . . . . . . . . . . . . . . . . . . . . . 28
3.4.5 Design del Cron . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.4.6 Internazionalizzazione del Bot . . . . . . . . . . . . . . . . . . . 30
3.4.7 Log Unificati . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.5 Verifica e Validazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.6 Prodotto Finale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
iii
iv INDICE
4 Valutazioni Retrospettive 37
4.1 Raggiungimento degli Obiettivi . . . . . . . . . . . . . . . . . . . . . . 37
4.1.1 Obiettivi Aziendali . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.1.2 Obiettivi Personali . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.2 Bilancio Formativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.3 Valutazioni Personali . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.3.1 Preparazione del Corso di Laurea al Lavoro . . . . . . . . . . . 41
Bibliografia 43
Elenco delle figure
1.1 Logo di Miriade S.p.A. . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Reparti Tecnici di Miriade . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Funzionamento di un bot . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4 Logo di Spring by Pivotal e Apache Maven . . . . . . . . . . . . . . . 5
1.5 Principi Agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.6 Logo di Jira e Bitbucket . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1 Esemplificazione del funzionamento di un bot. . . . . . . . . . . . . . . 8
3.1 Principali metodi di input dei comandi del chatbot . . . . . . . . . . . 14
3.2 Mockup del Prodotto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3 Mockup Instagram Top Popular . . . . . . . . . . . . . . . . . . . . . . 17
3.4 Tipologie di Utenti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.5 Use Case Principali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.6 Logo di PostgreSQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.7 Prodotti di Google Cloud Platform. url: https://cloud.google.com 25
3.8 Parte del Package Instagram della Business Logic . . . . . . . . . . . . 29
3.9 Workflow del post per gli utenti autenticati . . . . . . . . . . . . . . . 29
3.10 Workflow del post per gli utenti non autenticati . . . . . . . . . . . . . 30
3.11 Console di Gestione del Cron di GCP . . . . . . . . . . . . . . . . . . 31
3.12 Console di Controllo dei Log di GCP . . . . . . . . . . . . . . . . . . . 32
3.13 Schema TDD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.14 Screenshot delle schermate di avvio ed autenticazione . . . . . . . . . 34
3.15 Screenshot delle schermate di performance di account e singolo post . 34
3.16 Screenshot della schermata di suggerimento dell’orario per pubblicare 35
3.17 Screenshot della schermata di download di un media . . . . . . . . . . 35
v
vi ELENCO DELLE TABELLE
Elenco delle tabelle
2.1 Piano di Lavoro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1 Comparazione Database Considerati . . . . . . . . . . . . . . . . . . . 24
4.1 Raggiungimento degli Obiettivi Aziendali . . . . . . . . . . . . . . . . 37
4.1 Raggiungimento degli Obiettivi Aziendali . . . . . . . . . . . . . . . . 38
4.2 Realizzazione delle Funzionalità Applicative Obbligatorie . . . . . . . 38
4.2 Realizzazione delle Funzionalità Applicative Obbligatorie . . . . . . . 39
4.3 Realizzazione delle Funzionalità Applicative Opzionali . . . . . . . . . 39
4.4 Raggiungimento degli Obiettivi Personali . . . . . . . . . . . . . . . . 39
4.4 Raggiungimento degli Obiettivi Personali . . . . . . . . . . . . . . . . 40
Capitolo 1
Azienda Ospitante
1.1 Struttura
Figura 1.1: Logo di Miriade S.p.A.
Miriade1 è un’azienda di consulenza informatica nata nel 2000 a Caldogno, in
provincia di Vicenza; attualmente occupa 2 sedi: Thiene, la principale, e Padova.
Entro il primo trimestre del 2018 ne aprirà un’altra a Milano.
Conta approssimativamente 50 dipendenti divisi tra amministrazione e 5 reparti tecnici.
Miriade S.p.A. è divisa in due settori: amministrativo e tecnico. Del reparto
amministrativo fanno parte l’ufficio legale, l’ufficio acquisti, i back e front office, l’ufficio
paghe, i commerciali e l’ufficio marketing. Per quanto riguarda gli uffici tecnici, Miriade
ha un 5 divisioni: il loro numero è elevato, se si considerano quelle presenti nelle aziende
di pari dimensioni. Questo la rende maggiormente appetibile per clienti con progetti
che necessitino di prodotti completi e che attraversino diversi ambiti.
1.1.1 Reparti Tecnici
I reparti tecnici e le loro principali occupazioni sono:
∗ Sviluppo si occupa dello sviluppo di applicazioni on demand (sia web sia mobile),
di portali aziendali (tipicamente B2B o intranet) e dello sviluppo di integrazioni
1 Miriade S.p.A.. url: http://www.miriade.it.
1
2 CAPITOLO 1. AZIENDA OSPITANTE
tra sistemi già esistenti (utile per chi volesse estendere un prodotto giunto a fine
vita o per l’affinamento di prodotti realizzati in casa dal cliente);
∗ Servizi Cloud si occupa di creare ambienti cloud nuovi o di migrare sistemi
esistenti on premise;
∗ Database Administration DBA si occupa di installazione, migrazione, gestione
di database dei clienti (sia SQL che noSQL);
∗ Big Data è la divisione più recente e si occupa di analisi di big data: dalla
creazione di cluster (principalmente Hadoop2 ) allo sviluppo di modelli predittivi
di machine learning3 ;
∗ Servizi Sistemistici si occupa di installare, configurare e gestire presso il cliente
soluzioni di networking, virtualizzazione, antivirus, storage, nonché di soddisfare
le esigenze aziendali in termini di hardware e configurazioni;
∗ Business Intelligence BI si occupa della creazione di datawarehouse (archivi
di dati interni all’azienda, utili per analisi di profitti e per prendere decisioni
sulla strategia dell’azienda), caricando dati da fonti eterogenee e della creazione
di dashboard di reportistica.
Figura 1.2: Reparti Tecnici di Miriade
Miriade è partner di due dei più importanti e innovativi provider di servizi cloud:
Amazon (con Amazon Web Services [g] ) e Google (con Google Cloud Platform [g] ); questa
partnership viene spesa soprattutto nei reparti sviluppo e servizi cloud, Big Data e
sistemistico.
2 Hadoop è un framework per consentire l’elaborazione dati in parallelo di grandi quantità di dati.
I cluster Hadoop sono costituiti da numerosi nodi che si occupano ciascuno di una porzione ridotta di
dati.
3 I modelli di machine learning sono modelli matematici che, ricevendo un insieme di dati in input,
forniscono un output che sia coerente con dei pattern appresi in una precedente fase di training.
Questi modelli vengono spesso allenati su un gran numero di osservazioni per poi essere utilizzati per
effettuare previsioni. Chiariamo con un esempio. Si potrebbe allenare un modello fornendo in input
sia i valori di pressione e umidità di alcune stazioni metereologiche di una zona che un valore booleano
che indica se il giorno seguente alle misurazioni ha piovuto o meno; in un secondo momento si potrebbe
chiedere al modello di prevedere la possibilità di pioggià per l’indomani, considerati in input i valori di
pressione ed umidità attuali. Ovviamente l’accuratezza di tali modelli cresce all’aumentare del numero
di dati di allenamento (e test) e all’aumentare della correlazione tra grandezze in input e in output.
1.2. RAPPORTO CON L’INNOVAZIONE 3
(a) Logo AWS (b) Logo GCP
1.2 Rapporto con l’Innovazione
Nonostante l’innovazione non sia gratuita (la formazione e l’ambientamento dei tecnici
con le nuove tecnologie hanno infatti un costo temporale non trascurabile), essa è al
centro della strategia aziendale di Miriade; la società è infatti in costante ricerca delle
novità e delle nuove tendenze in fatto di prodotti, strumenti e piattaforme. Un esempio
è dato dai numerosi prodotti creati con i Beacon Bluetooth[g] (tecnologia che permette
la micro-localizzazione dei dispositivi mobili attraverso piccoli dispositivi bluetooth che
trasmettono un indentificativo univoco nel raggio di pochi metri); un altro esempio è
dato dall’interesse che Miriade ha manifestato da subito nell’ambito dei chatbot, che
cominciano ad essere sempre più in voga.
Figura 1.3: Funzionamento di un bot
Nel reparto Sviluppo questa filosofia di rinnovamento costante è abbracciata da
tutti i dipendenti ed è messa in evidenza dalle frequenti discussioni sulle novità in
fatto di framework/prodotti da utilizzare, dalla propensione alla formazione continua
nonché dall’apertura all’adozione di nuovi framework/tecnologie proposti da membri
del gruppo. Tuttavia, non è sufficiente che i soli reparti tecnici desiderino innovare: è
fondamentale anche l’atteggiamento del titolare e degli altri commerciali, che stimolano
i clienti a scegliere soluzioni moderne e innovative. La reputazione che si è creata
Miriade nel tempo è quella di un’azienda che sa suggerire al cliente soluzioni nuove a
problemi che egli stesso non aveva compreso appieno, spesso sfruttando le numerose
competenze derivanti dalla stretta collaborazione dei 5 reparti tecnici (si vedano i reparti
tecnici). Questo modus operandi consente di realizzare prodotti ad ampio spettro; due
esempi possono essere modelli predittivi di machine learning che monitorano la linea
di produzione attraverso dispositivi IoT e interagiscono con l’utente attraverso chatbot
ed estensioni per applicativi di reportistica nell’ambito della Business Intelligence.
Uno stimolo spontaneo all’innovazione è dato dall’interazione con i tecnici degli altri
reparti nei momenti di pausa o nelle chat, email o post nel social network interno. La4 CAPITOLO 1. AZIENDA OSPITANTE
propensione allo scambio di competenze è ben radicata nei dipendenti: in fase di analisi
e progettazione sono numerosi i confronti e le interazioni tra i vari reparti. Nella fase di
progettazione della mia esperienza di stage, ad esempio, nonostante io appartenessi al
reparto Sviluppo non è mancato il confronto con alcuni tecnici Big Data per la scelta
delle tecnologie di storage più appropriate, con tecnici DBA per discutere la struttura
del database e con i sistemisti per valutare l’opzione più conveniente per effettuare il
deployment del sistema.
Miriade investe molto sulla formazione: quasi tutti i dipendenti dell’area tecnica
conseguono una certificazione all’anno, che verrà poi esposta con orgoglio nella sede
principale. Queste certificazioni consentono a Miriade di essere partner di aziende
leader come Amazon AWS, Google Cloud Platform, Nutanix, Trifacta, Qlik e altri.
1.3 Prodotti dell’Area Sviluppo
Alcuni dei prodotti dell’area sviluppo sono:
∗ applicazioni on demand web e mobile per clienti esterni;
∗ consulenze (ad esempio riguardanti la migrazione di applicazioni che girano on
premise verso qualche servizio cloud) e formazione su alcuni framework specifici
(come Liferay o Spring);
∗ definizione di user experience e user interface dei prodotti;
∗ sviluppo di portali aziendali (per lo più B2B4 e interni all’azienda);
∗ componenti necessarie a prodotti di altri reparti interni (come script/funzioni
periodiche di collezione dati da iniettare in dataset di Big Data);
∗ strumenti per la gestione interna (ad esempio il portale per l’inserimento dei
rapportini);
∗ applicazioni non commissionate da clienti esterni ma proposte dai dipendenti.
1.4 Tecnologie Utilizzate
Per lo sviluppo di applicazioni web si adotta principalmente Java e si fa uso in
maniera estensiva di Spring. Quest’ultimo è un framework che facilita lo sviluppo di
applicativi (in particolare web app) grazie a: numerosi package avanzati (come quelli
per interfacciarsi con DB SQL e NoSQL), l’incentivo ad adottare buone pratiche di
programmazione (una su tutte la Dependency Injection) ed alcuni vantaggi pratici che
riducono il tempo necessario al deployment (come la possibilità di creare facilmente
4 B2B è l’acronimo di Business To Business e sta ad indicare i prodotti che fungono da interfaccia
tra aziende diverse; si differenzia dai prodotti B2C (Business To Customer) che, invece, collegano
un’azienda con il consumatore finale.1.5. GESTIONE DI PROGETTO 5
un’applicazione web in formato jar 5 ). Miriade si occupa anche di formazione su Spring
presso clienti. Per la gestione dei progetti Java, in particolare delle dipendenze e degli
script di compilazione, si utilizza Maven; per buona parte di essi viene utilizzato anche
Liferay, piattaforma per cui Miriade ha conseguito diverse certificazioni.
Figura 1.4: Logo di Spring by Pivotal e Apache Maven
Per il deployment delle applicazioni, ove possibile, vengono preferite le soluzioni in
cloud piuttosto che on premise.
Queste sono alcune delle tecnologie adottate, ma, come spiegato nella sezione sul
rapporto con l’innovazione, nelle fasi di analisi e progettazione, il team di sviluppo
è aperto a nuove proposte per quanto riguarda innovative e differenti tecnologie da
adottare.
1.5 Gestione di Progetto
Il team di sviluppo implementa un modello Agile: il lavoro viene diviso in sprint della
durata di 2 settimane. Durante questo periodo ciasun membro si occupa di portare a
termine i task a lui assegnati facendo progredire il progetto. La maggior parte dei task
viene stabilita ed assegnata all’inizio dello sprint (qualche aggiunta è permessa ma
perlopiù per la correzione di errori, o per imprevisti con priorità elevata); al termine
delle 2 settimane il team effettua una valutazione retrospettiva. Lo strumento utilizzato
per il tracciamento delle issue e dei task è Jira; quello per effettuare del planning e per
tracciare diagrammi di Gantt è Teamwork.
Per il versionamento del codice viene usato git, in particolare Bitbucket (su un server
privato), che si integra facilmente con Jira e permette di correlare issue o task con i
relativi commit. Nexus viene utilizzato come repository di pacchetti (perlopiù librerie
5 Il file jar è un’applicazione web standalone, l’alternativa avrebbe richiesto l’installazione e
configurazione manuali di un Web Container (come Apache Tomcat) e la creazione di file war.
Figura 1.5: Principi Agile6 CAPITOLO 1. AZIENDA OSPITANTE
interne); Bamboo (della suite di Atlassian come Jira e Bitbucket) viene utilizzato in
alcuni progetti per gestire CI e CD6 .
Figura 1.6: Logo di Jira e Bitbucket
6 CI sta per Continuous Integration mentre CD per Continuous Deployment e indicano sistemi
automatizzati di compilazione, test e deployment del codice al fine di ridurre al minimo il lavoro da
effettuare ad ogni rilascio per aumentare quindi la frequenza di deployment di nuove versioni.Capitolo 2
Progetti di Stage nella Strategia
Aziendale
2.1 Miriade e i rapporti con l’università
I motivi principali per cui Miriade partecipa all’evento StageIT e propone dei progetti
di stage a studenti laureandi sono principalmente due:
∗ avviare, proseguire o completare progetti che rischiano di bloccarsi per mancanza
di tempo delle risorse interne;
∗ valutare nuovi elementi da inserire eventualmente in organico.
Va precisato che l’area sviluppo non è la sola ad aderire ad iniziative simili: anche i
reparti DBA, BI e Big Data partecipano ad eventi dell’Università di Padova e accettano
stagisti.
La collaborazione con l’Università di Padova è motivo d’orgoglio per Miriade, la
quale, infatti, oltre a partecipare all’evento StageIT, nell’anno didattico 2016/17 è stata
azienda proponente di un capitolato d’appalto del corso di Ingegneria del Software
e due dei suoi dipendenti hanno tenuto un seminario tecnologico dedicato ai Beacon
Bluetooth1 .
1 I Beacon sono dei piccoli dispositivi che attraverso la tecnologia Bluetooth a bassa energia (BLE)
trasmettono in broadcast un codice identificativo univoco (UUID) settabile dal programmatore. I
dispositivi mobili possono sfruttare l’univocità di questo codice e, per alcuni scopi, l’intensità del
segnale al fine di localizzare l’utente in uno spazio ristretto.
78 CAPITOLO 2. PROGETTI DI STAGE NELLA STRATEGIA AZIENDALE
2.2 Proposte di Stage 2017/2018
∗ Un primo progetto chiedeva allo stagista di svolgere un’analisi delle modalità di
integrazione di un bot di una delle principali piattaforme di comunicazione (Sky-
pe, Messenger, Telegram, WhatsApp) e di implementarne uno che permettesse
l’interazione degli utenti con alcuni social network, in particolar modo Insta-
gram. Allo stagista erano richiesti anche l’esplorazione e l’utilizzo dei framework
disponibili per la creazione di chatbot.
∗ Una seconda proposta verteva sullo studio delle API di Amazon AWS e Google
Cloud Platform e sulla realizzazione di una console unificata, semplice ed intuitiva
da usare, per la gestione dei backup dei dischi connessi alle istanze attive presso
ciascuno dei due provider. Tale console consiste di un portale web a cui l’utente
finale possa collegare i propri account AWS e GCP per gestire in maniera
trasparente le istanze.
∗ Il terzo progetto consisteva nello sviluppo di un’estensione per il prodotto di
reportistica Qlik Sense (un applicativo per la raccolta e la visualizzazione di dati
aziendali, utile per analisi di Business Intelligence e per prendere decisioni di
strategia aziendale). In particolare, allo stagista era proposto di lavorare con i
tool a disposizione nell’ambiente di Qlik Sense per l’estensione delle dashboard
al fine di realizzare un plugin che mettesse a disposizione dell’utente un set di
report più efficace e personalizzabile di quello fornito out-of-the-box.
Figura 2.1: Esemplificazione del funzionamento di un bot.
2.3 Proposta di Stage Scelta
Ho scelto il primo dei progetti di stage proposti da Miriade (si veda la sezione precedente
§2.2). Le principali motivazioni che mi hanno spinto a chiedere a Miriade di potermi
dedicare a questo particolare progetto sono le seguenti:
∗ Interesse personale verso i Chatbot. Il fenomeno dei chatbot (finti utenti di
piattaforme di messaggistica che sono in realtà applicativi software) mi incuriosisce
da qualche anno: essi rappresentano infatti un nuovo paradigma di interfaccia
utente molto differente da quelli tradizionali (web app, app native o altro) e per
molti aspetti simile ad un’interfaccia da riga di comando (seppur più amichevole).
I chatbot, infatti:
– necessitano di un minor impiego di risorse per lo sviluppo di un’interfaccia
utente;2.3. PROPOSTA DI STAGE SCELTA 9
– non necessitano di installazione nei device degli utenti (che sono spesso restii
a scaricare nuove applicazioni a causa di consumo di dati e memoria nel
dispositivo);
– vengono percepiti come app native (e non web);
– sono multipiattaforma senza alcuno sforzo di sviluppo (almeno in tutte le
piattaforme in cui l’applicazione di messaggistica viene distribuita).
∗ Opportunità di approfondire API di prodotti leader. La connessione con
piattaforme esterne è un’esigenza comune alla maggior parte delle applicazioni
moderne.
Dovermi interfacciare e dover studiare le API di due piattaforme leader come
Telegram e Instagram è stata un’ottima occasione per capire come si implementino
questi servizi connessi. Ad esempio:
– entrambi i servizi espongono delle API RESTful (l’architettura più popolare
e comune per comunicare con i web service2 );
– Instagram richiede di effetturare l’autenticazione con il protocollo OAuth
2.0, molto diffuso e considerato tra i più sicuri sistemi di autenticazione;
– Instagram consente di indicare un indirizzo per creare un webhook, in modo
da notificare il proprio web service ogni volta che un utente autenticato
pubblica un’immagine (Instagram effettua una chiamata POST con il
contenuto all’endpoint specificato).
∗ Opportunità di implementare un’architettura moderna. La natura stan-
dalone del progetto (che non è un’estensione di un prodotto esistente) e la libertà
lasciatami dal proponente riguardo alle tecnologie da utilizzare permettono di
studiare le moderne soluzioni di back end (ad esempio soluzioni serverless, basate
su servizi di terze parti che si occupano di effettuare la manutenzione necessaria
sui server) e di implementare un’architettura moderna.
2.3.1 Obiettivi
Obiettivi aziendali
L’obiettivo principale del mio stage era quello di sviluppare un bot per una piattaforma
di messaggistica che fornisse servizi utili per gli utenti di Instagram desiderosi di
migliorare le prestazioni del proprio account. Le attività da svolgere durante il periodo
di stage sono riassunte nel seguente piano di lavoro:
2 I web service sono componenti di un sistema che consentono l’interazione con applicativi terzi;
ad esempio i web service delle Bot API di Telegram espongono le funzioni che i bot possono
eseguire (inviare messaggi, ricevere aggiornamenti, . . . ), mentre i web service di Instagram consentono
interrogazioni al database di Instagram (richiedere il numero di follower di un dato utente, la sua foto
profilo, . . . ).10 CAPITOLO 2. PROGETTI DI STAGE NELLA STRATEGIA AZIENDALE
Tabella 2.1: Piano di Lavoro
Attività Ore di lavoro
Studio di Java e Spring 40
Studio API Telegram e Instagram 32
Studio GCP e AWS e scelta stack tecnologico 16
Progettazione del prodotto 16
Sviluppo connettore Instagram 40
Sviluppo connettore Telegram 40
Sviluppo core 40
Definizione funzionalità aggiuntive 8
Sviluppo funzionalità aggiuntive 72
(a) Logo Instagram (b) Logo Telegram
Obiettivi Personali
Gli obiettivi personali che mi sono posto per lo stage sono stati:
∗ la realizzazione del prodotto richiesto dall’azienda;
∗ lo studio approfondito della struttura di un back end moderno e la sua imple-
mentazione;
∗ l’inserimento in un team di sviluppo stimolante;
∗ l’adottare un’attitudine propositiva e una propensione alla collaborazione;
∗ l’approfondimento della metodologia agile by doing;
∗ l’eventuale inserimento in azienda dopo la laurea.
In particolare, oltre al soddisfacimento dell’obiettivo aziendale di realizzare un
prodotto funzionante, volevo sfruttare l’opportunità e la predisposizione di Miriade alla
sperimentazione di nuove tecnologie per realizzare un’architettura moderna, magari
serverless. Già in fase preliminare mi era chiaro che tale obiettivo avrebbe comportato
un maggior impiego di ore nelle fasi di studio, di progettazione e probabilmente anche2.3. PROPOSTA DI STAGE SCELTA 11
di codifica (a causa della minor conoscenza dei nuovi strumenti) e che questo avrebbe
diminuito l’efficacia del mio lavoro sul progetto. Il tutor aziendale ha però valutato
che ciò non sarebbe stato un problema e che l’adozione delle tecnologie individuate
sarebbe stata compatibile con la realizzazione del progetto.
2.3.2 Vincoli
Vincoli temporali
La durata dello stage è stata di 8 settimane (320 ore), da svolgersi tutte presso la sede
principale, a Thiene, e seguendo gli orari dei dipendenti: 9:00 - 13:00, 14:00 - 18:00.
Vincoli metodologici
Un vincolo di progetto riguardava le interazioni con il tutor; in particolare, erano
previsti:
∗ alcune ore di formazione su Java e Spring
∗ un momento di formazione su Jira
∗ un’ora di configurazione di Bitbucket e Jira
∗ confronti al termine della fasi di analisi e di progettazione.
Il tutor è rimasto comunque sempre a disposizione e le interazioni sono state frequenti.
La definizione delle specifiche del prodotto è stata effettuata con una dipendente che
conosce molto bene il social network Instagram e le esigenze degli utenti del prodotto.
Il progetto doveva utilizzare la stessa metodologia agile applicata dall’intero team
di sviluppo con sprint di 2 settimane (si veda §1.5 Gestione di Progetto).
Vincoli tecnologici
Miriade ha richiesto che il front end dell’applicazione (la componente che si interfaccia
con Telegram) fosse scritto in Java e in particolar modo utilizzasse Maven e Spring
Boot.
Il sistema di versionamento adottato è stato Bitbucket di Atlassian, strumento
utilizzato da tutto il team sviluppo, mentre per la gestione del progetto è stata creata
una board agile su Jira per gestire gli sprint e tracciare l’avanzamento.12 CAPITOLO 2. PROGETTI DI STAGE NELLA STRATEGIA AZIENDALE Altri vincoli teconologici non sono stati definiti a priori, ma, al termine della fase di analisi, lo stack tecnologico proposto avrebbe dovuto essere approvato dal tutor. migliorare le prestazioniAPI
Capitolo 3
Svolgimento del Progetto
3.1 Studio delle Piattaforme
La proposta di stage era realizzare un chatbot che permettesse di monitorare e migliorare
le prestazioni del proprio account Instagram.
Tra le piattaforme di messaggistica che permettono di implementare dei chatbot è
stata scelta Telegram perché molto flessibile e con una buona base di utenti.
3.1.1 Caratteristiche delle API di Instagram
L’interfaccia con le API di Instagram 1 era un elemento fondamentale per la realizzazione
del prodotto. Purtroppo tali API consentono di effettuare un numero ristretto di
operazioni.
In particolare gli endpoint utilizzati più significativi sono stati quelli relativi alle
seguenti funzioni:
∗ autenticazione per permettere agli utenti di effettuare il login;
∗ statistiche sul post per permettere di salvare il numero di like e commenti che
un post ha ricevuto in un certo momento;
∗ statistiche sull’utente per salvare nome e numero dei seguaci di un dato utente.
Un limite delle API di Instagram è dato dalla mancanza di informazioni "storiche":
non si possono cioè ottenere dati su statistiche nel passato, che sarebbero utili per
effettuare previsioni e indicare all’utente i progressi.
1 Instagram Developer Portal. url: https://instagram.com/developer/.
1314 CAPITOLO 3. SVOLGIMENTO DEL PROGETTO
Figura 3.1: Principali metodi di input dei comandi del chatbot
(a) Input con Comandi (b) Custom Keyboard (c) Inline Keyboard
3.1.2 Caratteristiche delle Bot API di Telegram
La piattaforma bot di Telegram2 consente di collegare la propria applicazione a
Telegram.
Dal punto di vista dell’interfaccia grafica, la piattaforma mette a disposizione
dell’utente 4 principali metodi di input:
∗ input testuale (semplici messaggi di testo) che sono però poco intuitivi (l’utente
non necessariamente conosce la sintassi da utilizzare né quali sono le funzionalità
disponibili) e richiedono all’utente lo sforzo di digitare la propria richiesta;
∗ comandi i comandi sono sequenze di caratteri (senza spazi) preceduti da un
"/" vengono interpretati dai bot per eseguire specifici compiti, inoltre, quando
l’utente inizia il messaggio con uno slash, l’applicazione suggerisce i possibili
comandi all’utente;
∗ custom keyboard il metodo di input più amichevole è rappresentato da una
tastiera personalizzata: composta cioè da pochi pulsanti specificati dallo svilup-
patore;
∗ inline keyboard è composta da una serie di bottoni che compaiono direttamente
sotto ad uno specifico messaggio inviato dal bot, e rappresenta le possibili risposte
indirizzate a quel preciso messaggio.
Queste sono le principali modalità attraverso cui l’utente può inviare contenuti al
bot. Le più intuitive sono la terza e la quarta e sono state usate il più possibile dal bot.
2 Telegram Bot API. url: https://core.telegram.org/bots.3.2. ANALISI DEI REQUISITI 15
3.1.3 Definizione dei casi d’uso del prodotto
La definizione dei casi d’uso del prodotto è stata da me effettuata attraverso alcune
riunioni con una dipendente di Miriade esperta di Instagram. Tali riunioni hanno
portato alla realizzazione dei seguenti mockup come linee guida.
Figura 3.2: Mockup del Prodotto
Per la descrizione dei casi d’uso significativi si veda § 3.2.3 Casi d’uso salienti.
3.2 Analisi dei requisiti
3.2.1 Scopo del prodotto
Il prodotto avrebbe dovuto essere un bot sulla piattaforma Telegram che consentisse
agli utenti di monitorare e migliorare le performance del proprio account Instagram.
Le performance di un account dipendono da alcune metriche legate all’account e ai
suoi post. Le metriche più comuni sono:
∗ follower il numero di seguaci che ha un determinato account. Più che il valore
assoluto di questo numero è significativo l’aumento relativo tra due istanti di
tempo.
∗ post like il numero di mi piace che un determinato post ha totalizzato. I like
vengono ricevuti in maggiore quantità nelle prime ore di vita di un post, mentre
già dopo 24 ore il numero tende a non incrementare ulteriormente.
∗ commenti il numero di commenti che gli altri utenti scrivono in risposta ad
un post effettuato. Sebbene non sia automatico che tutti i commenti siano
di apprezzamento (come invece è per i like), essi rappresentano una metrica
positiva. I commenti negativi, infatti, (in cui gli altri utenti denigrano il post o
l’autore) sono nella pratica una minima percentuale e contribuiscono ugualmente
ad accrescere la notorietà dell’autore del post.16 CAPITOLO 3. SVOLGIMENTO DEL PROGETTO
∗ post engagement: è una metrica relativa al singolo post composta dalle tre
precedenti; essa indica la visibilità e l’apprezzamento generato da un determinato
post in relazione al numero di utenti che solitamente seguono l’autore. Per il
computo ho utilizzato la formula:
like + commenti
engagement =
f ollowers
Come si può notare, tale valore aumenta all’aumentare delle interazioni legate
ad un post ma risulta normalizzato al numero di seguaci.
Una formula simile viene utilizzata da Instagram per valutare quali siano i
contenuti più interessanti, ma essa non è resa pubblica dall’azienda.
∗ popular for hashtag è una metrica booleana che rappresenta l’ingresso o meno
di un post nella pagina dei "post popolari" per uno degli hashtag indicati in
descrizione.
Quando un utente posta un contenuto è solito aggiungere delle etichette3 (o
hashtag) alla descrizione. Queste etichette vengono indicizzate da Instagram ed
è possibile, tramite la funzione cerca o il click/tocco su un hashtag, visualizzare i
post pubblicati recentemente da tutti gli utenti con profilo pubblico che conten-
gono quello stesso hashtag.
I primi 9 post di questa pagina sono post selezionati da Instagram che vengono
visualizzati da tutti gli utenti; tali post sono comunemente chiamati top popular 4
(si veda la figura 3.3 come esempio).
L’algoritmo utilizzato da Instagram per la scelta di quali post mostrare è scono-
sciuto, ma è certo che i like, i commenti e il numero di follower lo condizionino
(probabilmente è una variazione sulla formula di engagement indicata prima).
Quando un post viene selezionato da Instagram e inserito tra i popular, esso
ottiene molta più visibilità migliorando notevolmente la propria performance.
3.2.2 Attori
Gli attori coinvolti nei casi d’uso del progetto sono:
∗ Telegram Bot API le API che Telegram mette a disposizione degli sviluppatori
per la creazione di bot;
∗ Instagram API le API che Instagram mette a disposizione per interrogare il
database e ottenere dati sugli utenti e sui post;
∗ Utenti sono utenti di Instagram e di Telegram che decidono di avviare una
conversazione con il bot per monitorare le proprie performance.
Per ottenere l’accesso più permissivo ai dati Instagram di un determinato utente è
necessario che egli autorizzi l’applicazione. Gli utenti sono però restii ad autorizzare
3 La sintassi per indicare queste etichette è un cancelletto "#" (hashtag in inglese) seguito dall’eti-
chetta scritta senza spazi. ad esempio, per i post relativi ad una giornata di sole, si potrebbe usare
#sunnyday.
4 Si consulti, a titolo di esempio la pagina https://www.instagram.com/explore/tags/sunnyday/.3.2. ANALISI DEI REQUISITI 17
Figura 3.3: Mockup Instagram Top Popular
applicazioni di terze parti a gestire il proprio account Instagram: in parte per la noia
di dover inserire username e password, in parte perché Instagram è solito bloccare i
profili di utenti che usano applicazioni di terze parti che violino le sue linee guida5 .
Per rassicurare l’utente, al momento dell’autorizzazione dell’app, vengono richiesti
solamente i permessi di visualizzare le proprie statistiche (like, followers, . . . ) e non,
ad esempio, quelli per effettuare like o postare contenuti. L’utente inesperto potrebbe
però non notare ciò e rinunciare comunque del tutto all’autenticazione.
Si è scelto quindi di considerare 3 tipologie di utenti:
∗ autenticati: sono gli utenti che effettuano il login con Instagram permettendo
così di avere pieno accesso ai loro dati attraverso le API Instagram;
∗ indicanti l’username: sono utenti che indicano solamente il proprio username.
Essi hanno accesso ad un set limitato di funzionalità che utilizzano quote pubbliche
5 Alcune applicazioni di terze parti sfruttano l’autorizzazione fornita dall’utente per postare conte-
nuti, seguire nuovi utenti, o mettere "mi piace" a post di altri in maniera automatica, violando le
linee guida di Instagram.18 CAPITOLO 3. SVOLGIMENTO DEL PROGETTO
Figura 3.4: Tipologie di Utenti
delle API di Instagram (quindi potrebbero aggiornare i dati con una frequenza
minore) o fanno affidamento a web crawler 6 ;
∗ non autenticati: sono utenti che non effettuano il login né indicano il proprio
username e utilizzano il bot per una serie minima di funzionalità (come il download
di media a partire dall’url di un post).
3.2.3 Casi d’uso salienti
UC1 Effettua login
Permette a qualsiasi utente di effettuare il login. Se l’utente è già autenticato viene
sostituito il precedente account in favore di quello nuovo.
∗ UC1.1 Login con Instagram permette di autenticarsi attraverso le proprie
credenziali di Instagram. È il modo consigliato e che mette a disposizione
dell’utente tutte le funzionalità
∗ UC1.2 Login con l’username permette di autenticarsi inserendo solamente il
proprio nome utente di Instagram. È una modalità sconsigliata, ma a disposizione
degli utenti più diffidenti.
∗ UC1.3 Visualizza errore di login indica all’utente che l’username/password
erano errati (se è stato tentato un login autenticandosi con Instagram) ovvero
che l’username non esiste o appartiene ad un utente privato (se è stato tentato il
login con il solo username).
6 Per aggiornare alcuni dati degli utenti che indicano solamente il proprio username, il back end
visita le pagine web di instagram.com e scansiona il contenuto dell’html per estrapolare le informazioni
rilevanti. Questo metodo è meno affidabile perché non fa affidamento sull’immutabilità della struttura
della pagina web3.2. ANALISI DEI REQUISITI 19
Figura 3.5: Use Case Principali20 CAPITOLO 3. SVOLGIMENTO DEL PROGETTO
UC2 Visualizza messaggio di aiuto
Permette all’utente di ricevere un messaggio testuale che lo istruisca sulle funzionalità
del bot e sulle loro modalità di fruizione.
UC3 Visualizza statistiche account
Permette all’utente di visualizzare informazioni riguardo al proprio account, come:
∗ il numero di seguaci;
∗ il numero di utenti seguiti;
∗ il numero di media condivisi finora;
∗ un grafico rappresentante l’andamento dei follower nelle ultime settimane.
UC4 Ottieni stima miglior momento per postare
Permette all’utente di ricevere una stima di quale sia il miglior momento della giornata
per pubblicare un contenuto.
Tale stima viene inferita dall’engagement dei post passati nelle prime 2 ore di vita.
Miriade intende affinare l’algoritmo di suggerimento dell’orario migliore per postare
effettuando analisi statistiche raffinate quando si saranno racconti un numero maggiore
di dati sui post degli utenti. Ho implementato il design pattern Strategy al fine di
rendere agile la sostituzione dell’algoritmo con uno più avanzato.
Le informazioni salienti che vengono visualizzate sono:
∗ l’intervallo orario di 2 ore entro cui si consiglia pubblicare;
∗ una heatmap 7 dell’engagement ottenuto dall’utente con i contenuti passati.
UC5 Visualizza statistiche ultimo post
Permette di visualizzare alcune informazioni circa l’ultimo post; in particolare:
∗ il numero di like;
∗ il numero di commenti;
7 L’heatmap è un grafico utilizzato per rappresentare funzioni che, presi due argomenti in input,
ne restituiscano uno di tipo numerico. Si presenta visivamente come una tabella le cui le colonne
indicano uno dei valori in input, le righe l’altro e a ciascuna cella sia associato un numero. Solitamente
le celle vengono colorate con intensità proporzionale al proprio contenuto.3.3. ARCHITETTURA 21
∗ l’engagement (cfr. equazione dell’engagement);
∗ se l’ultimo post è stato selezionato ed inserito Instagram nei popular per qualche
hashtag, questi vengono visualizzati.
UC6 Inserisci URL nuovo post
Permette di inserire l’url del proprio post, dopo che si è pubblicato, per cominciare a
monitorarne le performance.
Questo caso d’uso è necessario solamente agli utenti non autenticati tramite In-
stagram. Quando un utente si autentica effettuando il login con Instagram, grazie
ad un webhook 8 , il back end viene informato automaticamente della pubblicazione di
nuovi contenuti, rendendo superflua questa funzionalità. Di contro, gli utenti che si
autenticano inserendo solamente il proprio username devono informare manualmente
il back end dell’aggiunta di nuovi contenuti.
UC7 Download Media
Permette di inviare un link ad un post Instagram (di qualsiasi utente, purché pubblico)
a cui il bot risponderà inviando il contenuto in chat.
È una funzione utile per effettuare il repost di contenuti o per salvarne una copia.
Sono supportati i tipi di contenuti ad ora supportati da Instagram: video e immagini.
3.3 Architettura
Per l’applicazione, ho scelto un’architettura three-tier in cui i 3 strati Business Logic,
Persistenza Dati e Front End fossero ben separati.
La separazione netta degli strati favorisce la loro manutenzione (ad esempio: si
può rilasciare una nuova versione del front end senza che la business logic debba
riavviarsi con esso) e l’estensione (ad esempio: per aggiungere una nuova piattaforma
di messaggistica, o un’applicazione web, sarebbe sufficiente aggiungere un nuovo
elemento di front end, senza alcuna modifica al sistema esistente).
La separazione è enfatizzata dall’utilizzo di tecnologie diverse per ciascuno strato.
8 Instagram consente di indicare un indirizzo per creare un webhook, in modo da notificare il proprio
web service ogni volta che un utente autenticato pubblica un’immagine (Instagram effettua una
chiamata POST con il contenuto all’endpoint specificato)22 CAPITOLO 3. SVOLGIMENTO DEL PROGETTO
3.3.1 Business Logic
Lo strato di Business Logic si occupa principalmente di:
∗ aggiornare periodicamente le statistiche dei vari post e account;
∗ esporre un endpoint per l’autenticazione ad Instagram con OAuth 2.0 9 ;
∗ esporre un endpoint su cui realizzare un webhook per gli aggiornamenti di
Instagram.
Tecnologie
Si è scelto di utilizzare i prodotti offerti da Google Cloud Platform perché convenienti
dal punto di vista delle funzionalità e del prezzo. La Business Logic, in particolare, è
tutta basata su Google Cloud Functions.
Le Cloud Functions sono funzioni NodeJS che vengono invocate al verificarsi di uno
specifico evento trigger. Questa tecnologia favorisce la scrittura di codice che rispetti
il principio di singola responsabilità; infatti ogni compito viene incapsulato in una
specifica Cloud Function.
Il cuore della Business Logic è quindi rappresentato dalle Cloud Functions, ma sono
necessarie altre tecnologie per la coordinazione della loro esecuzione.
Google Cloud Platform mette a disposizione Cloud Pub/Sub per l’invio di messaggi tra
i suoi prodotti.
Avviene quindi che ogni funzionalità ha un suo topic (un titolo) associato (come
updateFollowersCount); quando si vogliono attivare le funzioni associate è sufficiente
emettere un messaggio Pub/Sub contenente quel topic ed un eventuale payload di dati
necessari. Le funzioni che avranno quel preciso topic come evento trigger verranno
quindi invocate.
Le Cloud Functions permettono di limitare i costi di manutenzione del sistema
(essendo totalmente gestite da Google non necessitano di aggiornamenti, antivirus,
rinnovo di certificati o altro). Il costo del sistema è nullo, infatti le prime 2 milioni
di invocazioni di funzioni e i primi 3.2 milioni di secondi di esecuzione (circa 890 ore)
ogni mese sono gratuiti10 .
Per supportare la schedulazione di compiti ricorrenti è stato necessario scrivere un
cron. Per semplicità di gestione ho scelto di usare Google App Engine, un altro prodotto
della suite di prodotti di GCP, che consente di effettuare il deployment di applicazioni
senza curarsi dell’infrastruttura sottostante. Indicando in un file yaml l’opportuna
9 OAuth 2.0 è un protocollo che permette a terze parti di ottenere accesso limitato agli account
di un determinato utente presso un servizio http: nello specifico Instagram. Viene utilizzato per
autorizzare il bot ad accedere ai dati Instagram di un determinato utente. Si veda OAuth Protocol.
url: https://oauth.net
10 I costi attualmente in vigore prendono in considerazione 3 parametri: il numero di invocazioni (i
primi 2 milioni sono gratuiti), il traffico di dati uscente (i primi 5GB sono gratuiti) ed il numero di
GB-secondi di memoria complessivi (sono grauiti i primi 400000 GB-secondi, cioè 400000 secondi di
esecuzione allocando 1GB di RAM o, ad esempio, 3.2 milioni secondi allocandone 128MB)3.3. ARCHITETTURA 23
configurazione si possono lanciare applicazioni che scalino automaticamente da zero a
centinaia di istanze.
Ho quindi realizzato un cron in Python per lanciare periodicamente dei messaggi
Pub/Sub che invocassero le necessarie funzioni.
3.3.2 Persistenza dei Dati
La persistenza dei dati è centrale nell’applicazione sviluppata in particolare per due
motivi: per mantenere uno storico delle varie statistiche raccolte al fine di mostrare
all’utente dati rilevanti e per creare dataset sufficientemente ampi sui quali condurre
qualche indagine statistica che sia significativa al fine di migliorare l’algoritmo di
suggerimento del momento migliore per pubblicare.
La maggior parte dei dati da immagazzinare sono dati di statistiche associati ad
un certo istante in cui sono stati misurati. Ad esempio si vuol tener traccia dei like,
commenti e engagement dei post pubblicati nelle ultime 48 ore, aggiungendo il valore
aggiornato ogni 10 minuti.
Per fare questo verranno privilegiate operazioni di append piuttosto che update in
modo da preservare i dati storici. Questo richiede a sua volta che i dati siano lo stretto
necessario, perché il numero di entrate nel database potrebbe crescere smisuratamente.
Tecnologie
Si è considerato dapprima se fosse più opportuno un database relazionale od uno non
relazionale. La natura strutturata dei dati da inserire (tabelle con poche metriche e
ben definite) gioca a favore dei primi, mentre la maggior semplicità di interazione con
un database non relazionale dal linguaggio NodeJS (utilizzato nelle Cloud Function)
giocava a favore dei primi.
Il fattore decisivo che ha condizionato la scelta in favore dei database relazionali è
l’abilità di processare join in maniera efficiente. Come spiegato sopra, l’aggiunta di
nuovi dati deve essere effettuata senza creare entrate inutili (se il numero di like di un
post è rimasto invariato dall’ultima misurazione, è inutile aggiungere una nuova entrata):
la possibilità di effettuare join su una tabella temporanea, prima dell’inserimento dei
dati, consente di scremare i dati in ingresso dimandando al database il computo delle
differenze con quelli già presenti.
Ho considerato ulteriormente il servizio gestito Google BigQuery, per lo stoccaggio e
l’analisi di Big Data. BigQuery consente di interrogare rapidamente grandi quantità di
dati, ma ha un limite nella latenza relativamente elevata (tra i 5 e i 10 secondi) anche
per le query più banali su dataset di una decina di righe (probabilmente a causa del
tempo necessario a dividere il dataset nei nodi che poi devono effettivamente eseguire
la query) e per questo non l’ho ritenuto opportuno.
Per questa serie di considerazioni si è scelto di utilizzare PostgreSQL, in particolare
il prodotto CloudSQL di Google Cloud Platform che fornisce un database PostgreSQL
completamente gestito.24 CAPITOLO 3. SVOLGIMENTO DEL PROGETTO
Figura 3.6: Logo di PostgreSQL
Tabella 3.1: Comparazione Database Considerati
Tecnologia Pro Contro
MySQL - Veloce - Poco flessibile
- SQL compliant - Necessita di licenze
PostgreSQL - Veloce - Poco flessibile
- SQL compliant
NoSQL - Flessibile - Poco performante in join
BigQuery - Performante con dataset molto - Alta latenza, influente soprat-
ampi tutto con dataset ridotti
3.3.3 Front end
Il Front End consiste di una applicazione Java che si occupa di fornire un’interfaccia
utente attraverso le Bot API di Telegram.
Il Front End si connette al database da cui ricava i dati da mostrare all’utente.
Tecnologie
Per il deployment si è optato, anche in questo caso, per Google App Engine per i
seguenti motivi:
∗ è una soluzione completamente gestita con zero costi di manutenzione;
∗ è di semplice implementazione;
∗ è semplice la gestione di prodotti appartenenti tutti alla stessa suite (ad esempio
viene fornita una console unificata dei log).
Per effettuare il deployment dell’applicazione, ho compiuto i seguenti passi:3.4. PROGETTAZIONE 25
Figura 3.7: Prodotti di Google Cloud Platform. url: https://cloud.google.com
(a) Logo Cloud Functions (b) Logo CloudSQL (c) Logo App Engine
1. grazie a Apache Maven e Spring ho potuto creare un eseguibile .jar dell’appli-
cazione (si veda §1.4 Tecnologie Utilizzate);
2. specificando un semplice Dockerfile ho potuto creare un container Docker 11
contenente il necessario per configurare ed avviare il modulo di front end ;
3. attraverso un file yaml, ho specificato quali fossero le configurazioni per App
Engine;
4. attraverso l’interfaccia di Google Cloud Platform da linea di comando, ho potuto
effettuare il deployment dell’applicazione in pochi minuti.
Si noti come i successivi deployment richiedano semplicemente:
1. la creazione del package .jar;
2. il build dell’immagine Docker ;
3. l’upload dell’app aggiornata;
consentendo quindi di lanciare in produzione una nuova versione del front end in meno
di 2 minuti.
3.4 Progettazione
3.4.1 Spring Boot e Maven
Nella realizzazione del front end si è utilizzato Maven per la gestione delle dipendenze:
attraverso un documento xml, noto con il nome di pom, è possibile definire tutte
le dipendenze esterne del progetto (ad esempio framework come Spring Boot) e le
istruzioni per effettuare la compilazione del progetto.
11 I container Docker sono dei pacchetti contenente tutto quello che serve ad un’applicazione per
essere eseguita. Sono isolati dal contesto e vengono caricati da App Engine in una o più macchine
virtuali a seconda delle esigenze di scalabilità dell’applicazione. Consentono, inoltre, di isolare il
software da quello che è il sistema specifico in cui viene fatto girare, semplificandone la verifica.26 CAPITOLO 3. SVOLGIMENTO DEL PROGETTO
Come anticipato, nel progetto, ho utilizzato estensivamente il framework Spring
Boot. Alcuni dei vantaggi tratti dal suo utilizzo sono stati:
∗ Dependency Injection: l’iniezione delle dipendenze è un design pattern che
mira a semplificare lo sviluppo e migliorare la testabilità del codice. Spring Boot
mette a disposizione del programmatore l’annotazione @Autowired che consente
l’iniezione automatica delle variabili da parte del framework.
Supponiamo, ad esempio, che una classe C debba utilizzare un oggetto di un’altra
classe I. Per rispettare il principio di Inversione delle Dipendenze, C dovrebbe
dipendere da una astrazione di I, quindi è opportuno dichiarare un’interfaccia
InterfaceI, che verrà implementata da I e che esponga il set minore possibile
di funzionalità. Si pone però il problema dell’istanziazione dell’oggetto specifico
I: se la sua creazione fosse fatta da C, i nostri tentativi di isolare il più possibile
le implementazioni delle interfacce dagli oggetti che le usano sarebbero vanificati.
A questo punto entrano in gioco le annotazioni @Autowired e @Bean, semplificando
il lavoro dello sviluppatore. Supponiamo ad esempio le classi siano dichiarate
come segue:
Listing 3.1: Esempio di Autowiring di Spring
@Service
public class C {
@Autowired
private I i ;
}
public interface InterfaceI {}
@Bean
public class I implements InterfaceI {}
Quando viene instaziato un oggetto di tipo C, Spring Boot cerca una classe
annotata con @Bean che implementi l’interfaccia richiesta (InterfaceI) e si
occupa di iniettare un oggetto di questa classe nella proprietà i di C.
Quello presentato è un caso semplice, a titolo esemplificativo. Spring Boot
consente di configurare in maniera raffinata i Bean, prima di effettuare l’injection.
∗ Package inclusi: Spring Boot include numerosi package utili per effettuare
operazioni comuni. Ad esempio il package JDBC fornisce un meccanismo semplice
ed intuitivo per gestire le connessioni e le interrogazioni di un database esterno.
∗ Creazione di un jar: Spring Boot consente la creazione di un unico pacchetto
jar con tutto il necessario per eseguire l’applicazione; l’alternativa sarebbe la
produzione di un archivio war che deve però eseguito su un servlet (ad esempio
Apache Tomcat), il quale deve essere installato e manutenuto.
3.4.2 Struttura del codice di routing dei comandi del bot
Lo sviluppo di un bot presenta delle sfide legate al routing degli aggiornamenti. Gli
aggiornamenti che Telegram invia all’applicazione sono di tipologie molto diverse tra3.4. PROGETTAZIONE 27
loro; alcuni esempi di aggiornamenti sono:
∗ un nuovo messaggio in una chat privata;
∗ un nuovo messaggio in un gruppo;
∗ un utente lascia un gruppo;
∗ il bot viene aggiunto in un gruppo;
∗ un utente modifica un messaggio inviato in precedenza;
∗ un utente invia una foto in una chat di gruppo;
∗ un utente preme su un inline button (si veda §3.1.2 Caratteristiche delle Bot API
di Telegram).
Si deve prevedere un oggetto che effettui il routing di ciasun aggiornamento verso
l’oggetto handler a cui compete la sua gestione.
L’idea più intuitiva è inserire un metodo in ogni oggetto handler che valuti se
l’aggiornamento ricevuto è di sua competenza ed eventualmente agisca.
Questo approccio è di semplice implementazione e permette di avere una struttura del
codice chiara, ma comporta uno spreco di risorse: molti oggetti handler effettueranno
gli stessi controlli sul medesimo aggiornamento, aumentando il tempo di risposta del
server.
Un secondo approccio potrebbe essere di inserire nel router un metodo che valuti
tutti i possibili casi e inoltri l’aggiornamento solamente all’handler designato.
Questo porterebbe però ad un lungo elenco illeggibile di clausole if ed else che
renderebbero difficili l’aggiunta di nuovi handler e la manutenzione di quelli esistenti.
Il terzo approccio, quello adottato, è una versione ibrida dei primi due. Consiste
nell’effettuare alcuni dei controlli nel router, al fine di scremare l’insieme di handler a
cui viene inoltrato l’aggiornamento.
Per non aumentare, però, le responsabilità del router e violare il principio di singola
resposabilità, sono i vari handler che devono dichiarare a quali tipologie di aggiorna-
mento sono o non sono interessati.
L’interfaccia degli handler si può esemplificare nella seguente:
Listing 3.2: Esempio di interfaccia di Handler degli aggiornamenti del bot
public enum ChatType {
PRIVATE , GROUP , ALL
}
public interface Handler {
boolean wantsTextMessage () ;
boolean wantsPhoto () ;
ChatType wantsMessageFromChat () ;
// altri
void handle ( Update upd ) ;
}
28 CAPITOLO 3. SVOLGIMENTO DEL PROGETTO
Mentre questa è una esemplificazione del metodo di routing:
Listing 3.3: Esempio di metodo di routing del bot
private List < Handler > handlers ;
private route ( Update upd ) {
Stream < Handler > selected = handlers . stream () ;
selected = selected . filter ( h -> upd . chatType == h .
wantsMessageFromChat () || h . wantsMessageFromChat () ==
ChatType . ALL ) ;
if ( upd . isMessage () && upd . hasText () ) {
selected = selected . filter ( Handler :: wantsTextMessage ) ;
}
if ( upd . isMessage () && upd . isPhoto () ) {
selected = selected . filter ( Handler :: wantsPhoto ) ;
}
selected . foreach ( h -> h . handle ( upd ) ) ;
}
3.4.3 Gestione di Utenti con Diversa Autenticazione
Come spiegato in §3.2.2 Attori, ci sono alcuni utenti che effettuano il login con Instagram,
e alcuni utenti che forniscono solamente il proprio nome utente.
Mentre per i primi si possono utilizzare le API di Instagram adoperando il token
associato a ciascun account senza preoccuparsi di raggiungere il limite della quota
prevista di utilizzo12 , per la seconda categoria si devono usare dei token comuni (con il
rischio di eccedere i limiti di quota).
Un altro problema è che alcune statistiche richieste dal proponente non sono fornite
dalle API di Instagram. Per esse è stato quindi necessario implementare alcuni crawler 13
che analizzassero le pagine di instagram.com.
Nel diagramma in fig. 3.8 Parte del Package Instagram della Business Logic si
possono vedere alcune delle classi del pacchetto "Instagram" della business logic. Si
noti in particolare l’utilizzo delle interfacce Provider e delle classi Factory al fine di
istaziare gli oggetti appropriati per ogni caso.
Si noti anche come alcuni dati (come le statistiche sugli hashtag) siano ricavabili
unicamente tramite web crawler.
3.4.4 Instagram Subscriptions
Per migliorare l’esperienza degli utenti autenticati si è scelto di implementare le User
Subscriptions. Tale mecanismo consente di indicare ad Instagram un indirizzo di
callback su cui effettuare una chiamata in POST ogniqualvolta un utente autenticato
12 Le API di Instagram consentono di effettuare fino a 5000 chiamate entro una sliding window di
un’ora.
13 I crawler sono applicazioni che scansionano le pagine web per estrapolarne dei dati.Puoi anche leggere
