Chapter 29 — Capstone build

Lesson map

Lesson 29 published. Map, example, EX085.

flowchart TD
  N0["Learning outcomes"]
  N1["29.1 Choosing the capstone"]
  N2["29.2 Building it"]
  N3["29.3 Testing"]
  N4["29.4 Security of the pack"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Worked example"]
  EX --> Q["Exercise EX085"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["29.1 Choosing the capstone"]
  N2["29.2 Building it"]
  N3["29.3 Testing"]
  N4["29.4 Security of the pack"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX085"]

[Learning outcomes]
    |
    v
[29.1 Choosing the capstone]
    |
    v
[29.2 Building it]
    |
    v
[29.3 Testing]
    |
    v
[29.4 Security of the pack]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX085]

Learning outcomes

You will (1) build a capstone deliverable; (2) integrate earlier work; (3) test thoroughly.

29.1 Choosing the capstone

For his capstone, Tomás builds a "network health pack" for Ridgeway: a set of scripts and a one-page dashboard that combine the drift report, log arrival check, certificate expiry, alert precision and account review status into a single weekly summary for Gareth and the head teacher. The capstone integrates earlier work into something the school will use every week, which makes it both a learning exercise and a lasting contribution. Gareth agrees the scope and confirms the summary would save him time each week.

29.2 Building it

Tomás uses the standard library only, so the pack runs on the school's existing management server. Each check is a small function with tests. The summary is a simple text and HTML page with green, amber and red statuses and a short explanation for anything amber or red. He keeps the design modular so Gareth can add checks later. All development happens in the lab with synthetic data; only after testing does Gareth install it at school with real data under his control.

29.3 Testing

Tomás writes tests for each check with normal, edge and failure cases: a device that stopped sending logs yesterday, a certificate expiring in 59 days, a configuration with one changed line, and an empty alert file. He also tests the whole pack end to end with a full synthetic week. Two bugs are found: a date comparison off by one day and a crash on an empty file. Both are fixed and tests added so they cannot return unnoticed. The tests run before every release.

29.4 Security of the pack

The pack reads sensitive configuration and log data, so it runs under a read-only account in the management zone, stores no credentials in code, writes output only to a protected folder and logs its own runs. The HTML summary contains no passwords, addresses or student data. Tomás asks a classmate to review the code for security issues. Building secure tooling is part of the capstone's assessment, since a monitoring tool that leaks data would undermine the purpose of the project.

Worked example

The health pack runs five checks weekly; testing finds two bugs, both fixed with new tests.

Synthetic case. The pack is synthetic.

Errors and limits

Tools developed on live data before testing risk errors and data exposure.

Exercises

• EX085 — Capstone purpose. What does the network health pack provide?
  Show marking criteria

  Rubric: 3 = single weekly summary of five checks;; 2 = summary;; 1 = alerts;; 0 = none.
• EX086 — Bugs found. Name the two bugs found in testing.
  Show marking criteria

  Rubric: 3 = off-by-one date comparison, crash on empty file;; 2 = two;; 1 = one;; 0 = none.
• EX087 — Pack security. List two security measures for the pack.
  Show marking criteria

  Rubric: 3 = read-only account, no credentials in code, protected output, no sensitive data;; 2 = two;; 1 = one;; 0 = none.

Synthesis

A tested, secure capstone tool integrates earlier work into lasting value for the school.

Continue studying — chapter 29 of 30

← Chapter 28 (draft) · Course chapter index · Chapter 30 (draft) →