logo

 

     
 
Home
Site Map
Search
 
:: Bitwise Courses ::
 
Bitwise Dusty Archives
 
 
 

rss

 
 

ruby in steel

learn aikido in north devon

Learn Aikido in North Devon

 


Section :: Features
- Format For Printing...

Ruby On Rails – The Ten Minute Expert

Bluff your way in Rails with this simple guide...
Wednesday 31 January 2007.
 

Ruby On Rails is currently the programming equivalent of War and Peace – most people have heard of it, hardly anyone knows what it’s all about.

We all know the name of Tolstoy’s masterwork but very few of us ever get around to reading it – well, there never seems to be quite enough spare time! Similarly, lots of developers have heard the name ‘Ruby On Rails’ but very few of us have written any Ruby On Rails applications.

While I can’t help you to bluff your way in Tolstoy, I think I can save you a bit of effort with Rails. In this article, I’ll explain what the fuss is all about and help to guide you through the ideas, the technology and the buzz words.

See also: Ruby On Rails Tutorial : The Basics

So What The Heck Is Ruby On Rails, Anyway?

OK, so before going any further, let’s dispel one popular myth: Ruby On Rails is not a programming language. Ruby is a programming language and Rails is a ‘framework’ for Ruby. The name ‘Ruby On Rails’ is really just a more verbose way of describing Rails by emphasising the fact that it runs ‘on’ Ruby.

The core of Rails is a code library, written in Ruby, aimed at knitting together web pages, programming code and databases. The idea is that users can interact with a web page, say by entering some text into a field or clicking a button; this interaction triggers some Ruby code to process the data that’s been entered or to retrieve some data which the user has requested; and finally the data itself is accessed from a database and displayed in a web page.

This breaks down into a three part process called MVC (Model, View, Controller):

- Model: the stuff that deals with the database
- View: what you see in the web page
- Controller: the code that processes data as it passes between the Model and the View

The Model

Let’s take a concrete example. Suppose you write a Blog application in Rails. The Model will be the database and some Ruby code which interfaces to the database. This code may include some ‘validation rules’ to check that certain data fields (say the title of a new blog post) have been entered and some ‘relationship rules’ to define the connections between data fields (say that a single blog post may be associated with many comments whereas each comment belongs to just one post).

This is the actual code required to define these rules:

class Post < ActiveRecord::Base
        validates_presence_of :title
        has_many :comments
end

class Comment < ActiveRecord::Base
        belongs_to :post
end
The ‘Fifteen Minute Weblog’ is probably the most famous example of a Ruby On Rails application. You can watch the creator of Rails. David Heinemeier Hansson, creating this entire project in an online movie on the Ruby On Rails web site.

Even if you’ve never seen any Ruby code before, you can probably follow pretty much what is going on in the Ruby code shown above. That’s one of the cunning features of Rails. It lets you write Ruby code in a way that hides much of the complexity. In the example above, for instance, you don’t need to know exactly what ActiveRecord::Base is (in fact, Base is the name of a class inside the ActiveRecord module, and the classes Post and Comment are descendent classes of ActiveRecord::Base). Many Rails developers seem to get an awfully long way without knowing any of these things (see my views on their blissful ignorance HERE).

The View

When you develop a Rails application, you create one or more views in the form of HTML templates, some of which may be incomplete or ‘partial’ pages, with bits of Ruby code embedded between special ‘server-side include’ tags, <% and %>. An ‘embedded Ruby’ processing utility strips out the Ruby code, executes any other code required by the embedded Ruby (to access data, do some text processing or whatever) and constructs a fully-formed HTML page as a result. It is this Ruby-free HTML page which is displayed in the browser.

The Controller

Typically, the controller is the file which contains the bulk of the Ruby code. It may do all the sort of things that you might expect to do in any normal standalone application – calculate totals, format text, move the Adventurer into the Dark Forest and throw the Elvish Sword at the Troll, all that kind of thing. It’s the place in which data that is on its way between the Model and The View can be handled in any creative way that takes your fancy.

How Does Ruby Compare With Perl, PHP, Python…?

Ruby has many features in common with other interpreted languages. Unlike Perl, PHP and Python, it was conceived as an object oriented language from the ground up. Everything (well, almost everything) in Ruby is an object defined by a class. Until a couple of years ago, if you were to have compared Ruby with other languages, you might have concluded that it had most in common with Perl and Python – a ‘scripting’ language best used for writing relatively lightweight programs to do things such as disk or file operations, text processing and so forth.

But with the advent of Rails, Ruby has increasingly been seen as a rival to PHP – that is, a language that can be used for writing interactive, data-driven web applications. Ruby has a number of advantages over PHP: it is much more thoroughly object orientated, has a relatively easy to master syntax and (as an added bonus) it doesn’t look anything at all like C. Moreover, many people find that the Rails framework for Ruby greatly simplifies web development – though it has to be said that a number of Rails-like frameworks such as Code Igniter are now aiming to provide a similar blend of MVC power-and-simplicity for PHP programmers (indeed, there are now also some web frameworks for Perl and Python).

Another problem for Ruby On Rails is that it is not yet widely supported by hosting services (even the Bitwise host, Hostgator, does not support it). Rails does not integrate smoothly with the Apache server and some hosts feel that the whole Ruby and Rails technology is simply not yet mature. Things are moving fast in the Ruby world, however, and this situation could change significantly in the months and years ahead. It is still too early to predict how big a challenge Ruby On Rails may offer to PHP and its various frameworks. What’s for sure is that Ruby On Rails is definitely a technology to keep n eye on...

Want to know how to use Rails in practice? Stay tuned. We’ll have a series of hands-on Rails tutorials starting in Bitwise shortly…

See also: Ruby Off The Rails...?


Huw Collingbourne is co-developer of the Ruby In Steel IDE for Visual Studio 2005.


Jargon Buster

If you’ve spent your life programming in languages such as C++, Java and Pascal, some of the terminology used by Ruby and Rails developers may leave you flummoxed. Here are a few of the commonly used acronyms and buzzwords…

- DRY – “Don’t Repeat Yourself” – an old truism of computer programming which has been made surprisingly trendy by giving it this new acronym.
- “Convention Over Configuration” – Many of the relationships between different bits of a Rails applications are defined according to naming conventions rather than entries in configuration files. So, for example, a Ruby file called post.rb may contain a class called Post which deals with data from a database table called posts, which is manipulated by code in a file called posts_controller.rb which contains a method called show which is displayed in a web page defined by a template called show.rhtml (and so on…)
- CRUD – Create, Retrieve, Update and Delete – another newish acronym which tries to make boring old database operations sound cool.
- MVC – Model, View, Controller: at the risk of sounding pompous, this is a ‘software engineering design pattern’; put more simply, it’s a way of dividing up an application into the database stuff (Model), the user interface stuff (View) and the programming stuff (Controller). In Rails, you can mix bits of the M into the C and bits of the C into the V if you really want to but it’s generally thought better practice to keep each bit reasonably separate from each other bit.
- REST – a short way of avoiding having to say ‘Representational State Transfer’. Some Rails programmers pride themselves on being RESTful. What REST actually is would be impossible to describe in a few sentences here. Fortunately, the good people at IBM have saved me the trouble. I refer you to an article called ‘Crossing borders: REST on Rails’ by Bruce Tate.

AddThis Social Bookmark Button

Forum

  • Ruby On Rails – The Ten Minute Expert
    31 January 2007, by James Bennett

    Historical aside: Python’s been thoroughly OO since its beginning. And everything in Python is an object (though not necessarily everything is an instance of a class).

    • Ruby On Rails – The Ten Minute Expert
      1 February 2007, by Huw Collingbourne

      I admit that I may have been a little hasty in dismissing Python ;-)

      It is my understanding that Python implements a sort of hybrid OOP/procedural language (like Delphi et al) rather than a strict version of OOP (like Smalltalk or, up to a point, like Ruby). I confess a large degree of ignorance in this mattter, however. I’ll try to educate myself on Python in the coming year.

      best wishes

      Huw


Home