CSCI E-168

Attached is the quick and dirty multiple model form from today’s section.

Click here to download.

Here’s a blog post summarizing new features for Java 7:

http://code.joejag.com/2009/new-language-features-in-java-7/

The new features are:

• Language support for collections (like Ruby . . . but apparently still no Hash literal — probably way too late to wedge that in)
• Automatic resource management (like Ruby’s IO objects that yield a reference to a block . . . but looks far less general)
• New type inference operator
• Underscores in numeric literals (1_000_000) (like Ruby)
• Strings in switch statements (like Ruby . . . but only for Strings, so no ‘case equals’ operator)
• binary literals (like Ruby)
• Simplified varargs

Another completed project from the Sunday section.

This application makes use of the following:

• form_for
• Partials for DRYness
• has_many :through where tables and foreign keys don’t match
• collection_select drop downs
• named_scope and default_scope

Click here to download the completed application.

Interesting post from a Django-ist:

http://jacobian.org/writing/thank-you-rails/

I think I’ve recommended this book before: Eldon Alameda’s Practical Rails Projects.

It has a sweet chapter on building a RESTful application, and shows very well how the controllers should be “rescoped” to work only on data that is appropriate. This “rescoping” is part of the requirements for Assignment 4 (requirement #5 about not letting users edit data “owned” by another user).

That chapter is a free download:

http://www.apress.com/book/view/1590597818

For those of you who burn the midnight oil, as I do . . .

The download for Assignment 4 (and 5) is available on the downloads page. I’ll send an e-mail tomorrow morning (the Harvard e-mail service is unavailable from 1 AM to 4 AM!!).

Say you have a model called Match with attributes wins and losses, both of type integer.  To this model you add validation to ensure these attributes are only integers:

class Match < ActiveRecord::Base
 validates_numericality_of :wins, :only_integer => true
 validates_numericality_of :losses, :only_integer => true
end

Then, in script/console:

>> m = Match.new
=> #<Match id: nil, wins: nil, losses: nil, created_at: nil, updated_at: nil>
>> m.wins = "seven"
=> "seven"
>> m.losses = "five"
=> "five"
>> m
=> #<Match id: nil, wins: 0, losses: 0, created_at: nil, updated_at: nil>
>> m.valid?
=> false

The strings have been cast as integers, but why does the validation fail?  The answer is that ActiveRecord stores much more information than what shows up as instance attributes.

>> m.attributes_before_type_cast
=> {"created_at"=>nil, "losses"=>"five", "updated_at"=>nil, "wins"=>"seven"}

An indepth look at all of the machinery of ActiveRecord might be a course in itself, but I thought this would provide a taste of the breadth and depth of the ORM.

Agile Web Development with Rails, 17.4 and 17.5, covers this subject.

On page 307 of the PDF, Migrating Data with Migrations, the basic scheme you might use is demonstrated.  As another example, suppose I create a users table and model:

$ ./script/generate model users first_name:string last_name:string

The migration looks like this:

class CreateUsers < ActiveRecord::Migration
 def self.up
   create_table :users do |t|
     t.string :first_name
     t.string :last_name

     t.timestamps
   end
 end

 def self.down
   drop_table :users
 end
end

After adding a number of users, it becomes clear that a full_name attribute would be very useful:

$ ./script/generate migration AddFullNameToUser full_name:string

This new migrations looks like this:

class AddFullNameToUser < ActiveRecord::Migration
  def self.up
    add_column :users, :full_name, :string
  end

  def self.down
    remove_column :users, :full_name
  end
end

Before running it, I add the line to update the users:

class AddFullNameToUser < ActiveRecord::Migration
  def self.up
    add_column :users, :full_name, :string
    User.find(:all).each do |u|
      u.full_name = u.first_name + ' ' + u.last_name
      u.save!
    end
  end

  def self.down
    remove_column :users, :full_name
  end
end

An important note here:  I did not use update_all because string concatenation is not portable between database engines (|| for Oracle, postgres and sqlite3, + for SQL Server and Sybase,  concat for MySQL, etc).

As John demonstrated in his migrations 3 example, depending on what you are trying to accomplish, the down method may not be data preserving.

Beyond the above and similar data manipulation, section 17.5 covers ways to execute fragments of native SQL or arbitrary SQL.  Using this functionality is beyond the scope of this course and of course has the significant downside of being much less portable.

A couple of weeks ago I mentioned the “cheat” gem which has a plethora of useful quick docs on various topics such as regular expressions. I breezed through the install — and fix for Ruby 1.9.1 — here it is, for the record:

gem install cheat
# NOTE: If you're on Linux or OS/X and have a standard install (rather than using the ruby_switch.sh script, you want to do sudo gem install cheat)

If you run it under 1.9.x, you should get an error like so:

cheat regexp
/Users/jnorman/.gem/ruby/1.9.1/gems/cheat-1.2.1/lib/cheat.rb:150:in `cache_dir': uninitialized constant Cheat::PLATFORM (NameError)
	from /Users/jnorman/.gem/ruby/1.9.1/gems/cheat-1.2.1/lib/cheat.rb:16:in `sheets'
	from /Users/jnorman/.gem/ruby/1.9.1/gems/cheat-1.2.1/bin/cheat:4:in `<top (required)>'
	from /Users/jnorman/.gem/ruby/1.9.1/bin/cheat:19:in `load'
	from /Users/jnorman/.gem/ruby/1.9.1/bin/cheat:19:in `<main>'

What you want to do is edit the file producing the error (in my case, from the exception trace, /Users/jnorman/.gem/ruby/1.9.1/gems/cheat-1.2.1/lib/cheat.rb). Go to the line, and change the constant PLATFORM to RUBY_PLATFORM. Save the file.

And voila!

chelsea:~ jnorman$ cheat regexp
regexp:
  A regexp's form is written /pattern/modifiers where "pattern" is the regular
# much deleted

For help,

cheat cheat

I know a number of you are interested in how Ruby and Rails seems to favor smaller projects, code brevity, and a general attitude of representational efficiency.

You might be interested in this new post by Ola Bini who discusses the claim that if a project is very big, you need all of the helps from a statically-typed language (such as Java).

http://olabini.com/blog/2009/10/plan-to-write-big-software-and-you-have-already-lost/