An 8-module intensive training program for mid-level Java engineers. Java Booster builds the practical skills that separate competent Java developers from high-performing ones: agile discipline, safe integration patterns, test-driven development, CI/CD, reading legacy code under pressure, AI-assisted refactoring, and production readiness.
Each module combines an interactive SCORM e-learning experience with hands-on Java exercises.
java-booster/
├── SCORM/ # Packaged SCORM 1.2 modules for LMS delivery
│ ├── HTML Previews/ # Standalone HTML previews (no LMS required)
│ ├── java-booster-intro-scorm.zip
│ ├── scorm_module1_scrum_simulation.zip
│ ├── scorm_module2_di_boilerplate.zip
│ ├── scorm_module3_tdd_fundamentals.zip
│ ├── scorm_module4_cicd_pipeline.zip
│ ├── scorm_module5_reading_complex_code.zip
│ ├── scorm_module6_booby_trap_simulation.zip
│ ├── scorm_module7_refactoring_with_ai.zip
│ ├── scorm_module8_production_release_retro.zip
│ └── style-guide.md # SCORM design system & component guide
├── module-01/ # Design artifacts: flowcharts, pseudocode
├── module-02/ # Solution: TransactionValidationService
├── module-03/ # Solution: TDD exercise
├── module-04/ # Maven pom.xml scaffold
├── module-05/ # Starter: LegacyPaymentProcessor monolith
├── module-06/ # Starter + Solution: Booby Trap Simulation
├── module-07/ # Starter: AI Refactor Sprint
└── module-08/ # Chaos simulation Java sources
SCORM: java-booster-intro-scorm.zip
Preview: HTML Previews/course-intro.html
Orients engineers to the program structure, learning philosophy, and what to expect across all 8 modules. Sets expectations around AI usage, production thinking, and professional discipline.
SCORM: scorm_module1_scrum_simulation.zip
Source: module-01/
An interactive sprint simulation. Engineers work through a realistic backlog, make scope decisions under time pressure, and learn to estimate and protect sprint integrity. Includes a flowchart and pseudocode for a Java Transaction Validation Service as the sprint deliverable.
Key artifacts:
flowchart-java-transaction-validation-service.svg— system design diagrampsuedo-code-java-transaction-validation-service.txt— initial pseudocodepsuedo-code-revised-java-transaction-validation-service.txt— refined design
SCORM: scorm_module2_di_boilerplate.zip
Source: module-02/
Covers the mechanics and rationale of dependency injection in Java. Engineers implement a TransactionValidator from pseudocode, wiring components using constructor injection, interface segregation, and Spring-compatible patterns.
Key artifacts:
psuedo-code-TransactionValidator.txt— specificationsolution-transaction-validation-service/— Maven project with full solution
SCORM: scorm_module3_tdd_fundamentals.zip
Source: module-03/solution/
Introduces the red-green-refactor cycle through a structured exercise. Engineers write tests first against the TransactionValidator interface, then implement to pass. Reinforces testing as a design tool, not just a safety net.
SCORM: scorm_module4_cicd_pipeline.zip
Source: module-04/pom.xml
Covers continuous integration and deployment principles for Java projects. Walks through pipeline stages, Maven lifecycle integration, build verification, and the professional discipline of never shipping broken builds.
SCORM: scorm_module5_reading_complex_code.zip
Source: module-05/legacy-payment-processor/
Preview: HTML Previews/module-05-preview.html
Places engineers inside a realistic legacy monolith and trains systematic code reading under pressure. The LegacyPaymentProcessor is intentionally complex — hybrid responsibilities, tight coupling, hidden side effects, and partial documentation.
The challenge: add a new validation rule without breaking existing behavior.
What you deliver:
- A written summary of class responsibilities
- A dependency map
- A list of high-risk modification points
- A safe modification strategy
- Identified test coverage gaps
Engineers do not implement the feature in this module. Understanding precedes modification.
Key classes:
LegacyPaymentProcessor— main monolithic orchestratorFraudEngine— risk scoringPaymentGatewayClient— external payment simulationTransactionRepository— persistence layerAuditLogger— audit trail
SCORM: scorm_module6_booby_trap_simulation.zip
Source: module-06/
Preview: HTML Previews/module-06-preview.html
A high-pressure integration exercise built on the legacy payment processor from Module 5. Engineers must introduce a new TransactionValidator into the existing pipeline without triggering the embedded traps: static state bugs, execution order violations, shared mutable context, and runtime failures that don't appear at compile time.
The lesson: Code compiles. Tests may pass. Runtime fails.
Source structure:
starter-booby-trap-simulation/— the broken integration starting pointsolution-booby-trap-simulation/— reference solution
Integration risks embedded in the codebase:
- Static invocation counters (rate limiting)
- Order-dependent currency normalization
- Shared mutable audit context
- Feature flag execution branches
- Non-null return assumptions
SCORM: scorm_module7_refactoring_with_ai.zip
Source: module-07/starter-ai-refractor-sprint/
Preview: HTML Previews/module-07-preview.html
A structured AI-assisted refactoring sprint on the legacy payment processor. Engineers learn to use AI tools to accelerate code comprehension and refactoring while maintaining professional discipline — verifying AI output, preserving behavior, and writing tests before changing logic.
Covers:
- When to use AI vs. when to think independently
- Prompting strategies for code analysis
- Verification discipline: never trust, always confirm
- Before/after refactoring patterns in Java
- Extracting method responsibilities, reducing coupling
Source: starter-ai-refractor-sprint/ — the legacy codebase in its pre-refactor state, ready for an AI-assisted sprint.
SCORM: scorm_module8_production_release_retro.zip
Source: module-08/
Preview: HTML Previews/module-08-preview.html
The capstone module. Engineers finalize the system for production release, survive a chaos engineering simulation, and conduct a structured retrospective on AI's role in the development lifecycle.
Covers:
- Production readiness checklist
- Operational stability validation
- Chaos engineering: concurrent load, fault injection, recovery validation
- Engineering retrospective frameworks
- Critical reflection on AI-assisted development
Chaos simulation sources:
ChaosRunner.java— executes 500 concurrent transactions across 25 threadsChaosInputFactory.java— generates randomized, edge-case payment requestsChaosContext.java— provides the shared processor under test
Pass criteria: The system must handle the chaos simulation without data corruption, missed transactions, or silent failures.
All modules are packaged as SCORM 1.2 compliant zip files for upload to any standard LMS (Moodle, Canvas, Cornerstone, etc.).
Mastery score: 75% on all module assessments.
Tracked data per module:
cmi.core.lesson_status— not attempted / incomplete / passed / failedcmi.core.score.raw— 0–100cmi.core.session_time— time spent on modulecmi.core.lesson_location— last screen visitedcmi.suspend_data— full progress state (screen, quiz answers)cmi.interactions— individual quiz responses
Each module includes a localStorage fallback so progress persists even when previewed outside an LMS.
Open any file from SCORM/HTML Previews/ directly in a browser. All interactivity, quizzes, and progress tracking work without an LMS connection.
See SCORM/style-guide.md for the full SCORM design system. Key decisions:
- Theme: Dark-first with
data-theme="dark" - Fonts: General Sans (body), Manrope (UI labels), JetBrains Mono (code + headers)
- Minimum font size: 16px (12pt)
- Per-module accent colors: M5 amber
#f5a623· M6 red#e85565· M7 emerald#10b981· M8 indigo#818cf8
For the Java exercises, you will need:
- Java 11+
- Maven 3.6+
- An IDE with Java support (IntelliJ IDEA recommended)
# Build any module
cd module-XX/[project-directory]
mvn clean verify
# Run tests
mvn testJava Booster is built around three convictions.
Understanding precedes modification. Before changing code, map it. Before merging, read it. Before deploying, verify it.
AI accelerates; engineers decide. AI tools are part of the professional toolkit. But output must be verified, assumptions must be tested, and the engineer remains accountable for every line that ships.
Production is the standard. Every exercise simulates the conditions of real production systems: legacy constraints, hidden side effects, time pressure, and incomplete information. Clean code in isolation is easy. Safe changes in production systems require discipline.