Week 14: Capstone Workshop

Pick the real task you will automate. Scope it with the instructor. Build it. Present it. The course's last piece.

Theme

You spent weeks 1-13 learning the tools. Week 14 puts them to work on a problem of your choosing. The capstone is one tool you actually want, automating one task you actually do.

There is no lecture in week 14 and no traditional lab. The week's structure is: scope-check on day 2, build for the rest of the week, polish and prepare a demo, present at the capstone presentation block (a ~3-hour session outside the per-week budget).

The capstone's success criterion is in the brief (see CAPSTONE.md): the tool must be something you would actually use after the course ends. Not a textbook exercise. Not a polished version of a tutorial example. Something YOU repeat that the tool will save you time on.

By the end of week 14 you have shipped a Git repository containing your tool, three or more pytest tests, a README, and a multi-commit history. You also have a 5-minute demo prepared with one paragraph on a bug you found and one paragraph on what you would do differently. That is the deliverable.

Reading (~30 min, optional)

The capstone is hands-on; the reading is light.

1. CAPSTONE.md (in this directory). Re-read the full specification. The grading rubric (40/30/30 code-quality / tests-and-docs / reflective-depth) is the contract.
2. Three exemplar specs (in CAPSTONE.md). At least skim them; do not pick one verbatim unless you genuinely have that need.
3. GitHub Actions: a starter workflow at https://docs.github.com/en/actions/quickstart. ~10 min. Optional stretch; CI on your capstone repo is a portfolio polish.

Week shape (no lecture, ~9 hours student time)

Total: ~8.5 hours of student time over the week + 1 cohort-presentation slot.

Day-by-day guidance

Day 1: brainstorm

List 5 things you repeat. The pattern: anything you do MORE THAN ONCE a month that involves data on your computer or the public internet.

Examples real students have picked in pilots:

• "I rename photos from each trip to a consistent format" -> photo renamer
• "I track my fantasy basketball team's stats weekly" -> stats scraper
• "I plan meals for the week from a fixed recipe set" -> grocery-list generator
• "I scan my mailbox for receipts and need a monthly summary" -> receipt parser (forward-pointer to AI-101 for the OCR step; for FND-102 use existing-CSV input)
• "I back up my notes directory to cloud storage and want to verify nothing got corrupted" -> backup-and-verify tool
• "I find the slowest queries in my service's daily log" -> log-analysis tool

If you have nothing repeated, you are not paying attention. Watch yourself for a day; note every "I'm doing this again" moment. Pick one.

Day 2: scope-check

The instructor's job: push back on scope. Most first-draft capstones are too ambitious. A good capstone has THREE properties:

1. Small enough to finish in a week. ~200 lines of Python is the sweet spot. ~50 lines is acceptable for a focused, well-tested tool. ~500+ lines means too ambitious.
2. Concrete enough to define "done." "A meal planner" is not concrete. "A CLI tool that reads recipes.json, accepts a week of meal names, and emits a deduplicated shopping list grouped by aisle" is.
3. Real enough that you will use it. If your gut says "I'll use this once and forget," pick a different task.

The instructor will ask:

• What is the input? (a file? a URL? a CLI argument?)
• What is the output? (a file? stdout? a database?)
• What does "done" look like? Three concrete success criteria, please.
• What is the smallest version you could ship? (A tool that does 60% of what you imagine in 200 lines is better than 100% imagined and 0% built.)

Bring a sketch (paper, whiteboard, README draft) to the meeting.

Days 3-5: build

The build pattern that worked for FND-102 labs:

1. Write the argparse first. Run with --help. Iterate the help strings until they read like documentation.
2. Build the happy path end-to-end with hardcoded inputs. Confirm it works.
3. Replace hardcoded inputs with argparse arguments.
4. Add error handling for the obvious failure modes.
5. Write tests for the now-defined behavior.
6. Polish: commit messages, README, README examples that work.

Push to a Git remote daily; you get free off-machine backup and the ability to share with the instructor for spot-check questions.

Day 6: polish

The polish day matters more than students expect. Things to check:

• --help reads like documentation. Field-name help strings ("input: input") are a tell that you ran out of time.
• Commit messages are sentences. Squash "wip" / "fix" / "asdf" commits via interactive rebase before pushing the final version.
• README has 5 sections. What / install / usage / tests / license (or "course artifact"). 150 words.
• Tests pass from a fresh clone. Try it: git clone YOUR-URL /tmp/test-clone; cd /tmp/test-clone; pytest. If anything is missing (a data file, a requirements.txt entry), fix it.
• The demo's bug-paragraph. Pick the most interesting bug you found. Write one paragraph: what was broken, how you discovered it, how you fixed it.

Presentation block: demo + Q&A

The format: 5-minute demo + 5-minute Q&A per student.

Demo structure:

1. What problem does this solve? (one sentence; the real thing you repeat)
2. What does the tool do? (one CLI command; show the output)
3. What's interesting in the code? (point to ONE function or module; do not tour the whole codebase)
4. What did you find while building? (the bug-paragraph from your reflection)
5. What would you do differently? (the "what would I do differently" paragraph)

Q&A: peers and instructor ask. Common questions:

• "What happens if [edge case]?"
• "Why did you pick [design choice] over [alternative]?"
• "What is the next feature you'd add?"

Answer honestly. "I didn't handle that edge case; here's what would happen" is a good answer. "I considered approach X but picked Y because [reason]" is a good answer.

Independent practice (built into the days above)

The week IS the practice. No separate independent practice block.

Reflection prompts (~30 minutes; do this BEFORE the demo)

These become the demo's reflection paragraph. Write them out fully; they help you speak fluently.

1. The bug. One bug you found while building. What was broken? How did you find it (print? pdb? a test? a user trying the tool)? How did you fix it?
2. The trade-off. One design choice that had an obvious alternative. What did you pick? Why? What would the alternative have changed?
3. What you would do differently next time. One thing. Not "I would write better tests" (that's everyone); something specific to this tool and this build.
4. The next feature. What would you add if you had another week? (Often comes up in Q&A; rehearse the answer.)
5. The audience. Who would use this tool besides you? Be specific. "Anyone who takes a lot of photos" is not specific; "members of my hiking club who share trip photos via Discord" is.

Tool journal (week 14)

No new tools introduced; this week consolidates everything from weeks 1-13. The student's tool journal by week 14 has ~40-50 entries; the capstone is the synthesis.

Submission

Push your capstone repository to GitHub or GitLab. Email the URL to interested@virtuscyberacademy.org with subject FND-102 capstone, {your-name}. Include in the email:

• The repository URL
• A one-sentence description of the real task you automated
• The one bug you found and fixed (a sentence; the full version is in the demo)

The course team grades within 7 days. Outstanding capstones (top decile per cohort) are invited to be added to the academy's public capstone showcase with the student's permission.

What comes next

The course ends. You move on to one of the courses that FND-102 gates: SEC-101 (Cybersecurity Principles), NET-101 (Networks & Packet Analysis), PEN-101 (Intro to Pentest), CSA-101 (Computer Systems Architecture I), HW-101 (Electronics & Microcontrollers), or AI-101 (Intro to AI for Security). All six assume FND-102 fluency. Your capstone is a portfolio piece you can cite in applications and demonstrate in interviews.

Keep building. The discipline of "this is something I repeat; let me automate it" is the discipline that distinguishes practitioners from copy-paste-from-Stack-Overflow programmers. FND-102 was the first 14 weeks of practice; the next 14 years are yours.