Leap Motion

The Leap Motion seems to be a rather cool idea.  It’s a highly sensitive, touch-free, gesture based interface reminiscent of futuristic computer and internet depictions in movies like Johnny Mnemonic and Minority Report.

My initial thoughts were that this would be an exhausting way to interact with a PC, but then I realised that I was being hampered by my own expectations of computer use (e.g. programming).  Next, I thought of how it could be used for giving presentations, all that swishing would definitely be impressive.  Then I realised that it could open up a whole new genre of computer games.  We’ve already got Kinect, but it’s not particularly sensitive and is aimed at using your whole body.  This would allow for finer detail – maybe some thing like a computer version of the classic Operation game.
I’ve signed up for the free Developer SDK and if I get it I may indeed try to make an Operation clone.

Pattern Matching to the Rescue

Today I was pair programming with a colleague to add some new functionality to an existing, and slightly gnarly, codebase.  Whilst there we a found an existing class which we should reuse, if only it wasn’t so tightly coupled to another object.

It’s purpose was to filter out a lost of parent objects by a value in a child object. It would loop through the whole list of parents examining each child. We wanted to reuse the class, but we were only handling the child objects and creating a bunch of parent objects for this purpose would be incredibly wrong. We needed to refactor to decouple, but how?

IList filteredParents = _filter.FindMatch(parents);

Suddenly, a light bulb goes off in my colleague’s eyes and he proceeds to turn the problem on its head – pattern matching.

We refactored the filter class so that it accepted a single child object and returned a bool indicating whether the match was successful. Then, using Linq we applied this pattern to the list of parent objects to filter out those with matching children. It was beautiful.

IList filteredParents = parents.Where(x => _filter.FindMatch(x.Child));

We can now reuse the filter class on our list of child objects without a need for the parents.

I realise that this is normal practice in the functional world, and I’ve toyed with it before, so I’m disappointed that I didn’t figure this out sooner, but it’s amazingly simple when put into action.

CoffeeScript browser compile works inline

Decided to spend an hour or two trying to get my WebGL Lessons in CoffeeScript working, but I still couldn’t figure out why it refused to compile in the browser as a separate .coffee file.  I had specified the text/coffescript type on the script tag and the mimetype on the server side.

Very stumped, very frustrated and just gave up by putting the content into the script tag within the html file.  It seems to like that much better – it works.

Now, to move onto lesson 2.


Just a quick note to mention a really good Git Tutorial site: GitReady.
I personally like how it breaks down the tutorials into Levels, so that you know where to start reading and what to get a grasp on first.  Diagrams and the friendly language used are also very good.

CoffeeScript Closure?

Following on from my adventures in CoffeeScript and WebGL I’m having trouble with the CoffeeScript compilation in the browser.  If I compile into JavaScript everything runs fine, and simple HelloWorld CoffeeScripts will work too.  I can only guess from what I’ve read elsewhere that I’m stumbling into some issues with the closure wrapping and I’m going to have to seriously scratch my head to figure this one out..