November 2008 Archives

I was reading this blog post about the state of Ruby testing, and it introduced some nifty syntax for writing unit tests in Ruby. Instead of using method names as the test name:

def test_separate_invalids_creates_invalid
  nurse = Nurse.new
  nurse.separate_invalids!

  assert_create_invalid_file_for "Job"
  assert_create_invalid_file_for "JobReport"
  assert_create_invalid_file_for "JobView"
end

You could give each test a string name, like this:

test "separate_invalids! creates invalid file for each model" do
  nurse = Nurse.new
  nurse.separate_invalids!
  assert_create_invalid_file_for "Job"
  assert_create_invalid_file_for "JobReport"
  assert_create_invalid_file_for "JobView"
end

I wondered if we could do something like this in Objective-C with OCUnit. It turns out it’s possible with some preprocessor magic.

I just posted a binary of Radar Forwarder version 1.0. Radar Forwarder is a small application that handles those rdar:// URLs to Apple Bugs and forwards them to another URL. By default, it’ll forward to the Open Radar website. The application is a faceless background application that is launched on demand and quits after being idle. Once you click past the initial “this application was downloaded from the Internet” warning, it should run transparently and use no resources when not in use.

The application is packaged inside a preference pane due to one snag: if you’ve installed the iPhone SDK, MobileSafari included with the simulator registers for rdar:// links, for some reason. The preference pane allows you to chose which application handles rdar:// links. It also allows you to set the URL to forward to, if you’re so inclined.

Wow, talk about snowball effect. Here’s a tweet I wrote yesterday afternoon:

I’d love to make a public rdar database. I’ve got some ideas on how to implement it. Anyone else interested?

This is something I’ve wanted for a while. Apple’s bug database is not public. All you can see are your own bugs (called “radars” because that’s the name of Apple’s internal bug database tool application), but I’ve always thought it would be nice to be able to see already filed bugs. Maybe someone already filed a bug? Maybe they found a workaround?

I soon got tons of feed back from “Yes” to “We should use {insert your favorite web technology here}”. About five hours after my tweet, Tim Burks (of Nu fame) tweeted that he built a quick prototype on Google’s App Engine:

Here’s a quick start using App Engine: http://openradar.appspot.com

And this morning, I woke up to find more than 85 bugs already entered! Amazing… that’s less than 24 hours from idea proposition to app being built, deployed, and used. I gotta say, I’m ultra impressed with Tim and App Engine. This is my first experience with App Engine and the ability to write and deploy a web app so easily is pretty remarkable.

So head on over to Open Radar and add your own bugs. The bigger the database we get, the more useful it will be. This is still very, very early in development, but I’m ecstatic with the progress thus far.

One note: this does not replace reporting bugs with Apple. You should file all bugs you find, even ones that have already been reported. Apple engineers have repeatedly mentioned that the more duplicates there are, the higher priority a bug becomes. It’s sort of like a voting system. Apple wants to fix the bugs affecting the most people. So lemme reiterate: even if you find a bug in Open Radar before filing it yourself, file it with Apple anyway.

Oh, and the source code to Open Radar is Open Source and Tim posted it up in GitHub. Jump on in and give us a hand.