Anthony Bailey

One case for queues

Ted Dzubia recently posted The Case Against Queues. I have to grant him that, like anything else, queues can be over/misused, so probably they are being in some parts. Film at 11. (I would say that re useful metrics to alarm on, the time between a message arriving on a queue and it being acked as processed is typically easy to measure and to set sensible thresholds for.)

In an Google+ discussion of the post the argument has been advanced that queues should be avoided wherever possible; that they cause more problems than they solve. My limited experience is the other way; I’m working on systems where I’m finding them to be a highly valuable abstraction and where I’m not seeing significant cost. I thought the discussion would benefit from more examples, so I present here one case where I’ve found them very useful.

Suppose there are two systems, which I’ll call Truths and Consequences. They maintain state in related domains, but are decoupled - probably owned by different teams - and they model their domains in sufficiently different ways that working out the consequences of truths requires some code to crunch. It could take quite a long time to recalculate all consequences of all truths, but we can usually comfortably keep up with recalculating consequences as truths change, and we don’t want to ignore the consequences of any truths.

Truths and Consequences communicate through a queue with typical robustness properties such as At-Least-Once delivery. When the truth about some named thing (say “cats”, or “dogs”) changes, Truths publishes a message containing that name onto a queue. Note that the message doesn’t say “the truth about cats is that they are all gray”, but rather “the truth about cats has changed”. When Consequences consumes the message, it asks for the current Truth about the named thing, updates relevant consequences, and acks the message. For any given set of truths, calculating their consequences (and hence, processing a message) is of course idempotent.

Of course the queue decouples the two systems so that you can change truths without waiting to hear about the consequences - hell, Consequences can drop off the network for a while as far as Truths cares, and in a halfway decent framework the queue works as a resilient store out-of-the-box. These are the kind of reasons why we introduced the abstraction in the first place. But there are other nice properties of this system too.

For example, suppose occasionally a new truth appears that we can’t currently calculate the consequences of. Maybe there’s a disastrous edge-case that crashes the calculation (“dog.getNose().smell() throws NullPointerException”), or maybe the truth breaks some assumptions that the calculation has used (“uh, what? dog.getHead() returned an array??”) The “dogs” message is poisonous and Consequences can’t currently handle it. So it nacks the message, prompting it to be moved from the original queue to an associated dead-letter queue (DLQ). After the Consequences system has been updated to deal with the new situation, it can have another go at consuming such messages, which were sitting on the DLQ in the mean time. Another possibility is that Truths realizes they were talking nonsense, and changes their mind back to something sane. In that case the Consequences system doesn’t need any update, it just reconsumes the message; when it asks for the truth about “dogs” it finds that they have just the one head again and all is well.

Another example: for some set of things, the truths are unchanged, but Consequences is updated to fix a mistake in the existing calculation, or to extend it with a useful new consequence to calculate. Publish messages naming all the relevant things, and the new calculation will be applied. Is it going to take a while and we don’t want to interrupt business as usual? Put these messages on a lower priority “backfill” queue that is only consumed when the regular one is empty. Are some of the things more important than others? Order the messages on the backfill queue to reflect that. Similar approaches apply when truths about a large new set of things become available and need backfilled.

A last example: during an era of uncertainty, truth about some set of things becomes very volatile, swinging back and forth faster than the consequences can be calculated and recalculated, filling up the queue with a backlog of messages naming the same things over and over. Just introduce some plumbling that dedupes the pending messages by name - because we always calculate consequences based on the current truth, not the historic one.

Note that either system can take responsibility for the queue and work to redrive DLQs and reprioritize messages - typically it depends on which role cares most about the relationship. If Truths wants to be heard, it can own the queue; if Consequences needs to know the truth, vice versa. In the system I work on right now, we play both these roles in relationships with various other teams.

One, Two, Testing

The first official DLC for Portal 2 came out today. It’s a new Co-op campaign.

Now this kind of play is probably great fun, but I still haven’t managed to play the co-operative campaign that originally came with the game. Because, you know, you have to be organized enough to dovetail the windows in your packed social schedules and all that.

So I was kind of hoping for a new set of Valve-quality Portal 2 single-player maps.

It’s OK though, because instead the Internets sent me a new set of better-than-Valve-quality Portal 1 single-player maps: Try Anything Twice by HMW. I spent around four hours on Sunday playing through this masterpiece.

Try Anything Twice is very much to my tastes. There are no very tricky moves, and fairly few halfway tricky ones - instead it’s all about the puzzles. Said puzzles are very well-paced; I was consistently stretched but never got totally stuck.

There’s a nice central concept/conceit: you solve each of the five maps twice, the second time around with some minor changes to the situation which demand major changes to your solution.

The level architecture and engineering is beautiful, with chambers rearranging themselves like something out of, well, Portal 2.

Lastly there are a few new game mechanics with great art and execution. The element introduced for the second try of the last chamber gives rise to the most mind-bendingly enjoyable puzzles I’ve seen in any Portal context.

Better than any other Portal mod I’ve played. Download it.

Forcing functions that are better than comments

A recent thread at work discussed the value (or otherwise) of comments in code. I think comments on anything owned and used by a small team are usually a code smell.

One of the excuses offered for comments was that if you wrote e.g. JavaDoc for some code, then that forces you to think about the details of the code’s behavior and the way that it presents itself to clients; and that such thinking catches edge cases, and prompts redesign all the way from minor naming tweaks through to major simplifications.

I agree completely that the forcing function of explicitly expressing one’s intent has that value. And it’s a really significant value. But tests do it better than comments without any of the “eventual inconsistency” downsides.

This is old news. But then I noticed a pattern I thought worth posting:

One genuine usefulness of comments can be in providing the “why” instead of the “what”: to give the motivation for behavior rather than simply a description. And making motivation explicit is as valuable to a developer as making descriptions explicit is. It analogously exposes gaps in thinking, and prompts re-aiming toward equally valuable goals that are easier to hit.

Tests are only good for expressing descriptions, not motivations. So here they can’t play the same role of a superior substitute forcing function to comments. You know what can though? Talking with your pair.

Google Plus minus writes

Google+ finally began to roll-out an API. Yay! But, it is read-only. Boo!

I write my stuff here, in a space (i.e. under a domain name) that I own.

Some people have chosen to follow me on Google+ and from this I conclude they may want to read what I write. The obvious way to link the resources is to post a link on Google+ each time that I write something here. I was hoping for a Google+ API that allowed writes, so that this could be automated. Oh well. Guess I’ll copy and paste manually when I remember too.

Not that I write enough for this to be a big deal for me or for anyone else. But it does disappoint me. Perhaps Google+ really is intended to be a big walled garden within which you rent a plot where you plant your thoughts - but if I wanted that silly silo model, I’d be on Facebook.

Google Identity

These are some thoughts in response to a post by Pavlos on Google+, on Google+. (They are posted here on my blog in order to be consistent with their content! Consider this a trackback. Hmmm, whatever happened to trackback?)

I have three things to say here.

First, whatever Google’s worthy plans may be re other long-term benefits of having well-defined identities in this new space, we should not forget that real names, tied to real addresses, are worth more to a company whose primary business is advertising. Pavlos, I expect you are cognizant of this, but I didn’t see it in your posts yet.

Second, anyone who believes in the value of having an online identity and who then gives a commercial company ownership of their main identity page is taking quite a risk. Google has previously been mostly on the side of light re supporting technologies (such as OpenID) that do this stuff right: which is, to let you define your identity provider somewhere that you control, so you can migrate identity providers if required. (Register a domain name. Delegate everything that speaks canonically about you online - email, blog, profile - via resources accessed under that domain name.) I really hope Google+ makes supporting this approach a priority too.

Lastly, with regards to both to my second point and to Pavlos’ third (re those who require anonymity) - this service is brand new. A lot of the features we are after are allegedly simply on the to-do list. So we should wait and see.

Who is ready to make some science?

When Portal 2 came out, I had grand plans for a detailed post discussing the game, the multi-stage ARG that surrounded the launch, the plans for DLC, and lastly my thoughts on whether the less clinical look of the game would get in the way of homebrew levels.

Skip to the end… no, it has not. Wish there had been another two scenes in the middle act of the game? Install this Sphere of Roundness / Old Faithful level pair created by mapper Lobster. Beautiful puzzles!

Oh yeah, I keep meaning to organize playing through the co-op. Anyone up for that?

Update: the maps that won the first Portal 2 Thinking With Portals contest are of a similarly high quality.

Mixing a Modern web presence

Under the banner of Miss Fitz-Poste Modern Mixers, my partner Julie and her friend/cofounder Emily (henceforth, “the Fitz-Postes”) for about a year have been running a mostly monthly vintage-themed event: a new-fangled take on the old-fashioned concept of a social mixer.

The exact content varies with the theme but this Sunday afternoon’s Hello to Berlin will do as an example: three burlesque performers, a band, DJ and compere, shopping from four craft stalls, hair and makeovers, silly games with prizes, and other bits and pieces. They are genuinely great affairs I’m unashamed to push at my readership because your cooler significant other gets it straight away even if you don’t, and in any case you get to laugh at what I wear on the door.

Other than manning said door, my main contribution is to enable their online presence. The website is a zero budget affair, static pages hosted off the side of a slice I was already renting. The visual design is technically sound but that’s the nicest thing anyone is likely to say about it something under my direct management. To mitigate that, apart from core static copy served directly from the slice, the structural approach is to embed and aggregate content which is hosted elsewhere and created/managed by the Fitz-Postes. As much for my own diary as anything, I’ll describe the current arrangement.

We host photos at PicasaWeb (embedding tag-driven slideshows within our site pages) and videos at YouTube. Any substantial written content, especially if it has potential long-term value, is created as blog posts. The blog is hosted on Blogger but to avoid tight coupling that would impede migration, we reference it as and serve it from a CNAME we control. The content is syndicated via a feed to the social spaces most of our regular punters use to follow us day-to-day: an almost pointless MySpace, an obligatory Twitter, and by far the most popular current portal Facebook. The Fitz-Postes’ update with shorter notes and talk to punters very frequently on Facebook, which I think is appropriate for this immediately valuable but more ephemeral stuff, and has a much lower activation energy - which is important, because more updates is better business.

And finishing up said business: tickets are sold as PayPal items, and email is implemented in a similar fashion to the blog: permanent public addresses under the modernmixers.co.uk domain are backed with mail accounts hosted elsewhere, currently Gmail. (The Fitz-Postes use theit Google accounts to co-ordinate more admin through Google Docs, unsurprisingly.)

Decloaked

The last time I updated here, I said I was journeying off into the desert. More than three months since, if I had readers I didn’t know they’d probably be a bit worried about me.

No, the trip was only a week as planned. A similarly brief description: the sheer scale of the landscape (mountains en route, then sands as far as the eye can see) was vastly impressive. I got to ride a camel through what was technically a sandstorm. I hung out with very friendly hosts and a weird mix of nice-on-average visitors circling a middle-class artistic hippie locus, although there was far too much deference to native musical and spiritual authenticity. (I judge modern clubs better at trance rhythms, and the music that gave me shivers of joy was Without Why on my MP3 player in the airport.)

Whilst deserting, I also got to enjoy the practicalities of a cloaking device: a long hooded covering formally called a burnous. It’s particularly well-suited to the soft places of Morocco: quite light, warm when need be, a shelter against sand and wind, and a keeper of personal space.

Back here, I already regularly wore the cloak as a dressing-gown around the house. Then I visited my parents in London over Christmas; wanting to minimize what I carried, I tried it as my outdoor coat. And at the start of this year my regular furry black coat went away for repairs, so I wore the cloak around town for a couple of weeks.

I really quite liked it. Warm and light as previously noted, it is also great for my regular extra thirty minutes of sleep in the back of the 43 bus during my commute out to South Queensferry, and it didn’t take me too long to learn how to not trip on it. But it gives off very loud pretentious goth vibes, whilst I’m a quiet and dispassionate goth who does not seek to provoke the staring or the cries of “hey, Aragorn”.

So now that my furry coat is relined and returned, I have disengaged the cloaking device. Ironically, said coat itself wants to be worn by a 70’s rock-star even further removed from my character; I guess I learned to forge my signature coat long enough ago that this ceased to worry me.