Emmanuel Guefif

Teacher Coop lets teachers upload teaching resources and find them again through a search engine. Documents are tagged with objectives from the French curriculum, so teachers can search by what they want to teach.

The app is built with Elixir, Phoenix and LiveView. It uses Postgres for data, Meilisearch for search and Oban for background jobs. An admin dashboard tracks search quality: zero results, failed searches and click position.

It runs in Docker behind Traefik, with Let's Encrypt certificates, and sends email through Mailgun. Every pull request runs tests, coverage and Dialyzer in GitHub Actions. Each merge on main builds an image, pushes it to Docker Hub and redeploys through a Portainer webhook.

Goals

• Learn Elixir, Phoenix and LiveView on a complete app: authentication, background jobs, PubSub and real-time UI.
• Design an application around contexts.
• Integrate a search engine and measure its quality.

Spotlights

I'm proudest of the domain design. I spent a lot of time on context boundaries and names. What sets the app apart is not storing files but helping teachers find resources. That gave me my core domain:

• Discovery (core): search, plus tracking whether each search succeeded.
• Library (supporting): documents, files and their curriculum objectives.
• Curriculum (reference): the French curriculum.
• Accounts (generic): authentication.

"Search" named an action, while "Discovery" names the goal. "Library" says what teachers build together. Once the names were right, I knew where new code belonged. Search statistics, for example, got their own Dashboard context.

Lessons Learned

• A LiveView is a process. Its state lives in assigns, and each change re-renders and sends only the diff to the browser.
• LiveComponents run inside the parent's process and have their own assigns. They receive data through update/2, not mount/3, and each needs a unique id. The dashboard components load their data with assign_async.

A Game Boy emulator written in Rust. It emulates the CPU, memory bus, graphics and interrupts well enough to run Tetris. Other games did not work.

Goals

• Learn low-level architecture: registers, opcodes.
• Understand how a CPU works by building a virtual one.
• Get comfortable with Rust on a larger project.

Spotlights

Implementing interrupts showed me how a game like Tetris is actually written. It is a tiny loop. Most of the logic is written in interrupt. For example, when a VBlanck interrupt is sent by the GPU, the game write the next frame in the graphic memory. At the end of that logic, the code execution come back to the main tiny loop.

Lessons Learned

• How a CPU works: decoding opcodes, flags, the stack and cycle timing, and why every component must stay in sync.
• Memory management in Rust: modelling the memory bus and deciding who owns it (CPU, graphics, timers).
• The borrow checker: several components need access to the same memory. I had to rethink my design around ownership instead of fighting the compiler, and that made the code cleaner.

I gave this talk on May the 18th at the Lyon Python meetup. It introduced MicroPython on the ESP32. It builds up to a working door alarm, step by step, from blinking an LED. The repo has the code, the wiring and a guide so attendees can reproduce each step.

Hardware: ESP32-WROOM DevKitC, breadboard, LED, button, reed switch and resistors. Tools: esptool to flash the firmware, pyboard.py to copy files, picocom for the REPL and uv.

Goals

• Show Python developers that they can program microcontrollers with the language they already know.
• Cover the core embedded concepts: GPIO, Wi-Fi, interrupts and watchdogs.
• Learn how a microcontroller boots, communicates and recovers from failures.

Spotlights

The final demo is a door alarm that brings every concept together:

• A reed switch on a GPIO pin detects when the door opens, using an interrupt instead of polling.
• If the door stays open too long, the ESP32 sends an HTTP request over Wi-Fi to a self-hosted ntfy server, which pushes a notification to my phone.
• A watchdog resets the board if it hangs. To show it live, I blocked the port with a firewall rule: the ESP32 got stuck waiting for the TCP handshake, and the watchdog rebooted it.

Lessons Learned

• Serial communication: UART has no shared clock, so both sides must agree on the baud rate. That's why flashing and the REPL each need a speed setting.
• The boot process: MicroPython runs boot.py, then main.py, from its own filesystem.
• Wiring: pull-down resistors and why a floating input gives random readings.
• Interrupts: handlers must stay short and follow MicroPython's ISR rules.
• Robustness: network calls can block forever, and a watchdog is a simple safety net.

This was the last C project in 42 Common Core. I worked with Maxime to make this one work. We created a Ray Tracer capable of drawing sphere, cylinder, plane and triangle.

Goals

This project goals were: * Implement in C a Ray Tracer with all the maths and physics behind rendering * Use multi-threading to optimize. * Implement texture mapping on objects.

Spotlights

This RayTracer is able to draw triangles. Therefore, it can draw all figures composed of triangles. This was not the most difficult thing to do. There is plenty of literature on how to know if a ray is crossing a triangle but the end view is impressive.

Lessons Learned

The teamwork was interesting on this one. At this point in the curriculum, I was used to working with Maxime. We had already worked on a couple of projects and we knew how to do this. We were pair programming a lot and used TDD whenever we could. On this project though, pair programming didn't work. As we were understanding the maths behind that at different paces, we only figured out together how to draw a plane. When we both understood the concept behind Ray tracing, we decided to split the work. He was much better than me at understanding the maths behind. Working this way gave me some time to familiarize with the concept.