public digest · 5 picks
Dashboards as code, watermark removal, and a dbt course repo worth stealing from
This week's batch is a mixed bag on purpose. Two are infrastructure-adjacent tools you'll either adopt wholesale or steal patterns from (Grafonnet's generated-builder approach, CVAT's auto-annotation hooks). One is a CSS kit making a genuinely contrarian bet about how styling should work. One is a course repo that's more honest about its gaps than most production code. And one — the watermark remover — is the kind of project worth reading closely regardless of whether you'd ever run it, because it forces you to think about what 'removing a mark' actually proves.
As always: picked because they're worth your time, not because they're flawless. Read the weaknesses sections before you build on any of these.
// pick 1 of 5
A Jsonnet library that generates Grafana dashboards, panels, and alerting resources from code. The builders are generated from the OpenAPI documents in grafana-foundation-sdk, so the surface follows Grafana's schema rather than a hand-maintained copy. It suits teams that keep dashboards in git and render them in CI.
The core idea here is sound: generate the Jsonnet builder surface from Grafana's own OpenAPI docs instead of hand-maintaining a shadow copy that drifts out of sync with every Grafana release. That alone makes it more trustworthy than most dashboard-as-code libraries, and the coverage is wide — Prometheus, Loki, Tempo, CloudWatch, Azure Monitor, Elasticsearch, Pyroscope query helpers, plus full alerting builders for contact points and notification policies.
The move away from grafonnet-lib's chained builder pattern to plain object construction is also the right call, even if the README's performance claim comes with no numbers attached.
What to know going in: this is explicitly labeled experimental with no SLA, and the install points at @main rather than a pinned tag — a jb update can silently change your generated output. If you find a bug, you can't fix it here; the fix has to land upstream in grafana-foundation-sdk and get regenerated. And if you're using the stock C jsonlint instead of go-jsonnet, the README itself says you're on the slow path.
View on GitHub → Our full take →
// pick 2 of 5
Oat is a classless-ish semantic HTML/CSS/JS UI kit that styles native tags and ARIA attributes directly instead of requiring utility or component classes. It's aimed at developers who want a Bootstrap-style component set (accordions, dialogs, toasts, tabs) without a build step, a framework dependency, or the churn of npm-based component libraries.
Oat's bet is genuinely different from the usual utility-class or component-library approach: style the semantic tag or ARIA attribute directly, no classes required. That forces cleaner markup as a side effect, and the per-component file split backs up the ~10KB claim — you're not paying for parts of the kit you don't import. Zero runtime dependencies and WebComponents instead of a bespoke framework for the interactive bits (tabs, dropdown, toast) also means less supply-chain surface than the typical npm-based component library.
The tag-based styling approach does run into trouble the moment you need two visually distinct buttons on one page without adding classes anyway, which undercuts the pitch a bit once your UI gets past 'demo.' And there's no accessibility testing or ARIA compliance documentation visible despite leaning hard on semantic HTML as the styling mechanism, no visible test suite for the interactive components either.
Heads up: it's pre-v1 with an explicit breaking-changes warning. Fine for a side project, something to actually plan around if you're shipping a product on it.
View on GitHub → Our full take →
// pick 3 of 5
This is a stdlib-only Python HTTP service and thin agent skill that strips provenance marks from files (C2PA manifests, EXIF, XMP, document properties) and runs a rewrite pass over text to weaken statistical watermarks. It is aimed at people cleaning content they own before publishing it. The file-metadata side has the clearest mechanics; the text side depends on a model backend you configure yourself.
The metadata-stripping half of this is solid engineering: stdlib-only Python, external tools like c2patool and exiftool are version-probed rather than trusted blindly, and /capabilities only reports what actually works on your machine. The format routing by magic bytes with an explicit 'unknown, refused' path is the right failure mode, and the README documents a real past bug (DOCX decoded as text and mangled) rather than hiding it in a changelog. The fail-soft detector design — a missing GPU sidecar degrades gracefully instead of blocking the pipeline — is also a good sign of someone who's run this in anger.
The text-watermark side is where you need to slow down. POST /clean on text just 400s unless you bring your own Layer B backend (transformers/roberta-large or an LLM endpoint), so adopting this means adopting a model dependency, not a drop-in tool. And critically: nothing here can verify a removal against real vendor detectors — the README says this plainly, but the vendor coverage table reads more confident than the actual guarantees. SynthID text support was also removed after Google retired API access, so parts of that table are historical record, not current capability.
If you need the heavier image-watermark stack, check licenses before you deploy: the reverse-SynthID scorer is non-commercial-only and noai-watermark ships with no license at all. Both are local-build-only for a reason.
View on GitHub → Our full take →
// pick 4 of 5
CVAT is a self-hosted web app for annotating images, video, and 3D point clouds for computer vision training data — bounding boxes, polygons, masks, keypoints, cuboids. It's for teams that need a real annotation pipeline with task management and review workflows, not a quick labeling script.
This is a real annotation pipeline, not a labeling toy — task management, review workflows, 20+ export formats (COCO, YOLO, Pascal VOC, KITTI, MOT) that slot straight into existing training code without custom converters. The Nuclio-based auto-annotation hooks (SAM, YOLOv7, RetinaNet) mean you can pre-label with your own model rather than clicking every box by hand, and the Python SDK/CLI alongside the REST API means task creation and dataset export can be scripted into CI rather than done by hand every time.
What to know going in: this is a multi-container Docker Compose deployment, and auto-labeling needs a separate Nuclio/nuctl setup plus per-model deployment — there's no single `docker run` path if you want AI assistance. The free self-hosted edition is also deliberately feature-gated: quality control UI, SSO, and the newer SAM 2/3 auto-labeling are Enterprise/Online-only, so budget for that wall if your team needs them. Browser support is Chromium-first — Safari isn't supported, Firefox has caveats — which matters if your annotators don't control their own machines. And it's a large multi-package monorepo, so customizing annotation behavior means learning several codebases, not one.
View on GitHub → Our full take →
// pick 5 of 5
Companion code for a paid dbt course, built as one Airbnb listings project on Snowflake. It suits people new to dbt, or analysts moving into analytics engineering, who want to see models, tests, snapshots, macros and a few Python models working together in one repo.
As companion code for a paid course, this does something most example repos skip: it shows unit tests living next to the models they cover, custom generic tests you can actually reuse, and Python models (moon-phase dimensions, sentiment scoring) that most dbt tutorials never touch because they're harder to get right. The CI workflow names suggest per-PR slim CI with schema teardown, which is more rigor than you'd expect from teaching code.
Heads up before you clone it: everything assumes Snowflake, so moving to Postgres or BigQuery means rewriting config as well as SQL. The top-level README is mostly a course pitch with a referral link and gives no local run instructions — you'll need to dig into _course_resources or the devcontainer config to actually get it running. There are also near-duplicate models sitting side by side (dim_hosts_cleansed and a _v2) with no note on which is canonical, and a second, nearly undocumented Python project (dbt_dagster_project) bolted onto the same repo with no explanation of how — or whether — it relates to the main one.
View on GitHub → Our full take →
If you want this in your inbox instead of hunting for it, the email signup is on the homepage — same picks, same bluntness, once a week.
Get this in your inbox →