Icelab

Last week when I introduced our plan to ship Decaf Sucks for iPhone, I promised I would write regularly about our progress. One week later, we’ve definitely moved forward, but still have a lot of work ahead. Here’s how we’ve gone.

Getting Started

We completed 4 user stories this week:

• On the café list screen, show the distance away from the current (or searched for) location for each café
• Show a loading spinner when tapping the cell to view more cafés in a list (Thanks to Jake)
• When scrolling to new areas of the map, the cafés that are no longer in the current set of results are removed from the map
• When the user views the café details screen, any additional reviews are loaded from the API and displayed

To support this last story, I had to extend the existing Decaf Sucks API, which until now has only needed to support the AJAX-driven web interface. Instead of building it onto the Rails app’s existing controllers, the API now has its own URL namespace, which means that I’ll be able to develop it without conflicting with the operation of existing web interfaces.

I used a couple of very useful libraries to make the development of this new API easier. They are Representative (a DSL for easily converting Ruby structures into XML or JSON), and Representative View (a gem for incorporating Representative as Rails template format). These allow me to have a very small controllers that pass the objects onto views for formatting as JSON. For example, here is reviews/show.rep:

r.element :review, review do
  render :partial => 'review', :locals => {:review => review}
end

It uses a partial for showing the review details, which allows a lot of reuse between the API templates. Here’s the partial:

r.element :id
r.element :slug
r.element :body
r.element :rating
r.element :human_distance
r.element :created_at
r.element :updated_at

r.element :reviewer, review.user do |user|
  render :partial => 'api/v1/people/person', :locals => {:person => user}
end

I highly recommend you give a tool like this a try. The work is faster and simpler, and means you can completely avoid the headache of messing around with as_json methods in your models.

Trajectory

I chose ThoughtBot’s Trajectory to manage our user stories, mostly out of my usual curiosity for trying new software. It has turned out to be a really good move. While it lacks many of Pivotal Tracker’s more advanced features, I haven’t missed any of them, and the relative simplicity of the Trajectory interface means that my focus remains tightly on the upcoming work. Trajectory’s wide, single-column interface also means there’s much more room for large comment fields, which I think encourages longer, more thoughtful dialogue around user stories, which works out well for the distributed team that is working on this project.

My biggest most pleasant surprise about Trajectory is how it handles the email notifications for these comments, and any other activity in the system. By default, every user in the system receives an email for every event that occurs. New stories, comments on stories, and changes to the story’s state as it is worked on. Initially, I felt like this volume of email would be bothersome, but in practice, these whole-of-team notifications have meant that other people have been able to jump in with useful feedback on work that they might never have otherwise seen. Coupled with the useful “Discussions” area (for messages that don’t initially relate to any particular story), Trajectory has worked out to be a great general project management tool.

Forecast

With all out of the way, how are we tracking so far? Trajectory is telling us that the stories comprising our “1.0” release will be completed by August 22nd. This puts us a week behind, already! I’m posting this right now with an entirely free weekend in front of me, so I guess it’s time to get to work. See you next week.