This blog seems to be nothing but short announcements lately, but here’s
a good one: we’ve just completed a nearly-$13 million Series A funding
round with NEA and Catamount Ventures. I couldn’t be happier to have
them as partners in our (ad)venture.
We’ve hired quite a few people in Seattle
this year—four seems like quite a few to me now—and we’ve had to open
an actual office. For some reason, small startups are all the rage
lately, so it took quite a while to find anything of a reasonable size.
Then there was another delay before we could take possession and do a
It has finally come together, though, and it’s quite a nice place to
work. It actually tempts me to come into the office even if I’m going to
be the only one there—and that’s not just because it has air
conditioning, something old Seattle houses like mine don’t enjoy.
We’re open to visits from Seattle folks interested in coworking. If
you’re interested in spending a day with us, let me know!
As you can see, we’re basically an IKEA showroom. Cheap desks with
expensive chairs is my motto. By the way, I took these on a Sunday.
Normally there are people in the chairs. :)
Update: John Firebaugh figured out a better way to do this and made a gem out of it! So ignore this post, and use the capybara-firebug gem instead.
Today I was debugging a failing test in a Selenium / Capybara suite, and I really needed Firebug. In fact, I decided everyone on the team should have Firebug available in tests, ideally without any manual setup.
Of course, I searched to see if someone had already accomplished this, but I found only a few useful hints, none of which gave complete instructions. So here’s what I did.
Step 1: Configure Capybara to include Firebug
By default, Capybara launches Firefox with an empty profile. It turns out to be pretty easy to make it include Firebug in the profile. Put this code in an initializer (we’re using Cucumber, so this goes in features/support/firebug.rb or thereabouts):
Capybara.register_driver :selenium do |app|
profile = Selenium::WebDriver::Firefox::Profile.new
profile.add_extension File.join(Rails.root, "features/support/firebug.xpi")
Capybara::Driver::Selenium.new app, :profile => profile
Note the path features/support/firebug.xpi, which is where you’ll put a copy of firebug.xpi. You can retrieve that from the Firebug downloads page.
Unfortunately, the first thing Firebug does when it starts up is to look at the version of the previously-installed Firebug. If it thinks you’ve just upgraded, it launches a tab for the changelog page to show you the great new features. Depending on how your tests are written, that might be fine. My tests broke, so I needed to get rid of the welcome page.
Step 2: Rejigger Firebug to eliminate the welcome page
Reading the Firebug code, I saw that the welcome page logic pretty much insists on showing the page on a new install. It compares its version number with the value stored in the extensions.firebug.currentVersion preference (initialized to ""), and if it’s greater, up comes the page.
The code uses Unix utilities, so if you’re on Windows without Cygwin you’ll have to figure out an equivalent for the embedded script. Please send it to me if you do.
Step 3: Profit!!!
Or at least profit a little faster, because now you can find those tricky DOM problems in your tests with the help of the fabulous Firebug.
This afternoon I was iChatting with my excellent co-founder Jonathan when my video started to go all jittery. I checked iStat and saw that kernel_task was using about 200% CPU time. That seemed…odd. Since the chat was rapidly becoming unusable, I signed off temporarily to debug the problem.
At first I blamed Time Machine, which happened to be doing a backup at the time. I’ve seen some crazy CPU usage when Time Machine is “cleaning up”. But stopping the backup didn’t help. In fact, rebooting didn’t help. Something very weird was going on.
I thought to myself, “this is a job for DTrace!” and spent an enjoyable ten minutes poking around in DTrace-land. Eventually I ran across hotkernel.pl which, despite its age, still seems to work. It told me most of the time was going into the function machine_idle. Uh, what?
Now, we have four cats, and most of them have figured out that a MacBook Pro is a lovely, warm place to sleep, and one of them happened to be sleeping on it. Perhaps due to my cursing, she decided to find a more peaceful spot for a nap. As soon as she left, kernel_taskCPU time started going down, and so did the fan speed. Pretty soon everything was back to normal.
Clearly the cat was to blame (so often the case). She had blocked the ventilation on my MacBook and somehow caused this bizarre behavior. Doing further research using the google, I discovered the possible answer—though I’m not sure it has been confirmed by Apple. Apparently, when the MacBook Air came out, there was some controversy because it was so easy to overheat it (e.g., by playing 1080p video for two minutes), and it reacted by shutting down processor cores to conserve power. “They” say that Apple issued a patch so that instead of shutting down a core, the kernel scheduler just stops using it, and the unused time shows up under kernel_task. “Their” theory is that it looks better to customers than a disabled core. An amusing case of engineering by PR, if true.
Now I’m wondering if this situation is detectable in software, so next time I can just have an alert box that tells me what’s really going on.