The Deck has put together a readership survey for sites that are part of the network. We’d love if you take a moment to fill it out.

If you do persevere and make it through to the end we’ll ask you for an email address. We’re only doing that so we can randomly choose twenty people and send them some Field Notes Brand Memo Books and a free year of 37signals’ Highrise in appreciation.

Thanks for participating.

Balsamiq Studios is “a fresh little software company, focused on adding flavor to your Web Office suite.” The company page describes Balsamiq this way…

Micro-ISV Yes, a couple of guys in a studio

Profitable and Well Funded We’re in this for the long haul

Clear Focus We only bite off what we can chew

Outstanding Advisers We are so lucky!

Contagious Passion We absolutely LOVE this!

Giacomo ‘Peldi’ Guilizzoni, Founder and CEO of Balsamiq, used to be a Senior Software Engineering Lead at Adobe. He recently wrote a post about why he’s blogging less and how Balsamiq Studios is growing and maturing as a company. In it, he says…

I am trying to build what DHH calls “a little italian restaurant on the web”…so while it’s good to know the owners and know that they are doing well, that shouldn’t be the reason you go eat there: it’s the quality of the food (ehm, product) that matters most.

We liked the sound of that and decided to interview Peldi about Balsamiq and the choices the company has made (e.g. focusing on small problems, eschewing outside investments, being in it for the long haul, etc.) Here are his answers…

How did you start working on Balsamiq?

In 2001 I moved to the US with a 5-year plan: learn as much as I could about how to make software from big corporate America, then move back to Italy to start something on my own. After 6.5 years at Macromedia (then Adobe), a confluence of factors made me decide that the time was right to make the jump.

Some of these factors were personal (I describe them in detail in this what’s your story? post), but others were more technical:

• I saw the power of “web office” (being able to save and edit your data from anywhere, revision history, native collaboration abilities and all that good stuff…) and I was hooked. It’s a paradigm shift, which meant loads of opportunities suddenly opening up.
• I couldn’t find a good enough solution to a problem that I had (i.e., early stage collaborative wireframing), and the solution I was dreaming of happened to both require my skill set to implement and was small enough that I could do it all on my own.
• I also read Bob Walsh’s Micro-ISV: from Vision to Reality and Erik Sink’s The Business of Software, which showed me that being small is OK, and of course Getting Real, which provided me with a real example of a new generation of software company: small, ambitious, transparent, fast, daring, fun. It painted a pretty compelling picture: if you guys were doing it, why not me? ;)

Why do you choose to focus on small problems?

From the beginning, I wanted to do it all myself for a while so that I could really understand every aspect of running a business. In fact, figuring out all it takes to bring an idea to market was one of my main goals in starting Balsamiq Studios. As a professional programmer in a large company, I was only peripherally involved in “the numbers,” design, marketing, sales and support issues during my career, but I was always fascinated by the business-side of things. I contemplated going to business school, but was lucky enough to be surrounded by great advisors (Erik Larson, Fang Chang, Michael Fitzpatrick, all MBAs, and my bosses Dennis Griffin and Robert Tatsumi) who talked me out of it. Instead, they pointed me a bunch of great books to read. And read I did! (Here’s my bookshelf if anyone’s interested.) After a few months, I realized that reading would only take me so far. If I was really going to learn it, I was going to have to do it. I had about a year’s worth of saving, so I jumped.

CarsForaGrand.com shows all cars currently on eBay for under 1k. Simple idea, yet Chris Hedgecock, the site’s founder, is earning a high six figure a year income from it. He recently managed to get nationwide attention for the site by driving cross country in one of the cars too.

After we hit New Orleans we noticed the coverage kind of snowballing. For example, the news story we shot in San Diego got picked up by their sister station in LA, the one we shot in El Paso aired in San Francisco, etc. By the time we were done in Miami, the story had gone national… on the largest day we did over 110,000 uniques – all for free…

So to recap, if you have an idea get off your ass and just go for it. The worst thing that can happen is you will learn something new, and you might just succeed beyond your wildest expectations in the process.

The whole thing is a great example of how you can take even the simplest of ideas, execute the heck out of it, market it creatively on the cheap, and see big rewards. Nice job Chris.

Orbitz offers an “I prefer non-stop flights” checkbox…

...which I have a tough time understanding. Are there really people out there who don’t prefer non-stop flights??? Does anyone say, “Yeah, I’m going from Chicago to Dallas…but I really hope there’s a 2-hour layover in Atlanta along the way!”

Seems akin to offering checkboxes that say:
“I prefer flights without screaming babies.”
“I prefer flights that takeoff and land safely.”
“I prefer web sites that don’t ask ridiculous questions.”

I was digging in some old Basecamp code today while working on a new feature and I ran into this bit of view code:

<div class="rss">
  <%= rss_link :icon %>
  <p><%= rss_link "Project RSS feed" %></p>
</div>

This code renders an RSS icon wrapped in a link and a text link beside it:

I wanted to add a class to the linked RSS icon. If the template used the standard Rails link_to helper to render the linked image I would know how to provide the class with an options hash. But rss_link isn’t a standard helper, so I had to dig up the definition to see what’s possible. It wasn’t very pretty:

def rss_link(body, options={})
  if body == :icon
    body = image_tag("feed-icon-14x14.png", :size => "14x14", :alt => "RSS Feed",
                     :border => "0", :align => "absmiddle")
  end

  link_to(body, { :controller => "project", :action => "rss_confirm",
      :return_to => request.request_uri }, options)
end

It turned out we were using a single helper to render either a text link or a linked icon for the RSS feed depending on the ‘body’ param. It works fine, but I would have never been able to guess how it works without looking inside the method definition. Now I can see that it is possible to pass an options hash, but I had to look to find that out.

It would have been better in this case to use the standard link_to in the template and delegate the truly unique stuff to helper methods. The unique bits that I don’t want to repeat are the long url_for hash and the image tag params. Here’s a refactoring that splits the helper into two methods to return only those special parts:

def rss_path
  { :controller => "project", :action => "rss_confirm",
    :return_to => request.request_uri }
end

def rss_icon
  image_tag("feed-icon-14x14.png", :alt => "RSS Feed", :class => "rss_icon")
end

These helpers allow me to stick with link_to, which is a helper that I and my team already understand:

<div class="rss">
  <%= link_to rss_icon, rss_path, :class => 'image' %>
  <p><%= link_to "Project RSS feed", rss_path %></p>
</div>

It’s much easier to tell at a glance what this code is doing and it’s easier to make changes because the link_to helper is standard.

The next time we want to change this bit of view code, we won’t have to dig into the helper to check if it takes an options hash. It’s clear from the call to link_to that we’re simply providing method calls as params. I hope this tip helps to make your view code a bit more readable and more predictable to maintain.

A couple of years ago a lot of buzz started in the Ruby community about Erlang, a functional programming language developed by Ericsson originally for use in telecommunications systems. I was intrigued by the talk of fault tolerance and concurrency, two of the cornerstones that Erlang was built on, so I ordered the Programming Erlang book written by Joe Armstrong and published by the Pragmatic Programmers and spent a couple of weeks working through it.

A year later, Kevin Smith began producing his excellent Erlang in Practice screencast series in partnership with the Pragmatic Programmers. It’s amazing how much difference it made for me to be able to watch someone develop Erlang applications while talking through his thought process along the way.

As I was learning Erlang, I kept threatening to rewrite the poller service that handles updating Campfire chat rooms when someone speaks in room. At some point my threats motivated Jamis, who was also playing with Erlang in his free time, to port our C based polling service to Erlang. Jamis invited me to look at the code and I couldn’t help myself from refactoring it within an inch of it’s life.

The code that Jamis wrote worked fine, but it was not very idiomatic Erlang. While I didn’t have much more experience developing Erlang code than Jamis, I had definitely seen more real Erlang code. I tried to pattern our work after what I had been exposed to, making improvements along the way. We ended up with 283 lines of pretty decent Erlang code.

parameter(Parameter, Parameters) ->
  case lists:keysearch(Parameter, 1, Parameters) of
    {value, {Parameter, Key}} -> Key;
    false -> undefined
  end.

For the curious, here’s a very simple example function from the real Campfire poller service. This function takes two arguments, the name of a parameter to search for, and the list of parameters. If it finds a matching parameter it returns the associated value, otherwise it returns the atom undefined. Atoms are like symbols if you’re a Ruby programmer.

Last Friday we rolled out the Erlang based poller service into production. There are three virtual instances running a total of three Erlang processes. Since Friday, those 3 processes have returned more than 240 million HTTP responses to Campfire users, averaging 1200-1500 requests per second at peak times. The average response time is hovering at around 2.8ms from the time the request gets to the Erlang process to the time we’ve performed the necessary MySQL queries and returned a response to our proxy servers. We don’t have any numbers to compare this with the C program that it replaced, but It’s safe to say the Erlang poller is pretty fast. It’s also much easier to manage 3 Erlang processes than it was the 240 processes that our C poller required.

Erlang definitely isn’t a replacement for Rails, but it is a fantastic addition to our collective toolbox for problems that Rails wasn’t designed to address. It’s always easier to work with the grain than against it, and adding more tools makes that more likely.