Project 14 — FINAL: A Real Small Application

“Whatever you do, work heartily, as for the Lord and not for men.” — Colossians 3:23

“The mark of a great workman is the ability to do small things well.” — anonymous craftsman

Chapter: 16 — Final Review When: In class, ~60 minutes (your instructor may adjust to 75) Submit: A link to your code — an OnlineGDB Java project URL or a public GitHub repo URL — with all seven required deliverables present (see Submission below). See Appendix D for the OnlineGDB workflow and Appendix A for AI assistant setup.

Allowed during the exam:

• The course’s AI assistant (Appendix A).
• The textbook itself (printed or non-interactive PDF).
• Your own past project files, in printout or USB form (your past prompts.txt logs are especially useful).
• The compiler, the JVM, JUnit 5, and a basic editor.

NOT allowed:

• The open internet (other than the AI assistant interface itself).
• Communication with another human during the exam.
• Anyone else’s code (other than the Java standard library and JUnit 5).
• A submission that lacks the prompts.txt log of every prompt you sent.

The Setup

You have learned, over fifteen weeks, to build a small system well.

Week 1: read code carefully. Week 2: write a spec. Week 3: handle errors deliberately. Week 4: write tests before code. Week 5: debug by hypothesis. Week 6: persist data with care. Week 7: recurse where natural. Week 8: collections as native vocabulary. Week 9: pair with AI as a senior partner. Week 10: prompts as specifications. Week 11: review AI output discerningly. Week 12: architect before you prompt. Week 13: iterate to green. Week 14: claim what is honestly yours. Week 15: drill the integration.

The final asks you to do all of it. In 60 minutes. On a real small application of your choice.

This is the capstone. It is also, by design, exactly the kind of small project a working junior engineer might ship in their first month. The fact that it is achievable in 60 minutes, with AI as a partner, is the point of the course. You can do this. The rest of your career is doing variants of this, on larger scales, with longer time horizons.

Learning Targets

By completing this project, you will demonstrate that you can:

• Write a specification (P2 skill).
• Write JUnit 5 tests before production code (P4 skill).
• Persist data to a file in a documented format (P6 skill).
• Handle exceptions deliberately at I/O boundaries (P3 skill).
• Document a module architecture (P12 skill).
• Use AI for individual methods within an architecture you designed (P9, P10, P13 skills).
• Reflect honestly on what the AI did versus what you did (Chapter 14 skill).
• Integrate all of the above under a 60-minute time pressure (capstone skill).

The Approved Scope List

Pick one of the following. Each is approximately the same size and complexity. Pick the one that resonates — they are all real, all useful, all buildable in 60 minutes by a student who has done the reps.

Scope 1 — Daily Verse Rotator

Reads a CSV file of reference,text rows. Each run displays one verse. Tracks which verses have been shown so each appears once before any repeats. Resets the cycle when all are shown.

Scope 2 — Study-Streak Tracker

Records the dates a user “checks in” (one check-in per day). Computes the current streak (consecutive days). Persists across runs. Reports current streak and longest-ever streak.

Scope 3 — Sermon-Note Indexer

Reads a text file of sermon notes. Builds a keyword index. Supports search: given a keyword, return the line numbers (or sermon titles) where it appears. Save the index to disk so the second run is faster.

Scope 4 — Prayer-Journal Recorder

Records timestamped journal entries (text + datetime). Supports search by date range. Persists across runs. Lists all entries within a window.

Scope 5 — Hymn-Suggestion Generator

Reads a CSV of hymns with associated themes/keywords. Given a theme keyword input, returns the top-3 best-matching hymns by simple scoring (keyword overlap is fine; nothing fancier required).

All five fit one of the five patterns in Chapter 16 §16.2. Identify the pattern first; the architecture follows.

A direct word, as with every project that touches the apologetics frame:

These scopes are tools, not theology. A daily-verse rotator does not claim to be a devotional practice; it is a small program that happens to use verse data. A hymn suggester does not claim to be a worship planner; it is a small program that happens to use hymn data. The course is asking you to build real things; the things happen to be in the church-adjacent space because that’s the frame of this textbook library. The technical work is the technical work.

Coach’s Note (confessional Lutheran framing) — The scope list is deliberately church-adjacent because the LCMS audience this book serves has natural use for these tools. None of these are a substitute for the means of grace (the Word and the Sacraments); they are small assists for the ordinary disciplines of Christian life. A Lutheran Service Book hymn suggester is not the same kind of thing as Sunday morning Divine Service, and the course knows the difference. Build the tool. Use it in its proper role.

Normal Tier

Goal: Ship one of the five scopes, complete with all seven deliverables.

Required deliverables

1. spec.txt — A complete specification, including:

   • One-sentence description.
   • Inputs and outputs.
   • At least 3 invariants.
   • The public API (class names + method signatures).
   • The persistence file format you chose, documented.

2. <MainClass>Test.java — A JUnit 5 test file with at least 6 tests, written before the production code. The grader checks file timestamps where possible; more importantly, your prompts.txt log shows the order. Tests cover the public API and at least one error case.

3. <MainClass>.java (and any supporting class files) — The implementation. Compiles cleanly. Runs end-to-end against a sample input. All your tests pass.

4. architecture.docx — A brief module-architecture doc, ~half a page. Lists each class, what it owns, what it does, and the data flow between them.

5. prompts.txt — Every prompt you sent the AI, in chronological order, with timestamps. Same format as previous Phase 2 projects (see P13’s submission spec for the template). At least 2 methods in your final code must have been AI-built, and their prompts must be in the log.

6. reflection.docx — 200–400 words. Honest. Specific. Answers:

   • What the AI got right on the first try.
   • What you had to redirect.
   • What you wrote by hand because asking would have taken longer.
   • One thing you would change about your approach next time.

7. A reflection comment block at the top of <MainClass>.java:

   /*
    * Project 14 — Capstone: <Scope Name>
    *
    * Tier targeted:     Normal / Medium / Hard
    * Time used:         <e.g., 56 minutes>
    * Tests passing:     <count>/<count>
    * AI methods:        <count> of <total> methods
    * Total prompts:     <count>
    * What I learned:    one sentence
    */

Normal-tier rubric (out of 100)

Medium Tier (+up to 25% extra credit)

M1. A second persistence mechanism

Implement a second way to persist the same state. Most students do this by adding JSON output alongside the plain text format from Normal tier — your data file can be written as either text or JSON depending on a constructor flag or a CLI argument. Both formats must round-trip cleanly (write, restart, read, behavior unchanged).

This exercises the interface boundary lesson from Chapter 12 — the persistence layer is swappable behind a common interface (StateStore or similar). Define the interface explicitly. Provide two implementations.

M2. A --format json (or equivalent) command-line flag

Wire the new persistence mechanism into your main via a command-line argument. The grader will run your program with and without the flag; both must work.

Medium-tier additional points (+up to +25)

• Persistence interface defined cleanly with two implementations: +10
• Both implementations round-trip correctly: +10
• CLI flag works without breaking the default behavior: +5

Hard Tier (+up to 25% additional extra credit)

H1. A small CLI menu

Replace one-shot main with a small interactive menu loop:

> add        — record an entry / check in / index a note (per scope)
> list       — show recent state
> search X   — search the index / find by date range / etc. (per scope)
> reset      — reset the cycle / clear state
> quit       — save and exit

Five commands. Each exercises one path through your existing API. Robust to bad input (a typo’d command is reported, not crashed).

H2. Exhaustive integration tests

Add an IntegrationTest.java with at least 4 tests that exercise full round-trips:

1. Add entries → restart → list shows them.
2. Reset → restart → state is genuinely cleared.
3. Bad input in the CLI doesn’t corrupt state.
4. Two persistence formats produce equivalent reads (only required if you did Medium tier — otherwise four tests on one format).

These tests should actually invoke your CLI loop programmatically (or at least drive its underlying API end-to-end) — not just unit-test individual methods.

Hard-tier additional points (+up to +25)

• CLI menu functional with 5 commands: +15
• Bad-input handling on the CLI: +5
• IntegrationTest.java with 4+ end-to-end tests, all passing: +5

Submission

Submit one URL via the course portal:

• OnlineGDB project link (recommended). Create your project at onlinegdb.com, choose Java as the project language, add all your .java files and the seven deliverables as text files. Share the project link.
• GitHub repo link (alternative). Push everything to a public repo. Filenames must match public class names. The grader will compile with javac *.java and run with java <MainClass>.

What the linked project must contain

1. All source files (*.java), filenames matching public class names.
2. All seven deliverables from Normal tier (Medium and Hard add to them, not replace).
3. A sample input file so the grader can press Run without setup (a small verses.csv, notes.txt, or equivalent for your scope).

The grader will: open the project, read the comment block at the top of <MainClass>.java, read spec.txt and architecture.docx, run the tests, run the program end-to-end with the sample input, read prompts.txt and reflection.docx, and grade against the rubric.

Every deliverable is graded. You cannot make up for a missing reflection.docx by writing more code. Budget for all seven.

Coach’s Note — Coding 1 and Coding 2 focus on writing code, not managing development environments. If something behaves oddly, you and the grader are looking at the exact same browser-hosted environment — there are no “works on my machine” defenses by design. Coding 3 will introduce a local toolchain properly.

Hints (Read Before the Exam)

• Pick your scope in the first 60 seconds. All five are roughly equal in difficulty; the choice should be quick. Pick the one whose pattern (§16.2) you most recently drilled.
• Spec, then architecture, then tests, then code. In that order. Chapter 15 §15.3 walks the whole sequence. Re-read it.
• 3 minutes for the spec. 3 minutes for the architecture. 10 minutes for the tests. The rest is implementation, review, and reflection. This timing isn’t a suggestion; it’s the pace that produces 60-minute completions.
• Use the AI for the routine method bodies, not for architectural decisions. §16.6 of Chapter 16 is explicit on this.
• Scope every prompt to one method. §13.3. “Modify only recordCheckIn. Output only the new method body.” Saves regressions.
• Always paste the failing test into the prompt. §13.4. Doubles the AI’s accuracy.
• Log every prompt in real time. Not at the end. The discipline must already be habit by now; if it isn’t, you’ve practiced a different exam.
• Budget 3 minutes for reflection.docx. It is graded for 10 points. Three minutes for 10 points is excellent ROI; skipping it is not.
• If a feature isn’t working with 5 minutes left, cut it. Better to ship a clean Normal-tier than a half-broken Medium-tier. The rubric rewards completeness within tier far more than ambition outside it.
• Estimated time: Normal: ~50 minutes (10 minutes buffer). Medium: full 60 minutes. Hard: 60 minutes is tight; budget for skipping a Hard feature if pressed.

What Mastery Looks Like

A great Project 14 has a spec.txt you could hand to another student and they could build the same program. That is the test of a real spec. Vague specs are not specs.

A great Project 14 has tests that fail before the code is written, then pass after. The test file timestamps and the prompts.txt log show this.

A great Project 14 has an architecture.docx that names the pattern (one of the five in §16.2) and explains why that pattern fit the scope.

A great Project 14 has a prompts.txt log a senior engineer could audit and respect. Scoped prompts. Diagnostic-first. Tests embedded. Total count probably between 5 and 12 prompts for the whole program.

A great Project 14 has a reflection.docx that names a specific moment when AI partnership worked well, and a specific moment when it didn’t. “AI worked great” is worth nothing; “I asked the AI to fix a failing test on line 23; its first attempt rewrote next() and broke versesRemaining(); my redirect with the joint-constraint prompt template fixed both in one round” is the work.

A great Project 14 is the size it needs to be and not larger. Five classes for a daily-verse rotator is over-engineered. Two classes is probably under-engineered. Three is the right answer most of the time.

A great Project 14 has the student’s name on it because the student wrote the system. The AI wrote some lines. You wrote the system.

Coach’s Note on Exam Day

The students who pass the final have done two things: the reps before the exam, and at least one full timed Drill-5 practice run (Chapter 15 exercises).

If you haven’t done a timed practice run, do one right now, even if you’re reading this two hours before the exam. The discipline of building the whole shape of program under a clock changes how your fingers move.

In the exam room:

• Spec first. Three minutes. No exceptions.
• Tests second. Even if you can “see the code in your head,” write the tests first. You will be wrong about what’s in your head more often than you think.
• Compile early, compile often. Java’s compiler is your tightest feedback loop.
• Log prompts as you go. The five seconds per prompt now is much cheaper than reconstructing from memory at minute 58.
• Take the keyboard when the AI is wasting time. §13.7. You are the senior.

The final is a project. Treat it like one.

A Theological Footnote

The course’s apologetic frame across both books has been the question what does it mean to do this work well as a Christian? You have ranged across the questions: careful reading, faithful promising, deliberate handling of brokenness, epistemic discipline, honest self-correction, stewardship of data, the part-and-whole logic of recursion, the catalog as the church’s labor, the partnership of human and tool, the precision of confession, the discernment of spirits, the architecture of cities (Babel and Jerusalem), the patience of correction, and the honesty of attribution. None of these have been settled fully. They were not meant to be. They were meant to put a Christian student in the habit of asking those questions, deliberately, of every piece of work in front of them.

The vocation question — what can a Christian engineer build? — does not have a clean answer this chapter can give you. It has a shape of an answer: you can build small things well, in service to your neighbor, honestly attributing the labor of others (human and tool), without overclaiming and without falsely shrinking. That shape can be filled in across the next thirty years of your career, project by project, in whatever industry you land in.

The capstone is one small instance of that lifelong shape. Show up to it the way you mean to show up to all of them.

If the apologetic frame has spoken to you, the questions don’t end on Sunday afternoon when you submit your final. They follow you into your first job, your fifth job, your second decade. They follow the people around you, your coworkers, the juniors who will eventually look to you the way you have looked to senior engineers in this course’s pages. You will be a senior engineer to someone. The way you direct AI, the way you correct, the way you claim your work and credit others — all of it forms a posture that other people will read off of you. Form it deliberately.

Show up rested. Trust your training. Submit something honest.

See you on the other side.