James on Software

There've been a few quiet releases of Friendly since I blogged about 0.4. Mostly, they were bug fixes, except for the addition of change tracking which is mostly an internal feature that will support arbitrary caches. You can see all the notable changes in the changelog.

This week, I released 0.5 which includes built-in support for building a new index in the background without interrupting your app. Here's how it works:

First, declare the new index in your model:

class User
  # ...snip...

  indexes :name, :created_at # this wasn't there before
end

Then, make sure to run Friendly.create_tables! to create the index table in the database. Don't worry, this won't overwrite any of your existing tables.

Friendly.create_tables!

Now that the the new table has been created, you need to copy the .rake file included with Friendly (lib/tasks/friendly.rake) to somewhere that will get picked up by your main Rakefile (lib/tasks if it's a rails project). Then, run:

KLASS=User FIELDS=name,created_at rake friendly:build_index

If it is a rails project, you'll need to prefix friendly:build_index with a rake task that loads your rails environment. For our app, the full command looks like this:

KLASS=User FIELDS=name,created_at rake environment friendly:build_index

If you're running this in production, you'll probably want to fire up GNU screen so that it'll keep running even if you lose your SSH connection. When the task completes, the index is populated and ready to go.

We've already built a couple of indexes with this code in production and it worked great!

Get It!

As always, install Friendly as a gem:

sudo gem install friendly

If you're not already following the github project, it's a great way to keep up with Friendly's development. Finally, if you feel so inclined, I'd appreciate a recommendation on Working with Rails.

My new years resolution was to measure more. For a while now, I've wanted to get a better picture of our systems and our business, and hopefully, how they relate.

So, my first day back at work after the holidays, I started looking for the right tool to gather data with. After investigating some of the options, I wound up settling on munin.

I say settling because I was quite dissatisfied with the available options. I tried everything from collectd to reconnoiter and found all of the solutions horribly lacking in some way. This is an enormous market just waiting for a startup to revolutionize it.

In any event, we were already using munin to trend our system metrics. So, now it was just a matter of figuring out how to get our business metrics in there. Here's how we did it.

Custom Graphs

It's actually relatively easy to write a munin plugin. All you need is an executable that responds to a config command and emits a specially formatted value when it's called with no parameters.

Most of the examples I could find were implemented using multi-line strings, which seemed ugly to me. So, I wrote a little ruby DSL to make my plugins easier on the eyes.

Here's an example plugin written with munin_plugin. I won't go in to what all the parameters mean. The official documentation does a good enough job of that.

#!/usr/bin/env ruby

require 'rubygems' # or rip or whatever
require 'munin_plugin'

munin_plugin do
  graph_title  "Load average"
  graph_vlabel "load"
  load.label   "load"

  collect do
    load.value `cat /proc/loadavg`.split(" ")[1]
  end
end

Everything outside the collect block gets emitted as configuration. When the above script is called with config, it produces the following output:

graph_title Load average
graph_vlabel load
load.label load

When it's called without any parameters, it would produce something like the following:

load.value 0.03

As you can see, the DSL just emits whatever you give it, essentially verbatim. Nothing fancy, just a little syntactic sugar.

Let's trend some business metrics.

Trending Business Metrics

One of our most popular features is picture uploads. I wanted to get a sense of how quickly pictures were being uploaded at different times of day. Since munin polls nodes every 5 minutes, I wasn't sure exactly what kind of value it was going to need to get this going. Do I need to calculate the rate myself?

It turns out munin has an option called DERIVE, which turns your monotonically increasing value in to a per unit of time graph. So, I created a little REST API that returns the total number of pictures on the site. Then, all I had to do was scoop it up with a fairly simple munin plugin.

#!/usr/bin/env ruby

require 'rubygems'
require 'munin_plugin'
require 'open-uri'

munin_plugin do
  graph_title    "Picture Upload Rate"
  graph_vlabel   "Pictures / ${graph_period}"
  graph_category "FetLife"
  graph_period   "minute"
  pictures.type  "DERIVE"
  pictures.min   "0"
  pictures.label "pictures"

  collect do
    pictures.value open("http://an.internal.ip/stats?id=pictures").read
  end
end

Here's the result (actually for a different metric, but it uses roughly the same script):

We use a nearly identical plugin to chart the all the critical objects in our system. The graphs are starting to give us a nice look at exactly what happens during peak load, and as time goes on, hopefully they'll assist us in identifying problems, too.

The moral of the story is that seting up custom graphs is easy. You should do it.

Back when I was running a consultancy, I was a big fan of user stories as a method for gathering requirements. Having left the consulting world, though, it's become really clear to me that stories are the wrong approach.

Why consultants like stories

With a freshly inked contract, the client typically wants to begin work immediately. If you're smart, you've sold them on the value of good design. But, they probably haven't engaged a designer just yet. So, starting the requirements gathering process by story carding is a great way to get the ball rolling.

In fact, an iteration or two worth of story cards are a really great thing to put in a proposal. They demonstrate to the client that you have listened to them during your initial meetings. A reiteration of the requirements proves that you're (at least basically) on the same page.

The problem

The thing is: applications are not collections of words. They engage us in completely different ways than reading story cards.

Words mean different things to different people. Even meticulously written user stories that follow a standard form leave plenty of room for interpretation. That's why, even with your carefully crafted stories, it still takes several tries to get it right with the designer.

The design process exposes all the holes in your requirements. You discover missing, irrelevant, or grossly mis-estimated stories. With something to look at, everybody sees the application far more clearly. In fact, this is the first time they actually see the application at all.

Now that the stakeholders have seen the designs, the inevitable rounds of changes begin. A good design process should yield important refinements to the product. Which means that by the end of it, the stories are even less relevant.

The solution

Start with UI.

User interface assets (xhtml / css — not photoshop documents) leave very little to the imagination. They are as close as you can get to a working application without actually implementing it.

A good designer (and supporting team) will gather requirements and incorporate feedback throughout the process. All the while, the project stakeholders will be able to actually point and click at the interface, even if it's not completely functional.

So, for application development, the designer belongs on the team rather than as an external resource. They should play a central role in bridging the gap between stakeholders' brains and the development team.

The reality is that designers play that role either way. It is during the design process that the requirements become truly understood. So, come to terms with that, and save everybody a lot of time and money.