Over the weekend, I discovered that it is possible to get streamed “favorite” events from the Twitter API… as long as you’re logged in as that user. Luckily my friends seem to trust me (?), so I am now authenticating both as my own application and the account that I want to watch.

I figured out how to watch for favorite events (if (data.event == "favorite")) and retweet events (if(data.retweeted_status)), and how to update documents in a MongoDB using the Node mongodb wrapper (a convenient findAndModify with {"upsert":"true"}).

But my retweeter, which is supposed to retweet when an incoming favorite/retweet event directs its attention to a tweet with more than a certain number of retweets/favorites, was never firing. It turns out that the “favorite_count” I was seeing was incorrect. My best guess is that, unlike the identically-named field of a naked tweet object, the “favorite_count” value of a tweet delivered via a streamed “favorite” event is relative to the authenticated user, meaning, “how many times has this user favorited the tweet?” Which is almost useless, since a user can’t favorite or retweet more than once; if you’re seeing the message at all, the answer is “once.” (Except that it’s the value right before the event was sent, so the value is actually “0.”) So you have to do a search query on the returned tweet ID, which counts against your rate limit. I’m going to run it tonight and see if I get rate limited. If I do, I’ll just do all the counting in my own database, and hope my stream doesn’t cut out.

I also went to lunch with Lindsey, who is at Hacker School as a resident! And I attended Daphne’s concise and demystifying Makefile workshop.