

Beeminder API - andrewpbrett
http://blog.beeminder.com/api/

======
dreeves
Danny of Beeminder here! Thanks so much for enthusiasm about our API! We're
really excited about the things people are cooking up. Especially related to
Hacker News, here's my Beeminder graph of HN use over the last year:
<http://beeminder.com/d/hn> (that's time spent as tracked by <http://tagti.me>
but it would be great to have something that measures page loads of
news.ycombinator.com directly...)

~~~
hollerith
Regarding TagTime: I am a little curious why you chose to have TagTime pop up
a dialog box rather than doing something less distracting, like taking a
screen shot.

BTW, one can programmatically take a screen shot on OS X with
/usr/sbin/screencapture (where the -x flag means screencapture should not play
the usual "camera click" sound).

~~~
dreeves
Ah, the idea of TagTime is to be a happy medium between something like
RescueTime (where it automatically infers where your time goes based on what
app or web page is in the foreground) and manual logging where you explicitly
clock in and out of projects to get your exact time spent.

Details are in this article: <http://messymatters.com/tagtime>

Short version: TagTime randomly samples you with a popup, asking what you're
doing right at that moment. You never have to remember to do anything, so it's
essentially passive. But you're not trusting the computer to infer what you're
doing, so it's perfectly accurate (asymptotically -- you need a week or so of
data for the inherent noisiness to average out, ie, to get a big enough sample
size).

~~~
hollerith
OK, but I feel the need to head off a possible misconception by pointing out
that my screen-shot suggestion is _also_ in the happy medium between automatic
inference and manual logging.

Part of my suggestion, left unspoken above, is that once a day or once a week,
the person would "review" the screen shots. During this review, the same
(time-stamp, tag) pairs would be (manually) created that are created by your
pop-ups. Its just that the "pairs" (or records) would be created in batches,
rather than at the time of the events they refer to.

Now that I am done trying to head off a possible misconception, let me say
that I plan to try your way, because there is already software available to
support it. (I have software to automatically create the screen shots, but not
software to support the task of reviewing the screen shots while manually
creating the (time-stamp, tag) pairs.)

~~~
dreeves
Oh, interesting! One thing I like about TagTime as it works now is that it
captures things like spacing out or getting interrupted by a coworker or other
things that you can't infer from screenshots.

But for people who don't like getting interrupted by the popups, your solution
sounds good. (I find the popups aren't distracting at all -- they even tend to
reinforce what I'm focusing on, or remind me to refocus if I was distracted.
It's not like getting interrupted by email where it pulls your attention away
from what you were trying to focus on.)

~~~
hollerith
Installed TagTime and test drove it for a few hours.

Seems useful. I made 2 comments over at
[http://beeminder.uservoice.com/forums/3011-general/filters/n...](http://beeminder.uservoice.com/forums/3011-general/filters/new).

------
bsoule
Ooh! One use we didn't describe in the post is TallyBee -- I added Beeminder
integration to a super simple android tally app (it increments a counter every
time you touch the screen). Put it on the floor, do pushups. Your nose
increments the count at the nadir, and your Beeminder graph is instantly
updated. Awesomepants!

~~~
bsoule
by popular demand: <https://dl.dropbox.com/u/50476194/bee_push_01.mov>

------
andrewpbrett
One design dilemma we ran into when building this out is the "username"
endpoint. When a user grants access, the OAuth default is to just pass the
token back to the client. But to access other endpoints, the client needs to
know the username of the user that just granted access.

So we added the "username" endpoint, but weren't (and still aren't) quite
satisfied with that as a solution. Have other API designers run into this same
issue? Seems pretty common - would like to hear what HN has to say about it.

~~~
jmillikin
My preferred ways to solve the problem:

1\. Make the OAuth server end append additional parameters to the successful-
auth URL. It would end up looking like <http://> some-app.com/oauth-
ok?access_token=abc123&username=jdoe

2\. Provide an endpoint with the same data as /user/<name>.json, but without
the uesrname in the URL. OAuth clients would query this new endpoint instead.
While you're at it, might as well allow the client to request the goal list at
the same time. Ideally, a client should only have to send a single request to
populate its "home page".

~~~
dreeves
Thanks, klochner and jmillikin, for setting us straight on this!

We're taking both your suggestions: username is returned along with the token
as part of the oauthing, and also you can just use "me" in place of the
username for any endpoint, and it's essentially macro-expanded.

No more lame-o dummy resource just for getting the username! (Well we're
leaving it there in case anyone has already written code that uses it but it
can now be undocumented.)

Thanks again for the help!

