diff --git a/ZolaApp/content/blog/c-programming-experience-assistant.md b/ZolaApp/content/blog/c-programming-experience-assistant.md
new file mode 100644
index 0000000000000000000000000000000000000000..6d9616734da43d9889269bce1854ed2b078acf26
--- /dev/null
+++ b/ZolaApp/content/blog/c-programming-experience-assistant.md
@@ -0,0 +1,68 @@
++++
+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.
+
+