Hackathon #10 - Résumé des Toy Projects

Publié le

11 juil. 2019

events

Déjà notre 10ème Hackathon ! Cette fois-ci en Espagne, dans la montagne madrilène.

Le super cadre a stimulé les équipes pour être à fond sur leur ToyProject. Les sujets étaient très variés : deux projets pour faire un jeu, du son via JS, un power-up pour Trello, un twitterbot et la mise en place de Drone.io. Ça vous donne envie d’en savoir plus ? Voici les résumés des projets !

TeamDrone

Albin et Nico M. voulaient tester drone.io pour confirmer (ou infirmer) la faisabilité du remplacement de notre CI actuelle (en mode SaaS) par une CI self-hosted. Voici leurs retours :

“On a principalement fait un travail de recueil de données, afin de mieux nous guider dans notre prise de décision. Nous avions établi une petite liste de points techniques à vérifier avant le Hackathon. Et nous savions qu'il était nécessaire de comparer la tarification des principaux hébergeurs Cloud afin d'en tirer le meilleur.

Au fur et à mesure de notre analyse des tarifications, nous nous sommes aperçus qu'il était nécessaire d'en savoir plus sur l'utilisation actuelle de notre CI tel que le nombre de builds par jour et par mois, l'amplitude horaire, le nombre de builds concurrents maximum, le temps moyen de build, etc. En effet, certaines tarifications Cloud semblent avantageuses de par leur unité de temps (à la seconde) mais impliquent parfois des "détails" qui peuvent vite représenter un budget conséquent dans notre cas. Cette comparaison était d'autant plus nécessaire que les solutions techniques envisagées diffèrent en fonction de l'unité de temps de facturation (ex. une VM par projet ou une VM par build ?).

On a donc comparé : DigitalOcean, mais le manque de solutions de stockage IaaS (NFS ou CIFS) implique de maintenir notre propre serveur de stockage et rend donc la solution économiquement et techniquement peu réaliste ; ensuite Google Cloud, mais le coût de la bande passante vers l'extérieur est relativement prohibitif. Puis nous avons fait de même avec Amazon EC2 et Azure.

Finalement un collègue de la team Infra est venu nous souffler l'idée d'OVH, qu'on avait jusqu'alors mis de côté sans trop de raison. Finalement, OVH semble être économiquement le plus compétitif. Il nous fallait alors confirmer techniquement ce choix. Après quelques tests ratés et un mauvais placement d'un serveur NFS résultant en une bande passante ridicule, il semblerait qu'OVH soit effectivement le provider Cloud le plus à même de répondre à nos besoins.

Il nous reste encore du travail, notamment pour confirmer la méthode de mise en cache des layers Docker et pour confirmer l'efficience du NFS pour le stockage des artefacts de builds (logs, cache, etc...). Mais le choix d'OVH semble désormais acté, nous pouvons donc passer à l'étape suivante: monter une instance drone.io pour mener les prochains tests sur un ou deux projets internes.

Une fois ces derniers tests réalisés, il nous restera tout de même un peu de travail : l'autoscaler drone.io devra être légèrement adapté puisqu'il ne gère pas OVH actuellement."

TeamSolo

Marc souhaitait finir le bot Twitter qu’il avait commencé au dernier Hackathon et qui récupère des starred github repository et qui les poste ensuite sur Twitter.

Voici son retour :

“J’ai remplacé l’interface dans un terminal par une interface web. L’utilisateur voit les tweets générés automatiquement, les tweets postés et l’historique. C’est un peu comme un tweetdeck ou trello-like.

C’est fait en React, derrière il y a API Plateforme et Mercure. C’est API Plateforme qui communique avec github, Mercure va envoyer les mises à jour, par exemple quand un tweet est envoyé, le back va directement envoyer les informations, donc plus besoin de mettre à jour la page.

C’est la première fois que j’ai utilisé API Plateforme, j’ai pu le mettre en place rapidement, mais je me suis aperçu qu’on est un peu bridé pour agréger des flux de différentes source.

Le bot fonctionne un peu comme trello, on peut sauvegarder, créer et supprimer des cartes. API Plateforme est un peu com FOSSRestBundle en mieux.

J’agrège la data qui vient de Github, les repos avec des stargazer. Le dernier star sur un repo est récupéré qui récupère un JSOn que je stocke dans la base dans un objet. Avec APIPlateform je peux faire un datatransform d’un appel.

Au final, REST prépare les futurs tweets, IID, titre, et image. Et je transforme des mots clefs dans la description en hashtag pour augmenter la visibilité sur Twitter. Il reste à configurer pour programmer les tweets qui sont en file d’attente.”

JungleRunners

Laurent, Thomas, Antoine, François et Hugo voulaient créer un jeu de Jump-and-Run comme Mario programmé avec Unity : c’est un jeu pour deux joueurs avec un monde aléatoire. La plateforme était déjà existante et il existe même un repo git. Chacun peut directement contribuer.

Unity est basé sur C# - ils avaient envie de l’essayer pour le fun. Cela permet de faire un jeu vidéo rapidement et sans investissement préalable de formation.

Voici leurs retours :

“On avait envie d’explorer les maths et physiques dans la programmation. Les éléments de design existent déjà. On avait tous une mini expérience avec C#, on s’y fait vite.”

Laurent : “Premier feedback sur Unity, le versionning n’est pas en git, il ne peut y avoir que 3 personnes sur le repo, donc il fallait être en pair. Avec Antoine on a fait le design des personnages. Je trouve que Unity est abordable rapidement grâce à la documentation.”

Antoine : “Unity et itch.io ont pleins d'assets et sprites qui sont très inspirants pour faire de petits jeux. Avec pour objectif de le faire en 3D dans l’année.”

Thomas : “J’étais sur le front, avec les arbres qui avancent, ce qui est tricky. Comme j’avais déjà fait du Unity, ça a été. On n’a pas fait les menus pour démarrer le menu ou la fin. Mais demain on pourrait le faire. Très peu de code, mais très intéressant pour gérer le moteur physique pour gérer l'impulsion et le matérialiser. Beaucoup de vecteurs.”

François : “J’ai fait les petits tuiles qui se déplacent (les marches sur lesquelles on saute) via un système de grilles.”

Hugo : “J’ai fait du pair avec Antoine et Thomas, la création des maps, superposer les images. J’ai aussi fait les recherches sur les assets.”

Screepers

Léna, Nico, Alu, Pedro et Alessandro avaient envie de tester un jeu créé par des développeurs pour des développeurs : Screeps . Le but était de créer une IA permettant le développement d’une colonie, le jeu n’étant qu’un grand bac à sable.

Chaque participant va donc devoir coder le comportement de chaque membre de sa colonie avec une stack basée sur JS avec ou sans typescript ou n’importe quelle librairie JS qu’il souhaite.

La difficulté est de réussir à tout automatiser, les constructions, la création des meilleures routes et des bâtiments, ainsi que le comportement de chaque membre de la colonie (récolteur, soldat, mixte, explorateur, soigneurs, etc.). Il s’agit donc de chercher l’optimisation pour récupérer les ressources, mais aussi leur exploitation (création de routes, bâtiments ou nouveau membre) tout en prenant garde aux autres colonies potentiellements hostiles.

Leurs retours :

“La force du jeu est d’apporter une réflexion autour de sujets qui peuvent paraître simples mais qui deviennent rapidement complexes. Cela amène les participants à élaborer des stratégies spécifiques pour répondre à telle ou telle problématique. Ce qui est intéressant c’est d’observer de temps en temps une convergence des solutions à un problème et de temps en temps une manière totalement différente de l’aborder.

Le fait d’êtres plusieurs au sein d’un même monde oblige aussi les joueurs à réagir rapidement en cas d’attaque ou d’occupation d’une ressource que l’on souhaite exploiter.

Sur le côté technique, il est possible d’utiliser des transpileurs pour utiliser des langages autres que ceux du monde JS.

Information importante, la quantité de CPU et mémoire est limiteé à chaque “tick” (boucle d'interaction du jeu), si le script est trop gourmand, le script risque d’être interrompu et donc le comportement devient assez aléatoire.”

Alu : “L'intérêt réside vraiment dans l’approche et la résolution de problème complexe et surtout dans l’échange de conception ou d’implémentation que chaque équipe a mis en place. Nous avons toujours envie de corriger ou améliorer un comportement, c’est réellement de l'héroïne pour développeur, il est difficile de s'arrêter…”

Alessandro : “J’ai aimé le refacto en continu, laisser jouer ton code et ne pas jouer soi-même.”

Yoann : “Un jeu addictif pour développeurs. Deux jours sur le jeu a permis de voir succinctement une grande partie des fonctionnalités du jeu et d’imaginer un algorithme optimal pour battre ses adversaires. Une infinité d’implémentations et de conceptions sont possibles, ce qui a permis l’échange de visions des différents participants.”

Pedro : “Renforce le refactoring, et j’aimerais faire des tests dans le code. Le débogueur n’est pas super bien foutu.”

Léna : “Suite à une grosse refacto, j’ai pu améliorer ma colonie (qui était tuée pendant la nuit). J’ai complètement changé ma stratégie depuis hier.”

Nico N : “Le début est un peu douloureux car l’API est très fournie, mais on se prend très vite au jeu… J’ai aussi aimé le côté refacto, je les ai un peu énervé après le premier décès de ma colonie, car j’ai utilisé un script que j’ai plus abouti que j’ai trouvé sur Github pour le laisser tourner la nuit :D , ça les a motivé pour améliorer leur script.”

SYÑORA

Pib, David et Léo ont expérimenté les API Web Audio et Web MIDI pour programmer un synthétiseur. Et ça “sonne” bien !

Avec JS, React et la librairie tone.js (wrapper Web Audio), ils ont créé un synthé utilisable avec un contrôleur MIDI (Pad AKAI). Un oscillateur 1 voix peut être ajusté via une enveloppe ADSR, la forme d’onde également. Quelques effets sont disponibles comme un délai ping pong ou une distorsion. La niveau de sortie est ajustable via un bouton de volume et visualisable sur un VU-mètre.

Leurs retours :

Pib : “Un synthétiseur dans Chrome, on a utilisé React (première expérience pour moi) pour les différents boutons de contrôle (sliders, faders ou clavier virtuel) pour paramétrer l’évolution du son (note, forme, enveloppe). L’utilisateur peut jouer via les touches du pad ou par le clavier virtuel. On a entamé un petit éditeur midi pour jouer des séquences en boucle, mais ce n’est pas encore fini.

Le bootstrap a été fait en pair pour appréhender tone.js, qui se révèle plutôt simple à utiliser puis chacun de nous a fait des composants pour chaque fonctionnalité.”

David : “Il y a plein d’options, on a aussi géré le volume. Chacun a pris une partie.” Léo : “J’ai fait du functional programming pour la première fois, ce fut très instructif.”

Trellowers

Emma voulait finir l’extension Trello, qu’elle avait commencé au dernier Hackathon, pour voir l’historique de la description des cartes. Joris renforce l’équipe avec l’envie d’explorer les PowerUps de Trello.

Le but était de faire une fonctionnalité sur Trello pour voir l’historique des cartes, car l’historique n’est pas disponible en natif sur les cartes (mais il possible d’aller les chercher en faisant une requête depuis l’API Trello). Une extension chrome avait été commencée par Laurent et Emma au dernier Hackathon, mais ça n’a pas été concluant à cause de la génération à la volée des cartes en javascript et l’impossibilité de récupérer les événement JS de Trello.

Afin de palier à ce problème, ils avaient utilisé les Power-ups de Trello (une autre API à dispositions des devs).

La documentation n’était pas claire, manquait d’infos, et rendait les recherches compliquées. Et les Power-ups avaient également une certaine limite, comme pour ce projet : “c’est une iframe qui affiche notre fonctionnalité, et une fois le power-up chargé, la taille de cette iframe ne peut être modifié”.

Ainsi, Emma et Joris se sont demandés comment ils allaient faire pour pouvoir afficher les descriptions sans avoir de problème de visibilité et au contraire ne pas avoir un bloc qui pollue l’affichage des sections d’une carte Trello : “il faudra trouver un juste milieu!”

Leurs retours :

Joris : “On a repris des infos sur le plugin qui a été fait au dernier hackathon, afin de créer un power-up à installer sur Trello. Le code doit être hébergé sur un serveur externe, et préciser l’url dans l’instanciation de votre power-up. On a donc utilisé glitch pour avoir une url de notre code, c’est un peu années 90, mais c’est très pratique et on peut coder en live directement dans le browser. On peut même le connecter avec Github afin d’importer le code versionné.

On a eu des problèmes avec l’authentification pour accéder à l’API Trello qui sauvegarde un token chez Trello et comme la documentation n’est pas top, on a pas mal galéré.

Pour retranscrire le markdown, on a utilisé la librairie ShowDown, qui est plus au point que la librairie Snarkdown utilisée sur l’ancien projet d’extension Chrome.

Et pour finaliser ce power-up, il faudrait dockeriser le projet et l'héberger sur un droplet chez Digital Ocean et après on pourra la sortir sur le marketplace de Trello.”

Emma : “Pour ajouter des power-ups il faut être admin d’une équipe Trello, et depuis l’administration des power-ups de Trello, on peut ajouter des power-ups personnalisés. Dans notre cas, on a utilisé la section “card-back-section“ qui permet d’ajouter une iframe dans le corps de la carte Trello.

On a réutilisé des classes et du css provenant de Trello pour avoir un design cohérent, et ajouté des traductions pour avoir les textes traduits en fonction de la langue du browser (pour l’instant, seulement anglais et français).

Mais sinon, très contente d’avoir enfin pu finaliser ce projet avec Joris qui m’a appris pleins de petites choses en javascript et en Functional Programing ! Le power-up est fonctionnel, plus qu’à finaliser les dernières petites choses, écrire un article, et partager!”

Voici l’article avec la description plus détaillée sur comment faire un power-up pour Trello.

Talk de Pierre sur sa vision de la vie d’un développeur.

Le but d’un développeur est de faire avancer des tâches, sans que la carte ne revienne en arrière. Le premier step est de comprendre le besoin de l’utilisateur et de parler le même langage via le ubiquitous langage et le BDD. Faire un dictionnaire de vocabulaire et détailler les besoins du client.

Code review

Après le développement de la fonctionnalité, il y a la Code Review du code produit. Vérifier les erreurs, vérifier l’intégrité du projet, se mettre d’accord sur l’avancement et monter l’autre en compétence, par exemple en posant des questions et en suggérant des améliorations.

On peut également faire d’abord une auto-review, ou mettre en place des outils pour le code style.

Commenter son code aide aussi. S’il y a des commentaires, il faut traiter les retours, car notre but est de faire avancer notre carte.

Next step, la validation du client, on suppose que le client est content, la tâche est validée.

Les tests

Ensuite, il y a des tests automatisés pour lesquels on se base sur la pyramide de tests : les tests de base sont des tests unitaires, très bas et très simple - end to end.

En haut de la pyramide, ce sont des tests automatisés qui remontent toutes les actions de l’utilisateur. Donc les tests rapides ont un grand coverage, et on réduit au fur et à mesure.

Je ne vous dis pas de tout tester : les fonctionnalités importantes comme un tunnel de commerce doit être énormément testé, l’inscription d’une newsletter est moins importante**. Donc le test coverage change en fonctionne des besoins du client.**

Ensuite l’environnement de test

Il faut dès le premier sprint une CI pour faire tourner des tests.

Merci pour votre attention :D

Forum ouvert

Les Hackathons sont aussi un lieu formidable pour discuter des sujets qui sont moins facilement abordables à distance.

Agent_Es a animé un forum ouvert. Il y avait une dizaine de discussions sur la matinée du samedi : accueil des nouveaux, le rôle du développeur chez KNP, la vision du KNPTaste, présentation de Prisma, booster son environnement de dev, vision du Knowledge, comment gérer la communication interne… Tous les sujets sont abordés et retranscrits par un rapporteur.

S’il y a des actions à prendre, elles sont ajoutées dans notre Trello “KNPeer’s Life”.

Lego4Scrum

Comme au tout premier Hackathon, Eve a proposé un Lego4Scrum pour ceux qui ne l’avaient pas encore fait.

Avec une équipe de 10 personnes, Léna a proposé de construire le Châteauform’ de ses rêves ! Avec les retours d’Alu et Agent_Es, qui eux, ont déjà animé des ateliers similaires, ils ont eu l’idée de proposer une Lego4Scrum plus orienté discussion MVP et des sprints plus orientés sur des livrables qui peuvent générer directement un retour d'investissement.

Résumé

Globalement on a passé du bon temps, les toy projects ont généré des coding sessions passionnées et les discussions ont pu dégager quelques actions pour la suite ! Au bout de notre dixième édition, le format des Hackathons se confirme !

Pendant ce temps, notre nouveau collègue Flam Antrose a pris du bon temps : Questions, envie de travailler avec nous ? => hello@knplabs.com