🟨2026.04.03
C Orienté Objet | 2

Nous avons lors du premier épisode créé une “classe” Person, mais elle se sent bien seule. Les objets sont fait pour communiquer, avoir des relations, s’envoyer des messages. Pour l’instant, nous n’avons rien de tout ça. Commençons.

Une table de personnes

Je voudrais avoir un tableau de personnes, avec la possibilité d’y ajouter et d’en retirer des éléments, de supprimer ou récupérer des éléments par leur index, de savoir si la table contient une certaine personne, et d’en afficher le contenu. On a du boulot. Commençons par écrire personsTable.h pour définir tout ça proprement:

#include <stdbool.h>
#include "person.h"

typedef struct PersonsTable PersonsTable;

PersonsTable* PersonsTable_make();
void PersonsTable_destroy(PersonsTable* t);
void PersonsTable_add_person(PersonsTable* t, Person* p);
bool PersonsTable_remove(PersonsTable* t, int idx);
Person* PersonsTable_get(PersonsTable* t, int idx);
bool PersonsTable_contains(PersonsTable* t, Person* p);
void PersonsTable_print(PersonsTable* t);

Il y a de nombreuses façons d’implémenter ces fonctionnalités. L’idée est donc ici que les utilisateurs de ma “classe” ne devront pas s’en préoccuper. Et si je veux changer, ça ne devrait pas les affecter.

En particulier, j’ai deux grands choix à faire ici:

• Quelle structure de donnée utiliser pour la “table”?
• Quelle est la définition de l’égalité pour mes Personnes (c’est-à-dire: comment je détermine si ma table contient une certaine Personne).

Cette seconde question va me faire évoluer la classe Person. Commençons par là.

Égalité des personnes

Je dois rajouter une méthode dans person.h:

bool Person_equals(Person* p, Person* other);

Et évidemment l’implémenter dans person.c. Je peux utiliser strcmp pour comparer des chaînes de caractères. Je prendrai donc la définition de l’égalité ici comme: “a le même nom et le même prénom”. J’aurais pu à la place choisir de vérifier si l’adresse des deux objets en mémoire était la même, mais ce serait fort limitant. Évidemment, dans un vrai système, j’aurais besoin de quelque chose de plus “identifiant” que le nom et le prénom, mais on va rester simple pour l’instant. strcmp compare deux chaînes de caractères (“null-terminated”, c’est-à-dire qu’il y a un caractère nul \0 pour marquer la fin), et renvoie 0 si tous les caractères sont les mêmes.

bool Person_equals(Person* p, Person* other) {
    return (strcmp(p->first_name, other->first_name)==0 && 
            strcmp(p->last_name, other->last_name)==0);
}

Testons dans le main:

Person* p = Person_make("Adrien", "Foucart");
Person* other = Person_make("Adrien", "Foucart");
Person_print(p);
Person_print(other);
if (Person_equals(p, other)){
    printf("Persons are equal.\n");
}
else {
    printf("Persons are not equal.\n");
}
Person_destroy(p);
Person_destroy(other);

Je reçois bien Persons are equal. Et si je change une lettre à mon nom, j’ai bien unequal. Tout va bien! Revenons à notre table.

Tableau redimensionnable

Une manière classique de réaliser une table est le principe du “tableau redimensionnable”. Il implique de garder en parallèle une “taille physique” (espace mémoire occupé par la table) et une “taille logique” (nombre d’éléments dans la table). Lorsque la taille logique rattrape la taille physique, on agrandit la table (généralement en la doublant). On traduit ça dans notre struct PersonsTable:

// personsTable.c
struct PersonsTable {
    Person** table;
    int capacity;
    int size;
};

Le constructeur devra donc donner une capacité initiale à la table, et une taille logique (size) de 0. Notons le “double pointeur” pour table. Schématiquement, j’ai:

[table] --> Addr: 0x1234 (exemple)
[0x1234] --> [Person a]
[0x1235] --> [Person b]
[0x1236] --> [Person c]

table pointe vers l’adresse du premier élément du tableau, qui se trouve quelque part dans la mémoire du programme. Ce premier élément est lui-même un pointeur vers une Person. L’élément suivant dans la mémoire sera le pointeur vers la personne suivante, etc. Au niveau du constructeur, j’aurai alors:

PersonsTable* PersonsTable_make(){
    PersonsTable* pt = malloc(sizeof(PersonsTable));
    pt->size = 0;
    pt->capacity = 16;
    pt->table = malloc(sizeof(Person*)*pt->capacity);
    return pt;
}

J’ai deux malloc dans le constructeur, j’aurai donc besoin de deux free dans le destructeur:

void PersonsTable_destroy(PersonsTable* t) {
    free(t->table);
    free(t);
}

Notons un choix fait ici: je ne libère pas les Person. Elles n’ont pas été construites par la classe table, donc elles peuvent exister ailleurs dans le programme. Ce n’est pas la responsabilité de PersonsTable de s’en préoccuper.

Quand on ajoute une personne, on doit d’abord vérifier si on ne doit pas allonger la table (avec realloc). Et il ne faut pas oublier d’incrémenter la taille.

void PersonsTable_add_person(PersonsTable* t, Person* p) {
    if (t->size == t->capacity){
        t->capacity *= 2;
        t->table = realloc(t->table, t->capacity);
    }
    t->table[t->size++] = p;
}

Pour retirer une personne, il faut s’assurer que l’index est valide. On retire une personne en décalant les éléments suivants vers la gauche. On renvoie un booléen pour indiquer si l’opération a réussit. Et on n’oublie pas de décrémenter la taille.

bool PersonsTable_remove(PersonsTable* t, int idx) {
    if (idx < 0 || idx >= t->size)
        return false;

    for (int i = idx; i < t->size - 1; i++)
        t->table[i] = t->table[i+1];

    t->size--;
    return true;
}

Récupérer un élément est assez simple. On renvoie NULL si l’index n’est pas valide:

Person* PersonsTable_get(PersonsTable* t, int idx) {
    if (idx < 0 || idx >= t->size)
        return NULL;

    return t->table[idx];
}

Pour savoir si notre table contient un élément, on n’a pas trop le choix: il faut les parcourir tous. Je ne prétends pas ici à une grande efficacité!

bool PersonsTable_contains(PersonsTable* t, Person* p) {
    for (int i = 0; i < t->size; i++){
        if (Person_equals(p, t->table[i]))
            return true;
    }

    return false;
}

Et finalement on veut pouvoir les afficher:

void PersonsTable_print(PersonsTable* t) {
    printf("[PersonsTable]:\n");
    for (int i=0; i < t->size; i++){
        printf("\t");
        Person_print(t->table[i]);
    }
}

Important ici: pour ces deux dernière méthodes, nous avons fait appel aux méthodes de Person. Des objets qui s’envoient des messages, comme il faut!

Reste à tester que ça fonctionne.

int main(){
    printf("Start program\n");

    // Create test persons
    Person* p = Person_make("Adrien", "Foucart");
    Person* other = Person_make("Leonardo", "Da Vinci");

    // Create and fill table
    PersonsTable* pt = PersonsTable_make();
    PersonsTable_add_person(pt, p);
    PersonsTable_add_person(pt, other);

    PersonsTable_print(pt);
    
    // check contains method
    if (PersonsTable_contains(pt, p)){
        printf("Table contains person: ");
        Person_print(p);
    }

    // check get method
    Person* found = PersonsTable_get(pt, 1);
    Person_print(found);

    // check remove
    PersonsTable_remove(pt, 0);
    PersonsTable_print(pt);
    
    if (!PersonsTable_contains(pt, p)){
        printf("Table does not contain person: ");
        Person_print(p);
    }

    PersonsTable_destroy(pt);
    Person_destroy(p);
    Person_destroy(other);

    printf("End program\n");
    return 0;
}

Ce qui me donne:

[PersonsTable]:
        [Person]: Adrien Foucart
        [Person]: Leonardo Da Vinci
Table contains person: [Person]: Adrien Foucart
[Person]: Leonardo Da Vinci
[PersonsTable]:
        [Person]: Leonardo Da Vinci
Table does not contain person: [Person]: Adrien Foucart
End program

Un peu de recul

Qu’avons-nous jusqu’à présent?

• Des objets qui offrent des interfaces publiques et disposent d’attributs privés.
• Des objets qui sont responsables des opérations qui les concernent, et peuvent déléguer du travail en envoyant des messages.

C’est déjà pas mal, pour une poignée de lignes de code!

Mais j’ai l’impression qu’on peut aller un peu plus loin. Une prochaine fois.

[lien permanent]

🟨2026.04.01
C Orienté Objet | 1

Le C n’est généralement pas un langage associé à la programmation orientée objet. Quand j’ai appris le C++, on me l’a initialement un peu présenté comme “du C mais avec des objets”, et c’est comme ça que j’ai généralement regardé ces langages (que j’utilise très peu) jusqu’à présent.

Mais en “jouant” à résoudre les vieux puzzles Advent of Code en C (voir mes notes à ce sujet!), je me suis rendu compte que je commençais à utiliser naturellement des principes “orienté objet” dans mes résolutions. On a parfois je pense (en tout cas moi!) un peu tendance à réduire “orienté objet” à “on peut déclarer des classes”. Mais on peut avoir des classes et des objets sans faire de la programmation orientée objet (beaucoup de projets Python en sont un bon exemple!), et on peut faire de la programmation orientée objet sans classes. Car au-delà de la syntaxe, c’est surtout dans la façon d’organiser et de penser son code que les concepts orientés objets apparaissent.

Et après tout, beaucoup de langages “orientés objets” sont écris en C, donc c’est nécessairement possible d’en faire en revenant à la source!

Essayons.

Une classe Person

Commençons par un classique: une classe Person, qui contiendrait un nom et un prénom. Nous n’avons pas de “classes” en C, mais on peut déclarer des structures:

struct Person {
    char* first_name;
    char* last_name;
};

Ici, on a donc bien une Person qui possède un first_name et un last_name. Si je veux l’utiliser dans mon code, je pourrais faire quelque chose comme ceci:

struct Person* p = malloc(sizeof(struct Person));
p->first_name = "Adrien";
p->last_name = "Foucart";
printf("%s %s\n", p->first_name, p->last_name);
free(p);

Avec malloc, j’alloue dans ma mémoire l’espace pour mes deux pointeurs, que je fais pointer vers des chaînes de caractère.

Dans une logique “orientée objet”, cependant, je ne veux pas que ces détails d’implémentation de ma classe (comme le nom des attributs) soient connus. Je voudrais idéalement ne manipuler que des méthodes “publiques”.

On va donc commencer par créer deux fichiers: person.c et person.h. Dans person.h, nous allons mettre nos déclarations publiques:

// person.h
typedef struct Person Person;

Person* Person_make(char* first_name, char* last_name);
void Person_destroy(Person* p);
void Person_print(Person* p);

Je prévois ici trois méthodes: un constructeur, un destructeur, et une méthode pour afficher le contenu de l’objet. Avec typedef struct Person Person, on permet de ne pas retaper struct Person à chaque fois en lui donnant un “alias” Person.

L’implémentation, maintenant, va se trouver dans person.c, et sera invisible pour les utilisateurs de person.h:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include "person.h"

struct Person {
    char* first_name;
    char* last_name;
};

Person* Person_make(char* first_name, char* last_name){
    Person* p = malloc(sizeof(Person));
    p->first_name = malloc(strlen(first_name)+1);
    p->last_name = malloc(strlen(last_name)+1);
    strcpy(p->first_name, first_name);
    strcpy(p->last_name, last_name);

    return p;
}

void Person_destroy(Person* p) {
    free(p->first_name);
    free(p->last_name);
    free(p);
}

void Person_print(Person* p) {
    printf("[Person]: %s %s\n", p->first_name, p->last_name);
}

Dans le constructeur, on alloue de l’espace pour les chaînes de caractères des noms et prénoms, que l’on copie. On ne veut pas juste copier les pointeurs, sinon celui qui appelle Person_make pourrait ensuite changer la valeur de p->first_name, ou faire un free dessus. Dans le destructeur, on fait le ménage.

Pour utiliser tout ceci, écrivons un main.c:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include "person.h"

int main(){
    printf("Start program\n");

    Person* p = Person_make("Adrien", "Foucart");
    Person_print(p);
    Person_destroy(p);

    printf("End program\n");
    return 0;
}

Ce main n’a plus aucune visibilité sur ce que contient Person. Si j’essaie d’ajouter printf("%s\n", p->first_name);, j’ai une erreur de compilation, car person.h ne contient pas de détail sur les “attributs” de Person. Je ne peux les utiliser qu’à travers ses méthodes.

Autrement dit: Person se comporte maintenant comme un “objet” qui, par exemple en Java, s’écrirait¹:

public class Person {
    private String first_name;
    private String last_name;

    public Person(String first_name, String last_name){
        this.first_name = first_name;
        this.last_name = last_name;
    }

    public void print(){
        System.out.println("[Person]: " + first_name + " " + last_name);
    }
}

On ne va pas encore très loin dans le concept, mais je dirais que ça compte, comme premier pas. Pour la suite… on verra dans les épisodes suivants!

[lien permanent]

⏩2026.03.30
auto-complétion

Durant les séances d’exercice, je me retrouve souvent à réfléchir au rôle que joue l’auto-complétion, et plus généralement les outils de génération de code, dans la pratique de la programmation. Car c’est, je pense, l’un des nombreux domaines où les dommages causés par l’IA générative se fait fortement ressentir.

L’auto-complétion “traditionnelle” fonctionne est simple et largement déterministe: étant donné les éléments présents dans le scope et les premières lettres entrées par l’utilisateur, déterminer quels sont les possibilités de complétion et (seule partie probabiliste) les trier selon leur pertinence. Les outils de génération, eux-aussi, sont (étaient) simple: étant donné un template paramétrable, et une série de paramètres, générer un ou des blocs de code.

Simple, mais puissant. Il y a plus de dix ans maintenant, je l’utilisais pour générer des dizaines de classes à la volée en Java sur base d’un schéma de base de données. Tout le boilerplate répétitif de la création de classes “modèles” et “contrôleurs” était fait, on pouvait se concentrer sur la logique de plus haut niveau du programme.

Et l’auto-complétion classique, en plus d’être un gain de temps, est aussi un formidable outil d’apprentissage et de découverte. Quelles sont les méthodes disponibles depuis cette classe? Tape un ., appuie sur TAB (ou Ctrl-Espace selon les IDEs, en général), et fait défiler tout l’univers des possibilités. Cette auto-complétion fonctionne au rythme du développeur et encourage la réflexion et la remise en question. Il m’est régulièrement arrivé de m’arrêter, intrigué par une proposition de méthode que je ne connaissais pas, de lire rapidement la documentation, et de me rendre compte d’une possibilité que je n’avais pas envisagée pour remplir les besoins de mon programme.

Le code généré, quand à lui, ne nécessitait pas vraiment de relecture. Une fois qu’on avait compris le principe de comment configurer le template, on pouvait être certain que le résultat serait toujours exact, et on garde une compréhension aussi complète que possible de ce qui se trouve dans le code du projet.

Les IAs génératives nous privent de tous ces bénéfices, et ne visent plus qu’à l’objectif de productivité à court terme: produire plus de lignes de codes, maintenant, tout de suite.

L’étudiant.e écrit if, et l’IA propose immédiatement un bloc if-else complet qui fait quelque chose, quelque chose qui à première vue semble toujours logique par rapport à ce qui leur est demandé. Parfois, on peut résoudre un exercice complet à coup de TAB-TAB-TAB jusqu’à ce que tous les tests passent.

On ne sait pas ce qu’il y a dans le code. On ne sait pas pourquoi ça marche. Quand finalement ça ne marche plus, on n’a pas la moindre idée de par où commencer.

Vécu récemment: un.e étudiant.e m’appelle, me montre son code.

– Monsieur, je ne comprends pas ce qu’il se passe.
– Qu’est-ce qui ne marche pas?
– Ca marche, mais je ne comprends pas pourquoi il faut écrire ça.
– Pourquoi tu l’as écrit? Qu’est-ce que tu cherchais à faire?
– …

Je peux alors expliquer le pourquoi, mais la qualité de l’apprentissage n’est jamais la même. On apprend en faisant. Avec l’IA générative, l’étudiant.e ne fait pas, il relit ce que l’IA a fait et pense le comprendre.

Heureusement, iels sont nombreux.ses à s’en rendre compte. Beaucoup m’appellent pour me demander de l’aide pour couper les aides IA. Ils voient bien qu’ils n’apprennent pas. Mais ces outils reviennent, se réactivent, se réinstallent à chaque mise à jour. Ce sont des mauvaises herbes dont ils peinent à se débarrasser. Et la tentation est toujours présente, quand la charge de travail devient un peu trop élevée, lorsqu’on se sent un peu trop largué, lorsqu’on est coincé alors que l’enseignant.e est occupé.e avec d’autres et qu’on a envie d’avancer.

L’utilisation des IAs génératives brident l’apprentissage. C’est dramatique pour les étudiant.es, c’est problématique même pour les développeur.euses aguerri.es. J’ai beaucoup appris durant cette première année en tant qu’enseignant, à donner des cours dans des matières qui ne sont pas nécessairement les miennes. Je suis un meilleur développeur aujourd’hui que je ne l’étais il y a un an. Et je le dois, je crois, au fait que je me suis forcé à toujours faire les choses moi-même, à faire tous (ou presque) les exercices qu’on demande aux étudiant.es de faire, à me donner des petits projets pour aller plus loin. Et toujours j’ai cherché à avancer à petits pas, en comprenant à chaque étape ce que je faisais et pourquoi je le faisais.

Serais-je allé plus vite avec Claude à mes côtés? Peut-être. Mais j’en serais sorti diminué. Au fur et à mesure des années, je suis persuadé que celleux qui se reposent sur Claude et ses amis seront de moins en moins compétents, de moins en moins capable de réfléchir, de moins en moins capable de penser une solution. Je crois qu’aujourd’hui déjà, et certainement demain après l’éclatement de la bulle spéculative des IAs génératives, être capable de développer sans agent à mes côtés est une compétence qui n’a pas de prix.

[lien permanent]

🛑2026.02.07
java test runner

Les tests unitaires en Java semblent assez désagréable à mettre en place. Le framework le plus utilisé semble être JUnit, et à première vue ça me semble un peu “usine à gaz”. Il y a aussi visiblement eu de gros changements entre les versions, et les tutoriels que j’ai trouvé sont pour la plupart obsolètes.

Mes besoins en tests unitaires sont assez limités. Je ne compte pas faire des tonnes de réflexion, de mocking ou autres joyeusetés. Je voudrais juste pouvoir facilement créer des classes de test, et avoir un point d’entrée d’où je peux tous les lancer automatiquement. Ca ne devrait pas nécessiter de faire tout un setup Maven ou Gradle et d’importer des jar dans tous les sens.

On va voir: faisons un petit “test runner” Java en utilisant uniquement la librairie standard.

Première étape: les tests à tester

Dans mon dossier src, où j’aurais dans un projet les “vraies” classes développées, mettons un dossier Test et créons une classe TestTest qui servira à tester le test runner. Rien de confus jusqu’à présent.

package Test;

public class TestTest {
    public static void testSuccess(){
        assert true : "if this fails, we are in trouble.";
    }

    public static void testFailed(){
        assert false : "test has failed successfully!";
    }
}

On met deux tests dedans: le premier devrait réussir, le second échouer.

Deuxième étape: lancer les tests

Ajoutons maintenant une classe TestRunner, avec une méthode main. C’est ici que toute la partie intéressante doit se passer. Commençons simplement et laissons de côté la partie “découverte des classes et méthodes de test” pour juste lancer les deux tests et vérifier que tout se passe comme prévu.

package Test;

public class TestRunner {
    public static void main(String[] args){
        TestTest.testSuccess();
        TestTest.testFailed();
    }
}

On lance… et rien ne se passe. Petit moment de recherche: par défaut, les assertions en Java sont désactivées. Pour qu’elles aient de l’effet, il faut aller modifier le DefaultAssertionStatus du ClassLoader:

public class TestRunner {
    public static void main(String[] args){
        ClassLoader loader = ClassLoader.getSystemClassLoader();
        loader.setDefaultAssertionStatus(true);

        TestTest.testSuccess();
        TestTest.testFailed();
    }
}

On relance:

Exception in thread "main" java.lang.AssertionError: test has failed successfully!

Parfait.

On continue: trouver les méthodes dans une classe

La classe Class permet de récupérer les méthodes qui existent dans une classe donnée. Imaginons donc qu’on a une liste de “classes de test”. On peut parcourir ces classes et récupérer leurs méthodes:

public class TestRunner {
    private static String[] testClasses = {"TestTest"};

    public static void main(String[] args){
        // ...
        for (String c: testClasses){
            try {
                Class testClass = Class.forName(c);
                Method[] methods = testClass.getDeclaredMethods();
                for (Method m : methods) {
                    System.out.println(m.getName());
                }
            } catch (ClassNotFoundException e) {
                System.err.println("Class not found: " + c);
                return;
            }
        }
    }

Ce qui me donne…

Class not found: TestTest

Effectivement, le “nom” de la classe doit inclure le nom du package:

    // ...
    private static String[] testClasses = {"Test.TestTest"};
    // ...

On a maintenant:

testSuccess
testFailed

Parfait.

Invoquer les méthodes et récupérer les exceptions

Reste à invoquer la méthode, ce qu’on fait avec evoke:

public class TestRunner {
    // ...
    public static void main(String[] args){
        // ...
            for (Method m : methods) {
                m.invoke(null);
            }
        // ...
    }

Mon IDE me signale que je dois traiter des possibles IllegalAccessException et InvocationTargetException. La première peut arriver si la méthode que je cherche à invoquer est privée. Ceci nous donne donc gratuitement un filtre sur notre méthode de découverte: si la méthode est privée, on ne va pas l’invoquer. Dans nos classes Test, on pourra donc utiliser ça pour écrire des méthodes “internes” dont on pourrait avoir besoin.

InvocationTargetException arrive si une exception a lieu lors de l’exécution de la méthode. Par exemple, une AssertionError si un assert est false. On a donc notre moyen de détecter si le test a échoué.

Voyons où on en est:

public class TestRunner {
    private static String[] testClasses = {"Test.TestTest"};

    public static void main(String[] args){
        ClassLoader loader = ClassLoader.getSystemClassLoader();
        loader.setDefaultAssertionStatus(true);

        for (String c: testClasses){
            try {
                Class testClass = Class.forName(c);
                Method[] methods = testClass.getDeclaredMethods();
                for (Method m : methods) {
                    try {
                        m.invoke(null);
                    } catch (IllegalAccessException e) {
                        continue;
                    } catch (InvocationTargetException e) {
                        System.err.println("❌ Test " + m.getName() + " failed (" + e.getMessage() + ")");
                        continue;
                    }
                    System.out.println("✅ Test " + m.getName() + " passed");
                }
            } catch (ClassNotFoundException e) {
                System.err.println("Class not found: " + c);
                return;
            }
        }
    }
}

Testons:

✅ Test testSuccess passed
❌ Test testFailed failed (null)

Presque bon: le message “test has failed successfully!” n’apparaît pas. Pourquoi? InvocationTargetException ne contient pas ce message, c’est — me dit la documentation — un “wrapper” autour de l’exception dans la méthode invoquée. Je dois donc récupérer d’abord la-dite exception, qui sera normalement le AssertionError.

System.err.println("❌ Test " + m.getName() + " failed (" + e.getCause().getMessage() + ")");

✅ Test testSuccess passed
❌ Test testFailed failed (test has failed successfully!)

Cette fois, c’est bon!

Découverte automatique des classes

Java ne fournit pas de moyen simple de récupérer toutes les classes présentes dans un package, mais on peut s’en sortir grâce à notre ami le ClassLoader, celui-là même qui nous permet de voir les assert.

Un certain Victor Tatai a partagé en 2007 un bout de code permettant de faire tout ça. Créons une sous-classe privée Discovery pour encapsuler toute cette logique.

public class TestRunner {
    // ...

    private class Discovery {
        private static Class[] getClasses(ClassLoader classLoader, String packageName) {
            // ...
        }
    }

On pourra ainsi appeler Discovery.getClasses(loader, "Test") pour récupérer la liste des classes de test.

La première étape est de récupérer toutes les “ressources” du package:

// dans getClasses(...)
assert classLoader != null;
List<Class> classes = new ArrayList<>();
try {
    resources = classLoader.getResources(packageName);
} catch (IOException e) {
    return classes.toArray(new Class[0]);
}

On va recevoir une liste d’URLs qui aura un seul élément dans notre cas: le chemin vers le dossier du package. Si on n’arrive pas à charger les ressources, on renvoie une liste vide. On peut parcourir les URLs et récupérer le dossier correspondant dans un objet de type File.

// ...
while (resources.hasMoreElements()) {
    URL resource = resources.nextElement();
    File directory = new File(resource.getPath());
}

Ensuite: récupérer la liste des fichiers dans le répertoire.

// ...
File[] files = directory.listFiles();
assert files != null;
for (File file : files) {
    // ...
}

Les fichiers qu’on cherche seront les fichiers .class, qui contiennent le code Java compilé. Pour ceux-là, on doit récupérer leur nom (sans le .class), et on peut ensuite charger les classes correspondantes avec Class.forName(...), en n’oubliant pas de rajouter le nom du package devant:

for (File file : files) {
    if (file.getName().endsWith(".class")) {
        String className = packageName + "." + file.getName().substring(0, file.getName().length()-6);
        classes.add(Class.forName(className));
    }
}

C’est à peu près bon, mais il faut maintenant traiter le cas où on a une arborescence un peu plus compliquée avec des sous-dossiers dans notre répertoire de test. Dans ce cas-là, file peut être aussi un dossier, et il faut alors chercher les fichiers dans ce sous-dossier. Pour pouvoir réaliser ça, on va devoir faire un peu de récursion et extraire une méthode findClassesInDirectory de notre méthode getClasses. On arrive au final à tout ceci pour la classe Discovery:

class TestRunner {
    // ...
    private class Discovery {
        private static Class[] getClasses(ClassLoader classLoader, String packageName) {
            assert classLoader != null;
            List<Class> classes = new ArrayList<>();
            Enumeration<URL> resources;
            try {
                resources = classLoader.getResources(packageName);
            } catch (IOException e) {
                return classes.toArray(new Class[0]);
            }
            while (resources.hasMoreElements()) {
                URL resource = resources.nextElement();
                File directory = new File(resource.getPath());
                classes.addAll(findClassesInDirectory(directory, packageName));
            }
            return classes.toArray(new Class[0]);
        }

        private static List<Class> findClassesInDirectory(File directory, String packageName) {
            List<Class> classes = new ArrayList<Class>();
            if (!directory.exists()) {
                return classes;
            }
            File[] files = directory.listFiles();
            assert files != null;
            for (File file : files) {
                if (file.isDirectory() && !file.getName().contains(".")) {
                    classes.addAll(findClassesInDirectory(file, packageName + "." + file.getName()));
                } else if (file.getName().endsWith(".class")) {
                    String className = packageName + "." + file.getName().substring(0, file.getName().length()-6);
                    try {
                        classes.add(Class.forName(className));
                    } catch (ClassNotFoundException e) {
                        continue;
                    }
                }
            }
            return classes;
        }
    }
}

Utilisation de la découverte automatique

On peut maintenant retirer notre attribut testClasses et utiliser la découverte automatique pour récupérer toutes les classes de test. Voyons ce que ça donne:

public class TestRunner {
    public static void main(String[] args){
        ClassLoader loader = ClassLoader.getSystemClassLoader();
        loader.setDefaultAssertionStatus(true);

        Class[] classes = Discovery.getClasses(loader, "Test");
        for (Class c : classes) {
            System.out.println(c.getName());
        }
    }
    // ...
}

On reçoit:

Test.TestRunner$Discovery
Test.TestRunner
Test.TestTest

Évidemment, le TestRunner et la sous-classe Discovery sont là aussi. Il va falloir les filtrer, puis on peut continuer comme avant.

public class TestRunner {
    public static void main(String[] args){
        ClassLoader loader = ClassLoader.getSystemClassLoader();
        loader.setDefaultAssertionStatus(true);

        Class[] classes = Discovery.getClasses(loader, "Test");
        System.out.println("Found " + (classes.length-2) + " test classes.");
        for (Class c : classes) {
            if (c.getName().startsWith(TestRunner.class.getName()))
                continue;
            System.out.println("Searching for tests in " + c.getName());
            Method[] methods = c.getDeclaredMethods();
            // ...
        }
    }
    // ...
}

On relance:

Found 1 test classes.
Searching for tests in Test.TestTest
✅ Test testSuccess passed
❌ Test testFailed failed (test has failed successfully!)

Et c’est bon! J’ai maintenant un dossier Test que je peux “dropper” dans d’autres projet pour déployer des tests unitaires simples sans me casser la tête.

Code complet sur Codeberg: https://codeberg.org/adfoucart/JavaTestRunner/

[lien permanent]

🖋2026.01.26
correction assistée par ordinateur

Pourquoi passer dix heures à faire des corrections lorsqu’on peut passer cinq heures à faire un système qui automatise partiellement les corrections, et puis passer quand même dix heures à faire des corrections?

Bon, il y a effectivement quelques révisions à prévoir pour réutiliser “mon” système, mais même si le résultat n’a pas été tout à fait à la hauteur de mes attentes cette session, je pense que les concepts de base sont raisonnablement sains. Mais prenons les choses étape par étape.

1. Le besoin

Une partie de mes corrections était sur papier. Pas d’automatisation par là, juste une solide grille de correction permettant de ne pas trop agoniser sur chaque demi-point à donner.

Mais deux parties d’examen étaient susceptibles de recevoir un peu d’aide technologique: une question de maths en Excel, et un examen de machine learning avec des fonctions Python à compléter.

Ce que je voulais éviter, c’est de devoir:

1. Ouvrir (et refermer) 300 fichiers Excel pour aller regarder les formules écrites par les étudiant.es une à une.
   
2. Ouvrir, exécuter et refermer 200 fichiers Python, et possiblement les modifier pour tester des fonctions individuelles.

Il faut sans doute le préciser au vu de la situation actuelle, mais l’objectif n’est évidemment pas de balancer tout ça dans ChatGPT, Copilot ou autre et de lui “demander” de me coter tout ça pendant que je bois un café. Je veux me faciliter la vie et rester le plus correct possible dans mes cotes.

Non, ce que je veux, c’est pouvoir me faciliter la vie. Tester automatiquement ce qui est testable automatiquement, et me mettre en avant les informations utiles pour corriger chaque étudiant.e sans devoir aller manuellement ouvrir tous les fichiers soumis.

Idéalement, j’aimerais avoir quelque chose qui va me détecter facilement quand quelque chose est juste, pour que je puisse concentrer mon attention sur les cas où il y a des erreurs pour voir si ce sont des erreurs très problématiques ou non. Ou pas des erreurs du tout: tout système automatique aura ses faux positifs.

2. Le plan

Ce que j’avais en tête était, en principe, raisonnablement simple:

• Récupérer, pour chaque étudiant.e, le(s) fichier(s) remplis.
• Pour Excel:
  • Récupérer le contenu des cellules à modifier.
  • Comparer ce contenu avec les formules attendues.
  • Créer un fichier “rapport” par étudiant.e avec le contenu des cellules et une note indiquant si c’est juste ou pas.
• Pour Python:
  • Copier les fichiers dans un environnement d’évaluation avec des fichiers pytest permettant de tester les différentes fonctions implémentées.
  • Lancer pytest et récupérer le résultat.
  • Créer un fichier “rapport” par étudiant avec le résultat des tests et une copie du code.

Ensuite, dans les deux cas, créer aussi un fichier “index” avec la liste des étudiant.es et un lien vers leur rapport. Tout ça idéalement en HTML pour pouvoir facilement naviguer d’un rapport à l’autre.

Python reste mon langage de prédilection, c’est donc de que j’utiliserai pour essayer de faire tout ça.

3. Premier écueil: la récupération des fichiers

Il y a plusieurs configurations possibles pour faire passer des examens sur machine à la Haute-École. Dans celle utilisée pour le cours de mathématiques, les étudiant.es reçoivent des identifiants temporaire pour le temps de l’examen, et doivent mettre leurs fichiers à la fin sur un disque réseau. À la fin de l’examen, on peut récupérer le contenu de ces disques, identifiés par le login temporaire. Les feuilles de login sont distribuées avec les énoncés lors de l’examen, et il n’y a donc pas de correspondance connue a priori entre les comptes et les étudiant.es.

Par conséquent, les consignes indiquaient clairement que les étudiant.es devaient renommer le fichier Excel fourni (Probabilites.xlsx) avec le format NOM_PRENOM.xlsx. Ils devaient aussi dans le même examen faire un projet Java qu’ils devaient également appeler NOM_Prenom et mettre à la racine du disque réseau. Et on leur demandait également de mettre leur nom et prénom sur la feuille de login qu’on récupérait à la fin de l’examen.

On aurait pu simplement décider que le non respect des consignes amènerait un 0, et ne pas corriger si le fichier Excel n’était pas correctement renommer, mais on est gentils. On va donc essayer de faire un minimum d’effort pour trouver toutes les correspondances entre les étudiant.es et leur compte.

Pour commencer, je parcours tous les dossiers et, dans chaque, dossier, j’utilise la méthode glob de pathlib pour rechercher tous les fichiers .xlsx qui se trouvent dans le dossier ou ses sous-dossiers: xlsx_files = list(f.glob("**/*.xlsx")). S’il y en a un qui ne s’appelle pas Probabilites.xlsx, je récupère le nom du fichier et considère que c’est le nom de mon étudiant.e. C’est le cas de base, pour celleux qui ont respecté les consignes.

Sinon, je cherche s’il y a un dossier à la racine qui correspondrait au projet Java, et je note l’association. Et sinon, je note simplement le numéro de session, et espère qu’on retrouve une feuille de login avec un nom dessus. Sur un peu moins de 300 étudiant.es qui ont passé l’examen, je n’en ai qu’un seul au final qui a rempli quelque chose et qui n’a laissé aucun moyen de l’identifier.

La seconde configuration, utilisée pour l’examen en Python, rend les choses un peu plus faciles: les étudiant.es uploadent leur projet sur une plateforme Moodle, où iels sont connecté.es avec leur propre compte. J’ai donc alors un fichier ZIP par étudiant.e avec son nom dessus.

4. Tester Excel, c’est galère

Il y a plusieurs librairies qui permettent de s’attaquer à un fichier Excel en Python. Une des façons les plus simples est d’utiliser pandas et sa fonction read_excel. On peut y faire:

import pandas as pd

file_content = pd.read_excel("/path/to/excel/file.xlsx", header=None)

Pour récupérer le contenu du fichier dans une DataFrame. Problème: on récupère uniquement les valeurs des cellules. Mais je ne veux pas juste les valeurs: je veux récupérer les formules. En effet, dans l’exercice proposé, une bonne partie des valeurs à trouver leur sont déjà données dans le fichier, et iels devaient justement trouver la formule permettant de les retrouver!

Pandas utilise openpyxl en arrière-fond. Avec openpyxl, on peut ouvrir un fichier en récupérant soit les valeurs, soit les formules, et ensuite adresser directement les cellules:

from openpyxl import load_workbook

wb = load_workbook("/path/to/excel/file.xlsx", data_only=False)
sheet = wb["Sheet1"]
g4 = sheet["G4"].value # formule dans la cellule G4

wb_val = load_workbook("/path/to/excel/file.xlsx", data_only=True)
sheet_val = wb_val["Sheet1"]
g4_val = sheet_val["G4"].value # valeur dans la cellule G4

Et j’ai — malheureusement après avoir choisi de ne pas utiliser cette libraire — fini par trouver un moyen d’accéder aussi aux graphes présents sur la feuille, et à récupérer quelles données ont été utilisées pour réaliser ce graphe, et de quel type de graphe il s’agit. Le problème, c’est que c’est assez mal documenté, et qu’on doit accéder à des attributs “privés” (au sens pythonesque de “marqué par un _ comme ne faisant pas partie de l’API”) pour pouvoir jouer avec:

all_charts = sheet._charts

for chart in all_charts:
    print(chart.tagname) # donnera le type de graphe
    for ser in chart.ser: # parcourir les ranges
        print(ser.val.numRef.f) # formule du range
        print([pt.v for pt in ser.val.numRef.numCache.pt]) # valeurs utilisées dans le graphe

C’est un peu dégueu, et probablement pas très stable, mais ça peut marcher. Malheureusement, je n’ai pas trouvé ça tout de suite, et je suis tombé sur des recommandations pour xlwings, que j’ai finalement utilisé. xlwings permet de récupérer le contenu d’un fichier Excel avec ses formules et ses valeurs, ainsi que d’extraire les graphes et de les sauvegarder en fichiers images. Par contre, s’il y a un moyen de retrouver les données utilisées pour créer le graphe, je ne l’ai pas trouvé. Et xlwings est leeeeeent. Je pense que la prochaine fois, je reviendrai sur openpyxl. xlwings propose une API similaire:

import xlwings as xw

wb = xw.Book("/path/to/excel/file.xlsx")
sheet = wb.sheets['Sheet1']
g4 = sheet['G4'].formula
g4_val = sheet['G4'].value
# extraction des graphes
charts = sheet.charts
for chart in charts:
    chart.to_png("/path/to/chart.png")

Avec xlwings, j’ai donc pu faire à peu près ce que j’avais en tête:

• Récupérer les formules des cellules qui m’intéressent.
• Récupérer le graphe s’il y en a un, l’extraire et le sauvegarder en PNG.
• Comparer les formules à des “formules attendues”.
• Générer un rapport avec tout ça.

Le rapport obtenu ressemble à ça (anonymisé ici):

Le problème principal qui m’a tout de même fait rouvrir une bonne partie des fichiers Excels, c’est que le nombre de différentes manières équivalentes d’écrire les formules était juste trop grand. Entre les parenthèses, les différentes manières possibles d’arriver au résultat, ou le choix (tout à fait raisonnable!) fait par certain.es d’utiliser des cellules “intermédiaires” pour découper les formules en éléments plus simples… on ne s’en sort pas trop, et énormément d’étudiant.es avaient une réponse correcte à laquelle je n’avais pas pensé.

Notes pour le futur

• Utiliser openpyxl directement.
• Mettre dans le rapport les formules et les valeurs des cellules attendus, mais aussi de tout autre cellule non-nulle modifiée par l’étudiant.e.
• Tester d’abord sur les valeurs en excluant certaines formules “non-autorisées” pour y arriver, plutôt que de tester sur les formules. Par exemple ici, certain.es ont tenté le coup de “recopier” les valeurs qui étaient déjà données (avec par exemple =C4 pour récupérer dans la cellule où ils devaient mettre la formule la valeur déjà fournie correspondante): la valeur serait correcte, mais la formule pas.
• Récupérer les ranges et valeurs du graphe et les mettre dans le rapport, quitte à recréer le graphe en matplotlib sur base de ces valeurs plutôt que d’essayer de l’extraire depuis Excel si je veux l’avoir quand même affiché.

5. Tester Python, c’est plus facile?

J’avais mis toutes les chances de mon côté avec l’énoncé de mon examen de Machine Learning en Python: les étudiant.es avaient des fonctions à compléter dont iels n’étaient pas supposé.es changer le nom ou la signature, et avec des spécifications très claires sur les entrées et sorties attendues. Le scénario idéal pour pouvoir déployer des tests unitaires. J’avais donc préparé une batterie de tests avec pytest. Mon plan était donc: pour chaque étudiant.e, récupérer les deux fichiers de code qu’ils devaient modifier, les mettre dans un environnement de test avec mes fichiers pytest prêts à l’emploi, lancer les tests, récupérer les résultats, et mettre ces résultats avec le code dans un fichier “rapport” par étudiant.e.

La correction devait ainsi être raisonnablement rapide: si les tests d’une fonction sont passés, c’est juste; sinon, on jette un coup d’oeil au code pour voir si l’étudiant.e a quand même compris quelque chose.

Premier écueil: les étudiant.es ont été un peu trop enthousiastes sur l’auto-complétion, et ont souvent inclus des libraires imprévues dans leurs imports. Je ne spécifiais nulle part dans l’énoncé qu’il fallait limiter les import aux librairies nécessaires, donc je n’ai pas voulu pénaliser ça… mais je n’avais pas moi-même installé ces librairies dans mon environnement de test, donc les tests unitaires foiraient complètement. Heureusement, ces imports excessifs n’étaient pas utilisés ensuite dans le code, et pouvaient donc être automatiquement enlevés avec autoflake. J’ai fait les évaluations depuis mon PC-de-la-maison qui a encore Windows dessus, donc j’ai fait un bon vieux script .bat pour parcourir les dossiers, lancer autoflake, lancer les tests et mettre les résultats dans un fichier:

REM Run autoflake and pytest in all directories
for /f %%i in ('dir /b/ad') do (
    echo Autoflake in "%%i"
    autoflake --in-place --remove-all-unused-imports "%%i/src/conseiller_fraude.py"
    autoflake --in-place --remove-all-unused-imports "%%i/src/detection_fraude.py"
    echo pytest in "%%i"
    pytest "%%i/tests/test_conseiller_fraude.py" --no-header -tb=no >> "%%i.txt"
    pytest "%%i/tests/test_detection_fraude.py" --no-header -tb=no >> "%%i.txt"
)

Le pytest aurait pu être fait en une fois, mais le faire séparément sur les deux fichiers permet de tout de même avoir les résultats si un des deux fichiers plante complètement, par exemple pour cause d’import foireux.

Les rapport obtenus ressemblent à ceci:

Le problème principal que j’ai eu avec ces tests n’était ici pas technique, mais conceptuel: les tests unitaires que j’avais prévu ne capturaient pas bien les critères sur lesquels je voulais les évaluer. Du coup, à part si tous les tests d’une méthode passaient (ce qui n’arrivait malheureusement pas très souvent à part pour les méthodes les plus simples), je devais tout de même souvent repasser sur le code ligne par ligne avec ma grille de critères pour voir ce qui passait ou non. C’était un peu bête de ma part: j’ai écrit les tests unitaires comme si je développais le programme, au lieu de les écrire avec la grille d’évaluation en tête. Probablement parce que je n’avais pas encore écrit la grille d’évaluation, ce qui n’aide pas.

[lien permanent]

🌍2025.11.22
idiomatique

Mon langage de prédilection en programmation est depuis longtemps maintenant le Python. Dans le cursus dans lequel j’enseigne, cependant, les langages principalement utilisés sont le Java et le Typescript. J’ai fait pas mal de Java. Le Typescript est une “surcouche” du Javascript, et j’ai déjà fait du Javascript. Donc “ça devrait aller”, en tout cas pour m’en sortir dans la syntaxe. Et, évidemment, les concepts de programmation en général sont transférables d’un langage à l’autre.

Mais ce qui va me manquer, et sur lequel je vais devoir un peu travailler, c’est ce qui fait souvent dire à des gens qui ne maîtrisent pas un langage particulier que ce langage est nul: la connaissance des idiomes du langage.

J’entends souvent des gens qui se plaignent du Python, et à chaque fois quand je vois ce qui les bloque, c’est qu’ils n’ont “pas compris” comment utiliser Python efficacement. Je râle de mon côté sur le Java ou le Javascript chaque fois que je me retrouve à en faire, et c’est sans doute pour la même raison.

Les idiomes ne sont pas seulement liés à la syntaxe ou aux règles formelles du langage, mais bien au “bon usage”, les réflexes à avoir qui font que les choses fonctionnent sans friction.

L’exemple typique, en Python, est celui des listes en compréhension. Si on cherche à appliquer une certaine fonction sur tous les éléments d’une liste et à stocker les résultats dans une nouvelle liste, on pourrait faire:

nouvelle_liste = []
for i in range(len(ma_liste)):
    element = ma_liste[i]
    resultat = ma_fonction(element)
    nouvelle_liste.append(resultat)

Ce serait tout à fait “correct” au niveau de la syntaxe du langage, mais ce n’est pas idiomatique. La liste en compréhension offre, en Python, une manière plus lisible (pour celleux qui sont ont l’accent local!) d’exprimer la même opération:

nouvelle_liste = [ma_fonction(element) for element in ma_liste]

Et comme dans les langages parlés par les humains, plusieurs idiomes peuvent coexister. Dans certaines régions du pays Python, on utiliserait plutôt:

nouvelle_liste = list(map(ma_fonction, ma_liste))

Avec toujours le même résultat.

Comprendre non seulement la syntaxe et les règles, mais aussi les idiomes du Typescript, c’est ce que je vais chercher à faire dans les prochains mois. Je documenterai cette aventure en terre moins connue ici: Typescript: une aventure.

[lien permanent]

🪙2025.11.04
simulation probabilités

[Lien vers le simulateur]

Dans le cours de mathématiques, on utilise le Paradoxe de Saint-Peterbourg comme exemple de calcul de fonction de masse et d’espérance d’une variable aléatoire.

Le paradoxe tourne autour d’un jeu qui se déroule ainsi:

• le joueur mise une certaine somme.
• il fait ensuite une série de jets de pile ou face.
• le jeu s’arrête au premier “pile”.
• le joueur gagne alors 2ⁿ euros, où n est le nombre de “faces” obtenues avant d’avoir un “pile”.

Donc si, par exemple, j’ai la série: Face-Face-Pile, le jeu s’arrête après trois lancers et je reçois 2² = 4 euros.

Le paradoxe réside dans le fait que, théoriquement, l’espérance des gains obtenus est infinie. Pourtant, peu de joueurs seraient prêts à miser une grosse somme, vu que les chances de gagner plus qu’une poignée d’euros sont extrêmement faibles.

Notre cours de mathématique ne s’intéresse pas trop au cas infini. On ajoute donc une règle supplémentaire: si au bout de 10 lancers on n’a obtenu que des faces, le joueur gagne 2¹⁰ = 1024 euros et la partie s’arrête aussi. Les gains ne sont plus infinis, mais le “paradoxe” reste présent. L’espérance du gain dans cette configuration est de 6 euros, mais les chances pour un joueur de gagner de l’argent en misant 6 euros sont faibles (12.5%, pour être précis).

On peut calculer toutes ces valeurs, mais dès qu’on fait des probabilités, j’aime bien simuler les choses, pour obtenir une bonne intuition de ce qui se passe. En plus, comme on enseigne à des futurs développeurs, approcher une solution via une simulation est une compétence qui semble intéressante à mettre en avant.

Le simulateur permet de voir comment l’espérance change avec le nombre maximal de lancers autorisé, et comment la précision de notre estimation de l’espérance s’améliore avec le nombre de parties simulées.

Pour que tout ça soit accessible sur une page web, on va faire un peu de Javascript. Commençons donc par la simulation d’une partie:

function jeuSaintPetersbourg(max_n) {
    let n = 1;
    while (Math.random() < 0.5) {
        if (n === max_n) return 2**n;
        n++;
    }
    return 2**(n-1);
}

On utilise pour “pile ou face” un test Math.random() < 0.5, et on considère ici que true représente face, et false représente pile. La fonction renvoie le gain: si on atteint le maximum de lancers, on renvoie 2ⁿ, sinon on s’arrête dès qu’on tombe sur pile et on renvoie 2^n − 1.

Pour estimer une statistique via une simulation, il faut pouvoir relancer l’expérience beaucoup de fois. On va donc faire ça, en collectant la distribution des résultats:

function lancerSimulation(){
    // ... récupération d'inputs
    const resultats = {};
    for (let i = 0; i <= maxLancers; i++ ){
       resultats[2**i] = 0
    }

    let total = 0;
    for (let i = 0; i < numJeux; i++) {
        const gains = jeuSaintPetersbourg(maxLancers);
        resultats[gains]++;
        total += gains;
    }

    const moyenne = (total / numJeux).toFixed(2);
    // ... affichage des résultats
}

maxLancers et numJeux sont récupérés dans des <input>. On initialise le tableau des résultats avec tous les gains possibles, puis on lance numJeux parties, et on collecte les gains obtenus. On calcule notre estimation de l’espérance en faisant la moyenne des gains. L’affichage se fait via un diagramme en barres fait dans un <canvas>.

Il est clair que miser beaucoup sur une partie n’est pas très avantageux. Mais si on peut miser un peu sur beaucoup de parties, par contre, la dynamique change. C’est la deuxième partie de la simulation: que ce passe-t-il si on peut rejouer?

On va maintenant calculer le total des gains si on joue une série de parties, chacune avec une mise fixe:

function totalSerie(numJeux, prix) {
    let total = 0;
    for(let i = 0; i < numJeux; i++){
        res = jeuSaintPetersbourg(10);
        total += res - prix;
    }
    return total;
}

Et on va cette fois-ci dans notre simulation regarder une variable aléatoire binaire: est-ce qu’on gagne de l’argent à la fin? (bon, en vrai je l’ai faite ternaire parce que j’ai séparé le cas où on récupérait exactement notre mise).

function lancerSerieJeux(){
    // ... récupération d'inputs
    let partiesGagnees = 0;
    let partiesPerdues = 0;
    let partiesEgales = 0;
    for( let i = 0; i < numSimulations; i++ ){
        gains = totalSerie(numJeux, prix);
        if(gains > 0){
            partiesGagnees += 1;
        }
        else if( gains < 0){
            partiesPerdues += 1;
        }
        else{
            partiesEgales += 1;
        }
    }
    // ... affichage des résultats
}

En jouant avec le simulateur, on peut ainsi facilement voir que si on mise une fois 1000 euros, on va vraisemblablement les perdre (0.1% de victoires). Si par contre je joue 200 parties à 5 euros, j’ai plus d’une chance sur deux de sortir vainqueur de l’échange. Enfin, sauf si on compte le temps perdu à jeter la pièce.

[lien permanent]

🗄️2025.10.17
tests postgres

Est-ce que ma requête est correcte?

Je ne suis pas un grand spécialiste des bases de données PostgreSQL. Des trois cours que je donne ce quadrimestre, c’est certainement celui dans lequel je suis le moins à l’aise. Je sais comprendre et expliquer tous les concepts théoriques, mais pouvoir rapidement vérifier si une requête fonctionnne exactement comme prévu, si elle répond exactement aux critères de l’énoncé, ce n’est pas toujours évident.

Je me suis demandé: est-ce qu’il y a moyen de faire l’équivalent en SQL des “tests unitaires” qu’on peut retrouver dans les différents languages de programmation auxquels je suis plus habitués? Cela me permettrait de mettre en place des procédures relativement simples pour vérifier qu’une solution (la mienne ou celle d’un.e étudiant.e) est correcte… ou de pointer dans la direction de l’erreur dans le cas contraire.

Je suis tombé sur un article prometteur: “Unit Testing and TDD With PostgreSQL is Easy”, par un certain Vedran Bilopavlović. Nous n’avons pas nécessairement la même notion de easy, mais je dois reconnaître que la solution est, en tout cas, raisonnable. L’idée est d’utiliser une procédure SQL qui va:

• Insérer des données de test.
• Exécuter la requête à tester.
• Utiliser des ASSERT pour vérifier si le résultat est celui attendu.

La bonne nouvelle, c’est que ça marche assez bien. La mauvaise, c’est que c’est clairement quand même un peu lourd à écrire. Mais c’est sans doute une question d’habitude plus qu’autre chose. En tout cas je suis prêt à tenter un peu. Prenons un exemple avec quelque chose qui piège pas mal d’étudiant.e.s débutant.e.s: la différence entre un LEFT JOIN et un INNER JOIN.

Imaginons un schéma avec trois tables: pizza, garniture et garniture_pizza. Une pizza aura un identifiant, un nom et un prix. Une garniture aura un identifiant et un nom. Et on fera le lien entre les deux pour pouvoir associer des pizzas à leurs garniture(s):

BEGIN;
CREATE TABLE IF NOT EXISTS pizza (
    id_pizza int,
    nom varchar(50) UNIQUE,
    prix float not null,
    PRIMARY KEY (id_pizza)
);
CREATE TABLE IF NOT EXISTS garniture (
    id_garniture int PRIMARY KEY,
    nom varchar(50) UNIQUE
);
CREATE TABLE IF NOT EXISTS garniture_pizza(
    id_pizza int,
    id_garniture int,
    PRIMARY KEY(id_pizza, id_garniture)
);
COMMIT;

Pour respecter les principes du “test driven development”, on va commencer par écrire les tests avant d’écrire la requête. Imaginons qu’on cherche à récupérer le nombre de pizzas dans laquelle chaque garniture est utilisée. Quels sont les différents cas à tester?

• Une garniture g est utilisée sur n>=1 pizzas -> on doit voir aparraître le tuple (g, n) dans la réponse.
• Une garniture g n’est utilisée sur aucune pizza -> on doit voir apparaître le tuple (g, 0) dans la réponse.
• Une pizza p n’a aucun ingrédient -> elle ne doit pas affecter le résultat de la requête.

J’ai donc besoin d’insérer dans mes données, au minimum:

• Trois pizzas (1, 2, 3)
• Deux garnitures (1, 2)
• Liens (pizza, garniture): ((1, 1), (2, 1))

On pourrait ne mettre que deux pizzas, mais le nombre de pizzas serait alors égal au nombre de garniture, ce qui peut rendre des tests sur le “nombre de résultats obtenus” moins évidents.

Mettons ça dans une procédure, en commençant par supprimer toutes les données (pour s’assurer qu’on n’a bien uniquement nos données de test), et en terminant par un rollback (pour remettre la base de données dans son état initial). Il va de soi que je ne mettrais pas cette procédure dans une base de données en production, on va éviter de supprimer toutes les données par erreur!

CREATE OR REPLACE PROCEDURE test_nb_pizzas_par_garniture() AS $$
    BEGIN
        -- supprimer toutes les données
        TRUNCATE pizza, garniture, garniture_pizza;

        -- données minimales pour le test
        INSERT INTO pizza VALUES (1, 'pizza 1', 0),
                                 (2, 'pizza 2', 0),
                                 (3, 'pizza 3', 0);
        INSERT INTO garniture VALUES (1, 'garniture 1'),
                                     (2, 'garniture_2');
        INSERT INTO garniture_pizza VALUES (1, 1),
                                           (2, 1);

        ROLLBACK;
    END;
$$ LANGUAGE plpgsql;

call test_nb_pizzas_par_garniture();

Si on exécute ceci dans une base PostgreSQL, on va: - supprimer les données existantes. - ajouter les données de test. - annuler tout et remettre la base dans son état pré-exécution.

On doit maintenant ajouter la requête et les tests. Pour commencer, on imagine que notre requête se trouve dans une fonction nb_pizzas_par_garniture, qu’on définira plus tard. On peut alors récupérer les résultats de cette requête dans notre procédure de test avec:

CREATE TEMP TABLE result ON COMMIT DROP AS
SELECT * FROM nb_pizzas_par_garniture();

On stocke ainsi le résultat dans une table temporaire, qui sera éliminée à la fin de la transaction. On peut maintenant passer aux tests. La syntaxe des ASSERT est: ASSERT [expr][, msg], où si l’expression est fausse on affiche une erreur et, optionnellement, le message. On doit tester:

• Que l’on trouve 2 garnitures
• Que la garniture 1 apparaît sur 2 pizzas
• Que la garniture 2 apparaît sur 0 pizzas

Traduisons cela en SQL:

-- 2 garnitures trouvées
ASSERT (SELECT COUNT(*) FROM result) = 2,
    '2 garnitures attendues, reçu ' || (SELECT COUNT(*) FROM result)::text;
-- garniture 1 -> 2 pizzas
ASSERT (SELECT nb_pizzas FROM result WHERE id_garniture = 1) = 2,
    '2 pizzas attendues pour la garniture 1, reçu ' || (SELECT nb_pizzas FROM result WHERE id_garniture = 1)::text;
-- garniture 2 -> 0 pizzas
ASSERT (SELECT nb_pizzas FROM result WHERE id_garniture = 2) = 0,
    '0 pizzas attendues pour la garniture 2, reçu ' || (SELECT nb_pizzas FROM result WHERE id_garniture = 2)::text;

La syntaxe n’est pas la plus lisible, mais ça passe. || permet de concaténer des chaînes de caractères, et ::text de caster les entiers de nb_pizzas en chaînes de caractères. Commençons par écrire une requête bidon pour vérifier que notre test fonctionne (sans oublier de la mettre dans une fonction):

CREATE OR REPLACE FUNCTION nb_pizzas_par_garniture()
RETURNS TABLE (
    id_garniture int,
    nb_pizzas int
) language sql as $$
-- LA REQUÊTE EST ICI:
SELECT 0, 0;
-- FIN DE LA REQUÊTE
$$;

On peut maintenant maintenant appeler la procédure de test: call test_nb_pizzas_par_garniture();, qui va bien planter dès le premier test en renvoyant le message: ERROR: 2 garnitures attendues, reçu 1.

Imaginons maintenant un.e étudiant.e qui utilise un INNER JOIN pour répondre à la question:

-- Mauvais JOIN
SELECT g.id_garniture, COUNT(gp.id_pizza)
FROM garniture g
INNER JOIN garniture_pizza gp ON gp.id_garniture = g.id_garniture
GROUP BY g.id_garniture

Il aura bien une erreur: ERROR: 2 garnitures attendues, reçu 1, car le INNER JOIN aura éliminé la garniture 2. S’iel fait un LEFT JOIN en laissant le reste identique, tous le tests passeront. S’il se trompe dans le COUNT et écrit:

-- Mauvais COUNT
SELECT g.id_garniture, COUNT(g.id_garniture)
FROM garniture g
LEFT JOIN garniture_pizza gp ON gp.id_garniture = g.id_garniture
GROUP BY g.id_garniture

Iel aura: ERROR: 0 pizzas attendues pour la garniture 2, reçu 1.

Le code complet avec la requête correcte:

CREATE OR REPLACE FUNCTION nb_pizzas_par_garniture()
RETURNS TABLE (
    id_garniture int,
    nb_pizzas int
) language sql as $$
-- LA REQUÊTE EST ICI:
SELECT g.id_garniture, COUNT(gp.id_garniture)
FROM garniture g
LEFT JOIN garniture_pizza gp ON gp.id_garniture = g.id_garniture
GROUP BY g.id_garniture
-- FIN DE LA REQUÊTE
$$;

CREATE OR REPLACE PROCEDURE test_nb_pizzas_par_garniture() AS $$
    BEGIN
        -- supprimer toutes les données
        TRUNCATE pizza, garniture, garniture_pizza;

        -- données minimales pour le test
        INSERT INTO pizza VALUES (1, 'pizza 1', 0),
                                 (2, 'pizza 2', 0),
                                 (3, 'pizza 3', 0);
        INSERT INTO garniture VALUES (1, 'garniture 1'),
                                     (2, 'garniture_2');
        INSERT INTO garniture_pizza VALUES (1, 1),
                                           (2, 1);

        CREATE TEMP TABLE result ON COMMIT DROP AS
        SELECT * FROM nb_pizzas_par_garniture();

        -- 2 garnitures trouvées
        ASSERT (SELECT COUNT(*) FROM result) = 2,
            '2 garnitures attendues, reçu ' || (SELECT COUNT(*) FROM result)::text;
        -- garniture 1 -> 2 pizzas
        ASSERT (SELECT nb_pizzas FROM result WHERE id_garniture = 1) = 2,
            '2 pizzas attendues pour la garniture 1, reçu ' || (SELECT nb_pizzas FROM result WHERE id_garniture = 1)::text;
        -- garniture 2 -> 0 pizzas
        ASSERT (SELECT nb_pizzas FROM result WHERE id_garniture = 2) = 0,
            '0 pizzas attendues pour la garniture 2, reçu ' || (SELECT nb_pizzas FROM result WHERE id_garniture = 2)::text;


        ROLLBACK;
    END;
$$ LANGUAGE plpgsql;

call test_nb_pizzas_par_garniture();

Est-ce que c’est beaucoup de boulot juste pour tester une requête? Oui, mais je peux voir des cas où cela vaudrait la peine. Par exemple dans un examen ou une interro, pouvoir valider rapidement que les résultats attendus ont été obtenus peut éviter des erreurs de correction.

Évidemment, ces tests ne détecteront pas les codes sous-optimaux. Par exemple, je pourrais ici ajouter une jointure inutile à pizza et compter sur p.id_pizza, et les tests passeront.

Mais je trouve que l’idée reste intéressante.

[lien permanent]

➕2025.10.07
les maths, c’est chouette?

Donner les exercices de mathématiques n’était pas vraiment la tâche qui m’emballait le plus dans mes assignations du quadrimestre. Nos étudiant.e.s n’ont pas un profil “maths fortes” à la base, et ne viennent certainement pas dans une école d’informatique dans le but de faire des maths. Tout l’enjeux, c’est donc de leur faire comprendre pourquoi, au juste, on fait faire des maths à des futurs informaticien.ne.s.

Parce que les maths qu’on leur fait voir sont, heureusement, adaptées à leurs besoins. On ne fait pas d’analyse complexe: on fait de la logique, de la théorie des ensembles, des suites. Des concepts qui ont un lien direct et raisonnablement facile à tracer avec les programmes qu’ils vont devoir développer.

Et cet exercice-là, trouver les liens, voir les étudiants passer d’un désintérêt fataliste à, si pas de l’intérêt, au moins une certaine prise de conscience que ce qu’on est en train de voir, ce n’est pas juste pour les embêter… je trouve ça chouette.

[lien permanent]

⏱️2025.10.03
le temps file

Je m’attendais à ce que le rythme soit soutenu, mais s’y attendre et le vivre, ce sont deux choses bien différentes. Quand on regarde l’horaire, on se dit “ça va”. Après tout, il y a “seulement” vingt heures par semaine face aux étudiant.e.s dans un temps plein. Certain.e.s expert.e.s semblent juger que, pour les enseignant.e.s du secondaire en tout cas, c’est trop peu [rtbf.be]. Je ne vois personnellement pas comment on pourrait faire plus en gardant un minimum de qualité.

Cette semaine est passée en un clin d’oeil. Pourtant, j’ai un rôle facile. Je suis arrivé tard, tous les cours ou presque sont déjà préparés. Je n’ai qu’à être présent pour les étudiant.e.s, répondre à leurs questions, faire l’une ou l’autre correction au tableau. La matière n’est pas particulièrement compliquée. Mais c’est toujours la course. Donner cours, relire les notes, boire un café, donner cours, écrire des notes, manger, donner cours, rentrer à la maison.

Je n’ai pas à me plaindre. Mais un prof qui ne se plaint pas un peu, est-ce que c’est vraiment un prof?

[lien permanent]

👨‍🏫2025.09.28
rentrée tardive

Il y a déjà beaucoup de dates de rentrée des classes en Belgique. Pour ma fille, c’était le 25 août. Pour ses ami·e·s en école néerlandophone, c’était le 1er septembre. Pour la plupart des étudiant·e·s et enseignant·e·s du supérieur, c’était le 15 septembre. Cette année, je suis un petit peu en retard: pour moi, ce sera le 29 septembre. La transition avec mon ancien travail aurait été un peu trop abrupte, mon engagement était un peu trop tardif, je ne voulais pas laisser un trop grand chantier derrière moi.

Du coup, j’ai des choses à rattraper.

Mes collègues connaissent déjà, un peu, la cohorte de jeunes qui s’amasse dans nos classes et nos auditoires. Ils sont déjà rentrés dans leur routine. Pour ce premier quadrimestre de ma nouvelle vie d’enseignant, je viens m’intercaler comme je peux dans des cours et des exercices préparés par d’autres. J’espère ne pas tomber comme un cheveu dans la soupe, mais plutôt comme du parmesan sur un plat de spaghettis: on aurait pu faire sans, mais ma présence est appréciée!

[lien permanent]

🔎2025.09.24
merci Google

En développant riem [riem-project on gitlab.ulb.be], le projet que je suis en train de terminer (enfin, clôturer plutôt) dans mes derniers jours de chercheur à l’ULB, j’utilise le “viewer” Napari [napari.org] pour visualiser et annoter des images médicales. Napari est une excellente libraire Python, mais sa documentation est parfois un peu bancale. Je dois donc souvent faire appel à Google pour essayer de trouver comment certaines fonctionnalités fonctionnent.

Je cherchais en particulier comment pouvoir intercepter l’événement déclenché lorsqu’on ajoute un point dans l’interface. Je vous passe les détails du pourquoi. J’ai donc ouvert Google, et j’ai lancé la requête napari event when point added to layer.

Google ne donne plus des “résultats de recherche” comme première option, c’est dépassé. Au lieu de ça, j’ai évidemment eu droit à la fameuse “AI Overview”. En général, j’ignore l’AI Overview autant que possible. Mais étant un peu pressé, j’ai tout de même voulu tester cette fois-ci la solution qu’il me proposait. Le code fourni n’était pas utilisable tel quel, mais j’avais les lignes qui m’intéressaient:

Pour pouvoir intercepter l’événement:

points_layer.events.data.connect(on_point_added)

Et pour le traiter:

def on_point_added(event):
    if event.type == 'add':
        print("Point added!")

J’ai ajouté cela à mon programme et, sans grande surprise, je reçus en retour une erreur: type n’est pas un attribut de event. Zut. Mais où Google a-t-il cherché ce event.type? Heureusement, l’AI Overview fourni des sources. Dans ce cas-ci, la principale était une discussions sur Github [issue#2809 on github.com/napari], datant de 2021, et proposant de modifier le comportement du data event de Napari pour y ajouter un type, qui pourrait être “set”, “move”, “add” ou “remove”.

Le problème, évidemment, c’est qu’entre le moment où cette proposition a été faite et le moment où la fonctionnalité a été rajoutée dans Napari, deux ans se sont écoulés, et l’idée a fait son chemin et s’est transformée [pull#5967 on github.com/napari]. Dans la description du “pull request”, on voit que finalement l’événement n’a pas de type mais est associé à une action, qui peut être add, remove ou change. Le bon code serait donc:

def on_point_added(event):
    if event.action == 'add':
        print("Point added!")

Sauf que ça ne marche toujours pas. Heureusement, une fois qu’on sait quels fichiers sont impliqués dans cette fonctionnalité [pull#5967 files on github.com/napari], on peut aller voir à quoi ils ressemblent aujourd’hui. Et on peut ainsi retrouver que les actions ont été modifiées peu de temps après leur ajout [commit#bc3c1e3a on github.com/napari]: dorénavant, on trouve adding, removing, changing, added, removed et changed.

On peut donc faire:

def on_point_added(event):
    if event.action == 'adding':
        print("Appelé avant ajout du point")
    elif event.action == 'added':
        print("Appelé après ajout du point")

Ce qui fonctionne enfin.

L’AI Overview, une nouvelle fois, n’aura servit qu’à ralentir le processus, et à entraver l’apprentissage: quand bien même la réponse fournie aurait fonctionné, le fait de lire, même en diagonale, les pull requests et les codes des commits est extrêmement informatif sur le fonctionnement de la librairie. Si Google pouvait faire ce qu’il faisait tellement bien avant, c’est-à-dire me diriger tout de suite vers les bonnes sources d’information, il serait tellement plus utile !

Mais nous vivons à l’ère du tout-à-l’IA, et on ne peut pas se permettre de bêtement donner des informations correctes ou utiles… Par curiosité, j’ai regardé ce que Copilot et ChatGPT me proposaient, et aucun des deux n’avaient de bonne solution non plus.

[lien permanent]

💬2025.09.22
des blogs

J’aime bien faire des blogs. Sans doute un truc d’enfant des années Skyblog (même si je ne pense pas que j’en avais un, mais ma mémoire me fait peut-être défaut). C’est important pour moi d’écrire sur ce que je fais et sur ce que je pense. Sur mon blog d’opinions souvent plus politiques [2xRien], il m’est bien souvent arrivé de démarrer un article avec une opinion que je voulais partager, puis de me rendre compte en l’écrivant, et en cherchant des sources pour vérifier mes a priori, que c’était une opinion que je n’étais en réalité pas capable de défendre. Ou qu’elle était banale et sans intérêt. Même ces articles jamais publiés m’aident à façonner et tester mes idées.

Mon blog de recherche [Research blog] était une extension naturelle: je voulais dissocier mes opinions personnelles de mes opinions professionnelles, dans lesquelles j’engageais mon expertise (et ma légitimité) de chercheur. Et puis, quand je communiquais sur ma recherche, je préférais le faire en Anglais.

Mais à partir du 29 septembre, je ne serai plus chercheur. Il va donc être temps de clôturer le blog de recherche, ou en tout cas de le mettre de côté (je resterai en contact avec la recherche, mais sur mon temps personnel). Je commence une nouvelle carrière d’enseignant en informatique. L’occasion de repartir à zéro sur un nouveau blog, que voici sous nos yeux ébahis. J’y parlerai d’enseignement, d’informatique, de technologies, d’intelligence artificielle, de programmation, de Python, de Java, de tout ce qui peut piquer mon intérêt et que j’ai envie de partager avec ma casquette “enseignant” et qui ne rentre pas dans la “ligne éditoriale” de “2xRien”. Le choix de publier dans l’un ou l’autre sera arbitraire et jamais justifié. On va dire que c’est du “vibe blogging”, sauf que ce sera vraiment moi qui écrirai.

Car si je ne garantis rien sur les contenus (ni sur les thèmes, ni sur la qualité!), je garantis que tout ce qui est écris ici (ou sur tout autre de mes blogs) l’est entièrement par moi. Écrire m’aide à penser: si l’IA écrit pour moi, elle pensera aussi pour moi, et vu l’alignement politique de ceux qui construisent ces IAs [whitehouse.gov], je n’ai pas trop envie qu’elles aient trop d’influence sur mes pensées.

[lien permanent]