Image de couverture du post

2018-10-21 02:29 - Événements

Comment on a organisé la Coding Battle du ShaKer

Cette année encore l’association INSAlgo a renouvelé le partenariat avec la KerTeam pour organiser une Coding Battle géante entre les étudiants et entreprises partenaires du salon du ShaKer. En tant que président d’INSAlgo, j’ai dirigé une équipe d’étudiants pendant deux mois pour préparer cet événement.

Dans cet article je fais un retour sur l’organisation, agrémenté d’anecdotes et statistiques inédites sur la Coding Battle.

Mise en contexte

Le ShaKer

Le ShaKer est un salon qui voit se rencontrer les étudiants et les entreprises dans les domaines de l’informatique et des télécommunications, sur un concept de speed dating: les étudiants et du personnel technique des entreprises partenaires sont associés par mots clés au cours de 3 rendez-vous, avant de pouvoir échanger librement au cours d’un goûter.

La Coding Battle a lieu la veille au soir, et les participants peuvent se connecter en ligne de toute la France voire de l’étranger. En général, les entreprises et plusieurs écoles partenaires organisent des hubs pour participer dans une ambiance conviviale, comme en témoignent ces images chez Dailymotion et Dassault:

Les entreprises participent à la Coding Battle

La Coding Battle comporte 6 exercices à difficulté croissante, d’un exercice très simple à un exercice d’algorithmique complexe. Le temps très limité rend le challenge vraiment difficile (seules 4 personnes ont atteint le score maximal).

La Team INSAlgo

Nous étions 4 à travailler activement sur le projet, assistés en plus par Thomas Lacroix qui avait dirigé le projet l’année dernière. Nous sommes tous les 4 au département informatique à l’INSA de Lyon: Alexis Le Conte, Arthur Tondereau, Mohamed Challal, et moi-même.

Étant plus expérimenté en administration, développement web, et Docker, j’ai travaillé sur la plateforme du concours, tandis que les 3 autres travaillaient sur l’élaboration et la rédaction des problèmes, l’implémentation des solutions et les générateurs de tests. Le dernier problème a été pensé par un enseignant-chercheur du LIRIS, Vasile-Marian Scuturici, qui est aussi notre coach lors des grandes compétitions d’algorithmique.

L’équipe le soir du concours, répondant aux questions et administrant la plateforme:

La Team INSAlgo

Détails techniques

Plateforme et infrastructure

Pour la plateforme, j’ai travaillé à partir d’une plateforme libre et open source nommée Contest Management System (CMS). Sa licence libre m’a permis de la modifier (cf mon fork) pour répondre à notre besoin exact. J’ai ensuite créé une image Docker pour pouvoir déployer l’application facilement sur Amazon Web Services.

Les modifications que j’ai apportées à la plateforme sont les suivantes:

  • Support d’un concours multilingue (multiples descriptions de concours, noms de problèmes, énoncés)
  • Support de l’authentification via le protocole OpenID Connect pour authentifier les utilisateurs avec le serveur de la KerTeam
  • Amélioration du système d’import de concours pour augmenter les possibilités de configuration
  • Amélioration de l’interface utilisateur
  • Amélioration du système de scores (notamment pour départager les ex aequo par temps de dernier progrès)
  • Ajout de fonctionnalités d’export de données pour faire du data mining.

Au niveau de l’infastructure, voici les machines utilisées pour héberger la Coding Battle:

  • Machine principale (master): 8 vCPU, RAM 32 GiB
  • Serveurs web: 5 (4 vCPU, RAM 16 GiB) - 20 serveurs web
  • Machines d’évaluation: 4 (8 vCPU, RAM 32 GiB) - 32 évaluateurs
  • Base de données: PostgreSQL, déploiement en doublon, 4 vCPU, RAM 32 GiB

Problèmes, solutions, tests

Pour concevoir les problèmes, nous avons utilisé l’outil Polygon de Codeforces. Cet outil permet de comparer plusieurs solutions à une solution de référence, générer des jeux de tests, des vérificateurs de jeux de tests, ajuster les limites de l’énoncé et les limites de temps et mémoire des programmes à évaluer.

Cet outil nous donne un cadre de conception des problèmes, nous évite de faire les comparaisons et benchmarks à la main, et nous impose une rigueur de vérification de nos énoncés, solutions et jeux de test.

Statistiques

Bien que tous les exercices soient disponibles d’entrée de jeu, la large majorité des participants les a abordés dans l’ordre. Les exercices A et B ont été réussis par une majorité de participants, tandis que l’exercice C a posé un premier mur de difficulté, et peu de personnes ont eu le temps d’aborder les autres exercices.

Cela se voit très bien si l’on regarde le graphique des soumissions au cours du temps (à gauche, soumissions totales chaque minute, à droite leur répartition par exercice) ci-dessous. On notera des pics de soumissions au début lorsque tout le monde a pris connaissance du premier exercice, et à la fin quand on tente coûte que coûte de faire passer sa dernière solution:

Soumissions au cours du temps

Concernant la répartition des scores (à gauche, le pourcentage des participants ayant obtenu des points pour chaque exercice, et à droite la réparition des scores), on observe une bonne difficulté croissante avec cependant un mur entre le B et le C:

Répartition des scores

Au niveau des langages, les participants ont eu plus de succès en C++, puis Python, puis Java, C, et moins en C# et PHP, comme le montre le graphique de répartition des langages par score ci-dessous.

Langages par score

Anecdotes

Le jour du concours, au moment de faire le déploiement j’ai découvert que mon compte Amazon Web Services était trop récent pour louer tous les serveurs dont j’avais besoin, j’ai appelé le support, j’ai été rapidement en contact avec un gars à Washington qui m’a dit qu’il débloquerait le compte sous 24h. Dans l’urgence, j’ai donc pris moins de machines mais des machines avec plus de coeurs et de mémoire.

Pendant la battle, 10 minutes avant la fin, toutes les soumissions ont arrêté de se compiler ou de s’évaluer. Le problème n’était même pas un manque de performances ou de mémoire des machines d’évaluation, mais une saturation du disque avec les fichiers temporaires des programmes à évaluer. On a fait une annonce disant de soumettre quand-même, j’ai fait le nettoyage sur chaque machine d’évaluation et quelques minutes plus tard on a pu évaluer toutes les solutions soumises.

Conclusion

Ce projet m’a pris énormément de temps et causé pas mal de stress, je considère presque comme un miracle le fait que ça ait marché, quand on sait tout ce qui aurait pu faire planter le concours. Il faut comprendre qu’on bosse pendant des semaines sur quelque-chose qui va durer 2 heures. 2 heures qui doivent être un complet sans-faute autant au niveau de la plateforme qui doit tenir la charge, que des problèmes et jeux de test.

Merci beaucoup à toute l’équipe qui a travaillé avec moi là-dessus, et je suis sûr que ça a été une bonne expérience pour nous tous!

Log in to post a comment.