Enfin, l’équipe se retrouve !

Malgré quelques absents, nous avons pu vivre des instants de partage et d’échanges incroyables au Châteauform de Faverges-de-la-Tour, que nous avions été contraints d’abandonner en juin dernier… Grâce à leur professionnalisme et à des conditions sanitaires rigoureuses, tous les KNPeers présents ont pu travailler sur des projets qui leur tenaient à cœur, dans une ambiance décontractée, festive, chaleureuse, curieuse, créative et toujours innovante !

Avant de commencer à vous raconter le déroulement de ce Hackathon, il est important de remercier Laet pour avoir maintenu la tenue de ce hackathon, à Châteauform et leurs hôtes pour la mise en place d’un protocole anti-covid aux petits oignons et Amandine pour l’organisation de ce hackathon. Coeur avec les doigts sur vous.

Comme toujours à KNP, chaque KNPeer peut proposer un ToyProject ; chaque KNPeer est libre de rejoindre une Team ; chaque KNPeer peut proposer un sujet de discussion, présenter un sujet via des CoffeeTalks, ou animer un jeu / un atelier. Cette année, au programme notre équipe a préparé 7 toyprojects, concocté 3 workshops, et animé 5 discussions / conférences. Ça vous donne envie d’en savoir plus ?

Présentation des ToyProjects

Team Wall Of Chèvres

Le but de ce toy-project est de construire un système de badge à la Steam (mais propre à KNP) à partir d’une récolte de données compilées et publiées sur Slack. Les badges pourront être utilisés plus tard sur le wiki KNP (réalisé au Hackathon précédent) et à terme, imprimés sur de vrais badges.

Au cours de ce Hackathon, nous avons implémenté un badge correspondant à l’ancienneté des Knpeers. Nous avons donc, à l’aide de l’outil RabbitMQ en asynchrone, deux workers dont le but est d’écouter ce qu’envoie RabbitMQ, lui-même pluggé sur mongoDB et l’API Slack avec Symfony. Ce prototype est fonctionnel et testé. Il n’y a pas de front, car les badges seront affichés directement dans slack (et plus tard sur le wiki) mais on a réfléchi à un système de templating dynamique pour les badges à base de SVG.

Ce qui a été intéressant sur ce projet c’est la réflexion autour des fonctionnalités et la mise en place des badges.

Leur feedback :

Quentin : J’ai bien aimé réfléchir sur les fonctionnalités et les idées. C’est la première fois que j’ai travaillé sur un projet avec autant de services, je ne voyais pas au début où Pedro voulait aller :D

Olivia : J’ai géré les images pour générer les badges. Au lieu de faire des badges en dur, je voulais faire des SGV avec un texte dynamique. Plus tard avec Imagemagick.

Grégoire : Je me suis occupé du worker, qui permet d’envoyer des notifications sur slack. C’était intéressant de m’attaquer à Symfony que je ne connaissais pas encore. Ça m’a vraiment fait avancer sur ma compréhension de Symfony. J’ai aimé utiliser les handlers, appeler l’api slack. Là où c’était plus compliqué, c’est de nager dans trop d’informations, par exemple niveau syntaxe.

Pedro : Les deux services qu’on a créés sont testés et ils tournent sur circle. Je me suis amusé :)

Team NikoNiko

NikoNiko est un projet qui a été réalisé entre minuit et 3 heures du mat’ par Alu et sur lequel Cécile et Nico (et Alu) avaient bossé au dernier hackathon confiné! Pour ce Hackathon nous avons souhaité surtout nous concentrer sur le refactoring et des tests ; c’est d’ailleurs réussi car on est passé de 0 à 80% de tests. Et la petite surprise, c’est qu’on a également réalisé 3 petites features en plus !

Celle réalisée par Yoann, c’est le tri des différentes moods. Grâce à Nico, nous avons la possibilité de poster le message du jour de manière non-anonyme si on le souhaite. Et enfin, Alu nous a concocté une feature toute douce et pleine de bienveillance: lorsqu’il y aura des très bad moods, une petite surprise poppera afin de vous apporter un peu de réconfort.
Participer à NikoNiko a été l’occasion pour Yoann et Nico de découvrir Python!

Leur feedback :

Alu : Suite à la refacto on a eu aussi quelques surprises ^^

Yoan : Je voulais faire du python et voir comment fonctionne l’API Slack. Je me suis aperçu que python est long et galère pour comprendre un projet.

Nico N. : Je ne connaissais pas python, mais c’est plutôt cool. J’ai retenu un truc de python, tout est en snake case car c’est du python :)

Team MDR

Ce toy-projet est un petit challenge. Le principe, c’était d’écrire un petit client de messagerie qui respecte un protocole défini très simple, que chacun devait implémenter dans le langage ou la techno de son choix, pour qu’on puisse tous discuter ensemble à la fin du hackathon. Vous pouvez retrouver le challenge ici !

Pib a choisi de l’écrire en Go, langage qu’il a découvert au dernier hackathon en compagnie de Nathan. Alessandro l’a réalisé en JS, langage dans lequel il se sentait le plus à l’aise. Il souhaitait pouvoir terminer ce toy-projet! Louis a choisi de l’écrire en Haskell, car contrairement à Alessandro, il ne voulait pas être sûr de le finir! Et Soso a essayé de l’implémenter en JS, "essayé", car sans Alessandro, elle n’aurait pas eu une partie du protocole d’implémenté.

Leur feedback :

PIB : J’ai écrit mon bot en go. J’ai lancé un port sur 1234, et un autre sur 1235. Et le troisième se connecte au troisième. On peut aussi voir le protocole de communication. Ça marche en local, mais Alessandro peut aussi se connecter sur ma machine.

Alessandro : Implémenter un protocole que je n’ai jamais utilisé, c’était vraiment cool, un vrai défi. Je me suis bien amusé et c’était une super idée d’avoir une interface commun afin de communiquer. .

Louis : J’ai écrit en haskell, et j’ai pas mal galéré, c’est vraiment différent du Js. Par exemple, pour la liste des utilisateurs, en JS j’aurais poussé l’id des participants en liste, mais en haskell c’était galère.

Soso : J’ai utilisé JS, Alessandro m’a aidé pour le protocole. Ce qui est cool, c'est que j’ai pu toucher au réseau.

Team Keskonmange

Keskonmang’ est une application qui a vu le jour au Hackathon #11 et qui permet de rechercher un restaurant dans un périmètre de deux kilomètres autour d’une adresse.

Michel s’est consacré à modifier l’API utilisée auparavant. L’appli utilisait l’API de Foursquare pour récupérer les restaurants, mais la version gratuite limite le nombre de requêtes à 950 par mois. Avec la team, il a donc choisi de remplacer cette API par Yelp qui elle permet 5000 requêtes par jour. Il s’est chargé d’intégrer Yelp et de supprimer Foursquare.
Emma s’est penchée sur la partie des filtres pour pouvoir rechercher par type de cuisine, régime alimentaire et prix. Elle avait commencé le projet avec Joris, et elle souhaitait absolument le continuer. De plus, étant sur un projet client qui utilise React, elle souhaitait continuer d’approfondir la techno avec ce Toy Project, tout en prenant plaisir sur le back avec ce petit projet qu’elle maîtrise.
Hugo a plus travaillé sur la partie infra, avec une refacto de docker, et la mise en place d’une CI. De plus, l’ancien domaine avait été désactivé car non utilisé (à cause de la limite de requêtes), il a donc commencé à préparer une preprod.

Leur feedback :

Michel : L’appli utilisait l’API de Foursquare pour récupérer les restaurants, mais la version gratuite limite le nombre de requêtes à 950 par mois. On a donc choisi de remplacer cette API par Yelp qui elle permet 5000 requêtes par jour. Je me suis chargé d’intégrer Yelp et de supprimer Foursquare.

Emma : Je me suis penchée sur la partie des filtres pour pouvoir rechercher par type de cuisine, régime alimentaire et prix. J’avais commencé le projet avec Joris, et je voulais absolument le continuer. Et étant sur un projet client qui utilise React, je voulais continuer d’approfondir la techno avec ce Toy Project, tout en prenant plaisir sur le back avec ce petit projet que je maîtrise.

Hugo : J’ai plus travaillé sur la partie infra, avec une refacto de docker, et la mise en place d’une CI. De plus, l’ancien domaine avait été désactivé car non utilisé (à cause de la limite de requêtes), j’ai donc commencé à préparer une preprod.

Team KNP Jam

On a fait un atelier sur l’outil Unity 3D, outil que Flaggy connaît déjà bien. Après avoir présenté le métier de devs à plusieurs collégiens à distance sur sa chaine Twitch, Helly a rejoint Flaggy sur l’atelier et la réalisation d’un jeu vidéo ayant pour thème les knpeers.

Nous avons modélisé un tank au milieu d’une map et des projectiles qui arrivent par vague grâce à l’interface de paramétrage d’unity et en codant les composants pour le mouvement et la vie du tank et des projectiles.
Afin de rester dans le thème, nous avons mis à contribution tout les knpeers enregistrant leurs voix. Ces enregistrements nous ont permis d’animer les projectiles avec du son. Associé à un son, le projectile est également associé à une photo du knpeer responsable du bruitage.

Résultat : en peu de temps on obtient un petit jeu très drôle et funky qui rend hommage (enfin on croit) à nos knpeers. Le nom du jeu est “Knpire”! Wait…

Leur feedback :

Grégoire : J’ai modélisé avec Unity et on a une interface de paramétrage. On code des composants pour le mouvement, pour la vie etc. On a fait pas mal de données, j’ai créé un inspecteur pour configurer le jeu. Pour le mouvement, shooting, données avec les images des KNPeers et leur voix.

Helly : J’ai découvert Unity, et j’ai enregistré les voix des KNPeers, j’ai créé la map mais elle ne s’intègre pas encore au code de Grégoire.

Team Figma Crew

Au dernier hackathon, nous avions abordé les problèmes des communication entre les devs et le design. Nous souhaitions pour cette édition trouver des solutions.

Lors de ce hackathon nous avons testé Figma, qui est l’un des principaux concurrents à Sketch que nous utilisons actuellement en Design.
Nos problématiques sont que les outils d’aide à l’intégration (de notre côté Inspect pour InVision) ne sont pas forcément optimum, et faute de temps et d’organisation des projets, les specs ne sont pas toujours précisément communiquées. De plus, nous passons par beaucoup d’outils pour travailler avec les devs et les clients, et certaines informations se perdent.

Sketch VS Figma, nous avons comparé les deux solutions :

• Avec Figma, toutes les modifications sont enregistrées automatiquement et sont visibles et éditables en temps réel par les autres collaborateurs. Le travail en pair et au centre de l’outil et fonctionne particulièrement bien. Sur Sketch, c’est beaucoup plus laborieux.

• Figma a une bibliothèque de plugins moins fournie que celle de Sketch, mais ceux-ci sont plus facilement développables, permettant de créer ses propres plugins.

• La communication et l’organisation sont simplifiées, car les commentaires publiques et privés sont intégrés directement dans les maquettes.

• Les options de prototypage sont poussées, offrant plus de liberté et de précision que sur InVision. Par exemple, la feature d’auto-layout et certains plugins d’affichage en responsive sont très fiables.

• L’import des fichiers Sketch sur Figma est bien géré, les symboles sont recréés en composants

En conclusion :

Le bonus de Figma : c’est utilisable par tous les OS, et pas uniquement Mac.

Le principal problème : Figma ne fonctionne pas en offline, sans connexion nous ne pouvons tout simplement pas ouvrir les fichiers, même enregistrés en local. Son utilisation comme outil principal de Design est donc impossible pour le moment.

Ce projet nous a permis de communiquer sur ce que nous pouvions améliorer entre nous et sur nos méthodes de travail.
Le passage sur Figma à 100% n’est pas encore possible. En plus de l’impératif online, des problèmes de stabilité récurrents sont présents. Pour l’heure, nous nous en servirons pour créer des prototypes avancés et à certaines étapes des projets pour ses fonctionnalités de coopération.

C’est toutefois un outil prometteur, à suivre de très très près!

Discussions

Coffee Talk “I need a Hero !”

Notre Pedrotroller nous a parlé de l'importance du code review, du continuous testing, du continuous delivery, du deep cleaning, du continuous refactoring, et de toutes les bonnes pratiques nécessaires à la création d'un code de qualité.

Workshop “Comment bootstrapper une appli avec React” ?

Selon les demandes de formations internes, chaque KNPeer peut donner ou recevoir une formation interne. Pour ce samedi, il y avait du monde pour un bootstrap avec une appli react.

Samedi c'est la journée des #workshops ou des #discussions pendant notre #KNPHackathon : "Comment bootstrapper une appli #React" au #KNPHackathon - #dev #training #js #knptraining pic.twitter.com/pi24XXh4qD

— KNP Labs (@KNPLabs) October 17, 2020

Workshop “Comment participer aux projets Open Source” ?

Notre Team FOSS (free and open source software) a eu du renfort, et Alessandro (Snappy Bundle) nous a présenté les différents projets open source de KNP et comment y contribuer.

Puisque l’open source est dans notre ADN, nous formons nos nouveaux #KNPeers sur comment y contribuer #hacktoberfest #opensource #knpbundles #foss pic.twitter.com/wzA2lVxuNT

— KNP Labs (@KNPLabs) October 17, 2020

En Conclusion

Beaucoup de discussions, des beaux projets et pleins de nouvelles idées pour les prochaines éditions. Envie de travailler avec nous ? Un petit email à hello@knplabs.com