People are cool and like free software

MarcoPolo is free software (as in speech and beer). I do it for the love of programming, and for the challenge of tackling a problem and coming up with a useful, original solution. It's very much a part-time pursuit, and I don't get to it as often as I'd like, but that's fine too. I'm in it for love, not money or acclaim.

I remember not long after releasing MarcoPolo someone emailed me to ask if they could donate. I was flabbergasted. I didn't understand. He convinced me to add a PayPal link to my website. Someone else suggested an Amazon wish list, so I added one of those too. I seem to get a trickle of donations from both. It's far from enough to live on, but it handily covers my web hosting, and gives me some entertaining reading and listening. And every time someone donates it gives me a warm buzz. Why? Because no-one is legally or morally obligated to do that, but they do it anyway. It validates what I've done as something that matters to someone else, and matters enough for them to give up some money. Even a "thank you" email contributes to that, and I love reading that people's computing lives are a little more simple or joyous because of software that I wrote.

So a big thank you to everyone who has sent me a donation of any kind, or an appreciative email. I hope I can strive to keep making gradual process with this massive rewrite, and produce a piece of free software that's even better than before.

JavaScript rules

I'm fairly happy with how the sensor framework is looking now. It is solid and reliable, resilient to crashing sensors, and fully KVO so sensor value changes get reflected immediately.

The next step is to design the rules. In the past there have been many requests for more complex rule types (though people usually don't phrase it that way). Simple things like saying "when this device is *not* plugged in, ..." or "when *both* of these devices are present, ..." are impossible to do directly with the old MarcoPolo. I had originally planned to make MarcoPolo accept the wrapping of existing rule types in boolean operators (NOT, AND, OR), but now I think I have a better idea.

Here's the concept: embed V8, and allow rules to be written in JavaScript. There would be pre-made buttons to create standard matching rules so that most users wouldn't notice the difference, and power users would be able to write arbitrarily-complex rules in an expressive programming language.

Here's what a simple USB matching rule might look like:

function match(valueSet) {
  if ('usb' in valueSet) {
    var devs = valueSet['USB'];
    for (i = 0; i < devs.length; ++i) {
      if (devs[i].vendor_id == 0x046D &&
          devs[i].product_id == 0xC03D))
        return true;
    }
  }
  return false;
}

That would be a bit unwieldily for something that should be easy, so there can be builtin functions:

function match(valueSet) {
  return mp.hasExactMatch(valueSet, 'USB',
                          {'vendor_id': 0x046D, 'product_id': 0xC03D});
}

Of course then it can get complex very easily:

function match(valueSet) {
  return mp.hasExactMatch(valueSet, 'USB',
                          {'vendor_id': 0x046D, 'product_id': 0xC03D}) &&
         mp.hasExactMatch(valueSet, 'RunningApplication',
                          'com.apple.Xcode') &&
         !mp.hasExactMatch(valueSet, 'RunningApplication',
                          'com.apple.iTunes');
}

That rule would match if my mouse is plugged in, Xcode is running, but iTunes is not running.

Anyone got any thoughts? Can you see this being beneficial? Or is it just massive over-engineering?

Learning New Stuff

Here's something cool: in the 16 months that I've been working at Google, I've learned five new programming languages. Yep, five: Python, JavaScript, Sawzall, and two others that are so secret that I can't tell you their names. It's been an awesome learning experience, and I feel like the best is still yet to come.

I've still studiously avoided using Java, though.

Sensor IPC

I've got a basic sensor IPC going now. Similar to Chrome's process model whereby every tab runs in its own distinct process, MarcoPolo 3 now has each sensor running in its own distinct process. This means that an unreliable sensor, whether by memory leaks, buggy Apple APIs or my own mistakes will not bring down MarcoPolo itself. Nifty!

So far it only does the START and STOP messages, but it's a good start. Here's to more reliable software! If you are tracking the git repo, update it and then you should be able to run the SensorTester app.

You could even run the sensors directly:

$ xcodebuild -target SensorTester -configuration Debug
$ build/Debug/SensorRunner build/Debug/PowerSensor.sensor

Type in "START" or "STOP" and you'll be interacting with the sensor in the same way that MarcoPolo will be.

Context view (Part 2)

Below is another screenshot of the context view. The only visible changes are corrected alignment of the context group state (the currently "selected" context), and the button that will remove contexts and context groups.



The lack of visible changes belies the massive changes under the hood. It's now using bindings to connect the NSOutlineView to an NSTreeController that is directly using the context models. This will make my work much easier in the future.

Context view

Here's a screenshot of a development version of MarcoPolo 3, showing the new context view:



It's still obviously rough around the edges, but it shows off the new important concept of context groups. In this situation, I can track my physical location context independent of my network location context. This will make it easier to have complex rule/action setups. Of course the context groups themselves are configurable just as much as the context trees, so you could have, for instance, a mood context group that is managed by a collection of light sensor rules.

HTC Dream (G1): First Thoughts

As a full-time Google employee, I got given an HTC G1, the first commercially-available Android handset. It's got a nifty pattern etched on its back (specially for Google), and is completely unlocked.

I'm not sure what I'm going to do with it. I'm doing just fine with my iPhone (only about 4 months old), and there's enough shortcomings that rule it out as a full-time replacement:

• No multi-touch (this is only a software issue, though)


• No support for multiple Google accounts


• Non-standard headphone jack

The lack of multi-touch is a killer, for me. I took a quick photo soon after charging the G1, and tried to zoom in on it by using the iPhone-standard pinch manoeuvre. I also found the Google Maps application on the G1 quite clunky without multi-touch. Ugh, patents suck.

The keyboard is quite neat, though. I've gotten used to the iPhone's on-screen keyboard, but I can appreciate the tactile feeling that only a physical keyboard gives.

The fact that I can write software and run it on the physical phone is a big plus. I'm not pleased that I'm expected to pay $99 and ask Apple nicely before I can put my own software on my own iPhone. I haven't written anything yet for Android, though.

Finally, because it's officially a developer phone, it's fully unlocked. It's a quad-band phone, so it might work well as a travel phone. I don't travel too much (just twice this year), but the G1 could come in handy for my next trip, whenever that is.