The phrase “Initial commit” covers a real multitude of sins. It’s shorthand for “I’ve done too much stuff already to describe it meaningfully, so… here’s all of what I’ve done so far”. It’s an admission that an important step has been left too late.

Now, I have - I think - exercised good commit habits on Pandamonium, my current hobby project. But I’ve done a bunch of (I think) cool things with it that I’d like to share, and now I’m in a position where that’s a bit overwhelming - I’m in an “Initial commit” position on the blog.

So I’ll start with a brief introduction, post in-the-moment as I solve interesting problems, and slowly backfill the more interesting choices made so far.

Here’s what I’ve got so far:

How do you make your tests aware if you’re running them from your IDE or not? That’s what I’ve been wrestling with, and there were some surprising results, so I thought it would be worth sharing.

This is the eighth in a series of posts introducing co.unruly.control, a functional control library for Java. Previous parts:

• Most code fails badly
• How to fail in Java
• Carpet-oriented programming
• The difference between functions and methods
• The Applicable Pattern
• Railway-Oriented Programming
• What about the rest of the world?

Let’s recap briefly. We now understand what railway-oriented programming is, and we’re comfortable abstracting over the idea of collating failures at different points in an execution and handling them separately. We can combine operations which always succeed and operations which may fail, we can convert pretty much any failure mode into results, and we can resolve back to a regular value.

What else could we ask for? Well, let’s take an example: we’re working at the gate of a ride at WonderFunLand. We’ve got a queue of people coming up to ride the BoneRattler. Can they ride?