In my quest to build a better bug tracking application, I decided to try out Ruby on Rails since I'd been tracking it for a while, seen a demo at BarCampMilwaukee that piqued by interest, and had been itching to build something with it. I am only passingly familiar with Ruby syntax and development techniques, but the claims are that you can get up to speed with it very quickly and put together the rudiments of an application with very little effort. I think some of those claims are justified, and some of them are not, but here is my experience thus far.

1. I do most of my development in Eclipse, and at the talk I saw, they mentioned something called RadRails which is an Eclipse plugin although the didn't use it. I installed both the Ruby Development Tools (RDT) plugins for Eclipse and RadRails, which are both free.
2. Unfortunately, while Ruby on Rails has a big community with lots of users, RadRails is just starting to get some traction so I had to kind of muddle through it and piece things together by taking what I was seeing from a generic Rails tutorial, the examples on the RadRails site, and some leaps of faith. Essentially, RadRails allows you to issue the necessary rails commands to do things like launch servers, create models, etc. from inside of Eclipse, along with providing the basic Ruby and Ruby HTML editing facilities using Eclipse's powerful IDE framework. Overall, I've found it to be very useful after the initial learning curve of trying to learn Ruby, Rails, and RadRails all at once.
3. The other trick was getting a database set up to use. The recommendation is MySQL, and that makes sense for me since this site is hosted with DreamHost, and that is what they provide their users, so if I want to eventually deploy my application here, it will be possible. Since I run Fedora, I did a yum install to get the necessary stuff, and grabbed the mysql GUI admin tools from their website. I created a new database and threw some tables together that seemed sensible.
4. Now it started to get a little ugly. First of all, it was floundering in RadRails because when I tried to create a new application, it was claiming success and then silently failing (i.e. it wouldn't create the standard directory structure for a rails application). I discovered that I needed to install the rails code directly; that is not part of RadRails. In retrospect, this makes perfect sense since you need a version compiled for your OS, but I was totally stumped at first. Luckily, Ruby offers a nice installer tool like yum called gems, so I could just say 'gem install rails'
5. Unfortunately, this failed with some error about a missing library. Googling around, I figured out that I also needed to install some other dependencies that gem can't resolve. Check out Installing Ruby on Rails on Fedora Core 5. Seemed to work fine for FC6 as well. That fixed the dependencies issues.
6. Now I started to roll. I followed this tutorial, linked from the main Ruby on Rails website, only instead of creating a recipe tracker, I just created stuff for my bug tracking application. This worked fine up to a point.
7. The rails motto is convention over configuration. The idea is that by using certain conventions such as file structure, database table naming, etc. the system can infer connections and behavior. This is good for productivity, but poison for debugging problems in my opinion. The problem is, when you don't know the convention very well, you can break from it silently without knowing. I did this with my database tables. Rails uses a standard model-view-controller setup where by using naming conventions in your model, it will automatically hook up to your database tables. That's pretty cool, except I didn't know that when I created the tables, and the convention is not (as I would have expected) model name == table name. Instead, rails tries to be cute and un-pluralizes your table names in the model name. So when I created a table to hold the main bug info called casefile, I then created a model called casefile, but they couldn't hook up because rails was looking for 'casefiles'. Even worse, since I am a Java programmer primarily, I called my model CaseFile, which rails mapped to case_files knowing that I meant two words. I figured this out eventually and changed my table names, but it's sort of an odd convention to use as the default in my opinion. I assume there is some way to override this if for example, you are hooking up to legacy database tables, but I haven't gotten that far.
8. I started to get really screwed up when I tried a custom view to edit new bugs. I had a weird circumstance where the default value would update data into the database with no issue. However, my custom view simply did nothing, and produced no error. Googling for 'rails update fails', etc. produced nothing relevant. After comparing the HTML produced for the default view with my custom version, I discovered the problem. I guess rails uses a convention by which if you specify the name of a form widget like

So, in conclusion. I got something up and running in a couple of hours worth of effort, but I spent about 50% of that time debugging one weird issue that should have been caught by the system, and stemmed from the whole convention over configuration bit. The last thing I want to mention is that I don't like the fact that stack traces and other messages don't appear in the server window, but instead are only dumped to a log file that corresponds to the mode you are in (like development.log). This is a weird convention that will take some getting used to. I will post more on this topic as I make more progress on my application.