lixo.org

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…

Developers in most projects I have seen try to establish some sort of convention around leaving TODOs in the code. The most common seems to be “if you see something funny, try to fix it immediately, but if it’d take too long and you’ve got something else to worry about, leave a comment next to it starting with TODO, your initials and maybe a date”.

You know what? Using comments for that is not as cool in Ruby, Python or Java, which has had static imports for a while now. How about creating a TODO method that takes in the initials, date and comment text, or whatever else you might find useful?

import static my.project.DevelopmentUtils.TODO;

…

public void doStuffThatSmellsFunny() {
   TODO(”CV, 21/jan”, “Clean this mess up after fixing #3849″);
   …
}

There are some advantages to this: you can actually put some code inside that method to do, say, logging. Another good thing is that now the TODOs can be tracked using the same refactoring tools and features of modern IDEs as just any other code in the project.

It may seem a bit cumbersome, but I’ve been trying that for a few days now and it feels quite pleasant to use. I got my TODO method to just spit out the message to the console so when I run tests, I can quickly get an idea of what areas of the code touch stinky or incomplete ones.

I’ve been hanging out with friends in São Paulo over the last few days, getting unreasonably drunk, eating too much and attending the Google Developer Day, not necessarily in that order, so I missed the announcements that Facebook had opened up their API.

As a software developer with a healthy affection for all things related to network effects and emergent behaviours, this is brilliant.

The applications provided get added to a central registry inside Facebook, from where you can pick and choose the ones you want added to your profile. They still have to be deployed separately (as Facebook doesn’t host them for you), but the user doesn’t see any of that - all of it is a very simple and well-designed UI, so “installing” an application to your profile is a hell of a lot easier than installing a desktop application to your machine, and gives the user instant feedback.

Leaving important considerations on data ownership and privacy aside, which I won’t comment on since I haven’t read the agreements in much detail, I can see this thing eating a huge chunk of what we nowadays use disconnected internet applications for. Instant, mobile and email-like messaging, discussion groups, photo sharing and some other basic kinds of applications are already there, as are little data aggregation tools, like the del.icio.us and Magnolia importers. If this API is successful (and so far, nothing suggests otherwise), other social networks could as well be dragged inside Facebook if they support any kind of external API. And, if not, there are always screen scraping tools like Hpricot.

Something to watch out for, definitely. Ten years ago, we were wondering what kinds of applications could be made to run on the internet. Facebook is making us wonder what kinds of applications can be made to run on top of a social network. Which ones would you try?