DEV Community: Nickwang · Build Notes

A balanced rota can still fail: a two-person scheduling example

Nickwang · Build Notes — Sat, 14 Nov 2026 04:57:20 +0000

A rota can give everyone the same number of assignments and still leave a shift uncovered. The problem often starts with a reasonable shortcut: assign the next shift to the person with the lowest current workload.

Here is a small, fictional example that exposes the limitation.

Person	Morning	Afternoon	Maximum assignments
Ada	Available	Available	1
Ben	Available	Unavailable	1

Both shifts need one person. At the start, Ada and Ben have equal workloads. If a greedy tie-break assigns Ada to the morning, the afternoon is left without an eligible person: Ben is unavailable, and Ada has reached her limit.

Yet a complete schedule exists: Ben in the morning, Ada in the afternoon.

Separate constraints from preferences

Availability and maximum assignments are hard constraints. A schedule must satisfy them before its workload balance is useful.

For a slightly larger example, the checks might be:

Every shift has its required number of people.
Every assigned person is available for that shift.
Nobody exceeds their own assignment limit.
One person cannot cover two assignments in the same time group.

After those checks, compare feasible schedules using an explicit objective. One simple choice is to minimize the difference between the largest and smallest assignment counts, then use the sum of squared counts as a tie-break.

That is a definition of fairness for this model. It does not account for shift difficulty or individual preferences unless those are represented in the inputs.

A complete search you can inspect

For the two-person example, checking all combinations is small enough to write directly. This standalone JavaScript runs in Node.js and uses no packages:

const people = [
  { name: "Ada", available: ["morning", "afternoon"], max: 1 },
  { name: "Ben", available: ["morning"], max: 1 },
];

const feasible = [];
for (const morning of people) {
  for (const afternoon of people) {
    const assignments = [morning, afternoon];
    const available = morning.available.includes("morning") &&
      afternoon.available.includes("afternoon");
    const withinLimits = people.every(person =>
      assignments.filter(p => p === person).length <= person.max
    );
    if (available && withinLimits) {
      feasible.push({ morning: morning.name, afternoon: afternoon.name });
    }
  }
}
console.log(feasible);
// [{ morning: "Ben", afternoon: "Ada" }]

This example checks availability and assignment limits. It has four combinations, so completing the search is easy. Larger instances need better ordering and pruning, and they still need an explicit stopping rule.

A search limit changes what the result means

A useful scheduling interface should distinguish these outcomes:

Outcome	What the result establishes
Optimal	A feasible schedule meets a proven lower bound or a complete search established the best objective.
Feasible, search limit reached	The shown schedule satisfies the modeled constraints; a better schedule might exist.
Infeasible	A constraint check or a complete search established that no schedule satisfies the modeled constraints.
Unknown, search limit reached	The search stopped without finding a feasible schedule. This does not establish infeasibility.

The final two states are easy to confuse in a UI. A time limit is a statement about how much searching happened, not a proof about every possible schedule.

The same distinction is useful in packing, timetabling and small resource-allocation tools.

Keep the inputs with the result

An exported schedule is easier to review when it travels with its assumptions. Keep the availability table, individual limits, time groups and solver status alongside the assignments. If an input changes, recompute the result before sharing it.

For an initial check, use a tiny example where you already know the answer. Then try an impossible case, such as two required assignments with a total capacity of one. Finally, test an invalid input and make sure an old successful result is not left looking current.

I used these checks while preparing Fair Schedule Planner, a small offline browser tool with editable availability, personal limits, shared time groups, CSV results and a workbook for recording assumptions. The supplied examples are fictional. The interface reports the search outcomes above.

If you want the ready-made interface and worksheets, the Fair Schedule Planner download is available on Payhip for $12 as a one-time purchase. A free PDF preview is available on the product page. The JavaScript example in this article is independent and free to use.

This article and the product were prepared with AI assistance. The example output was checked, and the product's documented functional checks cover availability, conflicting assignments, impossible inputs and exported result data.

Before asking AI to build an app, write five answers and one acceptance check

Nickwang · Build Notes — Sat, 14 Nov 2026 01:19:50 +0000

A five-line brief gives an AI-assisted prototype a concrete starting point: one user, one trigger and an output you can inspect.

Consider a fictional product idea called LessonWrap, intended to help independent tutors write a weekly lesson report. Start by deciding what one completed workflow would look like.

Replace it with five concrete answers:

User: an independent tutor who already has lesson notes.
Trigger: writing the weekly report after the final Friday lesson.
Current workaround: copy notes into a document and manually check unfinished follow-ups.
Observable output: an editable report and a visible list of items still to do.
First-version boundary: no real student accounts, billing or automatic messages.

This brief creates a useful next question: what would count as the prototype working?

Use synthetic records to define the first checks. Empty input should produce a clear message. A malformed record should identify the field that needs correcting. A valid fictional lesson should produce a report that can still be edited. A download should preserve the words the user entered, including symbols and non-English text. The tool should explain what happens to edits when the page closes.

Write each check as an input and a result you can inspect. This gives you a way to judge the next implementation pass.

Try this prompt with your own brief:

Convert this brief into six acceptance checks. For each check, provide a synthetic input, an observable expected result, and the boundary of what the check proves. Keep unknowns as unknowns. Do not invent user validation, performance figures or integrations.

Brief: [paste your five answers here]

The next pass should look for missing decisions. Does the prototype send data to a server? Can a user inspect the generated output before it leaves the page? Are the examples fictional? Does export create a backup that import can actually restore? These questions matter more than adding another screen to the demo.

A compact acceptance record could look like this:

{
  "case": "backup_round_trip",
  "input": "a fictional lesson report with an edited follow-up",
  "action": "export a backup, clear the form, import that backup",
  "expected": "the edited follow-up returns unchanged",
  "proves": "the backup preserves the tested fields",
  "does_not_prove": "real classroom adoption or production security"
}

Once you have a small working slice, record what you checked and what remains untested. Then use feedback to change the brief. You do not need to manufacture a market survey to justify the next prototype.

I prepared AI MVP Blueprint as a downloadable workbench for this process. It includes six editable worksheets, twelve prompts, English and Chinese guides, CSV files and the clearly fictional LessonWrap example. The desktop browser tool works offline and creates text and JSON exports. A visible download link lets you save the file after inspecting its content. Session edits need an explicit backup before closing.

The planning exercise above is free to use. The ready-made workbook is a paid product at $9: https://nickster2735.gumroad.com/l/ai-mvp-blueprint

It is a planning toolkit, with no AI account, API credits, hosting or custom development included. The text and toolkit were prepared with AI assistance, and the examples are fictional.

Rendering vertical video one frame at a time: three runnable JavaScript examples

Nickwang · Build Notes — Thu, 12 Nov 2026 10:01:54 +0000

The public AI Short Video Method Library now includes three runnable MIT examples: GSAP cards and typography, Vega/D3 charts, and Mermaid diagrams. Each scene can be moved to a requested frame, captured in a browser, and encoded as a vertical video.

This article was prepared with an AI assistant from the repository code and the recorded server runs. Nickwang Studio maintains the repository and sells a separate complete edition with 25 method projects, guides and demonstration videos.

Run the public examples

Install the Node.js version specified in the README and make sure FFmpeg is available on your command line. Then run:

git clone https://github.com/Nickwang684/ai-short-video-method-library.git
cd ai-short-video-method-library
npm run setup
npm run render:gsap
npm run render:data
npm run render:diagram

The setup command installs the JavaScript dependencies and Chromium. On Linux, a browser launch error may identify missing system libraries that need to be installed for that environment.

The output files are output/m01.mp4, output/m10.mp4 and output/m16.mp4. The command npm run render:all runs all three.

Example directory	What to inspect
`examples/m01-gsap-html`	A paused GSAP timeline, staggered cards and SVG animation
`examples/m10-data-viz`	Vega/D3 chart state at a requested frame
`examples/m16-diagram-as-code`	Mermaid SVG with staged nodes and connections
`examples/_shared`	Local file serving, screenshot capture and video encoding

Separate scene time from capture time

The shared capture script expects a scene to expose SCENE_META and seekFrame(frame). A simplified scene interface looks like this; the scene must create its own timeline:

window.SCENE_META = {
  width: 1080,
  height: 1920,
  fps: 30,
  durationInFrames: 270,
};
window.seekFrame = frame => timeline.time(frame / 30);

At 30 fps, frame 90 represents three seconds of scene time. Capturing that frame may take longer than 1/30 of a second. The requested scene state determines the image; the encoding input rate determines its playback timing.

The actual capture loop waits for the scene's seek function and two browser drawing callbacks before taking each screenshot:

for (let frame = 0; frame < meta.durationInFrames; frame++) {
  await page.evaluate(async (current) => {
    await window.seekFrame(current);
    await new Promise((resolve) =>
      requestAnimationFrame(() => requestAnimationFrame(resolve))
    );
  }, frame);

  await write(ffmpeg.stdin, await page.screenshot(shotOptions));
}

The write helper handles pipe backpressure so screenshots do not keep accumulating while FFmpeg is still consuming earlier input. A scene can return a Promise from seekFrame when it needs to complete an asynchronous update.

The drawing callbacks do not establish that fonts, images, network data or WebGL resources have loaded. Those dependencies need their own readiness checks. Repeatability also depends on input data, assets, fonts and renderer versions. A live browser walkthrough needs separate capture checks because the external page can change.

What the recorded runs produced

On November 12, 2026, the project server ran the documented commands against commit 8be3897061983b5f55e80b88b597528def9d4aa5. FFprobe reported:

Output	Resolution	Frame rate	Frames	Duration
`m01.mp4`	1080×1920	30 fps	270	9 seconds
`m10.mp4`	1080×1920	30 fps	300	10 seconds
`m16.mp4`	1080×1920	30 fps	300	10 seconds

The capture script uses FFmpeg's image2pipe input and libx264, with scale=in_range=full:out_range=tv,format=yuv420p in its output filter. You can inspect your own output with:

ffprobe -v error -select_streams v:0 -count_frames \
  -show_entries stream=width,height,r_frame_rate,nb_read_frames:format=duration \
  -of json output/m01.mp4

If the frame count differs, check the scene metadata and capture log. For a size mismatch, check the viewport. For a different animation state, inspect the scene inputs, random seeds, fonts and dependency versions. Pixel comparisons across different machines would be a separate experiment; the recorded checks above establish dimensions, frame count and duration for these three server runs.

Source: AI Short Video Method Library on GitHub.

Five complete copies for developer trials

There are five free complete-edition copies for developers who want to try one method and report the actual result. Pick a technique that fits a real task, and check its README for required tools or services. The complete edition contains the 25 method projects, guides and rendered demonstrations; the public repository contains the three runnable examples described above and a method catalog.

To join, comment with your operating system, intended use and the method you want to try. Then claim a complete copy with the 100% discount. These five copies are shared across all recruitment posts. The code is limited to new customers of the store.

After trying it, reply here or open a repository issue with:

The method, OS, tool versions and exact command you ran.
Whether it produced the expected output, including dimensions and duration when available.
The first unclear or failed step, with the relevant error and README section.
One useful part and the first change you would make.

An unsuccessful run is useful feedback. A positive review is not required. Reports will be retained in their original form and linked to any resulting fixes.

Update note, November 13, 2026: this revision corrects the earlier claim that all 25 methods were open-sourced and replaces unsupported reproducibility claims with the recorded checks above.