Compte_rendu.md

@@ -2,52 +2,53 @@
 
 ### Accès au projet
 
-Générez une clé ssh sur la machine qui sera votre serveur via la commande `ssh-keygen`. Installez-la, au besoin, via la procédure indiqué sur internet pour votre OS.
+Générez une clé SSH sur la machine qui sera votre serveur via la commande `ssh-keygen`. Installez-la, au besoin, via la procédure indiquée sur Internet pour votre OS.
 
-Rendez-vous suir gitlab. Allez dans votre profile, onglet "SSH keys".
+Rendez-vous sur GitLab. Allez dans votre profil, onglet "SSH keys".
 
 Ajoutez votre clé publique avec le bouton associé.
 
 ### Clonage du projet
 
-Rendez-vous sur la machine qui sera votre serveur, dans le dossier de votre choix
+Rendez-vous sur la machine qui sera votre serveur, dans le dossier de votre choix.
 
-Clonez les deux repo git dans ce dossier, via
+Clonez les deux repos Git dans ce dossier, via :
 
 ```bash
 git clone git@git.unistra.fr:jagermasters/gyokeres-web-rebirth.git
 git clone git@git.unistra.fr:jagermasters/gyokeres-api-rebirth.git
 ```
 
-### Installation de docker
+### Installation de Docker
 
-Via la documentation officielle, installez [Docker engine](https://docs.docker.com/engine/install/) et [Docker compose](https://docs.docker.com/compose/install/)
+Via la documentation officielle, installez [Docker Engine](https://docs.docker.com/engine/install/) et [Docker Compose](https://docs.docker.com/compose/install/).
 
 ### Création du réseau inter-services
 
-Créez le network permettant à tous les services et le proxy de communiquer ensemble, via
+Créez le network permettant à tous les services et au proxy de communiquer ensemble, via :
 
 ```bash
-docker network create the_all_knowing`
+docker network create the_all_knowing
 ```
 
 ### Initialisation du proxy (optionnel)
 
-Si vous souhaitez choisir le nom de domaine à utuiliser et/ou simplement sécuriser l'accès à votre machine par les utilisateuers du site, récuperez le fichier `compose.yml` sur le [repo git d'aide au déploiement](https://git.unistra.fr/jagermasters/gyokeres-deploy-assistance).
+Si vous souhaitez choisir le nom de domaine à utiliser et/ou simplement sécuriser l'accès à votre machine par les utilisateurs du site, récupérez le fichier `compose.yml` sur le [repo Git d'aide au déploiement](https://git.unistra.fr/jagermasters/gyokeres-deploy-assistance).
 
-Rangez le dans le dossier de votre choix, puis lancez le nginx proxy manager (NPM) via
+Rangez-le dans le dossier de votre choix, puis lancez le Nginx Proxy Manager (NPM) via :
 
 ```bash
 docker compose up -d
 ```
 
-Rendez vous sur [l'interface de NPM](localhost:81)
+Rendez-vous sur [l'interface de NPM](localhost:81).
 
 Par défaut, l'email est `admin@example.com` et le mot de passe est `changeme`. Vous pouvez ensuite choisir celui que vous voulez.
 
-Cliquez sur "Proxy host" puis "Add proxy host" et entrez les informations suivantes : ![config_proxy_host](config_proxy_host.png). _Les noms de domaines demandez peuvent sit être votre IP (si vous possédez une IP privée ou que vous ne voulez pas de nom de domaine) ou le nom que vous avez acheté au préalable (à OVH, cloudflare ou autre)_
+Cliquez sur "Proxy host" puis "Add proxy host" et entrez les informations suivantes : ![config_proxy_host](config_proxy_host.png).  
+_Les noms de domaine demandés peuvent soit être votre IP (si vous possédez une IP privée ou que vous ne voulez pas de nom de domaine), soit le nom que vous avez acheté au préalable (à OVH, Cloudflare ou autre)._
 
-Si vous possédez une IP publique, vous pouvez aussi demander un nginx la création d'un certificat SSL (crypte les échanges sur le réseau pour plus de sécurité), aussi parfois nommé "le petit cadena sur google", via :
+Si vous possédez une IP publique, vous pouvez aussi demander à Nginx la création d'un certificat SSL (qui crypte les échanges sur le réseau pour plus de sécurité), aussi parfois nommé "le petit cadenas sur Google", via :
 
 ![ssl](ssl.png)
 
@@ -55,7 +56,7 @@ Si vous possédez une IP publique, vous pouvez aussi demander un nginx la créat
 
 Dernière ligne droite !
 
-Rendez vous là où vous avez cloné le projet (web et api) et, dans chacun des dossier, lancez les containers via
+Rendez-vous là où vous avez cloné le projet (web et API) et, dans chacun des dossiers, lancez les containers via :
 
 ```bash
 docker-compose -f docker-compose.prod.yml up -d
@@ -65,9 +66,13 @@ docker-compose -f docker-compose.prod.yml up -d
 
 # Prise en main
 
+## Technologies
+
+L'api utilise des technos vu en cours (prisma, express, jwt, etc) ou utilisé dans nos anciens projet (swagger, etc). L'extension et la maintanbilité ne devrait pas poser trop de problème.
+
 ## Ancien protocole d'installation
 
-Au besoin, les rares anciennes documentations et info transmise par l'ancien groupe en charge du développement de Gyokerske sont disponibles ici.
+Au besoin, les bribes de documentation et infos transmises par l'ancien groupe en charge du développement de Gyokereske sont disponibles [ici](https://git.unistra.fr/jagermasters/gyokeres-deploy-assistance/-/blob/main/Ancien%20protocole.md?ref_type=heads). Nous y avons ajouté un guide de création d'APK pour distribuer l'application mobile.
 
 ## Problèmes repérés
 
@@ -85,6 +90,35 @@ Au besoin, les rares anciennes documentations et info transmise par l'ancien gro
 - Le style de la modal pour rejoindre est affreux, c'est du natif HTML sans CSS
 - Modes multi ont une connexion instable
 - Modes multi sont affreusement lents (problème d'ergonomie, long à redévelopper)
-- Dans la CI/CD les tests et le lint ne marche pas, dans le sens où il est mal configuré, il manque des dépendances
+- Dans la CI/CD, les tests et le lint ne marchent pas, dans le sens où ils sont mal configurés et il manque des dépendances
 
 # Notes complémentaires
+
+## Interactions inter-équipes
+
+Deux groupes sont venus nous redemander un petit topo sur mon ancien projet, Kwizos, car la doc n'était pas à jour par manque de temps. Je leur ai fourni des instructions simplifiées et à jour (non pushées pour rester dans la logique du RP) expliquant comment j'avais réussi à déployer le projet.
+
+Un groupe est revenu me voir quelque temps plus tard, car les instructions étaient erronées... Sauf qu'en discutant plus longuement avec eux, j'ai bien vu que les membres :
+
+- n'ont soit pas lu les instructions, préférant RE-demander des choses déjà dites dans une doc pourtant concise (car l'ancienne doc était aussi trop longue selon eux)
+- ont choisi une branche aléatoire pour déployer (pourquoi ?)
+- revenaient me voir pour me demander si telle ou telle feature était en place, pour que je leur indique que "oui, comme c'est visible dans l'interface", avant de voir qu'ils n'ont même pas essayé de lancer...
+- me demandaient pourquoi il n'y a pas de script pour lancer facilement l'application entière (ex : un `init.sh`), alors que nous avons suivi la logique de `docker-compose`, qui le fait déjà à votre place en une seule commande simple, à la fois dispo sur notre doc, sur la documentation officielle (et ayant été vue en cours si on sort du RP).
+
+En tant que membre ayant écrit plus de 60% du projet _Kwizos by The Sevens_, j'ai bien conscience que certaines fonctionnalités sont instables... Contrairement au déploiement, qui a fonctionné sur plusieurs machines différentes au fil du projet, de manière efficace, puisque nous avons dû changer trois fois d'hébergement de serveur (j'ai même dû le remanier plusieurs fois pour pouvoir le lancer sur ma propre petite Raspberry Pi).
+
+Je suis juste surpris par les bruits de couloir, les groupes qui râlent sans demander d'indications pour autant, et je m'inquiète du manque d'interaction avec les membres de _The Sevens_ alors que TOUS _devraient être_ disponibles pour répondre aux questions, _pas seulement moi_.
+
+Il faut donc avouer que, de mon point de vue, la situation est telle qu'une partie des groupes ayant reçu Kwizos part du principe que "le projet n'a pas l'air bien à première vue, ils n'ont pas eu une bonne note, alors je ne fais rien et renverrai la faute sur les autres". Là où l'autre moitié tente des choses... extravagantes (même si je ne saurais dire s'ils le font pour le roleplay ou non).
+
+J'ai déjà subi la douloureuse note de ce projet lors du développement, j'aurais tout fait pour aider les membres des autres groupes (sans pour autant leur faire 100% du travail). Donc je voulais mettre en garde ici, pour la correction, afin de ne pas entrer dans un cercle vicieux non mérité.
+
+Enfin, et cette fois pour être plus taquin, je précise que le groupe qui nous a le plus critiqués de face, en tout bien tout honneur, a lui aussi des problèmes avec son ancien projet (aucune documentation, script modifiant les configurations Docker bloquant des projets pourtant indépendants, non-respect de beaucoup de conventions vues en cours et présentes en entreprise, ...). Or là, les gens (nous et les autres groupes l'ayant reçu) essayent et réussissent à déployer !
+
+-- Samuel
+
+## Configuration de Docker
+
+Le script de lancement du groupe Gyokereske apporte une configuration spécifique à Docker tout en "forçant" l'utilisateur à être sur une machine Linux.
+
+Autant la deuxième anomalie est réglable en précisant une image Docker basée sur Linux (ex : les versions "Alpine" des images X ou Y), autant la première a perturbé le projet d'alternance et provoqué plusieurs heures de debug sur un projet qui n'avait pourtant rien à voir...

Externe.md

-# FAQ
-
-## Interactions inter-équipes
-
-Les groupes sont venus nous redemander un petit topo car la doc n'était pas à jour. Nous leur avons fourni un README simplifié et à jour (non push pour rester dans la logique du rp), et effectivement nous avons pu déployer de notre côté notre projet en suivant les instructions.
-
-Une partie des groupes est revenu nous voir, quelques temps plus tard, car les instructions étaient erronées... Il s'avère que ces groupes :
-
-- n'ont soit pas lu les instructions, préférant RE-demander des choses déjà dites dans une doc pourtant concise
-- choisi une branche aléatoire au lieu du main ou même du develop pour déployer (pourquoi ?)
-- pas essayé de lancer... et revenait nous voir pour savoir si telle ou telle feature avait été mise en place...
-
-Autrement dit, on voit ici le principe du "le projet n'a pas l'air bien à première vue", "alors je ne fais rien et renverrai la faute sur les autres". Sachant évidement que les mêmes problèmes sont rencontrés pour leur ancien projet, mais les gens essayent et réussissent. 
-
-## Configuration du docker
-
-Le script de lancement du groupe Gyokereske apporte une configuration spécifique à docker tout en "forçant" l'utilisateur à être sur une machine linux.
-
-Autant la deuxième anomalie est réglable en précisant une image docker basée sur linux (exemple les versions "alpines" des images x ou y), autant la première a perturbé le projet d'alternance et provoqué plusieurs heures de debug sur un projet qui n'avait pourtant rien à voir...

todo.md

-- dans prochaine etape du projet : doit changer les valeurs de CI/CD ! (genre user et ip) et les mettre dans jogurmand
+- tester pour voir su proxy host marche
+- mettre ufw (firewall) et fermer les ports
+- réecrire les Readme au propre (les secitons conventionnelles à mettre, etc)
+- copier coller les questions de moodle sur la faq et y répondre
+- regarder un peu le code et en parler dans "prise en main" du compte rendu
+- déplacer les "init.sh" dans les compose/dockerifle directement (enelver dos2unix etc)
 
-tester de cloner les deux repo, lancer les containers, mettre ufw
+# Prochaine étape
 
-
-- ecrire les Readme (car faut rendre un git propre)
+Dans prochaine etape du projet : doit changer les valeurs de CI/CD ! (genre user et ip) et les mettre dans jogurmand