Teams

I'm having more eureka moments reading Jeff Atwood's Effective Programming: More Than Writing Code, than my average trip to the dunny.

This last one got me though, man.  I feel like a dumb-ass.

Work's been difficult the last few years, I've been uber inspired for the company to do great things but every time I suggest something I get excuses - or agreement but nothing comes of it.  So begrudgingly, in a very "I told you so" manner, I started to do the hard yards myself (which has been really cool actually, it's lead to some interesting stuff), but ultimately I'm the little red hen when it comes to getting any help.

Then Jeff came into my life, albeit in the form of a $2 blog to book (best damn money I've ever spent).  The gold nugget I found was that my approach sucked.  I was turning my frustration against the team which I realised wasn't working but didn't see a way through.  The trick, apparently, is to care about the people I work with and want to help them.

I do, for true, but I lost my way.

So yeah, this rings true for me.  And it's something I don't need to fake.

Whether this gets the team pulling together or not's the next question, but first thing's first: sort myself out first before trying to sort out others.

Boyd's Law of Iteration

I'm reading Jeff Atwood's Blog to Book, Effective Programming: More Than Writing Code and really enjoying it.  Straight away it's informative and inspiring.

I'd like to comment Boyd's Law of Iteration though, as it struck me as not quite right.

Jeff states Boyd's Law of Iteration as "the speed of iteration beats quality of iteration" but I think the mechanism is more evolutionary than that - it's to make trial and error as fast and inexpensive as possible.  I don't think quality has much to do with it.

Trial and error is a groping search, so it's relevant when the environment is dynamic or when the next move is unknown.  This is life.  As soon as we think we've arrived at our destination or solved all our problems, we'll stop moving and sink into the shifting sands.

In fact, I often hear the guiding question, “what problem are we trying to solve?” but I think this is not necessarily a good starting point.  Apple aren’t solving any problems, they’re showing us goods and services we didn't know we wanted.

Let’s not be lead by market fit, let’s be misfits and lead the market.

PS3 Tribunal Order

You might have guessed I haven't been maintaining my blog. Thanks for all your comments, I'll try to keep on top of things from now.

Here's the order from the tribunal.

"Sony Computer Entertainment New Zealand Ltd and Electronics Boutique Australia Pty Ltd are jointly and severally liable to pay..."

PS3 Story on Target

I got interviewed by Target the other day, so I might be on TV3 some Tue soon. They have a few other customer stories and they're going to ring Sony directly, so it should be interesting to watch.

I took down the PDF of the court ruling because it had my name, address and phone number. TV3 suggested it might be a good idea before the programme's screened. If you need it, let me know and I'll black out the personal bits and republish.

Otherwise, the main posts and comments for the PS3 hearing are here and here.

The Repository Pattern and Linq

I've just been around the block with the Repository pattern and Linq, and here are my thoughts.

The Repository pattern is designed to hide all data access concerns behind a facade, so for clients of the repository, quite simply, there is no Linq. I've seen a lot of people try to have their cake and eat it too, where they put the repository pattern in place then try all manner of witchcraft to let the client use Linq through it. This is bad. This is ice-skating uphill. Don't do it.

If you have a small project and want to use Linq for business logic, don't use the Repository pattern. If you have a large project and want a testable facade, or a storage agnostic repository, use the pattern, but make sure you pass domain objects to it, not data access objects.

Blogging velocity has slowed somewhat. Probably because there was so much code to post on my Rx Framework attempt I ran out of gas, then we had a baby. So bugger it, I wont post nothing on it and continue as if I wasn't going to.

So, I'm on the deck bbqing some chicken with a beer and laptop.  What to post?

I'll reflect on work. Fun times.

Over the last several years I've been building an Ajax UI framework for porting Windows applications to the web.  The first version only worked in IE and I've been working on the next version which will, theoretically, work in all browsers. But now a client is paying to have the first version work in FireFox and Safari as well.

I can't say I mind this too much and it (touch-wood) is turning out to be easier than I though.  Although I realise the devil is in IE6.

First step: Consistent look in IE7+, FF and Safari. Get everything looking the same- it doesn't have to be pretty but if all browsers start with the same foundation that isn't too bad, it can be improved from there.

This turned out easier than I thought by using the strict doctype and a good CSS reset. Removing any -moz- styles and the odd JavaScript fix for FF.

Second step: Consistent behaviour.

Third step: Carefully get it working in IE6.

Fourth step: Make it pretty.

My chicken is burning.

.NET Reactive Framework

In our game, stories are first-class beings -  invisible meddlers. They move around, observe and manipulate the world according to their plot. They wait for triggering conditions or patterns of events to occur, and then spring to life to advance the story.

In our case, we have an evil story waiting for the betrayal of a paladin. When this happens, the story will unravel a series of events, involving a horror, a child's toy and a man with a poisoned name.

How does the story listen out for the betrayal? Our game follows an event-driven design so we'll need to do some event-processing.

I recently saw Erik Meijer's presentation on .NET's up and coming Reactive Framework (Rx), which looks pretty cool and the right tool for the job. There are already a couple of other reactive programming frameworks out there, like Continous LINQ and Reactive LINQ, but I thought it would be interesting to see what's involved in writing one, so here we go.

Rx is the mathematical inverse of IEnumerable, dubbed IObservable. So instead of being able to iterate over a stream of objects you get to listen to a stream of events.

No big deal really, but the cool thing is that it supports Linq, so you can query over event streams.

IObservable<ICombatCommand> paladinFleeCmds =
  from cmd in CombatMediator.CombatCommands
  where cmd.CommandType == CommandType.Flee &&
        cmd.Subject.CharacterType == CharacterType.Paladin
  select cmd;

paladinFleeCmds.Subscribe(cmd =>
  {
    IStoryPoint betrayal = new Betrayal(cmd.Subject);
    story.RegisterStoryPoint(betrayal);
  });

I'll post how to implement this kind of Linq-to-Events shortly.