a page of tumbling madness

Archiving this so I don’t forget it: in Flask-SQLAlchemy on a Postgres DB, db.drop_all() can fail silently. This can be somewhat infuriating.

This link sums up the situation pretty well. There are a bunch of hacky fixes floating around Google, none of which work, except for a particularly simple one which Mike Bayer himself proposes in the comments of that same link:

db.reflect()
db.drop_all()

db.reflect() is the secret sauce that makes the drop operation work. Which makes sense, I guess.

The catch is that db.reflect() is 100% broken in the current version of Flask-SQLAlchemy. Hopefully that gets fixed soon. In any case, if anyone else is living in a world where db.drop_all() doesn’t drop any of their tables: call db.reflect() first.

Heroku’s documentation claims that “New apps created on Heroku automatically have a shared database installed.” Unfortunately, that isn’t at all true for Flask apps: if you create a new Flask app on Heroku, you don’t have any database at all by default.

I spent a couple of hours Googling and digging through documentation to try to figure out how to get a database for my app to use, and was finally helped out by user lukemelia in #heroku. If you find yourself in the position I was in, here’s all you need to do:

(moody) [jrheard@jrheard:~/envs/moody] (master) $ heroku addons:add shared-database:5mb
-----> Adding shared-database:5mb to moody... done, v11 (free)

Problem solved.

I bought a Fitbit in July, and ever since, I’ve been walking a lot. I walk home from work most nights, and on the weekends I like to walk to the ocean. I’ve been trying to walk fifty miles a week for the past few months, and I’ve hit that goal most of those weeks.

I’m doing mainly because the Fitbit universe is made of progress bars, and if you put a progress bar in front of me, I will walk on hot coals if it’ll make the thing move a little bit to the right.

This is a snippet of what the main Fitbit web interface looks like:

You’ll note that the dang thing is covered in progress bars. I’m helpless here.

The most important progress bar is the one in the top right: the weekly mileage goal. When I first got the gadget, I sort of just started walking a lot, and found that I could hit 35 miles per week without too much effort. From there, I just kept bumping up the goal until it actually took a little bit of work to reach, and now it’s set to 50. Also, 50’s a nice round number, so that was probably a factor too.

The thing is, since the weekly progress bar resets at midnight on Monday morning, if I don’t remember to check the thing before I go to bed on Sunday, I’ll have no idea whether or not I hit that weekly goal. That’s where the weekly Fitbit progress report email comes in:

So that’s pretty cool: every Monday afternoon, I get a pretty email that tells me whether or not I hit my weekly goal. Hunky-dory. In fact, I really much prefer the weekly email to the current Fitbit dashboard. Look at the font size on those numbers!

After a few weeks, I found myself wishing for a Fitbit web dashboard that was a lot more like the weekly email, with big numbers, a focus on how much you’ve accomplished so far this week, and what you’d need to do for the rest of the week in order to meet your goal.

So I built one. It’s really simple.

I have a cron job that updates this data every few hours, and always leave a tab open on this page so I can see where I’m at at any given point during the week. Take a look at what it looks like midway through the week, when I’ve still got lots of work left to do, or on a Sunday  of a particularly productive week.

Code Notes

If you’re a Fitbit user and want to use this thing yourself, feel free: the full source code for this dashboard is available at github.com/jrheard/fitbit. The two files where the meat of the work is done are fitbit.py and index.tmpl; I wrote this as a one-off side project in a weekend, so this isn’t exactly production code - prepare yourself for <table> tags and a constant named DISTANCE_TO_PORTLAND.

When I made this thing, I was under the impression that Fitbit didn’t have a web API, so I approximated one by just scraping a few logged-in pages. On further reading, it looks like they do in fact have an API that would have probably given me the information I needed, but it’s sort of unintuitively named and didn’t jump out at me when I was browsing their developer site. Oh well!

This was my first time playing with the Mako templating engine. Overall, I was pretty pleased with how simple it was: I like the general flow of “come up with a dict of key/value pairs, feed it to the template, there is no third step.” Simple is good.

This was also my first time using the python Requests library, which proved to be pretty indispensable. Its session object let me log in on fitbit.com and then stay logged in while I made requests to other pages in order to retrieve additional information, which would have been a pain to do with urllib. The relevant code looks something like this:

import requests

with requests.session() as session:
  # log in
  session.post('https://fitbit.com/login', data={'username': 'foo', 'password': 'bar'})

  # remain logged in by continuing to use the same session object to make further requests
  response = session.get('http://www.fitbit.com/my_personal_info')
  print response.content

PyQuery came in handy as always - I think I’ve used it in at least half of my random side projects at this point. Beats the hell out of BeautifulSoup. 

That’s about it for this post. Major props to the Fitbit team for building a neat product that’s keeping me healthy and giving me an excuse to explore the city I live in. Hit me up on twitter at @jrheard if you’ve got any suggestions for a killer feature I left out of the dashboard.

i’ve been working on a completely friggin’ awesome project with a couple of really smart guys for the past couple of months. as agreed, i split off from the development of the primary aspect of the project a couple of weeks ago in order to focus exclusively on creating its social-network-esque website counterpart, with my teammates continuing to work on preparing the main part of the project for its upcoming 1.0 release.

so, as a result, i’ve been working as the sole committer on a separate (and private, thankyouverymuch) github repo for the past couple of weeks. as it turns out, one neat feature that github has is the ability to show you really cool graphs about your repository, among them the “punchcard” graph, which plots your project’s commit activity over a period of time.

that’s me up there. those are my sleeping habits, my working habits, my partying habits, over the course of two weeks. the bigger the dots are, the more i worked at that intersection of day and hour.

that is so wild.

equally wild is the fact that the main project - the one that jhurwich and dmacdougall are still hard at work on finishing up (and which my buddy jackie is busily designing a few icons for) - has eerie, unintended parallels with this Punchcard graph thing: it’ll also tell you a whole lot that you may not have known about yourself and your habits, albeit in a completely different way. even though that wasn’t really what we had intended. at all. more on that in a couple of weeks.

http://jrheard.com/music/mice_parade.zip

http://www.last.fm/music/Mice+Parade

bem-vinda vontade’s my favorite.