Project 1 — Apologist’s Card

“You can’t measure your growth if you never wrote down where you started.”

Chapter: 1 — The Sport of Programming Due: End of Week 1 Submit: A link to your code — an OnlineGDB project URL or a public GitHub repo URL — with apologist_card.cpp as the main source file. See Appendix D for the full workflow. Allowed tools: cout, cin, string variables, escape sequences (\n, \t), and your own typing. Not yet allowed: if statements, loops, functions you define yourself, arrays, anything not covered in Chapter 1.

The Setup

Every sport has player cards. Baseball cards. Soccer kits with names on the back. Basketball jerseys. Boxer’s stat cards listing weight class and reach. There’s a reason: when you’re trying to become someone, it helps to have a clear picture of who you are right now.

Apologists need one too. 1 Peter 3:15 says to be “always being prepared to make a defense to anyone who asks you for a reason for the hope that is in you; yet do it with gentleness and respect.” Most of us, asked an honest question by a friend, are not prepared. By Week 16 of this course, you will have built fourteen programs that each took a real question and made some small piece of it more legible. You’ll be a little more prepared. That’s the goal.

This card is your starting line — a snapshot of who you are right now, where you’re from, and (if you want to push past Normal) one question you’d like to be able to think about clearly by the end of the course.

So make it real. Make it specific. Don’t write Name: Student — write your actual name. The card you build today is the one your Week-16 self gets to look at and either be proud of or find a little embarrassing. Both are fine outcomes.

Learning Targets

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

• Write a complete, compileable C++ program from scratch.
• Use cout to produce well-formatted multi-line output.
• Use cin to read input from the user and store it in a variable.
• Use a string variable to hold and re-emit user input.
• Use escape sequences (\n, \t) to control whitespace.
• Read and react to your own compiler errors without panicking.

If you can do these six things at the end of this week, you’ve earned a Normal completion. Everything else is bonus.

Normal Tier

Goal: A program that prints a clean, multi-line “Apologist’s Card” using the user’s typed-in name and at least one other piece of typed-in information.

Required features

1. Prompts the user for their name using cin.
2. Prompts the user for at least one more thing. Pick anything that fits the theme — your hometown, your home congregation, your major, the language you wish you spoke, your year in school, your favorite book of the Bible, anything. The point is to get a second cin working and to put something real on the card.
3. Prints a multi-line “Apologist’s Card” using the input. The card must:
   • Be at least 6 lines long.
   • Include a top border and a bottom border made of repeating characters (like +---+, =====, ********, etc.). Border characters should be identical top and bottom.
   • Include a title row that says APOLOGIST CARD (or whatever variant fits your design — STARTING LINE, WEEK 1 CARD, etc.).
   • Display the user’s name and the other input in labeled rows, like Name: Maya and From: Denver.
   • End with a goal line the user did NOT type — something like Goal: Be coding in any language by Week 16. This line is hard-coded into your program.
4. Compiles cleanly with g++ -Wall -Wextra apologist_card.cpp -o apologist_card. No warnings, no errors. (In OnlineGDB, the -Wall -Wextra flags live in the project’s compiler settings — see Appendix D.)
5. The output is recognizably card-shaped. A stranger glancing at it should immediately read it as “a card,” not “a list.”

Example of acceptable output

User types Marcus and Concordia:

+-----------------------------------+
|         APOLOGIST CARD            |
+-----------------------------------+
  Name:  Marcus
  From:  Concordia
  Year:  Week 1 of 16
  Goal:  Be coding in any language
         by Week 16.
+-----------------------------------+

(Your card doesn’t have to look exactly like this. Yours can be more square, more vertical, more decorative, whatever. The judging is on clarity and intentionality, not on matching this template.)

Grading rubric — Normal (out of 100)

Medium Tier (+up to 25% extra credit)

Layer the following on top of Normal. You can pick any one Medium feature for partial extra credit, or implement all of them for full Medium credit.

M1. Ask for three or more inputs

Extend your card to include at least four labeled rows from the user. Some suggestions, in increasing order of how much they’ll force you to think about the card’s design:

• Your hometown or home congregation.
• Your year in school or major.
• A favorite quote (any source — make it short).
• The question you most want to be able to think about clearly by Week 16.

That last one is optional but the most useful. Write down the actual hard question you don’t yet have a good handle on. Then in Week 16 you get to revisit it. Keep the formatting clean — the more rows, the more pressure on your layout to stay readable.

M2. Strengths & Open Question section

Add a divider line in the middle of the card. Above the divider, the card lists “facts” (name, hometown, etc.). Below the divider, it lists “training” — at least two things the user typed in answer to:

• “What’s one skill you already feel strong in?”
• “What’s one question you want to be able to engage clearly by the end of the semester?”

The output should treat the two sections as visually distinct. Apologetics, like programming, is partly knowing what you can do and partly knowing what you can’t do yet. The card should reflect both.

M3. Card that looks like a card

The Normal tier asked for “card-shaped.” The Medium tier asks for deliberate, visually clean layout. That means:

• All labels (Name:, From:, etc.) are vertically aligned — the colons line up in the same column.
• The card has consistent internal padding (e.g., one blank line between sections, two spaces of left margin on every row).
• The card is visually balanced — no row is dramatically longer than the others (or, if one is, the layout accounts for it).

Use "\t" for column alignment if you want — that’s the typical move.

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

The Hard tier is intentionally hard. It’s meant to stretch you slightly past what Chapter 1 explicitly covered. Hitting Hard means you’re already pulling ideas from outside the chapter, and that’s exactly the kind of student we want to challenge.

You may pick any one of the following Hard features. Each is worth full Hard credit on its own. Stacking multiple is allowed and reflected in the rubric, but ambitious. Pick what excites you.

H1. Two views from one input

Print two cards back to back using the same user input — but make them visually different from each other. For example:

• A “Week 1 Card” for the version of you who’s just starting.
• A “Week 16 Card” for the version of you who finishes the course.

Same data, different framings. This is your first taste of reuse — the same variable, used in multiple places, in slightly different ways. (Foreshadowing: Chapter 5 will give you functions, which is the formal tool for this idea.)

H2. Multi-column layout

Build a card that has at least two clearly-defined columns of data. Example:

+----------------------------------------+
|            APOLOGIST CARD              |
+----------------------------------------+
   Name:   Maya             Year:  1     
   From:   Denver           Reps:  0     
   Major:  Theology         Q:     ???   
+----------------------------------------+

You’ll need careful use of "\t" (and maybe extra spaces) to keep the columns aligned. Don’t worry if it breaks when the user’s input is unusually long — fixed-width input is acceptable for now. Just make it work for “normal-length” entries.

H3. The “Open Question” extra screen

The user’s first card is the Apologist’s Card. After printing it, your program prints a second screen titled // open question // with at least 4 lines of additional context that include hard-coded text mixed with the user’s name. Examples:

• A “question I want to be able to engage” line.
• A “first response I have today” line.
• A “what I’d still need to learn” line.
• A “Week 16 follow-up” reminder — something like “Maya, revisit this when you finish the course.”

The open-question screen should look visually distinct from the main card (different border style, different alignment, etc.). The point is to capture, in print, the actual question you don’t yet know how to handle — so you have something concrete to grow toward.

H4. The flex move

Find one thing you can do with cout/cin/string that we didn’t show you in this chapter. Document what it is in your README. Examples (Google-friendly): std::setw, std::setfill, \033 color codes (in some terminals), reading a full line with getline. If you go this route, your README must explain (1) what the feature does, (2) where you found out about it, (3) why you decided it was worth adding, and (4) one limitation you noticed while using it.

This is the “learn a feature outside the textbook” move. It’s the rep that turns students into self-directed learners. Treat it seriously.

Submission

Submit one URL via the course portal:

• OnlineGDB project link (recommended for Coding 1 and Coding 2). Create your project at onlinegdb.com, set compiler flags to -Wall -Wextra in the project settings, build your solution, and share the link. See Appendix D for the full workflow.
• GitHub repo link (optional). If you’ve set up local development on your own, push the source to a public repo and submit that URL. You’re responsible for making sure the code compiles when the grader checks it out.

What the linked project must contain

1. The main source file — apologist_card.cpp — containing your full solution.
2. A reflection comment block at the very top of that file:

/*
 * Tier targeted:    Normal / Medium / Hard
 * Features done:    list each feature you completed
 * What I learned:   one short paragraph (no bullets)
 * What I'd change:  one sentence
 * AI usage:         where and how, if any. Be honest.
 */

3. The program left in a “demonstrable” state — when the grader presses Run, the features for your targeted tier should be exercised. Hard-code inputs at the top of main() (or pre-fill OnlineGDB’s Stdin panel) so the grader doesn’t have to guess what to type.

That’s it. No separate demo.txt. No screenshots. The instructor will open your link, read the comment block, run the program, and grade against the rubric.

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 These If You’re Stuck)

• “My program ends before I can type anything.” You wrote a cout prompt but forgot a cin. Look right above the early exit.
• “The second input gets skipped.” Recall Rep 7. cin >> reads up to whitespace. If your first input was two words, the second word may have been consumed by the second cin. For Project 1, instruct your user to type one-word inputs — that’s fine — or use getline() (which the textbook doesn’t formally cover until Chapter 6, but you’re allowed to use it for the flex move).
• “My borders don’t line up.” Use a consistent character count for the border and use the same string literal both times — e.g., store it conceptually as a fixed-width string. (You don’t have variables for multi-line output yet, so for now, just be careful when you type.)
• “My alignment looks weird when I print it.” Different terminals render \t differently. Try resizing your window. Or, if you want hard alignment, use spaces instead of \t and count carefully.
• “How long should this take me?” Normal: 30 minutes to 1 hour if you’ve done the Reps. Medium: 1–2 hours. Hard: 2–4 hours depending on which feature you pick. If you’re spending way more than that, take a break and ask for help. If you’re spending way less, you might be missing a requirement — re-read the rubric.

What Mastery Looks Like (Beyond the Rubric)

The rubric tells you what to do. Here’s what to aim for:

A great Project 1 looks like you. Not generic placeholder text. Not a template-flavored card. Something specific — a hometown you actually live in, a quote that means something to you, a question you actually have. The grader can tell.

A great Project 1 has intentional design. Not just “I put a border somewhere.” Every spacing decision, every character, every label has a reason you can articulate. If asked “why did you center the title row?” the answer isn’t “I dunno, it looked OK” — it’s “because the eye scans cards top-down and the title needs to anchor the gaze.”

A great Project 1 is easy to read out loud. Your code, not your output. A grader reading your .cpp file should be able to predict what the output will look like before running it. That’s what clean code feels like.

You’re allowed to make Project 1 small. You’re allowed to make Project 1 a personal statement. Both are good. Pick which one calls you and commit.

When You’re Done

1. Read your own apologist_card.cpp out loud. Slowly. Listen to it.
2. Run it three times with three different inputs. Anything break?
3. Fill in the reflection comment block at the top of apologist_card.cpp to reflect what you actually built. (Be honest about tier.) See the Submission section above and Appendix D.
4. Submit.
5. Read Chapter 2. We’re going deep on Memory.

Coach’s Note — This is the first project. The bar is intentionally clear. Project 2 will assume you mastered everything here, so don’t half-ship it. Do every rep, hit at least Normal cleanly, and if you have time, push for Medium or Hard. The students who treat Project 1 seriously almost always cruise through Project 2. The students who phone it in pay for it in Week 2.

Welcome to the gym. See you on Monday.