Beginning Rails

A little engineering on Rails

Robert W. Hasker

Goals

•
Intro to the Rails framework

▫
Basic concepts: MVC, Active Record

▫
A bit of Ruby

•
Using Rails to build a website

•
Myths and issues

The Rails Framework

•
Basic goal: construct database
-
backed websites

•
Multi
-
platform: popular OS’s, database engines

•
Origins:

▫
Instiki

by David
Heinemeier

Hansson

▫
Basecamp

by 37signals

▫
Rails: domain
-
independent core

•
Built on the Ruby language

▫
General
-
purpose language: scripting, applications

▫
Dynamically typed, “open” classes

Basic Concept: MVC

•
Issue: how to separate logic from presentation?

•
Classic solution: Model/View/Controller

▫
Model: domain
-
level data

▫
View: how the data is presented to the user


Typically want multiple views

▫
Controller: logic linking the two

•
Rails

▫
Model


= tables in a relational database

▫
View


= web pages

▫
Controller

= controller

Basic Concepts: Active Record

•
Relational Databases: organize large amounts of
data

▫
Issue: no easy mapping to object
-
oriented design

•
Active Record Pattern

▫
A design pattern first described by Martin Fowler

▫
Object = table row w/ attributes stored as columns

▫
Table = collection of objects

▫
OOD = database (collection of tables)


Rails: link classes through id fields in tables

Active Record Example

•
Data for a simple voting system:






•
As tables:

▫
create table questions (id
int
, body text,
start
datetime
, end
datetime
, primary
key(id));

▫
create table voters (id
int
, username text,
password text, primary key(id));

▫
create table
vote_records

(
voter_id

int
, …);

•
Benefit: can add operations as needed
-

active

records

Using rails to build a voting application




•
See
http://www.uwplatt.edu/csse/tools/ruby/rails/rails
-
demo.html

Conclusion

•
Rails: quick OO websites

▫
MVC: sound organization

▫
ActiveRecord
: support good OO designs


Focus on relationships, not queries


Less likely to forget a join, but supports full SQL


Not shown: does support inheritance


Navigation: keep the class diagram close at hand!

Conclusion…

•
Design

▫
DRY: don’t repeat yourself

▫
Convention, not configuration

▫
Relationships are declared explicitly

▫
Scaffolding: quick data entry (prototyping only)

▫
Great development environment


has full debugging support; separate dev/prod db’s

▫
Supports JavaScript/Ajax/etc.


Explore Ajax support next time


Myths & Issues

•
Myth: slow sites, doesn’t scale

▫
Supports many web servers

▫
Many optimizations probably belong elsewhere

▫
Technology improving

•
Myth: only for specific types of projects

▫
Source: lots of simple examples out there

▫
Can

handle big problems

▫
Don’t have to involve a database

▫
See
http://wiki.rubyonrails.org/rails/pages/RealWorldUsagePage1

•
Issues

▫
Active Records: should have Table classes

▫
Ruby: run
-
time type checking requires lots of testing!


But has good built
-
in testing support!

▫
Developers tempted to use all
–

pick level and stick to it



Resources

•
Online tutorials

•
Classic text:
Agile Web Development with Rails

•
Starting points:

▫
http://guides.rubyonrails.org/getting_started.html

▫
Beginning Rails: From Novice to Professional


In library, but based on Rails 1.x

▫
Beginning Rails 3


Available soon

•
More detail:
The Rails Way