Delphi to Rails

One of the weirdest things in Ruby that took me a long time to figure out was blocks. They’re actually quite simple, but if you’re spending time learning Rails, and not focusing on learning Ruby it’s easy to assume it’s some kind of incomprehensible magic built into Ruby’s syntax.

Blocks are actually highly cool. They’re similar to Anonymous Methods in other languages — simply a block of code that gets passed to a function.

There are two ways to define a block. The first is with curly-brackets: { and }. While it’s not strictly enforced, this form is usually used on a single line, like so:

{ somevariable = 10 }

The second way is with do and end. This form is usually used over multiple lines, like so:

do
  somevariable = 10
  someothervariable = 22
end

Blocks are commonly passed to functions, and often are used on sets of things or loops.

12.times { thing.do_something }

['gordon', 'jamie', 'anthony'].each do |chef|
  tv_show.host(chef)
end

That second example shows passing parameters into a block. The pipe characters indicate the names of the variables being passed in. In this case, the tv_show object is being asked to use each item in the array as the host. You may have seen this one in rails controllers:

respond_to do |format|
  format.html
  format.xml { render :layout => false }
end

This is actually using two blocks! The first is being passed to respond_to, which is returning a format object. Then, the various formats are being called on it, html and xml. The format.xml call is being passed a block, calling render.

Once you get your head around using blocks and the various block methods like .each, you’ll find your code getting much more elegant! In fact, using the contents of hashes and arrays gets a lot easier when you’re using .each than trying to use them they way you might use them in Delphi. For hashes, each passes two variables, key and value:

my_hash = { :show => 'kitchen nightmares', :host => 'gordon' }
my_hash.each do |key, value|
  puts key
  puts value
end

Understanding blocks is critical to understanding how to effectively use Ruby, and by extension, Rails.

I am a tool junkie, and I’m not afraid to admit it. Way back in my Clipper days, there used to be this thing called the Zac catalog. It was a casually-written, sometimes funny booklet put out quarterly with lots of tools for Clipper developers. Why spend weeks or months writing complex features when, for five hundred bucks you could just buy it and not worry about it? Genius!

When I moved to Delphi in 1995, an amazing thing happened. Partly fostered by Borland, and partly a side effect of how easy it was to extend the VCL, writing third-party code that could easily be integrated into any program was accessible to the masses. This spawned a huge number of third-party components available for free, as open source, and commercially. Sites like Torry’s Delphi Pages, the Delphi Super Page and Delphi Pages all thrived. There was even something like the Zac catalog for Delphi components! TurboPower, Developer Express and other companies started making very high quality, very powerful visual and non-visual tools that could make programs written by some guy in his basement look like they came out of Microsoft, and that was amazing. And for the most part, the prices were pretty reasonable — free, up to a few hundred bucks, with most selling for about $50 or so.

Installing these components, especially in the early days of Delphi 1 and 2 was a little scary. You had to modify a file to include the new component libraries, and then rebuild your library. Starting from Delphi 3, packages made installing new tools much easier (though it also introduced a bag of pain that I won’t go into, the dreaded “The specified procedure could not be found” errors!)

Well, Ruby and Rails both have ways to add additional functionality into your programs, too! You can install them so they’re available globally to all your programs (gems), or just to a specific rails application (plugins, vendored gems).

The Old Way of adding additional functionality to a rails application is to use script/plugin. You find a plugin (say, at Agile Web Development‘s plugin list), and type ruby script/plugin install path/to/plugin. This downloads and installs the plugin in the proper place in your application, and is immediately available.

The benefit of this is that it’s easy, but there are problems updating plugins with multiple versions and so on, so most new libraries are released as gems. Gems are ruby add-ons, and you may remember back in my getting started post, rails itself is a gem! Adding gems is also easy, just run gem install gemname. (If you’re on a Mac or other Unix-based system, you will likely need to run sudo gem install gemname).

Once a gem is installed, you can generally make use of it right away, though some gems may require some unique configuration, but that’s usually documented in the readme file.

One last thing: many people, myself included, recommend that you vendor your gems. This means you are making a copy of the gem in your application. This removes any dependencies on a specific version of the gem being installed — you can update your system gems without it affecting your application. It also makes it easier to deploy, especially if you don’t have complete control over your server.

Rather than reiterate what others have said better than I could have, I’ll just link to the excellent Vendor Everything post on err.the_blog.

One of the best parts about the Rails community is how many free and open source gems and plugins are available. There are even a few commercial items, but far fewer than Delphi has. Still, a strong third-party ecosystem means better, easier and faster programming.

You’ll find the lion’s share of them at github, but they’re kind of scattered all over the place, so explore a little and you’ll find all kinds of cool ones.

Here are a few that I’m quite fond of: AuthLogic (very slick user authentication), Paperclip (attaching files to models), Haml (replacement for .erb files), chronic (date and time entry), and will_paginte (easy paging for large lists).

One of the things I loved more than just about anything else about Rails was the way it handles databases. Specifically, changing the structure of databases as you make changes to your code.

Remember the other day when I said that running script/generate model would create a table in the database? Well, I lied, kind of. It doesn’t create the table itself, rather, it creates a migration file. The table isn’t actually created until you run the following command:

rake db:migrate

This checks the database to see what migrations have not yet been applied, then applies them in the order they were created.

Now, coming from Delphi, you might me more familiar with using tools like Database Desktop or MS-SQL’s Database Manager or even Microsoft Access. You use these tools to visually create your tables, and then access those tables using TQuerys (or other TDataSet classes)

What happens when you need to modify your database structure? Well, if you’re like me, you’ve probably written a whole lot of SQL scripts and you’ve written a database upgrade program that runs the SQL scripts and applies the changes.

Though if you’re like me, you’ve probably forgotten to do that sometimes, and ended up with a customer with data that doesn’t work because you didn’t add the fields you were supposed to.

Enter Rails migrations. These are created automatically whenever a model is generated, and you can generate new ones any time you want to in order to modify the database. This manages the complete history of the database structure for you, so that you don’t need to worry about it. You can always migrate your database back and forth as required.

No more missing SQL scripts. No more forgetting data changes. For the most part, it’s all handled for you!

Migrations are Ruby files, marked with a timestamp and a name, something like this:

20090203112033_create_people_table.rb

The timestamp helps prevent any version number conflicts that might happen when you’ve got a bunch of people all working on the same project. It acts as the version number for the database.

Here’s what a migration looks like:

class CreatePeople < ActiveRecord::Migration
  def self.up
    create_table :people do |t|
      t.string :first_name
      t.string :last_name
      t.string :title
      t.timestamps
    end
  end

  def self.down
    drop_table :people
  end
end

Notice that this class has two methods: up and down. The up method is what is done when you’re applying this change to the database. The down method undoes what you did, reverting the database to its previous state.

I can’t stress enough: this code is all generated for you. In many cases, especially when adding tables or columns, you won’t need to change it at all.

This all fits in very well with the so-called Agile way of software development, where you iterate and test frequently. Create a table with what you need now, and don’t worry about fields you might need sometime down the road. You can add those later without hassle.

So, let’s say we wanted to add an email address field to the table, how do we do that? First, we generate the migration. Notice the naming conventions I use:

ruby script/generate migration add_email_to_people email:string

Rails is smart enough to know that when you say add something to X, X is the table you want to add the field to. Then, you list the fields and types. Rails creates a new migration file that looks like this:

class AddEmailToPeople < ActiveRecord::Migration
  def self.up
    add_column :people, :email, :string
  end

  def self.down
    remove_column :people, :email
  end
end

To apply this migration, we run rake db:migrate just as before.

You can even manipulate data using the models if you need to, but I'll talk about that in a future posting.

Sorry this is a little late, my computer had a tantrum and needed to be beaten into submission by the kindly folk at the Apple Store.

Accessing data in Delphi is simple. You drop a TQuery on your form, and you edit the SQL property, and code the SQL. Then you connect it to a TDataSource, and hook that TDataSource to any components you want to have access to the data, set Active to true, and shazam!

Well, that’s not really that simple, because you need to write the SQL, and there’s a lot of connecting to do, and let’s face it, often you don’t want to bother with dropping components on a form, so you write code like this:

procedure DoSomething;
var
  Users : TQuery;
begin
  Users := TQuery.Create(nil);
  try
    Users.Database := SomeDatabase;
    Users.SQL.Text := 'select * from users';
    Users.Open;
    while not Users.EOF do
      // do something!
    Users.Next;
  finally
    FreeAndNil(Users);
  end;
end;

Come now, we’ve all done it, quickly whipped up some code to open a dataset and do something with it. However, you might have heard that this isn’t a good way to do things, that you should separate out a “database access layer” and do everything through that. There are even a number of very good, and very popular tools for doing that in Delphi.

Well, in Rails, there’s something that does that, too, called ActiveRecord. With ActiveRecord, the code above looks like this:

User.find(:all).each do |u|
  u.do_something

OK, I fibbed a little. There is one thing you need to do, once, before you do that.

ruby script/generate model User name:string password:string

You run that on the command line, and Rails creates a database table called users (with the fields id, name, password, created and updated dates) and a model called User, which you can then use anytime you please. When you make the call to User.find(:all), ActiveRecord generates an SQL query tailored to the database you’re using.

This is called Object Relational Mapping, or ORM. There’s lots of ways to do it, but ActiveRecord is how Rails handles this by default.

The model, which will be located in the app/models folder, looks like this:

class User < ActiveRecord::Base

end

What about relationships? Well, ActiveRecord handles one-to-one, one-to-many and even many-to-many relationships, out of the box. Let’s say you have two models, User and Account. The users table has a field called account_id. To let Rails know that these models are related, you add a function call into the class declaration. Weird, I know, but just watch:

class User < ActiveRecord::Base
  belongs_to :account
end

class Account < ActiveRecord::Base
  has_many :users
end

Then, you can write code like this:

u = User.find :first
  print u.account.name

The User model has an account property, and the Account model has a users property (which acts as a collection of users). Suddenly, you have a lot less to think about!

While some feel this isolates you too much from the SQL, so ActiveRecord does supply a lot of methods to get down and dirty with conditions and even whole SQL statements, but for now we’ll keep it simple and end it here.