YOUR BOUNDARY
Keep one toolchain.
Store projects in one writable macOS folder and run the POSIX Wrapper and virtual-environment commands from Terminal. Keep machine-specific paths out of Git.
Loading…
ENGINEERED BOOTCAMP / MACOS / TERMINAL
Keep the bootcamp on your Mac, use Terminal with its default shell, and match every installer or container image to Intel or Apple silicon before you run it.
YOUR BOUNDARY
Store projects in one writable macOS folder and run the POSIX Wrapper and virtual-environment commands from Terminal. Keep machine-specific paths out of Git.
BEFORE STEP 01
YOUR PATH
Stop at a failed checkpoint, read the linked official source, and make one bounded correction before you continue.
STEP
01
INVENTORY
WHAT THIS STEP TEACHES
“I can identify my exact macOS release and whether the Mac uses Intel or Apple silicon.”
The chip architecture determines which native package can execute; the macOS release determines whether the vendor supports the operating system.
A package for the wrong architecture may not run or may rely on emulation, and a package for an unsupported macOS release may stop receiving fixes.
Predict whether uname -m will show x86_64 for Intel or arm64 for Apple silicon, then compare the observation with About This Mac.
Do not assume every Mac download is universal or that an Intel-only image is native on Apple silicon.
State the macOS release, chip, uname result, resources, and how those facts constrain later Java, Python, and container choices.
GUIDED ACTION
Open Apple menu → About This Mac and record the macOS version, chip, memory, and free storage. Run uname -m in Terminal and reconcile the result with the chip before downloading any architecture-specific package.
CHECK BEFORE STEP 02
Your record names the exact macOS release and chip architecture and links them to a vendor-supported package choice.
STEP
02
JAVA
WHAT THIS STEP TEACHES
“I can choose a Java 17 JDK that matches my operating system and architecture and distinguish a JDK from a runtime alone.”
A JDK contains the Java runtime plus development tools such as the javac compiler; a runtime-only package cannot compile your source code.
Professional builds compile and test from source, so both the runtime and compiler must be supported, discoverable, and on the same major version.
Find Java 17, JDK, your operating system, and your architecture on the official page before downloading or invoking a package manager.
Do not select a package because its filename contains Java; confirm JDK, major version 17, operating system, and architecture separately.
Explain why you selected this distribution and package, which architecture it targets, and why a JRE-only installation would fail the course check.
GUIDED ACTION
Choose Java 17 from Eclipse Temurin, Microsoft OpenJDK, or another compatible distribution. Select macOS x64 for Intel or macOS AArch64/Apple silicon for arm64. Download the JDK package—not only a JRE—through the official page, run the signed installer yourself, and record the distribution.
CHECK BEFORE STEP 03
The official source supports your host, and a new shell reports Java 17 for both java and javac from locations you recognize.
STEP
03
JAVA CHECK
WHAT THIS STEP TEACHES
“I can prove that a tool is configured persistently rather than available only in one lucky terminal session.”
A shell resolves command names through its current environment, especially PATH; installers and activation commands may change only one process or future processes.
Builds, CI jobs, new terminals, and restarted computers do not inherit accidental state from a terminal you configured manually.
Predict which executable a new standalone shell will find and whether its version will match the one you just installed.
Do not verify only inside an editor terminal or an already-activated environment and assume the configuration is persistent.
Explain what closing the old shell removed, what the new shell loaded, and what the version and executable-location checks prove.
GUIDED ACTION
Close Terminal, reopen it, list the available JDKs, and verify java and javac. If macOS selects a different installed JDK, use the selected distribution's official JAVA_HOME guidance rather than deleting another application's runtime.
CHECK BEFORE STEP 04
A newly opened standalone shell finds the intended executable and version without repeating an unrecorded setup command.
STEP
04
PYTHON
WHAT THIS STEP TEACHES
“I can install or select Python 3.14 without replacing an operating-system-managed interpreter.”
The operating system may depend on its own Python, while a project can deliberately select another interpreter and isolate packages in a virtual environment.
Replacing a system interpreter can break package-management or administration tools; project isolation keeps dependencies reproducible and removable.
Identify the exact Python 3.14 launcher or executable the official method will provide and predict how you will call it without changing the system default.
Do not repoint or overwrite an unversioned system Python merely to make a version command look correct.
Explain which interpreter belongs to the operating system, which one belongs to the course, and how your project selects the latter.
GUIDED ACTION
Open Python.org's macOS downloads, select the current stable Python 3.14 installer rather than the Python 3.15 prerelease, and follow the package installer. Keep Apple's system-managed tools untouched and confirm which python3.14 executable the shell resolves.
CHECK BEFORE STEP 05
The version-specific launcher reports Python 3.14, and the operating-system-managed interpreter remains untouched.
STEP
05
GIT
WHAT THIS STEP TEACHES
“I can identify one Git installation and separate executable configuration from my commit identity.”
Git is the version-control program; user.name and user.email are authorship metadata stored in commits, not login credentials.
Traceable work requires consistent authorship, while duplicate Git installations or copied credentials make failures and provenance harder to diagnose.
Predict which Git executable your chosen shell will find and decide which name and email are appropriate for your own commits.
Do not install a second Git just to obtain the newest number, and never place a password or token in identity fields.
Explain where Git came from, which shell uses it, what identity metadata does, and why it is not a password or access token.
GUIDED ACTION
Run git --version first. If Git is absent or unsuitable, choose one current path from Git's macOS page—Xcode Command Line Tools, Homebrew if you already use it, or MacPorts if you already use it. Do not install multiple package managers for this course.
CHECK BEFORE STEP 06
Your chosen shell finds one maintained Git installation and new commits contain only the identity you intentionally configured.
STEP
06
WORKSPACE
WHAT THIS STEP TEACHES
“I can create a workspace owned by my normal user and keep project paths portable.”
A workspace is the file-system boundary where source, generated files, and project-local dependencies live under predictable ownership.
Root-owned files, mixed Windows/Linux paths, and committed personal absolute paths cause permission failures and make a project fail on another machine or in CI.
Choose a location your normal user owns and predict its absolute path, but plan to use repository-relative paths inside tracked files.
Do not create or open the project with administrator or sudo privileges merely to bypass an ownership error.
Explain who owns the workspace, which operating-system side contains it, and why tracked files must not depend on your personal home path.
GUIDED ACTION
Choose a writable folder under your user account, open it from Terminal, and record its absolute path only in your private decision record. Configure your editor to open this folder without committing its machine-specific workspace state.
CHECK BEFORE STEP 07
Your normal user can create and edit files there, and a tracked-file search finds no personal absolute path.
STEP
07
PYTHON PROJECT
WHAT THIS STEP TEACHES
“I can create a project-local Python environment and prove that its interpreter—not a global one—runs pytest.”
A virtual environment is a project-specific interpreter context with its own package location; activation only changes how the current shell resolves commands.
Projects need different dependency versions, and CI must be able to reproduce those dependencies without modifying the machine-wide Python installation.
Predict which new folder will appear and which Python executable should run after activation or when addressed explicitly.
Do not use sudo or a global pip command to repair a project-local dependency problem.
Explain what the virtual environment isolates, what activation changes, what it does not change, and how you proved pytest ran inside it.
GUIDED ACTION
Create .venv with python3.14, activate it, install pytest through python -m pip, and run the tests. Close Terminal, reopen it, return to the project, reactivate the environment, and repeat the version and test checks.
CHECK BEFORE STEP 08
The project-local interpreter runs pytest, generated files belong to your normal user, and the environment folder is ignored by Git.
STEP
08
PROJECT CHECK
WHAT THIS STEP TEACHES
“I can use project-owned scripts and separate current observations from tools required only in later modules.”
A wrapper script records how the project invokes a build tool; an environment inventory records what is currently present without making every tool an immediate dependency.
Project-owned entry points reduce machine-to-machine differences, while installing future infrastructure early increases cost, privilege, and troubleshooting surface.
Predict which wrapper script belongs to your shell and list later tools you will inspect but intentionally not install yet.
Do not install every named technology during setup or substitute a globally installed build command for the project wrapper.
Explain why the wrapper is portable, which script your shell uses, and why Docker, PostgreSQL, Node, or Kubernetes may remain deferred.
GUIDED ACTION
Run ./mvnw for the Java project in Task 2. Record future tools only if they exist. Before Week 14, verify that required Docker images include your architecture or plan a multi-platform/fallback route; do not force an amd64-only image silently on arm64.
CHECK TO FINISH THIS PATH
The correct wrapper test passes, and every missing future tool is marked deferred with a supported later path rather than installed early.
YOUR COMMANDS
Type each command in the shell for your selected path. Do not include a prompt symbol. Keep redacted output and explain what each result proves.
COMMAND 01
uname -mAsk the operating system for the machine hardware name exposed to this environment.
Predict x86_64 for an Intel/AMD 64-bit environment or arm64/aarch64 for an ARM environment, then verify the exact output.
Read-only: it prints architecture metadata.
COMMAND 02
/usr/libexec/java_home -VAsk macOS to list the Java Development Kits it currently knows about.
Predict whether the new Java 17 JDK will appear and which vendor name its path will contain.
Read-only: it lists registered JDK installations.
COMMAND 03
java --versionAsk the Java runtime selected by this shell to identify its version.
Write which major version and vendor you expect before running it.
Read-only: it prints version information and changes no project file.
COMMAND 04
javac --versionAsk the Java source compiler selected by this shell to identify its version.
Predict whether javac exists and whether its major version matches java.
Read-only: it prints compiler metadata.
COMMAND 05
python3.14 --versionUse the selected Python launcher to identify the interpreter it resolves to.
Write the exact 3.14 patch line you expect and which installation should supply it.
Read-only: it starts the interpreter only long enough to print metadata.
COMMAND 06
git --versionAsk the Git executable selected by this shell for its version.
Predict which Git installation the shell will find if more than one could exist.
Read-only: it does not create a repository or change tracked files.
COMMAND 07
python3.14 -m venv .venvAsk the chosen Python 3.14 interpreter to create an isolated environment in a folder named .venv.
Predict which folder will be created and confirm that your normal user owns the project directory.
Creates or populates .venv inside the current directory; it should not change the system Python.
COMMAND 08
source .venv/bin/activateLoad the virtual environment's activation script into the current shell.
Predict which python command will resolve after activation and what will return when the shell closes.
Changes only the current shell session; it does not install a package or permanently replace Python.
COMMAND 09
python -m pytestRun the pytest module using the Python interpreter currently selected by the shell.
Predict how many tests pytest should discover and whether they should pass before running them.
Executes test code and may create test caches; it should not modify production source files.
COMMAND 10
./mvnw testUse the project-owned Maven Wrapper script to execute Maven's test lifecycle.
Predict which tests should run and whether the wrapper may need to download its pinned Maven distribution the first time.
May download the declared Maven distribution and writes generated build output such as target; it should not edit your source.
YOUR CHOICES
PASS CHECKS
FALLBACK TRIGGER
Use Codespaces when the macOS version, install privileges, local resources, or required architecture is unsupported and the remote quota/connectivity checks pass. Do not use emulation as an invisible default; record it as a deliberate later decision.
SWITCH PATH