Tuesday, December 21, 2010

Apple: Ouch!


I had my laptop wrapped in a blanket in my backpack when I dropped it on concrete at BART yesterday. It landed on the corner with quite a lot of force and bent a few metal pieces. Everything seems to work, with the exception of the ethernet port. Thankfully, I rarely use that. I'm hoping this is covered by the warranty, although it seems unlikely. The bent aluminum reminds me of body damage on a car.

Wednesday, December 15, 2010

Vim: PeepCode Videos

There are commercial videos on PeepCode that show how to use Vim. They're fantastic! The production quality is very high, so they're worth paying for. I bought both of them, and I learned quite a lot. Even the first one covered a ton of advanced stuff, so I highly recommend it.

If you're just getting started with Vim, I suggest you:
  • Read this blog post from Yehuda Katz. Basically, he suggests you use the GUI to get started and iteratively gain more experience with Vim. I think that's good advice.
  • Next, I suggest you fire up Vim and take the internal tutorial.
  • Last of all, watch Smash into Vim part I.
If you're an advanced Vim user, watch both videos and tell me what your favorite part was ;)

Friday, December 10, 2010

JavaScript: IE and DTDs

I was having a hard time getting Internet Explorer 8 (IE8) working with Socket.IO's "htmlfile" transport (or any other transport for that matter). I was getting weird permissions issues. I finally fixed the problem by adding a DTD to the top of my HTML file, "<!doctype html>". I was just being lazy not having a DTD, but I was really surprised when that fixed my problem. Of course, I'm still having a hard time getting IE7, IE6, and Opera working cross-domain (technically, I'm just using a different port, but eventually it'll truly be cross-domain).

Wednesday, December 08, 2010

Ruby: Why I Prefer Cucumber

I've been struggling to articulate why, in most cases, I prefer high-level integration tests with Cucumber and Webrat (or Capybara) over low-level model, view, and controller tests with RSpec. I think I finally have an example that conveys what I'm trying to say. Consider the following Cucumber test:
Scenario: create a new film unsuccessfully
Given I am logged in as "admin"
And I am on the admin films page

When I follow "New film"
And I press "Create"
Then I should see "There were problems with the following fields:"
And I should see "Name can't be blank"
And I should see "Url name can't be blank"
And I should see "Sort name can't be blank"
And I should see "URL doesn't look like a valid RTMPE URL"
But I should not see "Trailer URL doesn't look like a valid RTMPE URL"
And I should not see "Scene URL doesn't look like a valid RTMPE URL"
This test is short, readable, and easy to write. It doesn't test every possible validation failure, and it's not the only test I have. (In fact, I have some RSpec model tests that test the more esoteric URL validation rules.) However, it does test the model, view, and controller's handling of validation failures, and it even tests that they integrate with each other.

Can you imagine trying to write the same tests by separately testing the model, view, and controller using RSpec? Now, imagine trying to use a separate test for each assertion. That's a lot of code for something so trivial--this ain't rocket science, guys! Finally, remember that when you test the things separately, there's nothing preventing the code from crashing when you put all the pieces together. (For instance, what happens if the controller and view each pass their RSpec tests, but they disagree on the spelling of one of the assigns?)

Is there benefit to testing things separately--absolutely. Is it worth it in this case--absolutely not. I think it's important to remember that at a certain level, our job is to implement features that work. Tests are a means to an end--they help us keep the code working. They don't really have any intrinsic value for the stakeholder. They only have the secondary value of keeping the code working when it is extended.

Just as there is engineering value in implementing features using less code (as long as it remains readable), there is also engineering value in implementing features using less testing code (as long as the tests continue to serve their purpose of preventing regressions).

My point is that Cucumber lets you test more using less effort.