Tomb Raider: Legend

09 July 2006

Ten years of Tomb Raider, and only one of them was ever any cop. When the BBC and Design Museum ran a public poll for the greatest icons of British design, Tomb Raider was nominated the eighth greatest British Design icon. One notch ahead of Grand Theft Auto, no less. Which begs the question: has anyone who voted for it actually played a Tomb Raider game?

My review of Tomb Raider: Legend is now online at Pixelsurgeon. Surprisingly, the game doesn’t suck. Parts of it are, in fact, “rather good”. This was a turn-up for the books, so to speak.

It must be the heat

07 July 2006

I had my first ever nightmare about work. Well, I say nightmare; to be honest, it only qualifies as unsettling.

But it did involve Ruby’s unicode support.

If you know what I’m talking about, you’ll appreciate why I was scared.

  • Balloon. (Scripty postcards.) — Scripty postcards: chunks of Ruby you can run just by evaluating them. They do useful things, and are hilariously insecure – but the concept is delightful. Not sure what I’d use it for… but it all hangs together very nicely.
    Tagged as: fun proramming ruby scripting web
  • RedHanded » Hpricot 0.1 — Crunchy! _why knocks up a really loose HTML parser for Ruby (in C) with some delightful syntax. Now, to knock up some microformat parsers…
    Tagged as: gem html parser ruby

One thing most web applications need is a static page template. Now, whilst the page content might be static, the template itself might need to be dynamic – either because it’s going to change in future, or because you’ve got dynamic user information that appears in the tempalte.

So the most obvious way around this is the static controller. Dead easy, this: generate a new controller called static (or whatever you want). Then just write views for it named after pages you want. For instance: your about.rhtml file can contain all your “about” information. Then, when you hit up /static/about (to use the default routing), you get your static content, without having to make a whole page from scratch in public_html. You could even write a new 404 page on this controller.

All that remains, once it’s working, is to write some dedicated routes, and then the “static” controller can be hidden from existence – just route /about to :controller => "static", :action => "about" and you’re done. No need to write any controller logic at all!

Going on from there: one view I’ll always add to that template is the “foo” action.

So: when you’re mocking up a page, you’ll probably use lots of dummy links. Everyone expects this, because it’s obviously just a flat mock. But when you mock up an application, and show it to stakeholders in a working state, they click on things, and wonder why they get ActionController exceptions when it breaks. Also, they wonder why the link that breaks stuff is always /foo.

Obviously, it’s because I’ve left link_to "/foo" all over the shop. Have no fear: the easy way around this is to route /foo to :controller => "static", :action => "foo", and then write a static page called foo.

When you do this, the page should explain that it represents functionality that hasn’t been added yet, but will be added soon, and that the developers haven’t forgotten it.

This (from experience) reassures stakeholders that the thing that is not working will be working soon. It also means that when they do find “grey screen” errors, it either means that something’s genuinely broken, or it means that the developers really have forgotten something. Time to update that link to point to foo.

It sounds trivial, but it turned out to be an effective communication of diligence on the developer’s part, and saved much time in meetings explaining that “yes, we’re working on that”. Consider it, next time you’re developing for external stakeholders.