Schrade.Blog

It seems like every time I post something bad about a programming language, or compare one language (A) to another (B), at least one commenter lets me know that they like language B better, and furthermore, some aspect of my post has convinced them that language A is so bad that they won't even try it anymore.

The thing is, I don't care.

I'm not a consultant anymore. I'm not trying to sell you anything (unless you need drug discovery software). I'm no longer actively involved in open source community. If you don't want to ever try Ruby (or Smalltalk, or Python, or whatever) it really doesn't matter to me.

When I point out something about a language, I'm just doing it because I genuinely think that it is better than something else.

So how do I really feel about languages?

Well, over the last couple of months I've written code in Ruby, Smalltalk, Javascript, Python (if you haven't read Programming Collective Intelligence you should), Java, and even PHP (SearchMonkey is seriously cool, if you haven't checked it out).

So what language do I think that you should program in?

All of the above, and as many more as possible.

Learn about functional programming. And iterator methods. And closures And continuations.

Even more importantly (from my selfish point of view), learn about things that other programming languages can do that I don't know about.

Then hopefully someday we'll be able to have a discussion about programming languages without resorting to pointless statements like "I still prefer braces over keywords for blocks" and instead we'll get comments that we can all learn something from.

While reading yet another article on why PHP Sucks (today's witty twist, "but It Doesn't Matter") I realized yet another reason that I'm glad to be programming in Ruby.

Ruby, to me, is like a big open playground, while languages like PHP remind me of big industrial factories. I don't think that any of us would argue that industrial factories are more efficient for most things, but they also suck the creativity and life out of the people working in them.

For instance, why would you ever want to write code like this:

class DescribeNewBowlingGame extends PHPSpec_Context
{
    private $_bowling = null;
    public function before()
    {
        $this->_bowling = new Bowling;
    }

    public function itShouldScore0ForGutterGame()
    {
        for ($i=1; $i<=20; $i++) {
            $this->_bowling->hit(0); // someone is really bad at bowling!
        }       $this->spec($this->_bowling->score)->should->equal(0);
    }

}

when instead you can write this:

describe Bowling do
  before(:each) do
    @bowling = Bowling.new
  end

  it "should score 0 for gutter game" do
    20.times { @bowling.hit(0) }
    @bowling.score.should == 0
  end
end

You wouldn't. The first case is, at best, a bastard representation of the second case.

Of course, being out on the playground means that people get hit in the face with a ball once in a while, and everything isn't as neatly laid out for you as it is in a factory, but you also have the option to be creative, and not just do things like everyone else does.

And, sure, the playground is far more full of assholes than the factory, but these assholes are also more creative and entertaining to work with than people who just put widgets in place in a factory.

Plus the playground has that weird kid in the corner who's doing something totally crazy, but that just might be a genius, and if you get enough of these kids together, you're going to produce something that's much cooler and more creative than anything that gets built in a factory.

So you can talk all you want about big boring websites being written in PHP (or Java, etc).

As for me, I'll keep working in a language that encourages people to be creative.

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.

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.

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:

• Git homepage
• An introduction to git-svn for Subversion/SVK users and deserters
• Git for Computer Scientists
• Braid (A Piston clone for Git)
• Git Sake Tasks (Rake tasks for performing git operations)
• The Power of Git: git stash
• The Power of Git, Part 2

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

The hard drive on Macbook Pro died again the yesterday, so I had it in to my friendly neighborhood Apple Store to replace it once again.

Luckily, I was fully backed up through Time Machine this time, and when I got my machine back last night (note to self: always go to the flagship Apple store for repairs, they get your machine back to you much faster than other Apple stores) and started it up, one of the new options during setup was "Restore from Time Machine Backup". I chose that option, plugged in my disk, and when I woke up this morning my machine was back in exactly the same state that it was the day before.

That's not all though, it appears as one of the unexpected side effects of doing this is to clear out all of the temporary and log files that have built up over the last year or so. I went from 18 gigs of free space to over 30 gigs of free space just by going through the restore process.

So now I'm thinking that I might do just do a full reinstall of OS X and restore from Time Machine a couple of times a year to repeat this process. So far I haven't seen any downsides. Everything that I use in a normal day seems to be working perfectly (and actually, some things are going faster, I'm assuming because whatever trail of temp files they create over time has been cleaned up). If your machine is running slow or is low on space, doing a reinstall and a restore might be worth a try.

Whenever I start a new Rails project, one of the first things I do is install Rspec and delete the Rails default test directory. Even with that directory missing, however, Rails continues to waste my time by trying to run its various testing tasks.

To make it stop, just add the following:

Rake::Task[:default].prerequisites.clear
task :default => :spec

to the bottom of the Rakefile in the root application directory.

Obviously, if you want to have a default task other than spec, just change the right side of the second line to whatever task you want it to run.

At CDD we use Selenium RC and spec_selenium to run our acceptance tests. Selenium is a slow way to test in general, but lately for us it's become excruciatingly painful.

For some some unknown reason under Leopard, our tests would seem to randomly slow to a crawl. Tests that usually take 4 seconds to run would suddenly be taking 170+ seconds.

Even worse, this would persist across reboots, and then suddenly go away while we were trying to diagnose the problem.

It was at the point this morning where we were using DTrace to try to figure out what was going on.

Luckily, it doesn't seem to have anything to do with our code, and it looks like I've solved it (or at least worked around it) for now.

Selenium RC communicates over network sockets. It appears that Ruby network communication performance under Leopard is, in a word, terrible.

This problem can be most easily seen when doing a 'gem update' and then waiting forever while the metadata updates.

There seems to be a problem with DNS resolution somewhere in the chain that pops up intermittently.

For now, our workaround is:

1. Turn off IPv6
2. Use OpenDNS for lookups.

as suggested by the Ruby Forum thread linked above. That seems to fix things on all of our machines here.

I would file a bug report for this, but I'm not sure if this is a Ruby thing or an OS X thing. If anyone can shed some further light on this issue it would be appreciated.

I'm announcing today that I've decided to run for US Congress!

No, not really, but someone else named Kurt Schrader is.

This, however, is a blog about Ruby and internet startups.

Welcome.

Please read this book before continuing.

And if you live in Oregon, vote for that guy. He's got a name you can trust.

My friend Jay wrote a blog post today that says that you can use 'svn patch' as poor man's replacement for git-stash. Fair enough, I've heard of places that use patch as full-on replacement for source control and integration as well. :-)

First of all, I want to point out that we still use Subversion as our main code ghetto at work.

Git fully supports updating from svn and pushing changes back, so even if you have to use Subversion at work, you don't have to use it on your local machine.

The difference is that I have our entire history of source code commits on my machine in not even twice the space than it takes for my Subversion checkout (969M vs 578M). I also can do fast local branching and checkins, without worrying about being connected to the network.

Here's a real example of how we used git today at work that I never would have done with Subversion.

I started working on a feature yesterday on my laptop that is going to take a few days to finish. When I got to work today I decided to pair with my coworker Krishna to continue working on it.

In the pre-git world we would have had to either huddle around my laptop, check in the broken code to Subversion to check it out on our other machine, or do a patch of just the changes related to that feature and transfer it to and apply it on the pairing machine.

Not today though. Today I just fired up git-daemon on my machine and did a 'git pull' of the feature branch onto the pairing machine. At the end of the day I just did a 'git push' back to my machine to get all of the changes we made today back so that I could continue working on it tonight.

Even better than that though, I can not continue working on it tonight.

Git makes branching and merging so fast and easy that I can rewind all of the changes that I've made to the code base to support that feature, fix a showstopper bug, check that change into the subversion repo, and then merge the feature branch back on top without even worrying about it.

Git is starting to change the way that I do development. I can finally use branches the way that I've always wanted to. I can finally have several features in development at once on different branches, because it's so easy to switch and merge between them.

Even if you're stuck with Subversion as your backbone, you can still grow outside of it.