Salut à tous! Il est lundi matin ici, petit bilan de l’appel communauté/développeur de samedi après-midi! Au final, l’appel était vraiment plus centré développeur, et je ne l’ai pas enregistré car @MathieuA montrait son écran au début et je ne voulais pas filmer son desktop 
Je fais donc ici un petit compte rendu écrit pour vous tenir au courant de ce qui s’est dit.
Le premier retour que plusieurs membres ont fait, c’est leur inquiétude par rapport à certains bugs de la v3 qu’ils aimeraient voir résolu avant le lancement des chantiers sur la v4. On a donc décidé qu’on allait faire une passe sur tous les bugs actuels en leur donnant 2 notes:
- une note sur la criticité du bug (Beaucoup de personnes affectées? Gêne beaucoup les nouvel arrivants sur le projet ?)
- une note sur la complexité du bug (Est-ce que c’est un bug simple à résoudre ou est-ce que c’est un problème général plus dû à l’architecture de Gladys et qui sera fixé par Gladys 4?)
J’ai donc créé un spreadsheet en ligne pour référencer les bugs : Bug Gladys 3 - Google Tabellen, n’hésitez pas à le remplir si vous pensez à des bugs 
Attention: on parle bien de bug, de problème de stabilité, mais en aucun cas de fonctionnalités: pour cela il y a la v4!
Un des sujets dont nous avons parlé longuement, c’est au niveau des process de merge des PRs. Actuellement, il y a ensemble de points qui font que le testing et le merge des PR n’est vraiment pas facile.
Le tooling actuellement dans Gladys 3 est un tooling qui date d’il y a 3 ans (d’ou l’ambition de changer ce tooling dans Gladys 4) :
- le Frontend est une webapp AngularJS buildée avec grunt et uglifyJS. Ces deux outils sont beaucoup plus permissif que les outils de développement JavaScript moderne de 2019, et ainsi actuellement il y a très peu de checks automatisé. L’injection de dépendances dans AngularJS ne permet pas au compilateur de savoir si il y a des erreurs de fonctions inexistantes, et uglifyJS ne fait aucune analyse statique de code. Quand quelqu’un submit une PR, la PR va builder et passer. Si je télécharge la branche localement, lance Gladys: tout va tourner. Je me promène, je clique à droite à gauche: tout passe. Et pourtant, dans cette PR il peut y avoir une variable quelque part définie nul part (erreur de frappe, ou de copier coller, dépendance non incluse), qui lorsque le testeur de la PR (ou un utilisateur si on ne voit pas le bug) passe dans le cas: et bien on a un bug infâme dans la console JS (Ex: $scope is not defined ), et côté utilisateur, ça ne marche pas et on ne comprend pas pourquoi. Sur ce sujet, l’ambition est de configurer le projet Gladys 4, et d’utiliser des outils faisant en sorte que rien de tout ça ne soit possible, afin d’avoir des PR et une codebase bien plus “clean” et beaucoup plus simple à tester.
- Le backend est une app Node.js >= 8. Un outil de de check statique est présent (Eslint), mais au niveau des règles, peu de règles critiques sont activées. L’ambition dans Gladys 4 est d’être beaucoup plus strict là dessus. Nous avons parlé de TypeScript, qui apporte une rigueur évidente, mais présente un risque pour le projet si cet outil n’est plus utilisé dans 3 ans. Une solution plus simple à mettre en place est les check de type statique avec JSdoc.
Au niveau des PR, nous avons aussi parlé du processus de publication des PRs. J’ai ajouté récemment un outil sur GitHub (WIP) qui vous permet de rajouter “WIP” dans le titre de votre PR pour indiquer qu’elle est “Work In Progress” et que donc il n’est pas encore temps de la merger. Ainsi, au lieu de publier la PR à la fin de votre travail, vous la publier dès la 1ere minute où vous commencer à coder, et tout le monde peut suivre les développements en court. Cet outil indique dans le statut de la PR qu’elle est en court, ainsi il n’est même pas possible de la merger! Cela évite deux choses:
- Bosser 1 mois sur une PR pour se rendre compte à la fin qu’elle ne correspond pas vraiment à quelque chose qu’on souhaitait dans Gladys
- Bosser sur un sujet où quelqu’un travail déjà dessus.
Enfin, je vais probablement publier aujourd’hui mon travail de la semaine dernière sur l’Open API du Gladys Gateway. L’article sera publié dans la journée, vous recevrez une newsletter
