We released RadRails 0.7.0 this week and it's the first version of RadRails we built with the Ant scripts I contributed. RadRails is an Eclipse-based Ruby on Rails IDE.

Apparently Eclipse 3.2 couldn't export RadRails any more (the old deployment method) so the scripts were rushed into action and I managed to get up to speed relatively quickly with only a few minor errors to fix in the scripts.

The next step is to get RadRails building nightly on a build machine and then running a test suite as well. My main priority is making sure RadRails' deployment story is solid so that we can deliver a solid product. Then I'm going to be contributing new features and bugfixes.

One thing that people seem to forget: RadRails isn't even 1.0 yet. It's still under heavy development, new features are added all the time and it's probably about beta quality. We want to keep it usable so people can use it to do work, of course, but bugs are going to happen and they'll be fixed in the following releases if you let us know about them. :) Please report any bugs you find either on our trac database or on IRC (freenode #radrails).

When a regression test suite is in place the number of bugs in releases will probably be reduced. We also want to post integration builds so that people can test them before we make an official release. All of these things will help make RadRails an even better Ruby on Rails IDE than it is now.

For more details on the release see the RadRails blog and listen to the podcast.

For more information on the RadRails build scripts I created, see my post Building RadRails with Ant.

I'm loving my Mac after my recent Tiger Install. Using it as a dedicated development machine for Ruby on Rails and Java+Eclipse was a great idea.

However, the Ruby that came with Tiger is broken and I didn't fix it. So now I have to reformat my machine and do it all over again. I don't see this as being too much of a problem, it will just take some time to do it without DarwinPorts.

It certainly helps that nearly all of the data that's on this Mac is backed up to source code repositories or external hard drives anyway. The old Mac is 3.5 years old now -- so as far as I'm concerned it could die any day now. I'm not worried about that happening -- I'll just buy a MacBook. :)

Anyway, on with the install! Here were the install steps:

1. Installed Mac OS X 10.4 Tiger from DVD, erasing the previous installation.
2. Installed Mac OS X Xcode 2 Tools from CD.
3. Used Software Update to update to 10.4.7 (twice).
4. Changed the computer name in Sharing preferences.
5. Downloaded and installed FireFox, FireBug, Gmail Notifier, VLC.
6. Downloaded RadRails:
    I put it in /Applications/radrails/0.7.0
    and the workspace in ~/workspace/rails
7. Downloaded Eclipse:
    I put it in /Applications/eclipse/3.2
    and the workspace in ~/workspace/radrails-dev
8. Installed Ruby, RubyGems, Ruby on Rails, FastCGI, lightTPD and MySQL into /usr/local/ using the most excellent instructions at Hivelogic.

I just read Ed Burnette's blog post My dream job and I'd have to say I agree with most of the points. Maybe I'll make a post like this someday.

One point stood out for me:

"At my dream job there would not be separate quality testing groups. Developers would be responsible for the quality of their own code."

Which leads to my theory: recruiters and managers promised developers they wouldn't have to test to keep them with the company. Testing teams were common before that but the bubble entrenched them even more.

Besides, anyone can bang on software for hours and hours. The bubble created "testing" jobs for any Joe off the street. But great testers are technically savvy, rare and valuable.

Why do Ed and I think it's so important for developers to test their own code? I can't speak for Ed, but here are a few reasons I have:

1. Developers can't learn from their mistakes (and write better code in the future) if the bugs they make never come back to them. If the testing is left up to a testing team, a single bug can be created, found and fixed by three (or more) different people.
2. When you write your own tests, you tend to be more critical of your own code, leading to higher code quality and less defects to fix later.
3. If developers write the tests, they'll know how to fix the test suite and keep it green (100% passing) when the code changes!
4. Having unit tests in place makes the code easier, faster and safer to refactor in the future.
5. When developers write tests for their own code, they find new bugs (and regressions) faster. They don't have to wait for the testing and bug reporting turnaround time before the bug gets back to them. This speeds up overall development time instead of slowing it down (like is commonly thought because of the effort needed to make the tests).
6. Testing and development teams are sometimes adversarial, which can affect the attitude and morale of the entire building and affect the quality of the final product.

Should testing teams be completely abolished? No, testing teams can keep the developers honest about writing tests and sharing their expertise by helping developers write better tests. A testing team can also work on more advanced testing techniques, like code coverage analysis, performance testing and bringing in new testing solutions that can help the team. Testing can be just as much R&D as development.

There are also UI tests that are more efficiently (and cheaply) run manually by real people sitting in front of the software. I don't think this is going away anytime soon -- UI testing just isn't at a mature enough state yet, so banging on the end software is still important.

Testing is creeping its way up the API levels to the UI though, especially in platforms that are written to be automatically testable from the ground up, like I found with Ruby on Rails.

Just to be clear: I don't want to be a full-time tester, just like I don't want to be a full-time build/release engineer. I'm a software developer and I want to deliver quality software. I believe that part of that is writing tests for my own code.