Building Web-based Software with Ruby and Ruby on Rails

John G. Norman
Last revised: 26-Sep-2007

Overview

This course is a thorough introduction to Ruby and Ruby on Rails, focusing especially on the Rails sweet spot: Rapid prototyping and iterative development. The course culiminates in the design and implementation of a web-based software product.

Pre-requisites

We assume that you already know one higher-level object-oriented language (Java, C, C++, C#, VB, (sophisticated) Perl…), have done some web development, and understand the relational database model. Web development is essentially the simultaneous orchestration of multiple skills; if you are significantly weak in your solid understanding of at least one programming language, how the web works, or databases, you will have a difficult time with the course. NOTE: When I originally defined the pre-reqs for this course, I said: “already know one higher-level object-oriented language,” but the object-orientation got lost at some point. This is important; if, say, you only know PHP, or non-OO Perl, you may be at a deficit for this course. Thus I will be assuming that I can talk about “classes” and “instances” at a fairly high level without having to get bogged down in defining inheritance, polymorphism, etc.

Calendar

The course lectures will be Wednesday evenings starting at 7:35 PM, for about two hours each. The first meeting will be on Wed., 19 Sept. The Wednesdays on which we won’t meet, due to official Extension holidays, are Nov. 21 and Dec. 26. Note that there is a meeting in January 2008 on the 2nd. This will likely be a date on which students will demo work in progress (we’re aware of the fact that the 2nd is probably not the best day for everyone, so we will schedule some extra meetings in January for demos). Thus there will be 14 official meetings.

NOTE: Two important dates to watch out for: to drop (Harvard politely calls it “withdrawing”) with a full refund you need to take care of that with Extension by end-of-day 30-Sep.; for a half-refund by end-of-day 8-Oct.

Attendance policy

The course meets in Harvard Hall 102 (map).

Strict attendance is not required but you should come to as much as you can. For some students, section will turn out to be crucial. While there is a lot you can learn by studying the lecture slides, reading the texts, reading e-mail and/or on-line course discussion, and doing the assignments, you will most certainly find that there is a lot of important teaching and learning that can only be captured in person.

Sections

(Note: May change.) There will be two sections. You will be assigned randomly to a section, though we will swap if we can. Both will meet in 51 Brattle Street, room 119. One section will be at 6 PM Wednesday, the other at 7:35 PM Monday.

Assignments

There will be 5 assignments plus a final project, and perhaps occasional quizzes and other exercises. Briefly, the weights will be close to the following (subject to tuning):

Assignment 1 (due 30-Sep.) - System setup: 5%
Assignment 2 (due 7-Oct.) - Ruby One-Liners: 10%
Assignment 3 (due 21-Oct.) - Ruby application: 15%
Assignment 4 (due 18-Nov. [new date]) - ActiveRecord: 15%
Assignment 5 (due 9-Dec.) - Action Pack (controllers and views): 20%
Final Project (due in January): 30%
Quizzes, exercises, participation, etc.: 5%

Each of assignments 2 to 5 will require at least 4 hours of work at home — this is work beyond coming to class, reading the materials, experimentation, etc. There will be some who can whip off the assignment in an hour, others who will take 8 hours or more; we will monitoring this closely. Note that for many of the assignments there will be a required writeup or documentation: This is a critical and crucial part of the assignment, so even if the code is great, your submission may be problematic and get downgraded.

There are no extensions; if you’re not completely done, hand in whatever you have and you will receive partial credit. Your section leader is also your grader.

Grading

Very generally, grades on individual submissions will be based on the standard Harvard scale (http://extension.harvard.edu/2007-08/register/policies/grades/). For more detail, see the notes on grading after the schedule.

Required software versions

(Subject to revision — see the first assignment for the definitive list.)

  • Ruby 1.8.6 [1.8.5 is ok]
  • RubyGems 0.9.2
  • Ruby on Rails 1.2.3
  • Mongrel 1.0.1
  • MySQL 5.0.x
  • mysql gem 2.7.3

Required texts

PR: Thomas, et al., Programming Ruby, 2d ed. (2004), also known as the “pickaxe.” [Amazon] NOTE: Errata (fixed errors in the book) at http://books.pragprog.com/titles/ruby/errata (print this out and put it in your book) and code at http://www.pragmaticprogrammer.com/titles/ruby/code/index.html

AWDR: Thomas and Heinemeier Hansson, Agile Web Development with Rails, 2d ed. (2006) [Amazon] Errata at http://books.pragprog.com/titles/rails2/errata and code at http://www.pragmaticprogrammer.com/titles/rails2/code.html

Recommended texts

See http://e168f07.7fff.com/resources/books/

Schedule

In the schedule, we sometimes indicate a “Gem of the Week.” At times it will be a proper Ruby Gem (installable code module or component), at other times a screencast, demo, or tool.

Introduction

Week 1 (19-Sep)

  • Why Ruby? Why Ruby on Rails? Why Now?
  • Installation and setup
  • irb
  • ri
  • Demo of quick “Hello, world!” app
  • Demo of quick web app

Gem of the week: One-click Ruby Installer for Windows
Recommended reading: PR 1, 2 (skim), 15
Assignments 1 and 2 handed out; Assignment 1 due Sunday, 30-Sep.; Assignment 2 due Sun., 7-Oct.

Ruby Fundamentals

Week 2 (26-Sep)

  • Numbers
  • Strings
  • Arrays
  • Hashes
  • Yield and blocks — getting started

Recommended reading: PR 2, 3 (skim), 4, 12, 16

Week 3 (3-Oct)

  • Control structures
  • Regular expressions
  • Classes, objects, variables
  • Duck typing
  • Access control, visibility, inheritance, scope
  • More on blocks, yield, and iterators

Gem of the week: Editors (screencast)
Recommended reading: PR 3, 4, 5, 6, 7, 22 (read to fill in gaps), 23
Assignment 3 handed out; due Sun. 21-Oct.

Week 4 (10-Oct)

  • Modules
  • exceptions, catch and throw
  • dynamic Ruby
  • Ruby idioms

Gem of the week: TBA
Recommended reading PR 8, 9, 24 (read to fill in gaps)
Developing with Ruby on Rails

Week 5 (17-Oct)

  • Rails Overview
  • Demo of the Rails development process

Gem of the week: TBA
Recommended reading: AWDR 2, 4, 5, skim 6-8 and 10
Assignment 4 handed out; due Sun. 18-Nov. [new date]
NOTE: The assignment download includes a quiz (in the main “instructions” file), due late Sunday November 4th.

Week 6 (24-Oct)

  • SQL/relational refresher
  • Migrations
  • Active Record

Gem of the week: TBA
Recommended reading: AWDR 16, 17, 18, 19

Week 7 (31-Oct)

  • Testing and RDoc

Gem of the week: TBA
Recommended reading: AWDR 13

Week 8 (7-Nov)

  • More Active Record

Gem of the week: TBA
Recommended reading: AWDR 16, 17, 18, 19
Assignment 5 handed out; due Sun. 9-Dec.

Week 9 (14-Nov)

  • Action Controller and routing

Gem of the week: TBA
Recommended reading: AWDR 20 (up to p. 406), 21
…Happy Thanksgiving! (No class, 21-Nov)

Week 10 (28-Nov)

  • Action View

Gem of the week: TBA
Recommended reading: AWDR 22

Week 11 (5-Dec)

  • Action Mailer
  • Guest: David Berube, author of Practical Ruby Gems [Amazon]: Creating your own Gem

Recommended reading: AWDR 24

Week 12 (12-Dec)

  • Rails support for AJAX

Gem of the week: TBA
Recommended reading: AWDR 23

Week 13 (19-Dec)

  • Rails support for REST

Gem of the week: TBA
Recommended reading: AWDR 20 (pp. 407ff)

Week 14 (2-Jan)

  • Student demos of work-in-progress (REQUIRED)

There will be additional dates for this if the 2nd is bad.

FINAL PROJECT DUE DATE: TO BE ANNOUNCED.

Notes on Grading

Harvard Extension has some official policies on grades:

http://extension.harvard.edu/2007-08/register/policies/grades/

Grading has subjective and objective components, and you’ll see that in the following notes on grading.

Some general notes:

1. We take documentation very seriously. A submission without documentation or with lousy documentation that can’t be understood will most certainly result in a lower grade.

2. If we comment on an issue and it persists, it will weigh more heavily in our assessment.

3. We reserve the right to assign grades according to our perception of the quality of the submission in accordance with the Harvard letter grade system, which says, for instance, that “B+, B, and B- grades represent work of good to very good quality . . . however, it does not merit special distinction.” I.e., in some cases, it may be difficult to assign a grade in as objective a manner as we would like, and it will be more appropriate to make a holistic assessment. It is also by this means that we can give credit for intangibles or for contributions that are not strictly required by the course, such as outstanding observations during section.

Operationally, we will grade as follows:

Each major assignment will be worth 100 points; the points will be broken down into categories (documentation; passes tests; code organization; code quality; etc.) and each category will be given points separately, according to the standard Harvard scale.

We will adjust the standard Harvard 4.0 scale to percentages. E.g., at Harvard a B is 3.0, so 75% of 4.0.

Let us say that the first assignment has the 4 categories above, and the points are evenly distributed — each category getting 25 points. If the grader believes that your performance was around a B (good to very good) then you would get 75% of the 25 points for that category (about 18 or 19 points). Then we add them up to get the total.

The upshot of this is that we will maintain a big spreadsheet representing your performance, and will be able to take a longitudinal look at the different components of your work.

In many cases, we will have some rules of thumb for deducting points based on commonplace issues. For example, we may decide that we will take 2 points off from the “code quality” section if you don’t declare code literals as constants. Or it may be that we find that we need to take off 5 points from the top for flagrant missed opportunities to use common Ruby idioms in your code.