Cette semaine, c'était le challenge Codingame de printemps.

Il s'agissait cette fois-ci de faire pousser des arbres, en évitant de subir l'ombre de l'adversaire. Et du fait du contexte épidémique actuel, je ne pouvais pas participer comme je l'aurai souhaité : j'ai arrêté de coder mercredi soir, et j'ai choisi très volontairement, de coder en Rust, qui n'est pas le langage le plus simple (franchement l'un des plus complexes que je connaisse, en fait).

Et comme un bonheur n'arrive jamais seul, les règles incluaient certains éléments qui ont clairement augmenté la complexité du problème.

• D'abord le fait que le terrain soit hexagonal ajoute une complexité certaine : le stockage de données dans un tableau de tableaux n'est à priori pas utilisable (j'écris à priori très volontairement parce que je conservais, depuis Coders of the Carribean, un excellent article de référence sur la modélisation de terrains hexagonaux).
• Par ailleurs, l'unité de tour de jeu, le jour, n'est en fait pas atomique : les deux joueurs vont effectuer alternativement autant d'opérations qu'ils le peuvent, en continuant même si l'adversaire n'a plus d'actions possibles. Pour moi, ça a ajouté beaucoup de complexité.
• En plus, chaque joueur a deux échelles à optimiser : le nombre de points de soleil produits chaque jour, et le score final (qui dépend des arbres récoltés, de leur ordre de récolte et de la position de la récolte).

Franchement, quand on ajoute tout ça, ça donne un résultat facilement complexe. Et comme je n'avais aucune intuition géniale, j'ai utilisé un modèle de programmation hyper classique (pour moi) :

1. Décrire chaque entité du jeu dans un type (on a donc une Action qui est un enum Rust, un struct pour chaque arbre, et enfin un modèle représentant le terrain). Petite subtilité : j'avais commencé par représenter le terrain via l'une des structures indiqué dans l'article mentionné plus haut, avant de me rendre compte que le moteur de jeu fournissait la géométrie du terrain au démarrage, du coup, il était bien plus simple de simplement stocker la géométrie dans un Vec, et le contenu dans un autre Vec.
2. A partir de là, déterminer toutes les actions possibles
3. Éliminer les actions dont le coût est supérieur aux points de soleil disponilbe
4. Et trier les actions selon une heuristique

Avec ça, j'arrive à cette solution qui atteint le niveau argent. Pas trop mal en sachant que j'ai arrêté de coder mercredi ...

Bon, là; je me donne des excuses faciles.

En vérité, je savais dès Lundi, en particulier à la lecture de cet article sur les échecs "A step-by-step guide to building a simple chess AI" que ce que je faisais n'avait pas du tout les moyens d'atteindre le haut niveau. Sauf que j'ai été intellectuellement bloqué par le fait que ce que je voyais comme l'unité de durée du tour (la journée) ne l'était pas. Et je pense sincèrement que c'est un blocage psychologique stupide de ma part. Ca veut dire quelque chose sur moi, et quelque chose de pas très chouette (mais que je sais déjà). J'ai bien l'impression d'être incapable de tenter des solutions authentiquement innovantes (pour moi) quand je suis pris par la pression du temps. Pour le dire autrement, le biais d'ancrage est fort. Suffisamment fort pour que, la prochaine fois que je suis tenté de faire un challenge codingame, je m'oblige à utiliser ces fameuses techniques de Monte-Carlo, de min-max et autres, qui impliqueront des solutions pas forcément répétables, mais ça n'est pas trop grave.

Parce qu'il y a quand même des choses qui ont bien marché !

J'ai enfin réussi à comprendre le sens des lifetimes Rust ! Et ça implique que j'ai réussi à écrire du code avec beaucoup moins de clone(). Et ça implique à son tour que ce code, qui certes ne fait pas grand chose, est beaucoup plus efficace que mes précédentes solutions.

En bonus, mon article précédent expliquant comment démarrer une solution Rust m'a vraiment beaucoup aidé : je n'ai eu aucun mal à produire une solution raisonnablement intéressante.

Bref, j'ai encore appris beaucoup sur moi, et c'est ce que je demande à Codingame !

Pour ceux qui ne savent pas de quoi je parle, j'ai un projet de lifestream sur lequel je travaille depuis des années (les archives du tag remontent à 2010 au moins). ce projet a connu plusieurs incarnations. La dernière était un ensemble de plugins maven générant des fichiers Asciidoc que je passais ensuite dans un plugin JBake pour générer un site statique. Sur le papier, l'idée était chouette.

Mais le vrai problème d'un projet de développeur, c'est de le faire survivre à la prod. Mon choix pour la prod était de tout faire tourner sur mon Raspberry, parce qu'il tourne, et que je m'attache de plus en plus à limiter mon empreinte carbone numérique. Sauf que le Raspberry 3 a une mémoire limitée, et que mon lifestream comprend quelques fichiers :

• 2200 fichiers générés depuis Goodreads
• 8400 fichiers générés depuis Shaarli
• 1300 fichiers depuis Wordpress

Ca fait un bon paquet, et même en essayant d'optimiser les choses, je n'arrive pas à générer un site viable. Qu'est-ce que je peux faire maintenant ?

• La solution la plus simple serait de changer de machine de génération : faire ça depuis un vrai ordinateur (comme par exemple celui depuis lequel j'écris cet article) avec une belle quantité de RAM me sortirait cette épine du pied
• Une autre solution serait d'abandonner le site statique pour passer à un site dynamique ... mais ça m'embête beaucoup

Parce que l'un des prérequis de ce lifestream est d'être hébergé dans les pages perso de free.fr. Pourquoi ? Parce que c'est une solution performante :

C:\Users\nicolas-delsaux>hey http://nicolas.delsaux.free.fr/lifestream/

Summary:
  Total:        6.2935 secs
  Slowest:      4.1379 secs
  Fastest:      0.3488 secs
  Average:      1.0254 secs
  Requests/sec: 31.7790

  Total data:   6755645 bytes
  Size/request: 33778 bytes

Response time histogram:
  0.349 [1]     |
  0.728 [104]   |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
  1.107 [38]    |■■■■■■■■■■■■■■■
  1.486 [22]    |■■■■■■■■
  1.864 [13]    |■■■■■
  2.243 [6]     |■■
  2.622 [6]     |■■
  3.001 [1]     |
  3.380 [2]     |■
  3.759 [4]     |■■
  4.138 [3]     |■

Vous pouvez faire le test de chez vous, vous aurez normalement d'assez bonnes performances. Malgré la lenteur des machines de free.fr. Et ça, c'est un des plus importants objectifs de ce projet.

Du coup, je pense que la prochaine étape devrait tout simplement être de déplacer la génération vers mon ordinateur de bureau, avec une quelconque solution de tâche planifiée pour Windows ... Je vais néanmoins ajouter l'écriture des fichiers dans un repository GitHub, pour faciliter la réutilisation, et travailler sur l'écriture dans un outil comme AsciiBlog. Ou alors tenter de générer le site dans GitHub Pages, ce qui pourrait aussi être chouette (même si ma 1/2 heure de génération JBake ne risque pas d'être compatible avec GitHub Actions). Bref, j'ai encore des idées...

Evidement, je ne parle pas de jouer moi-même au pacman, mais plutôt de celui auquel il faut jouer dans le spring challenge 2020. Parce que comme j'ai l'intention de concourir dès demain, en essayant autant que possible de faire du Rust, j'ai essayé de me remettre à niveau en reprenant le problème précédent, et en essayant d'améliorer la solution dont je disposais déja. Et, comme vous pouvez le voir dans cette simulation, ça ne marche pas si bien. Avant d'aller plus loin, on va d'abord voir rapidement ce que fait mon robot.

Donc, à chaque tour

• D'abord, je découpe le terrain (autrement dit, je construis un pavage du plan) pour disposer pour chaque pac d'un terrain disjoint.
• Et ensuite, pour chaque pac, je score chaque déplacement en fonction des pillules atteignables au 7 prochains tours.

Il y a un certain nombre de choses qui ne sont pas implémentées, et c'est normal : je ne gère pas les ennemis, ni les changements de couleur, ni même le boost. Bref, c'est pas le niveau argent ...

Cela dit, mon robot est bien plus mauvais que simplement parce qu'il n'implémente pas ces fonctionnalités. Ce qui le rend vraiment mauvais, c'est qu'il privilégie l'accessoire à l'essentiel. Parce que dans ce jeu, il y a deux choses essentielles :

1. Survivre à l'adversaire
2. Manger les grosses pilules

Et mon code n'essaye de faire aucun des deux ... Bon, c'est con. Et, pire que tout, il n'est même pas performant, sans doute parce que le pavage du plan est assez consommateur en temps. Bref, la prochaine fois que je voudrais m'y mettre, je pense que je suis bon pour ... supprimer tout le code existant et tout refaire, tout simplement. J'ai donc appris un certain nombre de choses. La plus importante étant que faire du code performant en Rust ... c'est pas facile du tout. Lisez donc tranquillement cet article Moves, copies and clones in Rust, et vous comprendrez que l'impact de la sécurité mémoire sur le code écrit est loin d'être négligeable. Et je trouve ce problème assez ... stimulant (même si ça me donne parfois l’impression d'avancer avec un boulet au pied).

Suite à mon précédent article un poil critique sur la revue de code, j'ai eu droit à une question intéressante de la part de mon collègue Douglas

sixdouglas Douglas SIX 10 avr. 2021 à 08:38:35 @nmahoude @riduidel Par contre, comment gérerais tu cette activité dans le cadre d’une équipe qui n’a pas une connaissance profonde du produit sur lequel elle travaille (je parle du turnover de l’équipe) ? Pourrait-on simplement faire de la conception ensemble ?

La première chose à noter dans cette question, c'est l'insistance sur le fait que les développeurs ne connaissent pas forcément le produit sur lequel ils travaillent. Et c'est parfaitement vrai.

Donc, ça veut dire quoi "concevoir un développement" ? Il s'agit tout simplement de jouer, pour un développement particulier, le rôle de l'architecte. Et là, je n'aide personne, puisque le rôle de l'architecte est particulièrement flou dans le monde du logiciel. Néanmoins, pour une fois, je pense que la définition de Grady Booch est appropriée :

Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change.

Grady Booch - On design (voir aussi Software Architecture and Related Concerns)

Donc, quand on joue le rôle d'architecte pour un développement, c'est-à-dire qu'on le conçoit, on doit se poser les questions concernant les changements significatifs qu'on va apporter au système. Et pour revenir à la question de Douglas, c'est une excellente façon de découvrir le système et de le comprendre. Autrement dit, je propose d’utiliser ces phases de conception pour prendre le temps de découvrir ce qu'on va modifier.

Mais comment rendre cette connaissance partageable ? D'abord, via un support commun. Et si les issues des bugtrackers marchent bien pour discuter de petites modifications, je trouve que, pour les gros développements, il vaut parfois mieux créer un vrai document de conception qu'on mettra avec la documentation d'architecture - dans la section ADR. Sauf que j'aurais tendance à ne pas formaliser mon ADR aussi simplement que ce que proposent les différents modèles. Non, à titre personnel, j'aurais plutôt tendance à présenter le problème, puis la description de la solution en reprenant justement le plan de l'agile architecture documentation. Parce qu'il permet précisément de segmenter le gros problème en ses différentes facettes.

Typiquement, une grosse fonctionnalité, une qui requiert une documentation spécifique, va avoir des impacts sur différents éléments du logiciel : l'architecture, les donnée,s le déploiement. Et ce modèle de document couvre correctement ces différentes questions, comme je l'ai déjà écrit. Qui plus est, il permet facilement l'amélioration collaborative : un premier rédacteur peut lancer ses idées, et les voir améliorées par un second rédacteur.

Ce qui permet quelque chose que je trouve de plus en plus souhaitable, aussi bien organisationnellement que techniquement : remplacer le synchrone par l'asynchrone via un support permanent, et constamment amélioré.

Pour l'écrire autrement, ce que je propose est assez simple : quand vous lancez un nouveau développement, demandez à un nouvel arrivant d'en faire la conception en suivant le modèle de l'agile architecture documentation, en commençant par un simple commentaire dans le bug tracker puis, si il s'avère que la fonctionnalité est trop importante, dans un document que vous placerez dans vos ADR. Et relisez ce qu'il produit avant de lancer le développement.

La semaine prochaine, c'est le spring challenge !

Et comme l'année dernière, je vais essayer de le faire en Rust (un poil poussé par des collègues).

Mais contrairement à l'année dernière, j'essaye de préparer ma participation histoire de ne pas me faire avoir. Donc, voici une checklist de quelques détails utiles

• Créer le projet cargo avec cargo init --lib . (pour créer une bibliothèque plutôt qu'un binaire). Tout le code sera dans le fichier lib.rs parce que je n'ai pas encore trouvé la bonne façon d'utiliser include!(...) pour avoir plusieurs fichiers.
• Dans le dossier tests, créer un fichier design_tests.rs et un fichier integration_tests.rs
• Aller chercher dans target/debug/deps les exécutables qui doivent s'appeler design_tests_{un hash pourri}.exe et integration_tests{un autre hash pourri}.rs pour créer les configurations de debug de VSCode
• Le code doit avoir à peu près la forme suivante
  • Je lis les entrées
  • Je calcule mes sorties
  • IMPORTANT j'appelle la méthode qui génère le code du test d'ntégration
  • Et enfin je retourne ma sorte

Et avec ça, je devrais pouvoir coder assez rapidement, même si ça n'est pas automatique que ce que j'avais en Java.