Fitbit… getting closer!

Fitbit API

I originally thought the Fitbit looked awesome, but in digging into things, I found a few issues I didn’t like. (See Fitbit Improvements.) While it looks like they’ll never go the route of sending your own data to your own computer without first sending your data to the cloud, their official API is out (in beta) and should at least offer an improvement over the “unofficial” APIs people had been working on.

Over at you can read up on the details, and get some example code (none in Perl yet though!) It’s good for the Fitbit ecosystem, as more applications may come out that make use of the data. If anything, I’d like to see something like what I created for in Heard, an application that syncs your data back to your own server from the cloud.

I also noticed that Fitbit got a mention on the Arduino blog, which amuses me for a few reasons. First, if the Fitbit had been more open I probably would have looked more seriously into getting one last year. (Open source hardware would have been awesome, but I can live with closed, though it is interesting that they use the open source Arduino for rapid prototyping.) Second, I actually got into working with the Arduino partly to try to do some of the sleep monitoring functions that the Fitbit does. (Yes, that’s another project I got sidetracked on.)

Depending on how our research funds shake out this year, the Fitbit may still be on our list. As I’ve said before, I’m the type of person who needs to collect data, and analyze it, and chart it out, in order to find more value in it. Meanwhile, I’ll be in the lab working on my Arduino-based sleep monitor…


Scuttle Me Bookmarks

Apologies for the poor attempt at Pirate-talk, I was just excited to see that Phil Wilson mentioned me in his post about Scuttle.

My post Scuttle rides again! talks about how I was pulling data from Delicious and posting into my install of Scuttle. Phil goes the other way around and posts to his own installation of Scuttle, which then auto posts that to Delicious.

This is the awesome stuff that smart people can do with open APIs…

Keep hacking!


Mac OS X Text to Speech

I recently worked on a project that required making audio files out of text files, which is something I’ve done before, but haven’t done regularly since 2000 or so when I was making cassette tapes of web pages. There’s a simple way to do this using Mac OS X.

Keyboard System Preferences

Open you System Preferences and go to Keyboard and select the Keyboard Shortcuts pane. Click on Services and scroll down to Text until you see Add to iTunes as a Spoken Track and check that box.


Now open TextEdit and select some text and control-click (or right click depending on your computer input device) and you’ll see a contextual menu item for Add to iTunes as a Spoken Track. Select it.


Now jump over to iTunes and you’ll see the track. It’ll be called Text to Speech.

M4A audio file

In iTunes you can highlight your track and select the File menu and then Show in Finder (or just hit command-R) and the Finder will open the folder containing your file. It’s an MPEG-4 Audio file (also known as an AAC file) with an m4a extension.

ITunes can obviously convert the file to an MP3 for you, but if you want another format (like OGG) you can use Audacity. You should be able to do whatever you need to do with it from there, (And that whatever you need to do with it bit was the deciding factor for this specific project.)

I was really hoping to use an existing test-to-speech API on the web to automatically generate the audio. Google has an unofficial Text-To-Speech API (go on, try it.) Seeing as it’s “unofficial” and didn’t work in the way I wanted to use it, and there is an awesome group where people ask about APIs and ToS and no one answers, I skipped it.

AT&T also has a great text to speech demo online, which clearly spells out how you can’t use it, which is quite helpful. (Basically you can’t use it for anything public or commercial, which sucks, but I’m glad they come right out and say it.)

There are other options (almost all commercial) including services like iSpeech, which I may look into. There may be some open source text to speech options, but as to how good they are, or how easy they are to get up and running, that is yet to be seen… or heard, as it were.

(Note: I’ve got a follow-up post coming about Mac OS X Text to Speech via the command line.. stay tuned!)


Google Reader Subscription List backup shell script

If you’re interested in exporting (or backing up) your Google Reader Subscription List you can log into Google Reader, go to Manage Subscriptions, and then Import/Export and then export your subscription as an OPML file (which is basically an XML file.)

Google Reader - Export Subscription List OPML

If you want to automate this process, there are a few steps involved… I used curl, which is easy, but other tools can also work.

The first thing you need to do is get an Auth code:

curl -daccountType=GOOGLE -d Email=[USERNAME] -d Passwd=[PASSWORD] -d service=reader 

Substitute your own Google username for [USERNAME].

Substitute your own Google password[PASSWORD].

Once you do this, you’ll get 3 lines returned, that look something like this:


Note: I’ve shortened these (and made them up) but it’s but it’s basically 3 keys SID, LSID, and Auth and their associated values. You’ll need the value for the one labeled Auth.

Now, use curl to request the following:

curl -H "Authorization:GoogleLogin auth=HFDY49j7ljlkfh03fdkjgldkhfl945840598djglkjhjgh6640hi5h..." 

Again, I’ve shortened the Auth code (it’s really long!) You’re basically passing the authorization in the header of the request. It should go without saying that the SID, LSID, and Auth should be kept private. (Which is why I just made up a random string in the example above.)

OK, if it all worked, curl returned your subscription list as OPML. Hooray! Also, you just used OAuth, so Double Hooray!

And here’s our shell script, which will download/backup your subscription list as OPML file. (It’s similar to our mysql backup schell script.)


DT=`date +"%Y%m%d"`

curl -s -o /home/backups/SubscriptionList-$DT.opml -H "Authorization:GoogleLogin auth=HFDY49j7ljlkfh03fdkjgldkhfl945840598djglkjhjgh6640hi5h..." 

Each time you run it, it will get the date with the year, month, and day and use it in the name. So %Y%m%d would produce something like 20100816. This should work fine if you run just one backup per day. (And of course you can store it somewhere besides /home/backups/ if you like. cron is your friend here.)

I know that most people believe that Google will not lose their data, or if the day comes they want to export this data, they’ll just go to the site and export it, but this lets you prepare for the day you can’t get to the site and export your data… or the day Google loses it, or deletes it, or whatever.

By the way… I found most of this information in the Google Reader API wiki. It’s nice that Google is providing an API for things, I just wish some of the info was easier to find… as of this post, that’s the only damn page in that entire wiki!

This is all part of my renewed interest in putting my own data into my own hands, and I may be bugging Jason (@plural) a bit more in the future. ;)

Update: Jason reminded us of, which I’ll discuss in another post. :)

And just for fun: This gem from 2007: Data Loss At Google Reader.


Flickr Stuff…

I noticed a while back that my Flickr Date Search script stopped working… Well, it worked, but not quite right… Time to fix it.

Want to see all photos matching “barcampmilwaukee” uploaded between 2006-09-29 and 2006-10-03?

Here’s a sample of what the output might look like…

BarCampMilwaukee photos

I need to do more with the Flickr API, it’s definitely a cool thing…