AmouAI Hub/Courses/Programming Fundamentals/Day 24
Capstone Build Lab
Guided build sessions. You build yours while a parallel reference project gets built on camera.
By the end of today you can
- Work from a design document to a running program
- Build in vertical slices rather than horizontal layers
- Keep a suite green while the code changes underneath it
- Recognise when to cut scope rather than cut quality
- Use the debugger and the tests together
- Commit in small, reviewable steps
▶Today's videos
Watch each video, then work the matching sections below. Watching alone will not do it.
1How to build, not what to build
The order matters more than the speed.
Do not build all the classes, then all the persistence, then all the interface. Build one feature end to end — one command that reads input, changes the model, saves, and reports. Then the next. You always have something that runs, and you find integration problems on day one instead of at midnight.
A four-hour shape
| Block | Focus | Rule |
|---|---|---|
| 0:00–0:30 | Skeleton — project layout, one class, one passing test | It must run before you go further |
| 0:30–1:30 | Slice 1, end to end | Commit when green |
| 1:30–2:30 | Slices 2 and 3 | Commit each |
| 2:30–3:15 | Edge cases and error handling | Break it on purpose |
| 3:15–3:45 | Tests up to target; run black/ruff or the formatter | |
| 3:45–4:00 | README, and honest notes on what is unfinished |
Drop a whole feature and say so in the README. Do not ship four half-features with no tests. A smaller finished program scores better and, more importantly, teaches you more — because finishing is the part most people never practise.
2When you get stuck
Everything you learned on Day 5, in the order to use it.
- Read the error properly. Bottom line first, then walk up the frames. Two minutes here saves twenty.
- Reproduce it smallest. Can you trigger it in five lines? Now you have a test case.
- One hypothesis. "The list is empty when it reaches this function." Not "something is broken".
- One test. The smallest thing that would confirm or kill it — one print, one breakpoint.
- Change one thing. Re-run. Observe. Change four and you have learned nothing.
- Rubber-duck it. Explain the function out loud, line by line. The bug usually surfaces mid-sentence.
- Walk away for ten minutes. Genuinely effective, and the step people skip.
A failing test is a bug you can reproduce on demand, in one second, forever. That is the entire reason Day 15 came before Day 24: when the capstone breaks, you will not be hunting through a running program — you will be reading a red test that names the broken behaviour.
Common capstone failures
| Symptom | Usually | Fix |
|---|---|---|
| Nothing works after a big change | Too many changes between commits | git stash, go back, smaller steps |
| Tests pass, program is wrong | Testing the wrong thing | Test the behaviour, not the implementation |
| Save works, load does not | Format written ≠ format expected | Round-trip test: save then load then compare |
| Works for you, crashes for the marker | Absolute paths, or a missing data file | Relative paths; create the file if absent |
| Slower and slower as data grows | Accidental O(n²) | Day 11 — find the loop inside a loop |
>_Python playground
A real Python interpreter running inside your browser. Nothing is installed, nothing is uploaded, nothing can break.
input(), comma separated →
✓Exercise set
Checked automatically the moment you submit. Work top to bottom — each one assumes the last. Your answers are saved in this browser.
Day 25 — Testing, Delivery & Course Synthesis
Ship it, then trace the through-line across all twenty-five days.