... Oh, hello there. Hello? Hi. Is this thing on? Well, uhh.. welcome back. It's been a smidge over two years since I last posted on here, so I figure I should pop in an update - things have been busy but at the same time not really.

Along with the new content I've given the site a fresh lick of paint, I'm not going to spend ages getting it where I want because, frankly - the longer I spend on it, the less I'll be happy with it.

Real life things (tm)

I don't normally talk about real life stuff on here, but things have been busy and some pretty big and meaningful changes have been afoot so buckle up.

I quit my job. Twice. Without going into too much detail, I'm trying to sort out where my career is going. Being "on the tools" is making me feel like shit and killing what interest I do have, though part of this is environmental/situational and even more of it is a me problem.

Anyway, this is an ongoing thing and I need to sort things out still. At this point I'm considering moving to a whiteboard position (solutions architecture) or make a dramatic jump into something completely not IT related (book keeping seems reasonable at this point). Updates as they come, but we'll see where I land in the next 6-12.

Around two months after my last post, I proposed to my gal of 11 years. She said Yes! (thank god). Despite being stressful, I'm as happy about this as ever and it looks like it mightn't be anywhere near as stressful as planning a wedding :)

Oh, and we bought a house. And an adorable puppy named Frank(ie)!

So things in the real life department are pretty awesome. And expensive. So expensive. But mostly awesome :)


Nope! This post is getting too long already. You're going to have to check out the next three posts covering this section. Doing this big update makes me feel a little better, I don't feel like I've been so lazy for the last two years now.

Go me :)


Last year I founded my second real company, Meta Technology (website coming soon, for now please enjoy the SSL warning and webmail links).

I've been doing some contract work on and off for a handful of tech startups here in Perth, and this company will house that. This is part of my longer term goal of having a legal entity to fund some of my projects, support any that become viable and provide me with some level of protection for those that might not go so well.

So far, this is a happy story - the company has paid back its loan to me and exceeded its goal of breaking even. So far. With some additional work lined up to pad out the rest of the financial year, things are looking good.

So if you know anyone looking for a solutions architect for hire (specialising in applications at scale and the clouuuud), feel free to refer them to me.

I'll have a website real soon, promise ;)

Hooray! I've finally updated my home file server. This is the first non-drive change made to the system since I built it back in 2010.

The original build allowed up to 20x SATA drives sitting on top of LSI 2068E cards and a motherboard with three 8x PCIe slots on an Intel X58 chipset. This design was to allow for enough bandwidth back to the CPU for full controller-speed (SATA II) for all 20 drives in the chassis.

The system has served me well to date, but as I expand the array I'd like to keep on top of disk density - and if the opportunity arises, I wouldn't mind something a bit quieter.

Also beyond a crazy growth rate of ~300+GiB/mo for the first year or so, my growth rate has calmed massively and I'm only sitting at around 11TiB of data all up spread over 8x 2TB disks. So maybe supporting up to 20 drives isn't necessary after all.

I had a bit long rant preparated about all the goals and issues, but honestly it boils down to:

  • The newer backplane on the Norco I had still wasn't passive, and doesn't support 4TB drives
  • The IBM ServeRAID 1015 controllers (LSI SAS2008) I bought have a buggy Option ROM that doesn't pass the extended memory map through during boot and causes GRUB to wig out

I ended up settling for a design with a chassis supporting 12x 3.5" + 2x 2.5", with passive backplanes and different card on the LSI SAS2008 chipset. Whilst the dollar-per-bay isn't as great on the new case, it's a much higher build quality and has better airflow/cabling.

And it runs great - I've rebuilt the array onto 6x 4T drives still using linux software RAID but now using btrfs as the filesystem (I'll redo this as raw disk btrfs raid when the code for that is a bit more mature).

Now that the data migration and deduplication run have completed, I can cross this off my TODO list - and decide what to do with the spare gear I have left over, enough to build 2 file servers.

Any takers?




I mentioned in a recent post that I've been working with a cool piece of technology called AngularJS recently. It's been a long, long time since I've done any regular web work - but since picking up Angular, I can honestly say that building web applications has never been more enjoyable.

As a developer, I found the documentation reasonably sucky - it has a quick tutorial and jumps straight into API documentation. There's no guide on overall architecture, which makes understanding how you should be building your app a bit difficult.

What follows is my quick and dirty list of notes for developers looking at using Angular in their app:

  • Everything is a module
    • Every piece of code in AngularJS is attached to a module.
    • Modules can express dependencies on other modules.
    • Your application is a module
    • Modules can contain Services, Controllers and Directives
  • Dependency Injection
    • Angular provide dependency injection for all prototypes
    • You have two options for specify a dependency:
      • Lazily, by ensuring the name of the variable name in the signature matches the name of a service; or
      • Explicitly, by providing an array of the service names followed by the function with arbitrary variable names
  • Services
    • Services are singletons and are lazily created - so you'll need to reference it in the app if you need them to be instantiated
  • Controllers
    • Controllers are exactly what they sound like, if you need logic to glue the view model to service actions - this is where that lives
  • Filters
    • Filters can exist locally to a controller or globally on a module
    • Be wary of the built-in filter module, if you use the string comparison this is actually a substring match (this has caught me out badly before). You probably want to make a global filter using angular.equals in these cases.
  • Directives
    • If you need a common Controller/Template to render the same object in your app, chances are you can bundle it together as a directive
    • Even if you're not at the point where you need to use directives, it's worth reading the AngularJS Directives Guide to understand how the Angular parser resolves directive names (and why the documentation shows directives in camelCase even though the examples you use dash-delimited).
  • You need the extras
    • Downloading AngularJS isn't enough for single-page development, you're likely going to need the following modules:
      • angular-route.js - Provides the ngRoute module providing page routing for a single-page application
      • angular-resource.js - Provides the ngResource module allowing you to easily create services backing onto REST interfaces
  • Understand that AngularJS is javascript
    • No, really. If you build your entire site it won't be indexable by search engines unless you prerender out a static copy. Read more here

I hope this is useful to other people starting out.

I got dragged into another philosophical argument the other day regarding white space in code. It's one of those quintessential tech discussions that does nothing more than rile people up over something that, for the most part, doesn't achieve anything of value.

Generally speaking, I try and stay out of these discussions - however given I was trolling the person in this situation, I feel entitled to claim at least some small victory - someone has to.

That being said, I do have an opinion - and in the interest of adding to the pile of spew on this site that feeds back into the greater slum that is the internet - let me tell you what I think.

Let's start with my personal preference:

  • DO use tabs at the beginning of a line to indent code
  • DO NOT use tabs after the first non-tab character in any line
  • DO try and avoid indentation/formatting after code has begun
  • DO NOT insert editor-aware comments in your source to set editor options

Easy! You're well on your way to coding nirvana. I think this scheme works particularly well because:

  • It doesn't matter what size indentation you prefer - No more of this "I like my indentation to be 2 characters, not 4 or 8". Please stop. That's a presentation issue. Use an editor that supports configurable indentation widths.
  • It's semantic - The number of tabs corresponds exactly to the number of levels of indentation. You don't have to worry about whether the author prefers their tabs at 2,4,8 or 19 characters wide - nor whether they prefer milk of cream in their tea.
  • It helps filesize - Okay this is a bit of a weak argument, but using tabs reduces file size by not representing redundant information. Put your solution into a version control system and this has a slight multiplier effect.

And to cap it off, here are some common arguments as to why we should avoid TABs, and why I think you're wrong.

  • Not all editors support TAB characters properly - This has nothing to do with the file you're editing. If the specification(grammar) for your programming language treats both space and tab as whitespace, then it's whitespace. Your editor is not supporting the language you're working with, and that's your problem.
  • I prefer my indentation at x characters - I've already addressed this above. Learn to configure your editor properly if it will let you, or find a new one that will. Vim, a terminal text editor from 1991 supports just about every possible combination of tabs and spaces, so I'm confident this is quite a lot easier than you might make out.
  • My Wyse TTY is only 80 characters wide! - Brilliant! I also spend the majority of my time in 25x80 or other weird-sized, resizable terminals. Wouldn't it be terrible to have to re-format the file every time your terminal changed size? That's your editors job, and again it can reflow the text and preserve indentation if you're using a good one.

Ultimately though, arguments like this are a zero-sum game - nobody is going to be 100% happy, and there's always going to be that guy who has invested their sense of identity in their position on tab-vs-space - but you're wasting your time dealing with them anyway, right?

Pick one that makes the leasy number of people cry, stick to it and move on - we've got interesting problems to solve.

I recently stumbled across a post by Timothee Besset about his plan for an experimental framework for low latency, high fps multiplayer games. TTimo is a games programmer who wrote QRadient and has worked at id software, so knows a bit about what he does.

His post outlines the architecture for a modern FPS game engine, which struck a chord with me. Mostly because at a high level, it's similar to an idea I've had before, a message-oriented game engine using ZeroMQ and its zero-copy message model.

It's always nice to see your idea validated, especially by someone who knows what they're talking about. I'm most definitely not a game programmer, despite having tinkered and modded a lot over the years.

I also happened upon a fantastic interview with Edmund McMillen of Team Meat. Whilst being a talk about game development - Edmunds discussion about motivation, career and dealing with people really struck home about a lot of things I have been thinking about recently. Some of those things I'm not ready to talk about, but in terms of game development, the message is clear - keep going at it, the first 30+ things you make are going to be absolute horse shit..

Combined with discussions with one of my coworkers who is writing his own WebGL MMO, Langenium, the interest has definitely been reawakened, for now.

Onwards and upwards

As a result, I've been putting a small amount of time into this project over the last three weeks. One of the biggest problems I've had working on game-related projects (or really, anything at all) is trying to do too much all at once. You get no reward and make all the wrong design decisions at once.

Instead, I've been working at this iteratively - starting with a 2D maze game and upgrading a single thing at a time towards the end goal of a 3D FPS. A high-level of the iterations are as follows:

  • Tile-based 2D maze game using Windows Forms
  • Moving from tiles to continuous coordinate space
  • Move to OpenGL render in 2D
  • Generate 3D geometry
  • Move to 3D
  • Writing Quake 3 BSP parser
  • Move to BSP geometry
  • Quake 3 BSP culling

So currently, I can load and render a Quake 3 map - moving around within the world. I've implemented visibility testing using the BSP tree, however have a bug in either that code or my BSP loader which is preventing it from working correctly.

Before I push on - I need to fix that and implement support for Vertex Buffer Objects, as I am currently making an OpenGL call for each vertex, which is very expensive and thrashes the frame rate way down. I'm currently getting 10-15FPS, which is much better than I was expecting for my simplistic engine so far.

The Quake 3 map format is super-efficient and designed so data can be slurped straight off disk into OpenGL buffers. My BSP loader takes the data and interprets it into an object graph - so currently does not do this. The current plan is to implement my own load handler to re-flatten the data internally.

Whilst this is a bit of a waste for now, I don't have my own BSP tooling and want to keep my engine from being tied to the IBSP format. This is primarily a learning exercise, and I would like to support early versions of the Valve BSP format as well before I'm done.

From here

I'll be happy with my progress when I can come up with a simple death match game with netcode, similar to Quake 3 - complete with bots. Once I'm done with the game side I want to explore the map 'compilation' side of things, BSP partitioning and portal testing.

I've never really understood that side of things before now, and conceptually it's very straightforward - which is a nice refresher. I'm hopeful that as long as I can stay motivated and get past where I'm currently stuck, I can start to play with game ideas on top of my own engine stack.

image image image image image image image image

This is the personal website of Will Dowling, a DevOps Engineer hailing from Perth, Western Australia.


I talk shit here sometimes.


My terrible code. For free.


Pay me to write bad code and talk shit for you.


Pretty pictures, rarely my own.


Pretty pictures, actually mine.