Retour d’expérience: CodeStory 2013

code_story_logo

Le concours Codestory vient de se terminer, mais je suis heureux d’avoir pu participer de la première étape jusqu’à la phase finale. Voici donc mon retour d’expérience sur ce super évènement.

J’avais suivi l’édition 2012 de loin, mais cette année je n’étais pas prêt de la rater, surtout après le succès de l’édition précédente. De plus, c’était l’occasion de relever des challenges et de s’amuser. Pour la première phase lancée, il fallait implémenter un serveur et répondre à des requêtes Http envoyées par un robot. Ce dernier interrogeait tous les serveurs des participants avec de nouvelles questions dès que la bonne réponse avait été trouvée. Globalement, ça ressemblait à un atelier Extreme-startup.La première question posée était simple : “GET: /?q=Quelle+est+ton+adresse+email“, la réponse étant simplement un document HttpResponse contenant l’adresse email du participant.

Choix technique :

L’objectif étant d’implémenter un serveur Http, je n’ai pas trouvé intéressant de créer toute une application web, pour ensuite la déployer dans un conteneur d’application (Tomcat ou Jetty). Ma solution consistait donc à créer une simple application avec une classe Main, puis de lancer un ServerSocket ou bien d’utiliser un Framework avec le support du protocole Http. J’ai décidé de partir sur une implémentation à base du Framework Netty.

Pour le langage, j’ai hésité entre Java et Scala. Etant débutant sur ce dernier, j’ai opté pour le langage Java. Il fallait ensuite trouver une plateforme pour déployer rapidement mon application dans le Cloud : j’ai choisi CloudBees pour déployer mon application.

J’avais prévu d’implémenter mon application en utilisant la pratique TDD. Mais finalement, j’ai réalisé tout mon code sans presque rien tester, ceci pour les raisons suivantes :

– le contexte du concours et les énoncés étaient très difficiles à tester unitairement (voir impossible certaines fois : par exemple, tester la solution optimale à base d’une requête avec 50 000 demandes)

– le robot était tout simplement plus rapide. Pour tester mon code, j’avais juste à le déployer et attendre la question du robot. Si ma réponse était bonne, un cas de test de plus passant, et le robot m’envoyait tout de suite la question suivante. Sinon, il me renvoyait la même question. Je n’avais donc qu’à consulter mes logs pour vérifier si mon code marchait ou non.

Déroulement du concours :

J’ai démarré le concours en fin de première semaine de son lancement. Le premier jour,  il m’a fallu implémenter mon serveur Http. J’ai passé beaucoup de temps à mettre en place un modèle de résolution d’URI (redirection vers le bon Controller, récupération des paramètres Http, etc.). Une fois ceci fait, c’était place aux problèmes de déploiement avec Cloudbees. Après avoir eu quelques heures de galère, j’ai été contacté à 3h du matin par un développeur Cloudbees qui a reçu des alertes par rapport au déploiement d’applications à partir de mon compte. On a compris, après quelques échanges, que le plugin “maven-assembly-plugin” générait des fichiers dupliqués qui, au moment de la décompression du Jar, causaient le problème. J’ai donc corrigé le problème sur mon code, ainsi que l’équipe Cloudbees de son côté… j’étais enfin prêt.

Les premiers énoncés étaient simples et marrants :

  • ?q=Quelle est ton adresse email
  • ?q=Es tu abonne a la mailing list(OUI/NON)
  • ?q=Es tu heureux de participer(OUI/NON)
  • ?q=Est ce que tu reponds toujours oui(OUI/NON)
  • ?q=Es tu pret a recevoir une enonce au format markdown par http post(OUI/NON)

Les niveaux suivants étaient un peu plus durs, surtout le dernier énoncé. Pour les plus curieux, voici l’URL vers le premier énoncé :

– L’échoppe de monade sur Scalaskel

La question suivante consistait à évaluer une expression arithmétique. La première requête fut “1+1”, puis “2+2”, …  Quelques requêtes après, c’était l’opérateur qui changeait, ensuite des parenthèses, … A ce moment, il a donc fallu penser à une solution qui évalue toutes les expressions arithmétiques. Je me souvenais que pendant ma formation universitaire, j’avais étudié des algorithmes d’évaluation d’expressions arithmétiques, dites {prefix, postfix, infix}. Mais ceux-ci sont trop difficiles à implémenter, et trop compliqués. J’ai alors cherché des Api qui peuvent évaluer les expressions : j’ai utilisé l’api Exp4j. Ca avait l’air de marcher… jusqu’à la question suivante qui m’a terrorisé :

?q=((1,1+2)+3,14+4+(5+6+7)+(8+9+10)*4267387833344334647677634)/2*553344300034334349999000

Après quelques recherches, je suis tombé sur un poste d’un participant sur un forum informatique (qui apparemment était aussi en galère). On lui a proposé d’utiliser l’api Groovy j’ai donc testé… et ça a marché, super !! 🙂

Location d’astronef sur Jajascript

L’équipe CodeStory a gardé le meilleur énoncé pour la fin (l’énoncé par ici). Il ne fallait pas seulement répondre correctement, mais aussi implémenter un algorithme, très performant, qui peut répondre à une requête avec plusieurs demandes (50 000 max) en moins de 30 secondes ! Je dois avouer avoir bien peiné à atteindre l’algorithme optimal sur cette énoncé. J’ai même essayé plusieurs algorithmes, mais vainement. À la fin du concours, je n’ai pas réussi à obtenir la performance optimale.

La phase finale :

Bien évidement, je n’ai pas gagné 😀

La phase finale s’est déroulée chez Google à Paris (au passage les locaux de Google sont vraiment sympa). A 19h15, l’exercice de la phase finale du concours a commencé : il fallait le coder en 2 heures, en binôme, et déployer la solution sur un serveur public. Franchement, 2 heures ça passe vite, on dirait une itération CodeRetreat de 20 min.

La plupart des binômes qui ont participé ne se connaissaient pas avant (y compris mon binôme et moi), ce qui n’a pas facilité le binômage pour la plupart. Certains binômes ont perdu plus de 30 min, voire une heure pour configurer leur dépôt git, ou créer leur appli web, d’autres sont revenus sur leur code de la première phase.

Quant à mon binôme et moi-même, nous sommes parti sur le cœur de notre application en premier, pour gagner le plus de temps possible afin d’attaquer la partie Backend rapidement. Et franchement, ce n’était pas facile. Entre le manque de préparation et la mauvaise organisation, nous avons perdu beaucoup de temps : 30 min avant la fin de l’exercice, on n’avait toujours pas la partie Backend, et à la fin, on avait presque rien à présenter.

Au bout des 2 heures, chaque binôme devait montrer son application au jury pendant 3 minutes. Au final, après délibération, c’est Xavier Hanin (@Xavierhanin) et Christophe Labouisse (@XtlCnslt) qui ont gagné.

Le challenge était vraiment serré, il y avait du niveau. Personnellement, j’ai été impressionné par ce que certains ont réussi à produire.

Pour les plus curieux, vous pouvez regarder la vidéo de la phase finale (ici) réalisée par Nicolas De Loof (@ndeloof)

Et si vous souhaitez voir mon code de la première phase, il est dans mon repo 

Rendez-vous dans moins de 2 semaines pour Devoxx France 2013, vous pourrez aller les voir coder en direct.

Nombre de vue : 34

AJOUTER UN COMMENTAIRE