Wow, what a weekend. My friend and I left at 8:30am Friday morning, and thanks to his wifi enabled cell phone, I was able to code in Rails for the entire two hour drive up to Orlando and the two hours back. In all, I put in 27 hrs logged on to my laptop in Rails in two days! (Yes, my wrists are sore).

It was a real joy to be around members of the Rails community; hearing tips and debates on various patterns and solutions using the Rails framework. I met some great people too, many of whose web sites I have followed over the last year of my personal Rails adventure.

Robert Dempsey was the organizer and he did a great job of putting this thing together. The hotel had wifi issues (is there a hotel that doesn’t…how hard is it to get wifi working in a hotel?), but the conference went very smoothly and was filled with great teachers.

Here are some of the tips I picked up:

Netbeans for Rails
When I first got into Rails I tried Aptana. However, it seemed so slow and clunky that over time I went back to using a text editor and the command line. But Sun was at the conference and discussed Netbeans, so I downloaded it on the spot and tried it out. I really like it so far. Sun provides a version of NetBeans which is only for Ruby, so you aren’t loading an IDE that covers every development language in existence. Thus, a smaller footprint. Its snappy, and provides all the extras one would expect from an IDE.

Best Practices for Rails Teams
Luke Francl discussed some helpful tips for working in Rails teams. While I’ve never worked in a Rails team of greater than two, I’ve been working in teams of 4-8 in Java for 8 years now, and I’m very familiar with the need for good processes and tools. In fact, this has been one of my personal areas of focus. Everywhere I’ve gone, I’ve worked to bring that Internet Software department into a good development model, from creating design/development processes, to using Maven, to developing internal Project Management applications. So this subject was of special interest to me.

Luke recommended some solutions for the db migrations clashes that can occur (more on that in a later post), managing third-party code, security, source control, bug tracking, continuous integration and more. It was a great summary of all of these elements. He’s posted a summary of the talk on the blog Rail Spikes.

Simple Web Development
The Friday keynote was by Dan Benjamin. Dan spoke the words I’ve spent so much time trying to teach at my places of work. Here are three quotes that sum it up nicely:

  • As simple as possible, but no simpler
  • Develop for one scenario, not for ten
  • Good code does not impress users

He said a lot more than that, but I was listening so intently I forgot to take notes!

Testing Rails Apps
Bryan Liles gave a great overview of the state of testing Rails software. His session was titled, BDD With RSpec, but he scratched out the RSpec. When he signed up for the class he was a fan of RSpec, but during that time he moved away from it. He instead focused on the overall concepts and importance of proper testing, and that the testing be from the standpoint of the functionality the user is expecting and that the test cases be written first (also known as Behavior Driven Development) and then write the code needed to fulfill those tests. This goes along great with the concept of keeping your application simple and to the point.

He recommended trying Shoulda for a little extra functionality on top of Test::Unit. I am now using Shoulda for my current application and it does add some nice helpers, textual test names, and contexts but without the need to learn a full replacement for Test::Unit.

Conclusion
Also thanks to RailsMachine for the great party on Friday night. The food and giveaways were great and so were the many Rails discussions. I am certainly looking forward to the next Rails conference, and if Robert does another one of these, I highly recommend it. When I find time I plan to write some posts with more detail on some of the topics I quickly reviewed in this post.