Les coulisses d'Advent of Code

Qui est Eric Wastl ?

Eric Wastl est un développeur aux nombreuses casquettes : actuellement architecte sur une solution d'enchères, il est également passé par une marketplace de TCG (trading card game), ce qui fera rêver les fans de Magic, Pokémon et autres Yu-Gi-Oh. Sur son temps libre, il développe des outils pour les jeux auxquels il joue, fait des bots Discord/IRC, etc., des tutoriels sur une multitude de technologies, et enfin, depuis 2015, mène à bien son side project le plus connu : un calendrier de l'Avent avec des problèmes de logique algorithmique, le bien nommé Advent of Code (AoC).

Qu'est ce que l'Advent of Code ?

Pour résumer simplement ce qu'est l'AoC : c'est un calendrier de l'Avent où l'on vous propose de sauver Noël en résolvant des problèmes. Chaque jour s'accompagne d'une petite histoire qui sert de prétexte à un casse-tête mathématique. Le casse-tête demande uniquement une entrée en réponse, la manière d'y arriver étant laissée à votre imagination pour narrer vos exploits sur les différents réseaux. Une fois que la bonne réponse est donnée, une deuxième partie vient apporter un twist ou une problématique supplémentaire.

Ses motivations pour avoir débuté AoC viennent d'une volonté pédagogique : il aime aider les gens à devenir de meilleurs programmeurs. Il a également remarqué avec l'expérience qu'il apprend mieux quand il a un problème à résoudre. L'idée d'apprendre avec des puzzles est la suite logique de ces deux réflexions.

Comment host ce "petit" side project?

"Va-t-il y avoir du monde ? 50 personnes environ… Allez, on prend 70 utilisateurs simultanés pour être large", se dit innocemment Eric, à l'aube du premier AoC.

Le 30 novembre, il lance le site. Dès le premier jour, à la première connexion, il y a 80 personnes, on reste dans les clous… Puis, minute après minute, le nombre de visiteurs commence à exploser, et les serveurs avec. En 12 h, il y a eu plus de 4 000 personnes ; en 24 h, plus de 9 000, et à la fin du challenge, plus de 52 000 personnes pour la dernière énigme.

Malgré la coupure de son serveur Minecraft, les chiffres devenaient de moins en moins gérables. Il a donc décidé de passer sur une architecture cloud en AWS pour pouvoir encaisser la fréquentation grandissante. Aujourd'hui, c'est 1 400 000 personnes qui se connectent pour résoudre les puzzles, et au moins 930 000 qui ont réussi à décrocher au moins une étoile.

Le COVID aura également participé à la popularisation du challenge, faisant au passage craquer les load balancers, qui ne s'attendaient pas à des pics de visiteurs aussi soudains. L'exercice tombant à une heure fixe, le trafic monte en flèche avant de très vite retomber dans l'heure qui suit. Il a dû œuvrer plusieurs fois avec l'équipe d'AWS pour améliorer la gestion du trafic à cause de cette fréquentation assez singulière.

Pourquoi une telle popularité ?

Lui qui s'attendait à ce que la résolution de problèmes informatiques n'intéresse qu'une niche de la communauté des développeurs, il s'est vite rendu compte que l'AoC venait remplir plusieurs besoins :

• L'entraînement à la résolution de problèmes
• La préparation aux entretiens
• L'entraînement en entreprise
• Les concours de rapidité
• Le challenge entre amis/collègues

Parmi les habitudes des développeurs : la grande majorité de la communauté répond en Python, puis en Rust. Pour le reste, les chiffres sont plus ou moins similaires sur les autres langages les plus populaires : JS, C++, etc. Il y a aussi des excentriques, ce qui amuse énormément Eric Wastl, qui résolvent les puzzles sur Minecraft avec de la redstone ou même sur Excel en faisant du reverse engineering très poussé. On peut noter également pas mal de démarches universitaires ou d'entreprises avec la publication des solutions sur un tableau pour voir qui propose le meilleur algorithme.

Comment faire un bon puzzle ?

• Éviter les ambiguïtés : pas de phrases alambiquées et de multiples interprétations.
• Ne pas parler en data structures ou en termes informatiques : il s'agit de résolution de problèmes concrets.
• Éviter que l'utilisateur ne doive faire des suppositions. Bien se répéter et surligner les éléments importants. Pour chaque phrase, se dire qu'il y a un utilisateur qui risque de zapper la ligne et donc de rater du contexte.
• Faire tester les puzzles pour un regard extérieur.

Quels sont les contraintes lors de la réalisation d'un puzzle Advent of Code ?

• N'avoir qu'une seule réponse possible par input.
• Que l'on puisse le faire dans n'importe quel langage. L'AoC reste une terre d'expérimentation et un bon moyen d'apprendre un nouveau langage.
• Qu'il y ait beaucoup d'inputs possibles.
• Que le puzzle soit en 2 parties:
  • Checkpoint / twist
  • Simuler le monde réel en changeant des paramètres clés en cours de route. Le but c'est de forcer à réfléchir en amont à sa structure pour accueillir plus facilement les évolutions et challenger son code.
• Que les puzzles soient variés.
• Calibration de la difficulté, un des éléments les plus importants; change en fonction de chacun donc pas forcément évident à contrôler. Il existe quand même quelques astuces :
  • Des versions simples pour ensuite introduire des puzzles plus complexes avec des concepts similaires plus tard.
  • Jour de semaine vs weekends: faire varier le temps nécessaire en fonction. Les développeurs ont plus de temps le weekend en général.
  • Variété: si quelqu'un n'aime pas un puzzle, il peut toujours passer à celui d'après, ou en tout cas le lendemain ça ne sera plus le même problème et ça évitera à l'utilisateur de se décourager.
  • Progression a travers le mois, les problèmes deviennent globalement de plus en plus durs, sauf exceptions …
  • Faire des pics de difficulté parfois aléatoire, intéressant au début par exemple, pour forcer certains qui auraient abandonné si le même problème avait été proposé plus loin dans le challenge.
  • Faire des problèmes moins durs par rapport à la courbe de progression de difficulté: Permet d'éviter le burnout et la lassitude d'algorithmes trop complexes.
  • Interprété contre compilé: s'assurer qu'il n'y ai pas de trop de différence de runtime entre les deux.

Comment on le rédiger le problème ?

• Recherche d'inspiration: peut-être un problème rencontré au travail, quelque chose d'intéressant vu lors de la veille technologique ou des problèmes du monde réel.
• Recherche sur la problématique: est-ce que la problématique à déjà une réponse connue qui fera que tout le monde répondra vite ou trouvera la solution ailleurs?
• Design: récupérer la partie intéressante du problème et réussir à la formater de manière à ce qu'elle soit cohérente pour un débutant et que ça ne prennes pas trop de temps.
• Puis création de 3 programmes:
  • Un programme qui générera des inputs (pleins d'inputs)
  • Un solver pour la partie 1 (avec le runtime en tête)
  • Un solver pour la partie 2 (avec le runtime en tête)
• Ecriture de la prose.

Evidemment, l'exécution ne se fait pas toujours dans cet ordre la, tout dépendra du problème.

Réponses atypiques

Parmi les réponses préférées d'Eric Wastl, celles qui se fendent d'une représentation graphique remportent la palme d'or. Chaque année, il scrolle Reddit à leur recherche et prévoit même certains problèmes amenant facilement ce genre de réponse. L'effet est double, en plus d'être visuellement agréable, ces représentations peuvent aider les débutants à imaginer l'algorithme nécessaire pour arriver au résultat.

Voici quelques exemples:

Pour ce qui est de ceux qui sont en haut des leaderboards, les plus rapides d'entre tous, ils ne sont pas forcément des exemples à suivre pour être un bon développeur. Ce sont des gens qui passent leur temps à résoudre ce genre de problème, qui s'éloignent par leur réponse de l'ingénierie logicielle en produisant des codes courts en prenant des raccourcis et en produisant du code pas forcément maintenable qui ne finirait jamais en production. Être un bon développeur et un développeur rapide sont deux choses tout à fait différentes.

Les problématiques

• Arrêter de prioriser les choses.
• Demander de l'aide autour de soi.
• Ecrire de la meilleure documentation tous les ans, pour ne pas être perdu quand il revient dessus à chaque milieu d'année.
• Avoir une super communauté qui l'aide.
• Automatiser des taches et faire des helpers.
• Attaque Denial of Service: AWS à des tools pour se protéger heureusement.

Accessibilité

• Prendre les feedbacks sur l'accessibilité sérieusement.
• Suivre les WCAG AAA guidelines.
• Tester avec les outils d'assistances.

FAQ

• Pourquoi à cette heure là ? Parce que c'est l'heure à laquelle il est disponible et réveillé pour surveiller que les serveurs tiennent la route. Faire autrement ne serait pas viable pour son rythme de travail / vie de famille.
• Quel temps pour faire 25 puzzles ? Au moins tous les soirs pendant 2 à 4 mois, mais ça varie chaque année selon les puzzles. Ce à quoi se rajoute des moments d'organisation / écriture des histoires.
• Peut on envoyer des idées de puzzles? Il ne les lit pas, principalement pour ne pas avoir de soucis de droit d'auteur. De toute façon, il a déjà largement assez idées de côté chaque année.
• Comment certains font aussi vite ? Est-ce qu'ils trichent ? Non, ils sont juste extrêmement rapide. Ils ne lisent pas le puzzle, juste les keywords / les questions et codent en même temps. Certains enregistrent leurs écrans, si vous voulez vérifier, c'est assez impresionnant.

Anecdotes qui le pousse à continuer

• Une mère est étonné de voir son ado se lever pour faire ça, et vient sur redit pour comprendre ce qu'il va dire plus tard.
• J'ai eu un job grâce à AoC 2016
• Ma famille s'intéresse au code grâce à AoC
• Certains professeurs d'université s'en servent comme exercices de partiel.

Conclusion:

Les ingénieurs devraient résoudre des puzzles pour le plaisir. Rectification: TOUT LE MONDE devrait résoudre des puzzles pour le plaisir.

Source:

Article basé sur ce talk donné par Eric Wastle: https://www.youtube.com/watch?v=uZ8DcbhojOw

Le site d'Eric Wastl: https://was.tl/