DEV Community: Valentin

Cao, take and share easily your toolbox !

Valentin — Mon, 13 Apr 2026 22:17:41 +0000

I started building cao to solve a very personal problem.

Not just “sync my dotfiles”, but rebuild the right local environment on any machine without mixing personal setup, work setup, and sensitive access.

In practice, my local setup is not only ~/.gitconfig or ~/.zshrc.
It is also kubeconfigs, .env files, kubectl wrappers, aliases, small scripts, and config files that need to exist in the right place.

And I kept running into the same awkward trade-off:

one big repo that mixes everything together,
bootstrap scripts that drift over time,
or secrets managed completely separately from the rest of the setup.

So I built cao.

The idea is simple:
instead of having one repo or one source of truth for the whole machine, I split my setup into compartmentalized workspaces.

One personal workspace.
One work workspace.
And potentially one workspace per team, client, or project.

Each workspace can contain:

files,
encrypted secrets,
locally published commands,
wrappers and aliases.

On a new machine, I clone only the workspaces I want to use, run cao plan, then cao apply, and rebuild only the environment I actually need.

What I like about this approach is that the value is not just multi-device sync.
It is context separation.

Even inside a team, not everyone needs the same .env, kubeconfig, or internal commands.
Being able to partition that setup by workspace feels healthier than defaulting to one shared setup for everyone.

I like tools like chezmoi, but I was looking for something slightly different.
chezmoi is great when you want a single source of truth for dotfiles across multiple machines.
With cao, I wanted to compose local state from smaller clonable workspaces that become active locally, with encrypted secrets living next to the rest of the config.

cao is not trying to replace IAM or an enterprise secret manager.
The goal is simpler:
make the local state you are already allowed to have portable, reviewable, and reproducible.

If you already solve this with chezmoi, nix, or custom bootstrap scripts, I’d love to compare approaches.

ValentinAUCLERC / cao

Caisse à Outils

cao

cao is a workspace-first home-state composer for dotfiles, configs, secrets, and user scripts.

It helps you build a clean local setup from small, reviewable workspaces instead of one giant machine-specific repo. Put your personal setup in one workspace, your work setup in another, keep secrets encrypted, and let cao materialize the right files on demand.

Why cao

Workspace-first by design: every workspace present in workspaces/ is active by default.
Friendly CLI for common cases: add files, secrets, and commands without hand-writing manifests.
Safe local workflow: plan, diff, apply, and prune always operate from the workspaces you already have locally.
Secrets live next to the rest of your setup: use sops and age without bolting on a separate system.
Intentionally strict YAML: unknown fields, anchors, merge keys, and custom tags are rejected to keep things explicit and reviewable.

Install

Homebrew:

brew install ValentinAUCLERC/tap/cao

Prebuilt binaries are also…

View on GitHub

DISCLAIMER : This project has been vibecoded. I'm a webdev, i don't know go sadly. But the philosophy and architecture is human !

How would you do to exchange file through REST API ?

Valentin — Thu, 26 Sep 2024 10:20:52 +0000

Hey guys !

I'm looking for good practice from the community.

I'm developping a REST API and I sometime need to upload/download files.
What would be the best practice to you ?

Solution 1 : Sending a link to a ressource accessible publicly and let the client download it ?

Solution 2 : Send file through base64 value ?

Solution 3 : ???

Thank you !

Houston, we've got code quality problem here

Valentin — Tue, 23 Jan 2024 14:35:35 +0000

Let's say you have a rather old project (about fifteen years old), and a few developers working on it.

Today, there are no special practices regarding code quality, at least the bare minimum (code review and PR are still in their infancy, no CI/CD etc.).

This creates technical debt on the one hand, and bugs on the other - in short, a whole host of things that your developers will have to work on rather than features.

If you're the technical director or project manager on this project, at what point do you say to yourself "wow, this is serious, it's becoming the top priority"?

Now let's say I've analyzed the last 1500 commits and 45% of them contain the word "fix" or "bug" or something like that.
Mind you, we're also talking about fixes that haven't been reported by users, some of which are proactive (but still went to prod).
Is this normal in some teams? Let's face it, even in companies with extraordinary code quality, we never reach 0% of commits to fix WHAT HAS REACHED PROD (important). I'd really like to know at what point you say to yourself "we've got a code quality problem and we've got to deal with it NOW".

What metrics do you use to monitor the quality of your code? The % of commits containing "fix" or "bug" well... that's a start but I'd like more tangible things.

You can guess my side and how it is important to me but... how to convince my boss ? Obviously answer like "as long as there is one bug per year it's the top priority of the whole team to increase code quality", well it won't help, let's stay in real world with real issues :p)