Example page: every component, once. The plan below is invented.
Move the nightly export to a queue worker
The export runs as one long job and fails silently when it overruns. The plan replaces it with a worker that takes one account at a time and reports each result.
- Status
- PLAN version 2, commit
0000002(example). The versions are listed at the end of the page. - Effort
- estimate: 2 sessions.
- Page
- Worth building only because the plan has decisions. This page is the kit's example.
- Needed from you
- Nothing: the decisions form below is an example.
On this page
What changes
Before
One job exports every account in a single pass. If it overruns, nobody hears about it until a customer asks.
After
A worker takes one account at a time from a queue and writes a result per account. A missing result is visible the same day.
A plan nobody can check is a wish list.
How a page gets built
Template
base.html holds the components, the light and dark modes and the print rules. Colours and font come from the theme chosen in the metadata; your text goes where the placeholder is.
Script
base.js handles the generic parts: tabs from the keyboard, disclosures, steps with previous and next, the answer to copy. Page-specific interactions go in a script inside the content.
Check
check.py opens the page in Chromium at two widths, light and dark, tries every tab, prints, and loads the page without JavaScript.
Does a plan need a page?
The skill writes the plan file every time, but builds a page only if the plan asks the reader for at least one decision or estimates more than one session. Try the four cases.
A typo fix in three files
A mechanical correction, no choices, half an hour.
A migration with two routes
The plan asks the reader which of the two routes to take.
A long job without choices
No open decision, but the estimate is three sessions.
A plan written by an unattended job
The plan asks for a decision, but nobody can answer how the page should look.
The rule, with two sliders
Without JavaScript: build a page if there is at least one decision or more than one estimated session.
The steps
Four steps, from the plan to the cleanup. After step 2 both the old job and the worker run, so stopping there loses nothing.
Step 1. Write the plan
The plan file comes before any change to the export.
Step 2. Add the worker
The worker is deployed next to the old job and handles no account yet.
Step 3. Switch accounts over
Accounts move to the worker a few at a time; the old job skips the ones already moved.
Step 4. Remove the old job
Only after every account has a worker result for the agreed period.
Acceptance test
- pendingEach account has a result row for the night, read from the results table.
- pendingAn account that fails shows up in the report, not only in the logs.
- pending
check.pyprints OK on this page. - laterThe first overrun after the switch is visible the same day; it can only be seen when it happens.
What it costs
All figures are invented. Solid bars are work, grey is tests.
estimate: invented figures, not measured.
| Phase | Sessions | Of which |
|---|---|---|
| Prepare | 0.5 | work 0.5 |
| Build | 1.0 | work 0.7, tests 0.3 |
| Verify | 0.5 | work 0.5 |
| Kit file | What it does |
|---|---|
base.html | Components, themes, masthead and footer with the commit. |
base.js | Tabs, disclosures, steps, answer, print. |
build.py | Assembles the page from content and kit. |
check.py | Source and Chromium checks. |
Risks
A queue that grows faster than the worker drains it shows up as accounts without a result. The report lists them by name.
Each result row is keyed by account and night, so a retry overwrites instead of adding a second row.
During step 3 an account belongs to exactly one of them. A list of moved accounts says which.
Until step 4, moving an account back is one line in the list of moved accounts. After step 4, the old job comes back from version control.
Decisions form (example)
This plan asks for no decisions. The form shows the component with made-up questions: the answer it composes is not meant to be pasted anywhere.