If the thought of diving into yet another hot new technology gives you a headache, I sympathize. I've stuck mainly to PHP and Perl for years, happily ignoring most other development fads.
However, I'm rethinking this as my projects get steadily more complex. After hearing a full-time developer talk about the limits he bumped into when using PHP for larger database-driven Web projects, and how useful a development framework turned out to be, I decided it was time to look seriously at some more robust tools.
There are several interesting options out there if you're looking for a framework -- something to give structure to your applications and help you do more with less code. Rails for the Ruby programming language is probably the most popular framework right now, and I was curious to find out why.
But can a part-time coding enthusiast really learn Ruby on Rails (RoR)?
SitePoint Pty.'s Build Your Own Ruby on Rails Web Applications by Patrick Lenz pledges that it's written for both hard-core programmers and the less experienced -- even those who know only HTML and CSS. "Web development has never been easier, or as much fun as it is using Ruby on Rails," Lenz says.
Fun? OK, I'm ready to see if RoR can indeed be faster, easier and more fun than some recent projects I've sweat through using PHP and Perl.
Over several weeks, I went through a portion of Lenz's book, as well as a few other resources. I was, in the end, able to create a simple application to pull items from a MySQL database. And I came to see why coding Ruby applications on Rails has become an important Web development trend.
 Hands on with Ruby on Rails
|
Why use a framework like Rails?
Ruby on Rails is all about adding structure and built-in functionality to your projects, with the goal of limiting dull, repetitive and confusing coding. A caution, though: At the beginning, it seems to add complexity. It ends up paying major dividends down the road, but you have to hang on to the prospect of long-term benefits when you first dive in.
I liken it to doing your taxes. Say someone offered you a beautifully crafted, perfectly constructed file system for tracking your finances -- one that was intuitive and easy to use but had a bit of a learning curve. If you're single, fill out the short form and take the standard deduction, it would probably be easier to stick everything in a folder and deal with it in April. Likewise, for very simple scripts and applications, there's no need for a development framework like RoR.
But now imagine you have a family. And changed jobs. And have rental property income. And some self-employment income. Now that file system starts to look more appealing. So it is with Rails. As your application becomes more complicated and you want to keep adding features (or members of a programming team), a well-thought-out, pre-existing structure can be mighty handy.
"For me, discovering and learning Rails had a similar effect to Google Maps; it seemed almost too good to be true," Rob Orsini writes in Rails Cookbook. "Rails handled all of the things that I found most unpleasant about Web development automatically or so elegantly that they were no longer painful. ... I've often said that the simple act of creating a Rails project felt like there was a room full of experienced software veterans imparting their knowledge about sound application design, ensuring that my project started off in the right direction."
I can see this even in a simple application I coded for myself in PHP. It started out as a few pages of PHP and a simple MySQL database. Then I wanted a mobile version to view on my cell phone. Then I needed a couple of new fields in the database. Then I changed Web hosts. You get the picture.
An external configure file and style sheet took care of some of those issues, but it turned out there were subtle differences in some SQL commands used to access my database. Suddenly, I needed to change SQL code sprinkled throughout numerous pages. Yes, I could have structured my code more modularly at the outset. But I didn't. That's one advantage of a framework -- it makes me write more modularly, counteracting my natural tendency to just go the quick-and-dirty route.
Ruby on Rails "lets you write beautiful code by favoring convention over configuration," the framework's official Web site promises. In other words, instead of having to come up with structures for your application, Rails does much of that work for you. That means first off, you don't have to create a separate file for functions you'll be using throughout your application; Rails generates files like that for you automatically. It's not all that much work to create such files, of course. But since every Rails project uses the same file structure, everyone on a team knows where to find them -- even programmers who join a project midstream. It also makes it easier to maintain your own code when you haven't looked at it in a while.
Also, if you use the Rails naming conventions, as you create new "instances" of objects (see Object-oriented programming explained ... in English!), they automatically get mapped to an appropriate database row -- without having to write any SQL code. This is really handy if you're doing a lot of data storage and retrieval.
Rails even elegantly connects objects in different database tables with a few lines of easy-to-understand code. If I'm saving stories in a database and will be searching later to see which ones were published on a certain date, I can easily define at the outset that PublishDate has_many :stories and Story belongs_to :publishdate in the files that define PublishDate and Story. It looks like this:
Class Story < ActiveRecord::Base
belongs to :publishdate
end
Class PublishDate < ActiveRecord::Base
has_many :stories
end
(ActiveRecord is a predefined Rails class.) With those simple, human-readable lines of code, a relationship is set up allowing me to find what stories have been posted on a given date. How? If mydate is a variable representing a specific PublishDate, I find all the stories on that date just by
mydate.stories
That's it -- a lot less code than I've been using to do database queries from PHP.
Another RoR development principle, Lenz notes, is "don't repeat yourself." I've been violating that ever more egregiously, and will be glad to get help streamlining my code. Discovering after the fact what code snippets I should have made into repeatable functions is a serious time sink, and I haven't found the knack of sketching that out ahead of time.