title = "Teaching with the Dojo in the Programming class: an assistant's point of view"
description = "This blog post will give a review on the different observations made while using the Dojo to teach in the C programming class."
date = 2024-06-20T12:00:00+00:00
updated = 2024-06-20T12:00:00+00:00
draft = true
template = "blog/page.html"
[taxonomies]
authors = ["Orestis Malaspinas"]
[extra]
lead = "This blog post will give a review on the different observations made while using the Dojo to teach in the C programming class."
+++
## Foreword
In this post we will talk about the experience of a teaching assistant who used the Dojo to write a programming assignment in the C programming class in HEPIA. The class
is given during the first year in the computer science program.
Parti d'un template d'assignment existant.
There are no pre-requisites to follow this class. In particular students have no top limited C knowledge, to `make`,
to `git`, and to the Linux command line. Most of them were not familiar with Linux prior to this class where they were
made to install a dual boot with Linux on their laptop machines.
## Uses case
The assignment was created for a specific exercise about quadtrees. It consisted of writing the assignment, as well as unit tests,
and a solution.
The assignment was based on an existing assignment given in the previous years at HEPIA.
Writing the assignment is relatively straightforward because of the structure following unit tests.
After writing generalities about quadtrees and image processing, it was easy to follow the structure of the unit tests.
Plutîôt simple d'écrire le texte.
On part du corrigé et on implémente les tests pour les fonctions implémentées.
On peut les utiliser pour vérifier les sorties attendues.
Pratique parcce qu'on fait des tests avec une complexité croissante où on ajoue des détails d'implémentation dans les fonctions au fur et à mesure dans le corrigé.
La partie compliquée est de décider quelle est la frontière entre la liberté d'implémenter comme ils veulent
et cadrer la façon dont on veut faire. Pour l'arbre quaternaire on a une fonction qui libpère tout l'arbre mais on peut ajouter des fonctions "privées / statiques" pour des détails supplémentaires.
Écriture des tests:
* Tests straighforward: facile.
* Cas plus compliqués:
* Tester la nullité des pointeurs (mélange C - C++). Ping pong entre changer le test et changer l'énoncé.
* Quand on a des tests plus compliqués (pour des fonctions plus compliquées). Difficile de faire du
débugger les problèmes dans les fonctions parce qu'on est capturé dans l'environnement Dojo entre
le googletest et le'nvironnement docker.
* Quand on teste à l'intérieur d'une boucle on aimerait quitter plus tôt (avec un pauvre test) la fonction et pas avoir 100000 messages d'erreurs qui polluent la sortie.
* Note: on peut arrêter les tests à la première erreur dans gtest, mais il sort pas de rapport du coup.
Porblématique des tests unitaires:
* Tests interdépendants donc c'est compliqué de donner un ordre cohérent pour tous les tests. Il peut être compliqué pour les étudiants de faire un ordre raisonnable. Exemple: alloc/free.
Gestion du corrigé:
* Problème dans la doc pour la gestion du corrigé. On doit expliciter qu'il faut
1. Créer un exercice.
2. Résoudre l'exercice (la pipeline passe).
3. Publier l'exercice.
Reout d'étudiants:
* Beaucoup de mal à comprendre les erreurs des tests unitaires et des sanitizers.
* Refaire les rapports de tests serait une bonne idée.
