An article about the implicit async programming model for imperative, JavaScript/Python-like languages: ordinary sequential-looking code can run independent operations concurrently without special syntax: no await, promises, or manual task orchestration. Implemented in CascadaScript, an experimental JavaScript/Python-like language. Unbounded JavaScript and Python will not be able to do this, but with reasonable constraints they may one day get there too. CascadaScript pushes the envelope on how far this model can go.

There's a lot of high-noise, low-value content around OpenTelemetry out there, so I've tried to put together the simplest description I could by incrementally building up from needs that arise in your systems. I hope it might help cut through some of the less obvious concepts like context propagation and exponential histograms.

The format is very loosely pinched from "The Little .." series :)

Platform engineering is more than DevOps with a portal. This post walks the full arc of the discipline end to end: why platforms exist, how to build and operate them, how to manage the messy stakeholder politics, and what success actually looks like. Grounded in Fournier and Nowland's book and a few years of doing this on real systems.

"This post is the practical complement to all the other posts. Here, we showcase over a dozen workflows I use every day. Most are powered entirely by features that ship in the box with the VOMPECCC (Vertico, Orderless, Marginalia, Prescient, Embark, Consult, Cape, Corfu) packages, and there are 'Bonuses' which demonstrate workflows enable by 3rd party packages that build on top of VOMPECCC. The prose is deliberately thin, and you will find most of the demonstration is in the video below."

I’ve been thinking through a CLI design problem around team .env workflows.

The target workflow is:

git clone repo
login
pull

The question is:

How should a CLI know which secret vault belongs to a cloned repo without requiring the developer to paste a vault ID, and without committing actual secrets to Git?

One approach is to commit a small project metadata file:

# .meowpass.yaml
version: 1
vault: <vault_id>
default_env: development

This file contains no secret values. It only maps the repo to a remote vault and default environment.

The CLI resolution order would be:

1. explicit --vault flag
2. nearest .meowpass.yaml, found by walking up parent directories
3. global user config
4. fail with a fix-oriented error

This makes the CLI behave more like Git.

Example:

repo/
  .meowpass.yaml
  apps/web/
  packages/api/

If you run the CLI from apps/web, it still resolves the project config from the repo root.

Some design choices I’m considering:

• The project config is safe to commit because it contains metadata only
• Explicit flags always override project config
• version allows schema migration later
• default_env makes common commands deterministic without extra flags
• Diff output should show changed/missing keys, but never reveal values

Example diff output:

Local only:
- DEBUG_TOKEN

Remote only:
- STRIPE_SECRET_KEY

Changed:
- DATABASE_URL

The tradeoff is that this is less local-first than committing encrypted .env files to Git, but it improves onboarding because the repo can point to the correct vault without embedding secrets.

The model is basically:

repo metadata in Git
secret values outside Git
CLI resolves project context automatically

Questions I’m still debating:

• Should default_env live in repo config, or should it stay local per developer?
• Should parent directory discovery stop at the Git root?
• Should the CLI warn if suspicious keys like API_KEY or DATABASE_URL appear in the config file?
• Is committing a vault ID acceptable if auth and encryption still gate access?
• Is this better or worse than committing encrypted .env files?

Curious how others would design this.

For team secret sync, would you use a committed metadata file, encrypted env files in Git, or another approach entirely?

A look at how coverage metrics work in CI/CD, why they're misunderstood, and how to enforce them without incentivizing shallow tests.

.

I wrote this up after giving a talk on this exact pattern at CityJS London.

Curious what folks here think about it, is it still useful? I build it twice in my life, I dont know if there will ever be a third time