JerryJvL

The Maw

2012-05-19T07:47:37Z

I bought this game on-special on Steam over XMAS, but I had not played it yet. I had assumed it was going to be a tricky action-based game, and I never felt I quite had the patience for that before.

My bad.

The premise of the game is that the player and The Maw escape imprisonment on a space ship when it crash-lands in the opening sequence. Together they must try to make their way past their captors and the local wild-life to try and escape altogether.

Throughout the game the player must guide The Maw by an electronic leash that you find at the start of the first level. This gets hard at times when The Maw has his own idea of what he’d like to do.

The Maw is very expressive, which is quite an achievement considering he barely has any features at all. The styling and animation of this game has a very cartoony feel to it, which works perfectly with its sense of humour.

When The Maw gets excited he hops around on his one foot. When he gets hit he looks dazed. When he eats something delicious he gets a dreamy look in his eyes… uhm… eye.

Oh, I forgot to mention.

The Maw likes to eat things.

Anything really. Little of the indigenous fauna will be left standing when you complete each level. And as he eats, he will occasionally grow a size. And as he grows, he can eat larger food. And he will not leave you in any doubt as to what he’d like to eat next.

And that’s where the main twist comes in. Occasionally when eating an animal, The Maw will transform and gain an ability of said animal (no spoilers).

This adds a lot of variety to the game-play, because the strategy to tackle various levels changes depending on The Maw’s last meal.

Although a game with so much variety might otherwise risk becoming inaccessible to inexperienced gamers, The Maw manages to keep things flowing naturally by providing casual hints as you go along.

Early on, floating question marks draw attention to the next thing to try.

The level design seems to have been done very well to steer the line-of-sight of the player so that crucial elements of the level naturally come in view without feeling forced.

Additionally, the game controls are explained as you go along as well. At the start pop-up screens explain the main buttons to lead The Maw, move objects and throw them around.

And for the more action-based controls, small overlay balloons show you which button to use to for example do a Matrix-style dodge of an incoming shot.

And even if you react too late, nothing is lost. There are no “lives” in this game. You cannot die.

The only “down-side” of all this built-in assistance is that this is not a very challenging game. I managed to complete it in under 5 hours. And even if I try to finish all the achievements it probably would not add more than another 5 hours on top of that.

Having said that, nothing feels like “filler” in this game. New game elements are continuously introduced to the player and none of the levels involve excessive back-tracking in an attempt to make it feel like “you are getting your moneys’ worth“. It also doesn’t attempt to stretch the game by being fiddly; the controls are quite forgiving when trying to line up an action.

All up, it’s a lot of fun, and never really frustrating.

The only real criticism I have is that at times I wish I could have panned the camera up or down to get a better view of the level, but unfortunately you can only control it 360 degrees around. This is only a minor quibble though, because it never prevented me from seeing what I needed to see to keep going.

You can get the whole game on Steam with all the downloadable content for US$12, and that’s only if you’re not patient enough to wait for it to be on special sometime.

Hardware Alchemy

2012-04-15T11:07:32Z

I turned my no-longer-needed-because-I-upgraded Samsung Galaxy S into a HD7850 (almost), via the alchemical process called eBay. I’ve long since gotten over wanting to hang on to bits of hardware “just in case I need it sometime“.

I never do.

And they end up gathering dust till they are obsolete.

The best way to go about this I’ve found is to let the item do all the work:

List the most relevant specs
Highlight the best features
Mention any flaws, but don’t dwell on them
List for as long as possible (10 days)
Start at $0.99

And that last step is the scary part. So far every time I’ve sold for more than I expected, but it is always possible it ends up selling for $0.99 … I’d only stray from this tactic if I had to sell something to a niche market that might not spot the item within 10 days.

So finally, I’m back on a real graphics card. After my HD5870 died sometime last year and I settled for a HD5450 to tide me over, I can finally play Settlers 7 again!

I was originally looking at a HD7950 or a HD7870, but after some reflection I’m not the kind of gamer that needs the fastest possible card. I’ll drop the detail a fraction if I really cannot hit a decent framerate as-is.

And the media PC in the living room has a brand new silent (fan-less) HD5450 in the process.

Addendum (9pm): It feels great maxing out all those sliders! … That is all.

Forbidden Island

2012-04-11T14:57:19Z

Front of the Box

Almost every Wednesday evening we have some friends over. It’s a long-standing weekly ritual. It involves having snacks and dinner and dessert together. Sometimes it involves nothing but talk. Sometimes we go out and watch a movie. But most of the time we play board games…

I may have to be a little bit more specific here, because the first mental image that “board games” conjures for most people are the bland mainstays of Monopoly or Risk. Little do they know there’s this whole ‘nuther world out there of somewhat geeky/nerdy (but don’t let that turn you off before you try!) games with a lot more depth and complexity than traditional board games. And it really isn’t as intimidating as it sounds.

Tonight was the first time we tried Forbidden Island, and it played a lot quicker than I would have expected. In the end we had enough time to play 6 rounds, although some were shockingly brief.

Back of the Box

What is somewhat special about this game is that you do not play against each other. All the players are adventurers stuck together on an island, filled with treasures, that is slowly sinking. Everybody plays with their cards open on the table. It is a cooperative game, and you either win or lose together. The game actively tries to kill you all.

Fun fact: there is one way to win the game – collect all the treasures while shoring up the island to keep it above water just long enough to all make it back to the helicopter pad and escape the island.

Second fun fact: there are three ways to lose the game – one of the players drowns, or a part of the island sinks that is critical to completing the mission, or the water level rises too high.

Let’s put it this way: the odds are slightly stacked against the players. We played six rounds in about three hours at the “Novice” level. The first attempt we lost the game without even completing a full round due to sheer bad luck.

Contents of the Box

All in all I think we won three out of six, but it was more of a struggle than it seemed it should have been. The good thing about the game is that the turns are all pretty quick, so nobody will have to sit around twiddling thumbs getting bored. And when you lose, there’s always time for another game.

The rules seem complex at first reading, but once you get to playing the game it’s really not that hard to wrap your head around. The most easily forgotten part is that each adventurer has a “profession” and a special ability that comes with it. It’s very easy to overlook your special abilities when in the heat of the moment you are trying to save the helipad from sinking into the abyss and rescuing the pilot from certain death.

I think it’ll be a while before we scale the fourth difficulty level, intimidatingly labelled “Legendary”.

Easter Storm

2012-04-08T11:42:11Z

About ten minutes into the storm tonight it occurred to me that I had access to a tripod and a good quality DSLR. The view out the front rooms has always been great for lightning; the house is on the raised side of the street and we have a rather good view out over the suburb here.

Lots of sky.

Unfortunately it turned out that most of the lightning was happening behind the cloud cover, so I got only a few single bolts, and lots of ho-hum shots with purple/blue clouds.

After a day of no driving (everything is closed on Sunday, so there wasn’t really anywhere to go) it seemed like everyone started driving along as soon as the rain started. Most of my shots have streaky headlights in the bottom. I kept a few of the better ones to show off how wet the weather was. Especially the last one shows off the bucketing rain in the headlights of a passing car.

Now… what was I doing before all this started happening?

Site Redesigned

2012-04-06T14:42:38Z

Procrastination

I have wanted to re-style this site for quite some time. Looking at the free WordPress themes for inspiration I’d decided to get what I wanted I was going to have to put it together myself.

Alas, finding time to do it right has proven difficult.

Turns out that there was a much simpler way out. For about US$25 – US$35 the Theme Forest site has a very broad range of professional designs for WordPress. And plenty of them looking close enough to be good enough.

If you are looking to put together a personal blog this is an excellent place to get something slick. Just ask yourself, how much is your time worth to you? And how little of it would US$30 pay for?

Of course this means the theme isn’t completely exclusive to me, but there are plenty of knobs and levers to twiddle that it won’t look much like anyone else’s. Note that a lot of these themes use “Option Tree” which is a WordPress plugin that provides for very flexible configuration pages.

I wanted something a bit more than just a slick theme though; I wanted a responsive design that adjusts itself based on the dimensions of the window. As a result, if you look at this site on a mobile device or re-size the window it should adapt to any available space.

Responsive designs are not quite common yet, but more of them come out every day.

My Theme Choice

In the end I settled on the Apex Responsive Portfolio theme, which I tweaked and customised quite extensively to make it more my own.

The theme options allowed for most of the tweaks:

Picking a blue shade for the highlight colour
Adjusting the header fonts from the Google Web Font library
Substituting a custom logo based on the same font and colour I already picked
Setting up the front page slider with my own images
Customising the header menus
Tweaking the footer widgets

That didn’t quite get me where I wanted to be, so in the end I had to resort to some custom PHP hacking in the theme files. In no way do I recommend this. Few developers have the discipline to write maintainable PHP.

By default the blog view truncates every post to the first 35-odd words; I like my blog to show the full post instead.
Even where I didn’t want the full post to show, 35 words doesn’t seem like nearly enough. Although the word count was a parameter to the calls in the theme, it didn’t seem to accept values above 55, so… more tweaking.

There were many more minor tweaks that I won’t go into right now.

More interesting is the matter of plug-ins. It took me quite some time to find a compatible and functional set to address my needs. I’ll write about that process sometime soon, because I think I have a few useful suggestions for would-be WordPress users.

Understanding Code

2012-04-05T11:51:41Z

Spot The Invariant

Writing correct code in itself is not the most difficult and important thing programmers have to be able to do. By far the more difficult and crucial part of my profession is understanding code.

Understanding code is a factor in all of the following activities:

Finding bugs in existing code
Enhancing existing code
Using libraries from new code
Keeping a mental model of a system

And all of these activities are distributed over larger parts of a code base, whereas writing correct code is essentially a very localised activity. (Note that designing the architecture for an application or system can be much more difficult, but only needs to be done once, and is therefore not as big a part of the programmers life as understanding is).

And understanding isn’t always easy…

static int calculate(int n)
{
    int a = 0, b = 1;
    int x = 0, y = 1;
    while (n != 0)
    {
        if ((n & 1) == 0)
        {
            int temp = a;
            a = a * a + b * b;
            b = temp * b * 2 + b * b;
            n = n / 2;
        }
        else
        {
            int temp = x;
            x = a * x + b * y;
            y = b * temp + a * y + b * y;
            n--;
        }
    }
    return x;
}

In fact, this fragment goes out of its way to give as few clues about what it does as possible, and yet it implements a very simple and well-known calculation.

Two Viewpoints

Every language makes trade-offs in its syntax between being terse and being understandable. Perl^[1] is a famously terse language, where randomly mashing the keyboard is almost guaranteed to result in a valid program, whereas Java is well known to be verbose but relatively easy to understand.

Terse syntax has many obvious benefits. The terser the syntax, the more compact the code, the more source will fit on a single screen. And the more source fits on a screen the broader the overview you can get at a single glance over a fragment of code.

This is the rationale of many modern languages like Boo and Python and Ruby for example.

It seems to me though that the danger of making languages terse is that it optimises for ease of local understanding over easy of remote understanding. No matter how brief the source of a method is, if the method signature doesn’t give (m)any clues about the encapsulated functionality then using the method from another location in the source becomes needlessly difficult.

Clues

Naming is the first line of defense against incomprehensible code, and the only one that is guaranteed to exist in all languages (as far as I am aware). Classes get names, methods get names, often parameters get names. If these names are chosen well, both local and the global understanding are improved. This is why naming is such a big deal, and everyone intuitively understands this.

But often, names alone do not make the full constraints on parameters clear. This is where strongly typed languages have a further benefit. And even more so if there is at least optional explicit typing. Every parameter and return value that has a type implicitly tells something further about the meaning about the method (we’re operating on a collection, it holds strings, the result is a number, etc). I concede that small applications may be able to get away with pervasive dynamic typing, but larger systems often compensate by adding unit tests whose implicit purpose is to make sure methods operate on the right type of arguments and return the right type of results. But really, moving the typing information out of the method signature and into tests is in my opinion not progress.

Beyond this there are many more mechanisms that variously are employed to make code more understandable (documentation comments, code contracts^[2], unit tests, word documentation), but as you stray further and further away from the actual source code and method signatures itself, the connection between the code and it’s constraint becomes ever more tenuous. Often this requires intervention from the IDE and third party tools and build checks, which move ever further away from the point where a developer is trying to understand the code in front of them.

Remedies

I don’t really have a one-size-fits-all answer or a ready-made recipe to make code better, but here are a few suggestions.

Use good names – don’t just look at this from the local perspective; what would a method invocation look like? Is the invocation self-documenting? For methods with multiple parameters, try and use the parameter names at the invocation site if your language will allow you to. Consider using names to compensate for the lack of other mechanisms; if your language of choice has no explicit typing, maybe calling an argument “stringsToEliminate” is a good idea? Maybe calling an argument “positiveInteger” is a good idea? But don’t make anything more specific than it needs to be.
Use good types – even when typing parameters, pick the broadest type that will work. In .NET the compiler will keep telling you to use collection interfaces rather than explicit collection types. And sometimes creating a new type just so you can make one or more signatures more explicit may be a good trade-off; if a method only should take a value generated from a specific collection of other methods, then making the type “double” is probably not as good an idea as using a custom “Temperature“.
Use good tools – if you use any other mechanisms outside the language per-se, such as code contracts or source documentation, then you must have supporting tools as well. Source documentation is useless unless you have an IDE or tool that can “transport” this documentation from the method it is on to the place where it is invoked. Once you’re forced to go to the source of the implementation, odds are that a terse method implementation could more concisely explain what is going on already.

But first and foremost, pick a language that is suited to the problem at hand. Python is not a bad language, but I’m not sure it’s a good language for systems programming; it probably is better suited to web systems that often have many small self-contained features. Brevity is not a bad thing, as long as it doesn’t force you to work around an inability to use good names, or good types, or good tools.

Back to the Example

So, what of the example at the start of my post? It would have been much less opaque had the signature been along the following lines…

/// <summary>
/// Calculate the n-th Fibonacci number using an
/// O(log N) algorithm.
/// </summary>
static int Fibonacci(int n)
{
    Contract.Requires(n "Result will overflow int");
    ...
}

Making the implementation itself easy to understand requires a few pages of explanation, and I’ll leave that as an exercise to the reader.

^[1] Apparently, Perl users are unable to write programs more accurately than those using a language designed by chance – source: Lambda-the-Ultimate ↩
^[2] As of .NET 4, there’s a very useful Code Contracts mechanism available to C# developers; there are even plug-ins for the VS2010 IDE that can make these contracts visible as an implied part of the pop-up method documentation ↩

Book — The Time Traveler’s Wife

2012-04-06T04:14:15Z

I spent most of today stuck in “The Time Traveler’s Wide” by Audrey Niffenegger, and as I’m writing this I’m watching the movie based on the book. But first, the book.

The story was a surprisingly quick and easy read; at 540-or-so pages it didn’t take very long to read at all. Considering the amount of time travel involved it could easily have been incomprehensible, but the skill poured into this book is such that the story is easy to follow despite it’s complexities.

It’s inherently a very romantic story. And a very sad story. The foreshadowing does a good job of avoiding surprise in the reader, and leaves just the tension of the inevitable conclusions. I think that more than anything dragged me all the way through without stopping.

A note of critique is important here though; the book takes great efforts to try and give a rationale for the temporal displacement of the central character. And the continuous explanations to the people around him of his condition. It all feels contrived though, because this is very fundamentally not a science fiction story, and it would be much better for having lacked most of those elements.

Nevertheless, I would wholeheartedly recommend the book to anyone. Even those that may have seen the movie. Rather, especially those that have.

I’m sure the movie works in its own right, but watching it right after the book it’s painfully obvious how badly adapted it is. Everything feels rushed and mashed together. A lot of the natural setup in the carefully ordered scenes of the book is just missing. The central romance is not very well explained because they just dumped a whole lot of the scenes; why Clare cares at all about Henry is almost completely missing. How his travel shaped her growing up.

It feels like they have tried to make the movie more interesting by trying to increase the pace. Perhaps in the mistaken belief that the book is about time travel. And it does it so much injustice. If ever there was a book that could handily be a three hour movie and be better for it…

At best I would consider the movie a very badly warped cheat-sheet overview of the actual story. The plot points are all there, but the character motivation just simply isn’t.

Verdict: just read the book already.

Addendum; the movie just ended, and it looks like they converted all the suspense into surprise instead, and in my opinion the story is poorer for it. There is just no emotional pull at all. The longing of the first part of the book was completely missing. The happiness and contentment of the middle was weakly portrayed. And the sadness of the inevitability of the ending lacked punch because the first part was missing. A very flawed adaptation of a very good first novel.

The Time Traveler’s Wife – $17.16

On Python

2012-04-05T11:52:58Z

I’ve spent some time to familiarise myself with Python, and on the whole it’s a pleasantly terse language. Although the Python website does not explicitly say so, it seems to me that its terse syntax is meant to directly appeal to the idea that less code is better code.

And on the whole I wholeheartedly agree with that sentiment. But sometimes less code is just less code; less safety, less implicit documentation, less business-readiness (to just make up a word).

Let’s have a look at a fragment from a Sudoku solver (full article here: http://norvig.com/sudoku.html)

def search(values):
    "Using depth-first search and propagation, try all possible values."
    if values is False:
        return False ## Failed earlier
    if all(len(values[s]) == 1 for s in squares):
        return values ## Solved!
    ## Chose the unfilled square s with the fewest possibilities
    n,s = min((len(values[s]), s) for s in squares if len(values[s]) > 1)
    return some(search(assign(values.copy(), s, d))
		for d in values[s])

Before I rant, note that understanding this code in the context of the article isn’t too difficult. There isn’t a lot of code in the complete program, and it’s quite possible to hold all of the constraints and implicit type information in mind while reading through.

And yet, looking at just this fragment it’s needlessly difficult to figure out the semantics of the “values” argument, or the return value. I definitely wouldn’t be able to figure it out just from the method signature even with the documentation comment.

When I looked at some larger established samples of Python code it was striking how many large code bases compensate for this lack by having code comments that frequently approach the size of the functional code itself. The biggest problem with this kind of “contract” is that the comments are not validated by any part of the compiler, and as we all know, comments over time will invariably end up lying and contradicting the implementation.

More over, a lot of this deficiency seems to be compensated for with unit tests. I love unit tests. But why should I use unit tests to make sure method implementations continue to return values of the right types? Using unit tests to validate the contract of a method in my mind should be a remedy of last resort, not the first and only remedy.

On the upside though, yes, Python code can be wonderfully terse, and it is possible to keep a clear overview over much more functionality simply because methods are shorter and more of them fit onto the screen together.

I will definitely keep playing with Python, because there are a number of products use it as their scripting language. And I think it’ll be an excellent language to throw together once-off data processing tools.

But for anything larger than a few listings (and god forbid, involving developers at multiple skill levels and various familiarity with the existing code-base), I really need to stick with a language that does a bit more to help find flaws before run-time.

Alas, so much power, but just not enough safety. On to the next language.

Languages

2012-04-05T11:53:36Z

I have decided; I’ve been sitting comfortably on my preferred language (C#) for long enough now, whilst only casually observing interesting tidbits of other languages. It’s really about time that I crawl out of that box and try some other languages wholesale.

Currently I’m well on my way diving into Python, and now I’ve got a taste for more.

So, following, my short-list of languages that seem worth investigating in more depth:

F# (because it will complement C#)
Boo (because it has powerful meta-programming)
Python (because the web likes it, and it’s very terse)
Ruby (because it’s the other flavour-du-jour)
Some variant of Lisp (because I love braces)
Go (because AppEngine loves it)
D (because I’m curious if C can be salvaged)
Javascript (because we live in a Web world)
Scala (because Java is verbose, but the JVM is getting more interesting)
Haskell (because it is the key to the future)

I reckon that will keep me busy for a while. I am curious if it’ll impact on the substance of my thoughts about exceptions and dependency injection.

Python for now. I might blog some thoughts as I go along. Right now my mind is a little overwhelmed by the details; the broad brush strokes are fairly familiar and pedestrian.

On Code Libraries

2012-04-06T07:17:44Z

Libraries of common code have a bad habit of growing wild. I currently maintain one such library, and at just under 25k lines of code it is getting a little unwieldy and every change risks unintended consequences.

All the time the library seems to be gobbling up more and more additional code adding complexity and further headaches.

The Problem

In an ideal world the current version of the library would only contain code that is actually used by more than one application. The central purpose of a code library is to avoid duplicated effort.

In reality what has happened is that any variation on any theme that already exists in the library gets sucked into the library as well, regardless of whether there will ever be a second use for said variation.

The problem lies in the structure of the library. It wasn’t written to be modular in the Dependency-Injection sense.

Let’s say the library contains a carefully crafted component to deal with file IO, from monitoring an input directory, to file locking, to archiving and clean-up. Then an application comes around and it needs exactly that functionality… exactly… except, the scanning algorithm is all wrong; the files need to be returned sorted on that name between those underscores at the end there, see?

Now there are two possible approaches.

Either the application copies all the code of the component and adjusts the scanning algorithm in its local copy. Yes, I can hear you cringing at the mere thought of branching the code in this way. Then there are two versions to maintain.

The other solution is not much better though, because that involves implementing a feature in the library that only makes sense in the context of that single application. An extra set of branches at every extension point, and keeping fingers crossed that nothing was overlooked and no bad interactions with pre-existing code were introduced.

The Solution

I already gave it away above really. Writing the library with a foundation in Dependency Injection will give applications the ability to use a whole component whilst replacing just a single part of it with its own implementation.

Discussions on why Dependency Injection is a good idea tend to focus on test-ability, or auto-wiring of the dependencies, or component lifetime management.

In reality, the killer feature is the ability to allow a code library to define the common-scenario assembly of code parts into reusable components, whilst allowing individual applications to replace any one or more constituent code parts with its own as needed.

With DI in-place it becomes possible to enforce a strict rule that unless a code variation or component or code part is actively used by more than a single application it will not be let into the library. When the first application uses some code it will be private to the application. Only when a second use actually eventuates does it get considered for lifting into the library.

I plan to make that the new hard-and-fast rule as DI gets introduced into the code base of the library.

I’ll do a more in-depth post about DI and my opinions on its correct use sometime soon.