giant robots smashing into other giant robots

Types of Coupling

Tue, 15 May 2012 14:17:00 -0400

Those of you coming from a Google search are about to be disappointed: this is a post about types of coupling in programming.

Coupling refers to the degree to which components in your program rely on each other. You should generally seek to minimize this property, though you’ll see it’s impossible to eliminate entirely.

Here are a few types of coupling, ordered by severity (first is worst):

Pathological Coupling

Your class reaches inside another class and reads (or, perish the thought, changes) its instance variables.

You are literally pathological and deserve the pain this will cause you.

class NuclearLaunchController
  def initialize(launch_codes)
    @launch_codes = launch_codes
  end
end

class ExtremelyBadIdea
  def initialize(nuclear_launch_controller)
    @launch_controller = nuclear_launch_controller
  end

  def do_bad_things
    # This is poison
    @launch_controller.instance_variable_set(:@launch_codes, 'password')
  end
end

Global Coupling

You have two classes that both rely on some shared global data, maybe a Singleton or a class variable.

When many test files all depend on global factory definitions, a change to any one can ripple through the system.

# spec/factories.rb
FactoryGirl.define do
  factory :user do
    # Changes here are global and can affect many test files.
  end
end

# spec/model/user_spec.rb
before do
  # This refers to global data.
  @user = build_stubbed(:user)
end

# spec/model/order_spec.rb
before do
  # So does this.
  @user = build_stubbed(:user)
end

Note that this is probably an example where the cure (duplicating the logic for creating test objects in every spec) is worse than the disease.

Control Coupling

You pass in a flag that tells a method what to do.

Remember save(false) in ActiveRecord? That boolean argument caused control coupling. Remember how we all had to change our code when it became save(validate: false)? If we’d been calling save and save_without_validation instead, Rails Core could have refactored that method more times than the router and we’d never have known. Also, notice that passing validate: false into save does not reduce the coupling, it’s just disguised better.

Control couples are smelly because the calling method has intimate knowledge of how the receiver implements the method being called. You’re determining what an object should do based from outside it. Good OOP lets objects decide what to do based on their own state.

def save(should_run_validations=true)
  # When you see a parameter in a conditional, that's control coupling.
  # The fact that this method has an if in it has leaked out into client code.
  # Changes can now require changes in these clients.
  if should_run_validations
    run_validations
    persist
  else
    persist
  end
end

# One possible fix: define two methods and let the clients 
# choose which to call. Now we can refactor either without 
# affecting clients.
def save
  run_validations
  persist
end

def save_without_validations
  persist
end

Data Coupling

You call a method and pass it a parameter that doesn’t affect its control flow.

This is still coupling, but we’re starting to reach the kind that isn’t so bad. Sometimes you need parameters! If you wanted to remove all coupling you wouldn’t be able to pass data between objects at all.

class ScreenPrinter
  # This method is coupled to its parameter, because a change to that argument 
  # can cause breakage (if we undefined to_s, for example).
  def print(text)
    output_to_screen(text.to_s)
  end
end

Message Coupling

You call a method on an object and send no parameters.

You’re coupled to the name of the message, but not any hint of its implementation. This is the loosest type of coupling and should be your goal. Notice that this makes methods that take no arguments better than methods that take one (and so on).

# No reliance on anything outside this object. Feels good, man.
class ScreenPrinter
  def print_to_screen
    output_to_screen(@text)
  end
end

Keep an eye out for the nasty types of coupling in your code, and see if you can can’t refactor it into something further down the ladder.

(I cribbed this list of coupling types from Wikipedia’s article, paraphrased and added examples. The original article is worth reading.)

Get your callbacks on with Factory Girl 3.3

Tue, 15 May 2012 09:44:00 -0400

FactoryGirl 3.3.0 was released this weekend with a slew of improvements.

To install, add (or change) your Gemfile:

gem 'factory_girl_rails', '~> 3.3.0'

New Callback Syntax

Callbacks have been revamped to work well in conjunction with custom strategies. Instead of declaring callbacks like this:

FactoryGirl.define do
  factory :user do
    factory :user_with_posts do
      after_create {|instance| create_list(:post, 5, user: instance) }
    end
  end
end

you can declare callbacks with before and after, passing the symbol of the callback as the name:

FactoryGirl.define do
  factory :user do
    after(:custom) {|instance| instance.do_something_custom! }

    factory :user_with_posts do
      after(:create) {|instance| create_list(:post, 5, user: instance) }
    end
  end
end

Finally, you can use completely custom callbacks without a before or after prepended by just calling callback:

FactoryGirl.define do
  factory :user do
    callback(:custom_callback) {|instance| instance.do_something_custom! }
  end
end

These work great with custom strategies:

class CustomStrategy
  def initialize
    @strategy = FactoryGirl.strategy_by_name(:create).new
  end

  delegate :association, to: :@strategy

  def result(evaluation)
    @strategy.result(evaluation).tap do |instance|
      evaluation.notify(:custom_callback, instance) # runs callback(:custom_callback)
      evaluation.notify(:after_custom, instance)    # runs after(:custom)
    end
  end
end

Support all `*_list` methods

FactoryGirl already introduced build_list and create_list to build and create an array of instances; in 3.3.0, *_list methods are generated dynamically for all strategies registered, so build_stubbed_list and attributes_for_list join the immediate roster of methods; if you were to register a strategy named “insert”, insert_list would exist as well.

Fix `to_create` and `initialize_with` within traits

Traits are a great way to name an abstract concept of attributes, but for a long time, they didn’t support defining to_create or initialize_with. 3.3.0 fixes this shortcoming by having to_create and initialize_with behave in traits exactly as you’d expect. This is perfect for decorating objects from within FactoryGirl.

class NotifierDecorator < BasicObject
  undef_method :==

  def initialize(component)
    @component = component
  end

  def save!
    @component.save!.tap do
      Notifier.new(@component).notify("saved!")
    end
  end

  def method_missing(name, *args, &block)
    @component.send(name, *args, &block)
  end

  def send(symbol, *args)
    __send__(symbol, *args)
  end
end

FactoryGirl.define do
  trait :with_notifications do
    to_create {|instance| NotifierDecorator.new(instance).save! }
  end

  factory :user
end

create(:user, :with_notifications) # decorates save! when the instance is created


FactoryGirl.define do
  trait :with_notifications do
    initialize_with { NotifierDecorator.new(new) }
  end

  factory :post
end

create(:post, :with_notifications) # returns a post instance decorated with NotifierDecorator

Define `to_create` and `initialize_with` globally

If you’re using an ORM other than ActiveRecord, you may want to call different methods for persistence. Declaring a to_create (or initialize_with, if you wanted to use a global decorator) within the FactoryGirl.define block will now apply to all declared factories, behaving much like sequences, traits, and factories.

You can override the global to_create or initialize_with with traits or by defining to_create in a factory explicitly.

FactoryGirl.define do
  to_create {|instance| instance.persist! }

  factory :user do
    factory :user_backed_by_active_record do
      to_create {|instance| instance.save! }
    end
  end
end

What’s next?

There are still cases where traits don’t behave correctly (using implicit traits is a big remaining bug) and more work for initialize_with and accessing attributes needs to be done.

Beware Homonyms

Sun, 13 May 2012 15:29:00 -0400

When you name a class, choose a name that’s unlikely to refer more than one thing.

For example, Visitor is a bad name for a class that represents unregistered users.

The issue is that Visitor is the name of a well-known pattern. Like it or not, the Gang of Four claimed this one (that’s why they’re called a gang).

If you use this class name in a web app, I can guess which concept you’re referring to, but the ambiguity is unsettling. I’m not sure. The name has homonymatic complexity: it sounds too much like another thing.

UnregisteredUser is a better name. It’s easy to guess what this refers to.

However, notice the ambiguity is affected by the problem domain: in a voter registration app, this name would again be ambiguous.

In general, choose names so colleagues can easily guess an object’s identity.

SHOULDA BEEN GONE

Sat, 12 May 2012 09:14:25 -0400

We haven’t been taking pull requests on shoulda-matchers as much as we shoulda, but it’s back in the spotlight now. Shoulda’s been gone … but it’s back.

Here are the new features in shoulda-matchers 1.1.0:

A NEWS file so you can track new hottness in REAL TIME
shoulda-matchers’ very first dependency: ActiveSupport >= 3.0.0. This was an implicit dependency for a while, but now it’s official.
An only_integer option for validates_numericality_of
A query_the_database matcher, so that you can do it { should query_the_database(4.times).or_less }
Database column primality is correctly checked
The flash matcher can check specific keys using [], like so: it { should set_the_flash[:alert].to("Bad username") }
A validates_confirmation_of matcher: it { should validate_confirmation_of(:password) }
A serialize matcher: it { should serialize(:details).as(Hash).as_instance_of(Hash) }
A have_sent_email matcher can now check reply_to: it { should have_sent_email.reply_to([user, other]) }
An accept_nested_attributes matcher

If you filed a pull request and we didn’t take a look, please re-submit or ping me on Github. We’d love to hear from you.

Read between the lines

Thu, 10 May 2012 08:43:21 -0400

People frequently use lines of code as a metric. How many times have you heard someone say, “it’s only 10 lines?” or “This class is almost 200 lines?” Have you ever heard somebody boast that they could write something in fewer lines of code? Do you talk about your test to code ratio?

How many lines of code something takes doesn’t tell us much about the code. Let’s take a closer look at some better metrics.

Complexity

Focusing on lines of code encourages developers to jam as much complexity as they can into each line.

Compare this example:

def credit
  user && coupon = user.coupons.where(:product_id => product.id).first.try(:amount) || 0
end

To this one:

def credit
  user && user.coupon_for(product).amount || 0
end

# On User
def coupon_for(product)
  coupons.where(:product_id => product.id).first.try(:amount)
end

Although the first example is only three lines of code, it has a lot of complexity in one method. That means this method is harder to understand, reuse, modify, or extract. Flog rates this method at 13.9.

The second example example has twice as many lines, but each method is less complex. Flog rates the second example at 8.1 per method.

Even in the second example, the methods are dense. Further refactoring would result in more lines of code, but smaller, simpler methods.

Readability

The previous example also improves readability. Every method you extract is an opportunity to clarify something by naming it, while every piece of complexity you add to a line is anonymous.

Code is frequently more readable when it expands over multiple lines of code. Here’s a common Ruby idiom:

users.each(&:friend_added) if new_record?

I like to call this the “if surprise.” It’s easy to scan down a method and miss that dangling if, not realizing that the method you’re debugging actually has a logical fork.

I prefer this:

if new_record?
  users.each(&:friend_added)
end

It’s three times as many lines, but the same amount of complexity, and more readable.

Test to code ratio

Another place that people obsess over lines is their test to code ratio. Rails even comes with a task to print this stat out for you, and many presentations use this stat when bragging about their test coverage (or lack thereof). There are a few things that make this metric meaningless:

Some frameworks create taller code. RSpec tests tend to have more lines than the same Test::Unit test, despite having the same coverage.
The best way to have a high test to code ratio is to copy and paste test code, which is the testing equivalent of never flushing your toilet.
How many tests you have is a poor metric for measuring the quality of the test suite.

Here are some questions that can be useful when measuring your test suite:

Were all the tests written before the code that they motivate?
Do you have 100% C0 coverage? Ask rcov or simplecov.
Do your tests break if your code breaks?
Is there duplication in your tests?
Can you read your tests easily?
If you add new code, do old tests break?
Can you refactor one class without breaking the tests for other classes?

No code is faster than no code

Merb popularized this saying and encouraged users not to use code they didn’t need. However, it’s important not to misinterpret this by assuming that fewer lines of code means less code, and therefore faster code.

Here’s an example of a minimal Fibonacci sequence:

class Fibber
  def fib(n)
    if n < 2
      n
    else
      fib(n - 1) + fib(n - 2)
    end
  end
end

This implementation is pretty slow. It took almost five seconds to print out the first 35 numbers in the sequence on my machine. You can improve the performance dramatically with just a few more lines:

class Fibber
  def initialize
    @cache = {}
  end

  def fib(n)
    if n < 2
      n
    else
      @cache[n] ||= fib(n - 1) + fib(n - 2)
    end
  end
end

This takes around a millisecond on my machine.

Your application will perform better if you remove functionality you don’t need, but removing lines and watching the tests still pass doesn’t mean you haven’t lost anything.

Edge cases

In version 2.4.0 of factory_girl, we added almost three hundred lines of code and almost no features. That seems like a lot of code for no new functionality, but what actually happened is that we fixed a number of annoying bugs. Fixing the last few edge cases for a library can be a huge undertaking; the last ten percent frequently takes as long as the first ninety percent. There have been times that we’ve been tempted to rewrite factory_girl, because it doesn’t seem that hard to implement at a glance. However, a new implementation would reintroduce bugs that have been fixed for years.

If you’re thinking of rewriting something, remember that it’s probably not as easy as it looks. You don’t just have to reimplement the features; you have to fix the edge cases, too.

Love your lines

Let’s stop thinking in terms of lines of code. Here are a few tips:

Think in terms of complexity, not lines
Use flog or rcov, not wc -l
If you want to remove complexity or improve performance, remove features and not just code

As a community, we’ve developed a number of techniques and tools for evaluating code. We can do better than just counting lines.

Use Factory Girl's build_stubbed for a Faster Test Suite

Wed, 09 May 2012 10:49:00 -0400

Want to speed up your test suite? Reduce the number of objects persisted to the database. With Factory Girl, this is really easy; instead of using build or create to instantiate your models with data, use build_stubbed!

build_stubbed is the younger, more hip sibling to build; it instantiates and assigns attributes just like build, but that’s where the similarities end. It makes objects look look like they’ve been persisted, creates associations with the build_stubbed strategy (whereas build still uses create), and stubs out a handful of methods that interact with the database and raises if you call them. This leads to much faster tests and reduces your test dependency on a database.

For example, let’s say we have an OrderProcessor that accepts instances of Order and CreditCard. It hits the Braintree API and returns a boolean value for if the charge actually happened.

class OrderProcessor
  def initialize(order, credit_card)
    @order = order
    @credit_card = credit_card
  end

  def process
    charge_successful? charge_customer
  end

  private

  def charge_successful?(result)
    # processes the result to determine if the result is valid,
    # operating on the order and credit_card instance variables to
    # add errors, send emails, or track Braintree's transaction id
  end

  def charge_customer
    # runs Braintree::Customer.sale() with the appropriate options
  end
end

None of this code hits the database. This allows us to write tests like:

describe OrderProcessor do
  let(:transaction_id) { '1234' }
  let(:order) { build_stubbed(:order) }
  let(:credit_card) { build_stubbed(:credit_card) }

  subject { OrderProcessor.new(order, credit_card) }

  context 'when the Braintree result is valid' do
    before do
      MockBraintree.stub_successful_customer_sale(transaction_id: transaction_id)
    end

    it 'assigns the transaction id to the order' do
      subject.process
      order.transaction_id.should == transaction_id
    end

    it 'returns true for #process' do
      subject.process.should be
    end

    it 'does not assign any errors to the credit card' do
      subject.process
      credit_card.errors.should be_empty
    end
  end

  context 'when the Braintree result is invalid' do
    before do
      MockBraintree.stub_unsuccessful_customer_sale
    end

    it 'does not assign the transaction id to the order' do
      subject.process
      order.transaction_id.should be_nil
    end

    it 'returns false for #process' do
      subject.process.should_not be
    end

    it 'assigns errors to the credit card' do
      subject.process
      credit_card.errors.should_not be_empty
    end
  end
end

Instead of creating twelve different records (at the minimum - if any of these factories have associations, you introduce more multipliers), we create none. This keeps the spec blazing fast.

Properly factored code should be small and concise. Code should typically depend less on the state of the data in relation to the database and more on its state in relation to other objects. In the above example, OrderProcessor only handles dealing with Braintree and dealing with its errors; it does not care about how this data is displayed to the user. That’s left for the integration tests, which should be hitting the database.

Although it’s not useful in every situation (there are cases where you’ll want data to exist, like when you’re testing uniqueness constraints or scopes), build_stubbed should be your go-to FactoryGirl method over build or create. Everyone running your test suite (yes, even yourself) will thank you.

Constrain Yourself

Tue, 08 May 2012 10:27:00 -0400

Most Rails developers have written apps where you have a marketing homepage and a route that you should be redirected to after signing in. There may even be different pages to be redirected to after signing based on some sort of role system.

Who wants to remember that route across the app? No one.

Instead of writing a nasty helper to determine where to send a user after signing in, let’s have Rails handle this for us.

Enter Rails routing constraints.

It turns out Rack is a beautiful piece of software! With Rails routing constraints, we can re-use the Rails’ root to handle all this logic for us. This means no more remembering where root_url will take you or stuffing all that logic into some giant switch statement!

For example, I recently wrote an app using Clearance and high_voltage. When visiting the root path without being signed in, I wanted to render high voltage’s ‘homepage’ view. If the user was signed in, I wanted to display an administrative page where they could manage their assets.

My routes file looks like this:

root to: "assets#index", constraints: Clearance::SignedInConstraint
root to: "high_voltage/pages#show", id: "homepage"

Two roots! My constraint to hitting assets#index is based off my class Clearance::SignedInConstraint, which I’ve thrown in lib/.

# lib/clearance/signed_in_constraint.rb
module Clearance
  class SignedInConstraint
    def self.matches?(request)
      request.env[:clearance].signed_in?
    end
  end
end

This looks to request.env[:clearance] (introduced in Clearance 0.13), which returns a Clearance::Session instance, and allows us to call #signed_in?.

With Rails constraints, if .matches? returns true, the constraint is fulfilled and the router allows assets#index to do its thing. When false, the route ‘falls through’ and the next root kicks in.

Constraints are a great way to scope routes based on particular preconditions and may end up cleaning up a handful of nasty conditional logic in a view helper. Constraints can be great for things like subdomains as well, but I’d love to hear about some more inventive uses.

Humans Present: Refactoring

Sat, 05 May 2012 09:18:53 -0400

In the latest Humans Present, I sit down with Joe Ferris, our CTO, and we refactor real code from Trajectory.

This hour and ten minute interview and screencast shows:

What is refactoring and what you need to do it
Pros and cons of different refactoring techniques
Removing duplication
Extracting code to classes and modules

The changes in this video were merged into master and deployed to production the week after filming.

You can purchase this video for $15 or buy it for your entire company for $50. Check it out now. Click through for a preview.

We hope you like it.

I Suck at Testing

Fri, 04 May 2012 09:24:00 -0400

Testing is widespread in the Rails community, which is awesome. For most new developers, learning to test is not simple. New developers often think testing should come naturally if you can code well. I mean, I wrote the code, I should be able to write a test for it, right? Over the past 2 months at thoughtbot I’ve come to learn why this is false and now I’m learning to test.

Testing is Hard

Testing is like any other skill, you have to practice to get good at it. Good test driven developers use previous experience to figure out what tools to use when presented with new challenges. Don’t get discouraged when you don’t know how to test something, just take a step back and evaluate the problem. Improving your testing skill also requires discipline and persistence.

Testing is a discipline

No matter how dedicated you are to testing, there are times when it will slow you down. At that point, its really easy to skip testing, just this one time. It takes discipline to make sure that doesn’t happen. Take the extra time, invest the extra effort and find out how to test it, and then in the end your development process will speed up.

Ask for help

The Rails community has tons of people willing to help. If you get stuck on testing something, google first, then check out the Rails forums or the Rails IRC channel. Don’t hesitate to comment on blog posts which come close to solving your problem, but fall short. I’ve found the Rails community to be very helpful so don’t be afraid to ‘drink from the firehose.’

It gets better

Learning to be a good at test-driven development is hard, but being a developer is hard in general and testing skills must be practiced. Once you start writing tests more regularly, you also learn how to write code that is inherently easier to test. I joined apprentice.io to become a great developer and learning to test well is half the battle. It’s ok to suck at testing when you begin, but practice makes perfect. A great place to start learning is our Intro to Test Driven Rails Workshop, we have a course coming up later this month. Soon enough, you will think in tests before thinking in code.

Come Correct with Inject and Collect

Thu, 03 May 2012 09:31:21 -0400

Here’s a refactoring example for a simple Ruby math problem using the inject method.

The goal is to generate an n by n multiplication matrix. Pretty straightforward. Let’s make a first pass:

def multiplication_table(n)
  results = []

  (1..n).each do |row_index|
    row = []
    (1..n).each { |column_index| row << row_index * column_index }
    results << row
  end

  results.each do |row|
    header = '%-3s ' * row.length
    puts header % row
  end
end

multiplication_table(7)
1   2   3   4   5   6   7
2   4   6   8   10  12  14
3   6   9   12  15  18  21
4   8   12  16  20  24  28
5   10  15  20  25  30  35
6   12  18  24  30  36  42
7   14  21  28  35  42  49

It does the job, but it’s nothing to look at. We can condense using in-line blocks and fancy curly braces, but first let’s try using inject.

Quick background: Inject iterates over a set using a block with a collector, which is a variable whose value is passed back each round, making it good for iterative uses. The block’s return value is passed into the collector (make sure you return something or you’ll get a nil). Also, the return value of the whole inject block is the final collector value.

Simple example from the docs:

(5..10).inject {|sum, n| sum + n }            #=> 45

The inject method takes a parameter, which initializes the collector value (default is to set to the first value). You can pass in an empty array and add values:

def multiplication_table(n)
  results = (1..n).map do |row_index|
    (1..n).inject([]) { |row, n| row + [row_index * n] }
  end

  results.each { |row| puts '%-3s ' * row.length % row }
end

So that’s inject with the iterative collect (Whoo-aaaa - got you all in check)

Note: For a more in-depth discussion of inject, read Mike Burns’ recent post.

How to extract an intention-revealing name using Vim

Wed, 02 May 2012 11:47:10 -0400

This method has a magic number:

def wait_time
  @env[QUEUE_WAIT_HEADER].to_i / 1000
end

Let’s extract that to an intention-revealing name. We’ll type:

/1000<Enter>                   # Find the number we want to extract
cwmilliseconds_per_second<Esc> # Replace the number with a variable name
O<Ctrl+A> = <Esc>p             # Assign the replaced number to the variable

The result:

def wait_time
  milliseconds_per_second = 1000
  @env[QUEUE_WAIT_HEADER].to_i / milliseconds_per_second
end

Under the covers:

<Ctrl+A> inserts the last text you typed in insert mode, so the variable name is available after replacing the number
Replacing or deleting text in Vim will place that text in your default buffer, so the number is available to put at the end

Assuming your cursor is at the value you want to extract, this creates an intention revealing name in 10 keystrokes, plus the keystrokes it takes to type out the name.

Can you beat my Vim golf?

Date and time formats for pirates

Fri, 27 Apr 2012 13:59:00 -0400

Need to display a date in your Rails app? First try:

Time.now.strftime "arrrround %H'ish"

To remove duplication, you imagine a time format initializer. Second try:

Time.now.to_s :pirate

Then you remember the :default localized key. Third time’s a charm:

l Time.now

It formats based on the config/locales/en.yml file:

en:
  time:
    formats:
      default: "arrrround %H'ish"
  date:
    formats:
      default: "arrrround %H'ish"

Dates work, too:

l Date.today

The same system lets you alter the display of “days ago” and “minute from now.”

Inbox Zero: Github Issues Edition

Fri, 27 Apr 2012 13:30:00 -0400

We’ve noticed unpleasant trends in our most popular open source projects:

patches not getting merged
bugs not getting fixed
issues going unanswered

We believe the causes of the problems are:

feature requests, help requests, bug reports, and patches all in the same system
limited amount of manpower

We want to do better so we’re trying a new policy that we believe is helping.

Limit what’s in the queue

The Github Issues queue should contain items we can act on and close quickly.

This means feature and help requests should be submitted to the appropriate mailing list. If you’re worried about your pull request not being accepted, reach out to us on the mailing list before you start coding.

We’re trying to keep issues restricted to two kinds:

Pull requests that we can easily merge in
Bug reports that we can act on

We’re always going to be looking at pull requests before issues, meaning the fastest way to get your bug fixed is to submit a pull request that fixes it.

We’ve been doing this on a few projects and the results have been good.

By keeping the list restricted to items that we can act on quickly, we’ve brought Paperclip’s issues count down to 25 from hundreds and Factory Girl’s issue count has consistently been in the single digits.

Although this means that we’ll be closing some issues that might represent real bugs or valuable features, we’ve found that we can actually move more code through the queue by weeding out the issues that we can’t act on.

To recap:

Pull requests will be addressed first.
Bugs that we can’t reproduce or act on quickly will be closed.
Feature and help requests will be closed with a link to the mailing list.

Humans Present: An OSS Lifestyle

Thu, 26 Apr 2012 11:33:20 -0400

I recently sat down with Mike Burns to discuss his operating system and computer setup. Mike uses an entirely Open Source stack.

We discussed how he got started with this, the current state of running Linux, as well as some of the unique benefits and cool features of doing so.

We decided to make this special video available for free, and you can watch it here.

What is good code?

Wed, 25 Apr 2012 09:31:00 -0400

We often discuss the principles we use to write what we consider good code - test-driven development, object-oriented programming, SOLID, DRY, Law of Demeter - the list goes on. Sometimes it’s useful to remind ourselves of the fundamentals.

What is the code for?

Code makes an application work for users. Getting tests passing or removing duplication is useful, but the code needs to be shipped so that users can use it.

What kind of code is good?

Code needs to work. Assuming that as a prerequisite…

When code is easy to understand, we can change or extend it faster and are less likely to make a mistake in the process. Readability counts.

When code is easy to change, we can iterate on user feedback faster.

When code is fun to work with, we’re happier. Building software is our full time job. If we go home every day feeling wrung dry, something is wrong with our process.

Does good code matter?

Yes. Following certain principles can result in shipping products faster with fewer bugs and more programmer happiness.

How do our principles result in good code?

Test-driven development helps us understand code because we state the reason for each line of application code in the test. It also makes us happy by providing a clear process for working.

An automated test suite helps us change code because we have an early warning system when we break an existing component. It is fun to work with because we’re more confident and less fearful.

Removing duplication helps us read code by introducing semantic concepts and abstracting details. It also helps us change code by reducing the amount of code that needs to be touched for each change.

SOLID principles create individual components that help us understand code. SOLID helps us change code because components are reusable, swappable, and small.

How do our principles result in bad code?

Slow or brittle tests make code harder to change. We have to be careful about writing the correct tests and the correct amount of tests.

Are we writing good code right now?

Code isn’t good when it’s tested, DRY, or SOLID. Code is good when it works and we can work with it. When our teammates can understand our code quickly, respond to change, and are relaxed and happy, we’re writing good code.

FactoryGirl 3.2: so awesome it needs to be released during RailsConf

Tue, 24 Apr 2012 13:14:00 -0400

FactoryGirl 3.2 brings a slew of new features; while I’d considered breaking it all up into 3.2 and 3.3 releases, I decided to bundle them for MORE AWESOMENESS during RailsConf.

To install, add (or change) your Gemfile:

gem 'factory_girl_rails', '~> 3.2.0'

So, what does FactoryGirl 3.2 give you?

Implicitly Call FactoryGirl from Dynamic Attributes

Dynamic attributes are attributes you declare on a factory that are defined with a block to be evaluated every time the factory is run.

factory :user do
  name { NameGenerator.generate }
end

There have been a handful of times where I want to share a sequence or create a record inside of an attribute, but who wants to do this?

sequence(:long_string) {|n| "#{LoremIpsum.generate}#{n}" }

factory :user do
  name { FactoryGirl.generate(:long_string) }
end

Why type out FactoryGirl. in the block? In FactoryGirl 3.2, you don’t have to:

sequence(:long_string) {|n| "#{LoremIpsum.generate}#{n}" }

factory :user do
  name { generate(:long_string) }
end

If it just so happens that if you have a method named generate on your object and it’s colliding with FactoryGirl, you can still use the explicit FactoryGirl.generate(:long_string).

Deprecate Alternate Syntaxes

We’ve deprecated alternate syntaxes. This means if you’re using the object_daddy or machinist syntax, you’ll be urged to upgrade to the FactoryGirl 2 syntax. Support of the different syntaxes will be removed in FactoryGirl 4.0.

Why are we doing this?

We’re confident that the FactoryGirl 2 syntax is better than any other syntax out there. It’s clear, concise, and is incredibly flexible. It allows for usage of traits and other benefits we’ve added to the default syntax.

Skip the `to_create` Block Easily

Certain factories may skip the to_create block altogether (which normally calls #save!). Instead of calling to_create { } on the factory, you can now call skip_create.

factory :user do
  skip_create
end

Slim Down `initialize_with`

If you use initialize_with, you’ll know you can define your own construction method instead of just calling new without arguments. This becomes tedious, however, when you constantly repeate the build class.

We’ve created a shorthand for calling new within initialize_with:

factory :user do
  name "John Doe"

  initialize_with { new(name) }
end

Other class methods won’t be supported, but the common case (new) is covered for you!

Register Custom Build Strategies

Ever wish you could call FactoryGirl.json(:user) to get a JSON representation of your factory? Now you can. Ever wish attributes_for would build your association data instead of ignoring associations altogether? You can overwrite FactoryGirl’s implementation of attributes_for with your own code.

Here’s an example of registering your own JSON strategy, decorating the currently registered create strategy with additional behavior.

class JsonStrategy
  def initialize
    @strategy = FactoryGirl.strategy_by_name(:create).new
  end

  delegate :association, to: :@strategy

  def result(evaluation)
    @strategy.result(evaluation).to_json
  end
end

To register the new strategy, run

FactoryGirl.register_strategy(:json, JsonStrategy)

Once registered, you can refer to it like so:

FactoryGirl.json(:user)

I recommend digging through FactoryGirl’s current implementations of build, create, build_stubbed, and attributes_for, which use FactoryGirl’s brand new register_strategy interface.

Add ActiveSupport::Notifications Instrumentation

Now that we’ve dropped Rails 2 support, we can start using some of the awesome features of Rails 3. This includes ActiveSupport::Notifications, which uses pub/sub and allows us to track when factories get run.

Want to see which factories take longer than half a second to run? If you’re using RSpec, you could add this to the before(:suite) block:

ActiveSupport::Notifications.subscribe("factory_girl.run_factory") do |name, start, finish, id, payload|
  execution_time_in_seconds = finish - start

  if execution_time_in_seconds >= 0.5
    $stderr.puts "Slow factory: #{payload[:name]} using strategy #{payload[:strategy]}"
  end
end

Any slow factories will be written out to STDERR.

The other use case that I’ve wanted for a long time is keeping track of what factories I’m creating and the strategies used. Creating a record is obviously going to be significantly slower than building a stubbed version of it, so printing out a table of all the factories (and the number of times each strategy is executed for that factory) should be fairly straightforward. Feel free to dig into FactoryGirl’s acceptance tests to see a couple of straightforward uses.

What’s Next?

As we continue to move forward with FactoryGirl, we’re planning on making it easier to use initialize_with. I’d also love to see a pull request or example of generating a table of factories and strategy count (much like rake stats).

Turnip: a tasty Cucumber alternative?

Sat, 21 Apr 2012 09:12:00 -0400

We’ve used Cucumber heavily and successfully on client work, internal projects, and open source. We also love RSpec, so when we heard that Turnip would give the ability to run Gherkin based integration tests in our RSpec suite it was a no-brainer for us to try it out on a project.

Highlights of Turnip

Integrates directly into your RSpec test suite
Features and Step definitions live in the spec directory
No need to maintain two configuration files
Uses Ruby style symbols instead of regular expressions in step definitions
No need to write Given/When/Then in the step definitions file
Speed boost when running unit tests and integration tests together

We use Cucumber integration tests in thoughtbot’s clearance gem. In the example below I remove Cucumber and replace it with Turnip.

Steps used to change from Cucumber to Turnip

Set up your features directory inside the spec directory
Remove the Given/When/Then’s from the step definitions
Replace regular expressions in the step definitions with Ruby style symbols

Cucumber and Turnip use the same Gherkin syntax:

 Scenario: Visitor signs up with valid data
   When I sign up with "email@example.com" and "password"
   Then I should be signed in

Change the step definitions from Cucumber to Turnip style:

 # Cucumber step definition
 When /^I sign up (?:with|as) "(.*)" and "(.*)"$/ do |email, password| 
   visit sign_up_path 
   page.should have_css("input[type='email']") 
   fill_in "Email", :with => email 
   fill_in "Password", :with => password 
   click_button "Sign up" 
 end

 # Turnip step definition
 step "I sign in with/as :email and :password" do |email, password|
   visit sign_in_path 
   page.should have_css("input[type='email']")
   fill_in "Email", :with => email 
   fill_in "Password", :with => password 
   click_button "Sign in"
 end

Run the test suite

An advantage having everything running through RSpec is we get an immediate boost in speed when running the whole test suite. With Cucumber running Rake will run the RSpec and Cucumber tests (the Rails environment will be loaded twice). With Turnip all tests run through directly through RSpec (the Rails environment is only loaded once).

We save around 12 seconds when running the entire suite:

 # Rake running RSpec and Cucumber
 ~/Development/clearance_cucumber(master) $ time rake
 /Users/training/.rvm/rubies/ruby-1.9.2-p290/bin/ruby -S rspec ./spec/controllers/pages_controller_spec.rb ./spec/helpers/application_helper_spec.rb
 .

 Finished in 0.10696 seconds
 1 example, 0 failures
 /Users/training/.rvm/rubies/ruby-1.9.2-p290/bin/ruby -S bundle exec cucumber --profile default
 Using the default profile...
 .................................................

 13 scenarios (13 passed)
 49 steps (49 passed)
 0m1.729s
 rake 19.97s user 2.71s system 98% cpu 22.960 total

 # RSpec with Turnip
 ~/Development/clearance_turnip(master?) $ time rspec
 ..............

 Finished in 1.84 seconds
 14 examples, 0 failures, 0 pending
 rspec 8.85s user 1.06s system 95% cpu 10.362 total

Takeaways

Great light-weight solution for anyone already using RSpec
Step definitions easier to read than their Cucumber counterparts
Low barrier to entry for developers new to integration testing

This week in open source

Fri, 20 Apr 2012 16:49:00 -0400

factory_girl

There’s a new version of factory_girl this week, as usual: 3.1.1 (aa81d2f).

Mark Rushakoff (mark-rushakoff) fixed a typo (4682ab0). Have I mentioned how much I love documentation fixes? Because I do.

Joshua Clayton (joshuaclayton) ensured that FactoryGirl.attributes_for works with has_many associations (50be545). He also refactored Strategies to be modules instead of classes, and added an Evaluation façade to make building strategies easier (89d5e94).

flutie

flutie got some love this week from Edwin Morris (ehmorris), who changed values from pixels to ems (fd26ed0) and these new-fangled CSS3 “rems”. REMs are relative to the base element’s size, not to the parent’s size (more here). I wish I’d had that back in the day.

paperclip

paperclip got a bunch of bug fixes from Prem Sichanugrist (sikachu). He fixed the content_type validator to allow blanks and nils (5eed1dc), ensured that code dealt with the content type, not the MimeType (3f1d30f), closed ALL the files (4f6d482), and removed unused code (yay!) (02eb725).

Sebastien Guignot (sguignot) fixed attachment.reprocess! when using Fog or S3 (9d1355b).

Kir Maximov (kir) fixed a problem with an incorrect content_type (3e98fc2).

shoulda-matchers

shoulda-matchers continues to improve. Gabe Berke-Williams (gabebw - that’s me!) added tests for Rails 3.2 (aff2824) and bumped rspec-rails (5baa056). As ever, the NEWS file is the place to watch for updates to functionality.

Aaron Gibralter (agibralter) fixed the ensure_length_of matcher to check for all possible I18n error messages (0a8e652), meaning our internationalized users aren’t left with false negatives in their tests.

Victor Pereira (vpereira) added the in_array method (e40e2cb) to the ensure_inclusion_of matcher, meaning you can do it { should ensure_inclusion_of(:attribute).in_array(%w[cat dog]) now.

Meet thoughtbot at Railsconf 2012

Fri, 20 Apr 2012 11:21:00 -0400

We’ve had an abnormally warm Winter and Spring in Boston this year, but thoughtbot likes it EVEN HOTTER so we’re going south to Austin. As a bonus, Railsconf is there. If you’d like to meet a real, live thoughtbot employee, here’s who you can expect to see there:

Chad is the CEO of thoughtbot. You may recognize him from books like Backbone.js on Rails or movies like Humans Present: tmux. Chad’s been focusing on workshops and other learning materials. If you have an idea for a book, screencast, or workshop, come find Chad. I’m sure he’d love to hear about it!

Matt is our COO. He’s into movies, too, and he’s the mastermind behind such open source works as flutie and pacecar. If you have an idea for a web app or want to discuss your favorite kind of trail mix, look for Matt.

Joe isn’t always the CTO of thoughtbot, but when he is…actually, he always is. Joe is the original author of factory_girl and capybara-webkit. He’ll be working on those, as well as his secret project with Mike Burns. If you’re interested in any of those things, come find Joe.

Jon is one of the co-founders of thoughtbot. He wrote the paperclip gem. You may have heard of it. It’s kind of a big deal. He also wrote the excitingly-named cocaine. If you want to help out with paperclip, find Jon.

Mike is a long time thoughtbotter and just moved to Stockholm. He loves open source, Swedish slang, and the Oxford comma. If you want to discuss open source or pull requests, just follow your nose to the…well, look for Mike.

Josh likes testing more than he likes food or oxygen. He’s also the maintainer of factory_girl. If you want to yell about testing or factory_girl, Josh is ya boi.

Ben is a speaker and conference enthusiast. If you’re at a conference, look for Ben’s name. He’s probably on the speaker list under “v” for “Vim.” If you want to talk about speaking, Vim, or travel, you can’t do much better than Ben.

Prem is a frequent contributor to Rails (you may have heard of it), paperclip, and other open source libraries. If you have a strange problem with paperclip, the asset pipeline, or Rails in general, look for Prem; I bet he can tell you what’s happening.

Gabe brings humor, vocabulary, and Star Wars to thoughtbot. Gabe wrote kumade and can probably tell you how to pronounce it. He’s also a frequent contributor to open source, and has been focusing on shoulda’s matchers lately. For a good time, find Gabe.

Joel just started at thoughtbot after several years as a mercenary. He’s a chatty one, so if you’d like to talk about anything - Ruby, Rails, Sass, beer, dogs, beer for dogs, or the economic viability of dogs as laptop stands - find him. He’s the one with the big head.

Hope to see you there! If not, look for us at one of our other upcoming events.

thoughtbot in Bangkok

Wed, 18 Apr 2012 09:13:00 -0400

Sawasdee krub!

Jason Morrison is in Bangkok for a bit, and wants to talk shop and buy you drinks.

Come talk about testing in JavaScript-heavy web apps at the BKK Rails-JS meetup this Friday, April 20 at 19:00. Check the Meetup page for the full address and map.

Afterwards, come out and have a beer on us. All local Ruby, Web development, Web design, and startup folks are welcome! We’re meeting for drinks after the meetup at Mulligan’s Restaurant and Bar on Soi 11 - here are some Google Map directions.

If you can’t make it that day, get in touch with Jason on Twitter or by email.