April 03, 2013

the bot cave, March 2013

thoughtbot logo

This is the March 2013 edition of our newsletter, "the bot cave."

It contains our research on tools and techniques we're trying but don't think are polished enough yet to share GIANT ROBOTS, in the playbook, or merge into a master branch of an open source project.

It is organized like this:

  • Ruby 2.0
  • Sandi Metz' Four Rules
  • Cane
  • Zapier + Trello for Hiring
  • Google Docs
  • Conclusions From Previous Experiments

Enjoy but proceed with caution as you enter... the bot cave.

Ruby 2.0

Speed and named parameters: what's not to love? There is no question we will eventually move our production apps to Ruby 2.0 but there is a question of "when?"

Our process for determining when to upgrade has been to test the Ruby 2.0 compatibility of all the gems we use in Suspenders.

Most of those gems have test suites that run against Travis CI, which lets us specify different Ruby versions to run the test suite against. If there's a release of the gem after passing on Ruby 2.0, we consider it compatible.

We are about 50% of the way through evaluating those gems.

Sandi Metz' Four Rules

We are trying Sandy Metz' Four Rules:

  1. Your class can be no longer than 100 lines of code.
  2. Your methods can be no longer than five lines of code.
  3. You can pass no more than four parameters, including options hash members, to a method.
  4. When a call comes into your Rails controller, you can only instantiate one object to do whatever it is that needs to be done. As a corollary, controller actions can only set one instance variable for the view.

Any of these rules can be broken if you can convince your pair or pull request reviewer of the necessity.

Additionally, we enforce these rules on any existing methods and classes we touch. We can't bump classes or methods over 100 and 5 lines, respectively, and we'll attempt to refactor methods to not take more than four arguments.

Cane

Along similar lines of enforcing strict guidelines on ourselves and finding the boundaries of what is healthy and what isn't beneficial, we have been experimenting with Square's Cane.

It enforces style guidelines like trailing whitespace and code quality guidelines like method complexity. The following configuration in a Rakefile will fail the build if the guidelines aren't followed:

begin
  require 'cane/rake_task'

  desc 'Run cane to check quality metrics'
  Cane::RakeTask.new(:quality) do |cane|
    cane.abc_max = 10
    cane.add_threshold 'coverage/covered_percent', :>=, 99
    cane.no_style = true
    cane.abc_exclude = %w(Foo::Bar#some_method)
  end

  task default: :quality
rescue LoadError
  warn 'Cane is not available. The quality task is not provided.'
end

Zapier + Trello for Hiring

What kind of crazy person would subject themselves to joining a team who experiments with guidelines like five line methods and whitespace-that-fails-the-build rake tasks?

When someone applies to apprentice.io, their application ends up on a Trello board that we manage in a very similar style as Ryan Carson's How to hire a lot of talented people, very quickly.

One difference is we use Zapier to route candidates' applications from their Wufoo form to the first list in the Trello board.

We recently switched our sales pipeline to use the same process.

The benefits of Trello for the hiring process include:

  • assigning cards to teammates who are interviewing candidates at each stage so everyone knows who is currently responsible
  • creating new ad-hoc lists as processes change
  • great iPhone integration
  • using it for many other processes (sales, editorial calendar, technical research for the bot cave) so we're comfortable with one system
  • can assign due dates to respond to candidates who need to be processed particularly quickly (they have other offers)
  • use Markdown
  • upload files like emailed code samples

The other system that we're still using simultaneously to Trello has a permission model that allows management to see comments and talk salary. The way we're using Trello for hiring is more of an open system where all the full-time thoughtbot designers and developers can see each others' comments on the candidates.

The other system has the ability to forward email correspondence to the candidate's record. Without that ability, it's less likely we'll accidentally talk salary on the card.

When we hire someone, we delete their card. The board is just meant to organize the hiring process. Once they're hired, we can delete the data.

Glossary Google Doc

On some projects, we share a Google Doc with the team. It contains definitions of terms which are relevant to the software we're building. Some terms will end up being modeled in code and others are external, real-world terms. It can be helpful to identify synonyms in this document in order to train ourselves to try to use one primary term throughout the codebase and user interface.

Eric Evans refers to this concept as Ubiquitous Language in "Domain Driven Design."

Project Brief Google Doc

We have also been experimenting with a Google Doc that contains the following information in order to make communication and onboarding new project teammates really smoothly. It has the following general format.

Team:

  • First Last - Product Manager (name@client.com (555) 555-5555)
  • First Last - Developer (name@client.com, @github)
  • Dan Croak - Advisor (dan@thoughtbot.com, @croaky, (555) 555-5555)
  • Galen Frechette - Designer (galen@thoughtbot.com, @frechg)
  • Scott Albertson - Developer (scott@thoughtbot.com, @salbertson)

Email all team members at client@thoughtbot.com.

Schedule:

  • thoughtbot works Monday-Thursday
  • Monday 9am-10am product meeting, everyone
  • Thursday planning, Designer, Product Manager 4pm-5pm

Guides:

Communication:

Code:

Environments:

Glossary:

Credentials:

Conclusions From Previous Experiments

After further research, we concluded these experiments from previous months were failures:

  • Use Redis as a Rails i18n backend. The "in-memory Ruby" and "promote staging copy to production" features of the open source Copycopter web service make it the king of the hill.
  • Pixate for iOS design. NUI, an open source alternative, is free and better. NUI has text shadow support, gets updated more often than Pixate, and works with Cocoapods.
  • Order methods alphabetically in a class. This was not a clear-cut case, but we are currently using Dependency Method Order instead.

After further research, we concluded these experiments from previous months were successes:

  • Run specs directly from vim.
  • Use better_errors for local Rails development errors.
  • Use Foreman to run our applications in development.
  • Use Postgres Hstore instead of ActiveRecord's serialize method for situations where we have data that represents a key-value pair of strings and we want to do denormalized searches on those strings.
  • Use Oj instead of Yajl for JSON parsing.
  • Use Splunk for logging.
  • Use Stripe for processing credit cards.
  • Use the .ruby-version file convention to specify the Ruby version and patch level of a project. Check it into version control.
  • Use The Silver Searcher instead of ack or grep.

Learn Prime

We're continuing to adapt learning experiences for ourselves, for our apprentices, and for students around the world.

This past month, we announced a $99/month subscription called Learn Prime that gives individuals access to all our workshops, screencasts, e-books, a private blog, and a private Campfire room staffed by thoughtbot team members. The total value of those items would be $8,399 if purchased individually.

The subscription also gives individuals access to future content.

If you have feedback for us about anything in this newsletter, please reply to this email.

— The folks at thoughtbot