TD: 1.1.4

tech_documentation/ci.tex

@@ -8,4 +8,6 @@
 
 
 Ces vérifications permettent d’assurer que le nouveau code soit valide, et ne ‘casse’ pas la production.
-La validation de chacune de ces étapes pour chaque composant du projet est nécessaire avant de pouvoir fusionner une branche sur main, et ainsi créer une release du projet.
+La validation de chacune de ces étapes pour chaque composant du projet est nécessaire avant de pouvoir fusionner une branche sur main, et ainsi créer une release du projet.
+
+Le choix des GitHub Actions pour gérer la CI se justifie par leur facilité d'utilisation et leur integration facile avec les issues, pour traquer leur avancement.

tech_documentation/dev.tex

@@ -1,8 +1,11 @@
 Pour créer une instance locale du serveur, du scorometer et de l’application il faut:
-Cloner le dépôt GitHub.
-Remplir un fichier .env en prenant exemple sur le fichier \verb|.env.exemple| présent dans le dépôt.
 
-Exécuter la commande: \verb|docker-compose -f docker.compose.dev.yml up –build|.
-\\\\
+\begin{itemize}
+	\item Cloner le dépôt GitHub.
+	\item Remplir un fichier .env en prenant exemple sur le fichier \verb|.env.exemple| présent dans le dépôt.
+	\item Exécuter la commande: \verb|docker-compose -f docker.compose.dev.yml up –build|.
+\end{itemize}
+
+
 Le serveur est accessible depuis \verb|localhost:5000|, et l’application Web depuis \verb|localhost:19006|.
 

tech_documentation/front.tex

@@ -1,19 +1,18 @@
 Le code source de l’application front est dans le  dossier \verb|./front|.
-L’application Front-end est développée en React-Native, bootstrapé avec Expo.
+L’application Front-end est développée en React-Native, bootstrapé avec Expo. Ce sont les seules technologies stables permettant d'avoir une seule code-base pour un projet à la foix web et mobile. De plus, de nombreuses librairies tierces sont disponibles. 
 \\\\
-Concernant les communications avec l’API, les requêtes sont encapsulées dans le fichier API.ts. Les requêtes passent par les fonctions utilitaires de react-query (ex: \verb|useQuery|) qui permet de gérer facilement les états de chargement et d’erreurs.
+Concernant les communications avec l’API, les requêtes sont encapsulées dans le fichier API.ts. Les requêtes passent par les fonctions utilitaires de react-query (ex: \verb|useQuery|) qui permet de gérer facilement les états de chargement et d’erreurs, dans un paradigme réactif.
 \\\\
-L’application utilise un store Redux pour persister, rehydrater, et hook-er des paramètres de connexion (ex: access token) et les paramètres utilisateurs (thème, language).
+L’application utilise un store Redux pour persister, rehydrater, et hook-er des paramètres de connexion (ex: access token) et les paramètres utilisateurs (thème, language). Cette librairie est tres populaire et stable. 
 \\\\
 L’identité visuelle et le style associés sont mis en place grâce à la bibliothèque de style native-base. La configuration du thème est dans Theme.tsx. Le hook dans \verb|./hooks/colorScheme.ts| permet d’accéder à la configuration du thème (clair ou foncé) en fonction des paramètres de l’application et du navigateur.
 \\\\
 La navigation est gérée par react-navigation. Le fichier \verb|Navigation.tsx| met en place les routes disponibles en fonction de l’état de connexion de l’utilisateur (anonyme ou connecté).
 \\\\
-Les types des réponses de l’API sont validées au runtime grâce à la bibliothèque YUP. Les validateurs et modèles associées sont dans le dossier \verb|./models|.
+Les types des réponses de l’API sont validées au runtime grâce à la bibliothèque YUP. Les validateurs et modèles associées sont dans le dossier \verb|./models|. Cette librairie a ete choisie car elle est facile d'utilisation, d'integration et à maintenir dans le projet.
 \\\\
 Le support des traductions (Français, Anglais, Espagnol) sont faites avec le package react-i18n. Les valeurs des traductions sont dans le dossier \verb|./i18n|.
 \\\\
-Concernant la connexion au piano MIDI, l’application utilise l’API MIDI supportée par le navigateur.
-L’affichage de la partition est faite avec le package OpenSheetMediaDisplay.
+Concernant la connexion au piano MIDI, l’application utilise l’API MIDI supportée par le navigateur et les mobiles.
 \\\\
-La gestion des paquets se fait avec Yarn.
+La gestion des paquets se fait avec Yarn, car il permet une meilleure gestion des sous-dependences que npm.

tech_documentation/norme.tex

@@ -1,5 +1,6 @@
 Le nombre de contributeurs.euses sur le projet étant important, il est important que chacun.e suivent la même norme de code afin d’avoir une codebase homogène.
 Pour cette raison, ont été mis en place un Linter (eslint) et un Prettier (prettier) qui permettent respectivement d'identifier les erreurs de norme (définies au préalables) et d’appliquer la correcte indentation et sauts de ligne.
+Ces 2 outils ont été choisies car elles sont les plus populaires dans leurs domaines, et sont facile à integrer et utiliser.
 \\\\
 Le fichier de configuration eslint est \verb|./front/.eslintrc.json|. La documentation des règles utilisées est disponible sur le site d’eslint.
 \\\\

tech_documentation/revisions.tex

@@ -3,5 +3,6 @@
 18-11-2023 & 1.1.1   & Arthur JAMET & Résumé   & Réécriture du résumé \\
 18-11-2023 & 1.1.2   & Arthur JAMET & 3.1      & Ajout d'une description pour les tables de la DB
 18-11-2023 & 1.1.3   & Arthur JAMET & 2        & Ajout d'une description des relations entre les services
+18-11-2023 & 1.1.4   & Arthur JAMET & 3 à 5    & Ajout des justifications des techno utilisées
 
 

tech_documentation/scorometer.tex

@@ -1,6 +1,6 @@
 Le code source du scorometer est dans le dossier \texttt{./scorometer}.
 \\\\
-C’est un serveur de websocket qui utilise websocketd et développé en python.
+C’est un serveur de websocket qui utilise websocketd et développé en python. La raison de ce choix sont la facilité de development, et le grand support des librairies. 
 Websocket est un outil qui permet de faire un serveur de websocket en utilisant la stdin et stdout d’un autre programme, concrètement le code en python a seulement besoin de read la stdin pour avoir les nouveaux messages et écrire sur la sortie standard pour en envoyer.
 \\\\
 Pour parser les différents types de messages que le client front-end peut envoyer, on utilise la fonction \texttt{getMessage} qui renvoie une union de types des messages disponibles. Il suffit ensuite de match sur le résultat de \texttt{getMessage} en fonction du type de message qu’on veut gérer.

tech_documentation/server.tex

@@ -1,6 +1,6 @@
-Le code source du server est dans le dossier \texttt{./back}. Le serveur est développé en TypeScript, avec le framework NestJS.
+Le code source du server est dans le dossier \texttt{./back}. Le serveur est développé en TypeScript, avec le framework NestJS. Ce dernier a ete choisit car il permet de gerer facilement et rapidement des CRUD.
 \\\\
-L’ORM utilisé est Prisma. La définition des schéma se trouve dans \texttt{./prisma/schema.prisma}. (cf. Section “Base de données”).
+L’ORM utilisé est Prisma. La définition des schéma se trouve dans \texttt{./prisma/schema.prisma}. (cf. Section “Base de données”). L'ORM a été choisit car il permet de maintenir une type-safety tout le long de l'utilisation des données extraites de la BDD
 \\\\
 L’application est basée sur l'injection de dépendances. Les modules sont les suivants:
 
@@ -23,6 +23,6 @@
 \\\\
 La documentation de l’API du serveur se présente sous la forme d’un Swagger accessible depuis \url{https://nightly.chroma.octohub.app/api/api}
 \\\\
-La gestion des paquets se fait avec NPM.
+La gestion des paquets se fait avec NPM, car il est plus facilement utilisable que yarn pour NestJS.
 \\\\
 Les tests du serveur sont des tests End-To-End (E2E) faits en Robot, qui testent les méthodes de CRUD (Creation, Read, Update, Delete) des controllers.