I'm a Rails newbie and eager to learn. I welcome any suggestions or criticism you have. You can direct them to my inbox or leave me a comment below.
I finally set myself up with a blog. I mailed my dad the address and mentioned that it was running Typo, which is written in Ruby on Rails. The fact that it is written in Rails was a big factor in my decision. I am currently reading Agile Web Development With Rails and it will be great to use Typo as a learning tool, since I will be modifying my blog anyways regardless of what language it's written in.
Clearly Rails made an impression on me somehow or I wouldn't be investing this time on it. But my dad asked me a very good question:
Rails? What is so special about it? I looked at your page and it looks pretty normal to me. I miss the point of this new Rails technique for web development.
It's unlikely that he was surprised at my lengthy response, but I was. I have been known to write him long messages on topics that interest me. However, I've only been learning Rails for two weeks or so. Could I possibly have so much to say about it already? Apparently I do.
Ruby on Rails background
I assume a pretty basic knowledge of what Rails is, so if you're not familiar with it now's a good time to read something on the official Rails website and watch the infamous 15-minute screencast, where Rails creator, David Heinemeier Hansson, creates a simple blog application.
The screencasts are what sparked my curiosity, but they hardly scratch the surface of Rails. After that I spent hours reading whatever I could find about Rails before deciding to take the time to learn it well. As a result, a lot of what you read here will sound familiar if you've read other blogs and articles about Rails. This post wasn't planned so there's no list of references yet. I hope to add some links though so please contact me if any ideas or paraphrasing here is from your site, or if you know who I should give credit to.
Rails through my eyes
Rails is like my Black & Decker toolkit. I have a hammer, power screwdriver, tape measure, needle-nose pliers, wire cutters, a level, etc. This is exactly what I need—no more, no less. It helps me get things done quickly and easily that would otherwise be painful and somewhat difficult. I can pick up the tools and use them without much training. Therefore I am instantly productive with them.
The kit is suitable for many people who need these things at home, such as myself. Companies build skyscrapers and huge malls and apartments, and they clearly need more powerful tools than I. There are others that just need to drive in a nail to hang a picture, in which case the kit I have is overkill. They're better off just buying and using a single hammer. I happen to fall in the big grey middle chunk, not the other two.
I'm a university student. I code because it's satisfying and fun to create software. I do plan on coding for a living when I graduate. I don't work with ancient databases, or create monster sites like Amazon, Google, or Ebay. The last time I started coding a website from scratch I was using PHP, that was around the turn of the millennium. [It was a fan site for a favourite band of mine.]
After a year or so I realized I didn't have the time to do it properly (ie. securely and cleanly) if I wanted it to be done relatively soon. A slightly customized MediaWiki promptly took it's place. It did all that I needed quite well, just in a less specific way.
The wiki is serving my site extremely well, but there's still that itch to create my own site. I feel if Rails was around back then I may have been able to complete the project in a timely manner. I was also frustrated with PHP. Part of that is likely due to a lack of experience and of formal programming education at that time, but it was still not fun for me. It wasn't until I started learning Rails that I thought "hey, I could create that site pretty quickly using this!"
Rails fits my needs like a glove, and this is where it shines. Many professionals are making money creating sites in Rails, so I'm not trying to say it's for amateurs only or something equally silly.
Web Frameworks and iPods?
Some might say I have merely been swept up in hype and am following the herd. You may be right, and that's okay. I'm going to tell you a story. There was a guy who didn't get one of the oh-so-shiny iPods for a long time, though they looked neat. His discman plays mp3 CDs, and that was good enough for him. The latest iPod, which plays video, was sufficiently cool enough for him to forget that everyone at his school has an iPod and he would be trendy just like them now.
Shocker ending: he is I, and I am him. Now I know why everyone has one of those shiny devices. iPods and web frameworks have little in common except that many believe both the iPod and Rails are all hype and flash. I've realized that something creating this kind of buzz may actually just be a good product. I feel that this is the only other thing the iPod and Rails have in common: they are both damn good. Enough about the iPod, everyone hates hearing about it. My goal is to write about the other thing everyone is tired of hearing about.
Why is Rails special?
So what makes developing with Rails different? For me there are four big things that set Rails apart from the alternatives:
- Separating data, function, and design
- Readability (which is underrated)
- Database migrations
- Testing is so easy it hurts
MVC 101 (or, Separating data, function, and design)
Now I'm sure you've heard about separating content from design. Rails takes that one step further from just using CSS to style your website. It uses what's known as the MVC paradigm: Model-View-Controller. This is a tried and tested development method. I'd used MVC before in Cocoa programming on Mac OS X, so I was already sold on this point.
- The model deals with your data. If you're creating an online store you have a product model, a shopping cart model, a customer model, etc. The model takes care of storing this data in the database (persistence), and presenting it to you as an object you can manipulate at runtime.
- The view deals only with presentation. That's it, honestly. An interface to your app.
- The controller binds the model to the view, so that when the user clicks on the Add to cart link the controller is wired to call the
add_product method of the cart model and tell it which product to add. Then the controller takes the appropriate action such as redirecting the user to the shopping cart view.
Of course this is not exclusive to Rails, but it's an integral part of it's design.
Rails, and Ruby, both read amazingly like spoken English. This code is more or less straight out of Typo. You define relationships between objects like this:
class Article < Content
has_many :comments, :dependent => true, :order => "created_at ASC"
has_many :trackbacks, :dependent => true, :order => "created_at ASC"
has_and_belongs_to_many :categories, :foreign_key => 'article_id'
has_and_belongs_to_many :tags, :foreign_key => 'article_id'
dependent => true means if an article is deleted, it's comments go with it. Don't worry if you don't understand it all, this is just for you to see some actual Rails code.
In the Comment model you have:
class Comment < Content
validates_presence_of :author, :body
validates_against_spamdb :body, :url, :ip
(I snuck in some validations as well)
But look how it reads! Read it out loud. I'd bet that my mom would more or less follow this, and she's anything but a programmer. That's not to say programming should be easy for grandma, but code should be easily understood by humans. Let the computer understand things that are natural for me to type, since we're making it understand a common language anyways.
Ruby and Ruby on Rails allow and encourage you to write beautiful code. That is so much more important than you may realize, because it leads to many other virtues. Readability is obvious, and hence maintainability. You must read code to understand and modify it. Oh, and happy programmers will be more productive than frustrated programmers.
Here's one more life-saver: migrations. Migrations are a way to version your database schema from within Rails. So you have a table, call it
albums, and you want to add the date the album was released. You could modify the database directly, but that's not fun. Even if you only have one server, all your configuration will be in one central place, the app. And Rails doesn't care if you have PostgreSQL, MySQL, or SQLite behind it. You can develop and test on SQLite and deploy on MySQL and the migrations will just work in both environments.
class AddDateReleased < ActiveRecord::Migration
add_column "albums", "date_released", :datetime
Albums.update_all "date_released = now()"
remove_column "albums", "date_released"
Then you run the migration (
rake migrate does that) and boom, your up to date. If you're wondering, the
self.down method indeed implies that you can take this the other direction as well. Think
rake migrate VERSION=X.
Along with the other screencasts is one on migrations featuring none other than David Hansson. You should take a look, it's the third video.
Testing so easy it hurts
To start a rails project you type
rails project_name and it creates a directory structure with a fresh project in it. This includes a directory appropriately called test which houses unit tests for the project. When you generate models and controllers it creates test stubs for you in that directory. Basically, it makes it so easy to test that you're a fool not to do it. As someone wrote on their site: It means never having to say "I introduced a new bug while fixing another."
Rails builds on the unit testing that comes with Ruby. On a larger scale, that means that Rails is unlikely to flop on you because it is regularly tested using the same method. Ruby is unlikely to flop for the same reason. That makes me look good as a programmer. If you code for a living then it's of even more value to you.
I don't know why it hurts. Maybe it hurts developers working with other frameworks or languages to see us have it so nice and easy.
Rails means I have fun doing web development instead of being frustrated (CSS hacks aside). David Hansson may be right when he said you have to have been soured by Java or PHP to fully appreciate Rails, but that doesn't mean you won't enjoy it if you do like Java or PHP.
Justin Gehtland rewrote a Java app using Rails and the number of lines of code of the Rails version was very close to that of the XML configuration for the Java version. Java has strengths, libraries available now seems to be a big one, but it's too big for my needs. If you're like me then maybe you'll enjoy Rails as much as I do.
You're not done, you lied to me!
Sort of... there are a few things that it seems standard to include when someone writes about how Rails saved their life and gave them hope again. For completeness sake, I feel compelled to mention some principles common amongst those who develop Rails, and those who develop on Rails. It's entirely likely that there's nothing new for you here unless you're new to Rails or to programming, in which case I encourage you to read on.
Rails follows the DRY principle religiously. That is, Don't Repeat Yourself. Like MVC, I was already sold on this. I had previously encountered it in The Pragmatic Programmer. Apart from telling some_model it
belongs_to :other_model and other_model that it
has_many :some_models nothing has jumped out at me which violates this principle. However, I feel that reading a model's code and seeing it's relationships to other models right there is a Good Thing™.
Convention over configuration (or, Perceived intelligence)
Rails' developers also have the mantra "convention over configuration", which you can see from the video there. (you did watch it, didn't you? ;) Basically that just means Rails has sane defaults, but is still flexible if you don't like the defaults. You don't have to write even one line of SQL with Rails, but if you need greater control then you can write your own SQL. A standard cliché: it makes the simple things easy and the hard possible.
Rails seems to have a level of intelligence which contributes to the wow-factor. After these relationships are defined I can now filter certain negative comments like so:
article = Article.find :first
for comment in article.comments do
print comment unless comment.downcase == 'you suck!'
Rails knows to look for the field article_id in the comments table of the database. This is just a convention. You can call it something else but then you have to tell Rails what you like to call it.
Rails understands pluralization, which is a detail but it makes everything feel more natural. If you have a Person model then it will know to look for the table named people.
Code as you learn
I love how I've only been coding in Rails for a week or two and I can do so much already. It's natural, concise and takes care of the inane details. I love how I know that I don't even have to explain that migration example. It's plainly clear what it does to the database. It doesn't take long to get the basics down and once you do it goes fast.