Tammer Saleh

I’ve worked in a few different types of environments in my career (academia, start-ups, Japan, doing good, working for the man, etc), but I can honestly say that I’ve never enjoyed my work, or my coworkers, as much as I have while I’ve been working with the team at Thoughtbot.

Thoughtbot understands the Ruby on Rails culture in a way that I’ve always respected. As a company, they focus on producing good work for both the clients and for the community. As a team, they foster an incredible amount of camaraderie and team spirit, without needing to stifle differences of opinion.

Setting out

All of this has made my recent decision to leave the company incredibly difficult. While Thoughtbot has been the best environment I could have hoped for, the need to set out on my own and build something for myself was just too strong.

I will be doing agile Ruby on Rails consulting for a few clients, and will soon focus on developing my own suite of products. While I’m currently fully committed, I’d be happy to discuss new opportunities and give referrals. I will also be posting my journey, and my development thoughts here, so stay tuned.

If you’re an incredible developer, and interested in living in the Boston or NYC areas, then I cannot recommend a better company to work for.

I’ll be at RailsConf for the week of May 4th, so buy me a beer if you’re in town.

Here are some of the presentations I’m looking forward to in particular:

• Don’t Mock Yourself Out by David Chelimsky
• Discussion Panel: Women In Rails which will include two of my friends from hashrocket, Desi McAdam and Jacqui Maher
• iPhone On Rails by Mike Clark (‘cause who’s not on the iPhone bandwagon these days?)
• Blood, Sweat and Rails by Obie Fernandez – possibly the best business mind in our community.

And a quick shout out to my friend Eric Mill, from The Sunlight Foundation, who’s hosting the Open Government Hackathon. (And I think they’re still hiring, by the way.)

We give training classes at Thoughtbot, and one of the common issues I’ve seen is that there are many more examples of good ruby library code than there are of decent Ruby on Rails applications. A Rails application follows conventions and best practices that aren’t relevant to writing library code.

To that end, I’ve released the source to this blog on github.

Here be Dragons

I spent a little bit of time cleaning the code up, but here is the big disclaimer:

This is my playground. I try to keep the code somewhat clean, but I also experiment quite a bit. Not everything in here exemplifies best practices.

There’s an AntiPattern that I still see in the wild far too often: the overly normalized domain. It’s easy to spot – you find over 50 files staring you down after opening the app/models directory in what should have been a basic Rails application.

A simple example is the following domain snippet, showing a Product model with all the trappings that surround it.

Each of Condition, Color, ProductState and ShippingType are separate models, with separate tables, separate factory definitions, unit tests, RESTful controllers, migrations, etc.

And each is responsible for a single name column.

That’s a lot of code. The more code I see in an application, the sorrier I feel for the client. Code is a liability. Like a pack mule, the development process becomes bogged down, cumbersome, and eventually comes to a halt due to an overburden of code.

A much simpler solution is to reduce each of those models into columns on Product, using validations and named scopes to give all the benefits of the domain above:

class Product < ActiveRecord::Base
  COLORS = %w(Red White Blue)

  named_scope :colored, lambda {|c| {:conditions => {:color => c}}}
  validates_inclusion_of :color, :in => COLORS
end

Even the Photo model can be reimplemented this way, if you use the fantastic Paperclip plugin.

Developers, not coders.

It sounds absurd and even self defeating, but our job as developers isn’t to write code. Our job is to produce value for the client, and more often than not that means removing code.

That requires a whole lot of judgment, which translates to a whole lot of experience.

Behavior, not nouns.

The idea of removing classes in favor of values doesn’t fly in the face of good Object Oriented practices. The important distinction is that the classes above have essentially no behavior. A class without behavior is just a glorified value wrapped in maintenance costs.

Behavior, not vocabulary, dictates normalization. The moment you add a shipping_rate method to the Product model, you know you should migrate to a ShippingType class. The moment you have to be able to modify that price at runtime, you move to a model.

Simplest thing possible.

That’s the beauty of the BDD way. BDD teaches you to write your specs first, and produce the simplest thing possible in order to get them to pass. It also keeps you focused on producing business value for your client – something a domain explosion definitely doesn’t do.

The Plug

Chad Pytel and I delve into issues just like this in our upcoming Addison Wesley book, Rails AntiPatterns. Stay tuned for more information on the book, or for more posts like this.

Hashrocket recently honored Joe Ferris (no relation) and I by an invitation to come down to Jacksonville Beach, Florida to work on one of their 321 Launch projects as guest star programmers.

Chris O’Sullivan actually did an amazingly accurate job of describing the project from a technical point of view by doing an impressively detailed analysis of our github commits and tweets.

We had a lot of things going for us in this project: The clients were a breeze to work with; Desi and Lark were both great developers, and a lot of fun to pair with; and the end product, Spot.us was going open-source – meaning there was no room for “cowboy antics” (Desi’s words).

The client was very impressed with the progress we had made, and with the overall polish of the site. You can read more about the reaction here, and the demo video is below.

Working at Hashrocket was a lot of fun, and in many ways was the perfect vacation. You’re surrounded by talented coders (which fends off the normal vacation boredom), and you get to wake up to beautiful beach views every morning.

• Take a picture of yourself right now.
• Don’t change your clothes, don’t fix your hair…just take a picture. (should be super-easy with Photobooth)
• Post that picture with NO editing.
• Post these instructions with your picture.

(It’s “formal friday”)