Have you seen Green Goose? They're doing some beautiful stuff with sensors for consumers: turning everyday activities into games. I love the mundanity of it all: keeping the toilet seat up, brushing your teeth, walking the dog. One of their apps is called "BrushMonkey". It doesn't get any better than this.

They've been around for a little while - there's a story on RWW about them from early 2010, but they seem to have changed tack since then, away from financial monitoring and towards fun'n'games. Here's an interview with their founder from December last year. Green Goose seem to be spreading themselves thinly across many applications: "We’ve got about 50 or so other sensors in development right now that we will fairly quickly release over time".

Their hardware seems similar to Little Printer, in that they have their own gateway (the "station egg") which plugs into the spare port of a hub.

If you're at all interested in this sort of thing, you might want to wander along to the Smart Interconnected Devices Hackathon at Google Campus this coming Saturday: a chance for Android developers to Plug Things Together in interesting configurations...

I posted this onto G+ last week, and totally forgot to crosspost it here:

My superoptimiser has found a more efficient version of Math.abs() than that which ships with the Java runtime, which I think demonstrates that the approach of superoptimisation /can/ have merit for VMs - whether by producing shorter code than the optimiser inside the Java compiler, or by finding non-obvious algorithms. Either that, or the Math.abs() that ships is a weak implementation...

I'm now running a search for Math.max() and Math.signum() (the latter being the target of the original Massalin experiments). My suspicion is that signum() will need a longer sequences than I'm currently generating; I can add one operation to my current sequences (which take 13 hours to generate on a single EC2 instance) by parallelising the process across IRO 500 EC2 machines. Going beyond that would need 25,000 machines which at $1,500/hour will be well out of my budget. So, fingers crossed...

It's probably worth optimising the code further, but I'm completely out of ideas for order-of-magnitude improvements and I've spent quite a bit of time inside a profiler over the last couple of weeks.

Still, feels like I've achieved /something/ here.

Since then, a couple of small updates: I've run a search for Math.max() and found another sequence shorter than that which ships with the JVM; so in two cases I now have superior superoptimised code. Before I start the write-up proper, I'm spending another week looking into a more efficient Math.signum() function by parallelising the superoptimiser across a few hundred Amazon EC2 instances; I think this will buy me another instruction, which might juuuuust be enough to get something. We shall see.

Steph's pointed to this interesting set of documents. I'm going to dip into them over the next few weeks, but particularly enjoyed hearing how they're structured:

"I have found that, having started this set of notes in 1990 in the (for me) novel medium of hypertext, it has been difficult to tear free of it: my attempts to lend hierachical or serial order have been doomed to failure. Further, as ideas and these web pages have evolved, it has been important for me to be able to reorganize my thoughts, grab a new leaf, shake the tree and regard it as the root. So the reader needs to be aware of this, that each page may be an attempt to put across a given concept serially, but if you are looking for an order of concepts and subconcepts, you have as much hope as you would with words in the dictionary. "

I've been following the Quantified Self for a little while now, ever since Colin Hayhurst first mentioned them to me; and Kate has a similar enthusiasm for the quantitative, so we've both been tracking aspects of ourselves: between us weight (Withings), diet (manually), sleep (Zeo), and exercise (Runkeeper, Fitbit).

One of the modules of my Master's this year was Pervasive Computing, in which we spent a great deal of time looking at sensors and the real-world difficulties of extracting useful information from them. I did a project looking at LEDs, light sensors and morse code which I wrote about briefly here (and will post the full text of, once the course is over).

One key lesson from this was the difficulties of ensuring consistent useful results from different sensors; so when I noticed that Fitbit offers to track your sleep patterns, and Kate's Zeo did the same, I thought it'd be interesting to compare the results one gets from each. Fitbit straps to your wrist and detects hand movement, inferring sleep from a lack of such movement; Zeo monitors brain waves.

So a few nights ago I strapped both to myself and managed nonetheless to drift off. Here's what the Fitbit told me about my night:

Here's the Zeo for the same time period:

I was quite surprised at how close they both were. Here's the two graphs scaled to an equivalent size and superimposed:

This seems to suggest that I'm twitching physically not just when I wake up, but when I move between different types of sleep…

As a result of this, I'm much more confident in both products, as they seem to be measuring something consistently using two completely different methods; which, funnily enough, is an approach which my course tutor Dan Chalmers covered in his pervasive computing textbook...