Ruby is a modern, general-purpose, high-level, dynamically typed programming language, well suited for writing Web applications.
Ruby on Rails (called Rails for short) is a "framework" for Web application development that uses Ruby. Rails is designed to allow Web application developers to be more productive. It is based on two main principles:
The first principle means that all Rails developers are encouraged by the framework to use the same conventions, to remove variation, to remove choice, all of which faciliates collaboration and increased productivity.
The second principle means that developers can be more productive by avoiding repeated tasks required in earlier frameworks.
These principles mean that some Web applications can be developed very quickly in Rails. However, as the specifications become more complex and departs further from "convention", development inevitably becomes more time-consuming. (But still less time-consuming than using PHP, for two equally competent developers.)
There is an active and growing Rails developer community in Australia and internationally.
There are many jobs for Rails developers in Australia and internationally. (But not as many as there are for PHP developers.)
Rails consists of some Linux commands, some core libraries, and many contributed libraries. (Contributed libraries are called "gems", based on a Ruby convention!)
To be a PHP developer, if you want to do something, you have to write code to do it.
To be a Rails developer, if you want to do something, you have to search for a gem that already does it, and learn how to use that gem.
These are two different skills.
To be fair, there are PHP-based frameworks emerging that are similar to Rails. An example is Laravel. However, it is hard (for me) to imagine that these can be as good as Rails, since Ruby is a much better language than PHP.
I propose to teach Rails largely by example. To a large extent, I will present a simplified version of the sample app in the tutorial by Michael Hartl below. I will also refer to examples in the official "getting started", and the two other books by Kehoe and Ruby et al.
However, I will also try to describe how to perform many common Web application tasks (e.g., pagination, user-initiated search) independently of the running example.
The best way for you to learn is by doing! The laboratory tasks are designed to lead you towards an implementation of the application in the two assignments. (Sometimes) I give detailed instructions, but you need to try to understand the (somewhat unusual) Rails terminology and concepts as you carry out these instructions.
It's important to save your work as you go using Git and BitBucket.
It's important to write down the Rails commands you give, so you can refer to them as well as to the code they generate.
This example is from Chapter 2 of Hartl's Tutorial.
It demonstrates the use of "scaffolds" to produce a simple dynamic application involving users and microposts (aka tweets).
To create the application, all you have to do is this:
# Create a new app rails new demo_app cd demo_app # Create a user "scaffold" rails generate scaffold User name:string email:string rake db:migrate # Test in browser rails server # run this in a separate console window
A few commands and we have a working dynamic Web application. Amazing!
But, the application has the following limitations: no validation, authentication, layout, tests, understanding, etc.
# Create a micropost "scaffold" rails generate scaffold Micropost content:string user_id:integer rake db:migrate
In file app/models/User.rb, add
In file app/models/Micropost.rb, add
This is impressive, but there are limitations: no proper home page, author of micropost shown by id not name, can create a micropost by a nonexistent user (lack of validation), can't view microposts by a given user, etc.
Scaffolding is simple but inflexible. We'll reconstruct this example, without scaffolding, removing all the limitations, adding more features, in subseqent lectures.