Schrade.Blog

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.

I converted my Subversion repository at work to a git repository recently, and today I had my first real "aha" moment.

I was working on a feature this morning when I realized that some code I checked in about an hour before had broken the build. In the old Subversion world, I would have needed to keep track of what I was changing to fix the bug, and then make sure to just check that in to ensure that none of my half-finished new feature got into the trunk.

Not anymore. Today I just did a:

git-stash

and it stashed away all of my changes in a temporary branch. Then I fixed the build, checked in my fix out main Subversion repo (using git-svn), and did a:

git-stash apply

to unroll my earlier changes back on top of the now fixed code. It's not the world's biggest saving of time, but it's one less thing that I needed to think about during development, and using git I'm seeing more and more little things that are starting to add up to a big change in the way I'm doing development.

Whenever I get I get tired of dealing with all of the disconnected layers of Rails, I think about how I should really write a decent component architecture that works well on top of it. Luckily, someone has already done it for me.

From the Cells homepage:

Cells brings the benefits of component-oriented development to the Ruby on Rails web application platform, without the performance problems that had been associated with Rails' own, deprecated, component subsystem.

Each Cell is like a little lightweight controller (with associated views) that you can embed anywhere in your app. I've been playing with it tonight, and while it's not on the level of say, Seaside, it seems like a fairly good baseline for building a more component oriented system for your apps.

I know from a mailing list that I'm on that some people are kicking around taking this and building a stateful component framework with real object binding underneath. That would really take Ruby web frameworks to the next level. (And be a ton of work to get right, I'm sure. :-) )

Hopefully that project will get started soon. I'm extremely interested in watching and helping it develop.

Today's 10.5.2 update to Mac OS X seems to have solved my issue of losing wireless connectivity every half-hour and having to reboot to get it back. I was about ready to throw my laptop out of the window with this one. How was I supposed to get work done when the internet was constantly going away?

I wasn't sure how much more I could have taken before I just installed Linux on this box to get back to work.

So thank you Apple for saving my laptop. And thank you for not making me go through the pain of dealing with a dual-boot Linux box once again.

Both of my last two companies have been involved in the aggregation of large data sets.

At the company I co-founded, Ten Ton Labs, we collected and normalized music reviews from across the web to support our music search engine, Squishr.

Our original plan, however, was to collect all reviews, of anything and everything, and then build an application that analyzed and tracked various metrics from the data to find out how consumers felt about certain products. We scaled the idea back to focus on music to allow us to continue building the underlying review platform and to have an easier application to implement on top of it to prove it out.

At my current company, Collaborative Drug Discovery we collect huge amounts of data about experiments in the field of chemistry (there are about thirty million known chemical compounds) and allow people to search through the data in various ways, as well as add their own data. Our users can use our toolset to keep their data private, but search across the aggregated dataset.

Both of these companies have a lot in common. When I was at Ten Ton Labs, our music search engine held a huge amount of short-term value for us. It was the cool thing that we could show to investors to get them excited about the company, and it gave us attainable short-term goals to go after. CDD is very similar, we currently put most of our effort into our cheminformatics application that runs on top of our data, because it's what we sell to people and show to our investors.

Long term though, I don't think that our music search engine or the CDD cheminformatics app is really where most of our value lies.

It lies in the cloud.

A huge amount of value is created by building tools to make it easy to get data into the cloud, and to make it easy for people to process the data and get it back out in a manner that they're used to. Once you have those tools, especially if you're allowing people to build applications and communities on top of your data, you're creating real value.

You've created an app that people will come back to everyday to see what's new.

And you've created an ecosystem around your data that won't allow it to die. People will build tools to interact with it in ways that you never even thought of, and again, more value will be created because of it.

I think that building a platform for data like this, not just a one-off application, is where the opportunity for huge value creation eventually lies.

My friend Jay wrote a few days ago:

I bet of you looked at the majority of Rails applications you would find empty test folders (or only the generated tests, which are never run). I'm quite sure that's true because I expect the conferences to attract the best of the Ruby developers, and several of the people I talk to at those conferences "simply don't have time" to write tests.

These people are idiots. Either that, or they don't have any sort of complexity in their apps and they're writing them in a far too simplistic and elementary way.

Quite often, doing a little meta-programming magic in Ruby can make you massively more productive and, in my experience, the only way to find the side effects of doing a lot of meta-programming is to have a comprehensive test suite. As this magic-level in your app increases, the number of side-effects of that magic will also inevitably increase.

Eventually, you will get burned by something if you're not ready for it.

Tests are your flame-proof suit in this case. They're not going to protect you against everything, but most of the time they do a damn good job of keeping you alive.

DHH wrote the other day:

We try to do a fairly good job at keeping our test suites current and exhaustive as well. Basecamp has a 1:1.2 ratio of test code (thanks to the persistence of Jamis!), Highrise has a ratio of 1:0.8 (bad me!).

At CDD, our current code to test ratio is 1:4.2.

Overtested? Undoubtedly.

However, we don't want to ever have to go in and fix the damage after someone tries to import 1,000,000 molecules to our system and something goes wrong. The repair work can take days in some cases, so we err on the side of caution.

I'll wrap this up with the following three easy points:

1. If you're writing a Rails app, write tests for it.
2. If someone who works for you "simply doesn't have the time" to write tests, fire them.
3. If a consultant tries to give a Rails app without a test suite, fire them (and don't pay them, if at all possible, what they've given you is pretty much worthless, and is going to be a nightmare to maintain).