What's most interesting is the audience: Linux programmers. The Eclipse Rich Client Platform lets us simultaneously release RadRails for Windows, Linux and Mac OS X. Ruby on Rails could end up being very big with webapp developers that use Linux -- and RadRails will be there waiting for them, with very little additional work from our team.

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.

The PHP documentation on PHP.net is a perfect example and they've been doing it for years. Now Ruby and Ruby on Rails are getting into it with rannotate. I've found some excellent code nuggets in these comments.

Eclipse has a wiki -- which I think is great -- but could it also benefit from collaborative documentation? Absolutely. The collaborative docs could be based on the official Eclipse platform's existing JavaDoc as a starting point.

Eclipse could keep the original online JavaDocs pristine and put the collaborative versions online somewhere else. People could make comments in a class or below each method, or in many other places.

Challenges? How to update the collaborative docs when JavaDoc updates are released without affecting the comments on top of them? (ie. fixing spelling mistakes). Question: How many different minor versions of the collaborative docs do they maintain? (ie. 2.1.3, 3.0.x, 3.1.x, 3.2.x and they could even do 3.3.x while it's under development). The comments could be scored so that good tips rise to the top (ie. Slashdot, digg).

This could be an interesting Ruby on Rails web project...

One of the neat things I wanted to do with RadRails was build it with the Eclipse 3.2 platform plugins as well as the Eclipse 3.1 platform plugins every single time the build machine does a build. With the Ant scripts we can package standalone versions of RadRails based on either 3.2 or 3.1 and for Windows, Mac OS X or Linux.

Backwards compatibility with 3.1 is important because we want to make sure that RadRails still works on the stable 3.1.x branch for people that still have 3.1.x and use the update site to get RadRails.

Right now the build just makes sure that RadRails compiles under both 3.2 and 3.1. That's the absolute minimum smoke test, since code that can't even compile can't be packaged. Later on I'm going to add projects, packages and Ant support for a unit test suite and run that as well with each build.

The tentative plan is to offer the nightly and/or integration builds to the public as well, so that people can test 'beta' builds before we make releases.

When Eclipse 3.3 comes out, I'll add it to the build scripts and continue to build 3.1 as long as we offer backwards compatibility to that version (notice we don't bother with 3.0, should we?).

I'm still working on getting the nightly(N) and integration(I) builds going on the SourgeForge.net compile farm. Once I can login with sf's SSH key setup I should be all good as long as the build machine has Java 1.4 and cron.

Some people have asked me why I'm doing all of this build and test work. Am I still a Java+Eclipse+RCP developer? Of course, that's what I enjoy most. In RadRails' case I saw that I could contribute with the build/deployment experience I have from other RCP projects and improve its quality and stability. This is important to me because use RadRails for my Ruby on Rails work.

Sometimes you have to do things you don't think are super fun to ship a quality product. That's what software development is all about, right? OK, maybe Ant work isn't so bad. :) Deployment is an interesting, necessary and sometimes complex part of software development. Projects like this give me more of an appreciation for the hard work that software build engineers do.

I have a stakeholder interest in RadRails because I use it for my Ruby on Rails development. I like that it works on both Windows and my Mac and has nice Subversion integration, among other things. The fact that I'm already really familiar with Eclipse doesn't hurt either. I'm pretty pleased with RadRails but I wanted to see if I could help improve its quality and stability.

The invitation to be a committer was given after I submitted some Ant scripts to build RadRails. I gained a lot of familiarity with RCP proejct structure and Ant while working on Durham/AudioMan and subsequent Eclipse Rich Client Platform projects. Since the Durham Ant scripts were under the EPL, I just moved them over to RadRails with some changes.

The Ant scripts could be used by developers but mainly they will be used by a build machine to automate the build process. Automating the build process is important because it removes a lot of the human error that happens with 'manual' building of packages and it introduces consistency in the build process, both of which ultimately improve the quality of the final product. Build scripts also ensure that you can go back and built something three versions ago and it'll work just like the original.

When this is all in place I'll be one happy Software Engineer (B.Eng).

What else am I up to? I'm still working on fanconcert and looking for full time work in either Java+Eclipse+RCP or Ruby+Rails+DHTML. If you know of any opportunities in those two areas, especially in Ottawa, you can give me a shout: blog(at)ryanlowe(dot)ca.