Chapter 3 — Programming I
Lesson map
Lesson 03 published. Map, example, EX007.
flowchart TD
N0["Learning outcomes"]
N1["3.1 Why code"]
N2["3.2 Basics"]
N3["3.3 Functions"]
N4["3.4 Synthetic data"]
N5["3.5 Clear output"]
N6["3.6 Standard library"]
N7["3.7 Testing"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX007"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["3.1 Why code"]
N2["3.2 Basics"]
N3["3.3 Functions"]
N4["3.4 Synthetic data"]
N5["3.5 Clear output"]
N6["3.6 Standard library"]
N7["3.7 Testing"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX007"]
[Learning outcomes]
|
v
[3.1 Why code]
|
v
[3.2 Basics]
|
v
[3.3 Functions]
|
v
[3.4 Synthetic data]
|
v
[3.5 Clear output]
|
v
[3.6 Standard library]
|
v
[3.7 Testing]
|
v
[Worked example] --> [Exercise EX007]
Learning outcomes
You will (1) write small Python programs to read and check configuration data; (2) use variables, conditions, loops and functions; (3) test with synthetic data; (4) produce clear output.
3.1 Why code
The cloud team manages hundreds of resources. Reading each one by hand is slow and error-prone; a short program can check every resource the same way every time.
StudyHub alone has dozens of services, each with images, identities and network rules, spread across several accounts. A program that reads exports and applies the same checks to every resource finishes in seconds and gives the same answer each time it runs, which makes changes between runs meaningful. It also leaves a record of exactly what was checked and when.
3.2 Basics
Variables hold values; lists hold many items; dictionaries map names to settings. A loop visits each repository; an if statement checks a setting; print shows the result.
Samuel's first program uses all of these: a list of repository dictionaries, a loop over the list, an if statement checking the anonymous setting, and print for each problem. It is about fifteen lines long, short enough for Tom to review in a few minutes before trusting its output. He also adds comments naming the export each list comes from.
3.3 Functions
A function such as check_repo(repo) returns a list of problems. Functions make programs easier to test and reuse.
Returning a list rather than printing inside the function means the same check can feed a report, a test or a later tool. Samuel's check_repo returns an empty list when a repository has no problems, which makes tests easy to write: an expected-clean repository should return nothing at all. Functions also let him reuse check_repo when the account checks arrive later in the course, with only the input changed.
3.4 Synthetic data
Samuel writes his first programs against a small, made-up list of repositories, so mistakes cannot affect real systems and anyone can rerun them.
His made-up export has four repositories: one public, one private, one with the setting missing and one with an unusual name containing spaces. Each tests a different path through the program. Synthetic data also lets the lab be shared with classmates without revealing anything about Westmere's real accounts. The space in the name caught a formatting bug in his output on the first run.
3.5 Clear output
Each line names the resource and the problem in plain words, so non-programmers can act.
A line such as "records-api: anonymous pull enabled" tells a manager exactly what is wrong and where. Output like "repo[2] anon=True" would need translating. Samuel also prints a final count of repositories checked, so readers know the program looked at all of them and did not stop early. When a repository has several problems, each gets its own line, so nothing is hidden behind the first one. Tom forwarded the output directly to the registry owner without rewriting it.
3.6 Standard library
Labs use only Python's standard library, so they run on any machine and are easy to read.
Avoiding extra packages also removes a supply-chain risk from the labs themselves: nothing needs downloading from a package index to run them. The json, csv, collections and datetime modules cover everything the early labs need. Later chapters introduce outside tools only where the standard library is not enough. Readability matters too: a classmate or assessor can understand every line without first learning a third-party library's interface. Samuel notes in each lab's header which modules it uses.
3.7 Testing
For each check, Samuel writes one example that should pass and one that should fail, and confirms the output.
For the anonymous-pull check, the passing example is a private repository and the failing example is a public one. Samuel added a third case after Dr Jensen's question about missing fields, described in the worked example below. Each test is small enough to understand at a glance, which makes a failure easy to diagnose. Tests live beside the program and run with one command, so anyone changing the check can confirm it still behaves as intended.
Reading exports
The cloud team can export registry settings as JSON. Samuel's program opens the file with the json module, loops over the repositories and prints any problems. He records the export date in the output so readers know how current the result is. Later in the course, the same pattern checks accounts, identities and logs, so this first program becomes a template he reuses many times.
Worked example
Samuel's first program lists repositories with anonymous pull enabled from a synthetic export. Dr Jensen asks what happens if a repository record has no "anonymous" field. Samuel adds a rule to report "setting missing" instead of assuming it is off.
Synthetic case. Data are synthetic.
Errors and limits
Programs that assume missing settings are safe can hide problems.
Exercises
- EX007 — Why programs. Why use programs for configuration checks? Rubric: 3 = consistent, fast, many resources; 2 = partial; 1 = vague; 0 = none.
- EX008 — Function benefit. Why write checks as functions? Rubric: 3 = testable and reusable; 2 = partial; 1 = vague; 0 = none.
- EX009 — Missing field. How does Samuel handle a missing field? Rubric: 3 = report setting missing; 2 = partial; 1 = vague; 0 = none.
Synthesis
Small tested programs make checks reliable.
Continue studying — chapter 03 of 40
← Chapter 02 (draft) · Course chapter index · Chapter 04 (draft) →