Comment réussir un Hackathon en tant que participant ?

Le 19 et 20 mai 2018, j’ai eu la chance de participer au Hackathon de l’OPAC en tant que mentor.

Il s’agissait de mon premier hackathon. Et en tant que développeur, j’ai assisté au mieux les équipes sur l’aspect technique de leur projet, résolvant des conflits `git` par ici, modifiant un peu de CSS par là ou expliquant le bien-fondé du travail en local.

Suite à cette expérience, j’exprime ici quelques réflexions pour qu’en tant que participant vous viviez un meilleur hackathon.

C’est quoi réussir son Hackathon ?

Comprenez bien que je ne parle pas ici de victoire ou de podium, les critères d’évaluation étant différents d’un hackathon à l’autre et pouvant porter sur des aspects non techniques (budget, …), je me garderais bien de prétendre vous apprendre comment gagner.

Quand je parle de réussite, je veux dire qu’en tant que participant vous rencontriez le moins de « souffrances » inutiles. Vous êtes déjà chouchoutés par l’organisation, qui gère vos repas, vous propose des pauses bien-être (gym matinale, massage, …). Autant de points dont vous n’aurez pas à vous soucier pendant le week-end, de quoi vous concentrez sur votre projet normalement.

Encore faut-il y être correctement préparé.

Constituer son équipe

Un point essentiel du Hackathon, c’est qu’il se passe en équipe. On écarte immédiatement ce cliché du développeur seul dans sa pièce sombre, avec son sweat à capuche et son casque vissé sur les oreilles.

Non, le développement c’est un travail collectif. Le groupe peut se constituer soit avant l’évènement, soit au démarrage de celui-ci.

Durant tout le reste de cet article, je ferais souvent la distinction entre les deux possibilités. En effet, si l’on est seul ou à plusieurs, on ne se prépare pas de la même manière.

Si vous avez déjà votre équipe, vous devrez penser à la possibilité d’intégrer quelqu’un d’extérieur. Il faudra anticiper aussi bien le type de compétences qui manque à votre équipe, que le partage d’informations techniques avec ce nouvel arrivant (langage, …) ou encore à niveau plus humain l’intégration de cette personne à vos super « privates jokes » ^^.

Si vous êtes seul, sachez expliquer ce que vous savez et voulez faire (ainsi que son contraire). Il ne s’agit évidemment pas de passer un entretien, mais cela peut vous éviter de passer votre week-end à rédiger le pitch, quand vous rêviez de faire une application React depuis des semaines.

Préparer sa machine

Commander un lot de magnifiques stickers pour décorer votre portable, ce n’est pas ça préparer sa machine.

Il vous faut une machine avec laquelle vous êtes à l’aise. Evitez d’installer un Linux deux jours avant l’événement, si vous n’avez fait que du Windows toute votre vie.

Pensez aussi qu’il vous faudra peut-être projeter votre écran pendant le week-end, prévoyez les adaptateurs nécessaires (HDMI et VGA).

Choisir ses technologies

Ici, la différence entre l’équipe et le participant seul va être importante.

Si vous êtes seul, vous ne connaîtrez pas la technologie utilisée avant le jour-même. Mais sans trop m’avancer, je ne saurais trop vous conseiller d’installer une pile Apache, PHP, MySQL (ajoutez-y composer).

Peu importe que vous choisissiez de passer par une VM, un Docker ou une installation directe, mais tester votre configuration en montant un petit projet qui accède à la base de données.

J’ajouterais qu’en cette époque où le Javascript est partout, installer NodeJS et NPM est aussi une bonne idée.

Il faut aussi garder à l’esprit qu’intégrer une équipe pour le week-end, c’est aussi l’occasion de découvrir une nouvelle technologie avec des gens qui l’utilisent au quotidien.

Si vous êtes une équipe, vous allez pouvoir prévoir plus précisément ce que vous allez faire.
Vous pouvez choisir d’utiliser le langage et le framework que vous utilisez déjà au quotidien, ça ne fait pas très « Hack », mais c’est efficace.

Vous pouvez tenter de nouvelles choses, changer le framework en gardant votre langage, écrire un front-end en React/Vue parce que vous voulez découvrir le Front-End, tester une nouvelle techno (VR, Tensorflow, …).

Dans les deux cas, il pourrait être intéressant d’avoir un squelette de projet sur chaque machine. Ensuite dans le cas d’une technologie inconnue ou non maîtrisée, prévoyez de passer un peu de temps dans les semaines avant le Hackathon pour faire les premiers tutoriels.

L’idée est simple, moins vous aurez de configurations, installations à faire le jour J, plus de temps vous aurez pour travailler sur votre projet.

Anticiper la collaboration

Pendant 2 jours, vous allez devoir échanger du code, des idées ou des informations en tous genres. Là encore, prévoir à l’avance ces éléments vous permettra de vous concentrer sur ce qui est important.

Pour le code, la solution de-facto est Github. Vous pouvez y préférer Gitlab ou Bitbucket, mais le principe reste le même.

Il vous faut donc la ligne de commande `git` installée et configurée (pensez aux clés SSH pour gagner du temps lors des push-pull vers le serveur). Si vous ne connaissez pas Git, il est temps de s’y mettre.

Si vous êtes en équipe, vous pouvez créer le repo distant, y pousser le squelette évoqué précédemment et vérifier que tous les membres y ont accès. (Si on vous dit que c’est de la triche, vous n’aurez qu’à dire que c’est de ma faute.)

Si vous êtes seuls, posséder un compte Github me semble une bonne idée.
Pour les échanges d’informations ou autre, le choix est large. Slack ou Discord sont les deux plus connus.

Déployer son projet

Pour ce dernier Hackathon, Iteracode avait fourni des serveurs LAMP tout configurés de chez Aruba (https://www.aruba.it).

Ce ne sera pas forcément le cas ou cette solution ne vous convient peut-être pas.
Encore une fois, la préparation va faire la différence.

Chez Iteracode, nous déployons nos projets sur CleverCloud (https://www.clever-cloud.com/), ils gèrent plein de langages/technos/BDD et en plus, c’est une boîte française.

Il existe des tas de solutions similaires (ex. Heroku https://www.heroku.com/), peu importe celle que vous choisirez, mais tester de déployer votre petit projet test pour débloquer les gros soucis avant le jour J.

Ayez aussi en tête que vous voudrez (probablement) déployer des dizaines de fois pendant 2 jours. Autant choisir une solution avec laquelle vous êtes à l’aise.

Conclusion

Je pense que vous l’aurez compris, le point important c’est la préparation !
Quels que soient les choix que vous ferez, il faut les tester sur un petit projet « complet ».
Evidemment, ces idées sont discutables et vous pouvez avoir votre propre vision.
Certains me diront qu’il « ne faut pas s’embêter avec Git pour 24h ». Quand d’autres me reprocheront de ne pas être allé assez loin en oubliant la partie CI (https://travis-ci.org/ ou https://circleci.com/), le déploiement automatique de « master », …
J’ai essayé de trouver le juste milieu, à vous de trouver le vôtre.
Un bon hackathon à vous ! Et surtout amusez-vous bien !

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *