Dan Croak is the Chief Marketing Officer of the prominent development shop thoughtbot. Before he moved to San Francisco to start thoughtbot's west coast branch, Dan was a friend of mine in Boston who helped me learn the ins and outs of Ruby on Rails.

Dan's a good guy to know because he and his shop have authored everything from core Rails commits to numerous gems and plugins (such as Capybara Webkit and Bourbon) that are known throughout the web community. I wanted to sit down with him and talk about Rails, its evolution, and how his company has built such a following around Ruby on Rails.

I hired thoughtbot in 2006 to complete a side project. I was writing ASP.NET web applications by day. I wanted to learn about open source, Ruby on Rails, Test-Driven Development, Unix, version control, etc.

After they completed the project, I did some Rails freelancing, then applied for a job at thoughtbot and they hired me. I've now been at the company for more than five years.

Rails struck them as something that would be great.

In 2005 Jon and Chad had been doing consulting projects in different languages, such as Perl and Java. After they did a couple of projects in Ruby on Rails, they felt it was state of the art and that they could be reliably productive with it.

As a team, they needed to pick one language/framework and specialize in it. Rails struck them as something that would be great. The community surrounding the language were the kind of people that they would want to work with. They were one of the first consultancies to announce that Rails was their specialty.

That was the turning point - they could have been a shop that split technologies but by picking one, especially an up-and-coming one like Rails, they were able to attract great people like Tammer Saleh, Jared Carroll, Eric Mill, and others.

In total, our team currently spends about 2,000 hours/week interacting with Rails and its ecosystem. It is the main medium from which we work with our customers. It's the environment we feel most efficient, and most able to create software with a solid test suite.

I'm currently in a role where I'm reviewing a lot of code - reading thousands of lines of diffs a day - and it's nice to have a language that doesn't have a lot of ceremony or extra tokens. In the last year, we've developed a style guide that makes it even easier and more pleasant to review lots of code.

There is always some shortcut in Rails to clean up a view by letting it render partials polymorphically, based on its type and based on conventional directory structures. Things like HAML and CoffeeScript further reduce clutter and help simplify the code to focus exactly on your ideas and how to express them in a web app.

The community is a huge benefit, too. Ruby is a very stable, 20-year old language with a gigantic community. Libraries for dependency management (Bundler), testing (RSpec), authenticating users via OAuth (Omniauth), are in a great state. Rubygems.org is a tremendously useful community effort. There are thousands of Rubyists with GitHub accounts contributing to gems. Ruby is the second-most represented language on GitHub.

Once GitHub came out, it became obvious that Git and GitHub were the superior way to share code.

Prem and Arun show up on the Rails contributed list.

Paperclip and Shoulda were early libraries that became pretty popular in the community. Both were continuations of testing and file uploading that we did before. Paperclip was inspired by file_column and attachment_fu. Shoulda was built atop Test::Unit - similar to how Sass was built atop CSS. That process of improvement is never ending in the community. Other great efforts in the file attachment tradition continue today with CarrierWave and Filepicker.io.

I remember coming to Rails and learning a ton by going to technoweenie's Subversion account. Paperclip and Shoulda were open sourced on a custom Subversion instance at svn.thoughtbot.com.

Once GitHub came out, it became obvious that Git and GitHub were the superior way to share code. We moved our older libraries over to GitHub and have continued to chip in on other projects and some of our own. Shoulda has evolved into a library that works beautifully with RSpec. Factory Girl was written to replace fixtures.

We added test spies to a fork of Mocha, then a standalone library called Bourne that extended Mocha, and more recently added spies to RSpec Mocks. We didn't invent the test spy technique (we recommend everyone reads xUnit Test Patterns), but we worked hard to bring them into our workflow and add them to the existing tools in the community, evolving as those tools have gotten better and gained community support.

We wrote Clearance (which I personally maintain) after writing email-and-password-based authentication a few times by hand. We wrapped it in a library with a great automated test suite. It's now a battle-tested, four year old library. Things like that we're always trying to tweak and improve, as well as blog about it to keep the community informed and see how we're evolving our practices.

We've described our development process in our playbook and guides.

I've taken better advantage of my shell (zsh) and editor (vim). I've tightened my feedback loops, particularly when writing tests. I've gotten more consistent and disciplined about style and Git flow. I understand and use object-oriented techniques better.

I think they're great! I'm most looking forward to the speed improvement and named parameters in Ruby. I'm most looking forward to the additional Postgres integrations in Rails 4, like hstore and database array types.

We don't have any major projects in production on Rails 4 or Ruby 2 yet. Looking at the history of past releases, we tend to be careful not to jump the gun. We've been testing our open source libraries against both versions for awhile and reporting any issues back upstream, fixing what we can, but for the sake of our clients, we're a bit more conservative to adopt the newest technology.

For a long time, I've been wrapping my head around some of the base choices you need to make as a developer. We've had a less-than-a-hundred-line shell script called Laptop for a couple of years to help us set up new machines while documenting the current best practice we know of. I still think there's lots of room for improvement here, though.

Let's say you're using OS X. You probably want to use Homebrew but it's not the standard package manager for the operating system. I'd like to see Apple make that the standard. In the same way, Ruby installers, Ruby switchers, Bundler's binstubs, the .ruby-version file community convention, and rbenv's shims continue to evolve to manage different versions of libraries that you want to use on different projects.

It's unlikely we would make a primary replacement for Ruby as our server-side language.

I don't know! In the near future, definitely - there's a lot we can accomplish with Ruby, SQL, and JavaScript. It's unlikely we would make a primary replacement for Ruby as our server-side language. It's more likely we'd work on projects that use service-oriented architectures and the various services start to use alternative frameworks and languages such as Go.

I'd expect us to be more polyglot as opposed to replacing Ruby. We've used lots of databases in the past few years, although, Redis and Postgres can currently handle 99% of our use cases.

I'd also like to try doing something like the Barack Obama 2012 campaign's architecture, which was static HTML/CSS/JS served by Akamai and S3, with hundreds of backend APIs.

We've worked really hard for years to put our best advice on Learn Rails. We have a "trail map" specifically for learning Rails and we've curated it from across the web and in our own shop. Go in there and you can see which resources we recommend going through in which order. There's an iPhone app that helps you self-assess your own abilities and keep track of your progress along the Rails, Git, Postgres, JavaScript trails, and other trails.

In Conclusion

Thank you Dan for taking the time to do this interview, we really appreciate it.