3d-interface-rapport/rapport/techno.tex

\part{Choix des technologies et prise en main}
\paragraph{}
La première phase de stage était de choisir les technologies qui allaient être
utilisées par la suite. Nous cherchions des technologies permettant la
visualisation 3D sur un navigateur web afin de pouvoir faire une étude
utilisateur simplement.

\section{Côté client}
\paragraph{}
Pour le côté client, il y avait plusieurs possibilités :
\begin{itemize}
    \item WebGL, la spécification des fonctions permettant la 3D dans le
        navigateur
    \item Une librairie facilitant l'utilisation de WebGL
    \item Du code C++ compilé en JavaScript grâce à Emscripten
    \item N'importe quel moteur graphique qui puisse exporter vers JavaScript
\end{itemize}

\paragraph{}
La plupart des moteurs graphiques exportant vers JavaScript sont putôt lourd à
prendre en main, et nous voulions garder des solutions simples, c'est pourquoi
nous avons utilisé une librairie libre nommée \threejs{} permettant une
utilisation facile de WebGL.

\paragraph{}
Pour des raisons de simplicité, nous avons décidé de développer le code client
pour Google Chrome et Firefox, les autres navigateurs ne sont donc pas
(officiellement) supportés.

\section{Côté serveur}
\paragraph{}
Dans un premier temps, seul le côté client était pris en compte. Les programmes
étaient écrits en JavaScript et ne nécessitaient pas de serveur. Quand les
problématiques de dynamicité sont arrivées, il a fallu choisir une technologie
pour le côté serveur, et là, tous les langages étaient possibles.

\paragraph{}
Plusieurs langages et framework ont été téstés. Quand les problématiques
étaient encore simples (passage d'un paramètre dans une requête), on a commencé
par utiliser le php, puis on s'est tourné vers des scripts CGI en python. Quand
de plus nombreuses pages ont été nécessaires, on a commencé à chercher un vrai
framework, et on s'est penché sur Django (framework web pour Python) qui est
très pratique mais assez coûteux en mémoire vive (le serveur était alors
herbergé sur une petite machine de 512Mo de RAM).

\paragraph{}
Quand les problématiques de streaming ont commencé à apparaître, nous avons
choisi la simplicité en utilisant Node.js pour le côté serveur (un serveur
écrit en JavaScript) à cause de la présence d'une librairie nommée \socketio{}
qui s'avère très pratique pour la communication entre le client et le serveur.
Pour des raisons pratiques, le serveur a été herbergé sur un cloud gratuit
(OpenShift).

\section{Base de données}
\paragraph{}
Pour le système de gestion de base de données, nous avons choisi Postgres (qui
est libre et qui a largement fait ses preuves). OpenShift propose d'héberger
lui-même la base de données, mais la version gratuite ne proposant qu'1 Go
d'espace de stockage, nous avons préféré l'héberger nous-même.

\section{Développement, debug et déploiement}
\paragraph{}
Pour éviter d'avoir des fichiers trop longs, nous avons choisi de séparer les
sources dans de nombreux fichiers de taille plus petite, et de les fusionner
automatiquement. Pour le développement, ils seront simplement concaténés grâce
à un script développé spécialement pour cela, qui mime les paramètres de
Closure Compiler qui sera utilisé pour la fusion au moment du le déploiement
(ce dernier permet non seulement la fusion des fichiers mais aussi la
minification\footnote{la minification sert notamment à réduire la taille du
script : n'oublions pas que nous parlons de serveur web, et il est donc
intéressant de réduire la taille des programmes de sorte à les charger plus
rapidement} (effacement des commentaires et des retours à la ligne,
simplifications des noms de variables et plus \footnote{en JavaScript, il est
plus court d'écrire \texttt{!0} pour \texttt{true} par exemple.}). Pour le
développement, on a utilisé \href{https://github.com/remy/nodemon}{nodemon} et
inotify, qui permettent de relancer le serveur local lorsqu'une modification
est détectée (la fusion des fichiers est donc réeffectuée).

\paragraph{}
En ce qui concerne le versionnage des fichiers, nous avons utilisé Git avec
deux \emph{repositories} :
\begin{itemize}
    \item le premier, hébergé sur
        \href{https://github.com/tforgione/3dinterface}{Github}, sert au
        développement, et contient les fichiers fractionnés ainsi que les
        outils permettant la génération des fichiers fusionnés.
    \item le deuxième, hebergé chez OpenShift, qui contient la version finale
        du programme, permet de déployer le code du serveur quand les
        \emph{commits} sont \emph{pushés}.
\end{itemize}

\paragraph{}
Pour nous aider au debug, nous avons utilisé \href{http://jshint.com/}{JSHint}
qui nous aide à détecter les erreurs potentielles liées aux subtilités du
langage.

\section{Documentation}
Au delà des rapports, deux documentations sont présentes.

\subsection{\href{https://github.com/tforgione/3dinterface/wiki}{\emph{Github Wiki}}}
Github permet la création de Wiki pour chaque \emph{repository} et nous nous en
sommes servi pour de la documentation de haut niveau : il ne présente que des
aspects théoriques de ce qui a été réalisé pendant ce projet.

\subsection{\href{http://l3d.no-ip.org/}{L3D}}
Pour de la documentation de plus bas niveau (comment chaque classe ou méthode
fonctionne) nous avons utilisé \jsdoc{} (équivalent de javadoc mais pour
JavaScript) et nous générons automatiquement des pages html pour avoir une
documentation lisible et à jour sans avoir à parcourir le code.