A gentle intro to assembly with Rust

One of the things I’ve wanted to do for a while is really dig into assembly and get into the weeds of how programs actually run. A rework of the asm macro has recently landed in nightly rust so it seemed like a good time.

And compared to some other ways I’ve tried to approach this there’s a lot less setup we need to do if we just use the rust playground to do all the heavy lifting.

My process for figuring things out has been pretty simple. I write a tiny bit of rust code, look at the assembly output and try to figure out what’s going on (with lots of googling). I’m going to walk you through what I did, and what I figured out.

The Power of Names

So I’ve just started working with a new team at BlueCove. I’m really enjoying it, especially since we have a lot of decision making space to work with. The company has just turned one (there was cake, it was delicious) and the process of building up the code we need is still in full swing.

Something interesting happened to me the other day. I was talking with one of my co-workers about a problem we were trying to solve, and was about to reach for one of the terms from the Domain Driven Design (DDD)¹ book, namely Bounded Context I asked him if he’d read the book, and he hadn’t. I didn’t think much about it until I was on the tube home, and I was going over my day.

Before we go any further, I should give you a hefty disclaimer - I’m not any sort of expert in what I’m about to write about. When I was explaining why I was excited about writing this to my wife, she told me it sounded like I was writing about Semantics, which prompted an educational excursion through wikipedia. I am, however very willing to be wrong on the internet, so let’s dig in.

Reducible Systems

A while ago I had a minor revelation about why I’m ok with working in the LMAX codebase. I’ve got a pretty strong interest in functional programming by way of Clojure, so you’d think working in a system where pervasive mutation is the rule rather than the exception would slowly drive me nuts.

I think there’s a few reasons I’ve retained my sanity, but the most important one is the way the system is designed it’s easy to keep a mental model of, and that model isn’t often broken. Why is that the case, though?

re-frame and the Back Button

A few things I’ve been working on over the christmas break have involved a fair bit of front end work. I’ve been using re-frame to do most of it, which has been a very satisfying experience. It’s made me quite a bit happier than the month or so I spent working with Vue.js for a project at LMAX. But all of that’s probably a topic for another post.

One of the things that I (along with a good chunk of the internet, apparently) loathe is when a web site or app renders the back button non-functional, or otherwise stops it from doing what I expect. So of course as soon as I added a second panel to my application (I managed to hack away on a single page for a while.) I had to fix the back button.

Where the GC Fears to Tread

A while ago at LMAX Exchange our staging environment was having services killed frequently by the OOM killer. This wasn’t that unusual, since our staging vms are relatively under-provisioned compared to our production environments

(We have separate performance testing environments, with much beefier hardware for making sure we go fast, whereas the staging environments exist more for testing our deployment and configuration.)

But it was irritating, since it led to a reasonable amount of toil on the part of both the dev and systems teams. We eventually ended up figuring it out, but it was a bit of a journey. All of the dev team was interested in it, so we begged, bothered and cajoled the whole story out of Nick, who did most of the digging. I thought it was good enough to share with the world at large, so I’ve reproduced his presentation in blog form here.

Bitcoin crash course

I’ve just moved to London, and been working on LMAX Digital and as a result been given a bit of a crash course on how exactly Bitcoin (and other cryptocurrency) transactions actually work. I think there’s a near zero chance I’m going to remember it as I’ve moved on to another area of work, so I figured I’d better write it all down before I forget it all.

Roasters log 1

So I’m up to roast number 7 at this point (probably 8 or 9 by the time I’ve finished this blog post…). I’m beginning to think maybe I like the process of roasting coffee more than drinking it - my biggest issue at this point is that I can’t iterate quickly enough on the roasts because I don’t drink coffee quickly enough. I only want to roast enough coffee for about a 5 days worth of drinking, i.e. ~5 batches in my wee popcorn machine, since apparently the “freshness” really starts to fall off after 5 or so days. I’m tempted to try and foist it on my friends, but I think I need to try and dial it in a bit first.

Roasting coffee with a popcorn maker

I’m a big coffee fan. I’m also a massive cheapskate. Normally the first one wins, but the other day I found this post about how you can roast your own coffee. Within about an hour I’d ordered the necessary bits, and now less than a week later, I’ve roasted my 5th artisanal microbatch of coffee.

As you might be able to tell, I haven’t dialed in the actual roasting part of it just yet, but I can definitely tell you how to pull apart a popcorn maker.

The unreasonable effectiveness of checklists

One of the things we did recently was start using a checklist once we think we’ve ‘completed’ a story. The checklist is basically just a big list of features that already exist in our codebase, and some notable gotchas that have caught us out before. All we do is go through it and ask ourselves if what we’ve just written interacts with that feature or gotcha, and if so, have we written a test for it?

Why bother with property tests

So something I’ve been trying to do lately is write more property or generative tests. I’ve been spending a bit of time thinking about why we’re actually doing this. Obviously I think it’s a good idea, but what actual benefits do we get from these, apart from slightly more arcane tests?

Flamegraphs and benchmarks

lein jmh recently turned up on the Clojure scene. I’ve been using it to debug some performance issues with a library I’m about to open source called undertaker. I’m gonna tell you a little bit about the why and the how of getting benchmarks to produce Flamegraphs like this:

Clojure fspec surprise

Recently when writing Clojure I’ve been trying to cover everything I can in specs. This led me to a bit of a surprise when I used fspec. It evaluates the fspec’d function when it’s passed to a fdef’d function, not when you invoke the function. That’s probably super unclear, so look below the fold for an example.

Writing IntelliJ plugins

I’ve spent some time working on an IntelliJ plugin during our free time at work. There’s quite a bit of stuff I’ve learned from either reading source or messing with things until they worked, and I thought I’d record some of that.

You’ll need some knowledge of how IntelliJ plugins work, mostly about the Psi model and it’s API. If you want to learn about that, you should probably start with this or this. Anyway, tip #1 - PsiTrees are sensitive about what elements you put where.

Property testing tooling in Java

The NZ contingent of LMAX went to Codemania at the end of last week. And it was awesome, I always come out of there excited to make things. Then usually I give myself a hangover which puts an end to that. Anyway, the two themes we picked out from the conference were automate more, and property test all the things.

I’m already a huge fan of test.check for my Clojure code, and have been feeling some friction working with the tooling we had for property testing in Java. So I spent some time digging into the options we had, and this post is the result of that.

This post assumes you have some knowledge of what property based testing is, and how it works. I’m just going to compare and contrast Java libraries that enable it.

Performance checks on metrics

At LMAX we do a lot of automated testing, including running several dedicated environments for performance testing. We’ve got a lot of specific numbers that come out of these environments that we surface on dashboards like this:

But we also collect a bunch of other metrics from our servers and services that, until recently, we didn’t have much visibility over.

Coupling, Connascence, CSP and Actors

In the last 6 months, I’ve been lucky enough to be exposed to two very different ways of dealing with asynchrony in one of our production systems at LiveOps Cloud. We converted one of our core backend services from Clojure’s core.async to Pulsar. Having been a part of that transformation, I now, of course, have opinions that I’m going to subject you to. Those opinions boil down to CSP (Communicating Sequential Processes) as implemented in core.async is better than the actor model, at least as implemented in Pulsar.

Dependency Injection in Clojure

So this is the follow up to a follow up. I’ve been writing Clojure more or less professionally for about a year now, and I just re-read my old thoughts on Dependency Injection. Once again, it having been more than 6 months, my opinions have changed. The reasons I used dependency injection in C# don’t affect me nearly as badly in Clojure, so the amount I use it has vastly decreased, and the way and reasons I use it have changed.

Leaving the M$alt Mines

Error Handling in ASP.NET MVC

So today we’re gonna talk about how to make sure you don’t show your users something like this:

Fresh Thoughts on Dependency Injection

This is essentially a follow up to an earlier post Dependency Injection - A necessary evil?, from back when I had more reservations about using DI, and the benefits it gave me. I’ve since been fully converted to a ‘believer’. This post is bascially about why and how I think that happened.

Moving to Hugo and Lanyon

So if you’ve been here before (highly unlikely, I know), you might have noticed this place might have previously looked almost entirely different. There’s reasons for that. I got somewhat frustrated with my existing cobbled together solution of python scripts, so I had a bit of a look around and found this nice new-ish project (in Go, which is an important factor for me, I like to be able to stare into the guts of the things I use.) called Hugo. It seems to support pretty much everything I want it to, which is super. And it’s also relatively simple in terms of what it expects from the user, which is also great.

Dependency Injection - A necessary evil?

Basically my position on DI has since changed - go take a look at Fresh Thoughts on Dependency Injection

So first of all, to preface this and so you get a little bit of insight from where I’m coming from, I spend most of my days toiling in the great C# mine, so lovingly provided by Microsoft. I used to be a python guy, and I’ve gotten dangerous with Go, and am trying to do so with Clojure. The clojure thing is recent, so this might be a bit more cargo culty than I’d like. Anyway.

Fun with Icon Fonts

So I spent a good chunk of today messing around with making a few icons for use on this site. Which was… interesting. There isn’t really a heck of a lot of information out there about how to do this, or at least nothing that google turned up. I managed to cobble something together though. And now hopefully reading this will save you all that effort.

The Making of

This post is hideously out of date. Go take a look at Moving to Hugo and Lanyon for the lowdown on way this site works now

So. I’d written two posts in anticipation of getting this up and running, however they proved to be glouriously incorrect. I’ve been through about three or four changes in terms of how I actually decided to do this, so… yeah.

Anyway, at this point, it’s a site that’s built from Jinja2 templates. Mostly. In case you haven’t noticed, some bits of it are still not yet entirely working. Mostly the contact page. And all the examples I need to throw on the page that’s supposed to convince you to pay me. Which is just a little bit awkward.