An Independent Game Developer’s Diary

One of our agile techniques at guardian.co.uk is to have a central build machine.  The only way that the code that I write can get out into our production servers is to get copied to a central machine (using something called source control) and that central machine runs all the processes that turn my code into the program that actually serves the website.

This provides us with an environment that does the build in a repeatable, consistent way.  But sometimes I might “check in” code that doesn’t actually work.  Because we write tests as we go, this shouldn’t happen, but it does more often than you would think.  We need a way to find out that the building machine has broken code.  The developers have access to that information via a program called ccTray.  But we felt it was important to be able to get that information out to everybody working on the project in an easy way.

The thing that gets that information out is called a build radiator, because it radiates the information about the build to the room, and I had the privilage of working on developing a custom build radiator.  I’ve written up my experiences of developing that software on the build doctor as a guest post, and you may want to read it.

So I’m currently in the process of writing a well thought out, edited blog post on a freinds blog. He kindly gave me access to his blog on blogger.com where I could edit the post inline. Quite a gift of trust, given the spelling, grammer and general professionalism of my own blog.

Today I was looking at the blog, trying to read for spelling mistakes, grammer issues and any final touches, and I figured that the easiest way to check these things was to print it out. So as is my natural keyboard loving wont, I pressed Ctrl-P in firefox to bring up the print dialog.

Except when you are at blogger.com, Ctrl-P doesn’t bring up the print dialog, it publishes the damn post.

Now suffice to say, I had a brown trouser moment desperately trying to work the controls on blogger to unpublish a post (I set the publish date to the future, which seems to have worked). But this should never have happened. Ctrl-P is such a known keypress, it’s a basic facet of our computing user interface. To redefine it to do a destructive behaviour is an epic failure on the designers part.

For those who don’t know, the following keypresses have been in use for so long that they have become ingrained in their users. If you are writing an application, you should never override what these do unless you really know what you are doing;

Ctrl-P means Print
Ctrl-S means Save
Ctrl-X means Cut text
Ctrl-C means Copy text
Ctrl-V means Paste text

If you suport undo and redo operations;
Ctrl-Z means undo
Ctrl-Y means redo

So at my dayjob, we often have to do some funky things.  Like today, we are doing a refactor, and we wanted to know whether any of our web templates don’t use a component, because we needed to add something to it that would be global, and anything that didn’t use it would need to have our lines manually added.

With over 200 templates to look through this was looking like a pain to do, howver, in about 5 minutes, me and my pair managed to develop three solutions using just bash scripting.

My first was:

find . -iname \*.vm -exec bash -c "grep -Hiq javascript.vm {} || echo Not Found in {}" \;

While doing this, I was looking for the -q option on grep, to keep grep quiet when finding the files, and I found the -L option which does almost exactly this:

find . -iname \*.vm -exec grep -L javascript.vm {} \;

The -L says print the filename that didn’t match the expression on any of it’s lines.  (For the record, -l does the inverse, so finding all templates which contain a line is also easy).  Meanwhile Patric found a nice solution too,

find . -iname \*.vm -! -exec grep -q javascript.vm {} \; -print

This also relies on the return value of grep, but instead of some funky bash logic, uses find’s built in operators to execute the -print if the -exec returns 1

Did I say how much I like linux?