Self Tracking

Thanks to one of my housemates I’ve gotten interested in self tracking lately. The basic idea is to gather data about yourself and learn from it to optimize your life. Simple example: I could log my mood throughout the day as well as the number of hours of sleep I get. Then I could correlate my average mood with hours of sleep, and I could find out the amount of time I should sleep to maximize mood. Obviously there are a lot of complex correlations you can make, depending on the amount of data you gather. There’s a whole community of people interested in this, called the Quantified Self movement.

I’ve tried self tracking before, but my past attempts all failed for a few reasons:

  • Tracking was cumbersome: I did most of my tracking in a spreadsheet on my laptop, but having to manually enter a lot of data was annoying and interfered with whatever I was doing. Plus whenever I was away from my computer I had to take notes on my phone, which took even longer and required transcription later. A simpler, more mobile solution would have been better.
  • Tracking was hard to remember: I tried to track my meals, but sometimes I would forget to write down what I had for breakfast. The same thing happened with tracking the hours that I went to bed and woke up.
  • No good reminder system: I wanted to track my happiness level throughout the day. At the time, I attempted to do this with alarms on my phone. This was a bad plan, since the alarms annoyed my girlfriend (I would spend a few seconds getting my phone out of my pocket to turn them off), and couldn’t be easily randomized (I wanted to sample happiness throughout the day as randomly as possible).

I’ve decided to take another stab at self-tracking, and I think I’ve solved all three of the above problems.

  • Simplify logging with a web app: Instead of a spreadsheet on my desktop, I’ve built a tiny web app which pre-fills data like the date and time and makes it easy to select frequent locations and people I’m with. When I want to download the data, I just format it as a CSV in a special results page. The app can be used from both my desktop and my phone, so all my data is in one place and is much faster to use than before.
  • Generate random calendar appointments: Calendar appointments are much better than alarms for simple reminders. Rather than ringing forever, calendar appointments pop-up on your phone (or desktop), optionally play a short sound, and then sit quietly until dismissed. Using a library for writing ICS (iCal) files, I generated dozens of random appointment reminders for tracking my happiness and imported them into a new Google calendar, which gets synced with my phone.

I’m three days into the experiment and it’s going well. The less effort I have to put into tracking and remembering to log data, the more likely I’ll be to continue it long term. Hopefully in a few months I’ll have some interesting data to talk about.

Analog Decoding

I recently stumbled across the personal website of Matt Sarnoff, a fellow CMU alumnus who’s done some cool side projects. My favorite one is a little thing called Millitext.

Millitext is a way to encode messages so that they can only be read by displaying the encoded letters on an LCD monitor and using a magnifying glass. It’s a “sub-pixel” encoding. Each pixel on your screen is actually three bands of red, green, and blue sub-pixels. Due to the limited resolution of the human eye, from a distance these bands blend together into normal colors. By sending a certain color to a single pixel on the screen, you can control which parts of the RGB bands are “lit” and which are not, allowing you to spell things on them. So this:

becomes this:

What I love about this is how decoding the digital pixels requires a very specific analog medium. Display the image on some other type of monitor, or print it out on paper, and it won’t work. Of course, this is true for all information. You need a specific decoder to make sense of it. But what’s interesting in this case is that the decoder happens to be almost a side effect of some particular piece of hardware.

It would be fun to see data encoded in analogous ways for our other senses as well. For example, you could construct an audio recording that only made sense when played in a particular cavern, where the echoes would be timed correctly to make your message audible. It would be a fun puzzle to be in that kind of space and have to move around to find the position where the audio made sense.

What I learned from building an online board game

I recently finished an online version of Homesteaders, a board game by Alex Rockwell. Building the app was a great learning experience for writing maintainable code and designing a web app.

Listed below are a few of the things I learned. A lot of it is obvious, sure, but I had seen this advice before and still ignored it. Consider me thoroughly humbled.

Plan ahead

When I started coding Homesteaders, I thought I had a “pretty good idea” of how the game worked. I also thought this meant had a pretty good idea of how to structure the code. This would have been a decent approach, had I been coding tic-tac-toe.  I was able to quickly hack together a skeleton of the full game, which progressed through player turns and game phases successfully, but as I started to implement the more complex components of the game (like auctions, selling goods, and purchasing buildings) I realized I had forgotten about dozens of special cases and quirks in turn structure that conflicted with my architecture. The result was a kluged mess of duplicate code and labyrinthine paths of execution that made debugging a painful experience.  What I should have done was write up a small design doc, or sketched one out on paper, that described all the major components of the game and enumerated all the special cases that would come back to haunt me later. This probably would have helped me come up with an architecture that handled Homesteaders’ unusual turn structure more elegantly. Not all games are as complex as Homesteaders, but at the very least make sure you know what the big picture is before you start to code.

Read the rules

This advice applies just as much to playing games in real life as it does to coding them. Board games, unlike video games, can be played wrong. If you misread the rules, you end up playing an entirely different game than the designers intended. If the error is small it can go unnoticed for a while, until you play with someone else who learned the rules from a different source than you.  I didn’t re-read the full rules to Homesteaders prior to building my online version, and ended up having to change a lot of code when a friend explained I had been playing with the turn order wrong all this time. It’s also embarassing when you demo a game for one of the original playtesters and you realize you got the rules wrong…

Test Test Test

And then test some more. The first few full games of Homesteaders I played with other people had game-breaking or annoying bugs that could have been avoided if I had simply played out a few full games by myself, start to finish. Don’t waste your players’ time. Planning can help avoid bugs, but it’s not a substitute for thorough testing. Don’t be lazy!

Interface feedback is essential

Your interface should be so simple and so easy to use that someone who’s never heard of the game can play it and understand what’s going on. Everything should have a label, and buttons should be responsive when highlighted and pressed. I’ll admit I got lazy here, since the current Homesteaders interface needs a ton of work, but it’s vastly better than the original.

Zune Woes

I love Windows Phone but both the mobile version of Zune and the desktop app have some serious issues.

  • You can’t jump to a position in a song while on the phone. Instead you have to fast forward or rewind to the part you want.
  • When you fill up your device, you have to clear space on it by “unchecking sync groups”. It is unclear what this means and what the consequences are.
  • If you search for anything, it waits to show you online results before the results in your library. My library results should appear instantly, and I almost never want to search online – I’m usually looking for a particular song in my library.
  • Items that you search for cannot be played or added to a playlist from the search results screen. You have to select the individual search result first. So, if I want to add multiple search results to a playlist, I have to click each of them individually and add them.
  • There’s no real rating system. I’d like more variation than just “heart” or “broken heart” with my songs.

One gripe I used to have was the shuffle and repeat options were undiscoverable on the phone, but that has been fixed with the Mango update. Hopefully Microsoft’s paying attention. How can they expect to convert customers to Windows Phone if its software is a pain to use?

Writing a Cryptogram Solver

As a weekend project I wrote a cryptogram solver. You give it a cryptogram and it figures out some possible translations of that cryptogram, ordered by probability. You can also use it to make your own cryptograms.

This is a project I’ve wanted to do for a while and was also a good programming puzzle in itself. If you like puzzles or solving cryptograms I highly recommend writing one of these and coming up with your own algorithm. The one I came up with turns out to be close to the same one used by Decrypto: Starting from the largest word in the ciphertext, find all possible translations for that word in order of frequency. For each translation, recursively translate the rest of the cryptogram with the added constraints (i.e. added mappings from cipher letters to plaintext letters found from the new word). There are a few other hacks thrown in to fine tune performance. For example, it tries solving the full cryptogram, and then removes each word one at a time and tries to solve without having seen that word. This is useful if your text has long proper nouns that also happen to decode to real dictionary words.

It turns out this method is pretty fast if you have a good dictionary sorted by word length and word frequency. The dictionaries I found online included too many words that no reasonable human being would ever use and weren’t sorted by frequency, so I made my own dictionary by examining the text from a bunch of books on Project Gutenberg. Because I only used five books there were some problems with this approach (e.g. “EYRE” and “FINN” show up as high probability four letter words) but the solver works pretty well in spite of this.

As a side note, in the process of testing the solver Julia and I discovered some interesting things you can do with a cryptogram solver. Feed a solver a palindrome and it will give you all other palindromes of that length with those word breaks, and if you feed it the letters “abcdef…” etc. and you’ll get all isograms of that length.

You can check out the source code on GitHub here, or download the Windows installer and use the tool from here. I wrote this primarily for me so it hasn’t undergone lots of testing. Let me know if you discover any bugs or have ideas for improvements.

Window Manipulation with the Microsoft Touch Mouse

Julia and I won first place in the Most Useful category at the UIST 2011 Student Innovation Competition! Our application used the Microsoft Touch Mouse to move windows around by doing a three finger click anywhere on the window (I don’t understand why Microsoft hasn’t added this already in Windows 8 ) and also lets you resize windows with a two finger gesture on the mouse.

Sliding Block Puzzle in HTML and JavaScript

I’m starting to learn web development with HTML and JavaScript. To get started and to teach myself how to do basic interactions and animations, I built the 15-puzzle as a web page. You can try it out here.

Every time you play the script selects a picture and board size at random. All games are guaranteed to be winnable :)

To see how it works just view the source for the page. The code is pretty basic, so no promises that I did anything in the best possible way. I’m still learning after all.

Photomosaics

The other day I had the urge to write a photomosaic program. So I did.

The code is in Python and uses the Python Imaging Library. It’s pretty straightforward: First it builds a database of your photo library, storing the average color in every photo. Then, given an input photo, it breaks up the input into tiles and for each tile inserts a picture that has a similar color. I added a small optimization that looks at the quadrants of every tile but didn’t notice any big changes in the output.

Surprisingly, the bottleneck was in downsampling pictures, and not searching for which picture to insert. In retrospect this makes sense. I only have 3965 pictures, and a linear search through those is faster than resizing images that have over 3 million pixels each. Resizing takes much longer if you specify antialiasing too, which you have to do if you want the result to look decent. I optimized this by saving every resized thumbnail so that images that are used more than once in the mosaic only have to be resized once.

Here’s a link to the code. To use it, open it and change the settings at the top of the file. Then run it :)

I’m no Python expert, and I’m not claiming I did this in the fastest/shortest way possible. If you have any suggestions for how I can improve the code please comment or send me an email, I’d love to hear them.

Juggling Motion Capture

One of my housemates works for Disney Research Pittsburgh. Specifically he’s been working with the robot skeletons they use in rides (like Pirates of the Caribbean), and they’re teaching the robot to juggle!

To get some data, they asked me to juggle for them in the mocap lab. We did some ball juggling and cigar boxes. Here’s a short clip of me juggling five balls.