◇ OpenCyber Academy
Engineering · Chapter 4 · English

Chapter 4 — Programming I

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 4 — Programming I

Lesson map

Lesson 04 published. Map, example, EX010.

flowchart TD
  N0["Learning outcomes"]
  N1["4.1 Why program"]
  N2["4.2 Variables and types"]
  N3["4.3 Functions"]
  N4["4.4 Testing with known answers"]
  N5["4.5 Standard library only"]
  N6["Reading code before running"]
  N7["Linking to the project"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX010"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["4.1 Why program"]
  N2["4.2 Variables and types"]
  N3["4.3 Functions"]
  N4["4.4 Testing with known answers"]
  N5["4.5 Standard library only"]
  N6["Reading code before running"]
  N7["Linking to the project"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX010"]

[Learning outcomes]
    |
    v
[4.1 Why program]
    |
    v
[4.2 Variables and types]
    |
    v
[4.3 Functions]
    |
    v
[4.4 Testing with known answers]
    |
    v
[4.5 Standard library only]
    |
    v
[Reading code before running]
    |
    v
[Linking to the project]
    |
    v
[Worked example] --> [Exercise EX010]

Learning outcomes

You will (1) write small Python programs that read records and check conditions; (2) structure code with functions; (3) test with known answers.

4.1 Why program

Fernhill's 300 PCs cannot be checked by hand each day. Small programs that read configuration records and report problems make checks repeatable.

Before the project, Marta checked a few PCs per branch each month and hoped the rest were similar. A program can check every PC every day in seconds and print only the ones that need attention. The program does not replace her judgment; it tells her where to look. Running the same check every day also produces a history, so Marta can see whether problems are rising or falling.

4.2 Variables and types

Settings come as text, numbers and true-or-false values. A program must compare like with like: "15" as text is not the number 15.

Mateo met this exact problem in the worked example, where minutes stored as text made every PC appear to fail. He now converts each value to the expected type as soon as it is read, and treats a value that cannot be converted as an error to report. A setting recorded as yes in one export and true in another is normalised the same way, so later code never has to guess.

4.3 Functions

A function such as check(pc, requirements) returns a list of gaps. Writing it once and calling it for every PC avoids copying code.

When a requirement changes, Mateo edits the function in one place, and every PC is checked against the new rule on the next run. Each gap the function returns names the setting, the expected value and the actual value, so Marta can see what is wrong without reading the code. Keeping the function free of side effects means it can be tested with invented PCs and no network access.

4.4 Testing with known answers

Before running on real data, Mateo tests his function on two synthetic PCs: one that meets every requirement and one that fails exactly two. If the output matches, he trusts the function more.

He then adds cases for unusual inputs: a PC record with a missing setting, a value of the wrong type and an empty record. Each should produce a clear error rather than a pass. Tests with known answers catch mistakes that reading the code misses, and they keep catching them when the function is changed later.

4.5 Standard library only

The course labs use only Python's standard library, so they run on any machine and introduce no unreviewed code.

Avoiding extra packages also makes the labs easier to review. Anyone checking a script can see everything it does, because the only code it uses ships with Python itself. For Fernhill's own checks Mateo follows the same rule, since a library downloaded from the internet would need its own security review before running on the library's network. It also keeps the labs small.

Reading code before running

Mateo reads every script before running it, including examples from the course. He asks what the script reads, what it writes and whether it changes anything. All course labs only read synthetic records and print results. This habit protects real systems from mistakes and from code that does more than it claims.

He also learns to keep output short and ordered: counts first, details second.

Linking to the project

Mateo's first useful program reads a list of synthetic PC records and prints those whose USB storage setting is enabled. It is short, but it already answers a real question that Marta used to answer by walking round branches. Later chapters extend it into the hardening and restore checks.

Worked example

Mateo's first check reports every PC as failing auto-logoff. He discovers that the records store minutes as text. Converting to numbers fixes it, and he adds a test case with text input.

Synthetic case. Synthetic.

Errors and limits

Programs fail silently when data types differ; test with realistic inputs.

Exercises

Synthesis

Small, tested programs make checks repeatable.

Continue studying — chapter 04 of 50

← Chapter 03 (draft) · Course chapter index · Chapter 05 (draft) →