Ryan's Scraps - Blog

Rubyists, Learn Some iPhone Skillz

2009-06-02T00:24:00Z

If any of you Rubyists are going to be attending the FutureRuby in Toronto this July and have an interest in learning how to work some magic on the iPhone, I encourage you to check out Mobile Orchard’s Dan Grigsby and his Beginning iPhone Programming For Rubyists course taking place before FutureRuby. In addition to the iPhone basics, he’ll be covering our ObjectiveResource framework.

You can get a discount on the course if you register before June 9th so head on over and give it a peek.

What's New in Edge Rails: Database Seeding

2009-05-13T12:44:00Z

This feature is schedule for: Rails v3.0

I’m not sure if this was ever stated explicitly has a preferred practice or not, but for the longest time many of us have recognized that using migrations as a way to populate the database with a base configuration dataset is wrong. Migrations are for manipulating the structure of your database, not for the data within it and certainly not for simple population tasks.

Well, this practice now has a formal support in Rails with the addition of the database seeding feature. Quite simply this is a rake task that sucks in the data specified in a db/seeds.rb. Here are the details:

Specify Seed Data

Add or open the db/seeds.rb file and put in model creation statements (or any ruby code) for the data you need to be present in order for your application to run. I.e. configuration and default data (and nothing more):

12	[:admin, :user].each { \|r\| Role.create(:name => r) }User.create(:login => 'admin', :role => Role.find_by_name('admin'))

Load the Data

Once that is in place you can run one of two rake tasks that will populate the database with this data: rake db:seed which will only populate the db with this data and rake db:setup which will create the db, load the schema and then load the seed data. This is the task you’ll want to use if you’re starting in a fresh environment.

So, quit overloading your migrations with seed data and use this new facility. But, don’t go overboard and use seeds.rb for test or staging datasets – it should only be used for the base data that is necessary for your app to run.

tags: ruby, rubyonrails

What's New in Edge Rails: Touching

2009-04-20T11:51:00Z

This feature is schedule for: Rails v3.0

There are often times when you want an update made to one object to be reflected up the object graph as an update of an associated parent object. For instance, if a new comment is created on an article, you may very well want to mark the article as being updated. With the new touch feature of ActiveRecord, this is a whole lot easier. Using our previous example, here’s is how it works:

class Article < ActiveRecord::Base
  has_many :comments
end

class Comment < ActiveRecord::Base

  # Make create/update/deletes of a comment mark its
  # parent article as updated
  belongs_to :article, :touch => true
end

# Adding a new comment marks the article as being updated
article.updated_at #=> "Mon Apr 20 07:42:53 -0400 2009"
article.comments.create(:body => "New comment")
article.updated_at #=> "Mon Apr 20 07:43:27 -0400 2009"

# Same for updates/deletes
article.comments.first.destroy
article.updated_at #=> "Mon Apr 20 07:45:23 -0400 2009"

This is a great way to keep tightly coupled domain models in-sync without resorting to a potential maze of callback logic.

Also, if you have a timestamp field named something other than the standard updated_at or updated_on you can explicitly specify that field as the value to the :touch option and it will get marked instead:

class Article < ActiveRecord::Base
  has_many :comments
  validates_presence_of :last_updated_at  # non-standard
end

class Comment < ActiveRecord::Base
  belongs_to :article, :touch => :last_updated_at
end

# Adding a new comment marks the article as being updated
article.last_updated_at #=> "Mon Apr 20 07:42:53 -0400 2009"
article.comments.create(:body => "New comment")
article.last_updated_at #=> "Mon Apr 20 07:43:27 -0400 2009"

Also, somewhat conveniently, you can invoke touch directly on a model to update its timestamp outside any association callbacks:

123	article.updated_at #=> "Mon Apr 20 07:42:53 -0400 2009"article.toucharticle.updated_at #=> "Mon Apr 20 07:43:27 -0400 2009"

So, touch away (in a non-creepy kind of way)!

tags: ruby, rubyonrails

What's New in Edge Rails: Batched Find

2009-02-23T21:30:00Z

This feature is scheduled for: Rails v2.3

ActiveRecord got a little batch-help today with the addition of ActiveRecord::Base#find_each and ActiveRecord::Base#find_in_batches. The former lets you iterate over all the records in cursor-like fashion (only retrieving a set number of records at a time to avoid cramming too much into memory):

1
2
3

Article.find_each { |a| ... } # => iterate over all articles, in chunks of 1000 (the default)
Article.find_each(:conditions => { :published => true }, :batch_size => 100 ) { |a| ... }
  # iterate over published articles in chunks of 100

You’re not exposed to any of the chunking logic – all you need to do is iterate over each record and just trust that they’re only being retrieved in manageable groups.

find_in_batches performs a similar function, except that it hands back each chunk array directly instead of just a stream of individual records:

Article.find_in_batches { |articles| articles.each { |a| ... } }
  # => articles is array of size 1000
Article.find_in_batches(batch_size => 100 ) { |articles| articles.each { |a| ... } }
  # iterate over all articles in chunks of 100

find_in_batches is also kind enough to observe good scoping practices:

class Article < ActiveRecord::Base
  named_scope :published, :conditions => { :published => true }
end

Article.published.find_in_batches(:batch_size => 100 ) { |articles| ... }
  # iterate over published articles in chunks of 100

One quick caveat exists: you can’t specify :order or :limit in the options to find_each or find_in_batches as those values are used in the internal looping logic.

Batched finds are best used when you have a potentially large dataset and need to iterate through all rows. If done using a normal find the full result-set will be loaded into memory and could cause problems. With batched finds you can be sure that only 1000 * (each result-object size) will be loaded into memory.

tags: ruby, rubyonrails

Get Your iPhone and Rails Apps Talkin'

2009-02-05T13:06:00Z

The iPhone is cool and sexy. Rails is cool and sexy. Shouldn’t they be a little more compatible?

We think so and have released the first version of ObjectiveResource, our port of Rails’ ActiveResource to Objective-C for the iPhone. We’ve used it extensively on some of our iphone projects and have gotten a good response from others that have stumbled upon it.

Basically, it provides an easy way to consume and integrate with Rails’ standard XML and JSON RESTful web-services (just as ActiveResource does for Ruby).

iPhoneOnRails.com is where we’re going to keep the development progress and planning for the framework as well as the various resources we’ve established for those that have questions and concerns. So have a look, play with the source yourself, join the mailing list and keep track at the iPhoneOnRails blog.

And let us know if you’re using ObjectiveResource and want to be featured on the site, or have a quote about using the framework you want us to put up.

Rails 2.3 Released - Summary of Features

2009-02-02T00:43:00Z

Here’s a list of the major new features in Rails v2.3 (most recent first):

Rails 2.3 Features

The next scheduled release appears to be the 3.0 release, the merger of Rails and Merb. The core team has alluded to at least a preview release to be ready by RailsConf 2009. Seems a bit aggressive for all the internal tinkering in store, but stay here for for the latest.

You should also check out the Rails 2.3 release notes for the ‘official’ rundown of new features for 2.3.

tags: ruby, rubyonrails

What's New in Edge Rails: Nested Object Forms

2009-02-01T14:59:00Z

This feature is scheduled for: Rails v2.3

We were all teased a few months ago about the possibility of finally solving the nested model/complex forms problem in Rails, but were then cruelly notified that it wasn’t quite ready for prime time. But our day has come – the most requested feature for Rails 2.3, the ability to handle multiple models in a single form, is here.

This API update was added after the original commit. I’ve updated the examples here to account for this.

This feature has already been written about on the Rails Blog quite well by Eloy Duran, the committer of this fine feature, so I’ll try not to replicate what’s already out there. However, here’s a basic rundown of what you need to do to get your models nested-form capable.

Step 1: Notify Your Model of Nest-able Associations

The first step is to tell your models which of their associations will be able to receive nested attributes. For all associations you want exposed in nested forms you’ll need to use accepts_nested_attributes_for:

class Person < ActiveRecord::Base

  validates_presence_of :name

  has_many :children, :class_name => 'Person'
  accepts_nested_attributes_for :children, :allow_destroy => true
    # can also be used on has_one etc.. associations

end

With this bit in place, you can now directly create, edit and delete children from a person:

# Add a new child to this person
@person.children_attributes = [ { :name => 'Son' } ]
@person.children #=> [ <#Person: name: 'Son'> ]
@person.children.clear

# Add two new children to this person
@person.children_attributes =
  [ { :name => 'Son' }, { :name => 'Daughter' } ]
@person.save
@person.children #=> [ <#Person: name: 'Son'>, <#Person: name: 'Daughter'> ]

# Edit the son (assuming id == 1)
@person.children_attributes = [ { :id => 1, :name => 'Lad' } ]
@person.save
  #=> the son's name is now 'Lad'

# Edit the daughter (id == 2) and add a new offspring
@person.children_attributes =
  [ { :id => 2, :name => 'Lassie' }, { :name => 'Pat' } ]
@person.save
  #=> the daughter's name is now 'Lassie' and there's a new offspring called 'Pat'

# Remove Pat (id = 3), we don't like him/her
@person.children_attributes = [ :id => 3, '_delete' => '1' } ]
@person.save
  #=> Pat is now deleted

You’ll want to take away a few things from these examples.

To support both the creation of new objects and the editing of existing ones we have to use an array of hashes for one-to-many associations or a single hash for one-to-one associations. If no :id property exists then it is assumed to represent a nested model to create.
To delete an existing nested model, use this format: [ :id => pk, '_delete' => '1' } ] where the value of _delete evaluates to anything true. You must also set the accepts_nested_attributes_for option :allow_destroy to true as that capability is turned off by default.

While this may appear a bit hackish when you’re used to dealing with the pleasantries of a rich object model and with ActiveRecord’s associations, this provides the foundation for a seamless transition to the view where you need to create your nested model forms…

Step 2: Create a Nested Model Form

In the view, simply use fields_for on these nested models to expose the fields for each such model:

<% form_for @person do |person_form| %>

  <%= person_form.label :name %>
  <%= person_form.text_field :name %>

  <% person_form.fields_for :children do |child_form| %>

    <%= child_form.label :name %>
    <%= child_form.text_field :name %>

    <% unless child_form.object.new_record? %>
      <%= child_form.check_box '_delete' %>
      <%= child_form.label '_delete', 'Remove' %>
    <% end %>

  <% end %>

  <%= submit_tag %>
<% end %>

This will create a form with all the form fields necessary for submitting to a RESTful controller, transparently pushing your children_attributes onto the person.

If there are any validation errors on a child, they will be added to person.errors, and nothing will save if any of the children fail (i.e. fully transactional).

A few notes that might be useful to you:

Using fields_for on a has_many association automatically executes once for each nested model present, so think of yourself as being inside a loop when building your child_form
If you ever need to change behavior based on the nested model currently in scope, it can be accessed via child_form.object. In this example we use child_form.object.new_record? to determine whether or not to display the delete checkbox (as that only makes sense on an existing record).

Step 3: In Your Controllers … Do Nothing

The third step should be the easiest, because we’re all dealing with purely RESTful controllers, right? The beauty of this solution is that it takes your controllers out of the mix and makes standard for submissions work perfectly with no interference at the controller level. Just so there’s no confusion, here’s how your create and update actions will look:

class PersonController < ApplicationController

  def create
    @person = Person.new(params[:person])
    @person.save ? redirect_to(person_path(@person)) : render(:action => :new)
  end

  def update
    @person = Person.find(params[:id])
    @person.update_attributes(params[:person]) ?
      redirect_to(person_path(@person)) : render(:action => :edit)
  end

end

Not a peep of those pesky nested models – with the rich support for nested objects at the model layer, it just works!

Extras

As with most powerful features, there are few little tweaks you may find yourself needing.

Default Create Form Fields

Often times you’ll want to have the form displayed with empty fields for easily creating a new nested model. For example, when a user goes to create a new person I want there to be fields for creating a new child already displayed.

Since the person object is brand new they have an empty children collection and no child_form fields will be displayed. There are two ways to get around this:

You can build a new nested object on the controller side (i.e. in the new action):

  def new
    @person = Person.new
    @person.children.build
    # ...
  end

which will cause there to be empty child_form fields displayed as desired. Or you can do it on the view side with a view helper:

module ApplicationHelper
  def setup_person(person)
    returning(person) do |p|
      p.children.build if p.children.empty?
    end
  end
end

Which can then be used within form_for to setup the person to the correct form state:

123	<% form_for setup_person(@person) do \|person_form\| %> <!-- ... --><% end %>

I prefer this view-helper approach as it really is a view concern (whether or not to display the form fields to create a new nested object by default).

Specify When Nested Models get Built

If you do have empty nested model form fields displayed by default, you’ll run into the issue where the user submits the form with no values filled in and you have to decide if you want to treat that as somebody trying to create a new nested item with no values, or if that means that no new nested item was submitted. Quite often you just want to ignore the submissions with no nested field values filled out.

Although I would have expected this to be default behavior, you need to manually specify that submissions with empty nested values are ignored using the :reject_if option of accepts_nested_attributes_for:

Note: You now have the option to use :all_blank to ignore the item if all properties are blank. See below for an updated example.

class Person < ActiveRecord::Base

  validates_presence_of :name

  has_many :children, :class_name => 'Person'

  # This will prevent children_attributes with all empty values to be ignored
  accepts_nested_attributes_for :children,
    :reject_if => proc { |attrs| attrs.all? { |k, v| v.blank? } }

  # This does the same thing using :all_blank
  accepts_nested_attributes_for :children, :reject_if => :all_blank

end

123	@person.children_attributes = [ { :name => '' } ]@person.save@person.children.count #=> 0

This is also useful if you have boolean values in your nested model fields (since, as a checkbox, ‘0’ will be submitted if there’s no value):

class Person < ActiveRecord::Base

  validates_presence_of :name, :bad

  has_many :children, :class_name => 'Person'

  # This will prevent empty checkboxes submitted for a child to be
  # construed as a submission
  accepts_nested_attributes_for :children,
    :reject_if => proc { |attrs| attrs['bad'] == '0' && attrs['name'].blank? }

end

123	@person.children_attributes = [ { :name => '', :bad => '0' } ]@person.save@person.children.count #=> 0

Dynamically Adding Nested Form Fields

If you want to allow the addition of a large number of nested models via your HTML forms, one option is to just have several empty nested forms displayed by default. This is a little unappealing, however. The far slicker option is to use javascript to dynamically display the new nested form on the user’s request.

Eloy has a great example application setup on GitHub outlining how this works, and I’ll let you take a peek over there to see how to wire up your dynamic nested form additions.

Eloy’s example app is also a great place to see how the whole thing works, end-to-end. By far the best resource out there.

Conclusion

So there it is, Rails’ most requested new feature in the flesh and blood. I’m not sure if my experiences are indicative of everybody else’s, but this is a godsend for me. Many thanks to all the folks involved with this functionality (if you don’t know who they are, check out the next section which links to a bunch of great resources). A really great effort by the community.

Resources

tags: ruby, rubyonrails

What's New in Edge Rails: HTTP Digest Authentication

2009-01-30T02:03:00Z

This feature is scheduled for: Rails v2.3

Long ago, in your mother’s version of rails, we got a http basic authentication plugin. That functionality has since been rolled into Rails core, but it was always lacking HTTP digest authentication. Until this commit, that is.

For those that may now know the difference, basic authentication only base 64 encodes the authenticating username and password (making it easily decoded) whereas digest authentication sends an MD5 hash of your username and password. To simplify, digest is more secure than basic.

To request digest authentication in Rails, ~~you’ll need to be able to retrieve the cleartext password for a given user (so the framework can hash and compare it using the nonce it created specifically for that request)~~. This commit now allows you to also use a specific hashed format of the password. Here’s how this works if you have access to a cleartext password:

class ArticlesController < ApplicationController

  before_filter :digest_authenticate

  def digest_authenticate

    # Given this username, return the cleartext password (or nil if not found)
    authenticate_or_request_with_http_digest("Articles Administration") do |username|
      User.find_by_username(username).try(cleartext_password)
    end
  end

end

Most of us will want to do something with the result of the authentication and can do so with the boolean return value of authenticate_or_request_with_http_digest:

class ArticlesController < ApplicationController

  before_filter :digest_authenticate

  def digest_authenticate

    success = authenticate_or_request_with_http_digest("Admin") do |username|
      (@user = User.find_by_username(username)).try(cleartext_password)
    end

    # If authentication succeeds, log the user in.  If not, kick back out a failure
    # message as the response body
    if success
      session[:user_id] = @user.id
    else
      request_http_digest_authentication("Admin", "Authentication failed")
    end
  end

end

If you don’t want to store clear text passwords you can return an MD5 hash from the authenticate_or_request_with_http_digest block as long as it’s in the format username:realm:password. You can get a password hash by using Digest::MD5::hexdigest.

class User < ActiveRecord::Base

  attr_accessor :password
  validates_presence_of :username, :crypted_password
  before_save :hash_password

  ...

  def hash_password
    if password_changed?
      self.crypted_password =
        Digest::MD5::hexdigest([username, "UserRealm", password].join(":"))
    end
  end
end

and then in your controller:

class ArticlesController < ApplicationController

  before_filter :digest_authenticate

  def digest_authenticate

    # Just return the crypted (hashed) version of the password if it's in the supported
    # format.  Note that the realm here "UserRealm" should match the middle
    # argument of your password hash
    success = authenticate_or_request_with_http_digest("UserRealm") do |username|
      (@user = User.find_by_username(username)).try(crypted_password)
    end

    ...
  end

end

So there you have it, digest authentication in edge Rails.

tags: ruby, rubyonrails

Need Nested Model Support in Rails? Vote for it!

2009-01-07T16:10:00Z

Nested Model support in Rails is currently scheduled for Rails 2.3. Yay!

The Rails team has recently organized its community around the Rails Activists group and provided several ways for you to speak your mind about the framework – and one of the best ways to impact the maturation of the framework is to vote for features you’d like to see in upcoming releases.

While I don’t usually like to use this site as a bully pulpit, I have to say that the one feature I’d love to see make it’s way into Rails is nested model mass assignment support. The team teased us with the foundation of an initial implementation but later yanked it since it didn’t quite cover all the cases.

I’ve setup a suggestion on uservoice for exactly this feature. If you’d like to see this support in Rails vote for it now! to be heard.

By the way, I totally acknowledge that I am being less than useful here only in complaining and not actually contributing. Guilty as charged – but to be honest, it’s a hairy problem with a lot of edge cases and sometimes I’m just not that smart.

So be heard with your vote (for this feature or any other!)

tags: ruby, rubyonrails

Contest: Free iPhone Oxford Dictionary

2008-12-29T19:19:00Z

I’m not big on publicizing commercial works due to the obvious bias involved, but we’ve recently finished up the Oxford American College Dictionary and Thesaurus for the iPhone and our client was nice enough to give us a few free download codes. Never one to waste free stuff I thought I’d offer them up to my readers.

So here’s the deal – to distribute these free downloads of our Oxford Dictionary for the iPhone (appstore) I’m going to run a little contest: Post your favorite word in the comments along with your preferred usage of the word (like an example sentence). I’ll pick my favorite five entries after a week or so and will email you your promo codes (so be sure to leave your email address in the comment form). Note: I am a sucker for humor and wit, so be liberal in your application of them.

Most real iPhone dictionaries (from respected publications) go for upwards of $20 – $30 so this is a pretty decent value.

Now wow me with your vocabulary.

The winning words are: sesquipedalian, recidivist, floccinaucinihilipilification, obsequious (indirectly) and esquivalience

You guys should be getting your promo codes in a few minutes. Thanks for the submissions everybody! (and, yes, all these words are in the dictionary app)

tags: iPhone, dictionary

What's New in Edge Rails: Dynamic Scope Methods

2008-12-29T14:24:00Z

This feature is scheduled for: Rails v2.3/3.0

For quite some time now you’ve been able to perform simple queries using dynamic find_all_by_xx_and_yy methods:

12	Article.find_by_published_and_user_id(true, 1) #=> "SELECT * FROM articles WHERE published = 1 AND user_id = 1"

These dynamic finders provide an easy way to quickly encapsulate non-reused query conditions (for commonly used query logic you should consider using named scopes). The downside, however, is that you can’t chain query conditions when using these dynamic finders.

With the recent addition of dynamic scopes, however, you now have a way to both quickly specify query logic and chain further conditions. The naming works in the same manner as dynamic finders and the chaining works in the same fashion as conventional named scopes:

12	Article.scoped_by_published_and_user_id(true, 1).find(:all, :limit => 5) #=> "SELECT * FROM articles WHERE published = 1 AND user_id = 1 LIMIT 5"

Note how you can hang further chainable query methods off the dynamic scope here? You could also have preceded the dynamic scope with another scope, or even another dynamic scope:

12	Article.scoped_by_published(true).scoped_by_user_id(1) #=> "SELECT * FROM articles WHERE published = 1 AND user_id = 1"

This is really just another tool to put in your toolbox based on the powerful named_scope functionality of ActiveRecord.

tags: ruby, rubyonrails

What's New in Edge Rails: Merb!

2008-12-23T20:16:00Z

This feature is scheduled for: Rails v3.0

Wow, from the bombshell department comes the news that Rails and Merb will be merging to form Rails 3. It seems the Rails and Merb teams have acknowledged that there is good in both frameworks and that they can be combined into a singular web framework.

To be honest I don’t love the idea of having less choice in Ruby web-framework world. However, I do think this bodes well for Rails. We can only hope innovation stays alive within the combined team (and that their perspectives only enhance each other and don’t outright conflict).

Read what Yehuda, now a Rails core team member, Ezra, Carl and Matt have to say as well.

Little ‘ole Rails is definitely growing up – lots of big stuff coming in Rails 3…

tags: ruby, rubyonrails

What's New in Edge Rails: Rails Metal

2008-12-18T03:02:00Z

This feature is scheduled for: Rails v2.3/3.0

In what is clearly a move to make me irrelevant within the Rails community, news has broken about the new Rails metal feature before I had the time to do a proper write-up. (And for the second time in as many weeks, no less). I need to get on my horse here, many apologies.

So Rails Metal is a way to cut out the fat of the MVC request processing stack (and the all the niceties, too) to get the quickest path to your application logic. This is especially useful when you have a single action that you need to run as quickly as possible and can afford to throw away all the support Rails normally provides in exchange for a very fast response time.

While I could throw out some examples here, I’ll let Jesse Newland of RailsMachine do the heavy lifting with his great writeup (a little morsel – his tests have Metal running 25x faster than the comparable controller-based action).

This is definitely an exciting feature to keep an eye on!

tags: ruby, rubyonrails

What's New in Edge Rails: Application Generators

2008-12-11T13:53:00Z

This feature is scheduled for: Rails v2.3/3.0

I’m way late to the party on this one, but it’s such a great feature that the least I can do is provide some link love for Edge Rails’ new application template feature.

In a nutshell, this lets you create a Rails app already bootstrapped with your choice of plugins, gems and other base info specified. No longer do you need to manually download your preferred libraries at the start of every project – you can save your configuration off to any text/ruby file and kick off a new app with:

rails blog -m ~/my_template.rb

Or apply an app template to an existing app:

rake rails:template LOCATION=http://mydomain.com/templates/start.rb

Go read up on the details of this great new feature in Pratik’s writeup covers (which is wholly based on the rg project by Jeremy McAnally).

tags: ruby, rubyonrails

What's New in Edge Rails: No More Formatted Routes

2008-11-27T01:45:00Z

This feature is scheduled for: Rails v2.3/3.0

Parallel to the addition of :except and :only options to Rails’ routing comes the removal of all those formatted_xxx named routes. Turns out these routes ate up a lot of memory and served minimal purpose.

So with this routes.rb definition:

123	ActionController::Routing::Routes.draw do \|map\| map.resources :articlesend

you’ll no longer have any of the formatted_xxx url helpers available. However, you will be able to get the same functionality by passing in a :format option to the base view helper methods:

1234	# Old => Newformatted_article_path(article, :xml) => article_path(article, :format => :xml)formatted_new_article_path(:json) => new_article_path(:format => :json)# etc...

A minimal change that will have a big impact on the memory consumption of each of your Rails processes – especially if you’ve got a complex app with lots of routes.

If you’re on Edge Rails you’re going to start seeing deprecation warnings where you reference these formatted url helpers, so you’ve got some warning before you have to make the switch.

tags: ruby, rubyonrails