I spent the earlier part of this week at Pragmatic’s Rails Studio, an intensive three-day Ruby on Rails training. This one was in Seattle; they are offered periodically at various locations around the country. (There’s not another one announced yet, but they’ll be posting a new schedule shortly; check their web site.)

Overall, I found this to be very worthwhile. It would have been a lot more valuable, however, if I could have gone a couple months ago, as I’ve spent the past two months building a couple small Rails sites, figuring things out as I went along. So a lot of it was review for me—something like 80% of the first day, 60% of the second day, and 50% of the third day. Nevertheless, it was very helpful in filling some gaps in my knowledge. I picked up quite a few tips, and perhaps most important, it gave me confidence that I’m on the right track and moving along pretty well. The presentations went well beyond the facts to explain the best way to approach things, why certain things in Rails work the way they do, and other useful bits of perspective that come from long experience.

World-Class Instruction

The instructors are Dave Thomas, the primary author of Agile Web Development with Rails and the proprietor of the Pragmatic Programmers publishing house, and Mike Clark, also an author and an active developer, and the head of Pragmatic Studio, a separate training company that shares part of the brand with Dave’s company. Both are outstanding instructors with deep expertise in the subjects covered. Chad Fowler was also there helping out, and he surely knows as much about Ruby as anyone in the U.S.

Dave Thomas

Mike Clark

The format of the Studio is an hour or two of lecture, followed by half an hour or so of programming on your own (you need to bring your own laptop). It’s an effective format, since you really don’t know if you understand something until you try to do it. Mike and Dave alternate speaking, providing different perspectives and variety in style.

The attendees were surprisingly diverse. There was certainly a local Seattle-area contingent, but there were also some who had traveled a long way. I went out to dinner one night and in our group there was one person from Alaska, one from Paris, and one from Mexico City. Some of the attendees were building Rails sites for their days jobs, while many were working in other technologies and seeking to move into Rails, either with their current employer, on their own, or with a new employer TBD.

Is This the Right Seminar for You?

If you’re looking for a jump-start in Rails development and are just getting started, I highly recommend the Rails Studio. If you’ve already done some Rails development, though, it’s a tougher call.

If you’re comfortable with the basics of the MVC separation, using migrations, creating and using associations, performing validation, and using views and layouts, this seminar will be mostly review. It covers the basics of AJAX with RJS templates and simple Scriptaculous effects, but nothing complex. One part that was most useful to me was the coverage of unit, functional, and integration tests, although the depth of coverage here too was necessarily limited.

If this Studio sounds like it would be mostly review for you, consider the Advanced Rails Studio (next offered in April in Dallas).

I’ll be adding a series of posts during the next couple days about some of the things I learned at the Studio.

Agile Web Development with Rails, by Dave Thomas (of Pragmatic Programmers) and David Heinemeier Hansson (the original creator of Rails) has been the framework’s bible since the publication of the first edition in mid-2005. With the rapid evolution of the framework, the book didn’t last long before a second edition was badly needed.

To meet the urgent need of the community and gain feedback at the same time, Pragmatic Programmers has been publishing “beta books” in PDF form. All of us who have downloaded multiple versions and awaited a nicely bound, proofread, and indexed copy can finally rest easy: the book went to the printer yesterday.

If you can’t wait a few more weeks, you can buy the PDF-plus-printed-book package and get the PDF right away, with the book to follow when it’s back from the printer.

I’m currently at the Rails Edge conference, an interesting gathering of about 100 Ruby on Rails aficionados, newbies, and everything in between, in Denver. I’m excited about this framework and plan to use it for my future web development work.

For those of you who know about Rails, this post isn’t going to tell you much; I’ll have some deeper content later. But for everyone who may have heard of Rails but can’t quite make sense of it, I hope you’ll have a much better idea of what it is and why it is important by the end of this short article, even though it only scratches the surface.

Ruby is a pure object-oriented programming language, sometimes called “post-modern” and the object of an amazing amount of genuine affection. Programmers who have switched to Ruby really love this language. Ruby fans call themselves Rubyists and users groups go by the Ruby Brigade moniker. It’s attracting a lot of defectors from the Java and PHP communities, as well as from Python and Perl. I believe it is poised to become the most important language for the next wave of innovative web applications.

What’s so great about Ruby? It is clean and easy to read and to write (once you get accustomed to it), and it encourages good object-oriented programming practices without being overly constraining. It is a dynamic scripting language, which means that there’s no compilation required, no strict typing, and classes and objects can be extended dynamically at runtime. Programmers from a C++ background may find some of these freedoms horrifying and fear that they make it too easy to insert hard-to-find bugs, but the Ruby community would strongly disagree.

One of the benefits of Ruby is that it’s easy extensibility and minimalist syntax allows you to turn in into a domain specific language. In essence, this means your code can stay at a high level of abstraction, with terms that match the real-world names of the things in the domain your code deals with and a bare minimum of language-specific complexity to get in the way.

In this short piece, I’m going to have to ask you to take all this Ruby affection on faith for now, and move on to Rails, which is the short name for Ruby on Rails.

Ruby on Rails is a framework for writing web applications in Ruby. It was created by 37Signals as part of their Basecamp web-based collaboration tool. They didn’t set out to write a general-purpose framework; rather, they built the framework that they wanted for the application they were building, and when they were done, they extracted the framework from the application and published it as open source. Since then, a vibrant open-source community has helped rapidly enrich the framework. There’s a stunning amount of brainpower being applied to moving this technology forward.

Rails implements a design pattern well know to most experienced programmers, called Model-View-Controller (MVC). The code is divided into these three categories, with the following separation of responsibilities:

• Models: Models are the only code that talks to the database. They maintain the integrity of the data and do all the heavy lifting when it comes to manipulating data.

• Controllers: The controllers sit between the views and the models, making requests from the database and preparing the results for use by the views.

• Views: As the name suggests, the views are responsible for presenting information and accepting user input. Everything that is visible comes from a view.

It is certainly possible to write MVC applications in other languages, but none makes it as easy and natural as Ruby on Rails, and none has nearly as large and enthusiastic a community behind it. You can use Struts with Java to write MVC applications, but the amount of complex Java code and XML configuration that is required can be literally a factor of ten times greater than that for Rails. You can write MVC applications in PHP, but unless you work hard to avoid it, PHP’s natural path is to lure you into rolling everything into the view.

People with substantial experience building Java applications claim true order-of-magnitude improvements in productivity after moving to Rails. Perhaps even more significant, and also a source of this productivity improvement, they love doing it. Many people respect Java, and value what it can do, but few love writing programs in it. Barely a decade after its birth and rapid rise to the server programming language of choice, Java has become the old-school way of doing things that many Ruby converts say they will never go back to.

Rails encourages Agile development practices because it makes it so easy to make changes. This supports the iterative development style that is at the heart of most great applications today.

There’s lots more, from simple implementation of Ajax user interfaces to built-in templating and testing frameworks, but since this is a blog post and not a book, I’d better stop here.

Of course, Ruby on Rails is not without its drawbacks. Ruby is relatively slow, and this has been the source of much disparagement. In response, however, advocates note that while it may not make as good a use of CPU cycles as Java, it makes far better use of programmer cycles, and those are a lot more expensive and harder to scale. And there are efforts under way to increase its performance dramatically. The framework is also relatively young and rapidly evolving, which sometimes makes life challenging for developers. But to the converted, Rails has become the Holy Grail.

Technorati: The Rails Edge Ruby on Rails