|« May 2006||July 2006 »|
I'm Ryan Lowe, a Software Engineering graduate living in Ottawa, Canada. I like agile software development and Ruby on Rails.
I write this blog in Canadian English and don't use a spell checker. Typos happen.
» Full-time Ruby on Rails freelancer
» Full-time with Rails since May 2005
» Former committer for RadRails (now Aptana)
» I also have a few Rails side-projects in development:
1. wheretogoinTO.com Toronto nightlife
2. Hey Heads Up! TODO list and sharing
3. Layered Genealogy family history research
4. foos for foosball scoring
5. fanconcert for music fans (on hold)
Hiring Rails developers? I can telecommute by the hour from Ottawa, Canada
»» Email: rails AT ryanlowe DOT ca
Now hosted on Hey! Heads Up -- check it out!
Derek Lowe's (Ryan's older brother) words at Ryan's funeral
email@example.com no more
Forging Email Headers: Good, Bad or Ugly?
Sarcastic Dictionary (Part 1 of Many)
Twisting Rails is Risky Business
Risky Business? My Take on Early Alphas
Whoa, it's August 2007
A Postscript to "Growth at the grassroots"
»» All Blog Posts
David Heinemeier Hansson
James Duncan Davidson
Signal vs. Noise
Amy Hoy: (24)slash7
Luis de la Rosa
# 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...
# 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.
# 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.
# New fanconcert blog
A few reasons:
So enjoy! If you have a blog feed reader you can subscribe to the fanconcert blog's Atom syndication feed.