Everything's Beta

I have recently been working on CodeReviewr. It’s motivated by the need to have a place to easily stick up code and discuss it with minimum hassle. I have rewritten the code numerous time using various platforms(from mochiweb to node.js to tornadoweb) towards multiple goals (collaborative coding, reviews, etcs) as I succumbed to feature creep, premature optimization, not built here, et al.

Anyway, a couple of weekends back I decided to just deploy it so that we could use it for rackjam. I don’t consider it even close to finished. For eg, you have to refresh in order to see comments you just made (ack), and there is no documentation on how to use it. But, it’s finished enough. I decided to stop trying to release something perfect and go with the release and iterate model. So, I rounded off the minimal feature set and let dog fooding sort out the priorities.

A few weekends later, I am still adding features. BUT, these are user driven requirements. And I have a website that people are using It’s surprisingly good motivation to keep trying to make something better when you see people actually using it. Driven by feedback, I have added support for multiple versions, diffs between versions, better diff visualization, ability to download raw files, free private domain support etcs etcs. Funnily enough, I still haven’t been asked to fix commenting to address the refresh annoyance! More than anything else, this has taught me the importance of release+iterate as opposed to trying to imagine complete use cases. Of course, I will throw in real time comment updates in there, but not before the core featureset.

But this blog post isn’t only about extolling the virtues of MVP, release+iterate, dog-fooding blah blah blah. It’s about a new feature I have been asked to add; the ability to get emails when a review or set of reviews you are interested in changes. Before beginning this task, I wanted to make sure that sending subscribers updates should be as painless and decoupled from the current code as possible. The web app really shouldn’t care who gets updated and how. And anyway, I definitely don’t want the webapp sending email. So, my ideal solution is 1 line of code fire off an event so w/e subsystem or subsystems are in charge of updates inform interested parties as (and when) they see fit. I also wanted the update management subsystems to be as pluggable as possible. The first thing that I thought of was a message queue(à la beanstalkd) where I push out messages whenever an update occurs. Interested consumers could then process the message and send updates to whomever and however they wanted. All the logic in handling the complexity in delivering the message would be solely in the consumers, the webapp fires [off an event] and forgets. Sounds pretty perfect. Could we do better? Enter PubSubHubBub. (I’m going to assume you know about it, or will do the required research to get up to speed if you are interested). After some prototyping I decided to go with it because

• It met the 2 requirements I set forth.
• It’s easy.
• And, it allows me to have an interim solution for free that
  was good enough (rss feeds).

So after adding rss feeds to reviews (append .rss to the url) and subdomains (/feed.rss), creating a hub at superfeedr, and adding the 1 line of code to ping the hub when there is an update, I am 100% there w.r.t providing users with a way to receive updates and 80% there w.r.t email alerts. All I have to do now is to write bots that will subscribe to the hub and push out notifications through w/e medium people want. The best thing about this is CodeReviewr is now PubSubHubBub capable so anyone else can subscribe to the hub right now if they don’t want to wait for me to implement the bots they want