Tarik Hireche

Resident.java

780 → 106 lignes

Les écrans, un client HTTP, l'analyse JSON et les lectures au clavier en sont sortis. Il reste les sept champs d'une personne et les deux opérations qui lui appartiennent.

Menu.java

579 → 97 lignes

Les deux écrans de connexion, les deux écrans d'inscription, les deux menus principaux et cinq validateurs de saisie en sont sortis. La classe choisit maintenant entre se connecter et s'inscrire.

Suite de tests

9 → 35 tests

Sur 6 fichiers, contre 3. L'ancienne suite avait besoin d'une API tierce en direct pour passer ; mvn test n'a plus besoin ni de réseau ni de terminal.

Bogues de duplication trouvés

6

Chacun est apparu en fusionnant des copies du même code. Ils sont listés dans le commit qui les a supprimés.

On était trois à construire ça pour un cours et ça marchait très bien sur nos machines. C'était justement le problème. JUnit et Hamcrest étaient versionnés en fichiers jar, et Gson passait par un réglage IntelliJ qui pointait vers un dossier sur le portable de quelqu'un. N'importe qui d'autre qui clonait obtenait un mur d'erreurs. Passer à Maven a été la première chose que j'ai faite.

La partie que j'ai trouvée la plus intéressante, c'est la découpe de Resident.java. 780 lignes qui faisaient environ cinq métiers à la fois : garder les informations d'une personne, dessiner les écrans, appeler l'API de la ville, analyser le JSON et lire le clavier. J'ai sorti le réseau et l'analyse dans leur propre paquet, et les écrans dans un autre. Ça a fait remonter un bogue que j'aime bien : la liste des dix types de travaux existait en trois copies séparées qui avaient divergé, donc l'option 8 affichait « Travaux résidentiel » sur un écran et « Travaux résidentiels » sur un autre. Un résident pouvait déposer une requête et ne jamais la retrouver. C'est une seule énumération maintenant, avec un test qui échoue si les libellés cessent de concorder.

La plupart des bogues que j'ai trouvés venaient de la même cause : la même logique écrite plus d'une fois. L'autre chose que j'en retiens, c'est que séparer le code qui va chercher du code qui analyse est ce qui a permis aux tests de tourner sans réseau. L'ancienne suite avait un test qui appelait l'API de la ville en direct, donc la compilation échouait sur toute machine qui ne pouvait pas l'atteindre.

Sites suivis

421

boards_known dans le health.json que le balayage publie en direct. Allez le lire, le dépôt de données est public.

Offres dans le flux actuel

442

Réparties sur 268 entreprises distinctes, après déduplication, notées et classées. Comptées depuis le jobs.json en direct.

Offres balayées en amont

3 331

last_count du dernier balayage. Récupérées avec un ETag, donc une source inchangée coûte un 304 et aucune analyse.

Rafraîchissement du tableau

120 s

La page relit le flux sur minuterie. Chaque requête contourne le cache, puisque le CDN envoie max-age=300 et qu'un cache de cinq minutes annulerait l'intérêt de l'outil.

J'en avais assez de consulter les sites d'offres à la main chaque matin, alors j'ai construit quelque chose qui le fait sur planification. J'ai utilisé de l'aide de l'IA pour la plus grande partie de l'implémentation. Ce que j'ai fait moi-même, c'est décider comment les pièces s'emboîtent, écrire une courte spec pour chacune, et fixer le format JSON qu'elles se passent avant qu'il y ait du code. Ensuite j'ai relu ce qui revenait, je l'ai testé et j'ai corrigé ce qui n'allait pas. Pouvoir lire et déboguer ce code est la partie qui compte pour moi.

C'est en trois parties. Un dépôt privé contient la planification et mes filtres et lance la récupération. Un dépôt public ne contient que le JSON produit. Une page statique lit ce JSON directement depuis le navigateur. Il n'y a de serveur nulle part là-dedans, ce qui le garde gratuit à faire tourner et fait qu'il n'y a rien à maintenir en vie.

La panne que je n'avais pas anticipée, c'est un travail planifié qui s'arrête en douce. Il ne vous prévient pas. Il continue d'afficher ce qu'il a récupéré la dernière fois, ça a l'air parfaitement normal, et vous le remarquez une semaine plus tard. Donc chaque passage note maintenant quand il a tourné et quelles sources ont répondu, et la page affiche l'âge des données. J'ai aussi appris comment marchent les ETags en construisant l'étape de récupération : si un site n'a pas changé depuis la dernière fois, il répond 304 et il n'y a rien à télécharger ni à analyser.

Arrêt après SIGTERM

2,5 à 3,1 ms

Sept exécutions contre un worker supervisé par sentinel, chronométrées en attendant le processus. Le même worker seul était encore vivant à dix secondes et a dû être tué.

Enfant qui ignore SIGTERM

5,003 s

Même montage avec le worker qui ignore le signal exprès. Trois exécutions à moins d'1 ms d'écart. C'est le délai de cinq secondes qui fait son travail.

Suite de tests

13 sur 13

ctest sur une compilation release, 33 s. La CI lance build, test, shellcheck, docker et compose comme jobs séparés.

Je voulais comprendre ce qui se passe vraiment quand on demande à un conteneur de s'arrêter. Docker envoie SIGTERM et attend dix secondes avant de le tuer. Linux traite le premier processus d'un conteneur comme un cas spécial et ne lui livre pas un signal tant que ce processus n'a pas installé de gestionnaire, donc un programme assis à cette place passe les dix secondes à ignorer la demande puis meurt en plein travail. sentinel prend cette place, transmet le signal au vrai programme, et s'efface.

Le bogue sur lequel j'ai passé le plus de temps, c'est un intervalle entre le démarrage du processus enfant et l'installation des gestionnaires. Un signal d'arrêt arrivant dans cette fenêtre tuait sentinel et laissait l'enfant tourner dans la nature, ce qui est exactement ce que le programme existe pour éviter. Je l'ai connu un moment et j'ai laissé un TODO dessus avant de comprendre que bloquer ces deux signaux le temps du démarrage, puis les débloquer une fois les gestionnaires en place, referme la fenêtre.

Une bonne partie de ce projet, c'était lire des pages de manuel puis tester si j'avais bien compris. Ce qui m'est resté : mesurer est plus dur qu'il n'y paraît. Mon premier chiffre d'arrêt était dix fois trop élevé parce que je vérifiais dans une boucle et je lisais mon propre délai. Attendre le processus correctement a donné le vrai chiffre.