I designed and authored the Ruby and Ruby on Rails bootcamp ("piscine") for École 42 — from
scratch. This meant writing the subject PDFs in LaTeX, designing the progressive exercise and
project sequences, creating automated test suites that students couldn't cheat, and integrating
everything into the 42 intranet so it could be evaluated via the peer-to-peer correction system.
First-person: this was my work from first keystroke to deployment on the intranet.
2wk
Bootcamp duration
20+
Subjects authored
100%
Peer-evaluated
LaTeX
All PDFs
42 School Pedagogy
No teachers · peer-to-peer · project-only — the 42 model
École 42 was founded in Paris in 2013 by Xavier Niel on a radical premise: no teachers,
no lectures, no mandatory schedules, open 24/7. Students progress through a
curriculum of projects evaluated by their peers using a structured grading scale. The school is
free and requires no diploma — the only prerequisite is passing the four-week "piscine"
(swimming pool) selection process.
🏊
La Piscine — selection
A 4-week intensive immersion in C programming. Students sink
or swim. Those who pass demonstrate not technical skill, but the capacity to learn
under pressure — the real selection criterion.
🎮
Gamified progression
Projects earn XP (experience points). Students advance
through levels on a "Holy Graph" — a visual curriculum map showing available and
locked projects, like a skill tree in an RPG.
🤝
Peer evaluation (correction)
Every project is evaluated by 2–3 other students following a
grading scale written by the project author. No teacher marks anything. Students
teach each other during corrections.
📋
The Intranet
42's intranet is the central nervous system: student
profiles, project submissions, peer correction scheduling, XP tracking, slot
booking, coalition rankings, and subject PDF downloads.
🧪
Elective "piscines"
Beyond the main C curriculum, 42 offered 2-week intensive
bootcamps in specific technologies — PHP/web, C++, OCaml, Unity, and
Ruby/Rails. These were optional deep-dives authored by pedagogical
staff.
📄
PDF subjects in LaTeX
Every 42 project is defined by a PDF subject — a precisely
formatted document describing the task, constraints, allowed functions, expected
outputs, and grading scale. All authored in LaTeX.
The author's role at 42
Unlike Simplon where I was a live teacher, at 42 my role was
invisible infrastructure. I wasn't in the room when students worked. My
voice was the PDF. My presence was the test suite. If a subject was ambiguous, students
couldn't ask me — they had to interpret the document. This forced extreme precision in
writing: every edge case had to be anticipated and addressed in the subject text, because
nothing could be clarified in person.
Bootcamp Structure
The Ruby / Ruby on Rails Piscine — 2 weeks
I designed the bootcamp as a two-week intensive, structured so that a student with no Ruby
knowledge could progress from puts "Hello" to a deployed Rails
application. The progression was deliberately steep — the piscine model selects for people who
can learn under pressure, not people who already know the material.
Week 1
Ruby — the language
D1
Ruby basics
Variables, types, string manipulation,
conditionals, loops. Exercises in the style of C piscine — small,
precise, auto-testable.
D2
Collections & iterators
Arrays, hashes, ranges. Blocks, each, map, select, reduce.
The functional heart of Ruby.
D3
Object-oriented Ruby
Classes, instance variables, methods,
inheritance, attr_accessor, modules and
mixins. Building a small object graph from scratch.
D4
File I/O & exceptions
Reading/writing files, begin/rescue, custom
exception classes, gems and Bundler.
D5
Minitest / RSpec intro
Writing tests as first-class citizens. Students
write tests for their own solutions — and discover bugs in their
"passing" code.
Week 2
Ruby on Rails — the framework
D6
MVC & routing
Rails new, MVC architecture, routes.rb, controllers, views. First working
Rails page from scratch — no scaffolding.
D7
ActiveRecord & migrations
Generating models, migrations, associations,
validations. Building a multi-model schema. PostgreSQL under the
hood.
D8
Forms, CRUD, ERB
Form helpers, params, strong parameters, flash
messages. Full CRUD for a resource — the classic "to-do list"
milestone.
D9
Authentication & authorisation
Devise integration, session management, Pundit
policies. Protected resources — some pages only for signed-in users.
D10–14
Final project
An open-ended Rails application built over 4
days, evaluated by peer correction using a grading scale I authored.
Deploy to a live URL required.
Subjects I Created
20+ exercise subjects — from atomic to architectural
Each subject is a self-contained PDF that defines exactly what the student must produce, the
constraints they must respect, the test cases that will be run, and the peer-evaluation grading
scale. I authored all subjects for the Ruby/Rails bootcamp. The progression was designed so each
subject built on — and required — the previous ones.
ex00 — hello_rubyD1
Write a Ruby script that prints "Hello, World!" and accepts a
name argument. Constraints: no gems, no require. Validates: Ruby syntax, CLI arg
handling, string interpolation.
basicsARGV
ex04 — my_eachD2
Re-implement Array#each, #map, #select, #reduce without calling the originals. Forces understanding
of blocks and yield mechanics.
blocksyield
ex08 — oop_vehicleD3
Model a vehicle hierarchy using inheritance and mixins. Must
implement Driveable and Flyable
modules. Peer evaluator runs provided RSpec examples.
OOPmixinsRSpec
ex12 — miniparserD4
Build a CSV/JSON file parser using only Ruby stdlib (no gems).
Reads a file, transforms data, outputs to stdout. Error handling via custom
exceptions required.
file I/Oexceptions
ex15 — tdd_bankD5
Write a BankAccount class. But:
tests are provided first. Students must make all tests pass — pure TDD. The twist:
tests cover edge cases students wouldn't think to handle.
TDDRSpec
ex16 — rails_helloD6
Create a new Rails app. Add a route, controller, and view that
displays "Hello, 42!" with the current timestamp. No scaffold. Grader verifies: file
structure, route correctness, running server.
RailsMVC
ex18 — blogD7–8
Full CRUD blog: Post model with title/body/author. No
scaffold. Form with validations (title ≥ 5 chars, body ≥ 20). Flash messages.
Pagination. Grader checks each action individually.
ActiveRecordformsvalidations
ex19 — auth_appD9
Extend the blog with Devise auth. Posts belong to users. Only
the post's author may edit/delete. Pundit policy required. Grader attempts to edit
another user's post — must be rejected with 403.
DevisePundit
ex20 — final_projectD10–14
Open brief: build a Rails application of your choice.
Requirements: auth, at least 3 models with relationships, tests, live deploy URL,
README. Peer grading scale authored and shipped with the subject.
full-stackdeploytests
Test Design
Automated tests — the invisible examiner
At 42, the test suite is part of the subject authorship. For exercises that could be
auto-tested, I wrote RSpec test files that peer evaluators ran against the student's submission.
For project-level evaluations, I authored detailed grading scales used during peer correction
sessions. The challenge: tests had to be impossible to fake while remaining
learnable from.
01
Provided RSpec test files
For language exercises (days 1–5), I shipped RSpec test files
with each subject PDF. Students ran rspec ex04_spec.rb
against their code. Green = pass, red = fail. I designed tests to be instructive:
failing output included the expected vs. actual value, pointing students toward the
bug without solving it for them.
RSpec
02
Edge-case engineering
The most important tests were the ones students hadn't thought to
write themselves: empty arrays, nil inputs, integer overflow, Unicode strings,
concurrent access. I deliberately included 2–3 edge-case tests per exercise that
only careful readers of the subject would anticipate — rewarding precision over
guessing.
edge cases
03
Behavioural tests for Rails projects
For Rails exercises, I used Capybara + RSpec feature specs
simulating a browser: "click the delete button on another user's post — expect 403".
This tested Pundit enforcement, not just the presence of a policy file. Students
couldn't fake it by simply creating the policy file without implementing it
correctly.
Capybara
04
Peer grading scales (barèmes)
For project-level evaluation, I wrote structured grading scales:
a sequence of questions and checks the peer evaluator must perform in order, each
worth a fixed number of points. Scales were designed to be executable by a student
who had completed the same exercise — not by a Ruby expert. Binary checks ("does the
app start? does this route return 200?") kept evaluation consistent.
barème
05
Anti-cheating design
A known risk at 42: students copy each other's code. I designed
exercises where slight variations in implementation (variable names, method
structure) would still pass tests, but copy-paste of a classmate's code would fail
on the randomised inputs I embedded in the test runner. The RSpec seed was different
on every run.
integrity
The hardest test to write
The most technically challenging test I designed was for the my_each exercise — verifying that students hadn't called the
original Array#each internally. The naive approach (checking the
source file for "each") was trivially bypassed. My solution: I monkey-patched Array#each to raise an exception before running the student's code.
If their implementation called the original, it exploded. If it was a genuine
reimplementation, it passed. This kind of adversarial test design taught me more about
Ruby's object model than years of professional use had.
LaTeX Redaction
Every subject PDF was written in LaTeX
The 42 pedagogical team required all subject PDFs to be authored in LaTeX,
using a custom 42 document class that produced the school's signature dark-themed,
monospace-heavy format. This was non-negotiable: LaTeX ensured consistent formatting,
version-controlled source, and a professional output that matched every other subject in the 42
curriculum. I wrote all 20+ Ruby/Rails subjects in LaTeX.
A typical subject document structure in
LaTeX:
% École 42 — Ruby Piscine subject\documentclass{42-subject}
\title{Piscine Ruby — Day 01}
\subtitle{ex04 — My Each}
\author{[author]}
\version{1.0}
\begin{document}
\maketitle\chapter{Instructions}
\begin{itemize}
\item Only turn in the asked files.
\item\textbf{Do not
use the standard Array methods}
internally.
\item Your functions must pass the provided
RSpec tests.
\end{itemize}
\chapter{Exercise 04 — my\_each}
\begin{42infobox}
Turn-in directory: ex04/Files to turn in: my\_each.rbAllowed functions: none\end{42infobox}
Reimplement the following methods on
\texttt{Array} without using the
originals:
\begin{itemize}
\item\texttt{my\_each}
\item\texttt{my\_map}
\item\texttt{my\_select}
\item\texttt{my\_reduce}
\end{itemize}
\end{document}
Why LaTeX specifically
42's subjects needed to be: version-controlled (Git diff-able),
consistently formatted across hundreds of subjects from different authors, printable
as high-quality PDFs, and able to render code in monospace with syntax highlighting.
LaTeX with a custom class handled all of this in a single source format. Word or
Markdown would have produced inconsistent output across the curriculum.
LaTeX skills acquired
42 document classcustom class
Code listings
(lstlisting)syntax
highlight
Custom
environments42infobox,
42warning
Multi-chapter
structurechapters, sections
Git-based
versioningv1.0 → v1.3
PDF/A output for
archivepdflatex
Intranet Integration
Deploying subjects onto the 42 intranet
Writing the subject was only half the work. For the bootcamp to run on the 42 intranet, each
project needed to be registered in the intranet system: subject PDF uploaded,
grading scale encoded, XP value set, peer evaluation slots configured, and the project linked
into the correct sequence of the Ruby piscine curriculum graph. The intranet is the
infrastructure — without this step, the subject doesn't exist for students.
01
PDF compiled and validated
LaTeX source compiled to PDF via pdflatex. Checked against the 42 PDF standard: correct
document class, version number, author metadata, no missing fonts. Stored in the
pedagogical Git repository.
LaTeX → PDF
02
Project created on intranet
Using the 42 intranet admin interface: create project record, set
name, description, difficulty, XP value, allowed retry count. Upload the compiled
PDF — this is what students see when they open the subject.
intranet admin
03
Grading scale (barème) encoded
The peer evaluation grading scale is entered directly in the
intranet: a sequence of checkpoints, each with a point value and binary/gradated
answer. The intranet generates the correction form that evaluators use during peer
evaluation — my written barème became interactive form fields.
barème form
04
Linked into the curriculum graph
The 42 "Holy Graph" is a directed dependency graph of projects. I
linked each Ruby piscine project into the correct sequence: ex00
→ ex04 → ex08…. Dependencies enforced by the intranet — students can't
attempt day 3 exercises before completing day 1.
Holy Graph
05
Correction slot configuration
Set the number of peer corrections required per project
(typically 2–3), the time window for corrections, and whether the project was "solo"
or "group". The intranet's slot system auto-assigns evaluator/evaluatee pairs.
peer system
06
Test cohort run
Before general release, a test cohort of 5–10 students ran the
full bootcamp. I reviewed the corrections log, identified subjects where students
systematically scored low (ambiguous wording) or high (tests too easy), and iterated
on the LaTeX source + intranet grading scale accordingly.
iteration
Intranet as product
The 42 intranet is itself a Rails application — which meant that as a
Ruby/Rails practitioner authoring content for it, I had an interesting dual relationship
with the platform. Understanding how Rails structured its data helped me design subjects
that mapped cleanly to the intranet's project/skill/correction data model. The grading scale
encoding in particular benefited from thinking about it as ActiveRecord-like structured data
rather than a freeform document.
Retrospective
What building this bootcamp taught me
Designing a complete curriculum from scratch — subjects, tests, grading scales, intranet
integration — was one of the most demanding and rewarding technical writing projects I have
undertaken. The constraints of the 42 model forced a quality of precision that normal developer
writing never requires.
✍️
Writing as product design
A subject PDF at 42 is a product — it has users (students),
it has requirements (the curriculum), and it has bugs (ambiguities). LaTeX forces
precision, but the real discipline was anticipating misreadings.
🧠
Depth of language mastery
Designing the my_each
anti-cheating test required a deeper understanding of Ruby's metaprogramming and
object model than any production app I had written. Adversarial test design is the
most effective form of language study.
📐
LaTeX as a professional tool
LaTeX is verbose and unforgiving, but the output quality and
version-control compatibility make it the right tool for technical documentation at
scale. I became genuinely fluent — not just proficient.
🔄
Feedback loops matter
The test cohort iteration cycle was essential. No amount of
pre-emptive review catches everything. The real curriculum was the one that survived
contact with actual students — not the one I wrote in isolation.
🌐
42's global reach
Once deployed to the 42 intranet, subjects are available to
all campuses in the 42 Network — 50+ campuses across 30 countries. The Ruby piscine
I authored ran in Paris, Lyon, Madrid, Tokyo, São Paulo.
🏫
Teaching without being present
The most counterintuitive lesson: at 42, the best
pedagogical outcome is for students to never need you. A well-designed subject is
self-sufficient. The goal of authorship is to make the author unnecessary.
Personal reflection
The combination of these three experiences — Cashpad backend engineer,
Simplon live teacher, 42 bootcamp author — gave me a complete perspective on Ruby and Rails
as both a technical and a pedagogical artefact. Each context demanded a
different kind of mastery: production craft at Cashpad, human communication at Simplon, and
documentary precision at 42. I find that fluency across all three registers — building,
teaching, and writing — is what distinguishes a senior from a senior senior developer.
