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!