Skip to content

Commit

Permalink
feat: last (?) big modification done
Browse files Browse the repository at this point in the history
  • Loading branch information
NiccoMlt committed Mar 7, 2020
1 parent a1e230f commit 895294a
Show file tree
Hide file tree
Showing 6 changed files with 81 additions and 51 deletions.
2 changes: 1 addition & 1 deletion src/back/ringraziamenti.tex
Original file line number Diff line number Diff line change
Expand Up @@ -14,7 +14,7 @@

% Infine ringrazio il professor Mirko Viroli e il professor Danilo Pianini per la bella
% opportunità che mi hanno offerto, per tutto l'aiuto datomi per realizzare
% questo progetto e per le competenze che mi hanno permesso di avere.
% questo progetto e per le competenze che mi hanno permesso di sviluppare.

% % ------

Expand Down
10 changes: 4 additions & 6 deletions src/front/dedica.tex
Original file line number Diff line number Diff line change
Expand Up @@ -2,11 +2,9 @@
\thispagestyle{plain}
\null{}\vspace{\stretch{1}}
\begin{flushright}
\textit{Dedica}
% \textit{%
% A tutti coloro che mi hanno sostenuto.
%
% A mia nonna, che non ha potuto vedermi a questo traguardo.
% }
\textit{%
A tutti gli amici e i familiari che mi hanno sostenuto.\\
A chi non ha potuto assistere anche a questo traguardo.
}
\end{flushright}
\vspace{\stretch{2}}\null{}
4 changes: 2 additions & 2 deletions src/main/background/web.tex
Original file line number Diff line number Diff line change
Expand Up @@ -187,10 +187,10 @@ \chapter{Progettazione di sistemi web}\label{ch:web}
Scala mette a disposizione un type system allo stesso tempo più espressivo e più rigoroso, di conseguenza può risultare più \emph{user-friendly} sia durante lo sviluppo che in fase di debug.

\item[Prestazioni]
Secondo benchmark~\cite{Doeraene:256862} realizzati tramite una suite estensiva già utilizzata in letteratura~\cite{10.1145/3093334.2989232}, per quanto Scala.js risulti più lento della controparte JVM, riesce ad essere fino al 33\% più veloce di un programma equivalente scritto in JavaScript.
Secondo benchmark~\cite{Doeraene:256862} realizzati tramite una suite estensiva già utilizzata in letteratura~\cite{10.1145/3093334.2989232}, per quanto Scala.js risulti più lento della controparte JVM, riesce ad essere fino al \SI{33}{\percent} più veloce di un programma equivalente scritto in JavaScript.

Inoltre, il compilatore risulta molto efficiente in termini di dimensioni finali del \emph{bundle}:
secondo il sito ufficiale, generalmente si parte dai \(\SI{45}{\kilo\byte}\) per un'intera applicazione compressa in gzip.
secondo il sito ufficiale, generalmente si parte dai \SI{45}{\kilo\byte} per un'intera applicazione compressa in gzip.
Questo permette di avere buone performance al primo caricamento dell'applicazione web.

\item[Interoperabilità con JavaScript]
Expand Down
106 changes: 72 additions & 34 deletions src/main/conclusion/evaluation.tex
Original file line number Diff line number Diff line change
@@ -1,55 +1,93 @@
\chapter{Valutazione dei risultati}\label{ch:evaluation}

\section{Qualità del codice e unit testing}
Durante lo sviluppo, si è cercato di prestare particolare attenzione alla qualità del codice prodotto.

Si è ritenuto fondamentale, innanzitutto, per favorire la consistenza dello stile, che il codice fosse conforme a uno stile di programmazione riconosciuto.
Come detto nella~\Cref{subec:quality}, sono stati utilizzati diversi \emph{linter} (ESLint e ktlint)
per imporre lo stile Airbnb per TypeScript e lo stile ufficiale per Kotlin in tutta la codebase.
Questo ha permesso di evitare bug comuni riconoscibili attraverso analisi statica
e potenzialmente permette di rendere il codice, che è pubblico e open-source, maggiormente comprensibile per chi vorrà estenderlo in futuro.

Inoltre, per garantire il corretto funzionamento delle componenti più cruciali, sono stati creati degli specifici unit test in grado di coprire il codice per quanto possibile.
L'esecuzione dei test viene effettuata automaticamente da Travis CI su diverse piattaforma ad ogni operazione di push.

Per quanto riguarda il backend è stato utilizzato JUnit 5 con l'ausilio delle estensioni di Vert.x.
I report sulla copertura vengono raccolti tramite JaCoCo.

\unsure[inline]{Quali dettagli dovrei fornire dei test del backend?}

Anche il frontend è stato testato tramite unit testing.
In particolare, si è utilizzato la suite Jest per l'esecuzione dei test e la raccolta dei dati di copertura.

\unsure[inline]{Quali dettagli dovrei fornire dei test del frontend?}
\section{Considerazioni sul contributo}
Il problema delineato nei~\Cref{ch:requirements,ch:project} prevedeva la realizzazione di un sistema per l'esecuzione di codice Protelis attraverso una piattaforma web, appoggiandosi ad una rete di dispositivi simulata.
I requisiti funzionali sono stati tutti soddisfatti:
la Single-Page Application realizzata permette di visualizzare e modificare il codice Protelis all'interno del campo editor e ne permetta la rappresentazione dei risultati attraverso un canvas che disegna l'output.
L'utente non deve configurare impostazioni complesse:
l'unica configurazione messa a disposizione, oltre ovviamente al codice da eseguire, è la selezione del server di backend.
Anche il server soddisfa i propri requisiti funzionali:
l'esecuzione del codice è delegato a singole istanze del simulatore Alchemist, le quali generano ciascuna una rete virtuale, in modo da poter servire ciascuno degli utenti del sistema in contemporanea.

Il client soddisfa appieno anche i requisiti non funzionali:
l'esperienza utente è immediata, con un'interfaccia orizzontale responsiva strutturata su una singola pagina.
La configurazione dei polyfill permette il supporto a tutti i browser con percentuali di utilizzo superiori allo \SI{0.2}{\percent} e che non abbiano terminato il supporto ufficiale da più di 24 mesi;
lo strumento \texttt{browserlist} stima una copertura del \SI{91.67}{\percent} delle piattaforme correntemente utilizzate.
Anche il protocollo impiegato per la comunicazione con il server, SockJS, risulta compatibile con la maggior parte delle piattaforme in uso, utilizzando però soluzioni di trasporto meno efficienti su browser più datati.
Infine, il server soddisfa il requisito di scalabilità, garantito principalmente dalle possibilità fornite dal framework Vert.x.

Il sistema inoltre è stato progettato con diverse possibilità di espansione in mente, principalmente per quanto riguarda il supporto ad altri linguaggi (come ScaFi) e ad altri motori di esecuzione.
Si tratterà meglio questo aspetto nel~\Cref{ch:considerations}.

L'unica problematica individuata riguarda l'efficienza:
la costruzione di una nuova simulazione Alchemist per ogni utente che richieda l'esecuzione comporta tempi di costruzione e impiego di memoria non banali (soprattutto su piattaforme cloud gratuite come Heroku \emph{Free}).
Questo problema è strettamente legato alla necessità di esecuzione su una rete e può essere solamente aggirato tramite meccanismi di caching o scalando il sistema aumentando le risorse a disposizione.

\section{Valutazione dell'interfaccia}
Per quanto riguarda la valutazione del client, è stata presa in considerazione principalmente l'esperienza finale dal punto di vista dell'utente web.
Per quanto riguarda la valutazione della qualità dell'interfaccia web realizzata, è stata presa in considerazione principalmente l'esperienza finale dal punto di vista dell'utente web.
Per avere una misura quantitativa di quanto l'applicazione web si presenti adeguata, si è deciso di utilizzare lo strumento Lighthouse messo a disposizione da Google.

\emph{Lighthouse} è uno strumento automatizzato open-source, fornito inizialmente con la suite di strumenti \emph{Chrome DevTools}, che permette l'\emph{auditing} di pagine web secondo gli standard premiati dal motore di ricerca di Google.
Esso verifica le prestazioni di caricamento e navigazione, l'accessibilità, la SEO (\emph{\emph{S}earch \emph{E}ngine \emph{O}ptimization}), e in generale le buone pratiche di programmazione.
Esso verifica le prestazioni di caricamento e navigazione, l'accessibilità, l'ottimizzazione per i motori di ricerca, e in generale le buone pratiche di programmazione.
Supporta inoltre controlli aggiuntivi per le PWA (\emph{\emph{P}rogressive \emph{W}eb \emph{A}pp}) se abilitati.

\begin{figure}
\begin{figure}[htbp]
\centering
\includegraphics[width=\textwidth]{res/tests/Screenshot_2020-03-04 Lighthouse Report Viewer.png}% ChkTeX 8
\caption{Punteggio ottenuto con Google Lighthouse}%
\label{fig:lighthouse}
\end{figure}

Come è possibile vedere in~\Cref{fig:lighthouse}, l'applicazione web ha ottenuto un buon punteggio generale.
Come è possibile vedere in~\Cref{fig:lighthouse}, un'analisi dell'applicazione web realizzata attraverso il plugin ufficiale per FireFox ha ottenuto un buon punteggio generale.
Di seguito verranno analizzati i singoli valori separatamente.

\subsection{Performance}
Lighthouse ad ogni analisi assegna un punteggio denominato \emph{performance} basato su diverse metriche in relazione ai diversi stadi caricamento della pagina;
i valori grezzi ottenuti per ciascuna metrica vengono mappati su una distribuzione log-normale derivata dalle metriche prestazionali ricavate da HTTPArchive\footnote{\url{https://httparchive.org/}}.
0 è il minor valore possibile e generalmente indica un errore interno a Lighthouse, mentre 100 è il valore migliore, che posiziona la pagina analizzata nel 98-esimo percentile dei siti più performanti.

Secondo lo strumento, le performance %, sulle quali si ha avuto maggiore controllo durante l'implementazione,
del frontend di WebProtelis sono buone, con tempi di primo disegno inferiori al secondo e un ritardo prima di avere possibilità di interazione intorno a \SI{1.6}{\second}.
A pesare un poco sul punteggio vi è l'assenza di gestione della cache delle richieste, funzionalità non ritenuta importante in questo progetto.

I punteggi di accessibilità e \emph{best practices} sono strettamente legati dalle librerie impiegate, sia in positivo che in negativo:
\subsection{Accessibilità e Best Practices}

Il punteggio denominato \emph{accessibility} è dato da una media ponderata dei numerosi audit di accessibilità effettuati;
a differenza di quanto avveniva per le performance, ciascun audit non ha valori parziali, bensì solo 0 o 100.
Anche il punteggio di \emph{best practices} è composto da diverse caratteristiche, delle quali viene ricavata una media non pesata.

I punteggi ottenuti da questo progetto sono strettamente legati dalle librerie impiegate, sia in positivo che in negativo:
il valore elevato deriva da ottimizzazioni della libreria stessa sui componenti che fornisce, cercando di aderire quanto possibile agli standard più moderni;
le criticità che non portano al 100\% sono legate a limiti difficilmente aggirabili se non configurazioni complesse e fuori tema rispetto all'obiettivo di questa tesi.
le criticità che non portano al \SI{100}{\percent} sono legate a limiti difficilmente aggirabili se non configurazioni complesse e fuori tema rispetto all'obiettivo di questa tesi.

\subsection{SEO}

Infine, con \emph{SEO} si intende \emph{\emph{S}earch \emph{E}ngine \emph{O}ptimization}, ovvero quanto la pagina web è ottimizzata per la ricerca tramite motori come Google.
Il punteggio è determinato dalla presenza dei corretti tag nel documento, che permettono alla pagina di essere analizzata e descritta in modo accurato.
Nel caso di questo progetto, ottimizzando manualmente la configurazione base generata da React seguendo le specifiche documentate da Google, si è riuscito ad ottenere il massimo punteggio, che dovrebbe garantire un buon ranking nelle ricerche.

% \section{Qualità del codice e unit testing}
% Durante lo sviluppo, si è cercato di prestare particolare attenzione alla qualità del codice prodotto.

% Si è ritenuto fondamentale, innanzitutto, per favorire la consistenza dello stile, che il codice fosse conforme a uno stile di programmazione riconosciuto.
% Come detto nella~\Cref{subec:quality}, sono stati utilizzati diversi \emph{linter} (ESLint e ktlint)
% per imporre lo stile Airbnb per TypeScript e lo stile ufficiale per Kotlin in tutta la codebase.
% Questo ha permesso di evitare bug comuni riconoscibili attraverso analisi statica
% e potenzialmente permette di rendere il codice, che è pubblico e open-source, maggiormente comprensibile per chi vorrà estenderlo in futuro.

% Inoltre, per garantire il corretto funzionamento delle componenti più cruciali, sono stati creati degli specifici unit test in grado di coprire il codice per quanto possibile.
% L'esecuzione dei test viene effettuata automaticamente da Travis CI su diverse piattaforma ad ogni operazione di push.

% Per quanto riguarda il backend è stato utilizzato JUnit 5 con l'ausilio delle estensioni di Vert.x.
% I report sulla copertura vengono raccolti tramite JaCoCo.

Il punteggio massimo per la SEO, ottenuto ottimizzando la configurazione base generata da React, garantisce, secondo quanto dichiarato da Google, una migliore compatibilità con i motori di ricerca e dunque un ranking migliore.
% \unsure[inline]{Quali dettagli dovrei fornire dei test del backend?}

Le performance, sulle quali si ha avuto maggiore controllo durante l'implementazione, sono buone, con tempi di primo disegno inferiori al secondo e un ritardo prima di avere possibilità di interazione intorno a \SI{1.6}{\second}.
A pesare sul punteggio vi è l'assenza di gestione della cache delle richieste, funzionalità non ritenuta importante in questo progetto.
% Anche il frontend è stato testato tramite unit testing.
% In particolare, si è utilizzato la suite Jest per l'esecuzione dei test e la raccolta dei dati di copertura.

Volendo ottimizzare ulteriormente, si potrebbe aggiungere il supporto allo standard PWA, secondo le \emph{best practices} documentate da Google.
% \unsure[inline]{Quali dettagli dovrei fornire dei test del frontend?}

% \section{Performance}
% % TODO
% \unsure[inline]{Come valuto i risultati? Misure di Performance?}
% \section{Performance}
% % TODO
% \unsure[inline]{Come valuto i risultati? Misure di Performance?}
2 changes: 1 addition & 1 deletion src/main/contribution/tech.tex
Original file line number Diff line number Diff line change
Expand Up @@ -131,7 +131,7 @@ \section{Tecnologie utilizzate}
\end{description}

Per lo sviluppo del codice è stato utilizzato l'ambiente di sviluppo integrato \emph{JetBrains Intellij IDEA} in versione \emph{Ultimate 2019.3.3}.
Si è scelto questo rispetto ad altri IDE (come ad esempio Eclipse) in quanto in grado di offrire un'integrazione migliore con Gradle e Kotlin.
% Si è scelto questo rispetto ad altri IDE (come ad esempio Eclipse) in quanto in grado di offrire un'integrazione migliore con Gradle e Kotlin.

\subsubsection{Frontend}

Expand Down
8 changes: 1 addition & 7 deletions src/main/intro.tex
Original file line number Diff line number Diff line change
Expand Up @@ -12,12 +12,6 @@
da parte dell'Università di Bologna, di linguaggi e framework innovativi per la sua applicazione in contesti d'uso reale:
\emph{Protelis} e \emph{ScaFi}.

% Entrambi si avvalgono della piattaforma JVM (\emph{\emph{J}ava \emph{V}irtual \emph{M}achine}) per poter essere eseguiti;
% come vedremo, questo garantisce numerose proprietà, ma può essere limitante in contesti didattici.
% Infatti, la necessità di possedere una rete reale di dispositivi o di configurare un simulatore per l'esecuzione
% aggiunge ulteriore complessità per un novizio che voglia approcciarsi alla tecnologia.
% Inoltre, non è da ignorare nemmeno la necessità di configurazione di un progetto Gradle o SBT completo per poter realizzare un prototipo minimale.

La principale criticità legata a questo tipo di linguaggi, soprattutto in contesto didattico, è correlata alla configurazione del sistema per l'esecuzione.
Infatti, affinché la programmazione aggregata risulti significativa, è richiesta la presenza di diversi dispositivi sui quali il codice possa essere eseguito.
Poiché avere a disposizione una rete di dispositivi è costoso, molto spesso si decide di appoggiarsi a simulatori compatibili,
Expand Down Expand Up @@ -49,4 +43,4 @@
Nella~\Cref{part:contribution} viene analizzato il processo di progettazione del sistema a cui questo elaborato di tesi si riferisce e di sviluppo del prototipo.
Ciascuna fase del processo è descritta in un \nameCref{ch:requirements} dedicato.

Infine, nella~\Cref{part:conclusion} vengono raccolti i risultati del processo di sviluppo (\Cref{ch:evaluation}), presentate le prospettive future del sistema prodotto (\Cref{ch:future}) ed enunciate brevemente le considerazioni finali (\Cref{ch:considerations}) a conclusione di questa tesi.
Infine, nella~\Cref{part:conclusion} vengono raccolti i risultati del processo di sviluppo (\Cref{ch:evaluation}), presentate le prospettive future del sistema prodotto ed enunciate brevemente le considerazioni finali (\Cref{ch:considerations}) a conclusione di questa tesi.

0 comments on commit 895294a

Please sign in to comment.