lixo.org

So while I’m on what ThoughtWorks calls the beach, which is the really nice place to go when you’re not assigned to a project, I’ve been playing with OpenCV, a lovely opensource library originally developed by Intel. It’s got a gigantic set of really interesting features related to real-time image manipulation and especially around real-time motion detection and face, hand and body recognition. If you’ve never played with computer vision, I highly suggest giving it a try. It’s tons of fun – and you get to brag about actually knowing what the hell a cascade of boosted classifiers working with Haar-like features means.

While I’m at it, I’ve been building a very small set of wrappers to make it all look a bit more OO (and probably a lot easier to read and write). As the README says:

This project has been set up only as a way of representing the knowledge the authors have gathered about OpenCV and is not intended to be a complete set of OO wrappers for the library – but contributions of any kind are definitely welcome.

Still, I’d much rather see code like:

currentFrame.sub(initialFrame).threshold(thresholdAmount)

than…

sub = cvCreateImage(...)
cvSub(currentFrame, initialFrame, sub)
result = cvCreateImage(…)
cvThreshold(sub, result, thresholdAmount, 255, CV_THRESH_BINARY)

But then maybe that’s just me.

Oh, while I’ve got your attention – doesn’t Apple make or sell those external Firewire iSights anymore? I managed to get ahold of one, and they’re lovely. Now that pretty much every Mac laptop has a built-in camera, maybe there’s no point, but they’re still incredibly useful in these kinds of setups.

How many times have you had a conversation that started with “so while I was in the shower last night, I figured out how to…”, or something to that effect?

I naturally set out some time to think and daydream a little – about 10 minutes every two hours or so, while I have a cigarette (unfortunately, the nazi smoking ban hasn’t been enough to force me to quit just yet): most smokers will tell you that the hardest thing to give up are the ad-hoc social interactions you get with other people who wouldn’t otherwise only chat with or even meet.

But you don’t need to cover your lungs in filth just so you can have an excuse to think. When faced with a problem you want to solve, or even to find out where the real problems are in the first place, try what the native americans called the Medicine Walk:

The medicine walk is a day’s journey upon the face of the earth. It is also a mirror. In it, signs and symbols of your inward journey are reflected. The walk is a distilled form of the vision quest.

It doesn’t need to last a day, and it doesn’t need to sound like such an epic spiritual crusade either. Just get up and walk to place that’s about 10 or 20 minutes away, and that’s it. Take no distractions with you – no iPods, no phone, just about enough change to buy a cup of coffee once you get there, and then head back. Pay attention to the sounds, other people going about their lives, cars and buses passing by, the architecture of buildings, the colours and shapes and symbols around you. Look out for patterns, coincidences, and most importantly, pay attention to the internal dialogue going on in your head: it’ll be trying to pick apart the problem at hand, and you can follow some basic retrospective techniques to work some of it out once you’re in that state of mind.

After doing that on purpose for a bit, I noticed that going out for a walk works even better with a pair. You might need to take a longer break – I found that 20 to 30 minutes of walk time is ideal. That’ll give you about an hour to think, talk and socialise the ideas and problems at hand. Also, notice how easy it is to work out disagreements and suggest new things to try out; promenading has very different brainwave generating patterns, and is probably one of the best tools I have to stimulate creative thinking.

The Binary Guitar is a little experiment (took about a day or two to put together) I played with a couple of months ago, and I thought it was fun enough to share.

Installation is seriously clunky – I have never tried it on anything but MacOS X Leopard running on a MacBook Pro so far, and even then there are lots of moving parts, but if you go through the pain of setting it all up, you should have some pretty decent sounds coming out of a USB Guitar Hero Controller (mine’s the X-Plorer, which comes with Guitar Hero II for the Xbox 360).

• PureData
• Quartz Composer
• MidiPipe
• Xbox 360 Controller Driver
• GarageBand or other software that understands MIDI

Running:

1. Install everything
2. Open PD to MIDI.mipi in MidiPipe
3. Open Binary Guitar.pd in PureData
4. Go to Pure Data / Preferences / MIDI settings… and point the MIDI inputs and outputs to MidiPipe
5. Open Binary Guitar.qtz in Quartz Composer
6. Connect the X-Plorer Guitar. If everything’s working correctly, the Quartz Composer viewer should be black (rather
   than a checkered pattern)
7. Open GarageBand, select your favourite virual instrument.
8. Rock on!

Grab it in my github repository.

Yes, everything. Put it in a namespace. Everything. No exceptions and no excuses, unless yours is “I have just been thawed.” In this case, I want to be the first to warmly welcome you to the 21st century.

Here’s a simple and reasonably OK way to do it and be nice to your friends, other libraries and the world at large:

var Article = Article ? Article : new Object();
Article.title = “Report: School Shootings Help Prepare Students For Being Shot In Real World”;
Article.save = function() {
  alert(”Saving ” + this.title);
}

You could save a few keystrokes, though. Just use the object literal notation directly:

var Article = Article ? Article : {
  title: “Report: School Shootings Help Prepare Students For Being Shot In Real World”,
  save: function() {
    alert(”Saving ” + this.title) 
  }
}

These two last examples are great if you’re not that concerned about exposing the ‘title’ attribute to the rest of the world. If there is a chance that problems could arise if some other piece of code changed it directly, there is a solution:

var Article = Article ? Article : function() {
  var private = {
    title: “Report: School Shootings Help Prepare Students For Being Shot In Real World”
  };

  var public = {
    getTitle: function() {
      return private.title;
    },

    save: function() {
      alert(”Saving ” + this.getTitle());
    }  
  }

  return public;
}();

I find this a bit hard to get used to, after so many years of developing in languages that explicitly allow me to set access control. It makes sense, though: by creating an anonymous function that returns the object I want to define, and then immediately calling it (note the ‘()’ at the last line), I can hide whatever I don’t want other parts of the code to see - it’s all tucked away in the local context of that anonymous function.

After reading A Theory Of Fun, I started seeing projects (and many other human activities) modelled as a game. In the book, Raph Koster describes a series of game development rules, and I found that they can be mapped to the software development project domain with some interesting results:

• A project, just like a game, has roles. In projects, they’re specific to each role. These rules define the possible actions for each of them. (This one isn’t described in the book, but I added it just to contextualise.)
• Role-specific rules should be unambiguous, intelligible and apply to all people in that role.
• No project can be developed without the meaningful interaction of the people in all roles.
• The outcome of a project has to be uncertain, otherwise it loses its appeal.
• Rules and representation of a project are not independent but interact with each other.
• People require clear and immediate feedback to understand the relationship between action and outcome.
• People require a clear goal so they can perform meaningful actions within the project world.
• Conflict and competition against time, budget and scope are essential for everyone’s motivation.
• The challenges of a project should match the skills of the people involved: neither too easy (boring) nor too difficult (frustrating).
• Projects can be developed without the need for even skill sets among the team. Instead the people learn through interaction, and this should be allowed and encouraged to happen.
• People perform actions within the project world and observe how these actions change the state of the project.
• People form a hypothesis about the meaning of a deliverable or action on the basis of their studies.
• People recognise and learn fundamental patterns within the project and can apply these to different situations (and, of course, other projects).

The more I look at these, the more this matches the way I see people working in agile projects. I’m sure there’s a lesson to be learned here…