correction of spelling mistakes in the report

rapport-A52.md

@@ -8,27 +8,27 @@ L'objectif du projet est de créer une application web et mobile communiquant av
 
 La pipeline se connecte via une clé SSH à notre VPS, y envoie une version compressée du projet, la décompresse puis lance des Docker. Ces Docker build l'API et l'application web pour les rendre accessibles et optimisées sur le VPS. Grâce aux clés SSH, c'est sécurisé. Avec les Docker, c'est facile. En compressant, cela permet de réduire drastiquement la quantité d'espace disque utilisé : un élément très important pour nous puisque nous utilisons jusqu'à la version finale exclue un VPS avec très peu d'espace disque.
 
-La pipeline n'a plus ni linting, ni test, pourquoi ? Les tests automatisés (unitaires, d'intégration, ...) sont pratiques sur la longueur, pour s'assurer du bon fonctionnement de l'application. Cependant, ils rajoutent une charge supplémentaires de travail lors de leur écriture, mais aussi sur la durée puisqu'ils faut les mettre a jour régulièrement en même temps que l'appli elle-même. Nos délais étant très serrés, nous devions constamment ajouter des fonctionnalités, sans le temps d'écrire des tests adaptés pour toutes. Quant aux grosses fonctionnalités, d'une complexité élevée ou avec un impact fort sur l'application, ils ont d'abord eu le droit à leur test unitaires et d'intégrations, avant de devoir être retirés, car trop obsolètes et par manque de temps pour les mettre à jour. L'approche Test driven development, étudié pour l'API au départ du projet, n'a dès lors pas été maintenue. Quant au linting, l'ajout d'husky (node module) permets d'appliquer automatiquement un formattage et applciation du linting de code au moment d'actions, de hooks git (commit, push, ...), supprimant le besoin de rejeter du code si celui-ci n'est pas assez bien formatté.
+La pipeline n'a plus ni linting, ni test, pourquoi ? Les tests automatisés (unitaires, d'intégration, ...) sont pratiques sur la longueur, pour s'assurer du bon fonctionnement de l'application. Cependant, ils rajoutent une charge supplémentaire de travail lors de leur écriture, mais aussi sur la durée puisqu'il faut les mettre à jour régulièrement en même temps que l'appli elle-même. Nos délais étant très serrés, nous devions constamment ajouter des fonctionnalités, sans le temps d'écrire des tests adaptés pour toutes. Quant aux grosses fonctionnalités, d'une complexité élevée ou avec un impact fort sur l'application, elles ont d'abord eu le droit à leurs tests unitaires et d'intégration, avant de devoir être retirées, car trop obsolètes et par manque de temps pour les mettre à jour. L'approche Test driven development, étudiée pour l'API au départ du projet, n'a dès lors pas été maintenue. Quant au linting, l'ajout d'husky (node module) permet d'appliquer automatiquement un formatage et application du linting de code au moment d'actions, de hooks git (commit, push, ...), supprimant le besoin de rejeter du code si celui-ci n'est pas assez bien formaté.
 
 ### Image Docker
 
-Les docker build l'api et le web et les expose sur les ports du pc. le docker compose orchestre leur execution et leurs variable d'environement.
+Les docker build l'api et le web et les exposent sur les ports du pc. Le docker compose orchestre leur exécution et leurs variables d'environnement.
 
-sudo docker compose up -d --remove-orphans --build permet de force le build des dockers si jamais les images ont changés, remove orphan de supprimer les service inutilisés (suite à de smises à jour)
+sudo docker compose up -d --remove-orphans --build permet de forcer le build des dockers si jamais les images ont changé, remove orphan de supprimer les services inutilisés (suite à des mises à jour).
 
 ## Gestion du dépôt Git
 
 1. **Messages de commit :**
 
-Au début du projet, nos commits se devaient d'être atomique et avaient un nombre limité de mots dans le message (15 par convention)
+Au début du projet, nos commits se devaient d'être atomiques et avaient un nombre limité de mots dans le message (15 par convention).
 
 Après les cours d'A52, nous avons fait sauter cette seconde convention.
 
 2. **Processus de revue de code :**
 
-Malgré le manque de délai, nous avons essayé de review le code de l'application web à deux, entre les 3 personnes les plus concerné sur ce côte de l'application : Maxime, Samuel et Jawad.
+Malgré le manque de délai, nous avons essayé de review le code de l'application web à deux, entre les 3 personnes les plus concernées sur ce côté de l'application : Maxime, Samuel et Jawad.
 
-On commençait par une démo de la feature ou correction. Pour repérer les élements les moins ergnomique ou étranges. Puis nous regardions le code ajouté, en discutant du "pourquoi telle méthode", "pourquoi pas une autre".
+On commençait par une démo de la feature ou correction. Pour repérer les éléments les moins ergonomiques ou étranges. Puis nous regardions le code ajouté, en discutant du "pourquoi telle méthode", "pourquoi pas une autre".
 
 Mais la plupart du temps, nous ne pouvions (par manque de temps) qu'essayer l'application via le front mobile ou web et, si cela fonctionnait, merge request et continuer de coder.
 
@@ -43,17 +43,17 @@ Voici le workflow, dispo sur notre confluence ( <https://glazk.atlassian.net/wik
 
 - En choisir une et vous l'assigner
 
-- _Eventuellement, créez vous-même des sous-tâche dans votre issue actuelle pour montrer votre avancée à vos coéquipiers et/ou vous aider à réfléchir_
+- _Éventuellement, créez vous-même des sous-tâches dans votre issue actuelle pour montrer votre avancée à vos coéquipiers et/ou vous aider à réfléchir_
 
-- Appuyez sur la flèche bleu à côté de `create merge request` et choisissez `create-branch`
+- Appuyez sur la flèche bleue à côté de `create merge request` et choisissez `create-branch`
 
 - Changez le nom de la branche pour suivre les conventions (exemple feature-xxx)
 
 - Sélectionner `develop` en tant que source
 
-- En local, faites un `git fetch origin --all --prune` pour récuperer notamment votre branche (**attention --prune supprime les branches qui ont été complètement mergées/supprimées sur origin**)
+- En local, faites un `git fetch origin --all --prune` pour récupérer notamment votre branche (**attention --prune supprime les branches qui ont été complètement mergées/supprimées sur origin**)
 
-- Faite un `git switch feature-xxx`
+- Faites un `git switch feature-xxx`
 
 - Travaillez et commitez dessus
 
@@ -63,11 +63,11 @@ Voici le workflow, dispo sur notre confluence ( <https://glazk.atlassian.net/wik
 
 - Sur Gitlab, appuyez sur 'compare' puis 'créer merge request' OU directement sur 'créer merge request' s'il est proposé
 
-- Assignez qqun en reviewer (Jawad, Samuel et/ou Nicolas en priorité, vos autres collègues sinon)
+- Assignez quelqu'un en reviewer (Jawad, Samuel et/ou Nicolas en priorité, vos autres collègues sinon)
 
 - Cochez les options `delete source` et `squash`
 
-- Confirmez, la merge requets est maintenant créée
+- Confirmez, la merge request est maintenant créée
 
 - Choisissez une nouvelle tâche (\> voir section d'au-dessus)
 
@@ -100,13 +100,13 @@ _Votre tâche sera validée ou non par votre reviewer, qui mettra en commentaire
 
 4. **Documentation :**
 
-Nous avions une documentation très détaillé en début de projet, surtout pour l'api, disponible sur notre Confluence <https://glazk.atlassian.net/wiki/spaces/DL/pages/4456450/API> avec les routes, les types DTO, etc. Chaque ligne de code (à peu de chose près) avait le droit à son petit commentaire.
+Nous avions une documentation très détaillée en début de projet, surtout pour l'api, disponible sur notre Confluence <https://glazk.atlassian.net/wiki/spaces/DL/pages/4456450/API> avec les routes, les types DTO, etc. Chaque ligne de code (à peu de chose près) avait le droit à son petit commentaire.
 
-Néanmoins, il était non seulement très long de mettre à jour et nous faisais perrdre du temps mais aussi trop pénible à lire.
+Néanmoins, il était non seulement très long de mettre à jour et nous faisait perdre du temps mais aussi trop pénible à lire.
 
-Nous avons donc réduit la documentation au strict minium : un swagger (qui génère et affiche la documentation avec peu d'ajout de code) et des commentaires de code seulement là où nécessaire (code difficle à comprendre ou à ne pas modifier).
+Nous avons donc réduit la documentation au strict minimum : un swagger (qui génère et affiche la documentation avec peu d'ajout de code) et des commentaires de code seulement là où nécessaire (code difficile à comprendre ou à ne pas modifier).
 
-Au départ sur gitlab wiki, nous les avons déplacer sur Confluence en même temps que nos issues sur Jira (même environnement) pour un devoir de Management. Avec la réduction des besoins de documentation (raisons exprimé plus haut et fait qu'on retiens les convention à force), nous avons laissé sur confluence. Cependant, nous sommes revenus sur Gitlab issue afin de profiter des nombres automatisation : créer une branche et une merge request covnentionnée en un clic, pouvoir réferer des tâches, des soucis, des branches, des utilisateurs à n'importe quel endroit pour éviter d'avoir à naviguer pendant des heures pour trouver ce qu'on cherche.
+Au départ sur gitlab wiki, nous les avons déplacés sur Confluence en même temps que nos issues sur Jira (même environnement) pour un devoir de Management. Avec la réduction des besoins de documentation (raisons exprimées plus haut et fait qu'on retient les conventions à force), nous avons laissé sur Confluence. Cependant, nous sommes revenus sur Gitlab issue afin de profiter des nombreuses automatisations : créer une branche et une merge request conventionnée en un clic, pouvoir référer des tâches, des soucis, des branches, des utilisateurs à n'importe quel endroit pour éviter d'avoir à naviguer pendant des heures pour trouver ce qu'on cherche.
 
 5. **Conventions de programmation :**
 
@@ -151,7 +151,7 @@ Toujours faire des merge request
 
 - feature-xxx (purement pour les nouvelles features)
 
-- fix-xxx (purement pour les corrrections de features et regressions)
+- fix-xxx (purement pour les corrections de features et régressions)
 
 ####  Commits
 
@@ -168,13 +168,13 @@ Messages libres, pas de limitation particulière mais soyez précis et granulair
 ### Info sensibles
 
 - Assurez-vous qu'aucune information sensible n'apparaît dans le dépôt ou sur GitLab.
-- Pour les fichier d'environnements (.env), voyez avec le responsable du side-end associé (Samuel pour l'api, Jovanny pour le mobile, Maxime pour le web)
+- Pour les fichiers d'environnements (.env), voyez avec le responsable du side-end associé (Samuel pour l'api, Jovanny pour le mobile, Maxime pour le web)
 
 ```
 
 6. **Informations sensibles :**
    - Les variables d'environnement, mot de passe, etc devaient passer uniquement sur des canaux de messagerie privés.
-   - Ayant eu des problèmes initiaux avec la pipeline gitlab, affichant ainsi les mots de passes, ip et environnements de notre machine de test, la pipeline a été sécurisé par la suite grâce aux variables d'environnement gitlab, des clés ssh pour la connexion (comme dit plus haut) et toutes les informations ont été changées !
+   - Ayant eu des problèmes initiaux avec la pipeline gitlab, affichant ainsi les mots de passe, ip et environnements de notre machine de test, la pipeline a été sécurisée par la suite grâce aux variables d'environnement gitlab, des clés ssh pour la connexion (comme dit plus haut) et toutes les informations ont été changées !
 
 ## Conclusion
 
@@ -193,4 +193,4 @@ Messages libres, pas de limitation particulière mais soyez précis et granulair
 - Documentation Confluence : https://glazk.atlassian.net/wiki/spaces/DL/pages
 
 2. **Contacts :**
-   - Vous pouvez contacter notre équipe, si besoin, en ouvrant une issue sur le gitlab du projet ! Rendez vous sur https://git.unistra.fr/the-sevens/the-sevens/-/issues/new 
+   - Vous pouvez contacter notre équipe, si besoin, en ouvrant une issue sur le gitlab du projet ! Rendez vous sur https://git.unistra.fr/the-sevens/the-sevens/-/issues/new