112 lines
5.5 KiB
TeX
112 lines
5.5 KiB
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.
|
|
|
|
|