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 little remodeling.

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):

require 'selenium/webdriver'

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
end

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.

I didn’t want to change the code, so I decided to set the initial value of the preference to a very high number, thus ensuring that Firebug will never think it’s been upgraded. However, it wasn’t apparent how to jam a bit of JavaScript into the browser launch process to do that. Instead, I decided to just patch firebug.xpi to change it.

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_task CPU 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.

My five loyal readers already know this from my hiring plea at the top of the page, but in case you missed it, I’ve been working on starting a new company. Today we’re becoming a little less stealthy. My old friend and co-founder Jonathan Schwartz is announcing (via Twitter, of course) his participation. We’ve also put up a website: pictureofhealth.com. At this point we’re just saying the company is about “the intersection of innovation and public health”.

I’ve worked on several technologies whose goal was to improve the “health” of computers. As those systems were deployed around the world, I saw PCs everywhere became measurably more reliable and easier to use. I also saw how, once those systems became prevalent, the very process of creating and deploying software was changed for the better.

My goal, and hope, is that we can help to bring about a similar transformation in public health. I like to tell myself I helped to improve the mental health of millions of people by making Windows better, but I’d love to see a more direct effect on human happiness.

Needless to say, this is going to be a big job, and I need some help! I’m building our development and design team. We’ve posted a couple of job descriptions on the Picture of Health job page, and if this sounds interesting, please push the big Apply button. Actually, if you’re in the “smart and gets things done” category, please get in touch even if we haven’t figured out we need you yet.

I’ve received a couple of questions about how my new site is built. (If you want to hit “next” now, feel free!)

I used to have a Wordpress site. I maintain several sites for other people using WP, including my wife, so I’ve become fairly knowledgeable about it, though certainly not a guru. If you need a blog, a simple CMS, or a combination of the two, you can certainly do a lot worse.

For my personal site, though, here’s the thing. Well, two things.

First, Wordpress does way more than I want. I don’t want a dashboard showing me posts from other peoples’ blogs. I don’t want a categorized linkroll, or a custom taxonomy system, or a comment system (Disqus works great). In fact, I don’t even want the ability to edit posts in the browser. I want a minimal site where every feature is there because I see a need for it, and the workflow is designed around the way I like to work.

Second—and yes, this is a cliché—the thing is written in PHP. Not even the new-fangled PHP where they’ve layered objects and stuff onto the old-fangled one, but good old function-based code-in-the-template PHP. Every time I want to open the hood and customize or debug something, I am faced with this reality.

So when I decided to revamp my site, I realized that I should just start with nothing and add features until I got what I wanted. I found that other people had this same idea (see Toto, Jekyll, etc.) and took inspiration from them. (Of course, using one of those projects would defeat the purpose!)

The result is about 300 lines of Ruby (with comments), based on Sinatra. No database, just Git. I edit in TextMate, deploy to Heroku, and let Varnish do the heavy lifting.

When I explain this, sometimes people want the code. Well, my code isn’t all that. (To be clear, sometimes my code is all that—just not in this case.) Just do it yourself—it’s not that hard, and you’ll probably learn something.