/dev/notes/www

Conventional commits - why and how to write meaningful commit messages

Unknown — Mon, 06 Apr 2026 00:00:00 +0000

Open any long-lived project you haven't touched in six months. Run git log --oneline</code>. What do you see?</p>

a1b2c3d fixed stuff
</span>e4f5g6h updates
</span>h7i8j9k wip
</span>l0m1n2o more fixes
</span>p3q4r5s asdf
</span></code></pre>
Congratulations, your git history is a write-only data structure. Nobody - including future you - will ever extract useful information from it.</p>
Now compare that with a project that uses Conventional Commits</a>:</p>
a1b2c3d feat(auth): add OAuth2 PKCE flow for mobile clients
</span>e4f5g6h fix(parser): handle escaped quotes in string literals
</span>h7i8j9k docs: update API reference for v3 endpoints
</span>l0m1n2o refactor(db): extract connection pooling into shared module
</span>p3q4r5s feat!: replace session tokens with JWT
</span></code></pre>
Every line tells you what changed</em>, where it changed</em>, and why it matters</em>. The exclamation mark on the last one screams "breaking change" before you even read the description. That's the point of Conventional Commits - turning your commit history from noise into signal.</p>



Load testing your Rust API - tools and methodology
Unknown — Sun, 05 Apr 2026 00:00:00 +0000
Your Rust API compiles, the tests pass, and a quick curl returns the right JSON. Ship it? Not yet. You have no idea how it behaves when 500 users hit it at the same time. Or 5,000. Or when a steady stream of requests runs for 12 hours straight and that connection pool you configured starts leaking.</p>
Load testing is how you find out before your users do. Rust gives you a strong starting position here - no garbage collector pauses, predictable memory usage, real threads via tokio - but "fast language" does not mean "fast system." A badly tuned database pool, a blocking call on the async runtime, or an O(n^2) serialization path will still bring your API to its knees.</p>
This post covers the practical side: which tools to use, what patterns of load to apply, what numbers to watch, and how to figure out whether your bottleneck is CPU, I/O, or something else entirely.</p>


Logging vs tracing vs metrics - the three pillars of observability
Unknown — Sat, 04 Apr 2026 00:00:00 +0000
Your service is running. Users are making requests. Then someone reports that checkout is slow. Or worse, Slack lights up with "is the API down?" and you're staring at a terminal with no idea what's happening inside your own system.</p>
You check the logs. There are thousands of lines, most useless. You look at your monitoring dashboard - oh wait, you don't have one. You try to figure out which service is causing the slowdown, but you have no way to follow a request across service boundaries.</p>
This is the gap observability fills. Not just "can I see logs" but "can I understand what my system is doing right now, and why it's doing it badly."</p>
There are three fundamental signal types that give you this understanding: logs, metrics, and traces. Each answers a different question. None replaces the others. Getting all three right - and knowing when to use which - is the difference between debugging in minutes and debugging in hours.</p>


Rust Macros 101 - Declarative Macros with macro_rules!
Unknown — Fri, 03 Apr 2026 00:00:00 +0000
Before you reach for proc macros, syn</code>, and quote</code> - there's an entire code generation system built into the language that requires zero dependencies and compiles in milliseconds. Declarative macros with macro_rules!</code> are Rust's pattern-matching code generator. They're not as flexible as proc macros, but they cover a surprising amount of ground, and understanding them is a prerequisite for understanding the rest of the macro ecosystem.</p>
This post covers how macro_rules!</code> actually works - the matching rules, repetitions, hygiene model, and the sharp edges you'll hit. We'll build three practical macros along the way.</p>


Debugging Rust Beyond println!
Unknown — Thu, 02 Apr 2026 00:00:00 +0000
Every Rust developer's first debugger is println!</code>. It works. You sprinkle it around, recompile, squint at the output, add more prints, recompile again. Eventually you find the bug, delete the print statements, and move on. But this gets painful fast - especially with async code, macro-heavy codebases, or bugs that only show up under specific conditions.</p>
Rust ships with a surprisingly good debugging story that most developers never fully explore. This post walks through the tools and techniques that replaced most of my println!</code> usage, organized by the type of problem they solve best.</p>


MCP Audit - building and publishing a security scanner in Rust
Unknown — Wed, 01 Apr 2026 00:00:00 +0000
I've been working with MCP (Model Context Protocol) servers a lot recently - building tools, integrating them with Claude, configuring them for different projects. At some point I realized how easy it is to misconfigure these things. One wrong path and an AI agent has access to your entire filesystem. One hardcoded API key in your config and it's exposed to anyone who sees your dotfiles.</p>
So I built mcp-audit</a> - a CLI tool that scans MCP configurations for security issues.</p>