Stage 6 of 6 · Logistics, evidence, next steps
Lab & hand-in
The clock for the day and the evidence to leave behind, then the part that matters most this week: a concrete review plan for the midterm, because after today there is no new material between you and it.
The two hours
| Minutes | You do | Checkpoint before moving on |
|---|---|---|
| 0–10 | Station up, SSH in, circuit wired and traced, ~/iot/week6 with venv and .gitignore. | (.venv) prompt; circuit signed off. |
| 10–20 | On paper, together: capsule sketches for ReactionLog and ReactionGame; commit to docs/. | Both partners can say which class owns which state, and why. |
| 20–40 | reactionlog.py: type, import, REPL-test through the empty-log edge case. | summary() correct on 0, 1 and 3 times. |
| 40–65 | reaction_game.py: the refactor, played to five valid rounds. | False starts and valid rounds both behave; summary prints. |
| 65–75 | Re-run Week 5's verification table; commit the proof. | Every old row passes identically; the new summary row has its own check. |
| 75–110 | The class-design ladder, spec first, swapping roles each rung. | Each rung's spec and sketch committed before its code. |
| 110–120 | Evidence, exit ticket, clean shutdown, pack. | Drive returned; kit packed; station restored. |
Working as a pair
Navigator and driver, as in Week 5, with the navigator's job upgraded: besides the spec, the navigator owns the capsule boundaries, which class exists, what each owns, what each exposes, drawn before the driver types. Divergence found while coding ("this really wants to be the log's method, not the game's") goes back to the navigator as a design finding, the sketch is corrected, then the code. Swap each rung. By the midterm, both of you must be able to play both roles alone on paper, and this is the last supervised practice before it.
What to hand in
| Item | How to produce it | Shows that |
|---|---|---|
| Repository URL | Paste into the Omnivox form | reactionlog.py, reaction_game.py, ladder rungs with their specs, docs/ with sketches and the re-run verification table, commits from both partners, sketch-before-code order |
class-sketch.jpg or docs/design.md | Photo of the hand-drawn capsule boxes, or Markdown | The architecture existed before the code did |
| Verification table | In docs/requirements.md, updated | The refactor preserved Week 5's behaviour, and the new behaviour has its own checks |
station.txt | Typed in nano | Station number, Pi model, boot-drive label, both names, who navigated which rung, exit-ticket answers if asked |
Counts as completion of in-class work. From Week 8 on, Assignment 2 and the project will assume this shape, classes in modules, documents beside code, without saying so again.
Exit ticket
Answer without looking at the hub; write the answers at the end of station.txt if the teacher asks for them.
- In
sam.add(431), what isselfinside the method, and who passed it? - Write the class header and
__init__for aFanthat needs a pin and starts stopped. - Attribute or method:
button.is_pressed,led.blink(0.2, 0.2),game.log? One word each. - Week 5's
false_startflag no longer exists. What replaced it, and why? - Your NightLight shows mode NORMAL with the LED on. In one sentence, what design rule was broken?
Packing up
Homework: the midterm review plan
Midterm · Monday, October 19 · covers Weeks 1 to 6 · on paper
Two weeks, one of them without a class (no class Monday, October 12). Expect what the hubs have been telegraphing: tracing pseudocode and Python by hand, converting between pseudocode, flowcharts and code, repairing requirements, writing a small class or function on paper, short answers on the Weeks 1 to 3 tools, and the Week 4 kind of resistor calculation. Format details come in class and on Omnivox; the review below covers all of it regardless. The Week 7 hub turns this plan into full review pages, a 100-point practice exam and the reflection log guide.
| Session (~45 min each) | Revise | Prove it by |
|---|---|---|
| 1 · Week 1 | The four areas, the daily cycle, remotes, conflicts | Redrawing the four-areas diagram and narrating a commit-push-pull day from memory |
| 2 · Week 2 and Week 3 | Boot chain, core commands, apt cycle, SSH keys, UFW order | Writing the command for ten described tasks, and the allow-before-enable rule with its reason |
| 3 · Week 4 | Constructs, tracebacks bottom-up, GPIO rules, the LED math | Redoing the 330 Ω worked example and the 220 Ω exercise, cold |
| 4 · Week 5 | Requirement qualities, pseudocode conventions, trace tables, notations | One spec repair, one trace, one pseudocode-to-flowchart conversion per day |
| 5 · this hub | Class anatomy, self, state machines as classes | Writing ReactionLog on paper from its spec, then tracing two method calls |
| 6 · everything | Weak spots only | Every hub checklist green; every hub quiz answered before revealing |
The checklists and quizzes on every stage page were built for exactly this fortnight: they are the syllabus, itemized. Paper practice beats screen practice for a paper exam; the daily trace habit stays the single highest-value ten minutes.
Week 7: midterm and reflection log
Also due Week 7 · worth 10%
The reflection log
The journal notes the hubs have prompted since Week 2, exit tickets, "note it in your journal" moments, design homework, get assembled now, not the night before: one entry per week, what you built, what broke, what you understood only afterward. Honest beats polished; specific beats general. Submission format is on Omnivox.
After the break
Week 8: the second computer
The ESP32 joins the bench: analog sensing, a microcontroller beside your Pi, and Assignment 2 (the PID light-harvesting brief) lands, a requirements list you now know how to read, and a system your classes are ready to structure.