« May 2006 July 2006 »
blog header image
# Collaborative Documentation for Eclipse?

Open source software has some great examples of collaborative documentation, where you don't just browse the official docs -- you can also add comments to them to help others.

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

posted at June 28, 2006 at 10:47 AM EST
last updated December 7-, 2006 at 04: 1 PM EST

»» permalink | comments (4)

# Building RadRails with Ant

RadRails was different enough from Durham that the custom Ant build scripts to build their Rich Client Platform (RCP) products are starting to diverge. I don't see a problem with that -- it will be easier to maintain both that way.

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.

posted at June 22, 2006 at 08:25 AM EST
last updated December 7-, 2006 at 07: 1 AM EST

»» permalink | comments (4)

# RadRails Snares New Committers

This week I was invited by the RadRails guys on #radrails to join their team as a committer and I've gladly accepted. Thanks guys! RadRails is a relatively new IDE for the relatively new Ruby on Rails web platform. RadRails is Java software built on the Eclipse Rich Client Platform (RCP).

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.

posted at June 08, 2006 at 11:45 PM EST
last updated December 6-, 2006 at 10: 0 PM EST

»» permalink | comments (1)

# New fanconcert blog

I made a new fanconcert blog on Blogspot: the fanconcert blog. Why did I do this?

A few reasons:

  1. Having it on blogspot means that if fanconcert is not working, I can still update the blog and tell people what is going on.
  2. I needed a separate blog for fanconcert users that weren't concerned with other kinds of things I post on this blog. The fanconcert blog will talk about things from the user perspective.
  3. fanconcert users aren't necessarily concerted about development issues, like Rails stuff, that I talk about on this blog
  4. ...and finally: Blogspot has pretty blog templates. I can't compete with that!

So enjoy! If you have a blog feed reader you can subscribe to the fanconcert blog's Atom syndication feed.

posted at June 03, 2006 at 01:59 PM EST
last updated December 6-, 2006 at 07: 1 PM EST

»» permalink | comments (0)

Search scope: Web ryanlowe.ca