Course outline

01 · Getting Started6/6

02 · Variables, Types & Control Flow6/6

03 · Functions & Composite Types6/6

04 · Methods, Interfaces & Errors6/6

05 · Packages, Modules & Concurrency Intro6/6

06 · Your First Real Program6/6

07 · Testing & Debugging in Go6/6

08 · Capstone — Ship a Real Tool7/7

09 · Generics6/6

10 · Concurrency in Practice6/6

11 · Language Depth II6/6

12 · Standard Library Toolkit6/6

13 · Building Web Services6/6

14 · Working with Databases6/6

15 · Advanced Runtime & Tooling6/6

16 · Building a Terminal Dashboard with Bubble Tea5/5

17 · Closing the Loop2/2

Stage 1 · Code

Building a Terminal Dashboard with Bubble Tea

Demo Data, Snapshot Replay, and Shipping It

Give the dashboard two ways to get its numbers — a simulated feed and a real snapshot file — then finish the project the way tasker finished: a README, a release, and proper credit.

9 min readThe Complete Go EngineerCode

One Interface, Two Sources

The spec from earlier promised two ways to run burnrate: demo, for an instant self-contained dashboard, and run --file, for replaying real per-minute counts from a JSON snapshot. Rather than branching all through internal/tui on "which mode am I in," both modes satisfy one small interface, and the model never needs to know which one it's talking to.

Gointernal/data/source.go-—-the-source-interface.go

28 linesLn 1, Col 1Go

Four small methods are enough to drive every calculation in `internal/slo` and every line in `View`. This is the same interface-first instinct from earlier in the course — depend on behavior, not on a concrete struct — applied to a data source instead of an `io.Writer` or an HTTP handler.

The Demo Feed

The demo source exists so that anyone can see burnrate working in ten seconds, with zero setup — no real service, no metrics backend, nothing to configure. It simulates realistic traffic on each Tick(), with an occasional deliberate spike so the "CRITICAL" badge from the styling lesson actually gets exercised.

Gointernal/data/source.go-—-simulated-traffic-(abridged).go

30 linesLn 1, Col 1Go

Two states, one healthy and one incident, with a small random chance of transitioning between them each tick. That's enough to make the demo feel alive — most of the time it sits calmly in the OK range, and every so often the fast-burn window trips, exactly the scenario burnrate was built to catch.

The Snapshot Source

The second mode is the one that makes burnrate genuinely useful beyond a demo: replaying a fixed JSON file of real per-minute request/error counts, exported from wherever your actual metrics live.

Gointernal/data/source.go-—-loading-a-snapshot-file.go

23 linesLn 1, Col 1Go

This is the same "read file, unmarshal JSON, wrap it in a domain type, return a clean error on failure" pattern from the standard-library modules earlier in the course. A `snapshotFile` never leaks into `internal/tui` — it is converted into the same `Source` interface the demo feed satisfies, so the dashboard code doesn't change at all between modes.

One interface, and the model never knows the difference

Look back at tui.New(service, target, src, live) from the previous lesson: src is typed as data.Source, not *demoSource or *fileSource. That is the entire payoff of programming to an interface — the exact same Model, Update, and View code renders both a simulated feed and a real, replayed incident without a single if demo { ... } else { ... } branch inside the UI layer.

Shipping It — and Crediting Charm

Everything you already know from the capstone module about finishing a tool applies here unchanged: cross-compile releases for the platforms people actually use, write a README a stranger can follow, and tag a version. Reuse the exact Makefile pattern and cross-compile approach from module 8's cross-compile-releases lesson — the process doesn't change just because this tool happens to be interactive.

What is new here is the credit. Bubble Tea, Lip Gloss, and Bubbles are open-source libraries built by Charm, and this project would not exist in this form without them. burnrate's own --help output says so directly, and its README does too — not as a formality, but because giving credit to the tools and teams that make your work possible is simply the right thing to do, and it costs you nothing.

burnrate --help — credit lives in the tool itself

burnrate — a multi-window, multi-burn-rate SLO dashboard for your terminal

Usage:
  burnrate demo [--service NAME] [--slo 99.9]
      Run an instant live dashboard fed by simulated traffic. No setup
      required — this is the fastest way to see how it works.

  burnrate run --file snapshot.json [--service NAME] [--slo 99.9]
      Render a fixed snapshot of real (or exported) per-minute request and
      error counts. See testdata/sample.json for the expected file shape.

  burnrate help
      Show this message.

Built with Bubble Tea and Lip Gloss by Charm (https://charm.sh).

This is the actual usage text burnrate prints. The last line is not decoration — it is an honest acknowledgment that this entire project stands on work Charm has open-sourced for the whole Go community to build on.

Cross-compile for linux/amd64, darwin/arm64, and windows/amd64, exactly as in the capstone's release lesson.
Write a README covering both modes (demo and run --file), the keybindings (q to quit, space to pause), and a short explanation of the burn-rate concept for anyone unfamiliar with it.
Credit Bubble Tea, Lip Gloss, and Bubbles by name, with a link to charm.sh, in both the README and the program's own help text.
Tag a release the same way tasker did — git tag v0.1.0, then let the Makefile's release target build every platform's binary from that tag.

That's the whole project: a pure, tested math package underneath, a clean data-source interface in the middle, and a Bubble Tea + Lip Gloss dashboard on top — built with the same scoping, testing, and shipping discipline as tasker, applied to a genuinely different, genuinely useful kind of tool.

Mark this lesson complete to store local progress and unlock a cleaner resume path the next time you visit.