Operations | Monitoring | ITSM | DevOps | Cloud

From Handwritten Mocks to proxymock: The Complete Loop

Handwritten mocks are cheap one at a time. This series built enough of them to show how quickly that stops being true. Nine posts took one package notifier from a function returning "delayed" to a captured response from a real carrier. Along the way, we hand-authored canned successes, failure cases, a spy, a stateful fake, an HTTP server, response fixtures, and contract-drift tests in four languages.

How to automate sending and receiving faxes in IT processes? APIs, webhooks, integrations

It's true that fax in 2026 may seem like a technology out of place in today's DevOps environments. However, it's also true that in many regulated industries - it's still a key part of document workflows. The problem isn't necessarily the communication channel itself, but rather how it's handled. Traditional fax requires devices, phone lines, and manual document processing. API integration allows you to migrate this process to a software environment and connect it with existing systems. Curious? Let's dive in.

Did It Actually Send?

The notifier has returned a message throughout this series, which made testing almost suspiciously easy. Assert on the return value and you are done. Real notifiers do more than build strings: they send them. Once a message goes to an email provider or SMS gateway, the function may return nothing useful. When that change lands, every existing test loses the value it asserted on. This is part 4 of a ten-part series. The code is in Java, Node.js, Go and Python.

Make Failure Boring with Mocks

Every codebase has a failure path nobody has run. Not through laziness, but because reproducing it requires a backend dependency to misbehave on cue. In the package notifier, the carrier must refuse, stall, or return nonsense at the exact moment the test runs. So the retry logic ships unverified and everyone hopes. The seam from post 2 already gives the test control. A seam is a place where you can change what code does without editing that code.

Test Behavior, Not Choreography

The spy from post 4 is a sharp tool. Once a test can record every interaction, it is tempting to assert on all of them. The result looks thorough, but it is usually a transcript rather than a useful specification. This post takes a test written that way, makes a change that no customer could possibly notice, and watches the test fail anyway. This is part 5 of a ten-part series. The code is in Java, Node.js, Go and Python.

CRM API Rate Limits: What Developers Need to Know Before They Build

Every CRM integration starts the same way. You write some code, test it against a sandbox account with a few hundred contacts, and everything works beautifully. Then you push to production, where the account has 50,000 records and three other integrations pulling data at the same time, and suddenly you're drowning in 429 errors.

We Let AI Agents Rewrite a 92M-Message-a-Day Service in Go. Zero Incidents.

Our Results Daemon processes about 92 million messages a day. We recently rewrote it from Node.js to Go, and we let Claude Code write it. We wanted to know whether we could trust an agentic rewrite for a critical, high-throughput production service rather than a prototype. It shipped with zero incidents, a 70% reduction in running pods, and a lighter database load.