When I was last seen at ADTmag.com, I was writing about things like enterprise software running on Windows, Office's XML support and the like. This column, I am happy to say, will be completely different. That's because I'm no longer running Windows. Instead, my consulting career has turned to work with Ruby on Rails, and I develop on a mixture of Mac OS X and Linux boxes.

What happened? About two years ago, I walked away from the career I'd spent 15 years building and re-evaluated my tool set. The trigger for this was a growing dislike for Microsoft's intellectual property policies, which I regarded (and still do) as something of an unwarranted land-grab. I spent a few months evaluating various alternatives, including native Cocoa programming for OS X, Django and Rails. Rails won for several reasons, not least of which was the continuing "buzz" surrounding it. If you're going to sell programming services, it helps to sell something that people want to buy.

Switching from ASP.NET to Rails has been an interesting experience. I've moved from working full-time in a complex IDE to working full-time in a high-end text editor. There are several IDEs available for Rails, some of them quite useful, but switching has helped me to remember how much I enjoy working close to the code, without a lot of visual clutter or hidden code bits. The man-years of work that have gone into the Rails framework have resulted in some truly useful shortcuts. For a trivial example, generating a list of multiple suppliers for a particular part is as simple as writing

<%= render :partial => "supplier", :collection => @part.suppliers %>
and then supplying a template with the HTML for a particular supplier. I find this much easier than mucking about with visual controls in an IDE, though there's certainly a learning curve in moving from one to the other.

Working with Rails -- and with other Rails developers -- has made me a better coder. Not only is Rails itself "opinionated software" (it's easy to do things the way that Rails thinks you should do them, and harder to do them any other way), but it's supported by an opinionated community. Test-driven development -- or its newer cousin, behavior-driven development -- is assumed. People place a premium on elegant, non-repetitive code. And being closer to the actual code has meant being forced to buff up my HTML and CSS skills, rather than relying on code generation for everything.

Of course, Rails isn't a perfect development system -- nothing is. As a relatively young framework, it's moving fast. The consequence of this is that it can be hard to keep up with the latest and greatest way to do things -- and if you're an active Rails developer, you may find yourself maintaining different sites on subtly different versions of Rails. As with many other open source projects, the documentation has lagged behind the functionality (though this is getting better), leaving you with no alternative sometimes but to read the source code to figure out what to do and how to do it. Then again, reading well-written source code is always a good activity.

Setting up a server with Rails is also trickier than setting one up with ASP.NET. Here, the problem is one of evolution and competition: There are several different Web servers that you can happily use with Rails, and learning to choose and configure them can be difficult. If you pay enough money for hosting, you can get everything set up for you with a cherry on top. If you want to pay a more reasonable amount, though, you need to count on learning a fair amount of Linux sysadmin skills.

It's also impossible to work with Rails without running across persistent questions about scalability. There are several answers to these questions. One is that just about any system can scale if you're willing to work at it hard enough and throw enough money at the problem: There are sites (like LinkedIn) that have developed Rails applications that serve a tremendous number of page views without trouble, even as other sites (like Twitter) have stumbled. At the same time, though, one has to admit that any framework or language has its sweet spots; there's no one-size-fits-all answer. For the sort of sites that I'm currently working on -- database-backed Web sites doing tens or hundreds of thousands of page views per day -- Rails works fine, and allows me to deliver client value quickly.

If you're interested in kicking the tires on Rails (mixed metaphor and all), it's reasonably easy (and free) to get the software. After that, though, it can be tough to figure out where to start. Many of the available screencasts and tutorials are outdated due to the rapid pace of framework development.

The standard printed reference for new Rails developers has been Agile Web Development for Rails. Unfortunately, at this point the second edition is so outdated as to be dangerous. You can already purchase the third edition, which will get you a beta copy in PDF format and a printed book when it ships later this year. As I write this, the beta is incomplete but useable.

If you're following the same path as I did, the upcoming Rails for .NET Developers will be very useful -- I've seen draft copies of the manuscript -- but it won't be available until mid-November. Right now, the best Rails 2.0 book is Obie Fernandez's The Rails Way -- but be warned, it's more of an advanced reference than a tutorial.

Ultimately, the best way to learn Rails is still to just start writing code (I find this to be the best way to learn programming languages and frameworks in general, for that matter). If you can find a mentor to get you started, great! If not, pick some constrained problem space, like tracking your expenses or displaying a list of books, and dig in. Try the Akita on Rails tutorials for Rails 2.0 and 2.1 to get a quick overview; they're the best set I've seen so far.

All in all, I've found Rails to be an excellent playground for my improvement as a developer -- and a good framework to hang my continuing career on. If you've never done any work with an MVC (model-view-controller) framework, it's a good one to dig into; Rails makes it easy to structure your code according to MVC principles. And who knows? You might discover that you like it as much as I do. In the coming months, I'll be writing more technical articles, keeping you apprised of some of the cutting-edge work being done around Rails. But in the meantime, I'd just like to invite you to join me in seeing if it appeals to you. Hope to see you back next month!