71 lines
2.6 KiB
Markdown
71 lines
2.6 KiB
Markdown
# Team Build — Extended Notes
|
|
|
|
*Not rendered in the platform yet. Reference for instructors and for
|
|
future "learn more" surfaces.*
|
|
|
|
## Purpose
|
|
|
|
The capstone of `1.welcome`. By this point a cadet has used every
|
|
tool they need: `mkdir`, `echo`, `git init`, `git config`, `git add`,
|
|
`git commit`, and shell scripting with `chmod +x`. This battle forces
|
|
them to combine all of it into a single artifact — a working
|
|
automation script — and to read someone else's script for the first
|
|
time.
|
|
|
|
## Skills Demonstrated
|
|
|
|
- Composing learned commands into a sequential program
|
|
- Writing a script with a correct shebang and execute bit
|
|
- Producing exact output from automation
|
|
- Reading another cadet's code well enough to score it
|
|
- Giving and receiving honest feedback under a time limit
|
|
|
|
## Common Pitfalls
|
|
|
|
- **One commit covering all three files** — defenders forget that the
|
|
spec says *each file commits separately*. Three commits, not one.
|
|
- **File contents with extra whitespace** — `echo` adds a trailing
|
|
newline by default, which is fine; trailing spaces on the line are
|
|
not. Reviewers should `cat -A` to spot invisible characters.
|
|
- **Missing or wrong identity** — `git commit` will succeed even
|
|
without `user.name` set if a fallback is configured globally;
|
|
reviewers should check `git -C mission config user.name` directly.
|
|
- **Hardcoded absolute paths** — `cd /Users/...` breaks the moment
|
|
the script runs on someone else's machine. Use relative paths.
|
|
- **`MISSION READY` printed inside another message** — the spec says
|
|
"exactly". `echo "Done. MISSION READY now."` should fail review.
|
|
- **Forgetting `chmod +x`** — script runs fine via `bash launch.sh`
|
|
but fails when executed directly. Reviewers should test both.
|
|
|
|
## Discussion Prompts (post-battle)
|
|
|
|
Ask the pair to discuss for 5 minutes after both rounds:
|
|
|
|
1. Whose script was easier to read? Why?
|
|
2. Was anything in the spec ambiguous? How would you tighten it?
|
|
3. What would you do differently if you wrote this from scratch
|
|
today?
|
|
4. Did you find a bug your partner missed?
|
|
|
|
## Alternative Approaches
|
|
|
|
A cadet who's seen heredocs might write:
|
|
|
|
```bash
|
|
cat > manifest.txt <<EOF
|
|
Mission Apollo
|
|
EOF
|
|
```
|
|
|
|
Both `echo "..." > file` and heredoc are acceptable. The spec
|
|
doesn't require a specific style — only that the resulting file
|
|
content match exactly.
|
|
|
|
## Why This Is the Last Block of Welcome
|
|
|
|
This is the bridge between mechanical skill (typing commands) and
|
|
real engineering (composing them, reading others' code, judging
|
|
quality). Cadets who pass this battle have proven they can act as
|
|
both author and reviewer — the foundational loop of every
|
|
collaborative codebase. Python is built on this foundation.
|