Wednesday, 29 June 2011

Just Do It: Command-Query Segregation, Nike-Style

OK, CQRS is a hugely mis-applied and mis-understood architectural style. The insight I'm sharing here is based on my attending Udi Dahan's Advanced Distributed Systems Architecture course, then applying what I'd learned to a project we were building for 3-4 months, then having one of my colleagues go on the same course, and then have him come back and point out everything we'd done wrong. Let's assume you are already using CQRS. Maybe you're using it appropriately; maybe it's over-engineering; maybe it's completely misapplied. Doesn't matter, for what I have to say here; there are smarter folks than I who can tell you whether you should be doing it in the first place. No, I'm here to share a particular insight about CQRS with you.

Your commands should be like a psychotic drill sergeant screaming orders.

image

 

When you issue a command, your work is done. End of story. Maybe it happens immediately. Maybe there's a delay, and someone has to wait a few seconds. Maybe it doesn't go according to plan, and somebody else notices afterwards, and they call someone else, and it gets fixed up. Maybe it fails spectacularly. You don't care. (Hell, you're probably dead by now. Nobody would ever have won any wars if everyone threw an exception when they found the sarge face-down in a fox-hole with a bullet-hole in his head.)

You're the sarge. You are IN COMMAND. You order someone to destroy the ammo dump in North Camp, then you get on with your life. Tomorrow morning, you'll get a fresh intel report. Maybe it'll say that ammo dump in North Camp has been destroyed - maybe it won't. You'll review the fresh intelligence, decide what to next, issue a fresh batch of orders - and get on with your life. That's CQRS. Your data is stale, your word is LAW, and you have better things to do than hang around wondering if you maybe did the wrong thing. If you give a command, and it doesn't get obeyed, there's exactly two potential outcomes:

  1. Nobody notices
  2. Somebody notices

Nobody notices? Cool. No problem. Somebody notices? Well - that's where you hope it's one of your guys (i.e. alerts, logging, infrastructure, monitoring) instead of one of THEIR guys (i.e  customers/clients) That's how you do CQRS. Get your intelligence - your queries. The freshest data you can get, but don't bust a gut if it's a little out of date. Give your orders. Trust your intelligence. Get on with your life. Rinse. Repeat.

Saturday, 11 June 2011

How to install "Active Directory Users and Computers" on your Windows 7 Workstation

This one stumped me until I hit upon the magical combination that makes it work.

  1. Install Windows 7 Service Pack 1.
  2. Download the Remote Server Administration Tools for Windows® 7 with SP1
  3. Install them.
  4. Reboot
  5. Go into Start -> Control Panel -> Programs and Features, and go to "Turn Windows features on or off" - because the installer will download and install the admin tools, but won't actually switch them on. Helpful.
image

What makes it fun is that it just fails silently until you get it right. No error messages, no warnings... installer didn't even tell me I was missing SP1 - which I thought I already had.

Thursday, 9 June 2011

Why Cloning Classic Games in Javascript Makes for a Great Hack Day

Gary Larson / Far SideHack days should be about code. Anything that stops you writing code (or talking about / editing / refactoring code) is friction.

There's two things in any software project that tend to cause huge amounts of friction - certainly during the early stages. One is tooling. Installing compilers takes time. Installing libraries takes time. Configuration takes time. I remember a day at Snowcode last year when we spent literally five hours installing Ruby, various build tools, make files, modules, browser automation components, plug-ins... I don't think I wrote a single line of code that day. It was interesting, and educational, but a hack day should be about building stuff.

The other huge source of friction in software development? Debates. There's X ways of doing something, and you can't make any progress until you've chosen one. Should we allow HTML in the comments? How big do we make the gallery thumbnails? What colour should we paint the bike-shed? On a "real" project, these decisions are made by the product owner - but for something like a hack-day, if you one person in charge of all the design, decision-making and prioritisation, they'll rapidly become a rather frustrated bottleneck.

So - pick a problem that's clearly-defined and well-understood, and solve it using a language that everyone's already got, that doesn't need a compiler, linker or build environment, and that everyone can run just by opening a web browser.

In other words - clone a classic game in JavaScript.

Choose something everyone's played. Bomberman. Tetris. Lemmings. Asteroids. Pac-man. Have a copy of the game on hand - on a laptop, or an emulator, or bring a console, or whatever - so if anyone asks questions, you can just refer to your definitive reference implementation and get back to work. That'll eliminate debate without handing anyone the poisoned chalice of product ownership on a volunteer-based project.

And embrace the awesome lightweight expressiveness of JavaScript - the only language that you can write and run, out of the box, on every single computer since Windows 98. There's no compiler. There's no IDE, no build chain, no runtime or virtual machine or standard libraries to install. People can use vi, Visual Studio, TextMate, Notepad - whatever they like. (Personally, WebStorm is rocking my world right now - JavaScript intellisense and refactoring with built-in Git support... it's fantastic. Just remember that Ctrl-Y doesn't redo by default and you'll love it.)

OK, this weekend we were using NodeJS, so the build/run/test cycle involved restarting the node server (which is Ctrl-C, up, enter) - but the guys working on the renderer didn't even need a server. They built a client-side test harness (index.html), and their build and deployment cycle was Ctrl-S, Alt-Tab, F5.

That's low friction. That's walking in off the street, opening up your laptop, pulling the code, and starting to build stuff straight away. And I like that.

Sunday, 5 June 2011

Notes from the KaboomJS! LonDev Hack-Day

A couple of weeks back, I had this crazy idea to build Bomberman, in Javascript, in a day. I floated the idea on Twitter and got a pretty enthusiastic response, and so I set up the first LonDev hack day. 12 people, in a room, for one day, working together to build and ship a working game.

Did we do it? You'll have to read all about it on the new LonDev wiki, but personally, I'm really pleased at how it went, and really  excited at the idea of organising the next one.

What's really encouraging is the mix of people and expertise who contributed. We had a couple of .NET coders, some Ruby/Rails guys, some JS web hackers who'd not done node/socket stuff before, and @palfrey who, as far as I can tell, spends his days switching between Erlang and PHP to stop himself getting bored.

A fun day. Some really solid code. Some really interesting lessons learned. And there's a couple of us hanging out in #kaboomjs on Freenode over the next few days to get it finished off and up and running.