Jon Leighton

Rails controllers and OOP

2012-04-19T22:00:00Z

This realisation lead me to experiment with altering the conventions for controller code, and today I gave a talk on the topic at Railsberry called You Hate Your Codebase & It’s Your Fault.

I wrote a plugin named Focused Controller a while back, as part of this experiment, but have kept quiet about it until now, partly because it was undocumented.

But now I’m ready to announce it and I’m really keen for people to try it out and share their thoughts about this idea. I’ve gone into detail about the problems and solutions in the README, so I won’t repeat that here. Please just check it out!

Poltergeist 0.6.0: Javascript error handling and remote debugging

2012-04-14T22:00:00Z

My goal with Poltergeist is to create the fastest and best Capybara driver. A common problem when using Capybara, particularly when using a headless driver, is debugging. To be the best driver, Poltergeist needs to be the easiest to debug.

Javascript errors

Prior to 0.6.0, Poltergeist had rudimentary support for detecting Javascript errors on the page, but it was impossible to report the stack trace for these errors. This stems from a lack of support for reporting stack traces in QtWebKit, which PhantomJS is based on. This problem affects capybara-webkit too.

PhantomJS 1.5 was recently released, and prior to the release I worked hard to add stack trace support there. This was a pretty hard task and involved diving deep into WebKit’s source, but I got there eventually.

Poltergeist 0.6.0 updates the PhantomJS dependency to 1.5, and so I am happy to say that if there is a Javascript error in your page (or in Poltergeist’s Javascript code), the error will trigger an exception in your Capybara test, and you’ll see a full stack trace showing where it happened.

To my knowledge, Poltergeist is the first Capybara driver to support Javascript error handling at this level.

Remote debugging

You may have heard of the ‘remote debugging’ feature in Safari or Chrome. Essentially remote debugging means that your browser can run a WebSocket API on a given port, and then another browser (possibly on a completely different computer) can connect to it and use a Web Inspector to interact with the page.

This feature is actually a feature of WebKit which means that PhantomJS, being built on WebKit, can have remote debugging too. I’m sure you’ve guessed by now where this is going, so yes, Poltergeist 0.6.0 supports remote debugging.

There is an important caveat. It has been reported that remote debugging in PhantomJS doesn’t work on OS X. I don’t own a Mac, so it’s hard for me to confirm this problem or debug it myself. For now all I can say is that I have used the remote debugging feature successfully on Linux, and I would be delighted if somebody wants to step up and work out how to fix it on OS X.

Here’s how it works:

If you setup Poltergeist with the :inspector => true option (see the docs for details), PhantomJS will get set up in remote debugging mode. Note that due to internal WebKit reasons, we can’t report Javascript stack traces in this mode (but that’s okay, because you can see the stack traces in your inspector window).

With the inspector enabled, you can insert page.driver.debug into your test. This will pause the test and launch a browser window with two links. The first one is the “page” that PhantomJS runs its script in (don’t worry about this).

The second one is the one you want. Click on it and you’ll see a web inspector - this should look familiar. You can now add breakpoints to your code, or inspect the DOM, or whatever. When you’re read press return in the console and your test will continue. If you want to pause it again, just add page.driver.pause.

How to prevent Ruby's test/unit library from autorunning your tests

2012-02-18T23:00:00Z

test/unit installs an at_exit hook which runs all the tests before Ruby exits. This was problematic, because it meant that all the tests ran after perftools had already finished its profile.

So I wanted to turn off the autorunning and explicitly run the test suite. I found out how to monkey-patch test/unit to achieve this, and figured it might be useful to someone in the future, so:

Ruby 1.9

require 'test/unit'

class Test::Unit::Runner
  @@stop_auto_run = true
end

class FooTest < Test::Unit::TestCase
  def test_foo
    assert true
  end
end

Test::Unit::Runner.new.run(ARGV)

Ruby 1.8

require 'test/unit'

module Test::Unit
  def self.run?; true; end
end

class FooTest < Test::Unit::TestCase
  def test_foo
    assert true
  end
end

Test::Unit::AutoRunner.run

Tracking down method definitions in Ruby

2012-02-18T23:00:00Z

A trick that I often use is to get a Method object for the method that I want to find, and then to print out its location. Like this:

class Foo
  def bar
    "omg, where am I?"
  end
end

p Foo.new.method(:bar).source_location # found you!

Recently I was trying to find out where the #flash method of ActionDispatch::TestRequest was defined. It’s not defined in the main files that contain the definitions for ActionDispatch::TestRequest or ActionDispatch::Request (which is the superclass).

So I pulled out my standard tool:

r = ActionDispatch::TestRequest.new
p r.method(:flash).source_location

It didn’t work:

ArgumentError: wrong number of arguments (1 for 0)

It turns out that ActionDispatch::Request has its own method method, which relates to the HTTP method. Hence Ruby’s method method is overridden.

However, all was not lost! Ruby also makes it possible to get a reference to a method definition that isn’t bound to any particular object. This is called an UnboundMethod, and you can’t call it until you bind it to some object. So I was able to get an unbound reference to the original method method and then bind it to my object. Like so:

r = ActionDispatch::TestRequest.new
meth = Object.instance_method(:method)
p meth.bind(r).call(:flash).source_location # found it!

It turns out that the Request class is reopened in actionpack/lib/action_dispatch/middleware/flash.rb and the flash method gets defined there.

Hashes and encapsulation

2012-01-08T23:00:00Z

Then Josh, not realising that I was simply casting judgement down from my ivory tower, asked for more than 140 characters worth of explanation:

So, I agreed. Here is that explanation.

Suppose you have an object representing a DOM element. DOM elements have attributes, which you store as a hash. Something like this:

class DOMElement
  attr_reader :attributes

  def initialize
    # ...
    @attributes = Hash[parse_attributes.map { |name, value|
      [name, DOMAttribute.new(name, value)]
    }]
  end
end

In your code that uses DOMElement, you access an attribute like this:

element.attributes['margin-left']

If you try to access an attribute that does not exist, nil will be returned.

Later on, you realise that you are checking for nil in lots of places where you use attributes. Listening to the code smell, you decide that missing attributes should instead return a null object.

What do you do? Well, your only option is to add a default proc to the Hash:

@attributes = Hash[parse_attributes.map { |name, value|
  [name, DOMAttribute.new(name, value)]
}]
@attributes.default_proc = proc { NullDOMAttributes.new }

You have now made your object impossible to marshal without using insane hackery, since procs cannot be marshalled.

The more important point, though, is that by allowing users to dip into the @attributes hash like this, you are failing to encapsulate the internal implementation of your DOMElement object.

This presents another problem: an unrelated dodgy bit of code could remove an attribute from the element, without your DOMElement object realising!

el.attributes.delete('margin-left')

If you pass around the same hash between lots of different objects, that hash is quite likely to get mutated at some point in my experience, and when that happens it will affect all the other objects relying on it.

Yes, you could call @attributes.dup every time the attributes method is called, but that’s hardly very efficient when we only want to get at a single attribute.

If the code had been written in an encapsulated manner to begin with:

class DOMElement
  def initialize
    # ...
    @attributes = Hash[parse_attributes.map { |name, value|
      [name, DOMAttribute.new(name, value)]
    }]
  end

  def attributes
    @attributes.dup
  end

  def attribute(name)
    @attributes[name]
  end
end

It would be straightforward to add the null object without further consequences:

def attribute(name)
  @attributes.fetch(name) { NullDOMElement.new }
end

So, exposing internal hashes can be convenient, but you should always think twice before doing so and realise that you might regret the decision at a later date.