Ok, enough chit chat. let’s get started with our first real Ruby tutorial.
We are going to start our own weblog application. It makes sense, considering it is missing from this site :)
First things first: make sure you have ruby, rails, and mysqladmin in your PATH environment variable.
Under Windows, it is:
My Computer --> Right Click --> Properties --> Advanced --> Environment variables.Under Mac OS X, you need to edit .bash-login under your home directory. For me, it looks like this:
export PATH="/usr/local/bin:/usr/local/sbin:/usr/local/mysql/bin:/usr/local/mysql-5.0.37-osx10.4-i686/bin:$PATH"Second, pick a place on your home directory to store all your projects. I picked
~/Development/Projects/Ruby.
Now we’ll create our application skeleton. Open terminal, cd to your project directory, and type the following:
rails weblogYou should see a bunch of stuff being created. This is the rails framework working for you.
Now, let’s create our database. You can use the mysql GUI to do this, but that’s not geeky enough for us, is it... so in the command prompt, type the following:
mysqladmin -u root create weblog_developmentnotice the database name - it is exactly like our application’s name, ending with the “_development”. This is something you’ll see a lot in Ruby - it is called the “Convention over configuration” methodology. It means that a lot of things will just work together, if only you’ll agree to some pre-defined “rules”. one of these rules is that the database’ name is like the application’s name, ending with the development phase - it can be either development, testing, or production. You can see the configuration details under
config/database.yml.
The next thing we need to do is to migrate our database according to the application. We didn’t do anything just yet - we didn’t even write one line of code! But rails is doing a lot of things for us, and one of these things is to manage the database changes. In order to do it, it needs to setup a special table in our database, called
schema_info. This table manages our changes to the database. It allows us to “commit” and “rollback” any changes that we do to the database during development. It is directly connected to our code, as we’ll see later on. For a Java developer like myself, this is a huge leap forward.
So, in order to initialize our database for use with rails, we’ll write the following:
cd weblogfollowed by:
rake db:migrateYou can now open up the MySQL query browser and check the database
weblog_development. See that table called “schema_info”? It was just created for you automatically.
Next task: create our model. In Ruby on Rails, models are directly connected to their database counterparts. This means that if we create a model class named “Person”, it will have a database table called “people”. That’s right, rails knows that many persons = people. Pretty neat, ha? Of course, usually it will just be something like class=”Paper” and a table=”papers”.
Now let’s create our model for a log entry:
ruby script/generate model log_entryLook at the files that rails created for us. Especially pay attention to
001_create_log_entries.rb. Again,
log_entries, not
log_entry. I know it’s silly, but it’s still cool by my book :).
So what do we have inside that 001_create_log_entries.rb class? Well, this is our first change to the database. We want to create a new table in the database, called log_entries. And that’s exactly what the class contains:
class CreateLogEntries < ActiveRecord::Migration
def self.up create_table :log_entries do |t|
end end
def self.down drop_table :log_entries
end end
Not much here, is it? We’ll want to update this class to create the log_entries table.
class CreateLogEntries < ActiveRecord::Migration
def self.up create_table :log_entries do |t|
t.column :title, :string t.column :content, :text
t.column :author, :string t.column :creating_date, :date
end end
def self.down drop_table :log_entries
endend
The update basically tells the migration tool to generate a model containing the fields ‘title’ of type string, ‘content’ of type text, ‘author’ of type string and ‘creation_date’ of type date. Notice the form of writing: This one class will map the database to our newly created model. Notice the two methods we have here: self.up will be called when we build our database. self.down will be called when we rollback our changes.
Now let’s migrate the database to version 001. Once again:
rake db:migrateSweet. What just happened? Refresh your database and have a look. you should have a new table called “log_entries”, containing the fields title, content, author and creation_date.
Next: time to create our controller. The controller is the mediator between the view (the web page) and the model (which represents the database). We’ll call our controller ‘manager’. To create the controller, all we do is this:
ruby script/generate controller manager
Great. So now we have our model and we have our controller. What about our view? Well, we can write it, but we can also generate it using the scaffold command. Scaffold is an easy way to create some sort of a mockup version of our Webpage just to have something we can see on the page. We’ll create the view from our controller. Open manager_controller.rb and change it to look like this:
class ManagerController < ApplicationController
scaffold :log_entry end
This is it. We are done. We now have a working ruby application with a view, a controller and a model. Just think how much stuff you
didn’t do. To start your app, run the server script:
ruby script/server
Now point your browser to
http://localhost:3000/manager. You should see your app. Try creating some entries, editing entries and deleting entries.
