rusoblanco

We tell ourselves we’re prepared. We have backups. We have redundancies. Software engineers pride themselves on avoiding Single Points of Failure (SPOF).

But often, when chaos actually strikes (a server outage, a natural disaster, or just a really bad Monday), we find our backup plans were little more than lists of things we hoped would work.

A framework exists to cure this optimism bias: PACE planning.

It originated in the military, specifically for Special Ops comms plans. I’ve found it to be an incredibly potent tool for engineering resilience and personal peace of mind. It transforms “trying to figure it out on the fly” into a structured algorithm for continuity.

Simply writing a PACE plan down on a napkin isn’t enough, though. If you don’t understand your dependencies, even a four-layer backup plan can collapse in seconds.

Read more...

A common challenge in application development is the entanglement of business rules with external operations (like database writes or API calls). When these mix, testing becomes difficult, and error handling often degrades into a web of try/except blocks that hide the actual flow of logic.

This post explores a practical pattern to solve these specific problems. By treating program outcomes as data rather than exceptions, and by isolating external side effects from core logic, we can create code that is easier to read, safer to refactor, and simpler to test.

Read more...

Software engineering is often described as a constant struggle against complexity. As our systems grow larger, the number of possible implementations states within the program explodes. This turns our code into a chaotic landscape where bugs can easily hide in the corners we forgot to check. To fight this, we usually rely on external tools like linters, detailed documentation, or exhaustive test suites.

However, there is a deeper principle we can use that is built right into the code itself: the mathematics of data.

Regardless of the language you are using, whether it is Python, Rust, or Typescript, thinking in terms of Algebraic Data Types (ADTs) allows us to measure and tame this chaos. The key insight is simple but powerful: To build better programs, we should design functions whose type has the smallest cardinality possible.

Read more...

In computer science, the Futamura Projections are a legendary concept connecting interpreters, compilers, and partial evaluators. They act as a bridge between “running code” and “compiling code.”. Original 1983 paper in English.

But what happens if we treat Natural Language as our programming code, and an LLM as our processor?

Can we “compile” an English instruction? Can we build a “Compiler Generator” out of pure prose?

Read more...

Introduction

Property-based testing is a leap forward from traditional example-based tests. With tools like pytest and hypothesis, we can verify our code’s behavior over a massive, randomized set of inputs. But what if we could go even deeper? What if, instead of just testing outputs, we could test the rules of our algorithm itself?

This is where a classic proof technique from mathematics, mathematical induction, provides an incredibly powerful mental model. By structuring our property-based tests to mirror induction, we can achieve a more profound level of confidence, verifying that the structural integrity of our code holds, no matter how large the input grows.

Read more...

Introduction

Property based testing is a technique for testing software that is based on generating random inputs to a function and checking that the output satisfies some property. The idea is that if the property is true for a large number of random inputs, then it is likely to be true for all inputs. This is a powerful technique that can be used to find bugs in software that are hard to find using traditional testing techniques.

In this article I will explain a very common software construction that can be very nicely tested using property based testing. This construction is called a retraction section pair in mathematics.

Read more...