Monkey Patching Core Functionality == BAD, BAD, BAD 21

Posted by Kurt Schrader Fri, 25 Apr 2008 01:29:00 GMT

Yesterday, I finally got around to upgrading HAML in our Rails app to the newest stable version and the first thing that happened was that 20 completely unrelated specs broke.

Why, you may ask?

A monkey got into our code, that's why.

You see, Ruby allows you to redefine any method of any class on the fly (monkey patching) and it turns out that the old version of HAML had the following code in it:

  unless String.methods.include? 'old_comp'
  class String # :nodoc
    alias_method :old_comp, :<=>

    def <=>(other)
      if other.is_a? NilClass
        -1
      else
        old_comp(other)
      end
    end
  end

  class NilClass # :nodoc:
    include Comparable

    def <=>(other)
      other.nil? ? 0 : 1
    end
  end
end

This, in turn, snuck into our codebase in all sorts of little unexpected places. In one instance a test was comparing sorted Arrays of nils and returning true. Not good.

Luckily, in all of our cases this ended up being more of an irritant than anything else, but I can easily imagine any number of ways in which relying on the assumed behavior of these methods could have broken our app in any number of subtle and terrible ways.

So I'm only going to say this once:

Don't modify core Ruby functionality in your plugins or Rubygems.

You will break your users' codebase.

If you do modify core functionality you deserve to be slapped around by those around you.

Startup School, DHH, and the Missing Marketing Piece 7

Posted by Kurt Schrader Mon, 21 Apr 2008 18:03:00 GMT

If you weren't at Startup School this weekend or haven't watched DHH's speech yet, you should go check it out. It was entertaining and a good counter-point to much of the ridiculous talk that you hear out here in the Valley.

As I was watching it though, I had the same thought that I always seem to have when I hear someone from 37 Signals talk, and it came to me right when I saw the slide that said:

  1. Great Application
  2. Price
  3. Profit!

If only it were that easy. The thing that these guys always leave out seems to be step 1.5:

Market the hell out of your product, and get a bunch of people to use it.

That step is really, really hard.

I bet that if you asked DHH if he thought that 37 Signals would be just as successful if he hadn't invented Rails, and without the flood of free publicity that that got them, and he answered truthfully, the answer would be "no".

There are probably all sorts of great applications out there that would help me out on a daily basis, but I have little to no time to try out most of them. I've tried out Basecamp though, simply because while learning Rails you hear again and again about how Rails was extracted from it.

Would I (or you) know anything about 37 Signals if it wasn't for Rails? Probably not.

Those guys do a great job of marketing themselves and getting things out in front of people, but just because you're having fun marketing your stuff, doesn't mean that marketing isn't work that you have to do.

If you think that you don't have to market your app, no matter how great it is, you're living in a world similar to the one that DHH had on one his final slides where he said:

500 * $40 = $125,000

That's right, an imaginary world.

Rails is Moving to Git: Helpful Links For New Git Users 1

Posted by Kurt Schrader Thu, 03 Apr 2008 01:30:00 GMT

With the news today that Rails is moving from Subversion to Git, here are some helpful links for those of you that have never used Git before:

Feel free to add more in the comments and I'll update the list above as they come in.