Why don't I pair more?

I've been watching a video of the hashrocket guys just now that Corey Haines twittered about. I've been amazed and inspired by Corey's pair programming tour: talk about turning lemons into lemonade. What an awesome idea. I've paired with Corey on some open source stuff at conferences, so I naturally wanted to get in on his tour. As a result I had the good fortune to have Corey stay with me on his tour. Unfortunately the timing of his stop happened on a day I had to spend dealing with client issues and didn't get to spend time pairing with him. And this leads into my topic: Why don't I pair more?

This isn't another post about why pair programming doesn't work, isn't a good idea, or any other such nonsense. I'm a true believer in pair programming. I've been sold on the concept since I first read about it in the first edition of Kent Beck's Extreme Programming late in the prior millenium. I've experienced pair programming and so I know the benefits first hand:

• It consistently produces the best code, the code I'm proudest of in my entire career. And not a little prouder of. I mean, like, an order of magnitude more proud of.
• I'm operating at about twice the velocity I would normally, which is a rush, and incidentally, means there is no negative effect on team velocity. I've actually measured this on a real project.
• I learn way more
• I enjoy my job way more

And on an on. But that's not what I actually want to talk about. This post is a way for me to put down in writing the reasons that I don't pair nearly as much as I want to. I'm doing this chiefly as an exercise so I can better understand the issues and change them. If it helps someone else, hey, that's pure bonus. The first few are about me. Which is good news, because it means I can change them.

1. Part of me is afraid to
   I'll just go ahead and lead with this one since it's the hardest to talk about. I really like how the hashrocket guy put it: "Pairing is a burning crucible". Heat reveals impurities and exposes the true nature of things. If I'm having a self-doubting, insecure kind of day, I might not want this. Intellectually I'm totally convinced this is BS and the benefits far outweigh the minor pain of revealing what's obvious to everyone: I don't know everything. I like to think this reason is not a major factor preventing me from pairing, but in the interest of self-disclosure I'm putting it out there.
2. But I might not get my stuff done
   This one is a bit more insidious, but like the prior reason begins with self-centered fear. If I pair on your task, I might not get mine done. And conversely if you help me you might not get yours done. There are at least two ways to address this. The first is to get over it: I believe that the software I produce will be way better if I pair. And obviously producing better software is what's best for me and whoever I work for. I have to be clear on this and act on it, which in my experience is not always easy. And of course the other members of my team do as well.
   The other way to fix this is organizationally: don't assign tasks to individuals. I've been in situations where this was out of my control. Some clients like having a single "go to" person for a given feature or issue. But this doesn't have to stop pair programming if the team doesn't let it.
   
3. Inertia
   This one is a little more nebulous but I don't think it's less real. Sometimes I don't pair because I don't put forth enough effort to find someone to pair with. Other times I might be "in the middle of something". Either of these fall into the same general category of inertia: an object at rest (me, by myself, in front of my computer) tends to stay at rest.

The next few are harder to change, because they are about other people. Obviously I can't pair program if no one will pair with me. And no matter how much I would like to and am sure I know what's best for them, I can't actually control other people. But I'm going to list these issues anyways in the hopes that solutions will become clearer if we understand the problems.

1. Odd number of people on your team
   This is so obvious an issue it seems silly to put down, but I've seen it make a big impact. I know the song says "One is the loneliest number" but three is also not very good. What tends to happen is pairing becomes awkward as one gal or guy is left out and sometimes leads to little or no pairing at all. I suppose you could address this by making a pair your smallest unit of staffing a project. But it's also true that even if you have 3 people on your team you could still pair 2/3 of the time if you are intentional about it.
2. Distributed team
   Remote pair programming is a whole nother topic and I have some experience with it that perhaps I'll share in another post. Suffice to say: it's not as good as pairing in person, but better than not pairing at all. Because there are some technical details to work out and do, there is that much more barrier to overcome and it requires even more sustained effort to keep up.
   
3. They won't let me
   This is supposed to be the elephant in the room: management won't let me pair program. My thinking is that this one is mostly a myth. I've worked in a lot of places, some of them quite draconian. The truth however is that pair programming can start so innocuously that it's hard to have a mandate against it. Imagine management saying: you're not allowed to help other people. Even the pointiest of pointy haired bosses would see how stupid that is. I'm sure someone will comment that "No, that really does happen". Fine. I just don't think it's all that common. Most people, in my experience, actually do want to be useful and contribute something positive. They just may (wildly) disagree about how best to do so.
4. They code in X and X sucks
   This one requires compromise, but can be a a positive sometimes if you let it. My first ruby project I got to pair with my friend Jim, a dedicated emacs guy. As a result I had to learn emacs, something which I probably wouldn't have decided to do if I hadn't see what a productive environment it is first hand. There are other times where I pair with someone and they use something and even after trying it I still think it sucks. In that situation I try to get them to always pair on my machine. Err, I mean, switch back and forth between each others machines in the interest of fairness ;)
   
5. No one wants to pair (except me)
   Alas, this has been the hardest to solve. You can be fortunate enough to work for (or start) a company that mandates pair programming. Or else you can attempt to influence people. My only advice, based on experience, is that less is more. Don't talk about pair programming at all, just offer to help people. And then ask for help when you're stuck. I've sadly tried the approach of trying to convert people to pair programming, unit testing, or any other number of quite good ideas by incessantly talking to people about them. Don't do this.
   

Announcing Edit Me: a teeny weeny CMS plugin for Rails

I've been working for awhile on Rails plugin that makes it easy for users to edit their own content. I started it to scratch an itch I've had for a long time. The problem I have with most CMS systems is that they want run your whole site. Sometimes this is ok, but a lot of times you have a rails app where you have pieces of it that it would be nice to to let your client edit for example. For those cases, the edit_me plugin is your friend.

The idea is pretty simple: when in editing mode, edit_me gives you an edit icon next to the content produced by rhtml and html.erb files (you can configure which files you want to be editable). Click the edit icon and up pops an editor (using wymeditor). Save your changes and the page reloads with your changes. Edit me assumes you're using git (why wouldn't you?) and lets your roll back your changes in the History tab of the editor.

To check it out, head on over to http://github.com/superchris/edit_me/tree/master and follow the instructions in the README.

"Fun" with Hook Methods in Ruby

I've been wrestling with what turned out to be a rather interesting issue involving ruby hook methods. I don't yet have a solution to the problem but perhaps the activity of describing the problem in writing will illuminate a solution. Hook methods in ruby are callback methods you can implement in your code to get notified at interesting points in the lifecycle of a ruby object. The one which caused trouble in my case is inherited. By implementing the inherited method in a class you can get called back when another class inherits from it. It's quite useful when you want to do something like record each descendant of a given class, for example.

I ran into an issue with inherited while trying to understand a very strange behaviour in my IDE of choice, NetBeans. When running my rails test cases from NetBeans, I noticed they were not transactional, but when run on the command line they were. After sending a flame-o-gram which I will soon need to retract to the nb ruby mailing list, I decided to poke around in their code. I finally narrowed the problem down to their testrunner code.

In the newest version of NetBeans they have added a nicer ruby testrunner. In order to provide some features this new testrunner keeps track of all descendants of Test::Unit::TestCase. It does this, by, you guessed it, using the inherited method. When I delved into this code the first problem I saw was pretty obvious. The author had violated what I will now credit my friend Jim by referring to as Weirich's Hook Method Implementation Commandment:

Thou Shalt Always Delegate to the Previous Implementation

The reason this is important is that when you implement a hook method, you can easily step on someone else who had implemented it for another reason. Using the rails alias_method_chain will normally take care of this for you, but because this code loads before rails they didn't have that option and had not done the right thing and delegated explicitly.

And sure enough, I noticed that when I commented out the inherited method in the testrunner my tests became transactional. I figured at this point I had it licked. I went ahead and changed the NB testrunner code to delegate correctly and tried again. Sadly, it had no affect on the transactional issue. Much head scratching ensued. After many hours of investigation, I finally tracked down the real problem. I noticed that the use_transactional_fixtures class attribute of Test::Unit::TestCase was not being set. This led me to investigate how class_inheritable_attributes works in rails. Eventually I was able to put together a failing test case which expresses the problem. Here it is:

require File.dirname(__FILE__) + '/inheritable_accessor'
require File.dirname(__FILE__) + '/../test_helper'

class A
  class_inheritable_accessor :foo
  self.foo = "bar"
end

class B < A

end

class InheritableAttributesTest < Test::Unit::TestCase

  def test_foo
    assert_equal "bar", B.foo
  end
end

And here what's in inheritable_accessor.rb:

class A
  class << self
    alias_method :a_old_inherited, :inherited
    
    def inherited(base)
      puts "A inherited"
      a_old_inherited(base)
    end
  end
end

To try this at home, simply make a new rails project and drop these two files into your test/units directory. It should fail. But why? The inherited method does delegates to the previous implementation correctly, right? Now try switching the order of those two require statements. Poof, it passes.

Turns out the problem happens because of how class_inheritable_accessor is implemented. As you probably have guessed, it uses inherited. And yes, it does correctly delegate to the previous implementation. But it's where its implemented that is the problem: in order to let all classes be able to use this method, it's implemented on Class. However, there is an unfortunate side effect to this decision: it breaks for any class loaded before this code which itself defines inherited. In our example, the A class defines the inherited method before the rails code is loaded. But since the A class extends the Class class it's definition of inherited overrides the version rails adds to Class. The net outcome is that for the A class, and any class loaded before rails that defines inherited, class_inheritable_accessor is broken.

What's the right way to fix this? I'm not honestly sure. It could be that in order to do something like this which effectively adds a feature to the language, you need to be loaded first. On the flip side, it could be considered a bug that class_inheritable_accessor is broken in cases like this. Well, I had hoped that by the time I got this point in the post a clear solution would emerge. I suppose I'll have to leave it, as they say, as an exercise for the reader :)

Update: I was about to post this, and I went to grab some dinner and finally realized the solution: A still does not entirely obey Weirich's law. It correctly delegates to a previous implementation in the same class, but not to the superclass. A call to super at the end of the inherited method causes the test to pass. Adding the super call to the NB test runner code also causes my tests to be transactional again. Yay!

Ruby in the browser at Rubyconf

Just got the news this week that my submission on ruby in the browser, has been accepted for Rubyconf. This looks like an awesome conference and I am really psyched to be included. It is also inspiring me to do some more work on rubyjs_on_rails and try to finish up an activeresource client. I'll be hacking on that in whatever free time I have available this weekend.

I'm also thrilled that I get to be part of another dialogue session with Joe O'Brien and Jim Weirich. This session will be a similar format to our railsconf dialogue which seemed to go over pretty well. It's always a ton of fun to collaborate with these two phenomenal guys.

rubyjs_on_rails hackfest at erubycon

I had a really fun time hacking on rubyjs at eRubycon. It's amazing how much more fun and productive it is to hack with someone else than by yourself. Thanks to Corey Haines for staying up late at the hotel being my hacking buddy. As a result, we now have what will be the beginning of an ActiveResource client for rubyjs_on_rails. I generated a simple scaffold resource example called Customer with a few fields. I then created a Customer class in the view and started getting it to speak restfully with rails. Here's the result:

require 'dom_element'
require 'json'
require 'rwt/HTTPRequest'

class Customer
  
  
  attr_accessor :attributes
  
  def initialize(attrs)
    @attributes = attrs
  end
  
  def method_missing(method, *args)
    if method =~ /(.*)=$/
      attributes[$1] = args[0]
    elsif attributes[method]
      attributes[method]
    else
      super
    end
  end
  
  def self.main
    @name = DOMElement.find("name")
    @address = DOMElement.find("address")
    find_button = DOMElement.find("choose_customer_button")
    save_button = DOMElement.find("save_button")
    customer_id_text = DOMElement.find("customer_id")
    
    find_button.observe("click") do |event|
      Customer.find(customer_id_text["value"]) do |customer|
        @name["value"] = customer.name
        @address["value"] = customer.address
        @customer = customer
      end
    end
    
    save_button.observe("click") do |event|
      @customer.name = @name["value"]
      @customer.address = @address["value"]
      @customer.save
    end
    
    rescue StandardError => ex
      puts ex
  end
  
  def self.find(id)
    HTTPRequest.asyncGet "/customers/#{id}.json" do |json|
      hash = JSON.load(json)
      yield Customer.new(hash["customer"])
    end    
  end
  
  def save
    request_json = {:customer => attributes}.to_json
    HTTPRequest.asyncImpl "/customers/#{id}.json", "PUT", request_json, "application/json" do |json|
      self.attributes = JSON.load(json)
    end
  end
  
  def to_json
    attributes.to_json
  end
end

The first part I did was find. I've had that done for a couple weeks. This was super easy because rubyjs and rails support json so easily. The only odd bit is that it takes a block instead of returning a result. This is because the find call does an ajax request, and the a in ajax stands for.. you guessed it, asynchronous. Passing a block in makes it nice and simple to handle the result easily though.

The part I got working at rubycon was the save. This proved to be much easier than I thought it would be as well due to rails now supporting json updates natively. The controller code doesn't even need to be aware that the parameters are coming in as json, you can access param[:customer] the same as you would if it was coming from a normal form submission. I had to be sure and specify it was a PUT request when I sent it in, which I didn't realize was as straightforward to do as it is. I monkeyed around with a _method param and all sorts of stuff before realizing I could just tell the HTTPRequest object what kind of request I wanted to make. Duh.

Though this is a specific example right now, I think a large portion of this code should be easy to extract out into an ActiveResouce client base class. I haven't had any more time to hack on this since erubycon, sadly, but this is what I'll be focusing on when next I do. Also, I just now put up a new repo on github to hold this and any other rubyjs_on_rails example code: git://github.com/superchris/rubyjs_rails_example.git. Enjoy!

Announcing rubyjs_on_rails: ARAX sans silverlight

So maybe you're like me: sure javascript is nice and all but you really like ruby better. And as we move toward richer web apps, there are times it sure would be nice to write some of the client side code in ruby. Along comes M$ with their sexy silverlight DLR magic to make it happen. But you're suspicious: it requires a browser plugin, and can you really trust that it will be there on all the platforms you want to support. Sure, maybe M$ has learned how to play nice and it will be different this time. Maybe.

Well, you can quit holding your breath and exhale, girls and boys. You can write ruby code that runs in the browser right now. Today. No plugin or nuthin. So here's how. First, you'll need my forked version of the rubyjs ruby to javascript compiler. It's a little like GWT for you Java folk. Get it here. Sorry, until githubs gem building process decides to show me some love you'll need to download and install it locally with:

gem install --local rubyjs-0.8.1.gem

Next, you take standard rails app and install my superfantastic* rubyjs_on_rails plugin like so:

script/plugin install git://github.com/superchris/rubyjs_on_rails.git

So what did you get? Well, basically, one measly helper method. Sad, huh. Hey! Don't judge me! Cool your jets and let's see what it does already. First make a rails controller with a single action. Any old action will do, but let's imagine it's called hello. Go find hello.html.erb and put a single button button that doesn't do anything in it like so:

<input type="button" id="button" value="Say Hello">

Now let's write some ruby code to respond to the button click. Make a file called hello.rb in the same directory as your view and put this in it:

require 'dom_element'

class Hello
 def self.main
   button = DOMElement.find("button")
   button.observe("click") { puts "Hello from rubyjs!"}
 end
end

DOMElement is a class provided by the rubyjs gem that makes it easy to, surprise surprise, work with dom elements. In our case we just use it to grab hold of our button and observe the click event with a block of ruby code. Kind of cool I think.

But how to get this code into the brower? You remember earlier when I said all this plugin gives you is one measly helper method and you were all "Meh. I am sooo not impressed." Well now let's see it in action. Add this to your view right below the the button:

<%= rubyjs "Hello", "main" %>

Now hit this action in your browser. Click the button and you'll see your ruby block fire. The rubyjs helper method goes and finds hello.rb, compiles into javascript, and outputs a script tag to serve it up. The arguments to it are the class name and and a class method to invoke. It needs to be a class method; As this is the entry point to the code there is no instance yet to invoke methods on.

So that's it. Ruby running in the browser. You're welcome.

*Your superfasticalness may vary. No actual superfantasticness is either expressed nor implied by this blog post

eRubyCon: Be There!

Just a quick little post to get the word out to my readers about eRubyCon in Columbus, OH Aug. 15-17th. It's shaping up to be an awesome conference. And the early bird rate makes it the best conference deal I've ever heard of. Heck, even the post early bird rate makes it the best conference deal I've ever heard of. So register already. You know you wanna.