Steve Klabnik — Ruby & Rails

Docember

Tue, 01 Dec 2015 00:00:00 GMT

There are few things I appreciate more than using software projects that have good documentation. When I’m new to the project, documentation is invaluable for helping me get going. When I’m not new, good documentation helps me get the information I need to :shipit:.

We say programming is hard, and we hate bad code. So we practice writing code.

We say writing docs is hard, and hate bad docs…

— Some(@steveklabnik) (@steveklabnik) November 30, 2015

About a month ago, I was tweeting about this topic, and several of us came up with an idea: similar to how November is National Novel Writing Month, why not have a similar month for programming?

Here’s the idea: in December, let’s try to work on the documentation for the projects we work on. Make it 50k words like NaNoWriMo, make it 24 pull requests, whatever floats your boat. Your future self will love you for it.

Rescuing Resque (again)

Wed, 28 Oct 2015 00:00:00 GMT

A long time ago, there was a big open source project, which was a huge part of the Rails world, but had almost no maintenance. This project was Resque, the go-to way to write background jobs for your Rails application. I attended a talk where the current maintainer was clearly getting burned out, and so, offered to help. The problem is, things have changed.

It wasn’t just me. It was a bunch of people. We all used Resque, and loved it, and wanted to make it better. We made plans for a big 2.0 to pay off a bunch of technical debt, simplify the codebase, and add more features. A ton of people chipped in, I had some awesome remote pairing sessions. Things were good.

But slowly, we all started to drift away. One contributor changed jobs. Another decided to spend more time with family. I got discouraged, and then, there was a strange situation in which I accidentally released an entirely straight-up broken version. So I got scared, released a fix, and basically never touched Resque again.

Resque is used by a lot of people:

Yet, it hasn’t seen a release in 18 months. The PRs are piling up. 2.0 is basically dead in the water. I’m not much of a fan of 2.0s anymore myself, at least, ones that don’t follow the “stability without stagnation” principles. I don’t use Resque myself anymore, and barely have enough time for my work, let alone my personal projects, let alone a project that I care about but only work on out of the goodness of my heart.

I’m here to tell you that that’s changing a little bit. I’ve been chatting with Chris Hoffman, who’s interested in starting up on work again. I asked him what his intentions were, and what he answered with was exactly what I wanted to hear, as it turns out. So, I’m going to be doing some work again, this time, with the explicit intention of handing off maintenance to Chris and anyone else who wants to chip in. If you use Resque commercially, this is a great time to give some of your people the opportunity to give back. If you’ve never worked on an open source project before, but want to, I’d be more than happy to help mentor you with this. Resque is a big, real project, with a lot of impact. You can do a lot of good. That’s why I started working on it.

Without further ado, here is The Plan, from Chris and I:

TL;DR

change master from unreleased 2.0 back to 1-x-stable
clean up tests - make the development experience enjoyable
integrate pending Pull Requests
2.0? Never heard of it. At least, not for a while.

Make `1-x-stable` master again

Many have stated that the README on the master branch has led them astray, because the published gem is still at 1.25.2.

We will plan on making this switch in the next couple of weeks. If you feel this is the wrong move, please let us know. But since active development will in fact happen on 1.x, this feels like the correct thing.

Fix up the test suite

Tests need to be fast, and clean, so that there is more incentive to contribute.

One possible approach is using one of the available Redis mocking libraries (mock_redis, fakeredis) in non-forking tests, which could speed suite execution up considerably.

Review Pending `1-x-stable` PRs

This is the lion’s share of the work, as there are currently 56 (that’s fifty six) open pull requests…

And that’s an awesome problem! Let’s make use of them! These PRs need to be evaluated and closed, so that the project can benefit from the community.

Decide What to do with 2.0

The focus of Resque should be on stability, with an eye towards legacy support. 2.0 is off the table, at least in the near term.

If there is a 2.0, it will be a “garbage collection”-style release, where only deprecated functionality is removed, and the upgrade path is clear.

Ember Data: ‘DS’ is not defined

Sun, 05 Jul 2015 00:00:00 GMT

I’m doing a little Ember app, and if there’s one thing I’ve learned from writing software, it’s to blog about error messages. Two-years-later me has ended up finding my own posts when searching for help!

So today, when getting started with Ember Data 1.13, I was trying to use the new JSONAPIAdapter. I saw this code snippet:

App.ApplicationAdapter = DS.JSONAPIAdapter.extend({
    namespace: 'v1',
});

Using that gave me an error when ember serve-ing, though:

app.js: line 16, col 26, ‘DS’ is not defined.

Turns out, DS isn’t in scope by default, even though ember-cli installs Ember Data by default.

Fixing this just means importing it at the top of app/app.js:

import DS from 'ember-data';

Easy enough!

Resque 1.25.0 has been released

Mon, 16 Sep 2013 00:00:00 GMT

I’ve just released Resque 1.25.0! Resque is the most stable, widely-used job queue for Ruby. It uses Redis as its backing store.

This release is thanks to adelcambre, who took the time to get it over the finish line! <3.

A total of 19 contributors helped out with this release, with 77 commits. Thank you to everyone!

This release contains no changes from the 1.25.0.pre release that was put out a few weeks ago, so if you’re using it, you can upgrade with no problems.

CHANGES

You can see the full CHANGELOG here.

This release had a pre-release because of one big change: a refactor to the forking code. This was introduced to fix a problem: the exit syscall raises a SystemExit Exception in ruby, its exit is treated as a failure, thus deregistering the worker. After the refactor + fix, things should be peachy. But please give the prerelease a try.

In addition, it has been discovered that we have accidentally introduced a SemVer violation back in v1.23.1: https://github.com/resque/resque/issues/1074

I take SemVer seriously, and apologize for this change. SemVer states that at this time, I should basically do whatever. Since this fixes a bug, I’m inclined to leave it in. If this introduces a significant problem for you, please let me know. Since others might now be relying on this new behavior, I’m not 100% sure what the best option is. Your feedback helps.

INSTALLING

To get 1.25.0 installed, just use gem install:

$ gem install resque

Or include it in your Gemfile:

gem 'resque', '~> 1.25.0'

SOURCE

You can find the source on GitHub.

Beware subclassing Ruby core classes

Wed, 24 Jul 2013 00:00:00 GMT

TL;DR: Subclassing core classes in Ruby can lead to unexpected side effects. I suggest composition over inheritance in all these cases.

Subclassing Review

If you’re familiar with the concept of subclassing, skip down to “The Problem.”

In Ruby, you can make your own classes:

class List
end

You can also make subclasses of those classes:

class OrderedList < List
end

puts OrderedList.new.kind_of?(List) # => true

Now, subclassing represents an “is a” relationship. This means that our OrderedList should be a List in every respect, but with some added behavior. The Liskov Substitution Principle is one formulation of this idea.

The Problem

Ruby has two major bits of code that it provides for your use: the core library and the standard library. The core library can be found here, and contains cllasses that you know and love, like String, Hash, and Array. The standard library can be found here, and contains your favorite hits, like CSV, JSON, and Logger.

One way to think about the difference between core and the standard library is that core is written in C, while the standard library is written in Ruby. Core are the classes that are used the most, so they’re implemented in as low-level a fashion as possible. They’ll be in every single Ruby program, so might as well make them fast! The standard library only gets pulled in by bits and pieces; another way of thinking about the difference is that you need to require everything in the standard library, but nothing in core.

What do you think this code should do?

class List < Array
end

puts List.new.to_a.class

If you said “it prints Array,” you’d be right. This behavior really confuses me, though, because List is already an Array; in my mind, this operation shouldn’t suddenly change the class.

Why does this happen? Let’s check out the implementation of Array#to_a:

static VALUE
rb_ary_to_a(VALUE ary)
{
    if (rb_obj_class(ary) != rb_cArray) {
        VALUE dup = rb_ary_new2(RARRAY_LEN(ary));
        rb_ary_replace(dup, ary);
        return dup;
    }
    return ary;
}

If the class is not an Array, (represented by rb_cArray), then we make a new array of the same length, call replace on it, and then return the new array. If this C scares you, here’s a direct port to pure Ruby:

def array_to_a(ary)
  if ary.class != Array
    dup = []
    dup.replace(ary)
    return dup
  end
  return ary
end

array_to_a(List.new).class # => Array

So why do this? Well, again, this class will be used all over the place. For example, I made a brand new Rails 4 application, generated a controller and view, and put this in it:

ObjectSpace.count_objects[:T_ARRAY]: <%= ObjectSpace.count_objects[:T_ARRAY] %>

ObjectSpace allows you to inspect all of the objects that exist in the system. Here’s the output:

rails arrays

That’s a lot of arrays! This kind of shortcut is generally worth it: 99.99% of the time, this code is perfect.

That last 0.01% is the problem. If you don’t know exactly how these classes operate at the C level, you’re gonna have a bad time. In this case, this behavior is odd enough that someone was kind enough to document it.

Here’s the Ruby version of what I’d expect to happen:

def array_to_a2(ary)
  return ary if ary.is_a?(Array)
  dup = []
  dup.replace(ary)
  dup
end

array_to_a2(List.new).class # => List

This has the exact same behavior except when we’re already dealing with an Array, which is what I’d expect.

Let’s take another example: reverse.

l = List.new
l << 1
l << 2
puts l.reverse.class # => Array

I would not expect that calling #reverse on my custom Array would change its class. Let’s look at the C again:

static VALUE
rb_ary_reverse_m(VALUE ary)
{
    long len = RARRAY_LEN(ary);
    VALUE dup = rb_ary_new2(len);

    if (len > 0) {
        const VALUE *p1 = RARRAY_RAWPTR(ary);
        VALUE *p2 = (VALUE *)RARRAY_RAWPTR(dup) + len - 1;
        do *p2-- = *p1++; while (--len > 0);
    }
    ARY_SET_LEN(dup, RARRAY_LEN(ary));
    return dup;
}

We get the length of the array, make a new blank array of the same length, then do some pointer stuff to copy everything over, and return the new copy. Unlike #to_a, this behavior is not currently documented.

Now: you could make the case that this behavior is expected, in both cases: after all, the point of the non-bang methods is to make a copy. However, there’s a difference to me between “make a new array with this stuff in it” and “make a new copy with this stuff in it”. Most of the time, I get the same class back, so I expect the same class back in these circumstances.

Let’s talk about a more pernicious issue: Strings.

As you know, the difference between interpolation and concatenation is that interpolation calls #to_s implicitly on the object it’s interpolating:

irb(main):001:0> "foo" + 2
TypeError: no implicit conversion of Fixnum into String
    from (irb):1:in `+'
    from (irb):1
    from /opt/rubies/ruby-2.0.0-p195/bin/irb:12:in `<main>'
irb(main):002:0> "foo#{2}"
=> "foo2"
irb(main):001:0> class MyClass
irb(main):002:1> def to_s
irb(main):003:2> "yup"
irb(main):004:2> end
irb(main):005:1> end
=> nil
irb(main):006:0> "foo#{MyClass.new}"
=> "fooyup"

So what about a custom String?

class MyString < String
  def to_s
    "lol"
  end
end

s = MyString.new
s.concat "Hey"

puts s
puts s.to_s
puts "#{s}"

What does this print?

$ ruby ~/tmp/tmp.rb HeylolHey

That’s right! With Strings, Ruby doesn’t call #to_s: it puts the value in directly. How does this happen?

Well, dealing with string interpolation deals with the parser, so let’s check out the bytecode that Ruby generates. Thanks to Aaron Patterson for suggesting this approach. <3

irb(main):013:0> x = RubyVM::InstructionSequence.new(%q{puts "hello #{'hey'}"})
=> <RubyVM::InstructionSequence:<compiled>@<compiled>>
irb(main):014:0> puts x.disasm
== disasm: <RubyVM::InstructionSequence:<compiled>@<compiled>>==========
0000 trace            1                                               (   1)
0002 putself
0003 putstring        "hello hey"
0005 opt_send_simple  <callinfo!mid:puts, argc:1, FCALL|ARGS_SKIP>
0007 leave
=> nil
irb(main):015:0> x = RubyVM::InstructionSequence.new(%q{puts "hello #{Object.new}"})
=> <RubyVM::InstructionSequence:<compiled>@<compiled>>
irb(main):016:0> puts x.disasm
== disasm: <RubyVM::InstructionSequence:<compiled>@<compiled>>==========
0000 trace            1                                               (   1)
0002 putself
0003 putobject        "hello "
0005 getinlinecache   12, <ic:0>
0008 getconstant      :Object
0010 setinlinecache   <ic:0>
0012 opt_send_simple  <callinfo!mid:new, argc:0, ARGS_SKIP>
0014 tostring
0015 concatstrings    2
0017 opt_send_simple  <callinfo!mid:puts, argc:1, FCALL|ARGS_SKIP>
0019 leave
=> nil

You can see with a string, the bytecode actually puts the final concatenated string. But with an object. it ends up calling tostring, and then concatstrings.

Again, 99% of the time, this is totally fine, and much faster. But if you don’t know this trivia, you’re going to get bit.

Here is an example from an older version of Rails. Yes, you might think “Hey idiot, there’s no way it will store your custom String class,” but the whole idea of subclassing is that it’s a drop-in replacement.

I know that there’s some case where Ruby will not call your own implementation of #initialize on a custom subclass of String, but I can’t find it right now. This is why this problem is so tricky: most of the time, things are fine, but then occasionally, something strange happens and you wonder what’s wrong. I don’t know about you, but my brain needs to focus on more important things than the details of the implementation.

Since I first wrote this post, James Edward Gray II helped me remember what this example is. One of the early exercises in http://exercism.io/ is based on making a DNA type, and then doing some substitution operations on it. Many people inherited from String when doing their answers, and while the simple case that passes the tests works, this case won’t:

class Dna < String
  def initialize(*)
    super
    puts "Building Dna:  #{inspect}"
  end
end

result = Dna.new("CATG").tr(Dna.new("T"), Dna.new("U"))
p result.class
p result

This prints:

Building Dna:  "CATG"
Building Dna:  "T"
Building Dna:  "U"
Dna
"CAUG"

It never called our initializer for the new string. Let’s check the source of #tr:

static VALUE
rb_str_tr(VALUE str, VALUE src, VALUE repl)
{
    str = rb_str_dup(str);
    tr_trans(str, src, repl, 0);
    return str;
}

rb_str_dup has a pretty simple definition:

VALUE
rb_str_dup(VALUE str)
{
    return str_duplicate(rb_obj_class(str), str);
}

and so does str_duplicate:

static VALUE
str_duplicate(VALUE klass, VALUE str)
{
    VALUE dup = str_alloc(klass);
    str_replace(dup, str);
    return dup;
}

So there you have it: MRI doesn’t go through the whole initialization process when duplicating a string: it just allocates the memory and then replaces the contents.

If you re-open String, it’s also weird:

class String
  alias_method :string_initialize, :initialize

  def initialize(*args, &block)
    string_initialize(*args, &block)
    puts "Building MyString:  #{inspect}"
  end
end

result = String.new("CATG").tr("T", "U") # => Building MyString: "CATG"
p result.class # => String
p result # => "CAUG"

Again, unless you know exactly how this works at a low level, surprising things happen.

The Solution

Generally speaking, subclassing isn’t the right idea here. You want a data structure that uses one of these core classes internally, but isn’t exactly like one. Rather than this:

class Name < String
end

do this:

require 'delegate'

class Name < SimpleDelegator
  def initialize
    super("")
  end
end

This allows you to do the same thing, but without all of the pain:

class Name
  def to_s
    "hey"
  end
end

"#{Name.new}" # => "hey"

However, this won’t solve all problems:

require 'delegate'

class List < SimpleDelegator
  def initialize
    super([])
  end
end

l = List.new
l << 1
l << 2
puts l.reverse.class # => Array

In general, I’d prefer to delegate things manually, anyway: a Name is not actually a drop-in for a String it’s something different that happens to be a lot like one:

class List
  def initialize(list = [])
    @list = list
  end

  def <<(item)
    @list << item
  end

  def reverse
    List.new(@list.reverse)
  end
end

l = List.new
l << 1
l << 2
puts l.reverse.class  # => List

You can clean this up by using Forwardable to only forward the messages you want to forward:

require 'forwardable'

class List
  extend Forwardable
  def_delegators :@list, :<<, :length # and anything else

  def initialize(list = [])
    @list = list
  end

  def reverse
    List.new(@list.reverse)
  end
end

l = List.new
l << 1
l << 2
puts l.reverse.class # => List

Now you know! Be careful out there!

Resque 1.25.0.pre has been released

Tue, 23 Jul 2013 00:00:00 GMT

I’ve just released Resque 1.25.0.pre! Resque is the most stable, widely-used job queue for Ruby. It uses Redis as its backing store.

This release is thanks to adelcambre, who took the time to get it over the finish line! <3

A total of 19 contributors helped out with this release, with 77 commits. Thank you to everyone!

CHANGES

You can see the full CHANGELOG here.

I am releasing this version as ‘pre’ due to one big change: a refactor to the forking code. This was introduced to fix a problem: the exit syscall raises a SystemExit Exception in ruby, its exit is treated as a failure, thus deregistering the worker. After the refactor + fix, things should be peachy. But please give the prerelease a try.

In addition, it has been discovered that we have accidentally introduced a SemVer violation back in v1.23.1: https://github.com/resque/resque/issues/1074

INSTALLING

To get 1.25.0.pre installed, just use gem install:

$ gem install resque --pre

SOURCE

You can find the source on GitHub.

Removing Turbolinks from Rails 4

Tue, 25 Jun 2013 00:00:00 GMT

If you don’t want to use Turbolinks with your Rails 4 application, it’s easy! Just do this:

Remove the gem 'turbolinks' line from your Gemfile.
Remove the //= require turbolinks from your app/assets/javascripts/application.js.
Remove the two "data-turbolinks-track" => true hash key/value pairs from your app/views/layouts/application.html.erb.

Done!

Rails 4.0.0-beta1 to Rails 4.0.0-rc1

Tue, 21 May 2013 00:00:00 GMT

I’m writing Rails 4 in Action along with Ryan Bigg and Yehuda Katz. In updating the book to Rails 4, I started early: the sample app (ticketee) was done with 4.0.0.beta1.

Then 4.0.0.rc1 came out. I didn’t upgrade immediately, but last night, I took the plunge. There were only three errors, and the whole process took me something like 40 minutes.

Here’s what I had to do:

Error:

/Users/steve/.gem/ruby/2.0.0/gems/railties-4.0.0.rc1/lib/rails/application/configuration.rb:144:in `const_get': uninitialized constant ActionDispatch::Session::EncryptedCookieStore (NameError)

The EncryptedCookieStore went away. Now, the regular cookie store handles these kinds of things.

Fix:

diff --git a/config/initializers/session_store.rb b/config/initializers/session_store.rbindex c512cda..b4681fd 100644--- a/config/initializers/session_store.rb+++ b/config/initializers/session_store.rb@@ -1,3 +1,3 @@ # Be sure to restart your server when you modify this file.-Ticketee::Application.config.session_store :encrypted_cookie_store, key: '_ticketee_session'+Ticketee::Application.config.session_store :cookie_store, key: '_ticketee_session'

Routes

Error:

/Users/steve/.gem/ruby/2.0.0/gems/actionpack-4.0.0.rc1/lib/action_dispatch/routing/route_set.rb:408:in `add_route': Invalid route name, already in use: 'signin'  (ArgumentError)
You may have defined two routes with the same name using the `:as` option, or you may be overriding a route already defined by a resource with the same naming. For the latter, you can restrict the routes created with `resources` as explained here:
http://guides.rubyonrails.org/routing.html#restricting-the-routes-created

You can’t name two routes the same thing any more. In my case, just dropping the :as allowed me to get to where I needed to go:

Fix:

diff --git a/config/routes.rb b/config/routes.rbindex f010adb..d573e89 100644--- a/config/routes.rb+++ b/config/routes.rb@@ -2,8 +2,8 @@ Ticketee::Application.routes.draw do   root to: "projects#index"-  get "/signin", to: "sessions#new", as: "signin"-  post "/signin", to: "sessions#create", as: "signin"+  get "/signin", to: "sessions#new"+  post "/signin", to: "sessions#create"   delete "/signout", to: "sessions#destroy", as: "signout"

Clean dbs

Error:

Tons of test failures relating to what was essentially “I don’t delete the db between test runs.”

Fix:

Upgrade to rspec-rails 2.13.2. Done!

has_secure_password

Error:

  1) User passwords needs a password and confirmation to save
     Failure/Error: expect(u).to_not be_valid
       expected #<User id: 1, name: "steve", email: "steve@example.com", password_digest: "$2a$04$9D7M2iPvYavvvpb3rlLzz.vqMJdGBAQVBSJ6L.UIoXP6...", created_at: "2013-05-21 23:59:44", updated_at: "2013-05-21 23:59:44", admin: false> not to be valid

This test failed. The test looked like this:

it "needs a password and confirmation to save" do  u = User.new(name: "steve", email: "steve@example.com")  u.save  expect(u).to_not be_valid  u.password = "password"  u.password_confirmation = ""  u.save  expect(u).to_not be_valid  u.password_confirmation = "password"  u.save  expect(u).to be_validend

Turns out, it’s a regression! This will get fixed for RC2, but for now, just commenting out that middle section works. The final test is good enough for now.

Travis build matrix for Rails

Sun, 10 Mar 2013 00:00:00 GMT

Do you have a gem that needs to test against multiple versions of Rails? Doing it all can be complex, and while I have lots to say about this topic, but here’s one of the pieces: Travis build matrix.

Here’s what you want:

language: ruby
rvm:
  - 1.8.7
  - 1.9.2
  - 1.9.3
  - 2.0.0
  - ruby-head
env:
  - "RAILS_VERSION=3.2"
  - "RAILS_VERSION=3.1"
  - "RAILS_VERSION=3.0"
  - "RAILS_VERSION=master"
matrix:
  allow_failures:
    - rvm: ruby-head
    - env: "RAILS_VERSION=master"
  exclude:
    - rvm: 2.0.0
      env: "RAILS_VERSION=3.0"
    - rvm: 2.0.0
      env: "RAILS_VERSION=3.1"
    - rvm: 1.8.7
      env: "RAILS_VERSION=master"
    - rvm: 1.9.2
      env: "RAILS_VERSION=master"
    - rvm: ruby-head
      env: "RAILS_VERSION=3.0"
    - rvm: ruby-head
      env: "RAILS_VERSION=3.1"

Here’s what all this does:

1.8.7 and 1.9.2 is supported across all of the 3.x series, but not master
2.0.0 is supported on Rails 3.2 (as of the upcoming 3.2.13, but it will probably work with your gem with 3.2.12) and master, but not 3.0 or 3.1.
We want to allow failures on ruby-head, because it’s not likely to be stable
We also want to allow failures for Rails master, because sometimes it’s not stable either
ruby-head should only be built against master

What do you think? Tweet at me if you have suggestions for improving this matrix.

Using puma on Heroku

Sun, 24 Feb 2013 00:00:00 GMT

I’m a big fan of Puma these days. Today, I converted my blog over to use Puma, and I figured I’d share how I did it. This blog uses Sinatra.

If you want to look ahead, here is the commit.

Gemfile

Installing Puma is really easy: just add gem 'puma' to your Gemfile. Done!

This section is way too easy. I’m sorry Puma isn’t more complicated. ;)

Procfile

Heroku attempts to guess how you want to run your site, but sometimes it guesses wrong. I prefer to be a bit more explicit, and in Puma’s case, it will guess wrong and use Webrick, so we need to do this step.

Heroku uses a gem called foreman to run your application. Basically, foreman gives you a ‘Procfile’ that lets you specify different processes and their types, and then foreman manages running them for you.

To use foreman, add it to your Gemfile:

gem 'foreman'

And then make a Procfile:

web: rackup -s puma -p $PORT

This says “I want my web processes to run this command.” Simple. We tell rackup to use Puma with the -s flag, for ‘server.’

To start up your application, normall you’d run rackup yourself, but now, you use foreman:

$ bundle exec foreman start

It’ll print out a bunch of messages. Mine looks like this:

$ bundle exec foreman start
15:05:05 web.1  | started with pid 52450
15:05:06 web.1  | Puma 1.6.3 starting...
15:05:06 web.1  | * Min threads: 0, max threads: 16
15:05:06 web.1  | * Environment: development
15:05:06 web.1  | * Listening on tcp://0.0.0.0:5000

Now you can open http://localhost:5000 in another terminal, and bam! Done.

Other Rubies

If you really want Puma to scream, you should run with Rubinius or JRuby. I haven’t done this yet, but once I do, I’ll update this post with instructions.

Rails

If you’re using Rails, it’s the same process, but the Procfile line should be

web: bundle exec puma -p $PORT

Easy!

I'm writing "Rails 4 in Action"!

Wed, 13 Feb 2013 00:00:00 GMT

Last night, I took a big step forward in my writing career: I’ll be building upon the work Ryan Bigg was doing to take “Rails 3 in Action” and move it to Rails 4. I signed the contract a few weeks ago, but last night I actually did the first bit of editing, and successfully got everything through the system.

Here’s the early access edition link, where you can check out what I’m doing. Of course, Rails 4 isn’t actually out yet, but since I’m on the Rails team, I already keep abreast of changes daily. I’ll be doing a first pass to take the book from 3.2 to edge over the next few weeks, and then keeping it current until the actual release of Rails 4.

Of course, updating the content is much easier than writing it in the first place. Thanks for all of your hard work on previous editions, Yehuda and Ryan!

Of course, this doesn’t mean I’ll stop working my my two self-published books, Designing Hypermedia APIs and Rust for Rubyists. It just means I’ll be doing even more writing!

Ruby on Rails maintenance policy

Mon, 11 Feb 2013 00:00:00 GMT

Recently, the Rails team has committed to a specific policy related to release maintenance. Due to the rapid pace of recent releases, it’s good to understand how your apps relate to this policy.

The policy was originally posted on Google Groups, here: https://groups.google.com/forum/?fromgroups=#!topic/rubyonrails-security/G4TTUDDYbNA.

Here’s a copy if you don’t want to read Google Groups:

Since the most recent patch releases there has been some confusion about what versions of Ruby on Rails are currently supported, and when people can expect new versions. Our maintenance policy is as follows.

Support of the Rails framework is divided into four groups: New features, bug fixes, security issues, and severe security issues. They are handled as follows:

New Features

New Features are only added to the master branch and will not be made available in point releases.

Bug fixes

Only the latest release series will receive bug fixes. When enough bugs are fixed and its deemed worthy to release a new gem, this is the branch it happens from.

Currently included series: 3.2.x

Security issues:

The current release series and the next most recent one will receive patches and new versions in case of a security issue.

Currently included series: 3.2.x, 3.1.x

Severe security issues:

For severe security issues we will provide new versions as above, and also the last major release series will receive patches and new versions. The classification of the security issue is judged by the core team.

Currently included series: 3.2.x, 3.1.x, 2.3.x

Unsupported Release Series

When a release series is no longer supported, it’s your own responsibility to deal with bugs and security issues. We may provide back-ports of the fixes and publish them to git, however there will be no new versions released. If you are not comfortable maintaining your own versions, you should upgrade to a supported version.

You should also be aware that Ruby 1.8 will reach End of Life in June 2013, no further ruby security releases will be provided after that point. If your application is only compatible ruby 1.8 you should upgrade accordingly.

– Cheers,

Koz

Ember.js and accessibility

Thu, 07 Feb 2013 00:00:00 GMT

Hey everyone! I made a video today about Ember.js and accessibility. I had always been repeating what I’d heard about screen readers: they can’t work with JavaScript. Turns out that’s not exactly true. The video is the best way to show you:

VoiceOver, Ember.js, and WAI-ARIA from Steve Klabnik on Vimeo.

Here’s a rough transcript, if you don’t want to watch it:

Hey everyone. I recently was checking out Ember.js, and more specifically, Discourse. Discourse is supposed to be a next-generation discussion platform, and it’s an Ember app backed by a Rails-based JSON API. I mentioned to Ember co-creator Yehuda Katz that I wished Ember had ‘a better accessibility story’. He asked me to elaborate, and I mentioned how my friends on Twitter were saying that Discourse wouldn’t able to be inclusive because JavaScript-heavy apps can’t be used by screenreaders. So he said, “Hit ⌘-F5.”

Whoah.

Hitting that key combination activates VoiceOver, a feature of OS X I didn’t know existed. Basically, VoiceOver is able to interact with applications and allow keyboard navigation for those who are blind or sight-impaired. Neat! But what about in-browser? Turns out VoiceOver handles JavaScript heavy pages just fine.

I tried it out on http://try.discourse.org/, and it works pretty well! Not perfect, but you can manage. Yehuda also pointed me at WAI-ARIA, which is a W3C initiative. I’ll let the site explain:

WAI-ARIA, the Accessible Rich Internet Applications Suite, defines a way to make Web content and Web applications more accessible to people with disabilities. It especially helps with dynamic content and advanced user interface controls developed with Ajax, HTML, JavaScript, and related technologies.

Neat! Basically, you can add markup to your HTML, and it will help applications like VoiceOver allow people to use your site more easily, even if it uses a lot of Ajax. This is super cool, and for me, mitigates one of my main complaints against using SPAs. Of course, WAI-ARIA isn’t really Ember’s job; you’ll have to make the HTML be output in the right way yourself. But it makes me really happy to know that people with disabilities don’t need to be left out of the rich-client portion of the web.

How to not rely on rubygems.org for development

Thu, 31 Jan 2013 00:00:00 GMT

Due to the recent situation with Rubygems.org, a lot of people noticed that they rely on Rubygems.org when deploying. A lot of people advocate “vendor everything”, and while that’s one approach, I actually don’t think it’s necessary. I think a lot of people think they rely on Rubygems.org more than they actually do, or, at least, aren’t deploying with Bundler correctly. So let’s talk about it.

Deploying with Bundler

Bundler has a --deployment flag to help you deploy code. Here’s the documentation. If you use Bundler, and you don’t use --deployment when deploying, you are probably Doing It Wrong. Let’s try a brand new app, and see what happens:

$ rails _3.2.11_ new foo --skip-bundle
      create  
      create  README.rdoc
      create  Rakefile
      create  config.ru
      create  .gitignore
      create  Gemfile
      create  app
      create  app/assets/images/rails.png
      create  app/assets/javascripts/application.js
      create  app/assets/stylesheets/application.css
      create  app/controllers/application_controller.rb
      create  app/helpers/application_helper.rb
      create  app/views/layouts/application.html.erb
      create  app/mailers/.gitkeep
      create  app/models/.gitkeep
      create  config
      create  config/routes.rb
      create  config/application.rb
      create  config/environment.rb
      create  config/environments
      create  config/environments/development.rb
      create  config/environments/production.rb
      create  config/environments/test.rb
      create  config/initializers
      create  config/initializers/backtrace_silencers.rb
      create  config/initializers/inflections.rb
      create  config/initializers/mime_types.rb
      create  config/initializers/secret_token.rb
      create  config/initializers/session_store.rb
      create  config/initializers/wrap_parameters.rb
      create  config/locales
      create  config/locales/en.yml
      create  config/boot.rb
      create  config/database.yml
      create  db
      create  db/seeds.rb
      create  doc
      create  doc/README_FOR_APP
      create  lib
      create  lib/tasks
      create  lib/tasks/.gitkeep
      create  lib/assets
      create  lib/assets/.gitkeep
      create  log
      create  log/.gitkeep
      create  public
      create  public/404.html
      create  public/422.html
      create  public/500.html
      create  public/favicon.ico
      create  public/index.html
      create  public/robots.txt
      create  script
      create  script/rails
      create  test/fixtures
      create  test/fixtures/.gitkeep
      create  test/functional
      create  test/functional/.gitkeep
      create  test/integration
      create  test/integration/.gitkeep
      create  test/unit
      create  test/unit/.gitkeep
      create  test/performance/browsing_test.rb
      create  test/test_helper.rb
      create  tmp/cache
      create  tmp/cache/assets
      create  vendor/assets/javascripts
      create  vendor/assets/javascripts/.gitkeep
      create  vendor/assets/stylesheets
      create  vendor/assets/stylesheets/.gitkeep
      create  vendor/plugins
      create  vendor/plugins/.gitkeep

steve at thoth in ~/tmp
$ cd foo

steve at thoth in ~/tmp/foo
$ cat .bundle/config 
cat: .bundle/config: No such file or directory

We have no configuration for bundler. Makes sense, we never bundled. If we try to use --deployment now, we get an error:

steve at thoth in ~/tmp/foo
[1] $ bundle install --deployment                                             ✘
The --deployment flag requires a Gemfile.lock. Please make sure you have checked your Gemfile.lock into version control before deploying.

This is because --deployment checks the lock. So let’s make one:

steve at thoth in ~/tmp/foo
[16] $ bundle                                                                 ✘
Fetching gem metadata from https://rubygems.org/...........
Fetching gem metadata from https://rubygems.org/..
Using rake (10.0.3) 
Using i18n (0.6.1) 
Using multi_json (1.5.0) 
Using activesupport (3.2.11) 
Using builder (3.0.4) 
Using activemodel (3.2.11) 
Using erubis (2.7.0) 
Using journey (1.0.4) 
Using rack (1.4.4) 
Using rack-cache (1.2) 
Using rack-test (0.6.2) 
Using hike (1.2.1) 
Using tilt (1.3.3) 
Using sprockets (2.2.2) 
Using actionpack (3.2.11) 
Using mime-types (1.19) 
Using polyglot (0.3.3) 
Using treetop (1.4.12) 
Using mail (2.4.4) 
Using actionmailer (3.2.11) 
Using arel (3.0.2) 
Using tzinfo (0.3.35) 
Using activerecord (3.2.11) 
Using activeresource (3.2.11) 
Using bundler (1.3.0.pre.5) 
Using coffee-script-source (1.4.0) 
Using execjs (1.4.0) 
Using coffee-script (2.2.0) 
Installing rack-ssl (1.3.3) 
Using json (1.7.6) 
Using rdoc (3.12) 
Using thor (0.17.0) 
Using railties (3.2.11) 
Using coffee-rails (3.2.2) 
Using jquery-rails (2.2.0) 
Using rails (3.2.11) 
Using sass (3.2.5) 
Using sass-rails (3.2.6) 
Using sqlite3 (1.3.7) 
Using uglifier (1.3.0) 
Your bundle is complete! Use `bundle show [gemname]` to see where a bundled gem is installed.

This of course does hit the network, and does all the usual things. Your application normally has a lock already and has it checked in. We still don’t have a config:

steve at thoth in ~/tmp/foo
$ cat .bundle/config
cat: .bundle/config: No such file or directory

So, this is the state our app would be in before deploying. At this point, it’s just like we did a git pull or an scp to our server. So let’s install for deployment:

steve at thoth in ~/tmp/foo
$ bundle install --deployment
Fetching gem metadata from https://rubygems.org/.........
Fetching gem metadata from https://rubygems.org/..
Installing rake (10.0.3) 
Installing i18n (0.6.1) 
Installing multi_json (1.5.0) 
Installing activesupport (3.2.11) 
Installing builder (3.0.4) 
Installing activemodel (3.2.11) 
Installing erubis (2.7.0) 
Installing journey (1.0.4) 
Installing rack (1.4.4) 
Installing rack-cache (1.2) 
Installing rack-test (0.6.2) 
Installing hike (1.2.1) 
Installing tilt (1.3.3) 
Installing sprockets (2.2.2) 
Installing actionpack (3.2.11) 
Installing mime-types (1.19) 
Installing polyglot (0.3.3) 
Installing treetop (1.4.12) 
Installing mail (2.4.4) 
Installing actionmailer (3.2.11) 
Installing arel (3.0.2) 
Installing tzinfo (0.3.35) 
Installing activerecord (3.2.11) 
Installing activeresource (3.2.11) 
Installing coffee-script-source (1.4.0) 
Installing execjs (1.4.0) 
Installing coffee-script (2.2.0) 
Installing rack-ssl (1.3.3) 
Installing json (1.7.6) 
Installing rdoc (3.12) 
Installing thor (0.17.0) 
Installing railties (3.2.11) 
Installing coffee-rails (3.2.2) 
Installing jquery-rails (2.2.0) 
Using bundler (1.3.0.pre.5) 
Installing rails (3.2.11) 
Installing sass (3.2.5) 
Installing sass-rails (3.2.6) 
Installing sqlite3 (1.3.7) 
Installing uglifier (1.3.0) 
Your bundle is complete! It was installed into ./vendor/bundle
Post-install message from rdoc:
Depending on your version of ruby, you may need to install ruby rdoc/ri data:

<= 1.8.6 : unsupported
 = 1.8.7 : gem install rdoc-data; rdoc-data --install
 = 1.9.1 : gem install rdoc-data; rdoc-data --install
>= 1.9.2 : nothing to do! Yay!

We still hit Rubygems.org, but note now that it said “Installing” rather than using. That’s because we now have everything vendored:

$ cat .bundle/config
---
BUNDLE_FROZEN: '1'
BUNDLE_PATH: vendor/bundle
BUNDLE_DISABLE_SHARED_GEMS: '1'

steve at thoth in ~/tmp/foo
$ ls vendor/bundle/ruby/1.9.1
bin            cache          doc            gems           specifications

steve at thoth in ~/tmp/foo
$ ls vendor/bundle/ruby/1.9.1/gems
actionmailer-3.2.11        multi_json-1.5.0
actionpack-3.2.11          polyglot-0.3.3
activemodel-3.2.11         rack-1.4.4
activerecord-3.2.11        rack-cache-1.2
activeresource-3.2.11      rack-ssl-1.3.3
activesupport-3.2.11       rack-test-0.6.2
arel-3.0.2                 rails-3.2.11
builder-3.0.4              railties-3.2.11
coffee-rails-3.2.2         rake-10.0.3
coffee-script-2.2.0        rdoc-3.12
coffee-script-source-1.4.0 sass-3.2.5
erubis-2.7.0               sass-rails-3.2.6
execjs-1.4.0               sprockets-2.2.2
hike-1.2.1                 sqlite3-1.3.7
i18n-0.6.1                 thor-0.17.0
journey-1.0.4              tilt-1.3.3
jquery-rails-2.2.0         treetop-1.4.12
json-1.7.6                 tzinfo-0.3.35
mail-2.4.4                 uglifier-1.3.0
mime-types-1.19

Okay! Neat. So we’ve Vendored Everything… what happens if we bundle again?

steve at thoth in ~/tmp/foo
$ bundle
Using rake (10.0.3) 
Using i18n (0.6.1) 
Using multi_json (1.5.0) 
Using activesupport (3.2.11) 
Using builder (3.0.4) 
Using activemodel (3.2.11) 
Using erubis (2.7.0) 
Using journey (1.0.4) 
Using rack (1.4.4) 
Using rack-cache (1.2) 
Using rack-test (0.6.2) 
Using hike (1.2.1) 
Using tilt (1.3.3) 
Using sprockets (2.2.2) 
Using actionpack (3.2.11) 
Using mime-types (1.19) 
Using polyglot (0.3.3) 
Using treetop (1.4.12) 
Using mail (2.4.4) 
Using actionmailer (3.2.11) 
Using arel (3.0.2) 
Using tzinfo (0.3.35) 
Using activerecord (3.2.11) 
Using activeresource (3.2.11) 
Using coffee-script-source (1.4.0) 
Using execjs (1.4.0) 
Using coffee-script (2.2.0) 
Using rack-ssl (1.3.3) 
Using json (1.7.6) 
Using rdoc (3.12) 
Using thor (0.17.0) 
Using railties (3.2.11) 
Using coffee-rails (3.2.2) 
Using jquery-rails (2.2.0) 
Using bundler (1.3.0.pre.5) 
Using rails (3.2.11) 
Using sass (3.2.5) 
Using sass-rails (3.2.6) 
Using sqlite3 (1.3.7) 
Using uglifier (1.3.0) 
Your bundle is complete! It was installed into ./vendor/bundle

The bundle command uses our config settings in .bundle/config, which re-runs with the vendored bundle.

Wait, I thought you said NO to Vendor Everything!!!

Well, here’s the deal: you can Vendor Everything on your server, which means that we’re not committing gems into source control, and then pushing that huge mess over the network.

Let’s re-examine --deployment in the context of our two strategies: scp and git.

git

If you deploy with git, it’s two ways: sshing into the server and running a git pull, or by doing a git push. In both cases, you’ll have some sort of post-deploy hook that manages the rest of the deploy.

This scenario is exactly as shown above: just make sure that your first bundle on deploy is using --deployment, and you’re Good To Go. Each next deploy won’t hit the network. Rock on.

scp

If you use scp in some way to deploy, then you’re getting a new copy of the application every time, so that bundle full of gems won’t work. You need one more flag: --path

steve at thoth in ~/tmp/foo
$ rm -rf vendor       

steve at thoth in ~/tmp/foo
$ bundle install --deployment --path ../vendor/bundle
Fetching gem metadata from https://rubygems.org/.........
Fetching gem metadata from https://rubygems.org/..
Installing rake (10.0.3) 
Installing i18n (0.6.1) 
Installing multi_json (1.5.0) 
Installing activesupport (3.2.11) 
Installing builder (3.0.4) 
Installing activemodel (3.2.11) 
Installing erubis (2.7.0) 
Installing journey (1.0.4) 
Installing rack (1.4.4) 
Installing rack-cache (1.2) 
Installing rack-test (0.6.2) 
Installing hike (1.2.1) 
Installing tilt (1.3.3) 
Installing sprockets (2.2.2) 
Installing actionpack (3.2.11) 
Installing mime-types (1.19) 
Installing polyglot (0.3.3) 
Installing treetop (1.4.12) 
Installing mail (2.4.4) 
Installing actionmailer (3.2.11) 
Installing arel (3.0.2) 
Installing tzinfo (0.3.35) 
Installing activerecord (3.2.11) 
Installing activeresource (3.2.11) 
Installing coffee-script-source (1.4.0) 
Installing execjs (1.4.0) 
Installing coffee-script (2.2.0) 
Installing rack-ssl (1.3.3) 
Installing json (1.7.6) 
Installing rdoc (3.12) 
Installing thor (0.17.0) 
Installing railties (3.2.11) 
Installing coffee-rails (3.2.2) 
Installing jquery-rails (2.2.0) 
Using bundler (1.3.0.pre.5) 
Installing rails (3.2.11) 
Installing sass (3.2.5) 
Installing sass-rails (3.2.6) 
Installing sqlite3 (1.3.7) 
Installing uglifier (1.3.0) 
Your bundle is complete! It was installed into /Users/steve/tmp/vendor/bundle
Post-install message from rdoc:
Depending on your version of ruby, you may need to install ruby rdoc/ri data:

<= 1.8.6 : unsupported
 = 1.8.7 : gem install rdoc-data; rdoc-data --install
 = 1.9.1 : gem install rdoc-data; rdoc-data --install
>= 1.9.2 : nothing to do! Yay!

steve at thoth in ~/tmp/foo
$ cat .bundle/config 
---
BUNDLE_FROZEN: '1'
BUNDLE_PATH: ../vendor/bundle
BUNDLE_DISABLE_SHARED_GEMS: '1'

steve at thoth in ~/tmp/foo
$ ls vendor
ls: vendor: No such file or directory

steve at thoth in ~/tmp/foo
[1] $ ls ../vendor                                                            ✘
bundle

steve at thoth in ~/tmp/foo
$ bundle
Using rake (10.0.3) 
Using i18n (0.6.1) 
Using multi_json (1.5.0) 
Using activesupport (3.2.11) 
Using builder (3.0.4) 
Using activemodel (3.2.11) 
Using erubis (2.7.0) 
Using journey (1.0.4) 
Using rack (1.4.4) 
Using rack-cache (1.2) 
Using rack-test (0.6.2) 
Using hike (1.2.1) 
Using tilt (1.3.3) 
Using sprockets (2.2.2) 
Using actionpack (3.2.11) 
Using mime-types (1.19) 
Using polyglot (0.3.3) 
Using treetop (1.4.12) 
Using mail (2.4.4) 
Using actionmailer (3.2.11) 
Using arel (3.0.2) 
Using tzinfo (0.3.35) 
Using activerecord (3.2.11) 
Using activeresource (3.2.11) 
Using coffee-script-source (1.4.0) 
Using execjs (1.4.0) 
Using coffee-script (2.2.0) 
Using rack-ssl (1.3.3) 
Using json (1.7.6) 
Using rdoc (3.12) 
Using thor (0.17.0) 
Using railties (3.2.11) 
Using coffee-rails (3.2.2) 
Using jquery-rails (2.2.0) 
Using bundler (1.3.0.pre.5) 
Using rails (3.2.11) 
Using sass (3.2.5) 
Using sass-rails (3.2.6) 
Using sqlite3 (1.3.7) 
Using uglifier (1.3.0) 
Your bundle is complete! It was installed into /Users/steve/tmp/vendor/bundle

The --path flag controls where the bundle is located. In this case, we store it one directory up. Now, when we copy new versions of the code over, it will use the bundle location that stays the same, and all is peachy keen.

I am told by several people that this is what the Capistrano/bundler recipe does by default, so if you’re using that, you’re already doing this.

One Tiny Weakness

There is one small weakness of this approach compared to Vendor Everything: as an engineer, it’s your tradeoff to make.

This way of using bundler will hit the network when you deploy for the first time after updating your bundle. The cache on the server has to update in this case, so it will go fetch the new gems. So here’s the scenario:

I update my bundle. It gets the new versions of the gems.
Rubygems.org goes down.
I need to deploy a branch that has the new versions in it.

In this case, if you had Vendored Everything, the hit to Rubygems.org would have happened during step 1, and so things would work. If you used this strategy, it would have hit locally, so you could have developed, but then when deploying, it’d hit again to update the bundle on the server, and so it wouldn’t.

In these situations, you can temporarily switch to Vendor Everything, since you have the bundle installed locally: just copy your local gems over to vendor/bundle and you’re done. This may or may not be too much of a hassle. When I examine the downtime of Rubygems.org, I think it’s worth it to not mess up my git repository with all that gem code. You might not. Do whatever you need to do, but now you know how to not rely on Rubygems.org for every deployment.

An addendum

I got an email mentioning one more issue with the ‘vendor everything’ strategy:

$ ls vendor/bundle/ruby/1.9.1/gems/nokogiri-1.5.6/ext/nokogiri/*.o
vendor/bundle/ruby/1.9.1/gems/nokogiri-1.5.6/ext/nokogiri/html_document.o
vendor/bundle/ruby/1.9.1/gems/nokogiri-1.5.6/ext/nokogiri/html_element_description.o
vendor/bundle/ruby/1.9.1/gems/nokogiri-1.5.6/ext/nokogiri/html_entity_lookup.o
vendor/bundle/ruby/1.9.1/gems/nokogiri-1.5.6/ext/nokogiri/html_sax_parser_context.o
vendor/bundle/ruby/1.9.1/gems/nokogiri-1.5.6/ext/nokogiri/html_sax_push_parser.o
vendor/bundle/ruby/1.9.1/gems/nokogiri-1.5.6/ext/nokogiri/nokogiri.o
vendor/bundle/ruby/1.9.1/gems/nokogiri-1.5.6/ext/nokogiri/xml_attr.o
vendor/bundle/ruby/1.9.1/gems/nokogiri-1.5.6/ext/nokogiri/xml_attribute_decl.o
vendor/bundle/ruby/1.9.1/gems/nokogiri-1.5.6/ext/nokogiri/xml_cdata.o
vendor/bundle/ruby/1.9.1/gems/nokogiri-1.5.6/ext/nokogiri/xml_comment.o
vendor/bundle/ruby/1.9.1/gems/nokogiri-1.5.6/ext/nokogiri/xml_document.o
vendor/bundle/ruby/1.9.1/gems/nokogiri-1.5.6/ext/nokogiri/xml_document_fragment.o
vendor/bundle/ruby/1.9.1/gems/nokogiri-1.5.6/ext/nokogiri/xml_dtd.o
vendor/bundle/ruby/1.9.1/gems/nokogiri-1.5.6/ext/nokogiri/xml_element_content.o
vendor/bundle/ruby/1.9.1/gems/nokogiri-1.5.6/ext/nokogiri/xml_element_decl.o
vendor/bundle/ruby/1.9.1/gems/nokogiri-1.5.6/ext/nokogiri/xml_encoding_handler.o
vendor/bundle/ruby/1.9.1/gems/nokogiri-1.5.6/ext/nokogiri/xml_entity_decl.o
vendor/bundle/ruby/1.9.1/gems/nokogiri-1.5.6/ext/nokogiri/xml_entity_reference.o
vendor/bundle/ruby/1.9.1/gems/nokogiri-1.5.6/ext/nokogiri/xml_io.o
vendor/bundle/ruby/1.9.1/gems/nokogiri-1.5.6/ext/nokogiri/xml_libxml2_hacks.o
vendor/bundle/ruby/1.9.1/gems/nokogiri-1.5.6/ext/nokogiri/xml_namespace.o
vendor/bundle/ruby/1.9.1/gems/nokogiri-1.5.6/ext/nokogiri/xml_node.o
vendor/bundle/ruby/1.9.1/gems/nokogiri-1.5.6/ext/nokogiri/xml_node_set.o
vendor/bundle/ruby/1.9.1/gems/nokogiri-1.5.6/ext/nokogiri/xml_processing_instruction.o
vendor/bundle/ruby/1.9.1/gems/nokogiri-1.5.6/ext/nokogiri/xml_reader.o
vendor/bundle/ruby/1.9.1/gems/nokogiri-1.5.6/ext/nokogiri/xml_relax_ng.o
vendor/bundle/ruby/1.9.1/gems/nokogiri-1.5.6/ext/nokogiri/xml_sax_parser.o
vendor/bundle/ruby/1.9.1/gems/nokogiri-1.5.6/ext/nokogiri/xml_sax_parser_context.o
vendor/bundle/ruby/1.9.1/gems/nokogiri-1.5.6/ext/nokogiri/xml_sax_push_parser.o
vendor/bundle/ruby/1.9.1/gems/nokogiri-1.5.6/ext/nokogiri/xml_schema.o
vendor/bundle/ruby/1.9.1/gems/nokogiri-1.5.6/ext/nokogiri/xml_syntax_error.o
vendor/bundle/ruby/1.9.1/gems/nokogiri-1.5.6/ext/nokogiri/xml_text.o
vendor/bundle/ruby/1.9.1/gems/nokogiri-1.5.6/ext/nokogiri/xml_xpath_context.o
vendor/bundle/ruby/1.9.1/gems/nokogiri-1.5.6/ext/nokogiri/xslt_stylesheet.o

Basically, your compiled files get vendored, so if you’re, say, developing on Mac and deploying on Linux, you might end up with compiled native extensions for the totally wrong architecture.

Draper 1.0.0 released

Mon, 14 Jan 2013 00:00:00 GMT

Today, I released Draper 1.0.0! Draper is a gem that gives you decorators/view models for Rails.

Rubygems: https://rubygems.org/gems/draper
GitHub: https://github.com/drapergem/draper
README: https://github.com/drapergem/draper/blob/master/README.md

You can get it with Rubygems:

$ gem install draper

or by adding this to your Gemfile:

gem "draper", "~>1.0.0"

Draper supports all versions of Rails 3, and follows SemVer, so you can be confident that your application will work well with Draper in the future. Thank you to everyone who tried out our six (six!!!11) beta releases and gave us patches and feedback.

Rails has two default stacks

Mon, 14 Jan 2013 00:00:00 GMT

Rails’ greatest strength is “Convention over Configuration.” Basically, Rails makes a ton of default choices for you about how things should be named, where they should go, and other things. This is why working with Rails is so productive for an experienced developer: just follow the Golden Path and everything comes together quickly. It’s second greatest strength is its ‘full stack’ nature: Rails includes everything that you need to get going. It does not attempt to be ‘minimal’ in any way. Put these two things together, and a Rails app makes lots of assumptions about everything in your app.

But what happens when a significant number of people don’t use those defaults?

First, let’s talk about the actual default stack. Since Rails is omakase, I’m going to call this the ‘Omakase Stack.’ Roughly, this stack contains:

ERB for view templates
MySQL for databases
MiniTest for testing
Fat Models, Skinny Controllers

There has been a ‘second default stack’ brewing for a while now. I’m going to call this the “Prime stack”. This stack’s approximate choices are:

Haml for view templates
PostgreSQL for databases
Rspec/Cucumber for testing
Skinny models, controllers, and a service layer

This is great! As David says:

That doesn’t mean patrons can’t express exceptions. Substitutions are allowed, within reason. So you don’t like test/unit? No problem, bring your own rspec. Don’t care for CoffeeScript as a dessert? Delete a single line from your Gemfile.

A considerable minority uses a stack like this. It’s important that the Prime Stack isn’t exact: you might not use Cucumber at all, for example, or maybe you don’t have a service layer. The important part, though, is that this is the new default you build preferences off of: a big group of people assumes that you don’t use MiniTest, you use Rspec, and the choice is Cukes or Capybara. This creates the ‘secondary default’ effect.

Dual Stack Ecology

So where’s the beef? Well, before I get into it, I want to make one thing explicit: I am not taking a position on which stack, if any, is ‘better.’ I’m not interested, at least in this post, at placing them into any kind of order. That’s for another time. What I want to talk about here is about the effect that a second default stack has on the overall Rails ecosystem.

Looking at history, the Prime Stack was born from the Omakase Stack. A certain group of people noticed that they were changing a significant amount of the stack most of the time, and so the Prime Stack came into existence. Since this is a historical progression, many blog posts got written describing the delta: take “Waiting for a Factory Girl”, for example.

Here at thoughtbot, we’ve had it with fixtures.

But wait! Then, years later, you get a discussion on how factories are bad. My own “Why I don’t like factory_girl” is an example:

So that’s what it really boils down to: the convenience of factories has set Rails testing strategies and software design back two years.

Maybe a bit strongly worded. Anyway, the people who have created the Prime Stack also happen to be those who are vocal, blog a lot, and speak at a lot of conferences. Everybody loves a polemic. If I submitted a talk to RailsConf called “Why Fixtures are :metal:” this year, people would assume that I was being sarcastic. People always assume that things are slowly getting better: If the original advice was “use fixtures” and the new advice is “use Factories” and the newest advice is “use neither”… there’s no way that the “right answer” is “use fixtures,” right? Isn’t that so 2007?

For those of us who’ve been around Rails for a long time, this discussion is good, and interesting. I was able to search for that Factory Girl post by memory, because I remember reading it when it was posted. I’ve written tons of Rails apps in the past 6ish years, and formed my own opinions on what tools I want to use due to that experience.

But what about someone starting Rails today?

Beginners lose out

Someone told me earlier today that “Starting Rails today is like starting to watch a soap opera in the 7th season.” Like most witty statements, there’s both truth and falsehood here. But, as a newcomer, how do you pick between the Omakase Stack and the Prime Stack?

This is the crux of the matter for me. If today, you tweeted that you were building a Rails app with fixtures, people would tell you to Stop It. I saw it happen this morning. This is again, because a very vocal minority of Rails developers use the Prime Stack, and are really passionate about their choice over the Omakase Stack. That’s great.

The problem is this: it puts a pretty heavy burden on a new developer: they have to learn the Omakase Stack and the delta. At the moment when someone is new, and barely knows anything, we throw them into making more choices. This is the moment when they’re least likely to be able to properly evaluate which option they need to choose. It’s not just “You’re new to Ruby, now learn Rails,” it’s now “You’re new to Ruby, now learn Rails, and RSpec, and Cucumber, and use this advanced modeling technique that we agree Rails discourages. Oh, and your only help is all these blog posts. Have fun!”

As I said at the beginning of this post, Convention over Configuration is Rails’ greatest strength. So when a new person starts, the first thing we do is tell them to do a bunch of configuration. Any reasonable developer could easily ask “If these options really are so superior, why do I have to include them? And which do I choose? I’m drowning!”

Helping People Build Better Apps

We all want to write better, more maintainable apps. And many people (including me) are trying to push the state of the art forward in this regard. But we’re leaving the majority in the dust. Rather than trying to push the boundaries by choosing new techniques, maybe we should be helping people get better at existing ones, too. Because we need both approaches. There’s already so much to learn when building a Rails application, adding more gems and techniques to the pile just isn’t going to help.

Once those beginners become intermediate, then they can figure out how new techniques solve the particular pains that they feel while going with the default flow. But skipping straight to the tool that solves my pain without feeling that pain the first place doesn’t help, it just confuses.

Let’s keep pushing those boundaries, but let’s not require someone to catch up on a few hundred episodes before they can understand what’s going on.

If you read this post previously, the “Omakase Stack” was called the “37signals stack,” but David has pointed out that even if he didn’t work with 37signals, he’d use this stack, so calling it that would be wrong. I’ve since changed the name.

Getting started with chruby

Thu, 13 Dec 2012 00:00:00 GMT

If you’re looking for crazy simplicity in your ‘switch between multiple Rubies’ life, you may want to check out chruby. Written by Postmodern, it’s basically the simplest possible thing that can work. As in, 76 lines of shell script.

For that, you get:

Features

Updates $PATH.
- Also adds RubyGems bin/ directories to $PATH.
Correctly sets $GEM_HOME and $GEM_PATH.
- Users: gems are installed into ~/.gem/$ruby/$version.
- Root: gems are installed directly into /path/to/$ruby/$gemdir.
Additionally sets $RUBY, $RUBY_ENGINE, $RUBY_VERSION and $GEM_ROOT.
Optionally sets $RUBYOPT if second argument is given.
Calls hash -r to clear the command-lookup hash-table.
Fuzzy matching of Rubies by name.
Defaults to the system Ruby.
Supports [bash] and [zsh].
Small (~80 LOC).
Has tests.

Anti-Features

Does not hook cd.
Does not install executable shims.
Does not require Rubies be installed into your home directory.
Does not automatically switch Rubies upon login or when changing directories.
Does not require write-access to the Ruby directory in order to install gems.

Kinda crazy, eh?

Installing

Most of the time, I install things from homebrew, but I actually prefered to run the setup.sh script:

wget https://github.com/downloads/postmodern/chruby/chruby-0.2.3.tar.gz
tar -xzvf chruby-0.2.3.tar.gz
cd chruby-0.2.3/
./scripts/setup.sh

You can see the source for that script here. You’ll end up with an MRI, JRuby, and Rubinius all installed in /opt/rubies, and after restarting your shell, you should be good to go!

Usage

To see what Rubies you’ve got, just chruby:

$ chruby
   ruby-1.9.3-p327
   jruby-1.7.0
   rubinius-2.0.0-rc1

to pick one:

$ chruby 1.9.3

Pretty damn simple.

Getting more Rubies?

The setup script will install ruby-build, so just use that to get more rubies:

ruby-build 1.9.3-p327 /opt/rubies/ruby-1.9.3-p327

You’ll then need to update your list of Rubies in your .bashrc or .zshrc:

RUBIES=(
  # other rubies here
  /opt/rubies/ruby-1.9.3-p327
)

If you find this tedius, you can just glob them:

RUBIES=(/opt/rubies/*)

Automatic switching?

Not yet. This is pretty much the only thing keeping me from saying ‘zomg use this for sure now.’

How good is it?

I don’t know, I’ve been using it for less than 24 hours. Seems good.

Draper 1.0.0.beta2 release

Mon, 03 Dec 2012 00:00:00 GMT

I’ve relased the second beta for Draper 1.0.0! Many thanks to all of you who gave the first beta a shot. We’ve fixed some issues, and I’d apprecaite you giving this one a try. This solves all known issues with Draper, including every one we’ve found in 1.0.0.beta1.

You can get it by installing it from Rubygems:

$ gem install draper --pre

or by putting it in your Gemfile:

gem "draper", "1.0.0.beta2"

CHANGELOG

These are the changes since beta1. To find out what’s new in beta1, please see my previous post.

has_finders is now decorates_finders. https://github.com/haines/draper/commit/33f18aa062e0d3848443dbd81047f20d5665579f
If a finder method is used, and the source class is not set and cannot be inferred, an UninferrableSourceError is raised. https://github.com/haines/draper/commit/8ef5bf2f02f7033e3cd4f1f5de7397b02c984fe3
Class methods are now properly delegated again. https://github.com/haines/draper/commit/731995a5feac4cd06cf9328d2892c0eca9992db6
We no longer respond_to? private methods on the source. https://github.com/haines/draper/commit/18ebac81533a6413aa20a3c26f23e91d0b12b031
Rails versioning relaxed to support Rails 4 https://github.com/drapergem/draper/commit/8bfd393b5baa7aa1488076a5e2cb88648efaa815

Draper 1.0.0.beta1 release

Fri, 30 Nov 2012 00:00:00 GMT

I’m happy to announce the release of Draper 1.0.0.beta1 today. If you use Draper, I’d appreciate you checking out the beta release in your app, kicking the tires, and letting me know what’s up.

You can get it by installing it from Rubygems:

$ gem install draper --pre

or by putting it in your Gemfile:

gem "draper", "1.0.0.beta1"

Notable changes include:

Renaming Draper::Base to Draper::Decorator. This is the most significant change you’ll need to upgrade your application. https://github.com/drapergem/draper/commit/025742cb3b295d259cf0ecf3669c24817d6f2df1
Added an internal Rails application for integration tests. This won’t affect your application, but we’re now running a set of Cucumber tests inside of a Rails app in both development and production mode to help ensure that we don’t make changes that break Draper. https://github.com/drapergem/draper/commit/90a4859085cab158658d23d77cd3108b6037e36f
Add #decorated? method. This gives us a free RSpec matcher, is_decorated?. https://github.com/drapergem/draper/commit/834a6fd1f24b5646c333a04a99fe9846a58965d6
#decorates is no longer needed inside your models, and should be removed. Decorators automatically infer the class they decorate. https://github.com/drapergem/draper/commit/e1214d97b62f2cab45227cc650029734160dcdfe
Decorators do not automatically come with ‘finders’ by default. If you’d like to use SomeDecorator.find(1), for example, simply add #has_finders to the decorator to include them. https://github.com/drapergem/draper/commit/42b6f78fda4f51845dab4d35da68880f1989d178
To refer to the object being decorated, #source is now the preferred method. https://github.com/drapergem/draper/commit/1e84fcb4a0eab0d12f5feda6886ce1caa239cb16
ActiveModel::Serialization is included in Decorators if you’ve requred ActiveModel::Serializers, so that decorators can be serialized. https://github.com/drapergem/draper/commit/c4b352799067506849abcbf14963ea36abda301c
Properly support Test::Unit https://github.com/drapergem/draper/commit/087e134ed0885ec11325ffabe8ab2bebef77a33a

And many small bug fixes and refactorings.

Before the actual release of 1.0.0, I want to improve documentation and handle a few other things, but we currently have no confirmed and one possible bug in Draper as it stands, so your feedback as I clean up these last few things would be excellent. Please file issues on the tracker if you find anything.

Thank you! <3 <3 <3

Introducing the rails-api project

Thu, 22 Nov 2012 00:00:00 GMT

Ruby on Rails is a great tool to build websites incredibly quickly and easily. But what about applications that aren’t websites? Rails is still a first-class choice for this use-case, but why settle for good when you could be the best?

That’s why I’m happy to introduce Rails API: a set of tools to build excellent APIs for both heavy Javascript applications as well as non-Web API clients.

What

Rails’ greatest feature is making trivial choices for you. By following conventions, you’re able to avoid bikeshedding and only focus on the actual decisions that matter for your application, while automatically building in best-practices. Rails API will do this for the API use-case.

Here are some initial thoughts on what Rails API will do for you:

A simpler stack

First, we can remove many parts of Rails that aren’t important in an API context: many middleware don’t make sense, and all of ActionView can go away.

To check out exactly what we mean, look at this part of the README, which explains which middlewares we include. The default stack has 22, we have 14.

Similarly, the structure of ActionController::Base is interesting: it includes a ton of modules that implement various features. This means that we can build an alternate ‘controller stack’ that doesn’t include all of the ones that are in Base. Check out this portion of the README for a demonstration of the modules we do include. Base includes 29 modules, we include 11.

Consistent Javascript output

One of the biggest issues when building a distributed system is messages that are sent between components. In most Rails-based APIs, this means the JSON that your server side emits, and the JSON that your client consumes. By forming best practices around what JSON is sent around, we can simplify things for server-side and client-side developers.

The generation of this JSON should be as transparent and simple as possible on both sides. ActiveModel::Serializers is key here. Many new APIs are settling on HAL as a JSON variant that is important to them, and so we’ll be considering it heavily.

Authentication

APIs don’t need to handle cookie-based auth, and so a lot of that infrastructure isn’t important. Handling other kinds of auth in a simple way is incredibly important.

JavaScript as a first-class citizen

JavaScript is just as important as Ruby for these kinds of applications, and should be equally as important with respect to tooling, directory layout, and documentation.

This also means that it should be easy to use the various Javascript frameworks and testing tools. We have representatives from the Ember team on-board, but using other frameworks should be equally fantastic.

Hypermedia

Many people are interested in building Hypermedia APIs on top of Rails, and so building best-practices around this style should be taken care of, and building them should be easy.

Where

You can find the organization on GitHub at https://github.com/rails-api

Originally, these two repositories were located at https://github.com/spastorino/rails-api and https://github.com/josevalim/active_model_serializers.

We have a Google Group for discussion here: https://groups.google.com/forum/?fromgroups#!forum/rails-api-core

Getting Started

To get started, check out the README here: https://github.com/rails-api/rails-api#railsapi.

Who

Currently,

Carlos Antonio
Rafael França
Santiago Pastorino
Steve Klabnik
Yehuda Katz
Tom Dale
José Valim

Run Rails with custom patches

Thu, 04 Oct 2012 00:00:00 GMT

I often see comments like this in the Rails bugtracker. Generally, someone is running an older version of Rails, and some bug they face has been fixed on edge. But they may be running a version that’s too old to receive fixes, or need a fix that has yet to be included in an actual release. What to do?

Luckily, Bundler exists. It makes it super easy to run your own Rails. Check it out:

Step 1: Fork you!

Go to GitHub, hit up rails/rails, and click that fork button. My own personal fork of Rails is here, for example, so in the rest of these examples, I’ll be using my own username. If you’re me, you can use it too, but seriously, stop being me. If you’re not me, substitute your own username.

Step 2: apply patch

Let’s get our copy going locally:

$ git clone git@github.com:steveklabnik/rails.git
$ cd rails

We’ll apply the patch from the example comment above. In this case, the person wants to have this patch work on Rails 3.1.

You have two options here: Rails keeps a branch open for every minor version, and also tags every release. You can pick between the stable branch and a particular release. The stable branch should work just fine, but maybe you’re on a specific Rails release for a reason. For example, the latest version of Rails 3.1 is 3.1.8, but this person says they’re on 3.1.1. If they use the 3-1-stable branch, they’ll also get all the changes from 3.1.1-3.1.8, as well as unreleased changes that may exist on that branch. That’s possibly too much for you, so we’ll just work off of 3.1.1. This is probably a bad idea, since 3.1.6 included several security fixes, but you’re an adult, do dumb things if you want to.

$ git checkout v3.1.1

You’ll see a big message about a detached HEAD. Don’t worry about it.

If you want the stable branch for extra fixes,

$ git checkout 3-1-stable

Now, it’s a good idea to make our own branches, so that we don’t get confused with upstream. So let’s make a new branch:

$ git checkout -b my_patched_rails

Awesome. Now, we can grab the commit we wanted. We can do this with cherry-pick:

$ git cherry-pick 8fc8763fde2cc685ed63fcf640cfae556252809b

I found this SHA1 by checking out this page, which is linked at the top of the pull request.

If there are multiple commits you need, you can do one of two things: either cherry-pick the merge commit, in which case you’ll probably need to pass the -m1 option, or simply cherry-pick them all in order.

You may get conflicts. Yay backporting! If git whines at you, do what you normally do. Resolve the merge, then git commit.

Finally, push it back up to your GitHub:

$ git push origin my_patched_rails

Congrats! You’ve got your own custom Rails. Now it’s time to use it.

Step 3: update Gemfile

Go to your Rails app, and edit this line in your Gemfile:

gem 'rails', "3.1.1"

change it to this:

gem 'rails', :git => "https://github.com/steveklabnik/rails", :branch => "my_patched_rails"

It’s that easy! Now bundle:

$ bundle update

You should see it mention something about checking out a certain copy of Rails.

Step 4: Profit!

That’s it! Congrats, you’re using Rails with your patch.

But I’m on 2.3, I’m not running Bundler!

Do this.

Resque: let's do this

Sat, 22 Sep 2012 00:00:00 GMT

If you’ve ever done background job stuff with Rails, you’ve probably used Resque. Resque is “Yet Another GitHub Project They’ve Open Sourced and Then Abandoned.” But Resque is super awesome: it builds a job queue on top of Redis, which is a totally awesome piece of software.

Anyway, Resque has been psuedo-abandonware for a while now. In January, Terence Lee from Heroku got in charge of the project, but it’s a big job. Too big of a job to properly manage alone. It’s hard to sift through 60 pulls and 120 open issues, some of which have been open for a few years. And manage the 1.x line while working on new stuff for 2.0. And debug issues that basically boil down to “When I upgrade Resque and this random gem, everything breaks, but when I downgrade that other gem, it works again. But Resque throws the error.”

Even outside of heroics, the bus factor on a project that’s as important as Resque should be higher than one.

So Terrence gave a presentation at Frozen Rails, and in it, he outlined what needs to be done for Resque 2.0, and asked for some help getting it out the door. So myself and a few other people are gonna pitch in and help out, and we’d love to have you.

Here’s the deal: I will personally be looking at (and already have read) every single open issue on GitHub. Feel ignored about something involving Resque? You can come to me. I can’t guarantee that I can get it fixed, but at least I’ll help you figure out wtf is going on, and get us a bug report that we can use to build a fix.

Think of it as decoupling the front end from the back end: Terrence can focus on writing new code, and I can focus on paying attention to your problems, helping you solve them, and getting fixes applied to the 1.x branch.

If you’re interested in helping out, we’d love to have you. Helping triage issues would be awesome, fixing bugs would be awesome, writing code would be awesome, updating docs would be awesome.

Let’s do this.

Random Ruby Tricks: Class.new

Sun, 09 Sep 2012 00:00:00 GMT

If you didn’t know, classes are first-class objects in Ruby:

1.9.3p194 :001 > String.class
 => Class 
1.9.3p194 :002 > Class.class
 => Class

How is this useful, though?

Inheritance

You may create very simple classes at times. This often happens when subclassing an error of some sort:

class MyException < StandardError
end

raise MyException

That whole thing is awkward to me, though. Why bother with the end if you don’t need it? Turns out, it’s easy to make your own Class object: just use Class.new:

1.9.3p194 :001 > Class.new
 => #<Class:0x007fee209f42f8>

But that doesn’t help us a ton. Turns out Class.new takes an argument: the class this new class inherits from:

1.9.3p194 :002 > Class.new(StandardError)
 => #<Class:0x007fee209ee2e0>

We can then save this in our own constant:

1.9.3p194 :003 > MyException = Class.new(StandardError)
 => MyException 
1.9.3p194 :004 > MyException.new
 => #<MyException: MyException> 
1.9.3p194 :005 > MyException.ancestors
 => [MyException, StandardError, Exception, Object, Kernel, BasicObject]

I think I like this notation a bit better than class...end. But many people may not be familiar with it.

Passing a block

Of course, you can pass a block to Class.new and it’ll work like you’d expect:

1.9.3p194 :001 > Foo = Class.new do
1.9.3p194 :002 >     def bar
1.9.3p194 :003?>     puts "bar"
1.9.3p194 :004?>     end
1.9.3p194 :005?>   end
 => Foo 
1.9.3p194 :006 > Foo.new.bar
bar
 => nil

The block gets class_eval’d. I haven’t found a good use for this one, exactly, but it’s good to know about!

EDIT: @pete_higgins has chimed in on Twitter. I knew I’d done this before!

`new` vs `initialize`

Ever wonder why you call Foo.new but define Foo.initialize? It’s pretty simple. Here:

VALUE rb_class_new_instance(int argc, VALUE *argv, VALUE klass)
{
    VALUE obj;

    obj = rb_obj_alloc(klass);
    rb_obj_call_init(obj, argc, argv);

    return obj;
}

Obviously! This is the source for Foo.new. You might not read C, but it’s pretty simple: it first allocates the space for the object using rb_obj_alloc, and then calls initialize using rb_obj_call_init.

Random Ruby Tricks: Struct.new

Sat, 01 Sep 2012 00:00:00 GMT

One of my favorite classes in Ruby is Struct, but I feel like many Rubyists don’t know when to take advantage of it. The standard library has a lot of junk in it, but Struct and OStruct are super awesome.

Struct

If you haven’t used Struct before, here’s the documentation of Struct from the Ruby standard library.

Structs are used to create super simple classes with some instance variables and a simple constructor. Check it:

Struct.new("Point", :x, :y) #=> Struct::Point
origin = Struct::Point.new(0,0) #=> #<struct Struct::Point x=0, y=0>

Nobody uses it this way, though. Here’s the way I first saw it used:

class Point < Struct.new(:x, :y)
end

origin = Point.new(0,0)

Wait, what? Inherit…from an instance of something? Yep!

1.9.3p194 :001 > Struct.new(:x,:y)
 => #<Class:0x007f8fc38da2e8>

Struct.new gives us a Class. We can inherit from this just like any other Class. Neat!

However, if you’re gonna make an empty class like this, I prefer this way:

Point = Struct.new(:x, :y)
origin = Point(0,0)

Yep. Classes are just constants, so we assign a constant to that particular Class.

OStruct

OStructs are like Struct on steroids. Check it:

require 'ostruct'

origin = OpenStruct.new
origin.x = 0
origin.y = 0

origin = OpenStruct.new(:x => 0, :y => 0)

OStructs are particularly good for configuration objects. Since any method works to set data in an OStruct, you don’t have to worry about enumerating every single option that you need:

require 'ostruct'

def set_options
  opts = OpenStruct.new
  yield opts
  opts
end

options = set_options do |o|
  o.set_foo = true
  o.load_path = "whatever:something"
end

options #=> #<OpenStruct set_foo=true, load_path="whatever:something">

Neat, eh?

Structs for domain concepts

You can use Structs to help reify domain concepts into simple little classes. For example, say we have this code, which uses a date:

class Person
  attr_accessor :name, :day, :month, :year

  def initialize(opts = {})
    @name = opts[:name]
    @day = opts[:day]
    @month = opts[:month]
    @year = opts[:year]
  end

  def birthday
    "#@day/#@month/#@year"
  end
end

and we have this spec

$:.unshift("lib")
require 'person'

describe Person do
  it "compares birthdays" do
    joe = Person.new(:name => "Joe", :day => 5, :month => 6, :year => 1986)
    jon = Person.new(:name => "Jon", :day => 7, :month => 6, :year => 1986)

    joe.birthday.should == jon.birthday
  end
end

It fails, of course. Like this:

$ rspec
F

Failures:

  1) Person compares birthdays
     Failure/Error: joe.birthday.should == jon.birthday
       expected: "7/6/1986"
            got: "5/6/1986" (using ==)
     # ./spec/person_spec.rb:9:in `block (2 levels) in <top (required)>'

Finished in 0.00053 seconds
1 example, 1 failure

Failed examples:

rspec ./spec/person_spec.rb:5 # Person compares birthdays

Now. We have these two birthdays. In this case, we know about why the test was failing, but imagine this failure in a real codebase. Are these month/day/year or day/month/year? You can’t tell, it could be either. If we switched our code to this:

class Person
  attr_accessor :name, :birthday

  Birthday = Struct.new(:day, :month, :year)

  def initialize(opts = {})
    @name = opts[:name]
    @birthday = Birthday.new(opts[:day], opts[:month], opts[:year])
  end
end

We get this failure instead:

$ rspec
F

Failures:

  1) Person compares birthdays
     Failure/Error: joe.birthday.should == jon.birthday
       expected: #<struct Person::Birthday day=7, month=6, year=1986>
            got: #<struct Person::Birthday day=5, month=6, year=1986> (using ==)
       Diff:
       @@ -1,2 +1,2 @@
       -#<struct Person::Birthday day=7, month=6, year=1986>
       +#<struct Person::Birthday day=5, month=6, year=1986>
     # ./spec/person_spec.rb:9:in `block (2 levels) in <top (required)>'

Finished in 0.00092 seconds
1 example, 1 failure

Failed examples:

rspec ./spec/person_spec.rb:5 # Person compares birthdays

We have a way, way more clear failure. We can clearly see that its our days that are off.

Of course, there are other good reasons to package related instance variables into Structs, too: it makes more conceptual sense. This code represents our intent better: a Person has a Birthday, they don’t have three unrelated numbers stored inside them somehow. If we need to add something to our concept of birthdays, we now have a place to put it.

Why I don't like factory_girl

Sat, 14 Jul 2012 00:00:00 GMT

Once upon a time, I was building my First Serious Rails App. I was drawn to Rails in the first place because of automated testing and ActiveRecord; I felt the pain of not using an ORM and spending about a week on every deploy making sure that things were still okay in production. So of course, I tried to write a pretty reasonable suite of tests for the app.

To gloss over some details to protect the innocent, this app was a marketplace: some people owned Things, and some people wanted to place Orders. Only certain Things could fulfill an Order, so of course, there was also a ThingType table that handled different types of Things. Of course, some Types came in multiple Sizes, so there also needed to be a Size Table and a ThingTypeSize table so that a User could own a Thing of a certain Type and a certain Size.

Stating that creating my objects for tests was difficult would be an understatement.

Then I read a blog post about FactoryGirl. Holy crap! This would basically save me. With one simple Factory(:thing) I could get it to automatically build a valid list of all that other crap that I needed!

So of course, I had to write my spec for a thing:

describe Order do
  it "generates quotes only from Things that are of the right size" do
    order = Factory(:order)
    thing = Factory(:thing, :size => order.size)
    thing = Factory(:thing)
    order.quote!
    order.quote.thing.should == thing
  end
end

This test worked. It also generated around 15 objects, saved them in the database, and queried them back out. I don’t have the code running anymore, but it was like 30-40 queries, and took a second or two to run.

That was one test. I was trying to test a lot, even though I wasn’t good at test first yet, so my suite got to be pretty big. Also, sometimes my factories weren’t the best, so I’d spend a day wondering why certain things would start failing. Turns out I’d defined them slightly wrong, validations started to fail, etc.

How did we get here?

This story is one of Ruby groupthink gone awry, basically. Of course, we know that fixtures get complicated. They get complicated because we have these crazy ActiveRecord models, don’t use plain Ruby classes when appropriate, and validations make us make extra objects just to get tests to pass. Then fixtures get out of date. So let’s introduce a pattern!

Of course, since we know that Factories are really useful when things get complicated, let’s make sure to use them from the start, so we don’t have to worry about them later. Everyone started doing this. Here’s how new Rails apps get started:

steve at thoth in ~/tmp
$ rails new my_app
      create  
      create  README.rdoc
<snip>
      create  vendor/plugins/.gitkeep
         run  bundle install
Fetching gem metadata from https://rubygems.org/.........
<snip>
Using uglifier (1.2.6) 
Your bundle is complete! Use `bundle show [gemname]` to see where a bundled gem is installed.

steve at thoth in ~/tmp
$ cd my_app 

steve at thoth in ~/tmp/my_app
$ cat >> Gemfile
gem "rspec-rails"
gem "factory_girl_rails"
^D

steve at thoth in ~/tmp/my_app
$ bundle
Fetching gem metadata from https://rubygems.org/........
<snip>
steve at thoth in ~/tmp/my_app
steve at thoth in ~/tmp/my_app
$ rails g rspec:install                                                   
      create  .rspec
       exist  spec
      create  spec/spec_helper.rb

$ rails g resource foo
      invoke  active_record
      create    db/migrate/20120714180554_create_foos.rb
      create    app/models/foo.rb
      invoke    rspec
      create      spec/models/foo_spec.rb
      invoke      factory_girl
      create        spec/factories/foos.rb
      invoke  controller
      create    app/controllers/foos_controller.rb
      invoke    erb
      create      app/views/foos
      invoke    rspec
      create      spec/controllers/foos_controller_spec.rb
      invoke    helper
      create      app/helpers/foos_helper.rb
      invoke      rspec
      create        spec/helpers/foos_helper_spec.rb
      invoke    assets
      invoke      coffee
      create        app/assets/javascripts/foos.js.coffee
      invoke      scss
      create        app/assets/stylesheets/foos.css.scss
      invoke  resource_route
       route    resources :foos

steve at thoth in ~/tmp/my_app
$ rake db:migrate                                                         
==  CreateFoos: migrating =====================================================
-- create_table(:foos)
   -> 0.0065s
==  CreateFoos: migrated (0.0066s) ============================================

$ cat > spec/models/foo_spec.rb
require 'spec_helper'

describe Foo do
  it "does something" do
    foo = Factory(:foo)
    foo.something!
  end
end
^D

$ bundle exec rake spec       
/Users/steve/.rvm/rubies/ruby-1.9.3-p194/bin/ruby -S rspec ./spec/controllers/foos_controller_spec.rb ./spec/helpers/foos_helper_spec.rb ./spec/models/foo_spec.rb
*DEPRECATION WARNING: Factory(:name) is deprecated; use FactoryGirl.create(:name) instead. (called from block (2 levels) in <top (required)> at /Users/steve/tmp/my_app/spec/models/foo_spec.rb:5)
F

Pending:
  FoosHelper add some examples to (or delete) /Users/steve/tmp/my_app/spec/helpers/foos_helper_spec.rb
    # No reason given
    # ./spec/helpers/foos_helper_spec.rb:14

Failures:

  1) Foo does something
     Failure/Error: foo.something!
     NoMethodError:
       undefined method `something!' for #<Foo:0x007f82c70c07a0>
     # ./spec/models/foo_spec.rb:6:in `block (2 levels) in <top (required)>'

Finished in 0.01879 seconds
2 examples, 1 failure, 1 pending

Failed examples:

rspec ./spec/models/foo_spec.rb:4 # Foo does something

Randomized with seed 27300

rake aborted!
/Users/steve/.rvm/rubies/ruby-1.9.3-p194/bin/ruby -S rspec ./spec/controllers/foos_controller_spec.rb ./spec/helpers/foos_helper_spec.rb ./spec/models/foo_spec.rb failed

Tasks: TOP => spec
(See full trace by running task with --trace)

Woo! Failing test! Super easy. But what about that test time?

Finished in 0.01879 seconds

Now, test time isn’t everything, but a hundredth of a second. Once we hit a hundred tests, we’ll be taking almost two full seconds to run our tests.

What if we just Foo.new.something!?

Finished in 0.00862 seconds

A whole hundredth of a second faster. A hundred tests now take one second rather than two.

Of course, once you add more complicated stuff to your factories, your test time goes up. Add a validation that requires an associated model? Now that test runs twice as slow. You didn’t change the test at all! But it got more expensive.

Now, a few years in, we have these massive, gross, huge, long-running test suites.

What to do?

Now, I don’t think that test times are the end-all-be-all of everything. I really enjoyed this post that floated through the web the other day. I think that the ‘fast tests movement’ or whatever (which I am/was a part of) was a branding mistake. The real point wasn’t about fast tests. Fast tests are really nice! But that’s not a strong enough argument alone.

The point is that we forgot what testing is supposed to help in the first place.

Back to basics: TDD

A big feature of tests is to give you feedback on your code. Tests and code have a symbiotic relationship. Your tests inform your code. If a test is complicated, your code is complicated. Ultimately, because tests are a client of your code, you can see how easy or hard your code’s interfaces are.

So, we have a pain in our interface: our objects need several other ones to exist properly. How do we fix that pain?

The answer that the Rails community has taken for the last few years is ‘sweep it under the rug with factories!’ And that’s why we’re in the state we’re in. One of the reasons that this happened was that FactoryGirl is a pretty damn good implementation of Factories. I do use FactoryGirl (or sometimes Fabrication) in my request specs; once you’re spinning up the whole stack, factories can be really useful. But they’re not useful for actual unit tests. Which I guess is another way to state what I’m saying: we have abandoned unit tests, and now we’re paying the price.

So that’s what it really boils down to: the convenience of factories has set Rails testing strategies and software design back two years.

You live and learn.

How can I contribute to Ruby on Rails?

Thu, 05 Jul 2012 00:00:00 GMT

After RailsConf this year, I joined the Rails Issue Team. This means that I help triage issues that people have filed, try to reproduce errors, and point core team members at ones that are most important. Since doing that, a few people have asked me how to get started, so I decided to draw up my thoughts here.

Note that there is also an official Rails Guide on contribution too.

Who helps with Rails?

First up is the Rails Core team: http://rubyonrails.org/core/ Core team members essentially have the authority to merge code into the main Rails codebase. Someone from core reviews every patch that goes into Rails.

Issues team: This group of people has the authority to tag, close, and edit tickets, but can’t actually merge code.

Documentation team: A few awesome people contribute by writing documentation rather than just code. Docs are super important, so all these people are also awesome.

Everyone else!: Rails is open source after all, and 1224 people have contributed at least one patch.

You can find everyone’s commits and count here: http://contributors.rubyonrails.org/

About payment

Nobody is paid to just work on Rails itself. Everyone is a volunteer. Rails runs on a ‘scratch your own itch’ policy. This has two big effects:

Pull requests can sit sometimes. Pull requests must be merged by a Core member, so after your patch is submitted, you’re basically waiting on someone from a group of about 12 to decide ‘hey, I should merge some pull requests today’ and get on it. There are currently 168 pull requests open on Rails, the oldest of which is three months since its last comment.
Feature requests may simply fall on deaf ears. If you have a suggestion for Rails, and you don’t want to implement it, you need to convince someone to write the code for you. But it’s not as if the core team has a list of requested features that it goes over when working. Of course, they have a list of the features that they want to add, but it’s not like it’s comprehensive from every feature requested. That said, it’s possible that your idea may spark the attention of someone, so sharing a feature request is valuable. But don’t feel entitled here.

I found a bug, what should I do?

File a ticket on the Rails issue tracker and give us as much information as possible.

Note that only 3.2 is getting bug fixes. 3.1 and earlier are security fix only.

Good: Clear bug report, listed versions of Rails and/or Ruby and backtrace if applicable

Better: Steps to reproduce, maybe with a sample app.

Best: All of the above with a patch that fixes the problem.

I’ve found a security vulnerability, what should I do?

Don’t submit something to the tracker. Instead, check out this page which outlines the security policy. Basically, send an email to security@rubyonrails.org.

I have a feature request, what should I do?

Please don’t file an Issue; it’s a bad medium for discussing these kinds of things. It also makes it harder to keep track of what’s a bug and what’s a wish for future changes. Please post to the rails-core mailing list instead. Your idea is much more likely to be seen and discussed there.

You may get no response from the list. People tend to say nothing if they’re not interested. It happens.

I want feedback on an idea before I work up a patch

Same as a feature request, please ping the rails-core mailing list.

I’ve written a patch, now what?

Submit a pull request with your patch. Someone from core will review it, and may ask you to modify what you’ve done. Eventually it will either get merged into Rails or rejected.

I want to write docs, now what?

Don’t sumbit them as issues to the main Rails repo, instead, check out docrails.

I want to help, but don’t know what to work on!

We try to tag each issue with the part of Rails it affects. If you don’t know where to get started, pick your favorite part of Rails and sort the issues by that part. For example here are all the issues relating to the asset pipeline.

Try to reproduce the bug locally, write a test that fails, write a patch, boom!

How do I set up my local machine to work on Rails

Check the Rails Guide here.

Shoes 4 work is starting: get involved!

Fri, 25 May 2012 00:00:00 GMT

As you know, I’ve been doing a lot of work over the last few years to keep _why’s Shoes project going. A few other intrepid individuals have been doing a lot as well. We’re starting to work on Shoes 4, and we’d love your help.

A little about Shoes

If you didn’t know, Shoes is a GUI toolkit for Ruby. It uses blocks heavily:

Shoes.app do
  para "Push the button"
  
  button "Me! Me!" do
    alert "Good job."
  end
end

Super simple. You get native widgets on all platforms.

Shoes 4

Shoes 4 is a total re-write of Shoes. It’s being done in JRuby. There are a few related projects:

ShoesSpec: An executable specification for Shoes implementations, so that others can co-exist. A few other Shoes projects exist already, and a unified interface will be great.
Shoes-mocks: Sort of the opposite, a dummy set of Shoes that you can use to test applications written in Shoes.
The website: A new website is being made as well. Help here would be just as awesome as work on Shoes itself.

What we need

Of course, pull requests are always welcome. But if you use Shoes or want to, please get involved in the discussions about what Shoes 4 will look like on the bug tracker. Feel free to open an Issue with any topic for discussion. Thoughts from users, current and potential, are always awesome!

Let’s all have fun developing Shoes 4!

Building StoreEngine

Thu, 05 Apr 2012 00:00:00 GMT

So I said I was gonna build antisocialne.ws. But I’m changing gears instead: I’d rather do this project, which has a better spec and needs a reference implementation.

Building StoreEngine from Steve Klabnik on Vimeo.

Introducing metadown

Mon, 23 Jan 2012 00:00:00 GMT

Because I don’t have enough gems made already, I made another one last night: metadown.

What’s Metadown do?

This blog originally used Jekyll. When I moved it to my own personal blog implementation, I noticed something: Markdown doesn’t actually have support for adding YAML at the top of your files, like Jekyll does. I always knew this, I just didn’t think about it before. And I love using Markdown, so I ended up extracting my own version of this trick into Metadown.

Basically, sometimes you need metadata about your markup file. YAML is a nice format for writing key/value pairs, lists, and other things… so I’ve let you smash the two of them together in one file by adding some ---s at the top.

Gimme an Example

require 'metadown'

data = Metadown.render("hello world")
data.output #=> "<p>hello, world</p>"
data.metadata #=> "{}"

text = <<-MARKDOWN
---
key: "value"
---
hello world
MARKDOWN

data = Metadown.render(text)
data.output #=> "<p>hello, world</p>\n"
data.metadata #=> {"key" => "value"}

Where’s the code?

It’s implemented using a custom parser for Redcarpet, has a test suite, and works on every Ruby that’s not JRuby. You can check out the source here. Issues and Pull Requests welcome. There’s at least one thing that I know I’ll need to add to it in the near future.

Moving from Sinatra to Rails

Tue, 17 Jan 2012 00:00:00 GMT

I love both Sinatra and Rails, for different reasons. I’ve heard a few different heuristics for which framework would be better for your application, but I’m not sure the answer is all that simple, really. Regardless of which is correct for your application, I haven’t seen a lot of people discussing how to move between the two frameworks.

Step One: Evaluate your test coverage

In Working Effectively with Legacy Code (this is an affiliate link. Does this bother you?), Michael Feathers introduces a fantastic technique called “Lean on the Compiler.” It’s on page 315, for those of you playing along at home.

The primary purpose of a compiler is to translate source code into some other form, but in statically typed languages, you can do much more with a compiler. You can take advantage of its type checking and use it to identify which changes you need to make. I call this practice Leaning on the Compiler.Lean on the Compiler is a powerful technique, but you have to know what its limits are; if you don’t, you can end up making some serious mistakes.

Now, in a language like Ruby, we don’t have type checking. We do have something that double checks our code correctness: tests. Just like static type checks, tests cannot ensure that you’ve done your transformations, but they sure as hell can help. This becomes step one in the effort to move from one framework to another: evaluate your test coverage.

Acceptance Tests are most important

When looking at your tests, first check out your acceptance tests. These are the most important, for two reasons: they’re abstracted away from the framework itself, and their purpose in life is to make sure that major functionality is working. Do you have your happy paths covered? Is there any major functionality that’s not covered by acceptance tests?

While the happy path is a big deal, when moving to a new framework, we’re going to introduce a high chance of people encountering issues, so the sad path is also important. I personally tend to not write very many sad path acceptance tests and leave that for tests at the lower level. This is a good time to take stock of the worst of your worst paths: is there certain functionality that’s absolutely important to be handled 100% correctly? Then write some new acceptance tests. As with any kind of engineering project, there’s a tradeoff here: you can’t get coverage of every possible situation. Tests are supposed to give you confidence in your code, so liberally add coverage for any situation that makes you nervous.

Integration tests are important too

These tests are a bit more tricky, as they are tied into the framework that you’re using. I’m not sure that anyone writes many of these kinds of tests with Sinatra, outside of maybe model to model integration tests.

Model and View tests: not a big deal

These kinds of tests are much more of a sanity check than anything else for the purposes of this kind of move. It’s good that they pass, but really, they shouldn’t be too reliant on the framework you’re using. They’re better for making sure you’ve put things in the correct directories and haven’t forgotten anything in the move.

I’m not even sure what a ‘view test’ would be in Sinatra, and they tend to be not in favor with Rails projects anyway, so that’s more of a general ‘framework to framework’ bit of advice than anything else.

Controllers don’t exist in Sinatra…

… so you don’t really write those kinds of tests. Controller tests don’t seem to be that popular in Rails-land these days either.

Step Two: Git Can help

I’ll show you how I managed transitioning files over. However, I’m really interested in the idea of using a subtree merge to keep being able to update the original Sinatra project while working on the new Rails project.

First step is, of course, make a new branch. This transition will probably take some time, and you may want to push hotfixes into production during that period. Using master is not advised.

Next, make a copy of everything and shove it in a temp directory. Then delete everything in the git repo (except the .git directory, of course) and commit that blank slate. Back up one directory above your project directory, run rails new myproject with your project’s name, and you’ll get a blank rails app. cd myproject and mkdir sinatra, then copy the backup you made from the temp directory into the sinatra directory. Finally, commit this.

Now you’ve got a new blank Rails app with all your old code in a directory, and you can start moving things over.

Step Three: Set up your test harness

Since we’re going to allow our tests to guide our move, it pays to get tests up and running first! Depending on what testing framework you use, get it going with Rails. In our case, we were using minitest to test our code. This took a little bit of effort to get working with Rails, but there weren’t a ton of problems.

As always: red, green, refactor. I’d make a simple test that doesn’t test anything, assert true. Make sure that your rake test or rspec . or whatever you’ll use to run the tests works and then remove the dummy test.

There are two strategies for moving tests over: you can move a chunk at a time or move one at a time. Chunks are easier, but then you get commits where the build is broken. It’s really up to you and your team’s tastes: a huge test suite with a number of failures can show you how close you are to being done with the first 90% of the work. And since you’re not planning on releasing in this half-finished state, having a broken build is not that terrible… As always, you’re the professional: make the call.

Step Four: Move your models

Since models are the simplest to move, I like to do them first. You should just be able to copy over each test file and model file, though because you were using Sinatra, your models may be all in one file. This step should be largely painless, though: you’re not really relying on any framework-specific things.

Model tests can still suss out problems with your environment, though, like incorrect database settings, certain environment variables…

The idea to begin with the easiest thing comes from Dave Ramsey, oddly enough. My aunt works at a bank, and when I went to college, she bought me a few of his books to help me learn about personal finance. Dave is a big fan of the ‘get rid of all debt’ school of thought, and so a large portion of his work is strategies for getting out of debt. Dave contends that paying off loans with the highest interest, while mathematically the fastest way to pay off your obligations, is not actually the best strategy. People like to see progress and are heartened by seeing it. By paying off the smallest loan first, one is much more likely to feel more positive about the headway one is making, and so it’s a much better strategy in the end.

The same logic applies with this move: why start with the hard stuff? Knock out some quick wins to keep your spirits high.

Step Five: Convert your controllers

Next up: get your controllers created. This is a pretty manual process:

get "foos" do
  @foos = Foo.all
  render :"foos/index"
end

becomes

class FooController < ApplicationController
  def index
    @foos = Foo.all
  end
end

The biggest issue with moving all of this stuff is that Sinatra and Rails use redirect and redirect_to, respectively. So you’ll have to convert that stuff. However, I wouldn’t recommend changing things like redirect "/foos/#{id}" to redirect_to foo_path(foo) just yet. When dealing with legacy code, you want to change as little as possible with each step so that you know when you have introduced an error. If you try to convert things to a Rails style as well, you run the risk of introducing errors. Therefore, in all of these moves, leave the hell enough alone as much as possible. Once your code is up and running, you can gladly refactor. Just don’t do it now.

Don’t forget to generate your routes, too. Sinatra’s DSL is like a combination of Rails’ routing and controllers. Set those up in this step as well.

Since we don’t have tests, this part is very error-prone. Luckily, our acceptance tests will catch these issues in step seven. So give it your best shot, but don’t worry about being 100% perfect. Focus on getting the basic structural changes in place.

Having tests is so nice. :/

Step Six: Move your views

This should be as simple as the models: put your views in the correct directory, and things should be golden. If you were using inline views with Sinatra, well, you shouldn’t have that many of them, so breaking them out should be pretty easy.

Step Seven: Listen to your tests

Okay! Those last moves were really awkward since we didn’t have tests to check our work. This is where the acceptance tests come in. You can move these over in batches or one at a time, but the acceptance tests will tell you where you forgot a route, if your view is missing, or if you left some little bit of Sinatra-ness in your Rails somewhere.

You’re almost home! Once you get all your acceptance tests working, you should pat yourself on the back! You’re not done yet, but you’ve made a lot of progress.

Step Eight: Track your exceptions!

You should have been doing this anyway, but if you weren’t, set up some sort of mechanism to catch and handle exceptions. Airbrake is one such service, but even just recording them yourself would be fine. You need to have this set up in some form, as you’re likely to generate errors, and examining your exceptions is the best way to track down actual problems.

Step Nine: Plan out deployment strategies

Of course, now that you’re done developing, it’s time to get the app out to users. This’ll require a comprehensive plan for actually making the jump. A little bit of foresight can go a long way here.

My strategy was to roll out the new Rails app under a new domain: http://beta.myapp.com/. I then pinged my users with a message along the lines of “We’ve made some infrastructure updates, if you’d like to help us test them out, visit the beta site.”

This approach does have some sticky points, however. The first one is the database. In my case, I had a high level of confidence in my code, and this application wasn’t for anything that was considered mission-critical. We also had a decent backup strategy in place. Therefore, I connected the beta site up to the production data store. This meant there were no migration issues later. However, this may make you uncomfortable, but there are other options, too. You can treat the beta as a sandbox, and tell people that the data will not be persisted after the beta, or you can migrate people’s data back to the production data store afterwards.

Another approach is to automatically migrate a portion of your users over to the new code base. Ideally, nobody notices: your code base shouldn’t have changed in looks or functionality.

Step Ten: Push to production!

Congrats! Execute on the plan you created in step nine, and get ready to answer tons of emails about why your app is broken! Just kidding, I hope! I really recommend the beta strategy for this reason. No plan survives first contact with the enemy. Your users will find things you didn’t, no matter how much manual testing you did along the way.

Another strategy: mounting

I haven’t actually tried this myself, but I’ve been thinking about another way to make this happen: mount your Sinatra app inside of a Rails app, and use that to move things over slowly. Here’s an example of how to make this happen technically. If you had a really big Sinatra application, I could see how this might get you deploying faster; just carve out one vertical chunk of your app, move it over, and keep the rest of your app running in Sinatra.

ActiveRecord considered harmful

Fri, 30 Dec 2011 00:00:00 GMT

It is practically impossible to teach OO design to students that have had a prior exposure to Rails: as potential programmers they are mentally mutilated beyond hope of regeneration.Edsger W. Dijkstra (paraphrased)

I love ActiveRecord. It was the first ORM I’d ever interacted with. My first technical employer had commissioned a DBA, and so of course, we wrote all our own queries. Which was fine; I know my way around a JOIN or two. The problem came when it was time to make a new class; time to write “SELECT * FROM ‘tableName’ WHERE ‘id’=‘%’”… for each class. “Just copy one of the other small classes, hack out everything, and change the table names,” were my instructions. Fine. Whatever. But I knew there had to be a better way…

Along comes Rails. Holy crap, ActiveRecord is awesome! It writes the exact SQL I would have written myself! I don’t need to do anything. This is the best thing since sliced bread. But years later, not everything is rainbows and sunshine. I’ve written a lot of crappy code, and most of it is due to following Rails ‘best practices.’ Which is totally fine! Rails is kinda getting old these days. It’s no longer the new and shiny. But while Rails developers have gotten really good at busting out little CRUD apps, we haven’t moved web application design forward in a really, really long time.

And that’s what Rails did, really. That fifteen minute blog video was shocking. I know several people that threw away two or three week old projects and re-built their stuff in Rails within moments of watching it. And Rails has continued to lead the way in improving how we build rich applications on the web; the (not so but kinda whatever nobody but me cares) RESTful routing was great. The asset pipeline, though it has some bugs, has been great. The obsession with DRY has been great. The test obsession has been great. But Rails has also not been great in aiding us in writing maintainable software. Many of Rails’ design decisions make it difficult to write great software. It helps us write good software, but that isn’t enough anymore.

The real problem is that to truly move forward, Rails will have to re-invent itself, and I’m not sure that it can.

ActiveRecord is the problem

I’m not going to talk about all of the problems Rails has today, but I’d like to show you the biggest, most central one: ActiveRecord.

ActiveRecord’s greatest strength is also its problem: Tying class names to table names. This means that it’s impossible to de-couple your persistence mechanism from your domain logic. You can manage it through a combination of set_table_name, making a bunch of Repository classes, and careful coding… but then you might as well be using DataMapper. Except the Ruby library of the same name doesn’t really implement the DataMapper pattern all that well either, having the same issue of tying it all together.

This has another interesting effect: it led directly to the ‘fat model’ recommendation. While ‘get your stuff out of the controller’ is correct, it’s lead Rails developers to build huge, monolithic models that are hard to test, and violate SRP. It took me two and a half years to realize that Ruby classes in the models folder don’t have to inherit from ActiveRecord::Base. That is a problem.

We’ve gotten into a situation with a local minimum: our quest for great software has lead us to DRY ourselves into a corner. Now we have code that’s incredibly tightly coupled. Our ‘single responsibility’ is ‘anything and everything that tangentially relates to a Post.’

ActionController is the problem

ActionController relies on instance variables to pass information from the controller to the view. Have you ever seen a 200 line long controller method? I have. Good luck teasing out which instance variables actually get set over the course of all those nested ifs.

The whole idea is kinda crazy: Yeah, it looks nice, but we literally just say ‘increase the scope of variables to pass data around.’ If I wrote a post saying “Don’t pass arguments to methods, just promote your data to a global” I’d be crucified. Yet we do the same thing (albeit on a smaller scale) every time we write a Rails application.

ActionView is the problem

The whole idea of logic in templates leads to all kinds of problems. They’re hard to test, they’re hard to read, and it’s not just a slippery slope, but a steep one. Things go downhill rapidly.

What I’d really like to see is Rails adopting a ‘ViewModel + templates’ system, with logic-less templates and presenter-esque models that represent the views. The differences between Django’s idea of ‘views’ and Rails’ idea of ‘views’ are interesting here.

MVC is the problem

If you’ll notice, I basically have said that models are a problem. Controllers are a problem. Views are a problem. MVC has served the web well, even if it isn’t the GUI style MVC that named the pattern. But I think we’re reaching its limits; the impedance mismatch between HTTP and MVC, for example, is pretty huge. There are other ways to build web applications; I’m particularly excited about WebMachine. I don’t have a constructive alternative to offer here, I just know there’s a problem. I’m still mulling this one over.

It’s still good, even with problems

I love Rails. I build software with it daily. Even with its flaws, it’s been a massive success. But because I love Rails, I feel like I can give it straightforward criticism: it’s easier to trash something you love. The real issue is that changing these things would require some really serious changes. It’d involve re-architecting large portions of things that people classically identify with Rails, and I’m not sure that Rails wants to or can do that.

This post is light on examples. I want this to be the starting point of a discussion, not the end of it. Expect more, in detail, from me in the future. What do you think? Are these problems pain points for you? Are they worth fixing? Are they actually problems?

Redcarpet is awesome

Wed, 21 Dec 2011 00:00:00 GMT

It’s true.

If you haven’t used it yet, Redcarpet is the Markdown parser that GitHub uses to work all that magic on their site. So of course, it’s awesome.

You can use it and abuse it

What makes it really awesome is the custom renderers feature. Here’s the one from the documentation:

# create a custom renderer that allows highlighting of code blocks
class HTMLwithAlbino < Redcarpet::Render::HTML
  def block_code(code, language)
    Albino.safe_colorize(code, language)
  end
end

markdown = Redcarpet::Markdown.new(HTMLwithAlbino)

You can guess what that does: uses some library called Albino to render code blocks. There are a whole bunch of hooks you can use to make a custom renderer. They make it super easy to do something neat with markdown.

So I did.

Check it: outline generation

I’m working on… this project. And it needs to render a bunch of articles that are Markdown files. There will be a sidebar. I want to have links to each section. But I’m a good programmer, which means I’m lazy. So why bother making my own sidebar? Especially when I can abuse Redcarpet to do it.

Oh, and disclaimer: normally, I’m all about super clean code. Last night, that wasn’t the mood I was in. This code is probably terrible. That’s part of the fun! Please feel free to {clean up,obfuscate,golf,unit test} this code, email me, and tell me how awesome you are.

With that disclaimer out of the way, round one:

class OutlineRenderer < Redcarpet::Render::HTML
  attr_accessor :outline

  def initialize
    @outline = []
    super
  end

  def header(text, header_level)
    text_slug = text.gsub(/\W/, "_").downcase
    
    self.outline << [header_level, "<a href='##{text_slug}'>#{text}</a>"]

    "<h#{header_level} id='#{text_slug}'>#{text}</h#{header_level}>"
  end
end

Every time we hit a header, Redcarpet gives us the text and the header level. We grab the text, turn it into a slug, and then append a two-element array to our outline. It keeps track of the level of this header, and makes a link from the slug. Then, we spit out a header tag, adding on an id element that we linked to in our link.

Next up, rendering:

renderer = OutlineRenderer.new
r = Redcarpet::Markdown.new(renderer)
content = r.render(some_content)
outline = renderer.outline

This instantiates our Renderer, creates our Markdown parser, and renders the content. We also grab the outline we made. Sweet.

Finally, rendering the outline:

def format_outline(outline)
  prev_level = 2

  "<ul>" + outline.inject("") do |html, data|
    level, link = data
    if prev_level < level
      html += "<ul>"
    elsif prev_level > level
      html += "</ul>"
    end
    prev_level = level
    html += "<li>#{link}</li>"
    html
  end + "</ul>"
end

This… is amazing. And terrible. Don’t drink scotch and code, kids. Or do, whatever. This takes our Array of Arrays that we made with our renderer and runs inject over it. If our previous level is less than the new level, we indent with a <ul>, and if it’s greater, we outdent with a </ul>. Then we render our link, and wrap the whole thing in its own set of <ul>s. Done!

We can call this helper method in our layout, and bam! We get automatic outlines generated for our Markdown files. Like I said, this is quick and dirty, but for a first pass, I don’t feel too bad about it. Get it done, and then get it done right.

Fast Rails tests with CanCan

Mon, 12 Dec 2011 00:00:00 GMT

If you haven’t used it, CanCan is a great library for Rails that handles authorization for you. Its calling card is simplicity; just do this:

class Ability
  include CanCan::Ability

  def initialize(user)
    user ||= User.new

    if user.is? :paying_customer
      can :show, Article
    else
      can :show, Article, :free => true
      cannot :show, Article, :free => false
    end
  end
end

And then in a controller:

def show
  @article = Article.find(params[:id])
  authorize! :read, @article
end

Super simple! However, as simple as CanCan is, if you want to keep your test times super low, there’s a few things that you should know about.

Incidental coupling: the silent killer

The biggest problem with CanCan from the Fast Tests perspective is that we’ve got coupling with class names. In order to test our Ability class, we also have to load User and Article. Let’s try it without concern for how isolated our tests are:

require "cancan/matchers"
require "spec_helper"

describe Ability do
  let(:subject) { Ability.new(user) }
  let(:free_article) { Article.new(:free => true) }
  let(:paid_article) { Article.new(:free => false) }

  context "random people" do
    let(:user) { nil }

    it "can see free Articles" do
      subject.can?(:show, free_article).should be_true
    end

    it "cannot see non-free Articles" do
      subject.can?(:show, paid_article).should be_false
    end
  end

  context "paying users" do
    let(:user) do 
      User.new.tap do |u|
        u.roles << :paying_customer
      end
    end

    it "can see free Articles" do
      subject.can?(:show, free_article).should be_true
    end

    it "can see non-free Articles" do
      subject.can?(:show, paid_article).should be_true
    end
  end
end

A few notes about testing with CanCan: I like to organize them with contexts for the different kinds of users, and then what their abilities are below. It gives you a really nice way of setting up those let blocks, and our tests read real nicely.

Anyway, so yeah. This loads up all of our models, connects to the DB, etc. This is unfortunate. It’d be nice if we didn’t have to load up User and Article. Unfortunately, there’s no real way around it in our Ability, I mean, if you want them to read all Articles, you have to pass in Article… hmm. What about this?

let(:free_article) { double(:class => Article, :free => true) }
let(:paid_article) { double(:class => Article, :free => false) }

Turns out this works just as well. CanCan reflects on the class that you pass in, so if we just give our double the right class, it’s all gravy. Now we’re not loading Article, but what about User?

The key is in the ||=. If we pass in a User, we won’t call User.new. So let’s stub that:

let(:user) { double(:is? => false) }
let(:user) do 
  double.tap do |u| #tap not strictly needed in this example, but if you want multiple roles...
    u.stub(:is?).with(:paying_customer).and_return(true)
  end
end

Sweet! The first one is a random user: all their is? calls should be false. The second is our user who’s paid up; we need to stub out their role properly, but that’s about it.

It’s that easy

With some dillegence, isolating your tests isn’t hard, and works really well. I have a few more tests in the example I took this from, and 14 examples still take about a third of a second. Not too shabby!

Happy authorizing!

Oh, and the final spec, for reference:

require "cancan/matchers"
require "app/models/ability"

describe Ability do
  let(:subject) { Ability.new(user) }
  let(:free_article) { double(:class => Article, :free => true ) }
  let(:paid_article) { double(:class => Article, :free => false) }

  context "random people" do
    let(:user) { double(:is? => false) }

    it "can see free Articles" do
      subject.can?(:show, free_article).should be_true
    end

    it "cannot see non-free Articles" do
      subject.can?(:show, paid_article).should be_false
    end
  end

  context "users" do
    let(:user) do 
      double.tap do |u|
        u.stub(:is?).with(:user).and_return(true)
      end
    end

    it "can see free Articles" do
      subject.can?(:show, free_article).should be_true
    end

    it "can see non-free Articles" do
      subject.can?(:show, paid_article).should be_true
    end
  end
end

Devise: ActionController::RoutingError (No Route Matches [GET] /users/sign_out)

Sun, 11 Dec 2011 00:00:00 GMT

Just a quick note about Devise, and its RESTful implications. I ran across this error today, and thought I’d share.

I was trying to log out, so I hit the normal route for such things with my browser. Here’s the error:

Devise: ActionController::RoutingError (No Route Matches [GET] /users/sign_out)

Uhhhhh what? I run rake routes…

$ rake routes | grep destroy_user
    destroy_user_session DELETE /users/sign_out(.:format)      {:action=>"destroy", :controller=>"devise/sessions"}

So, wtf? Well, there is that pesky DELETE… Googling for this error led me to this commit. Looks like they changed some behavior, you can’t just go to that page anymore and log out. Bummer. But why?

HTTP verbs: transfer semantics, not state

As I’ve been doing my research for my book on REST, I’ve been doing a lot of reading about HTTP. And I kept coming across these kinds of curious comments in the spec. For example, sec 9.6: PUT:

HTTP/1.1 does not define how a PUT method affects the state of an origin server.

Uhhh… what? Don’t we all know that PUT means that we should be updating a resource? And that we have to send the whole representation?

When trying to get to the bottom of this, I came across this comment from Fielding:

FWIW, PUT does not mean store. I must have repeated that a million times in webdav and related lists. HTTP defines the intended semantics of the communication – the expectations of each party. The protocol does not define how either side fulfills those expectations, and it makes damn sure it doesn’t prevent a server from having absolute authority over its own resources. Also, resources are known to change over time, so if a server accepts an invalid Atom entry via PUT one second and then immediately thereafter decides to change it to a valid entry for later GETs, life is grand.

Soooooooo wtf?

Let’s take a look again at what PUT does:

The PUT method requests that the enclosed entity be stored under the supplied Request-URI. If the Request-URI refers to an already existing resource, the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server. If the Request-URI does not point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent, the origin server can create the resource with that URI.

It says “store,” Roy says “I don’t mean store.” Uhhhh…

Here’s my ‘translated for the laymen’ version of that quote:

PUT means ‘I’d like to later GET something at this URI.’ If something is already there, update it. If there isn’t anything there, then create it.

That’s it. It’s talking about the semantics of what goes on: create or update. It doesn’t actually say anything about how this is implemented. But if you PUT something to a URI, a GET needs to 200 afterwards. So what’s the difference between PUT and POST? HTTP sec 9.5: POST:

The POST method is used to request that the origin server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line.The actual function performed by the POST method is determined by the server and is usually dependent on the Request-URI. The posted entity is subordinate to that URI in the same way that a file is subordinate to a directory containing it, a news article is subordinate to a newsgroup to which it is posted, or a record is subordinate to a database.The action performed by the POST method might not result in a resource that can be identified by a URI.

Again, it’s really vague about what it does. With POST, it basically says “You have no idea what a POST does.” What you do know is the semantics of the action, POST ‘requests a new subordinate, but it might not create something.’

The main difference is actually mentioned here:

Methods can also have the property of “idempotence” in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request. The methods GET, HEAD, PUT and DELETE share this property.

Semantics again. PUT is idempotent, and POST is not. They could both be used for creation, they could both be used for updating. With POST, you don’t need a URI, and PUT specifies a specfic one. That’s it. Nowhere in those two sentences states ‘store in the database,’ nowhere does it says ‘full representation,’ nowhere does it say ‘POST is create and PUT is update.’ However you fulfill these semantics are up to you, but the semantics are what’s important.

So wtf does this have to do with Devise?

The issue is that Devise’s old semantics were wrong. A GET to /users/sign_out shouldn’t modify state: HTTP sec 9.1.1: Safe Methods:

In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered “safe”.

When Devise used GETs to log you out, that was a violation of the semantics of GET. Here’s the interesting part, though: Since POST is a super generic ‘unsafe action’ method, you could also use POST to represent a logging out. POST also has unsafe, non-idempotent semantics. DELETE specifically says delete, and POST says ‘any action,’ and ‘delete’ is a subset of ‘any action.’ So DELETE is better, but POST is not wrong, categorically.

Fixing the ‘bug’

So how do we take care of this? Personally, I did the pragmatic thing. In /config/initializers/devise.rb

config.sign_out_via = :delete
config.sign_out_via = :get if Rails.env.test?

Now, during normal operations, we have our usual DELETE semantics, but in our test environment, we can just hit it with GET. This way we don’t have to hit a page, use Javascript to make a link with DELETE, and hit the page. This keeps my test times down, means I can run my tests with rack-test and not Selenium, and still gives me a high level of confidence that my tests work properly, even though it’s technically not the exact same thing as production.

In conclusion

The HTTP spec defines semantics but not implementation details. Semantics should be obeyed. But in testing, obeying them 100% may not be worth it.

Rubinius is awesome

Tue, 04 Oct 2011 00:00:00 GMT

You walk into work tomorrow morning, and your boss says this:

Boss: Hey, we’re gonna need to go ahead and have you implement require_relative in rubinius. We have some new servers coming in, and we’ll be running it in production, but we use some 1.9.2 features of MRI that haven’t been implemented yet. So if you could just go ahead and get to implementing that, that would be terrific, OK?

Wat do?

(Disregard that your boss would never say this. I kinda wish some of mine would…)

You: Excuse me, I believe you have my stapler…

Err, sorry.

You: No problem, boss. Rubinius is mostly just Ruby, and it has a really helpful core team. I’m sure it won’t be a big deal.

Would you say this? Well, you should. I’m not gonna lie and say that every feature is super simple to implement, or rbx-2.0 would be out already, but for a language interpreter, Rubinius is one of the easiest I’ve ever tried to get into. I actually did implement require_relative last night, and it took me about an hour and a half.

This is my story.

(note: dramatazation. Actual wording made unneccesarily silly to protect the innocent. please do try this at home)

$ ssh stevessecretserver
$ tmux attach
<brings up irssi, I'm already in #rubinius on Freenode>
#rubinius: steveklabnik: hey, I need require\_relative to run my app. How hard
would you think that is to implement?
#rubinius: evan: Naw, man, it'd take like fifteen minutes. Go check out
http://rubygems.org/gems/rbx-require-relative, it's alredy basically got what
you want
#rubinius: steveklabnik: sweet.
#rubinius: brixen: just grep for 'def require'
#rubinius: brixen: and run bin/mspec -tx19 core/kernel/require\_relative to
run the RubySpecs for it.

Armed with this knowledge, I found where require is defined in rbx:

def require(name)
  Rubinius::CodeLoader.require name
end
module_function :require

Of course, I had to look at CodeLoader:

# Searches for and loads Ruby source files and shared library extension
# files. See CodeLoader.require for the rest of Kernel#require
# functionality.
def require
  Rubinius.synchronize(self) do
    return false unless resolve_require_path
    return false if CodeLoader.loading? @load_path

    if @type == :ruby
      CodeLoader.loading @load_path
    end
  end

  if @type == :ruby
    load_file
  else
    load_library
  end

  return @type
end

Hmm, see CodeLoader.require. There are codeloader18 and codeloader19 files…

module Rubinius
  class CodeLoader

    # Searches $LOAD_PATH for a file named +name+. Does not append any file
    # extension to +name+ while searching. Used by #load to resolve the name
    # to a full path to load. Also used by #require when the file extension is
    # provided.
    def search_load_path(name, loading)
      $LOAD_PATH.each do |dir|
        path = "#{dir}/#{name}"
        return path if loadable? path
      end

      return name if loading and loadable? "./#{name}"

      return nil
    end
  end
end

Okay. So we define specific stuff into the 19 file. There’s also a kernel19. So I worked this up:

# Attempt to load the given file, returning true if successful. Works just
# like Kernel#require, except that it searches relative to the current
# directory.
#
def require_relative(name)
  Rubinius::CodeLoader.require_relative(name)
end
module_function :require_relative

# requires files relative to the current directory. We do one interesting
# check to make sure it's not called inside of an eval.
def self.require_relative(name)
  scope = Rubinius::StaticScope.of_sender
  script = scope.current_script
  if script
    require File.join(File.dirname(script.data_path), name)
  else
    raise LoadError.new "Something is wrong in trying to get relative path"
  end
end

But then… running the specs gives me bunches of errors. What gives?

<back in irc>
#rubinius: steveklabnik: yo, my specs are failing, and I'm a n00b. Halp
pl0x?
#rubinius: brixen: oh, yeah, well, the StaticScope is the current scope,
and you're down another method, so that's _totally_ gonna screw up
your paths. Just get it above and pass it down. Oh, and File.join is
dumb, File.expand_path that shit!
#rubinius: steveklabnik: words.

So then I made this one little change:

# Attempt to load the given file, returning true if successful. Works just
# like Kernel#require, except that it searches relative to the current
# directory.
#
def require_relative(name)
  scope = Rubinius::StaticScope.of_sender
  Rubinius::CodeLoader.require_relative(name, scope)
end
module_function :require_relative

# requires files relative to the current directory. We do one interesting
# check to make sure it's not called inside of an eval.
def self.require_relative(name, scope)
  script = scope.current_script
  if script
    require File.expand_path(name, File.dirname(script.data_path))
  else
    raise LoadError.new "Something is wrong in trying to get relative path"
  end
end

$ bin/mspec -tx19 core/kernel/require_relativerubinius 2.0.0dev (1.9.2 cade3517 yyyy-mm-dd JI) [x86_64-apple-darwin10.8.0].....................Finished in 0.191995 seconds1 file, 20 examples, 47 expectations, 0 failures, 0 errors

One more pull request, and I’ve got a patch in on rbx. I had one a few months ago, but this one was way cooler.

In conclusion

Even if I didn’t have some code to look at, because Rubinius is just Ruby, it was really easy to dive in and check out the code, because it’s all Ruby. Seriously. Rubinius is just Ruby. Just Ruby. Ruby.

So dive in and add some features today! If having an awesome alternate Ruby implementation isn’t enough for you, the rbx team will bribe you with special stickers for committers, and sweet black-on-black tshirts for people with 10 commits or more!

Real, modern Ruby development

Wed, 28 Sep 2011 00:00:00 GMT

I came across a blog post the other day titled Modern Ruby Development. While it’s a perfectly fine blog post (other than the digs at rvm…) it really should have been titled something more along the lines of “My default tooling to build a Rails application.” I thought of this yesterday, as I was invited to show up at Vertigo and show them how we do things in the Open Source world. Vertigo builds lots of cool things, but they tend to be very .NET centric, and it was neat for both of us to see how the other half lives.

Shortly before my ‘presentation,’ we decided that I’d basicaly just build a little web app in front of them. Live coding to the max! We decided for maximum awesome, and since I was in town for the Twilio conference, that I’d make a Twilio app that they could text and it’d text you ’hello world: you said #{msg}” back. I thought I’d share that process with you, too. I ended up throwing away the code, though, because I committed my account credentials into the git repo to simplify things, so I’ll just be describing it to you. Check my other posts for code stuff. ;)

Oh, and one more thing: lots of this stuff is about getting ‘iteration zero’ out of the way: it’s setup work that you have to do to set the tone for everything else. In its own way, it’s also a tooling overview, I’ve just focused on the tools that help the process rather than the language stuff. I’ve already written a more ‘dev proccess’ style post over at Timeless, about BDD.

rvm –rvmrc –create 1.9.2@hello_text

First up: decide what Ruby you’re using. I talked breifly about MRI, Rubinius, and JRuby, and some pros and cons for each. I still tend to use MRI for my production code at the moment, but soon, rbx will become my default.

I use rvm because it does exactly what I want.

mvim README.md

I really enjoy README driven development. I didn’t actually demo this due to time constraints, but I generally write at least a minimal README.md before doing anything else. During Windy City Rails, Tom shared something that he likes doing: mv README.md SPEC.md. That way, you can keep your actual README in sync with what the code does right now, but have the final one that you want to work towards too.

git push origin

Now that we have a file, we can push it up to GitHub. A few clicks on the web, a git add remote and git push -u origin master and we’re off to the races.

mvim Gemfile && bundle

Next up we talked about Bundler, Gemfiles, and managing gems. I talked about the ability to run your own private gem server for internal gems, and how easy it is to build and publish a gem.

mkdir spec

I then generally type this. I would be lying to you if I told you that I do TDD 100% of the time. Sometimes, I get lazy. But I try to. And since testing is such a huge part of Ruby culture, and we have world-class testing tools, this is where I started.

I wrote specs for a model class called SmsGateway. This class would handle sending a message to a phone via Twilio. I was able to show off rspec, talk about DSLs, mocking, and TDD.

mvim something.rb

In this case it’s sms_gateway.rb, but you know what I mean. Write some code, rspec spec/sms_gateway_spec.rb, repeat. Red, Green, Refactor. Wheee!

mvim .travis.yml

I wanted to show Travis off, so in my demo I did this before implementing the gateway class, but normally I’d do this after the first spec passes. Continuous Integration and even Continuous Deployment are awesome. Travis makes it super easy.

I went over to Twilio’s site, registered a new account, and got my credentials. I used their docs to figure out where to put them, and how to get it all going inside my gateway class (I just mocked it out before), and talked about how needing to Google for docs is a weakness of Ruby.

heroku create && git push heroku master

Then I showed them how to get going with Heroku, and how easy it was to start giving them hundreds of dollars per month when you need to scale. .NET people are used to paying for everything. ;)

I also showed off one of my latest projects, which is an IRC bot that lets me deploy rstat.us into production. I have some serious Hubot envy. :D

… repeat!

I’d be lying if I said it worked the first time, I accidentally made a loop where the app texted itself. Whoops! But that was cool, and showing off my debugging process (I’m a puts/throw params debugger) was fun, as well. After realizing what I did wrong, we had the app working.

It’s not quite perfect

This dev process isn’t perfect yet. Nothing ever is. I’m always trying to improve upon it, but I’m pretty happy with how quickly I’m able to turn out new projects with a reasonable amount of quality. What’s your workflow? How does mine suck? Email me, I’d love to hear about it.

Better Ruby Presenters

Fri, 09 Sep 2011 00:00:00 GMT

My last blog post caused a bit of a stir in some circles. I got a bunch of emails. Apparently, I need to expand on a few things. So here we go. Let’s rap about the Presenter pattern, shall we?

No seriously, helpers suck

In Ruby, everything is an object. Every bit of information and code can be given their own properties and actions. - ruby-lang.org/about

… except helpers. Why is it in Ruby that everything is an object, even integers, yet as soon as we need to format a date, we all turn into Dijkstra and bust out structured programming? Actually, come to think of it, Dijkstra wouldn’t even write any code, because it’s beneath him, but you get the idea. (if you don’t get this, it’s a joke. About proofs, telescopes, and CS…) Helpers are like a compliment that you don’t want to give, but feel obligated to: “Yeah, I mean, well, you tried, and that’s what counts, right?”

This is the topic of a future post, but when programming in a language, you want to work with its primary methods of abstraction. In Ruby, that’s objects, and there’s a good reason for that: functions don’t provide a sufficient amount of power to tackle hard problems. I don’t want to get into this either, but there’s a reason that objects exist, and that nobody’s making procedural languages anymore. No biggie. C has a special place in my heart.

But I digress: objects > functions. At least in the context of getting stuff done in Ruby. This pretty much applies to most of the rest of the points in this post, so just keep that in the back of your brain.

Why not a class method?

Well, first of all, class methods also suck. Here’s the issue: Can you tell me the difference between these two methods?

def foo
  "hello"
end

class Bar
  def self.foo
    "hello"
  end
end

foo
Bar.foo

Yep, that’s right. You can see it clearly from the last two lines: class methods are functions that happen to be namespaced. That means they’re slightly better, but really, DictionaryPresenter.as_dictionary(something) might as well just be a helper. At least as_dictionary(something) is shorter.

Here’s another reason: I didn’t make that method be a class method, even though there was no state, because a really real presenter (I mean, that was a real world example, but…) generally works a little different. Usually, I make presenters that actually stand in for the objects they’re presenting. Check this out. Here’s the presenter I showed you:

class DictionaryPresenter
  def initialize(collection)
    @collection = collection
  end

  def as_dictionary
    dictionary = ('A'..'Z').inject({}) {|h, l| h[l] = []; h}

    @collection.each do |p|
      dictionary[p.title[0]] << p
    end

    dictionary
  end
end

The real-world presenter that I used this for looked like this:

class DictionaryPresenter
  include Enumerable

  def initialize(collection)
    @dictionary = ('A'..'Z').inject({}) {|h, l| h[l] = []; h}

    collection.each do |p|
      @dictionary[p.title[0]] << p
    end
  end

  def each &blk
    @dictionary.each &blk
  end
end

… or close to this. There was an ‘other’ category, and a few other things… but you get the idea. Now, instead of this:

@posts = DictionaryPresenter.new(Post.all).as_dictionary

You do this:

@posts = DictionaryPresenter.new(Post.all)

And the presenter actually stands in for the hash. A subtle but important difference. This gives you more options, because you have a real, live object instead of just some random processing. With this simplistic presenter, you might not see a huge benefit, but often, you’ll want something a bit more complicated. And since this was what I had in my head, I didn’t make as_dictionary be a static method.

Oh, and presenters that decorate a single object rather than a collection often implement method_missing, so that you only add methods rather than hide most of them. Some don’t. It depends.

Blocks vs. Policy

I also showed off a Ruby version of a design pattern known as the Policy pattern, or sometimes the Strategy pattern. Turns out that Policy is often a bit heavyweight for Ruby, especially in an example like this, so I wanted to show you an alternate version of it, taking advantage of a Ruby feature: blocks.

For reference, the old code, put into the new code:

class DictionaryPresenter
  include Enumerable

  def initialize(policy, collection)
    @dictionary = ('A'..'Z').inject({}) {|h, l| h[l] = []; h}

    collection.each do |p|
      @dictionary[policy.category_for(p)] << p
    end
  end

  def each &blk
    @dictionary.each &blk
  end
end

class UserCategorizationPolicy
  def self.category_for(user)
    user.username[0]
  end
end

We could use blocks instead:

class DictionaryPresenter
  include Enumerable

  def initialize(collection, &blk)
    @dictionary = ('A'..'Z').inject({}) {|h, l| h[l] = []; h}

    collection.each do |p|
      @dictionary[blk.call(p)] << p
    end
  end

  def each &blk
    @dictionary.each &blk
  end
end

DictionaryPresenter.new(Post.all) do |item|
  item.title[0]
end

While this is shorter, and a bit more Rubyish, it also means that we lose the reification of our concept of a policy. While this is shorter, I find it more confusing. Why am I giving this one line block to the presenter? It’s not really clear to me. And I can’t give a better name to item… and if I want to change the policy, it has to be done in every place we use the presenter…

This does get to the root of another thing that will end up being a follow-up: What’s the difference between closures and objects? If you don’t know, maybe this will get you thinking:

#ugh, this is slightly odd, thanks Ruby!
def apply(proc=nil, &blk)
  if block_given?
    blk.call
  else
    proc.call
  end
end

proc = Proc.new do
  puts "a proc!"
end

class MyProc
  def call
    puts "an object!"
  end
end

my_proc = MyProc.new

apply do
  puts "a block!"
end

apply proc

apply my_proc

Chew on that a while.

This is too verbose

Absolutely. DictionaryPresenter.new(PostCategorizationPolicy, Post.all).as_dictionary is too long. 100% there. Good thing that I’d actually write this:

Dictionary.new(Post.all, ByTitle)

I switched the arguments around, because it reads better. When writing blog posts, you have to balance writing code samples that explain what you’re trying to say, and ones that are ‘real.’ I tend to be a bit more verbose with things like this, because it’s easier for someone who just jumps in to remember what all the parts are… then again, by not showing the ‘real code,’ people might end up implementing the crappy, verbose version. It’s always a trade-off, and I may or may not make the right choice. It happens.

And yes, even earlier in this blog post: I said DictionaryPresenter and I’d really just say Dictionary.

Where does all of this go?

You’ve got two options, and only one of them is good: You should make a directory in app for your presenters. In this case, I’d be running touch app/presenters/dictionary.rb pretty quick. The other case is to put things in lib. This whole debacle uncovers something that @avdi went on a rant about over the last few days: models don’t have to inherit from anything. Here’s what Wikipedia says about models:

The model manages the behaviour and data of the application domain, responds to requests for information about its state (usually from the view), and responds to instructions to change state (usually from the controller). In event-driven systems, the model notifies observers (usually views) when the information changes so that they can react.

See anything about “saves stuff to the database?” Okay, ‘manages… data’ could be, but the point is, it’s not required. Models are the reification of a concept that exists in your application domain. Persistance is not required for every concept.

Therefore, if it relates to your problem domain, it goes in app. If it doesn’t, it goes in lib. Something like Dictionary? Depends on how important you think it is. It’s probably pretty important; that’s why you made it a class.

Design Patterns? Are you serious?

Yes. Design patterns don’t suck, Design patterns in Java suck. I’m not even going to start this one here, expect more in this space soon.

Design patterns are great, and they’re totally useful in Ruby.

In conclusion: A shout-out

I hope you’ve enjoyed this small digression on Presenters. If you’re gonna use presenters in your application, I encourage you to write simple ones as simple Ruby classes, but if they get slightly more complicated, you need to check out Draper by my buddy Jeff Casimir. It lets you do stuff like this:

class ArticleDecorator < ApplicationDecorator
  decorates :article

  def author_name
    model.author.first_name + " " + model.author.last_name
  end
end

article = ArticleDecorator.find(1)
article.author_name

There’s a lot of features to it, so check it out on GitHub. Totally worthwhile.

The secret to Rails OO design

Tue, 06 Sep 2011 00:00:00 GMT

UPDATE: I also have a follow-up here.

I often tell people that I learned Ruby via Rails. This is pretty much the worst way to do it, but I’d learned so many programming languages by then that it didn’t hinder me too much. The one thing that it did do, however, was give me a slightly twisted sense of how to properly design the classes needed in a Rails app. Luckily, I obsessively read other people’s code, and I’ve noticed that there’s one big thing that is common in most of the code that’s written by people whose design chops I respect.

This particular thing is also seemingly unique to those people. It’s not something that people who don’t write good code attempt, but do badly. It’s like a flag, or signal. Now, when I see someone employ this, I instantly think “they get it.” Maybe I’m giving it too much credit, but this advanced design technique offers a ton of interconnected benefits throughout your Rails app, is easy to imploy, and speeds up your tests by an order of magnitude or more. Unfortunately, to many beginning Rails devs, it’s non-obvious, but I want you to write better code, and so I’m here to ‘break the secret,’ if you will, and share this awesome, powerful technique with you.

It’s called the ‘Plain Old Ruby Domain Object.’

Yep, that’s right. A Ruby class that inherets from nothing. It’s so simple that it hides in plain sight. Loved by those who’ve mastered Rails, Plain Old Ruby Objects, or “POROs” as some like to call them, are a hidden weapon against complexity. Here’s what I mean. Examine this ‘simple’ model:

class Post < ActiveRecord::Base
  def self.as_dictionary
    dictionary = ('A'..'Z').inject({}) {|h, l| h[l] = []; h}

    Post.all.each do |p|
      dictionary[p.title[0]] << p
    end

    dictionary
  end
end

We want to display an index page of all our posts, and do it by first letter. So we build up a dictionary, and then put our posts in it. I’m assuming we’re not paginating this, so don’t get caught up in querying for all Posts. The important thing is the idea: we can now display our posts by title:

- Post.as_dictionary do |letter, list|
  %p= letter
  %ul
  - list.each do |post|
    %li= link_to post

Sure. And in one way, this code isn’t bad. It’s also not good: We’ve mixed a presentational concern into our model, which is supposed to represent buisness logic. So let’s fix that, via a Presenter:

class DictionaryPresenter
  def initialize(collection)
    @collection = collection
  end

  def as_dictionary
    dictionary = ('A'..'Z').inject({}) {|h, l| h[l] = []; h}

    @collection.each do |p|
      dictionary[p.title[0]] << p
    end

    dictionary
  end
end

We can use it via DictionaryPresenter.new(Post.all).as_dictionary. This has tons of benefits: we’ve moved presentation logic out of the model. We’ve already added a new feature: any collection can now be displayed as a dictionary. We can easily write isolated tests for this presenter, and they will be fast.

This post isn’t about the Presenter pattern, though, as much as I love it. This sort of concept appears in other places, too, “this domain concept deserves its own class.” Before we move to a different example, let’s expand on this further: if we want to sort our Posts by title, this class will work, but if we want to display, say, a User, it won’t, because Users don’t have titles. Furthermore, we’ll end up with a lot of Posts under “A,” because the word “a” is pretty common at the beginning of Posts, so we really want to take the second word in that case. We can make two kinds of presenters, but now we lose that generality, and the concept of ‘display by dictionary’ has two representations in our system again. You guessed it: POROs to the rescue!

Let’s change our presenter slightly, to also accept an organizational policy object:

class DictionaryPresenter
  def initialize(policy, collection)
    @policy = policy
    @collection = collection
  end

  def as_dictionary
    dictionary = ('A'..'Z').inject({}) {|h, l| h[l] = []; h}

    @collection.each do |p|
      dictionary[@policy.category_for(p)] << p
    end

    dictionary
  end
end

Now, we can inject a policy, and have them be different:

class UserCategorizationPolicy
  def self.category_for(user)
    user.username[0]
  end
end

class PostCategorizationPolicy
  def self.category_for(post)
    if post.starts_with?("A ")
      post.title.split[1][0]
    else
      post.title[0]
    end
  end
end

Bam!

DictionaryPresenter.new(PostCategorizationPolicy, Post.all).as_dictionary

Yeah, so that’s getting a bit long. It happens. :) You can see that now each concept has one representation in our system. The presenter doesn’t care how things are organized, and the policies only dictate how things are organized. In fact, my names sorta suck, maybe it should be “UsernamePolicy” and “TitlePolicy”, actually. We don’t even care what class they are!

It goes further than that in other directions, too. Combining the flexibility of Ruby with one of my favorite patterns from “Working Effectively with Legacy Code,” we can take complex computations and turn them into objects. Look at this code:

class Quote < ActiveRecord::Base
  #<snip>
  def pretty_turnaround
    return "" if turnaround.nil?
    if purchased_at
      offset = purchased_at
      days_from_today = ((Time.now - purchased_at.to_time) / 60 / 60 / 24).floor + 1
    else
      offset = Time.now
      days_from_today = turnaround + 1
    end
    time = offset + (turnaround * 60 * 60 * 24)
    if(time.strftime("%a") == "Sat")
      time += 2 * 60 * 60 * 24
    elsif(time.strftime("%a") == "Sun")
      time += 1 * 60 * 60 * 24
    end

    "#{time.strftime("%A %d %B")} (#{days_from_today} business days from today)"
  end
end

Yikes! This method prints a turnaround time, but as you can see, it’s a complex calculation. We’d be able to understand this much more easily of we used Extract Method a few times to break it up, but then we risk polluting our Quote class with more stuff that’s only relevant to pretty turnaround calculation. Also, please ignore that this is also presentation on the model; we just care that it’s a complex bit of code for this example.

Okay, so here’s the first step of this refactoring, which Feathers calls “Break Out Method Object.” You can open your copy of “Working Effectively With Legacy Code” and turn to page 330 to read more. If you don’t have a copy, get one. Anyway, I digress. Here’s the plan of attack:

Create a new class for the computation
Define a method on that class to do the new work.
Copy the body of the old method over, and change variable references to instance variables.
Give it an initialize method that takes arguments to set the instance variables used in step 3.
Make the old method delegate to the new class and method.

I’ve changed this slightly for Ruby, since we can’t Lean On The Compiler, and a few of Feathers’ steps are about doing this. Anyway, let’s try this on that code. Step 1:

class Quote < ActiveRecord::Base
  def pretty_turnaround
    #snip
  end

  class TurnaroundCalculator
  end
end

Two:

class TurnaroundCalculator
  def calculate
  end
end

Three:

class TurnaroundCalculator
  def calculate
    return "" if @turnaround.nil?
    if @purchased_at
      offset = @purchased_at
      days_from_today = ((Time.now - purchased_at.to_time) / 60 / 60 / 24).floor + 1
    else
      offset = Time.now
      days_from_today = @turnaround + 1
    end
    time = offset + (@turnaround * 60 * 60 * 24)
    if(time.strftime("%a") == "Sat")
      time += 2 * 60 * 60 * 24
    elsif(time.strftime("%a") == "Sun")
      time += 1 * 60 * 60 * 24
    end

    "#{time.strftime("%A %d %B")} (#{days_from_today} business days from today)"
  end
end

I like to give it a generic name at first, and then give it a better one in step 5, after we see what it really does. often our code will inform us of a good name.

Four:

class TurnaroundCalculator
  def initialize(purchased_at, turnaround)
    @purchased_at = purchased_at
    @turnaround = turnaround
  end

  def calculate
    #snip
  end
end

Five:

class Quote < ActiveRecord::Base
  def pretty_turnaround
    TurnaroundCalculator.new(purchased_at, turnaround).calculate
  end
end

Done! We should be able to run our tests and see them pass. Even if ‘run our tests’ consists of manually checking it out…

So what’s the advantage here? Well, we now can start the refactoring process, but we’re in our own little clean room. We can extract methods into our TurnaroundCalcuator class without polluting Quote, we can write speedy tests for just the Calculator, and we’ve split out the idea of calculation into one place, where it can easily be changed later. Here’s our class, a few refactorings later:

class TurnaroundCalculator
  def calculate
    return "" if @turnaround.nil?

    "#{arrival_date} (#{days_from_today} business days from today)"
  end

  protected

  def arrival_date
    real_turnaround_time.strftime("%A %d %B")
  end

  def real_turnaround_time
    adjust_time_for_weekends(start_time + turnaround_in_seconds)
  end

  def adjust_time_for_weekends(time)
    if saturday?(time)
      time + 2 * 60 * 60 * 24
    elsif sunday?(time)
      time + 1 * 60 * 60 * 24
    else
      time
    end
  end

  def saturday?(time)
    time.strftime("%a") == "Sat"
  end

  def sunday?(time)
    time.strftime("%a") == "Sun"
  end

  def turnaround_in_seconds
    @turnaround * 60 * 60 * 24
  end

  def start_time
    @purchased_at or Time.now
  end

  def days_from_today
    if @purchased_at
      ((Time.now - @purchased_at.to_time) / 60 / 60 / 24).floor + 1
    else
      @turnaround + 1
    end
  end
end

Wow. This code I wrote three years ago isn’t perfect, but it’s almost understandable now. And each of the bits makes sense. This is after two or three waves of refactoring, which maybe I’ll cover in a separate post, becuase this was more illustrative than I thought… anyway, you get the idea. This is what I mean when I say that I shoot for roughly five-line methods in Ruby; if your code is well-factored, you can often get there.

This idea of extracting domain objects that are pure Ruby is even in Rails itself. Check out this route:

root :to => 'dashboard#index', :constraints => LoggedInConstraint

Huh? LoggedInConstraint?

class LoggedInConstraint
  def self.matches?(request)
    current_user
  end
end

Whoah. Yep. A domain object that describes our routing policy. Awesome. Also, validations, blatantly stolen from omgbloglol:

def SomeClass < ActiveRecord::Base
  validate :category_id, :proper_category => true
end

class ProperCategoryValidator < ActiveModel::EachValidator
  def validate_each(record, attribute, value)
    unless record.user.category_ids.include?(value)
      record.errors.add attribute, 'has bad category.'
    end
  end
end

This isn’t a plain Ruby class, but you get the idea.

Now, you might be thinking, “Steve: This isn’t just for Rails! You’ve lied!” Why yes, actually, you’ve caught me: this isn’t the secret to Rails OO, it’s more of a general OO design guideline. But there’s something special about Rails which seems to lure you into the trap of never breaking classes down. Maybe it’s that lib/ feels like such a junk drawer. Maybe it’s that the fifteen minute examples only ever include ActiveRecord models. Maybe it’s that more Rails apps than not are (WARNING: UNSUBSTANTIATED CLAIM ALERT) closed source than open, so we don’t have as many good examples to draw upon. (I have this hunch since Rails is often used to build sites for companies. Gems? Sure? My web app? Not so much. I have no stats to back this up, though.)

In summary: Extracting domain objects is good. They keep your tests fast, your code small, and make it easier to change things later. I have some more to say about this, specifically the “keeps test fast” part, but I’m already pushing it for length here. Until next time!

I'm making it dead simple to contribute to Ruby's documentation

Mon, 22 Aug 2011 00:00:00 GMT

Okay! So, if you’d read my previous article on this, you’d know how easy it is to contribute to Ruby’s Documentaiton.

But Steve, I’m still kinda scared.

Okay, so here we go: I’m making it even easier on you.

Send me what you want changed, and how, and I’ll make a patch and submit it on your behalf.

No, seriously, I will. I already did once. This guy posted something about how it was too hard, so I made a patch for him. And now Ruby is better because of it.

Patches don’t have to be patches

Seriously, I don’t even mean diff outputs. I just got this email:

> I'm eager to contribute docs but I don't know where to start: I don't
> mean pulling down the repo and all that, I mean, I see this link
> here:http://segment7.net/projects/ruby/documentation\_coverage.txt but
> all I see is a ton of "# is documented" comments. Where does a
> relative n00b begin? Poking around in the source code is, well,
> intimidating. I'm completely new to this but I take direction well.
> Just point me in the right direction. Just give me something to
> document, please!

I sent this back:

> No code diving needed! That's part of it. Let's do this: Find the documentation for one of your favorite methods. Here, I'll pick one: http://ruby-doc.org/core/classes/Array.html#M000278 okay, that looks okay, but look at compact!:
> 
> > Removes nil elements from the array. Returns nil if no changes were made, otherwise returns </i>ary</i>.
> 
> Why's that </i> there? Total screw-up.  For example. So, send me this email:
> 
> "Hey Steve-
> 
> Check out the docs for Array#compact!, here: http://ruby-doc.org/core/classes/Array.html#M000279 . There's an extra </i> that's screwing things up.
> 
> -Jonathan"
> 
> Done! I'll go from there. How about this one: 
> 
> "Hey Steve-
> 
> I checked out the docs for Time._load, here: http://www.ruby-doc.org/core/classes/Time.html#M000394
> 
> These docs kind of suck. What if I don't know what Marshal is? There should at _least_ be a link to Marshall, here: http://ruby-doc.org/core/classes/Marshal.html And it should probably say something like "You can get a dumped Time object by using _dump: http://www.ruby-doc.org/core/classes/Time.html#M000393 
> 
> - Jonathan"
> 
> I'm sure you can find something that's formatted wrong, or worded incorrectly, or anything else.
> 
> -Steve

Now, the closer it is to an actual patch, the faster I’ll be able to do it. A vague “this documentation is confusing, but I’m not sure why” is helpful, but will take longer. I’d rather get that email than not. If you’re not sure, hit send.

Just Do It

And so I’ll do it again. Scared to deal with doc patches? I’ll make them up. I’m serious. I’ll do it. Send them to me.

That’s all.

Send me patches. steve@steveklabnik.com. Do it.

Contributing to Ruby's documentation

Tue, 10 May 2011 00:00:00 GMT

Update!

I’m now making it even easier than this: Read my new post about how I’ll do this for you. That said, if you want to do it yourself, the following will tell you how.

Original Article

Ruby 1.9.3 is coming out soon! drbrain has challenged the Ruby community to improve its documentation, but some people were asking about how to do so. So I made a video!

Some small errata: drbrain has informed me that he should edit the Changelog, not me. So don’t do that. :)

How to contribute to Ruby’s documentation. from Steve Klabnik on Vimeo.

If you don’t want to watch me talk about it, here’s the same info, in text:

Getting the Ruby source is pretty easy. You can find it on GitHub, here: http://github.com/ruby/ruby . Click the “fork” button and clone down your own fork:

$ git clone git@github.com:YOURUSERNAME/ruby.git

After that’s done, type cd ruby and add the main project as an upstream. This will let you keep up-to-date with the latest changes:

$ git remote add upstream https://github.com/ruby/ruby.git

$ git fetch upstream

Okay! Now that you’re all set up, poke around and find something that needs documented. I like to just look through the source, but you can also look here for a list of things that have no docs. Documentation is written in rdoc, and I’d check the recent commits that drbrain has been making to guide you in style. This commit, for example, is a pretty good template. You can also check out the formatting guides here. There’s also this which explains some directives for .rb files and this which handles directives for .c files.

Now that you’ve made a change to the documentation, you can regenerate the docs by using rdoc. First, grab the latest version from rubygems:

$ gem install rdoc

Always best to have the latest tools. Now do this to generate the docs:

$ rdoc --o tmpdoc lib/rss*

I’m passing it in an output directory with op, since the doc directory is not an rdoc directory. rdoc will complain and refuse to overwrite those files, which is a good thing. I’m also passing in a pattern of what to compile documentation for, compiling all of it takes a few minutes! In this case, I chose to document the rss library.

Now you have a website in rdocout. Open up its index.html, and poke around for what you’ve changed. If it all looks good, you’re ready to make a patch!

$ rm -r tmpdoc

$ git add .

$ git commit -m "adding documentation for $SOMETHING"

Now, you have two options here. One is to simply push the change up to GitHub, and make a pull request.

$ git push origin

… aaand pull request. The core Ruby development doesn’t really happen on GitHub though, and so your patch may take a while to get included. If you really want to do it right, submit a patch to RedMine. We’ll use git to make this patch:

$ git format-patch HEAD~1

This says “make a patch out of the last commit.” It’ll tell you a file name, it should start with 000.

Now, sign up for the Ruby RedMine here. Once you’ve clicked the confirmation email, open a new ticket, and assign it to Eric Hodel, category DOC, and give it your Ruby version, even though it’s not a big deal here. Click ‘choose file’ and pick your patch, then ‘create and continue’ and BAM! You’re done!

Let’s all pitch in and make this the best documented Ruby release ever! In writing documentation, you might even find some things that you’d like to help improve. ;)

Did you hear? I'm Ruby Mendicant University's first visiting teacher

Fri, 18 Mar 2011 00:00:00 GMT

I’ve heard Ruby Mendicant University (also known as RMU, not to confuse you Robert Morris alums!) described as “the best kept secret of the Ruby community.” High praise, indeed. If you haven’t heard about RMU before, check out this presentation by Andrew Cox:

TL;DR: RMU is a free, online ‘unversity’ from Gregory Brown, author of ‘Ruby Best Practices.’ You enter an intermediate Rubyist, and you exit an expert.

Anyway, RMU recently announced that I’ll be their first visiting teacher. Basically, I’ll be hanging out, giving advice, and just generally being even more accessible to RMU students than I already am. Greg and I have talked a lot about education, Ruby, and a lot of other things… between Hackety’s ‘nothing to intermediate’ and RMU’s ‘intermediate to expert’ approaches to learning, anyone wanting to get up to speed with Ruby should have no shortage of resources at their disposal.

If you’re feeling like you’ve got the hang of Ruby, but want to take it to the next level, applications are open! Hopefully I’ll see you there.

Hackety Hack v1.0

Sat, 25 Dec 2010 00:00:00 GMT

It’s been a long journey. I have a lot to say about this, but it’ll have to wait until I’m not in the middle of nowhere spending some time with Maria’s family. I just wanted to tell you all Merry Christmas, and point you at the Hackety Hack v1.0 release announcement and the new Hackety Hack website.

Merry Christmas!

A word about _why, Whyday, and Hackety Hack

Thu, 19 Aug 2010 00:00:00 GMT

Today is Whyday. A programmer’s holiday. Today is the day that we don’t forget that programming isn’t all Agile and driven by behavior and Serious Business. Inside each cubicle, the hacker spirit is trying to burst free. Today, it will.

Today, I’m also releasing a prerelease version of Hackety Hack 1.0. It’s been a long time coming. The announcement of Whyday got me thinking about the past year of a world without _why, and the ‘your domain is about to expire’ notices got me thinking about how I’ve now been the head of the Hackety Hack project for almost 12 months, too. I don’t like thinking about this, because I almost let _why down.

I never met _why. I can’t really claim to know him, or know what his intentions were, but I think about him a lot. ‘_why’ the persona, really embodies everything that I love about software. The world owes _why a great debt, and I’d like to think that I’m doing what I can to repay him.

At least, I am now. I don’t like to think about roughly 6 or 8 months of the last year of Hackety Hack; I did an exceptionally poor job of being a steward. Being alone, having no help, and having a bit of an identity crisis is an excuse; you can decide if it’s a good or poor one. But things have been looking up, and we’ve got some momentum, I owe a great debt to Fela for helping make this summer happen.

I really do feel that the Little Coder still has a predicament, and I’m almost to the point where they can find some solace. I still feel that Hackety Hack could become an absolutely invauable project, I’ve just got to keep going. I can, I will, and I am. But I wouldn’t be able to if so many people didn’t care, say a nice world, or lend a hand.

So thanks. And as ashbb would say, “Let’s all have fun with Hackety Hack!”

Happy Whyday.

EDIT: The release is now out. See the announcement here, and get it here.

Thanks!

Writing a su feature with Authlogic

Fri, 05 Mar 2010 00:00:00 GMT

Sometimes, when responding to a support request, it’s nice to see what your users see. At the same time, you don’t want to ask your users for their passwords, out of respect for their privacy. So what do you do?

Well, *NIX systems have a program called su. Here’s what man su has to say:

NAME
       su - run a shell with substitute user and group IDs

SYNOPSIS
       su [OPTION]... [-] [USER [ARG]...]

DESCRIPTION
       Change the effective user id and group id to that of USER.

su can be thought of as “substitute user” or “switch user.” It’s a command system administrators use to assume the identity of one of their users, or a way for someone with the root password on the system to switch to the root account itself. So how can we incorporate this into a web application?

Well, we want to first log ourselves out, and then log in as the user we’re su-ing to. That’s it. The tricky part, however, comes in when we’re logging in: as we said before, we don’t want to ask for their password. Luckily, Authlogic provides a way to create our UserSession object directly from a User object by just passing it to create.

This lets us write a controller method to do this pretty easily:

def su
  @user = User.find params[:id]
  current_user_session.destroy
  UserSession.create!(@user)
  flash[:notice] = "You've been su-d to that user."
  redirect_to dashboard_path
end

Add in a route:

map.admin_su "/admin/su/:id", :controller => "admin", :action => "su"

And to a view somewhere in your administrative tools:

<%= link_to "log in as this user", admin_su_path(@user) %>

And we’re good to go!

One last thing about this, though: You don’t want to let anyone who’s not an administrator do this, for obvious reasons. My administrative controllers always include a block like this:

access_control do
  allow :admin
end

acl9 makes this really easy, but it’s really important.

So there you have it. Easy as pie.

EDIT: This post made the Rails subreddit, and brettbender posted his code to get you back to admin.

The Hackety Manifesto

Thu, 31 Dec 2009 00:00:00 GMT

For those of you that don’t know, I’ve taken over a project by someone named _why. He dropped off of the face of the Internet back in March, and the community has picked up his works. Because I’ll be writing about the project in the future, and because I feel these words are still relevant, I’m reprinting the two of his essays that led up to the creation of the project, Hackety Hack, here on my blog. Here’s the second one.

Enjoy.

The Hackety Manifesto

Nearly four years ago, I wrote an essay called The Little Coder’s Predicament. It’s not too unusual. Lots of others like it have been written. The point is: programming just isn’t available to people like it was with the Commodore 64. I also outlined my requirements for a new cross-platform programming environment for beginners.

The essay was widely linked on Slashdot, Reddit, Lambda, etc. I got lots of mail from people who both agreed and disagreed. Great. Nice. Good people all of them! And yet, nothing has changed. Not really!

I’ve been told of the Xbox development kit and possible programming of Wii channels. The Playstation actually had a language. But none if it has met my criteria for a proper coding platform.

An Aside: We Care, But Not Enough

So, why has nothing been done about this? Maybe our interpreters and IDEs (ewww…) are good enough? Lots of people wrote in to say that HTML and JavaScript are the new BASIC. NO!!! You can’t be serious!!! So people have to write two languages now, which are intertwined in an almost inexplicable and unfathomable way? This doesn’t do it.

Hello world should be one line.

In fact, downloading an MP3 should be one line!!

We just don’t care right now, do we? Programmers have a paid gig. So business is happily slurping them up. Look at our books. Look at the programming sites. Programming is tightly coupled to business. Often the first example is an e-commerce site! Our books are like FIFTY DOLLARS!! For crying out loud.

This diatribe isn’t about business being bad. Of course you need to feed your family and drive an Audi.

This diatribe is about adding some balance to the world of programming. Okay, so, let’s take things into our own hands and bring hacking to the young folks.

The Bylaws of Hackety

Here are the rules by which Hackety Hack was established:

Beginners should be greeted to Hackety Hack by a cartoon character. (For the sake of argument, let’s call this character: Hacky Mouse.)
Also, helpful sentences. Preferably short and with a period.
Hackety Hack is fundamentally a browser and a programming language. For now, Gecko and Ruby.
I’m only using Ruby because I know it. Hopefully, more languages can be added!
Again, this isn’t about Ruby, it’s about simply offering a place for plainspeople to tinker with code.
IDEs are a disaster. Newbs should see only one non-scary window free of tree controls and pinned windows and toolbars.
As such, we want to stay away from project files and makefiles, the trappings of an IDE.
Hackety Hack also adds simple libraries for common things.
Common things are one-liners.
Keep args and options to a minimum.
In Ruby, blocks should be used to open up a method to more advanced possibilities.
Help files are clean, short, simple. Lots of short examples. No frames.
While all bug tickets are helpful and great, I just value tickets from beginners to a greater degree.
Hackety Hack is free and will remain free henceforth.

Beyond that… anything which makes life easy and fun for Hackety Hackers is definitely encouraged, even demanded.

Steve Klabnik — Ruby & Rails

Docember

Rescuing Resque (again)

TL;DR

Make 1-x-stable master again

Fix up the test suite

Review Pending 1-x-stable PRs

Decide What to do with 2.0

Ember Data: ‘DS’ is not defined

Resque 1.25.0 has been released

CHANGES

INSTALLING

SOURCE

Beware subclassing Ruby core classes

Subclassing Review

The Problem

The Solution

Resque 1.25.0.pre has been released

CHANGES

INSTALLING

SOURCE

Removing Turbolinks from Rails 4

Rails 4.0.0-beta1 to Rails 4.0.0-rc1

Cookie Stores

Routes

Clean dbs

has_secure_password

Travis build matrix for Rails

Using puma on Heroku

Gemfile

Procfile

Other Rubies

Rails

I'm writing "Rails 4 in Action"!

Ruby on Rails maintenance policy

New Features

Bug fixes

Security issues:

Severe security issues:

Unsupported Release Series

Ember.js and accessibility

How to not rely on rubygems.org for development

Deploying with Bundler

Wait, I thought you said NO to Vendor Everything!!!

git

scp

One Tiny Weakness

An addendum

Draper 1.0.0 released

Rails has two default stacks

Dual Stack Ecology

Beginners lose out

Helping People Build Better Apps

Getting started with chruby

Features

Anti-Features

Installing

Usage

Getting more Rubies?

Automatic switching?

How good is it?

Draper 1.0.0.beta2 release

CHANGELOG

Draper 1.0.0.beta1 release

Introducing the rails-api project

What

A simpler stack

Consistent Javascript output

Authentication

JavaScript as a first-class citizen

Hypermedia

Where

Getting Started

Who

Run Rails with custom patches

Step 1: Fork you!

Step 2: apply patch

Step 3: update Gemfile

Step 4: Profit!

But I’m on 2.3, I’m not running Bundler!

Make `1-x-stable` master again

Review Pending `1-x-stable` PRs

`new` vs `initialize`