chuyeow.wtf

Rendering plists from your Rails app

2010-06-14T11:22:50+00:00

Jeena</a> emailed me recently about his Rails plugin, plistifier</a>, that allows you to render plists</a> (property lists).</p>

It allows you to render your ActiveRecord objects as plists (among other things):</p>

def show
  @post = Post.find(params[:id])
respond_to do |format|
format.xml   { render :xml => @post }
format.plist { render :plist => @post }
end
end</code></pre></p>
Jeena was kind enough to let me know he "stole" my old Jsonifier plugin</a> (github</a>) code in plistifier</a>.</p>



Don't kill your app when using ActiveRecord in Rails Metal, release your database connections
2009-06-15T14:49:51+00:00
Rails Metal has been available on Rails since version 2.3 - it's old news. But if you haven't used it or heard about it, you can find out more about Rails Metal on the RoR weblog</a> and on Jesse Newland's blog</a>.</p>
So anyway, I am one of those laggards and only wrote a Rails Metal piece not too long ago for a Rails app on Wego.com</a> in an effort to optimize some high volume requests. It looked something like this:</p>
class Adamantine
  def self.call(env)
    if env['PATH_INFO'] =~ ROUTE_REGEX
      location = Location.find(1) # Use ActiveRecord.
  [200, { 'Content-Type' => 'text/html' }, [location.to_json]]
else
  # Leave it to Rails to deal with the request.
  [404, { 'Content-Type' => 'text/html' }, ['Not Found']]
end
</code></pre>
end
end</code></pre></p>
Notice the use of an ActiveRecord model. It ran for quite awhile, almost 30 minutes, in production</em> until I started getting notification emails about "Too many open database connections</strong>" to the MySQL server! The change was promptly rolled back and there was no cheezburger for me.</p>
As it turns out, Rails doesn't take care of certain things in Rails Metal pieces, including the releasing of connections back to the database connection pool. A bit of googling turned up this bug in Rails' bug tracker</a> (see Josh Peek's comment about ActiveRecord::Base.clear_active_connections!</code>).</p>
I rewrote the Rails Metal piece to always ensure it clears any active database connections with ActiveRecord::Base.clear_active_connections!</code>:</p>
class Adamantine
  def self.call(env)
    if env['PATH_INFO'] =~ ROUTE_REGEX
      location = Location.find(1)
  [200, { 'Content-Type' => 'text/html' }, [location.to_json]]
else
  # Leave it to Rails to deal with the request.
  [404, { 'Content-Type' => 'text/html' }, ['Not Found']]
end
</code></pre>
ensure
# Release the connections back to the pool.
ActiveRecord::Base.clear_active_connections!
end
end</code></pre></p>
Moral of the story: Don't forget to release your database connections if you're using ActiveRecord in your Rails Metal. Or even better, don't use ActiveRecord in Rails Metal - you're aiming for raw speed anyway right?</p>


Living on the Edge (of Rails) has a new home at the Official Ruby on Rails weblog
2008-06-22T17:55:39+00:00
You may have heard of it</a>, but just in case, Living on the Edge</a> is now going to be published on the official Ruby on Rails weblog</a>. Big thanks to Gregg Pollack</a> for getting me the new "gig", and more importantly, for reviving and freshening up the content on the official Rails blog.</p>
Catch the new first edition - this one's about the API changes since Rails 2.1</a>.</p>


RailsConf 2008 Day 1 - pics and a summary
2008-05-30T13:32:11+00:00
Day 1 of RailsConf 2008</a> was basically tutorial day (schedule</a>) and started with my colleague here with me, Arun</a>, missing out on Yoga on Rails</a> and me sleeping until the first tutorial session. Anyway, I snapped some photos while trying to remain the unobtrusive tourist.</p>
Here's a shot of Portland Convention Center where it's all happening:</p>
</div>

</p>
There're queues for collection of badges after registering your attendance:</p>
</div>

</p>
Patience in the queue rewarded me with a RailsConf badge/name tag:</p>
</div>

</p>
I was at the Meta-programming Ruby for Fun & Profit</a> tutorial in the morning. I think when I selected the tutorial it was before I'd seen Neal Ford and Patrick Farley's (the speakers) presentation videos from elsewhere - I know Patrick presented at MWRC</a> and enjoyed that video.</p>
</div>

</p>
So anyway, after the break I went over to the Refactoring Your Rails Application</a> tutorial. Was pretty good, but I didn't learn much I didn't already know.</p>
Lunch came in the form of a pretty box:</p>
</div>

</p>
After lunch was the 2nd tutorial session and I went to both CI for the Rails Guy (or Gal)</a> (by Chad Woolley) and Developer Testing Tricks</a> (by Brian Takita). There were some scathing comments about how the tutorials were rather underwhelming so far in #railsconf</a> on IRC. While I agree that the tutorials were rather underwhelming, I think I should have expected it. Oh well, I'll know to skip them next time.</p>
Later that night, at the Birds of a Feather session, after stealing a Pivotal Labs t-shirt</a> (they're launching a bug tracker, project management type app called Pivotal Tracker</a> at RailsConf), Yehuda Katz (Merb and jQuery ninja) gave a presentation on Merb (geared towards Rails folks). It was a pretty interesting talk though there wasn't much above what Ezra had presented previously at GoRuCo 2008</a> and at MWRC 2008</a> (I think Yehuda did one too but I can't remember where now). Yehuda pointed out a (heated) discussion that happened recently</a> on keeping Merb syntax as Rails-friendly as possible. I have no objection against a different syntax really, especially since Merb looks pretty well-documented in the source itself - would be nice if someone could point out an up-to-date Merb tutorial though.</p>
Anyway, that's it from me - as always, if anyone who reads my blog recognizes me</a> at RailsConf, do say hi (#railsconf</a> works too).</p>


Living on the edge (of Rails) #22 - pre-Railsconf 2008 edition
2008-05-25T19:06:36+00:00
No mind-blowing changes in Rails this week prior to RailsConf - as Gregg mentioned last week in the Rails Envy podcast</a>, it's pre-2.1 days (Rails 2.1 will probably</em> be released at RailsConf) so it's pretty easy to see why. Oh and all Rails tests now pass in Ruby 1.9 after a long-standing #module_eval</code> bug got fixed in Ruby 1.9's trunk (see thread</a> for more details).</p>
I'll be at (my first) Railsconf 2008 in Portland, Oregon this Thursday onwards - if anyone sees me and recognizes me from my Facebook picture</a> please come and say hi (no head butting though).</p>
This week’s report covers changes from 19th May 2008 to 25th May 2008 (the day the corresponding Rails Envy podcast</a> was recorded).</p>
first and last methods now work with associations and named_scope</h3>
Remember how the merging of the has_finder gem into Rails</a> allowed you to do things like Post.first</code> and Post.last</code>?</p>
Now you can go one step further and use the same methods on your ActiveRecord associations. For example:</p>
post = Post.find(1)
first_comment = post.comments.first</code></pre>
If you have a named_scope</a> named recent</code> defined, you can even do this:</p>
post.comments.recent.last</code></pre>
This neat little enhancement is courtesy of Ryan Bates</a> (yes, that Ryan Bates</em> of Railscasts</a> fame).</p>
Related changeset: http://github.com/rails/rails/commit/73c59638549686fccc749ffd3ac53cb533c5fd61</a></p>
Cache stores now have an exist? method and controllers get fragment_exist?</h3>
The cache stores in Rails (Memcache, file stores, etc.) now have an exist?</code> method that checks whether a cached value exists given a cache key. This allows Rails controllers to expose a fragment_exist?

</code> method that allows you to check for existence of a cache fragment:</p>
fragment_exist?('example.com/foo/bar')</code></pre>
This little enhancement is courtesy of José Valim</a>.</p>
Related changeset: http://github.com/rails/rails/commit/99860b72aebe0348f41e82d4710343498d89a84b#diff-2</a></p>
Create association records with block argument</h3>
You can now create records for associations like so:</p>
post.coments.create!(:title => 'Techcrunch') do |c|
  c.body = "Rails can't scale"
end</code></pre>
This is in keeping with the ActiveRecord::Base.create change previously mentioned</a>.</p>
Credit for this patch goes (once again) to Ryan Bates</a>.</p>
Related changeset: http://github.com/rails/rails/commit/6cba97d2a449faf21aec9fe9d4434067e414226f</a></p>
As always, let me know of any suggestions or how I can improve the Living on the Edge (of Rails) series.</p>


Living on the Edge (of Rails) in Spanish
2008-05-18T20:16:18+00:00
Juan Lupión</a> wrote in to inform me that he's also translating my Living on the Edge (of Rails) series of blog posts to Español. Thanks Juan!</p>


Living on the edge (of Rails) #21
2008-05-18T19:54:42+00:00
It's another slow week (just 2 changes of note imho</acronym>) after the release of the 1st Release Candidate (RC1) of Rails 2.1</a>. Follow that link for installation instructions - though if you're reading this blog post you probably don't care! (because you're, you know, "living on the edge"). Cheesiness aside, be sure to report any bugs you may encounter when upgrading to 2.1 RC1 or edge at the Rails bug tracker</a> - it is an RC so any bug reports would be very welcome and useful!</p>
This week’s report covers changes from 12th May 2008 to 18th May 2008 (the day the corresponding Rails Envy podcast</a> was recorded).</p>
caches_action can has conditionals</h3>
caches_action</code> now takes an :if</code> option (just like caches_page does</a>). For example:</p>
caches_action :index, :if => Proc.new { |c| !c.request.format.json? }</code></pre>
This little enhancement is courtesy of José Valim.</p>
Related changeset: http://github.com/rails/rails/commit/7708650f73ddb4db300ea2059c60c1d907a4384e</a></p>
Bugfix: :select option is now scanned in ActiveRecord finders to ensure needed tables are included in generated SQL</h3>
Post.find(:all, :include => :author, :select => 'posts.*, authors.id as "author_id"', :limit => 2)</code></pre>
Would generate an SQL statement like this:</p>
SELECT posts.*, authors.id as "author_id" FROM "posts" LIMIT 2</code></pre>
Notice how the authors</code> table is not joined. This oversight is now fixed.</p>
Thanks go to John Devine for this bugfix.</p>
Related changeset: http://github.com/rails/rails/commit/b28b54cab090bed8f099ef375b419a8f92390dd4</a></p>
As always, let me know of any suggestions or how I can improve the Living on the Edge (of Rails) series. Also, if anyone has any recommendations of (non-ruby-related) things to do in Portland, do let me know!</p>


Deploying with Capistrano via a gateway - some notes
2008-05-15T17:03:48+00:00
Some notes on setting up a gateway server for deploying via Capistrano</a> that I couldn't find at the source</a>.</p>

You can specify the user you want to use to login to your gateway server like so: set :gateway, 'deploy@deploy.example.com'</code>. This logs in to your gateway server as the "deploy" user.</li>
You can specify an alternate SSH port for both your gateway and</em> your deployment servers. E.g. setting ssh_options[:port] = 11111</code> will make Capistrano SSH to your gateway server with on port 11111. For your actual application (and web and database) servers, you can specify the SSH port like so:
set :gateway, 'deploy@deploy.example.com'
role :app, '192.168.1.113:22222'
role :web, '192.168.1.113:22222'
role :db,  '192.168.1.113:22222', :primary => true</code></pre>
</li>
If you're using public key authentication, you should put the public keys of your users (those who be deploying your app) on the gateway server and</em> on the actual servers. I thought Capistrano would use the key of the "deploy" user but nope.</li>
</ul>


Living on the edge (of Rails) #19 - change_table for migrations and more
2008-05-04T20:18:54+00:00
This week’s report covers changes from 29 April 2008 to 4th May 2008 (the day the corresponding Rails Envy podcast</a> was recorded).</p>
change_table for ActiveRecord migrations</h3>
Thanks to Jeff Dean</a>, who also blogged about the new change_table feature in ActiveRecord migrations</a>, you can now change a table with a block like so:</p>
change_table :videos do |t|
  t.add_timestamps
  t.add_belongs_to :goat
  t.add_string :name, :email, :limit => 20
  t.remove_column :name, :email # takes multiple arguments
  t.rename :new_name
  t.string :new_string_column # executes against the renamed table name
end</code></pre>
Some key things to note:</p>

add_XXX</code> would add a new column for you, e.g. add_string</code> would add a new string field.</li>
Of course, add_timestamps would add the magic created_at</code> and updated_at</code> datetime fields.</li>
remove_column</code> now takes multiple arguments.</li>
rename</code> would rename the table.</li>
</ul>
Very nice, DRY enhancement, props to Jeff Dean</a> once again.</p>
Related changeset: http://github.com/rails/rails/commit/96980bd561d79824b6cb6efbcbecdcbf8785d452</a></p>
ActiveRecord::Base.create takes a block like ActiveRecord::Base.new</h3>
Yup now you can also create</code> ActiveRecord objects with a block argument just like you could for ActiveRecord::Base.new</code>:</p>
@person = Person.create(params[:person]) do |p|
  p.name = 'Konata Izumi'
  p.age = 17
end</code></pre>
Credit goes to Adam Meehan</a> for this patch.</p>
Related changeset: http://github.com/rails/rails/commit/dd120ede53eaf71dee76894998a81626b7a689fc</a></p>
Bugfix: change_column should be able to use :null => true on a field that

formerly had false</h3>
You can now use change_column</code> in your migrations to alter a column as nullable if it was previously NOT NULL</code>.</p>
This bugfix is courtesy of Nate Wiger.</p>
Related changeset: http://github.com/rails/rails/commit/10ef65a3b054270ed3d458ec8eb7c2b9a3e638f7</a></p>
As always, let me know of any suggestions or how I can improve the Living on the Edge (of Rails) series.</p>


Living on the Edge (of Rails) in French
2008-05-01T00:07:34+00:00
It looks like Cyril Mougel</a> has translated my 2 latest posts to French: LotE #17</a> and #18</a>. Thanks Cyril!</p>


Living on the edge (of Rails) #18
2008-04-27T19:18:36+00:00
This week’s report covers changes from 21 Apr 2008 to 27 Apr 2008 (the day the corresponding Rails Envy podcast</a> was recorded).</p>
Not much interesting to report this week - there were mostly a bunch of bugfixes and Ruby 1.8.7-compatibility commits</a>.</p>
Introduce ActiveResource::Base.timeout and rescuing from Timeout::Error in ActiveResource::Connection</h3>
These are 2</a> changes</a> that I'd talked about</a> earlier this week so I won't repeat myself - take a read through ActiveResource timeouts and why it matters</a>.</p>
Smart integer datatype for the MySQL adapter in migrations</h3>
The MySQL adapter in Rails now maps the integer</code> column type in your migrations to either smallint, int, or bigint depending on the :limit option.</p>
This means that a migration like this:</p>
def self.up
  create_table :searches do |t|
    t.integer :foo, :limit => 2
  end</code></pre>
will create your foo</code> column as a smallint(2)</code> MySQL datatype (instead of int(2)</code> before). (More information MySQL numeric datatypes</a>.)</p>
Credit goes to DHH for this patch.</p>
Related changeset: http://github.com/rails/rails/commit/a37546517dad9f6d9a7de6e1dba4d960909d71e8</a></p>
As always, let me know of any suggestions or how I can improve the Living on the Edge (of Rails) series.</p>


New in Rails: ActiveResource timeouts and why it matters
2008-04-22T22:25:57+00:00
If you've ever used ActiveResource or for that matter, coded anything that involves interacting with a remote API, you've probably had the misfortune of having that API go down or become unresponsive. The experienced old geezers would already have forseen the problem and set a timeout on those API calls. For the rest of us, it's a good time to get acquainted with the idea of fail-fast</a> and how no response is better than a slow response</em>.</p>
So what happens when the API you're accessing via ActiveResource or Net::HTTP</code> (or whatever, really, so long as there's a network socket involved!) becomes unresponsive?</p>
Unfettered outbound remote connections can kill your server</h3>
ActiveResource (or Net::HTTP</code> or whatever you're using) would block while waiting for the API to return. What did we learn about blocking IO in Operating Systems 101? That your process or thread gets stuck waiting for a response that's what. So now your Mongrel/Thin/Ebb/X web server process basically stuck waiting for a response from an API that might return a response in 30 seconds, or maybe it'll never return at all. It won't be long before all your web server processes get blocked and its time to "kill dash nine" (kill -9</code>) some processes and bring out the 500 error page. Yes, your server has been incapacitated and your website is now basically offline.</p>
</div>

</p>
Timeouts and you</h3>
If you're using Net::HTTP you can easily safeguard yourself against errors like this by setting a timeout on the socket connection. Like so:</p>
def fetch_something_from_some_api(uri)
  http = Net::HTTP.new(uri.host, uri.port)
  http.read_timeout = timeout
response = http.start { http.request(Net::HTTP::Get.new("#{uri.path}?#{uri.query}")) }
response.is_a?(Net::HTTPSuccess) ? do_something_with(response.body) : nil
rescue Timeout::Error
logger.warn("Timeout accessing #{uri}: #{$!}")
nil
rescue
logger.warn("Error accessing #{uri}: #{$!}")
nil
end</code></pre></p>
Take note that you really do need to explicitly rescue from the Timeout::Error</code> (or Interrupt</code>) since it's a child of the Interrupt</code> class and not a StandardError</code>.</p>
Any good client library should also allow you to specify a timeout on the socket connection so read the API documentation.</p>
So what's this about ActiveResource?</h3>
So back to ActiveResource: Michael Koziarski was kind enough to commit my 2 patches (this</a> and this</a>) to ActiveResource so now on edge Rails</a>, you can do this:</p>
class Person < ActiveResource::Base
  self.site = 'http://api.people.com:3000/'
  self.timeout = 5
end</code></pre>
This sets the timeout to 5 seconds on the underlying Net::HTTP</code> instance that ActiveResource uses. The default timeout (to be exact, the read_timeout</code>) for Net::HTTP</code> is 60 seconds</strong> on most Ruby implementations (that includes MRI). That's far too long if your ActiveResource call is in a public-facing controller!</p>
If you are using ActiveResource anywhere and haven't safeguarded your application with a timeout, I think it's a good idea to fix it by using edge Rails or at least applying the patch</a>!</p>
The 2nd ActiveResource patch</a> introduces the ActiveResource::TimeoutError</code> exception that you should rescue from whenever you make an ActiveResource call. When this happens, it's up to your application to decide what to do (like show a placating we're sorry message). At least your application is still able to do something!</p>


Living on the edge (of Rails) #17
2008-04-20T19:21:22+00:00
Not much going on this week on edge Rails. It does seem however that we do have a new Rails core member, Joshua Peek</a>. Also, the new Rails' bug tracker</a> hosted on Lighthouse is ready for use, so be sure to submit your patches and bug reports there.</p>
This week’s report covers changes from 14 Apr 2008 to 20 Apr 2008 (the day the corresponding Rails Envy podcast</a> was recorded).</p>
Conditional caches_page</h3>
The caches_page</code> now takes an :if</code> option for specifying when a page can actually be cached via a Proc. You can now do this, for example:</p>
caches_page :index, :if => Proc.new { |c| !c.request.format.json? }</code></pre>
That will only cache your index page if the requested format is not JSON.</p>
Credit goes to Paul Horsfall</a> for this enhancement.</p>
Related changeset: http://github.com/rails/rails/commit/14a40804a29a57ad05ca6bffbe1e5334089593a9</a></p>
New ActionView::TestCase for testing view helpers</h3>
Remember how you can now use specialized TestCase classes for testing controllers and ActionMailer classes</a>? Now you can do the same with your Rails view helpers with the new ActionView::TestCase class.</p>
Here's a quick example:</p>
module PeopleHelper
  def title(text)
    content_tag(:h1, text)
  end
def homepage_path
people_path
end
end</p>
class PeopleHelperTest < ActionView::TestCase
def setup
ActionController::Routing::Routes.draw do |map|
map.people 'people', :controller => 'people', :action => 'index'
map.connect ':controller/:action/:id'
end
end</p>
def test_title
assert_equal "<h1>Ruby on Rails</h1>", title("Ruby on Rails")
end</p>
def test_homepage_path
assert_equal "/people", homepage_path
end</code></pre></p>
Credit goes to Josh Peek for this sweet little enhancement.</p>
ActiveSupport::Cache's mem_cache_store accepts options</h3>
Even though Memcache-client was added to ActiveSupport recently, it didn't allow you to specify any configuration options beyond just the IP of the memcached server. Now you can pass along more configuration options like so:</p>
config.action_controller.fragment_cache_store = :mem_cache_store, 'localhost', { :compression => true, :debug => true, :namespace => 'foo' }</code></pre>
This patch is courtesy of Jonathan Weiss</a>.</p>
Related changeset: http://github.com/rails/rails/commit/9e1d506a8cfedef2fdd605e4cbf4bf53651ad214</a></p>
As always, let me know of any suggestions or how I can improve the Living on the Edge (of Rails) series.</p>


Living on the edge (of Rails) #16 - Github edition
2008-04-13T16:09:43+00:00
A slight change this week since Rails has moved to Git</a> - all changesets are now referenced to Github</a>.</p>
This week’s report covers changes from 7 Apr 2008 to 13 Apr 2008 (the day the corresponding Rails Envy podcast</a> was recorded).</p>
A helpers proxy method for accessing helper methods from outside of views</h3>
A helpers</code> method has been introduced to ActionController - you can now access your helpers like so:</p>
ApplicationController.helpers.simple_format(text)</code></pre>
Credit goes to 19 year old Josh Peek</a>, one of the more prolific Rails contributors (and most likely to join Pratik in Rails Core imo).</p>
Related changeset: http://github.com/rails/rails/commit/917423d664038d6791738a73ad1446437dbb71df</a></p>
json_escape for escaping HTML entities in JSON strings</h3>
A json_escape</code> (aliased as j</code>, similar to how html_escape</code> is aliased as h</code>) has been introduced by Rick Olson for escaping HTML entities in JSON strings. This is useful if you find yourself emitting JSON strings in HTML pages (e.g. for documenting a JSON API):</p>
json_escape("is a > 0 & a < 10?")
# => is a \u003E 0 \u0026 a \u003C 10?</code></pre>
Of course, since json_escape</code> is aliased as j</code>, you can do this in your ERB templates:</p>
<%=j @person.to_json %></code></pre>
Related changeset: http://github.com/rails/rails/commit/0ff7a2d89fc95dcb0a32ed92aab7156b0778a7ea</a></p>
Automatically parse posted JSON content for Mime::JSON requests</h3>
Rails will now accept POSTed JSON content! For example, you can now send a POST to "/posts" of your Post resource like this:</p>
POST /posts
{"post": {"title": "Breaking News"}}</code></pre>
And your create</code> action will automatically parse the POSTed JSON into the request params</code> so that this code below just works:</p>
def create
  @post = Post.create params[:post]
end</code></pre>
Credit goes to Rick Olson.</p>
Related changeset: http://github.com/rails/rails/commit/4d594cffcfc93b37fad4e423ec8593299e50133c</a></p>
schema_migrations table replaces the schema_info table, allowing for interleaved migrations</h3>
A new schema_migrations table for storing which migrations have been run has been introduced, and this replaces the existing schema_info table (which simply keeps track of the last applied schema version). This change makes it possible to add migrations (for example, after you've merged from someone's branch) - when you migrate your database via rake db:migrate, those never-applied "interleaved" migrations will be run. Similarly, when migrating down schema versions, never-applied "interleaved" will be skipped.</p>
See http://dev.rubyonrails.org/ticket/11493</a> for more information.</p>
This useful patch is the brainchild of Jordi Bunster</a> (WWR profile</a>). I'm sure many Rails developers who branch extensively will thank Jordi for this excellent patch!</p>
Related changeset: http://github.com/rails/rails/commit/8a5a9dcbf64843f064b6e8a0b9c6eea8f0b8536e</a></p>
gems:unpack:dependencies Rake task</h3>
Remember how you can now run the gems:unpack</code> Rake task to unpack a gem into your vendor/gems/</code> directory (this was mentioned in an earlier Living on the Edge</a>)?</p>
David Dollar (Github profile</a>) has firmed up that patch quite a bit by adding the gems:unpack:dependencies</code> Rake task that unpacks the dependencies of the gems as well. So running:</p>
gems:unpack:dependencies GEM=activecouch</code></pre>
would unpack the full Rubygem dependency tree of gems that the activecouch</a> gem depends upon.</p>
Related changeset: http://github.com/rails/rails/commit/4364c361b599f99bc2345ce4eb2d145b07ed8a0f</a></p>
As always, let me know of any suggestions or how I can improve the Living on the Edge (of Rails) series! Now go out there and start forking Rails</a>!</p>


Living on the edge (of Rails) #15 - the early edition
2008-04-06T15:57:01+00:00
I'm gonna post up the Living on the Edge a little earlier this week because I've found I just can't keep up (when things get busy) with 2 separate sets of notes for the Rails Envy podcast</a> and another for my own blog posts.</p>
From this week onwards, I'll be following Pratik</a>'s suggestion to post about changes as they happen instead of after an entire week so expect a slight change in the format of Living on the edge for next week!</p>
This week’s report covers changes from 31 Mar 2008 to 6 Apr 2008 (the day the corresponding Rails Envy podcast</a> was recorded).</p>
Rails.env, Rails.logger, Rails.cache, Rails.root</h3>
This has been a long time coming: You can now use Rails.env</code> instead of RAILS_ENV</code>, Rails.root</code> instead of RAILS_ROOT</code>, Rails.logger</code> instead of RAILS_DEFAULT_LOGGER</code>, and Rails.cache</code> instead of RAILS_CACHE</code>. Not having to use constants is nice because it always felt a bit dirty to have so many hard-coded constants in the Rails namespace.</p>
Credit goes to Pratik Naik</a>, the newest Rails core team member for this cleanup.</p>
Related changeset: http://dev.rubyonrails.org/changeset/9180</a></p>
Render :partial now works with a collection of heterogeneous elements</h3>
You can now use render :partial</code> to render a collection of different elements and Rails will figure out which partial template to use. For example:</p>
render :partial => [ monkey, donkey, dramatic_chipmunk ]</code></pre>
will render the monkey with the 'monkeys/_monkey.html.erb' partial, donkey with the 'donkeys/_donkey.html.erb' partial, and last but definitely not lest, dramatic_gopher with the 'dramatic_chipmunks/_dramatic_chipmunk.html.erb' partial</p>
This is especially useful if when using STI</acronym>, where your ActiveRecord model would return objects of different types. The collection [ monkey, donkey, dramatic_chipmunk ]</code> could very well be something returned from your Animal</code> model that has subclasses of Monkey</code>, Donkey</code> and DramaticChipmunk</code> via STI.</p>
Credit: Zach Dennis</a> of ar-extensions</a> fame.</p>
Related changeset: http://dev.rubyonrails.org/changeset/9177</a></p>
ActiveModel work revived</h3>
It seems like work on ActiveModel (think unified ActiveRecord and ActiveResource behaviors) has been revived, if the latest commits (http://dev.rubyonrails.org/changeset/9171</a> and http://dev.rubyonrails.org/changeset/9173</a>) by David (DHH) is anything to go by.</p>
Bugfix: Assigning an invalid has_one association now causes #save to fail on parent</h3>
You could do this before:</p>
firm = Firm.find(:first)
firm.account = Account.new # Associate INVALID account
firm.save # This doesn't fail</code></pre>
Now that's fixed thanks to Pratik Naik</a>.</p>
Related changeset: http://dev.rubyonrails.org/changeset/9232</a></p>
As usual, any feedback is respectfully appreciated!</p>


Living on the edge (of Rails) #14 - the extreme edition. Extremely late.
2008-04-05T00:04:06+00:00
This week’s report covers changes from 24 Mar 2008 to 30 Mar 2008 (the day the corresponding Rails Envy podcast</a> was recorded).</p>
There're lots of big exciting changes this week on edge. Smells like 2.1 soon!</p>
has_finder gem merged into Rails</h3>
Ryan Daigle has the scoop on the new has_finder-like functionality in Rails</a> so head on over (I won't repeat it here in the interests of DRY</acronym>).</p>
Credit goes to Nick Kallen</a> for coming up with the has_finder gem.</p>
Related changeset: http://dev.rubyonrails.org/changeset/9084</a></p>
ActiveRecord: Unsaved attribute changes are now tracked</h3>
You can now ask an ActiveRecord model whether its attributes have been changed (and is unsaved) using the {attr_name}_changed?</code> (magic) method. The {attr_name}_was</code> method will return the original value of the attribute, and the {attr_name}_change</code> method will return an array with 2 members, the 1st being the original value, the 2nd being the changed (and unsaved) value.</p>
# Change person's name.
person.name = 'Jason Seifer'
person.changed?       # => true
person.name_changed?  # => true
person.name_was       # => 'jseifer'
person.name_change    # => ['jseifer', 'Jason Seifer']
person.name = 'Ceiling Cat'
person.name_change    # => ['jseifer', 'Ceiling Cat']</code></pre>
Credit goes to Rails core team member Jeremy Kemper (bitsweat) for this patch (which originated from Jeremy's very own Dirty plugin</a>).</p>
Related changeset: http://dev.rubyonrails.org/changeset/9127</a></p>
ActiveRecord#Base.all/first/last</h3>
Now you can do:</p>
Post.all.each { |post| # something }
Post.first
Post.last</code></pre>
Kinda like how some other ORMs do (like DataMapper).</p>
Credit: thechrisoshow</a> and again, Nick Kallen for has_finder.</p>
Related changeset: http://dev.rubyonrails.org/changeset/9085</a></p>
Timestamped Migrations</h3>
This is more useful than it sounds: migrations are now timestamped instead of using incremental numbers in your db/migrate folder. This eliminates the problem of migrations having the same version number when working on a multi-developer Rails app.</p>
Two new Rake tasks, rake db:migrate:up/down</code>, have been added to allow running of the up</code> and down</code> methods of individual migrations.</p>
Credit goes to John Barnette, the guy who gave you foxy fixtures</a>.</p>
Related changeset: http://dev.rubyonrails.org/changeset/9122</a></p>
New config.gem option for specifying which gems are required by the application + rake tasks for installing and freezing gems</h3>
Specify which gems are required by your Rails app in your Rails environment.rb</code>! "Vendor everything" supported right in Rails :). An example:</p>
Rails::Initializer.run do |config| 
  config.gems 'chronic'
  config.gems "hpricot", :version => '0.6', :source => "http://code.whytheluckystiff.net"
  config.gems "aws-s3", :lib => "aws/s3"
end</code></pre>
There are also new Rake tasks:</p>
# List required gems. 
rake gems 
Install all required gems:</h1>
rake gems:install</p>
Unpack specified gem to vendor/gems/gem_name-x.x.x</h1>
rake gems:unpack GEM=chronic</code></pre></p>
Credit goes to the prolific Rick Olson</a> for this gem of a patch.</p>
Related changeset: http://dev.rubyonrails.org/changeset/9140</a></p>
ActiveResource #clone</h3>
You can now clone an existing resource:</p>
gregg = Person.find(1)
borg = gregg.clone</code></pre>
This doesn't clone child ActiveResource members though, just the straight up attributes of resource.</p>
Contribors: Ryan Daigle</a> and thechrisoshow</a>.</p>
Related changeset: http://dev.rubyonrails.org/changeset/9121</a></p>
Big documentation patch</h3>
A big doc patch consisting of all the efforts going on in the doc-rails repository on Github</a> has been committed. Check out Pratik's post</a> for more info on what doc-rails is. Though with Rails moving to Git soon, doc-rails may no longer be necessary!</p>
Related changeset: http://dev.rubyonrails.org/changeset/9093</a></p>


Living on the edge (of Rails) #13 - Git script/plugin install, has_one :through
2008-03-27T23:46:34+00:00
It's time again for some edge Rails love. If you haven't listened to it yet, be sure to check out this week's Rails Envy podcast</a></p>
This week’s report covers changes from 17 Mar 2008 to 23 Mar 2008 (the day the corresponding Rails Envy podcast</a> was recorded).</p>
script/plugin install works for Git repositories</h3>
Yup you can now install plugins from Git</a> repositories simply by running:</p>
script/plugin install git://github.com/foo/kung_fu</code></p>
What this really does is to clone a git repository (sans the entire git history by passing the —depth 1</code> option) into your plugins directory. If you're looking for a Piston-like way to manage external Git repositories though, you'd still be better off with the development version of Piston</a> (François Beausoleil, is posting frequently on his progress with adding Git support</a>).</p>
Credit goes to Jack Danger</a>, a long-time Rails contributor for this patch.</p>
Related changeset: http://dev.rubyonrails.org/changeset/9049</a></p>
has_one :through</h3>
It's been a long time coming - now you can do has_one :through</code> (like has_many :through</code>) for your join models. Ryan Daigle</a> has example code</a> on how to use it if you're curious (though really, it's just like has_many).</p>
Credit goes to the Art of Mission</a> guys and Chris O'Sullivan</a> for pulling it all together.</p>
Related changeset: http://dev.rubyonrails.org/changeset/9067</a></p>
rake tasks time:zones:all, time:zones:us and time:zones:local</h3>
Some timezone-related rake tasks have been added to list the names of time zones recognized by the TimeZone</code> class for the config.time_zone</code> option you can put in your environment.rb</code>. For example</p>
rake time:zones:local</code></p>
* UTC +08:00 *
Beijing
Chongqing
Hong Kong
Irkutsk
Kuala Lumpur
Perth
Singapore
Taipei
Ulaan Bataar
Urumqi</code></pre>
Credit: Geoff Buesing (core team member)</p>
Related changeset: http://dev.rubyonrails.org/changeset/9074</a></p>
#number_to_currency helper now supports a :format option</h3>
Now you can do something like:</p>
number_to_currency(123.50, :unit => "£", :format => "%n %u") 
# => 123.50 £</code></pre>
Instead of being stuck with the {currency_code} {amount}</code> format which doesn't work in some locales (such as "42 pounds").</p>
Related changeset: http://dev.rubyonrails.org/changeset/9052</a></p>


Living on the edge (of Rails) #12
2008-03-20T20:19:18+00:00
This week’s report covers changes from 10 Mar 2008 to 16 Mar 2008 (the day the corresponding Rails Envy podcast</a> was recorded).</p>
Custom JavaScript and stylesheet symbols</h3>
Remember how you can do something like:</p>
javascript_include_tag :defaults</code></pre>
and Rails would load all the Prototype JavaScript files and your application.js?</p>
You can now register your own custom expansion symbol too:</p>
# In a Rails initializer.
ActionView::Helpers::AssetTagHelper.register_javascript_expansion :yui => ['yahoo', 'autocomplete', 'calendar']
In your view.</h1>
javascript_include_tag :yui</code></pre></p>
would result in:</p>
<script type="text/javascript" src="/javascripts/yahoo.js"></script>
<script type="text/javascript" src="/javascripts/autocomplete.js"></script>
<script type="text/javascript" src="/javascripts/calendar.js"></script></code></pre>
You can do the same with the stylesheet_link_tag</cpde> by registering a custom expansion symbol via register_stylesheet_expansion</code>.</p>
This is useful for anyone but in particular plugin developers who have a multiple asset files would appreciate being able to tell users to include JavaScript or stylesheets using a single symbol.</p>
Warning</strong>: This patch currently breaks the default symbols like :all</code> (check out the ticket</a> for more info).</p>
Related changeset: http://dev.rubyonrails.org/changeset/9016</a></p>
Sexy default timestamps in migrations</h3>
Remember how you can say timestamps</code> in a migration and Rails will create the 'created_at' and 'updated_at' columns for you? You can now also do add_timestamps :table_name</code> and remove_timestamps :table_name</code> in your migrations if you decide to add these columns later to a table:</p>
def self.up
  add_timestamps :posts
end
def self.down
remove_timestamps :posts
end</code></pre></p>
Related changeset: http://dev.rubyonrails.org/changeset/9014</a></p>
ActiveRecord::Base#find(:last)</h3>
Just like Comment.find(:first)</code>, you can now do something like Comment.find(:last)</code>. There's some controversy over whether this is bloat, but DHH</acronym> makes a good case for it with this example:</p>
class Person
  has_many :comments, :order => 'created_at'
end
@some_person.comments.find(:last) # => Returns the most recent comment.</code></pre></p>
Related changeset: http://dev.rubyonrails.org/changeset/9012</a></p>
Database rake tasks fixes</h3>
rake db:create</code> used to ignore the 'charset' and 'collation' options in your database.yml configuration file. This has been fixed so that your created databases now respect those options.</p>
rake db:drop</code> and rake db:migrate:reset</code> also no longer crash with an unhelpful exception if the database has already been dropped, and instead shows a proper error message.</p>
Related changeset: http://dev.rubyonrails.org/changeset/9004</a></p>
Rails' logger now creates the log directory if it doesn't exist</h3>
This is a blessing to those of us who use version control systems that don't support empty directories (like Git). Rails' default logger (the BufferedLogger), now creates a log/ directory if it doesn't already exist. This should save you the step of creating/symlinking a log/ directory (or symlinking) on deploy.</p>
Related changeset: http://dev.rubyonrails.org/changeset/9013</a></p>
String#squish is faster</h3>
A faster implementation of the String#squish</code> (and String#squish!</code>) core extension has been committed.</p>
Related changeset: http://dev.rubyonrails.org/changeset/9015</a></p>
The #excerpt TextHelper no longer includes 1 character too many</h3>
Turns out that the #excerpt</code> helper method was consistently including an extra character. This has been fixed.</p>
Related changeset: http://dev.rubyonrails.org/changeset/9030</a></p>
As usual, let me know of any inaccuracies or any suggestions you may have in the comments!</p>


Living on the edge (of Rails) #11
2008-03-12T19:39:17+00:00
This week’s report covers changes from 3 Mar 2008 to 9 Mar 2008 (the day the corresponding Rails Envy podcast</a> was recorded).</p>
Improve performance on :include/:conditions/:limit queries by selectively joining in the pre-query</h3>
This is another ActiveRecord performance boost related to the pre-loading any eager-loaded :includes</code> mentioned previously</a>. Basically what this patch does is to only join referenced tables when needed. It does this by checking the :conditions</code> and :limit</code> options to determine whether a table should be joined or can be left out and pre-loaded instead. You can find out more in tickets #9560</a> and #9497</a>.</p>
Credit goes to  Gabe da Silveira</a> (dasil003 on Trac) for this awesome performance patch.</p>
Related changeset: http://dev.rubyonrails.org/changeset/8977</a></p>
Better error message for type errors when parsing request parameters</h3>
Now when you pass an incorrectly formed request (e.g. GET, POST) parameter to your controller, it will raise an exception that includes a friendlier error message that indicates exactly what you passed to it. This is helpful when trying to debug whether you constructed your form correctly.</p>
Contributors: Chad Humphries</a> and matt.</p>
Related changeset: http://dev.rubyonrails.org/changeset/8986</a></p>
Make MimeResponds::Responder#any work without explicit types.</h3>
Here's something I didn't know: you can actually use any</code> in your respond_to</code> blocks as a catch-all response. E.g.</p>
respond_to do |format|
  format.html do
    redirect_to :action => 'login'
  end
  format.any(:js, :xml) do
    request_http_basic_authentication 'Web Password'
  end
end</code></pre>
Contrary to its name, using 'any' actually requires you to pass a list of types to respond to. This has been enhanced now so that if you don't pass any arguments, it'll function as a real catch-all.</p>
respond_to do |format|
  format.any do
    request_http_basic_authentication 'Web Password'
  end
end</code></pre>
Credit goes to Joshua Wehner</a> for this patch.</p>
Related changeset: http://dev.rubyonrails.org/changeset/8987</a></p>
Add readonly option to has_many :through associations</h3>
Turns out the :readonly</code> option for associations mentioned earlier</a> was left out for has_many :through</code> associations. This oversight has been fixed.</p>
Thanks to Emilio Tagua</a> for this bugfix.</p>
Related changeset: http://dev.rubyonrails.org/changeset/8989</a></p>
As usual, let me know of any inaccuracies or any suggestions you may have in the comments!</p>


Living on the edge (of Rails) #10
2008-03-05T20:01:32+00:00
Another awfully sleepy week on Rails edge. Though by the time I had sent over the notes to Gregg Pollack and Jason Seifer of the awesome Rails Envy podcast</a>, there has been some nice changes (that I'll be mentioning next week, but there's absolutely nothing stopping you from checking those out yourself</a>).</p>
In other interesting news, Pratik Naik</a> (lifofifo), a long-time Rails contributor has been given commit rights to Rails. Congrats Pratik, well-deserved and it has been long overdue in my opinion! Pratik keeps an interesting blog at http://m.onkey.org/</a> (where he's not afraid to say "fuck" in his posts and</em> his code) and hangs out an awful lot on #rubyonrails</a> and #rails-contrib</a> on IRC.</p>
As a sidenote, Capistrano 2.2.0 was released</a> by Jamis</a> last week.</p>
This week’s report covers changes from 25 Feb 2008 to 2 Mar 2008 (the day the corresponding Rails Envy podcast</a> was recorded).</p>
Time#end_of_XXX methods</h3>
A bunch of Time core extension methods have been added. These are: Time#end_of_day</code>, Time#end_of_week</code>, Time#end_of_year</code>, and Time#end_of_quarter</code>, which all return exactly what you expect them to return:</p>
Time.now.end_of_week # => Sun Mar 09 00:00:00 0800 2008</code></pre>
Credit goes to Juanjo Bazán</a> (a former Rails Hackfest winner</a>) and Tarmo Tänav</a> for contributing this patch.</p>
Related changeset: http://dev.rubyonrails.org/changeset/8934</a></p>
Date helpers now accept HTML options</h3>
ActionView's date helpers (such as date_select</code>, time_select</code>, select_datetime</code>) did not support any HTML options, unlike the other helpers (like f.text_field(:name, :class => 'my_css_class', :size => 20)</code>). This inconsistency has been fixed and you can now finally do:</p>
<%= date_select 'user', 'birthday', :order => [:day], :class => 'my_css_class' %></code></pre>
Murray Steele</a> (h-lame on the Rails Trac) and Jakob Skjerning</a> contributed this patch.</p>
Related changeset: http://dev.rubyonrails.org/changeset/8968</a></p>
No need for explicit respond_to for RJS templates</h3>
ActionController has been changed so that JS requests will automatically render action.js.rjs files without the need to specify an explicit respond_to</code> block. This means that your .rjs files work the same way as your .html.erb files - just put them in the right place and Rails will use it.</p>
Related changeset: http://dev.rubyonrails.org/changeset/8956</a></p>
Bugfixes</h3>

http://dev.rubyonrails.org/changeset/8937 - Prevent Rails from crashing when trying to deserialize an XML representation of a model named "Type" (using Hash#from_xml). Contributed by Juanjo Bazán</a> and Isaac Feliu</a>.</li>
http://dev.rubyonrails.org/changeset/8942 - Fix eager loading so that it doesn't pull in duplicate records in some cases. Contributed by Catfish.</li>
</ul>
As usual, let me know of any inaccuracies or any suggestions you may have in the comments!</p>


Living on the edge (of Rails) #9 - the sleeper edition
2008-02-27T09:56:49+00:00
It's been a slow week on the Rails trunk this week in terms of exciting changes.</p>
This week’s report covers changes from 18 Feb 2008 to 24 Feb 2008 (the day the corresponding Rails Envy podcast</a> was recorded).</p>
ActiveResource::Base now accepts user and password configuration</h3>
You can now set the user and password for HTTP authentication in your ActiveResource models:</p>
class Person < ActiveResource::Base
  self.site = 'http://example.com/'
  self.user = 'konata'
  self.password = 'password'
end</code></pre>
This is a better way to specify authentication credentials than the current way of doing it by putting it all in the site (e.g. self.site = 'http://konata:password@example.com/'</code>).</p>
Related changeset: http://dev.rubyonrails.org/changeset/8891</a></p>
script/plugin install now supports SVN export</h3>
You can now pass the -e/--export</code> option to script/plugin install</code> to do an Subversion export of the plugin. This allows you to then check in the plugin's files into your own repository. Though seriously, if anyone really wants to do this, I'd suggest they use Piston</a>. That is, for those of us still using Subversion rather than Git.</p>
Related changeset: http://dev.rubyonrails.org/changeset/8921</a></p>
Bug fixes for associations preloading</h3>
There've been some bug fixes the associations preloading change mentioned in Living on the edge #5</a>:</p>

http://dev.rubyonrails.org/changeset/8894</a> - Fixed a bug where associations that were preloaded (using nested :includes</code>) errors out when the associations return nil</code> (i.e. when there are no associated records).</li>
http://dev.rubyonrails.org/ticket/11154</a> - Fixed a bug where nested includes were assuming that all records are from the same class. This is not true for polymorphic associations, causing problems when they were being used.</li>
</ul>
Yup, that's it for this week. As usual, let me know of anything I might have missed or any suggestions you may have in the comments!</p>


Living on the edge (of Rails) #8 - the code optimization edition
2008-02-19T23:30:54+00:00
Here's this week's update of the important changes that have been happening on edge Rails. There were lots of performance patches this week, credit mostly due to the guys from Acunote</a> and their latest blog post on optimizing Rails</a>.</p>
This week’s report covers changes from 11 Feb 2008 to 17 Feb 2008 (the day the corresponding Rails Envy podcast</a> was recorded).</p>
ActiveRecord::Base#attributes-related optimizations</h3>
The ActiveRecord::Base#attributes_before_typecast</code> no longer clones attribute unnecessarily.</p>
Related changeset: http://dev.rubyonrails.org/changeset/8858</a></p>
ActiveRecord::Base#attributes</code> now no longer supports options. The ActiveRecord::Base#attributes</code> method used to support :only</code> and :except</code> options, which are actually unnecessary since it returns a Hash. You can use Hash#slice</code> or Hash#except</code> (both ActiveSupport core extensions) directly on the hash.</p>
Related changeset: http://dev.rubyonrails.org/changeset/8863</a></p>
ActiveRecord associations optimized by avoiding named block arguments</h3>
Alexander Dymo is at it again optimizing ActiveRecord performance, this time by avoiding passing named block arguments. Turns out that it is faster and more memory efficient in Ruby to pass blocks like this:</p>
def foo
  bar { |*block_args| yield(*block_args) if block_given?
end</code></pre>
instead of passing the block around like so:</p>
def foo(&&block)
  bar(&block)
end</code></pre>
Occurrences of the more expensive way of passing blocks have been replaced in the ActiveRecord associations code so associations are lighter to use.</p>
For a more detailed write-up, check out Alexander's blog entry</a>.</p>
Related changeset: http://dev.rubyonrails.org/changeset/8865</a></p>
ActiveRecord associations optimized by using symbol callbacks instead of string callbacks</h3>
Again from Alexander Dymo, this patch also improving ActiveRecord association performance. Internally, ActiveRecord associations code uses a lot of string callbacks (e.g. before_save "some_ruby_code_to_eval"</code>). It turns out that that is significantly more expensive compared to simply using Module#define_method</code> because when the callback string is evaluated, the binding needs to be passed along. Passing the binding takes up memory (which is bad, of course).</p>
The internal associations code has been changed to use that define_method</code> now, and if you're using a lot of associations, you would save megabytes of memory! (Alexander's blog post</a> has more detailed benchmarks.)</p>
Remember, when writing your own before and after filters, not to use a string that needs to be eval</code>ed!</p>
Related changeset: http://dev.rubyonrails.org/changeset/8867</a></p>
Improve ActiveRecord::Base#save performance by avoiding repeated calls to ActiveRecord::Base#connection</h3>
Another Alexander Dymo performance patch. This particular patch improves performance by getting the connection object just once and calling it directly, instead of needlessly calling several times. This should improve ActiveRecord::Base#save</code> performance.</p>
Related changeset: http://dev.rubyonrails.org/changeset/8871</a></p>
ActiveRecord associations now support the :readonly option</h3>
ActiveRecord::Base#find</code> supports the :readonly</code> option to retrieve records that were read-only (i.e. you couldn't save them). Now you can do the same for associations, like so:</p>
has_many :comments, :readonly => true</code></pre>
This allows you to protect associated records from being saved.</p>
Related changeset: http://dev.rubyonrails.org/changeset/8864</a></p>
String#squish and String#squish! to remove consecutive chunks of whitespace</h3>
A String#squish</code> extension has been added that trims whitespace from both ends of a string, and compressing consecutive whitespace groups within the string into 1 space each.</p>
For example,</p>
@description = %{ String#squish() allows me to write long strings
  inside my Ruby code, without having to worry about indentation,
  the page margin, spaces, tabs or newlines. "double" or 'single'
  quotes are both fine, and #{interpolation} works. }.squish
</code></pre>
Related changeset: http://dev.rubyonrails.org/changeset/8878</a></p>
As always, let me know of any inaccuracies or any suggestions you may have in the comments, see you guys next week!</p>


Living on the edge (of Rails) #7 - improved ActiveRecord::Base#attributes, time zone support
2008-02-13T23:49:44+00:00
It's that time of the week again (every Wednesday for the overly observant, coinciding with the release of the Rails Envy podcast</a>) for some choice updates of what changes have been happening on edge Rails. This week's report covers changes from 4 Feb 2008 to 10 Feb 2008 (the day the Rails Envy podcast</a> was recorded).</p>
More efficent ActiveRecord::Base#attributes</h3>
ActiveRecord::Base#attributes</code> returns a hash of all attributes with clones of their objects as values. This unnecessary cloning is expensive, and has now been removed. ActiveRecord::Base#attributes</code> now returns a hash of values</em> of the attributes.</p>
Thanks to Juanjo Bazan, there have been 2 further patches (after the podcast was recorded) related ActiveRecord::Base#attributes</code> that further improves ActiveRecord's performance: removal of cloning from ActiveRecord::Base#attributes_before_typecast</code></a>, and removing options (:only</code> and :except</code> options, specifically) from ActiveRecord::Base#attributes</code></a>.</p>
Related changeset: http://dev.rubyonrails.org/changeset/8824</a></p>
ActiveResouce::Base#exists? now uses HTTP HEAD instead of a GET</h3>
A HTTP HEAD</a> request is really all that is needed to check for existence (200 == exists, 404 == doesn't exist). This has been changed to HEAD from a GET request, which is more efficient since all we retrieve are the HTTP headers and there's no unnecessary instantiation of the ActiveResource object.</p>
Related changeset: http://dev.rubyonrails.org/changeset/8827</a></p>
Time zone support for ActiveRecord, and config.time_zone property for specifying a default Time Zone</h3>
ActiveRecord models now have time zone-aware attribute readers and writers. Times returned from ActiveRecord attribute readers now have a time_zone</code> attribute themselves, allowing time zone-aware calculations.</p>
You can now configure the default Time.zone</code> value with config.time_zone</code> in your environment.rb</code>. Setting this will enable time zone-awareness for ActiveRecord models.</p>
Related changeset: http://dev.rubyonrails.org/changeset/8806</a></p>
A Template class has been introduced to ActionView</h3>
As part of the ActionPack refactoring that's still ongoing, a ActionView::Template</code> class has been introduced to encapsulate all the data relevant to the currently rendered template. This is largely an internal refactoring so Rails users shouldn't be affected.</p>
Related changeset: http://dev.rubyonrails.org/changeset/8805</a></p>
Concrete sweeper classes</h3>
You can now use an explicit class when declaring a cache_sweeper. E.g.</p>
class ListsController < ApplicationController 
  caches_action :index, :show, :public, :feed 
  cache_sweeper Sweepers::List, :only => [ :edit, :destroy, :share ] 
end</code></pre>
Related changeset: http://dev.rubyonrails.org/changeset/8819</a></p>
As always, let me know of any inaccuracies or any suggestions you may have in the comments - this week's report is a little rushed because I'm a little late in posting it up!</p>


Living on the edge (of Rails) #6 - better performance, Git support, and more
2008-02-06T21:54:37+00:00
Here's another week of noteworthy updates on the Rails trunk. Thanks once again to the Rails Envy podcast</a> for featuring my updates, and even bigger thanks to the Rails contributors and committers who make things happen. This week's Living on the Edge was covered in Rails Envy podcast #17</a>.</p>
The company I work for, Bezurk</a> (yeah we know some of you hate the name "Bezurk" - that's going to change), is currently looking for a Ruby developer to join our ranks. This person will be working mainly on Ruby-based web development projects. As we all know, "Rails doesn't scale" (delivered in Jason Seifer-style - meaning it's just a joke!) so we'd love anyone who's up for a challenge and who's also willing to work outside the Rails comfort zone (our current favorite: Ramaze</a>). Our Ruby team currently comprises 3 experienced developers and 1 up and coming Rubyist.</p>
We're active Open Source contributors (Arun released ActiveCouch</a> recently), while I am a Rails contributor (I'm 'chuyeow' on the Rails Trac</a>) myself.</p>
If all this sounds interesting enough to you, do check out the full job description</a> and drop us an email. Yes, we're serious when we said "+1 for DotA/Counterstrike skills)". There's a catch though - you have to work on location at our office in Singapore.</p>
Anyway, let's get back on topic - this weeks’ report covers changes from 28 Jan 2008 to 3 Feb 2008 (the day the Rails Envy podcast was recorded).</p>
Saving, creating and updating ActiveRecord objects is more efficient</h3>
Thanks to Gleb Arshinov and Alexander Dymo with their blog post and patches about improving Rails performance</a> by approaching it via minimizing garbage collection, saving, creating, and updating ActiveRecord objects is now significantly more efficient.</p>
The expensive ActiveRecord::Base#attributes</code> method is no longer called internally, so there's no unnecessary cloning of attribute values. Less memory usage means less garbage collection, which means better performance!</p>
Related changeset: http://dev.rubyonrails.org/changeset/8770</a></p>
SQL calls and rendering are faster</h3>
This patch is courtesy of Gleb Arshinov and Alexander Dymo</a> too.</p>
Rails surrounds every SQL call and ActionView::Base#render</code> with the ruby method Benchmark#realtime</code> so that it can print out some benchmarking numbers. Benchmark#realtime</code> allocates an unnecessary 45k of memory per call (who knew!). This has been monkey patched in Rails to a leaner implementation, reducing memory usage and increasing performance.</p>
Related changeset: http://dev.rubyonrails.org/changeset/8771</a></p>
MySQL adapter slight optimization</h3>
Table and column names in the MySQL adapter are now cached in instance variables, reducing memory allocations (and thus the need for GC</acronym>).</p>
Related changeset: http://dev.rubyonrails.org/changeset/8794</a></p>
script/generate does Git!</h3>
script/generate</code> now allows you to pass the '--git' (or '-g') option to add the generated files to git (much like how you could do the same with Subversion with '-c' or '--svn'). This patch is the work of Steven Soroka</a> so nice work Steven!</p>
Related changeset: http://dev.rubyonrails.org/changeset/8772</a></p>
map.resources :products, :as => 'something_else'</h3>
Here's something that will make non-english Rails developers happy: you can now do, for example,</p>
map.resources :comments, :as => 'comentarios'</code></pre>
so that you can keep having your model names independent of what URLs you'd actually like to appear on the site.</p>
The above map.resources</code> means that you can keep your resource and model names in English (Comment), while having URLs like this: /comentarios/123.</p>
Related changeset: http://dev.rubyonrails.org/changeset/8785</a></p>
:index option for form_for and fields_for to simplify multi-model forms</h3>
Inspired by a Railscasts episode</a> where Ryan Bates mentions how ugly it is to have to pass :index => nil</code> to prevent #text_field</code> (and other form helpers) from inserting the model's ID in the input name (e.g. project[task_attributes][123][name] when what you really want is project[task_attributes][][name]).</p>
Meaning instead of</p>
<% fields_for "project[task_attributes][]", task do |f| %>
  <%= f.text_field :name, :index => nil %>
  <%= f.hidden_field :id, :index => nil %>
<% end %></code></pre>
you can now do:</p>
<% fields_for "project[task_attributes][]", task, :index => nil do |f| %>
  <%= f.text_field :name %>
  <%= f.hidden_field :id %>
<% end %></code></pre>
Related changeset: http://dev.rubyonrails.org/changeset/8786</a></p>
No more emails in your production logs</h3>
You'd probably have noticed that ActionMailer logs entire</em> email messages in the log, even in production. Well, it's been changed to be less verbose now. At the :info</code> log level, only the recipients are logged. You can still see the entire email at the :debug</code> log level (which is the default for development environment).</p>
Related changeset: http://dev.rubyonrails.org/changeset/8781</a></p>
As always, let me know of any inaccuracies or any suggestions you may have in the comments. Oh, and if you liked this, do me a favor by submitting it to Ruby Reddit</a>.</p>


ActiveCouch - a CouchDB library in the spirit of ActiveResource and ActiveRecord
2008-02-02T14:25:48+00:00
My fellow Rubyist at work, Arun Thampi</a>, has released ActiveCouch</a>, a Ruby library for CouchDB</a> (if you don't know what CouchDB is, read this</a>). Check out the official blog announcement of ActiveCouch</a>.</p>
ActiveCouch tries to be an ActiveResource and ActiveRecord (yes, there is even an ActiveCouch::Migration</code> class for creating CouchDB views) equivalent for representing CouchDB documents in Ruby. I wish I could write some coherent code examples here but I am not that up to date with the latest changes in ActiveCouch (despite my name being tagged as a committer to ActiveCouch, it is largely Arun's</a> awesome little baby).</p>
Never fear though, since Arun and I are chowing down our own dog food - we're currently porting several gigabytes worth of hotel data from our hacked together XML and Ferret-based library to use the ActiveCouch</a> library. I'm sure we'll get a more coherent API after this exercise, since we are no longer relying on specs and mocks, but working on a Real Application.</p>
If you decide to try out ActiveCouch, do let us know of any feedback or bug reports at the ActiveCouch Google Code site</a>. ActiveCouch is Open Source, so if you've patches that's even better!</p>


Living on the edge (of Rails) #5 - better eager loading and more
2008-01-30T18:26:39+00:00
Another week of edge Rails changes, featured on the Rails Envy podcast</a>. This weeks’ report covers changes from 21 Jan 2008 to 27 Jan 2008 (the day the Rails Envy podcast</a> was recorded).</p>
Eager loading :includes does pre-loading</h3>
The current gem Rails behavior when loading associations with something like</p>
Author.find(:all, :include => [:posts, :comments])</code></pre>
is to make a big query with multiple joins that fetches all the associations in the same query (for you RDBMS geeks, the "cartesian product").</p>
Frederick Cheung (fcheung on the Rails Trac) has contributed an impressive optimization to this by pre-loading the associations rather than trying to eager loading with one big query. So a find like this:</p>
Author.find(:all, :include => [:posts, :comments])</code></pre>
would first load all the authors, then all the posts, and then all the comments in 3 smaller, faster queries.</p>
The main benefit of this (depending on your data): Running X simple queries (to fetch authors, then posts and comments) rather than one mega-query that joins all the associated tables is faster most of the time. The result set is often smaller as well.</p>
More details can be found at ticket #9640 on the Rails Trac</a>.</p>
Related changeset: http://dev.rubyonrails.org/changeset/8672</a></p>
composed_of</code> aggregations can now be used in finder conditions</h3>
You can now use value objects that you've previously specified that your model is composed_of</code> in the finder conditions hash. E.g. if you have a Customer that has a balance aggregation:</p>
class Customer < ActiveRecord::Base
  composed_of :balance, :class_name => "Money", :mapping => %w(balance amount)
end</code></pre>
You can now pass a Money value object to Customer#find</code>:</p>
Customer.find(:all, :conditions => { :balance => Money.new(20, "USD") })</code></pre>
Convenient.</p>
Related changeset: http://dev.rubyonrails.org/changeset/8671</a></p>
New helper: label_tag</h3>
A label_tag</code> helper has been missing for quite awhile since the label helper was added. No longer:</p>
label_tag 'name'
# => <label for="name">Name</label>
label_tag 'name', 'Your name'</p>
=> <label for="name">Your name</label></code></pre></h1>
Related changeset: http://dev.rubyonrails.org/changeset/8685</a></p>
New ActiveSupport class: ActiveSupport::TimeWithZone</h3>
A new ActiveSupport::TimeWithZone</code> class</a> has been introduced to make timezone support in Rails easier. Ryan Daigle has a good writeup</a> on this.</p>
A word of warning though: this is still work in progress, as Geoff Buesing, the core team member responsible for these timezone changes, has more to add on how his plans for the timezone puzzle in the comments</a>.</p>
Related changeset: http://dev.rubyonrails.org/changeset/8696</a></p>
map.root can be easily aliased</h3>
map.root</code> now accept a single symbol as an argument to declare an alias. Just a little something to keep your routes a little more DRY, e.g.:</p>
map.new_session :controller => 'sessions', :action => 'new' 
map.root :new_session</code></pre>
Related changeset: http://dev.rubyonrails.org/changeset/8738</a></p>
As usual, let me know of any inaccuracies or any suggestions you may have in the comments!</p>


Rails and penis enhancements
2008-01-25T13:34:26+00:00
Funniest bug report I've seen on the Rails issue tracker</a>: http://dev.rubyonrails.org/ticket/10919</a>. Be sure to read the comments, and the resolution:</p>
I appreciate that penis enhancements are the norm for most of the commenters here, but their use is definitely not widespread enough to justify fixing this.</p></blockquote>


Living on the edge (of Rails) #4 - faster routes, easier form partials
2008-01-23T19:54:46+00:00
It's time again for your weekly dose of what's new in edge Rails. This weeks' report covers changes from 14 Jan 2008 to 20 Jan 2008 (the day the Rails Envy podcast</a> was recorded).</p>
Route recognition is faster</h3>
Rails' route recognition has been optimized and is significantly faster especially for applications using many resources (i.e. via map.resources</code> in your config/routes.rb</code>). Big thumbs up to Oleg Andreev (aka oleganza) who also wrote a detailed post about it</a>. You can also find out more about how this works in the code comments</a>.</p>
Related changesets: http://dev.rubyonrails.org/changeset/8674</a> and http://dev.rubyonrails.org/changeset/8652</a>.</p>
render :partial and forms</h3>
Instead of doing:</p>
<% form_for(:person) do |f| %>
  <%= render :partial => 'form', :locals => { :form => f } %>
<% end %></code></pre>
you can now do:</p>
<% form_for(:person) do |f| %>
  <%= render :partial => f %>
<% end %></code></pre>
Convenient. This also works with your custom form builders</a>:</p>
<% form_for(:person, :builder => LabellingFormBuilder) do |f| %>
  <%= render :partial => f %>
<% end %></code></pre>
The partial template rendered is then people/_labelling_form</code> and the local variable in the partial is labelling_form</code>.</p>
Related changeset: http://dev.rubyonrails.org/changeset/8646</a>.</p>
Callbacks refactored into ActiveSupport::Callbacks</h3>
All that duplicated callback code in ActiveRecord, ActionController::Dispatcher, and in test case setup and teardown methods have been extracted into the ActiveSupport::Callbacks module.</p>
Less duplication means more robust code so yay!</p>
Related changeset: http://dev.rubyonrails.org/changeset/8664</a>.</p>
ActiveRecord test suite gets a makeover</h3>
The ActiveRecord test suite has become something of a maze jungle in recent times, with no clear hierarchy of how things are organize. It's not that easy to find what you are looking for especially for newcomers trying to contribute to ActiveRecord. Thankfully, someone (John Barnette - the foxy fixtures guy) has stepped up and cleaned things up quite a bit. Fixtures, test cases, fixture models, etc. are now in their own directories and from looking at the directory hierarchy one should be able to know where to put what at a glance.</p>
Related ticket: http://dev.rubyonrails.org/ticket/10742</a>.</p>
Bugfixes</h3>
* redirect_to nil</code> no longer explodes (but raises a friendlier 'cannot redirect to nil' exception) (related changeset: http://dev.rubyonrails.org/changeset/8633</a>).</p>


Seen in the Rails source - Orcl nds shrt indx nms
2008-01-18T18:35:41+00:00
</div>

</p>
Hah.</p>


Living on the Edge (of Rails) #3 - X-Sendfile and many other sexy enhancements
2008-01-16T23:25:48+00:00
Edge Rails saw a barrage of refinements and enhancements this week and there's even talk about Rails 2.1 being just a little around the corner. There's also been a flurry of contributions to making Rails more thread-safe and performance optimizations (all still work in progress at the moment) - it's really nice to see how the Rails community is looking seriously at performance post-Rails 2.0 (not that they weren't serious about performance before Rails 2.0!).</p>
This week’s report covers changes from 7 Jan 2008 to the day the corresponding Rails Envy podcast</a> was recorded (13 Jan 2008).</p>
X-Sendfile gets easier with send_file :x_sendfile => true</h3>
If you only have a vague idea of what it is (like, X-Sendfile is that thing that lets you send files, right?), you'd do well to read this helpful explanation</a>. (In short, X-Sendfile allows you to send static files directly and more performantly to HTTP clients and bypassing your app server process.) You don't have to set those headers yourself or install the plugin mentioned in that article though, since edge Rails has an augmented send_file</code></a> helper that does all the legwork for you.</p>
All you have to do now is to this:</p>
send_file '/path/to.png', :x_sendfile => true, :type => 'image/png'</code></pre>
Rails will set the X-Sendfile header for you (i.e. response.headers['X-Sendfile'] = '/path/to.png'</code>) and sends a HEAD response (empty response body) with the file path, allowing your web server (Apache, Lighttpd) to serve the static file and not involve your Rails processes (such as your precious, perpertually resource-starved mongrels</a>).</p>
This is really</em> nice if you are serving lots of static files (downloadable images and documents come to mind) and are not already using X-Sendfile or doing it the "long" way (by setting the response header and then render :nothing => true</code>).</p>
Related changeset: http://dev.rubyonrails.org/changeset/8628</a></p>
ActionController::Base.asset_host proc now takes the request object as an optional 2nd argument</h3>
Rails 2.0.2 allowed you to set ActionController::Base.asset_host</code> to a proc that took a single source</code> argument (as detailed in my earlier post</a>). People were still running into problems</a> with asset hosting though, particularly while trying to serve assets from an SSL-protected page (i.e. HTTPS requests). When serving SSL-protected pages, you'd need to either have an SSL certificate for each asset host(!) or live with a mixed media warning (which browsers report when you have SSL and non-SSL content on the same page).</p>
The asset_host</code> proc now takes the entire controller request instance as an optional second argument. This allows you to either use a single asset host or to disable asset hosting for SSL requests. For example, this proc below practically disables asset hosting:</p>
ActionController::Base.asset_host = Proc.new { |source, request| 
  if request.ssl? 
    "#{request.protocol}#{request.host_with_port}" # Disable asset hosting.
  else 
    "#{request.protocol}assets.example.com" # Use asset host.
  end 
}</code></pre>
Related changeset: http://dev.rubyonrails.org/changeset/8578</a></p>
Nicer way to access request headers</h3>
There's now a nicer way to access headers - instead of request.env["HTTP_CONTENT_TYPE"]</code> you can now do request.headers["Content-Type"]</code> (or request.headers["content-type"]</code> (note all lowercase) or even good old request.headers["HTTP_CONTENT_TYPE"]</code>. How convenient - I often worry about getting the casing right (was it 'Content-Type' or 'Content-type'?) and now I can be sure it doesn't matter!</p>
Related changeset: http://dev.rubyonrails.org/changeset/8625</a></p>
ActiveSupport::TestCase and friends now support declarative setup and teardown callbacks</h3>
ActiveSupport::TestCase</code> (and the ActionController::TestCase</code> and ActionMailer::TestCase</code> subclasses) now support declarative setup and teardown callbacks that are called before setup/after teardown. For example,</p>
class FooTestCase < ActiveSupport::TestCase
  setup :run_this_first, :then_run_this do
    # Run this last.
  end
  teardown :remove_tmp_files, :undef_constants
def run_this_first
end</p>
def then_run_this
end</p>
def remove_tmp_files
end</p>
def undef_constants
end
end</code></pre></p>
will run run_this_first</code>, then_run_this</code>, and finally the stuff that's in the given block to 'setup' before running the actual setup</code> method. The teardown callbacks are done in reverse order, meaning undef_constants</code> is called, and then remove_tmp_files</code> (and then the actual teardown</code> method).</p>
Related changeset: http://dev.rubyonrails.org/changeset/8570</a></p>
TMail updated to 1.2.1</h3>
The bundled TMail</a> library (that ActionMailer uses) has been updated from 1.1.0 to 1.2.1. This new version currently maintained by Mikel Lindsaar</a> promises bugfixes and greater test coverage. For more details, see https://rubyforge.org/frs/shownotes.php?group_id=4512&release_id=18049</a>.</p>
Mikel has been working with Rails core to get Tmail Ruby 1.9-compatible. Good work Mikel!</p>
Related changeset: http://dev.rubyonrails.org/changeset/8620</a></p>
Bug fixes</h3>


    ActionController::UrlWriter</code> respects the relative_url_root</code>. For those of you who don't know, the ActionController::UrlWriter</code> module is a convenient mixin that allows you to use url_for</code> and</em> your named routes in arbitrary classes (such as in your mailers or in a BackgrounDRb worker).</p>
class SitemapWorker < BackgrounDRb::MetaWorker
  include ActionController::UrlWriter</strong>
Access your named routes and the url_for helper.</h1>
url = page_url(:permalink => 'foo')
end</code></pre></p>
  And now it respects your relative_url_root</code> instead of blissfully ignoring it.</p>
  Related changeset: http://dev.rubyonrails.org/changeset/8616</a>
  </li>

    render :text => nil</code> and render :text => false</code> work properly now instead of inexplicably trying to render a file. This was a big gotcha when using render :text => some_variable</code> where some_variable</code> could potentially be false or nil in some cases - Obie Fernandez has a writeup on this long-standing bug</a>. Related changeset: http://dev.rubyonrails.org/changeset/8577</a>
  </li>
</ul>
Optimizations</h3>
There're significant performance improvements for classic fixtures with HABTM data, due to some slightly clever caching model classes, and instantiating fixtures from the model class, instead of expensive constant lookups from the name of the class.</p>
Related changesets: http://dev.rubyonrails.org/changeset/8560</a> and http://dev.rubyonrails.org/changeset/8561</a></p>


Living on the Edge (of Rails) - 1st week of the year edition
2008-01-09T22:18:20+00:00
Yup, it's time for your weekly dose of the changes on edge Rails, more or less covered in the latest Rails Envy podcast</a>. Using edge Rails is neither arcane nor terrifying, and hopefully weekly reports like these will allow you to take control of your own release schedule</a> with your Rails apps.</p>
This week's report covers changes from 31 Dec 2007 to the day the podcast was recorded (6 Jan 2007).</p>
Caching changes</h3>
Looks like most of the changes from the 2.1 caching branch</a> have been

merged into the trunk</a>. Some key points:</p>

memcache-client has been vendored</a> (included in Rails directly). MemCacheStore works out of the box in Rails now, no need to install the memcache-client gem</a>!</li>
The caching code has been refactored and moved into ActiveSupport (ActiveSupport::Cache::*</code>).</li>
Added ActiveRecord::Base.cache_key</code> to make it easier to cache Active Records in combination with the ActiveSupport cache libraries introduced in this changeset.</li>
Fragment cache keys are now by default prefixed with 'views/'.</li>
Deprecation</em>: ActionController::Base.fragment_cache_store</code> is now ActionController::Base.cache_store</code></li>
</ol>
Fragment caching now works in RJS and Builder templates</h3>
Yup, you couldn't do fragment caching in non-erb views before - now you can</a>.</p>
Freezing Rails now automatically updates your Rails app</h3>
If you're using edge Rails and use the rails:freeze:edge</code> rake task, you probably usually forget to run (or maybe you're not even aware of) rake rails:update</code> to update your Rails app with the latest config/, scripts/ and javascript files from the version of Rails you just froze to. On edge Rails, the rake rails:freeze:edge</code> task runs the rails:update</code> task for you. +1 for convenience!</p>
I prefer to use Piston</a> so I'm gonna have to keep remembering to run my rake rails:update</code> now and then!</p>
Check out the related changeset</a>.</p>
Optimizations</h3>
Only 1 optimization in the past week worth talking about: the ActiveRecord::Base#exists?</code> method is faster. It now uses ActiveRecord::Base#select_all</code> instead of a more expensive ActiveRecord::Base#find</code> that unnecessarily instantiates AR objects. (Check out the related changeset</a>.)</p>
Bug fixes</h3>

http://dev.rubyonrails.org/changeset/8541</a> - Fixed a nasty bug when trying to render partials with layout when done from within the site layout. Yes, you can have layouts for your partials in Rails 2</a>, and yes, you can run into a bug when trying to use partial layouts in your main page layout.</li>
http://dev.rubyonrails.org/changeset/8529</a> - Fix atom_feed_helper</code> to comply with the Atom specifications</a>.</li>
</ul>


self.plug :with => 'Rails Hackfest'
2008-01-03T23:24:27+00:00
Yes, it's a plug for myself</a> and it's shameless:</p>
</div>

</p>
Whatever Zed Shaw may say about Rails its community</a>, Rails has done a huge part in making web development fun again for jaded web developers (first-time web developers probably won't be able to tell the difference), and more importantly, raising the profile of Ruby more than any other Ruby project/library/framework/tool ever did (and I'm sure we're all constantly rolling our eyeballs at the new web frameworks that're so terribly familiarly Rails-like). Hell, I bet at least 90% of Rubyists now wouldn't even be Rubyists if they hadn't come across the web framework that could</a> 2 or 3 years ago. So yes I'd still be contributing to Rails so that it can make my life as a web developer easier, thank you.</p>
I think I had about 18 accepted patches in December 2007 Rails Hackfest</a> (a few of the patches were not attributed properly in the Hackfest due to technical issues with the Rails Hackfest site).</p>
Probably the only significant patches were:</p>

Allowing a proc to be set for ActionController::Base.asset_host</code> (changeset 8421</a>).</li>
to_xml</code> should not automatically pass :procs</code> to associations included with :include</code> (changeset 8258</a>).</li>
</ul>
Of course Ruby 1.9 compatibility was a big deal in December 2007 since that Ruby 1.9 was targetted to be released on Christmas (changesets 8369</a>, 8309</a>, 8398</a>, 8397</a>, 8412</a>). Yes, I know, Ruby 1.9 is a development release.</p>
There were also broken tests to be fixed (changeset 8271</a>), bugs to be fixed (fixing Array#to_sentence</code></a>), and some refactoring (changesets 8343</a> and 8522</a>).</p>
And what would patching Rails be without random documentation fixes (changesets 8457</a>, 8471</a>, 8472</a>, 8280</a>, 8279</a>, 8278</a>, 8521</a>). The API documentation always needs a hand, so if you see any outdated or incorrect documentation, or think you can improve them with better examples or whatever, just submit a patch</a> (it's easy and should take you all of 3 minutes).</p>
This month's hackfest</a> has a terribly attractive top prize of a RailsConf ticket</a>. Too bad I won't be able to take part in this month's hackfest since winners of past month's hackfest are automatically excluded from the next's. But maybe you can ;).</p>


Living on the Edge (of Rails) - the pilot
2008-01-02T19:30:57+00:00
Gregg Pollack of Rails Envy</a> (the guys behind your favorite Ruby on Rails vs everything commercials</a>) asked me recently whether I could provide them with weekly updates of changes on edge Rails for the Rails Envy Podcast</a> (which is often hilarious besides being informative), seeing as I am already keeping up with developments on the Rails trunk while doing my small part contributing to Rails. Of course, I responded with a +1.</p>
The podcast is now available</a> and contains only abbreviated notes about the changes that I'd sent over to Gregg, so here's the detailed version of changes on edge Rails from the release of Rails 2.0.2 (17 Dec 2007) to the day the podcast was recorded (30 Dec 2007).</p>
Noteworthy changes on edge Rails: 2007-12-17 to 2007-12-30</h3>
Native mongrel handler</h4>
A native Mongrel handler has been introduced</a>. This is so that it can be worked on independent of Mongrel</a>'s release cycle (the Rails handler is currently in the Mongrel codebase). Jeremy Kemper</a> (bitsweat) has already made a minor performance improvement by moving the mutex from the handler itself into the dispatcher. This means that as Rails gets more threadsafe, the Rails team can push the mutex further down so that it's not a (scary) giant lock (the existing Mongrel Rails handler has a synchronized block around Rails' dispatcher).</p>
Note: The native mongrel handler is not used by default at this time on edge Rails.</p>
Caching branch for Rails 2.1</h4>
A caching branch</a> has been introduced, targeted for Rails 2.1. Other than being a big refactoring, there's also native cache key management (e.g. Product.find(5).cache_key # => "products/5"</code>) and memcache integration is also being looked at.</p>
Ruby 1.9 compatibility continues...</h4>
Yup, work on Ruby 1.9 compatibility for Rails continues. Rails is fortunate to have committers and contributors who are so keen on being 1.9-compatible - free performance gains are hard to turn down after all. There's been lots of patching going on to deal with the changes in Ruby 1.9 (Unicode changes, new syntax, deprecations, etc.).</p>
Yes, the Rails committers and contributors working on 1.9-compatibility are fully aware that Ruby 1.9 is a development</strong> release, but nothing's lost in making sure Rails is compatible with a version of Ruby that will eventually be a production version of Ruby. Besides, I think most of the 1.9-compatibility contributors have a dream that sometime soon, when Ruby 1.9 becomes "stable" enough, we'd be running our Rails applications on Ruby 1.9 for a free performance boost.</p>
Too bad running Rails on Ruby 1.9 is not really possible at the moment since other projects like Mongrel need to be updated for Ruby 1.9 as well, first.</p>
Bugfixes</h4>

The new TestCase subclasses</a> (ActionController::TestCase</code>,

  ActionMailer::TestCase</code>) introduced in Rails 2 have a gotcha</a>. This has been fixed</a> quickly by Josh Peek</a>.</li>
Fixed a bug where trying to :include for a belongs_to association inferred the foreign key incorrectly from the class name, rather than from the association name (changeset</a> contributed by Jonathan Viney</a>). Code is probably easier to understand:
class Post < ActiveRecord::Base
  belongs_to :main_category, :class_name => 'Category'
end
Post.find(:first, :include => :main_category)</p>
=> ActiveRecord::StatementInvalid: Mysql::Error: Unknown column</h1>
'posts.category' in 'on clause'</code></pre></p>
</li>
</ul>
Optimizations</h4>

JSON decoding is faster</a>. This helps if you're doing a lot of JSON decoding or deserialization (such as via ActiveRecord::Base#from_json</code></a>), or you are using the JSON format for ActiveResource</a>.</li>
has_many</code> associations are no longer loaded unnecessarily</a> in after_update</code> callbacks.</li>
</ul>
I can has feedback nao plz?</h3>
Please leave any suggestions for improvements you may have - about anything really: format, level of detail, what you'd like to see, whatever. Until next week...</p>


Why I love RSpec nested example groups
2007-12-30T13:16:49+00:00
Prior to the introduction of nested example groups</a> in RSpec</a>, I'd always felt that descriptions got a little unwieldy when trying to describe the different cases and disliked specifying the controller_name</code> repeatedly. For example (and these are real examples from real projects at work, with actual code removed for conciseness):</p>
describe 'POST HotelDealsController#create with a valid hotel deal' do
  controller_name :hotel_deals
before(:each) do
# ...
end</p>
it "should create and save a new hotel deal" do
# ...
end
end</p>
describe 'POST HotelDealsController#create with an invalid hotel deal' do
controller_name :hotel_deals</p>
before(:each) do
# ...
end</p>
it "should not perform any redirection" do
# ...
end
end</code></pre></p>
Nested example groups allow me to do this instead:</p>
describe SearchController do
  before(:each) do
    @search = mock_model(Search)
  end
describe "POST 'create'" do</p>
it "should render 'new' when creating an invalid search" do
  # ...
end

describe "with a valid search that has a location_id" do
  before(:each) do
    @search.stub!(:valid?).and_return(true)
    @search.stub!(:location_id).and_return(1)
  end

  it "should save a new search that has a location_id, location_code and location_name, and redirect to 'show'" do
    # ...
  end
end

describe "with a valid search that doesn't have a location_id" do
  before(:each) do
    @search.stub!(:valid?).and_return(true)
    @search.stub!(:location_id).and_return(nil)
  end

  it "should ask the Location model for possible locations if the search doesn't have a location_id" do
    # ...
  end
end
</code></pre>
end
end</code></pre></p>
What's the difference you say? Well, while it may sound trivial, I can do describe SearchController</code> only once and nest all examples for the different actions and scenarios inside without breaking it up into separate top-level example groups where I'd need to say controller_name :search</code> multiple times.</p>
Another (more important) benefit is I can progessively specify different scenarios</em> I want to test by nesting them and providing a before</code> block to setup mocks and stubs for that specific scenario</em>. Let's look at what I mean with some code. Over here, I'm specifying the create</code> action of my SearchController</code>:</p>

describe "POST 'create'" do
  it "should render 'new' when creating an invalid search" do
    # ...
  end
describe "with a valid search that has a location_id" do
# ...
end</p>
describe "with a valid search that doesn't have a location_id" do
# ...
end
end</code></pre></p>
There're 3 possible scenarios here: an invalid search, a valid search with a location_id, and a valid search without an location_id. I can write examples for invalid searches within the top-level example group itself (it "should render 'new' when creating an invalid search"</code>). Now, to test valid searches, I break out 2 nested example groups with their own before</code> block to setup mock searches, one which has a location_id, the other doesn't. What's the big deal? It just feels much more organized than the first, non-nested example where a top-level example group is created for each scenario.</p>
And I know it may not seem like much, and I don't think there's anything particularly wrong with non-nested examples - it's a matter of personal preference. Nesting allows me to write examples for controllers in a saner fashion where I can say confidently to myself that "all examples for XXX action go here". I'm a big believer in readable tests (if you're on the Rails Trac</a> much and have seen my reviews and patches you should know), so being able to write specs where I feel they belong makes me happier, and the examples read really nicely too.</p>
I guess what I'm really trying to say is this: when trying to add a new example to legacy specs (legacy being anything that was written more than 5 mins ago) I instantly know where to place it</strong> - gone are the days of going through different example groups looking for the right place to put my new specification (and often settling on just simply creating a new top-level example group). I like to think we've all been there.</p>
That said, I'm not saying that deeply nested examples are a good thing. When testing Rails controllers I find that you don't often have to go more than 3 deep to allow for all the possible scenarios. Any more would suggest that your controller is doing too much work.</p>


DRY in your functional and ActionMailer tests - Rails 2.0 a feature a day #7
2007-12-27T18:47:06+00:00
That's right, D</strong>on't R</strong>epeat Y</strong>ourself in your functional and ActionMailer tests. If you're a Test::Unit user, this will probably look familiar to you when writing Rails functional tests (for your controllers):</p>
class PostsControllerTest < Test::Unit::TestCase
  def setup
    @controller = PostsController.new
    @request    = ActionController::TestRequest.new
    @response   = ActionController::TestResponse.new
  end
def test_should_not_explode
# Invariably sexy test code.
end
end</code></pre></p>
You'd probably have noticed how setup</code> always</em> sets the @controller</code>, @request</code> and @response</code> instance variables in all your controller tests. In Rails 2.0, you can instead subclass ActionController::TestCase</code> (in turn a subclass of Test::Unit::TestCase</code>) in your test cases and avoid repeating the instance variable assignments.</p>
class PostsControllerTest < ActionController::TestCase
  # No need to define setup.
def test_should_not_explode
# Invariably sexy test code.
end
end</code></pre></p>
Isn't that much better?</p>
Watch out for a gotcha though, when you actually do need to define a setup</code> method (like when you need to setup several other things before your tests run), as Jeffrey Allan Hardy reports</a>. The issue has been resolved</a> on edge Rails. If you're not using edge Rails, you should remember to always call super</code> in your setup</code> method should you define one:</p>
class PostsControllerTest < ActionController::TestCase
  def setup
    super
    @user = users(:konata)
  end
def test_should_not_explode
# Invariably sexy test code.
end
end</code></pre></p>
A similar subclass of Test::Unit</code>, ActionMailer::TestCase</code> is available for your ActionMailer unit tests as well. That means you can replace this:</p>
class UserMailerTest < Test::Unit::TestCase
  include ActionMailer::Quoting
def setup
ActionMailer::Base.delivery_method = :test
ActionMailer::Base.perform_deliveries = true
ActionMailer::Base.deliveries = []</p>
@expected = TMail::Mail.new
@expected.set_content_type "text", "plain", { "charset" => "utf-8" }
@expected.mime_version = '1.0'
</code></pre>
end</p>
def test_signup
# Test code.
end
end</code></pre></p>
with this:</p>
class UserMailerTest < ActionMailer::TestCase
  def test_signup
    # Test code.
  end
end</code></pre>
For the geeks among you, check out the related changeset</a>.</p>
About the contributor, Michael Koziarski</h3>
Michael Koziarski</a>, better know as nzkoz, is a long-time Rails core</a> committer. Michael has done a signficant amount of work improving the performance of ActiveRecord for Rails 2.0 so we have him to thank for a good portion of the optimization work done on ActiveRecord. He also keeps a fairly new personal blog</a>.</p>


Generating migrations gets easier - Rails 2.0 a feature a day #6
2007-12-24T16:58:07+00:00
You may not have noticed this yet, but Rails 2.0 has a new convenient syntax for generating ActiveRecord migrations. Go ahead, run the migration generator with script/generate migration</code>. I'll wait.</p>
Yup, you can now specify the columns you want to add in your migration by passing attribute/type pairs to the migration generator. Ergo,</p>
script/generate migration AddMoreToAnime episodes:integer licensed:boolean</code></pre>
will generate a migration like so:</p>
class AddMoreToAnime < ActiveRecord::Migration
  def self.up
    add_column :animes, :episodes, :integer
    add_column :animes, :licensed, :boolean
  end
def self.down
remove_column :animes, :licensed
remove_column :animes, :episodes
end
end</code></pre></p>
This ties in pretty nicely with the syntax for the model generator (script/generate model</code>), which also accepts attribute pairs. Tiny change but "it's all about consistency".</p>
For the geeks among you, check out the related changeset</a> and ticket</a>.</p>
About the contributor, Pratik Naik</h3>
Pratik Naik</a> (WorkingWithRails profile</a>), probably better known as lifofifo or just lifo, is an active Rails contributor and can be found on #rails-contrib</a> and #rubyonrails</a> nearly 24/7. Almost everyone who's used Rails has used code that lifo has written. Oh, and lifo also won one of the monthly Rails Hackfests</a>.</p>
He also keeps a pretty good blog</a> where he posts mostly on Rails hacking and tips.</p>


Rails 2 a feature a day - update
2007-12-23T12:14:51+00:00
In case anyone is wondering about the pause in Rails 2.0 - a feature a day</a> posts, yes, I know, I've not been writing any posts for a week or so. I'll be posting more actively again from tomorrow - just taking a short break due to general lethargy these few days. And submitting patches</a> > blogging.</p>
On a somewhat related note, I'll be posting weekly updates of edge Rails changes in a tie-up with a particular Rails podcast from the beginning of next year - not gonna say which one!</p>


Rails 2.0.2 released, so what's new?
2007-12-17T11:09:13+00:00
Rails 2.0.2 was tagged not too long ago</a> and will hit the gem servers soon I expect. Being a minor point release there aren't many changes, but here're the ones I feel are worth mentioning:</p>
ActionPack changes</h3>
Configurable asset hosts</strong>: You can now pass a proc to ActionController::Base.asset_host</code>. This allows you to get by the hard-coded assumption that you have 4 asset hosts numbered 0-3 when using the '%d' wildcard (introduced in Rails 2.0.1).</p>
I contributed this patch</a> so I'm gonna be lazy and copy and paste most of the documentation I wrote for patch.</p>
The example proc below generates http://assets1.example.com and http://assets2.example.com randomly.</p>
ActionController::Base.asset_host = Proc.new { |source| "http://assets#{rand(2) + 1}.example.com" }
image_tag("rails.png")
  => <img src="http://assets2.example.com/images/rails.png" alt="Rails" />
stylesheet_include_tag("application")
  => <link href="http://assets1.example.com/stylesheets/application.css" media="screen" rel="stylesheet" type="text/css" />
</code></pre>
The proc also takes a single source</code> parameter which is the path of the source asset. This can be used to generate a particular asset host depending on the asset path. This is useful if you have, say, images hosted elsewhere, or you want an SEO-friendly URL for your images:</p>
ActionController::Base.asset_host = Proc.new { |source|
  if source.starts_with?('/images')
    "http://images.example.com"
  else
    "http://assets.example.com"
  end
}
image_tag("rails.png")
  => <img src="http://images.example.com/images/rails.png" alt="Rails" />
stylesheet_include_tag("application")
  => <link href="http://assets.example.com/stylesheets/application.css" media="screen" rel="stylesheet" type="text/css" /></code></pre>
Asset cache directories are automatically created</strong>: In Rails 2.0.1, if you tried to cache your assets (javascripts and stylesheets) in a subdirectory (example below), you either need to check it into your source control or have your deployment tool (Capistrano, etc.) create it for you. Josh Peek</a> contributed a patch</a> that created the subdirectory instead so you can do something like:</p>
javascript_include_tag(:all, :cache => "cache/money")</code></pre>
and not have to bother about creating the 'cache' subdirectory.</p>
Railties changes</h3>
Default database is now SQLite3</strong>: The default database is now SQLite3 instead of MySQL. Running 'rails takeover_the_world_app' will now come with a database.yml that's setup for SQLite3. To get the old behavior (where it's preconfigured for MySQL), run rails -d mysql takeover_the_world_app</code> instead. This is mostly to make this "just work" on Mac OS X Leopard, where SQLite3 is already installed with the OS.</p>
Template loading is faster</strong>: DHH has turned on ActionView::Base.cache_template_loading</code> by default in the production.rb</code> environment config file that basically means that Rails no longer does file system stat calls when loading templates. The downside is that you have to restart your Rails application to see templates changes in production mode, but it's not really that big an issue since no one should be editing templates anyway 'live' in a production application.</p>
New rake tasks for migrations</strong>: rake db:migrate:redo</code> to undo your last migration and re-run it - very useful when developing migrations (when you screw up, that is). rake db:migrate:reset</code> drops the database, re-creates it, and then runs all migrations.</p>
rake task for generating secret keys</strong>: rake secret</code> to generate a secure key that you can use for cookie sessions. This is useful for updating Rails applications from 1.x to 2.x, which uses cookie-based sessions by default and requires a secret key.</p>
config.action_controller.session = {
  :session_key => '_your_app_session',
  :secret      => 'some super long string that you can generate with the rake secret task'
}</code></pre>
Personally I just use super long quotes from Family Guy.</p>
That's it! For the curious, expect Ruby 1.9 compatibility, improved caching, and big ActionPack and rendering refactoring changes in Rails 2.1.</p>


Sensible GROUP BYs in ActiveRecord::Calculations - Rails 2.0 a feature a day #5
2007-12-16T15:16:12+00:00
Doing GROUP BYs in ActiveRecord has always been tricky. There's a lot of "magic" in ActiveRecord and room for untested edge cases. Thankfully, Rails also has a squadron of eagle-eyed contributors who are on hand to fix unforeseen errors.</p>
For example, if you wanted to do this:</p>
class Click < ActiveRecord::Base
  belongs_to :site  # site_id foreign key is a String, e.g. 'www.rubyonrails.org'
end
Now, try counting the number of clicks, grouped by site.</h1>
Click.count(:all, :group => :site)</p>
=> [[nil, 1], [nil, 3]]</h1>
</code></pre></p>
This is a surprisingly common thing to do especially when you are producing reports or statistics of any kind and unfortunately decided to go with a non-(auto)numeric foreign key. As you may have noticed, the sites were returned as nil</code> which is totally unhelpful. Thankfully, this has been fixed in Rails 2.0:</p>
Click.count(:all, :group => :site)
# => [[nil, 1], ['www.site, 3]]</code></pre>
GROUP BY and :foreign_key don't mix</h3>
This change is NOT in Rails 2.0.</strong></p>
If you wanted to do GROUP BYs in your ActiveRecord models (via the :group</code> option), you had to take note of one particular gotcha. For example, with an ActiveRecord model like this:</p>
class Anime < ActiveRecord::Base
  belongs_to :japanese_studio, :class_name => 'Studio', :foreign_key => 'studio_id'
end</code></pre>
Note that we specified the :foreign_key</code> option since it can't be inferred from the association name of 'japanese_studio'. If we wanted to count</code>ing the number of anime grouped by studio though, we're in big trouble:</p>
Anime.count(:all, :group => :japanese_studio)
# ActiveRecord fails and mumbles about an unknown "japanese_studio_id" key.
</code></pre>
Basically what happened is Rails did not use the specified foreign key column of 'studio_id', inferring it instead from the association name of 'japanese_studio'. This is not yet fixed but there's already a patch</a> ready for it at the Rails issue tracker</a>. In fact, I'm gonna verify it</a> right after posting this.</p>
About the contributor, Kamal Fariz</h3>
I thought it was time to cover Rails 2.0 contributions by someone closer to home ("home" being my home, Singapore</a>) so I singled out Kamal Fariz</a> (WorkingWithRails profile</a>), a Rails developer working in Malaysia for a Rails shop</a>. Kamal's also a former Rails Hackfest</a> winner (read the post-Rails Hackfest interview</a>). Kamal is also an active member of the Malaysia Ruby Brigade</a> (I guess it's not called a "Ruby User Group" since "RUG" sounds rather unglamorous).</p>
Wow look at the number of parentheses I used in the last paragraph. For no reason whatsoever here's a lolcats picture:</p>

</p>


ActiveRecord::Base.with_scope { :only => 'in your model' } - Rails 2.0 a feature a day #4
2007-12-16T13:44:34+00:00
Today's (un)feature covers the oft-abused and misunderstood with_scope</code> method. The excellent err.the_blog had a post on how you should be using with_scope</code></a> (yes, only use it in your ActiveRecord models, not</em> in your controllers or filters). Yes that blog post may have been written a long time back but it's still applicable to Rails 2.0.</p>
With Rails 2.0, the with_scope</code> method is now protected</code>, meaning that you can no longer use it in your controllers (unless you use the #send(:with_scope)</code>, or #send!(:with_scope)</code> in Ruby 1.9). I'm not even going to show you how you could use it in your controllers since you really shouldn't (unless you know what you are doing).</p>
Here's what with_scope</code> allows you to do:</p>
class SiteOwner < ActiveRecord::Base
Returns list of distinct active sites.</h1>
def active_sites(*args)
with_scope :find => { :select => 'DISTINCT(site)', :conditions => { :active => true } } do
find(*args).collect(&:site)
end
end
end</code></pre></p>
And even better example, stolen from the err.the_blog post</a> mentioned above, is re-using scopes:</p>
class Movie < ActiveRecord::Base
  def self.find_playing(*args)
    with_playing do
      find(*args)
    end
  end
def self.find_playing_by_id
with_playing do
find_by_id(*args)
end
end</p>
def self.with_playing
with_scope :find => { :conditions => [ state = ? AND visible = ?, NOW_PLAYING, true ] } do
yield
end
end
end</code></pre></p>
I tend to use that a lot combined with method_missing</code> magic (also from the err.the_blog post</a>) to allow me to do things like Movie.find_playing_by_name</code>:</p>
def self.method_missing(method, *args, &block)
  if method.to_s =~ /^find_(all_)?playing_by/
    with_playing do
      super(method.to_s.sub('playing_', ''), *args, &block)
    end
  else
    super(method, *args, &block)
  end
end</code></pre>
If you prefer to get these for free, check out the the Rails scope-out plugin</a> implements many of the ideas in the err.the_blog post.</p>
About the contributor, Josh Peek</h3>
Josh Peek</a> (WorkingWithRails profile</a>) was the man behind the "protection" of with_scope</a>. This is not Josh's greatest contribution to Rails, of course - Josh has been a very productive and active</a> Rails contributor since the very beginning. A winner of one of the monthly Rails Hackfest</a>, you can read up on the ever-elusive (I say "elusive" because he doesn't have a blog - it's just patch after patch after patch) Josh Peek in this post-Rails Hackfest interview</a>.</p>
Josh is also the man behind the deprecation and "plugin-izing" of dynamic scaffolding and pagination (yes, those are gone from Rails 2.0) among a great number of other patches and test coverage improvements. Right now, Josh appears to be working on refactoring ActionView</a>.</p>
Outro</h3>
Apologies for the late-on-arrival Rails 2.0 a feature a day</a> posts, but such is life. Feature #5</a> follows immediately after :)</p>


Concatenate your stylesheets and JavaScripts in 3 seconds - Rails 2.0 a feature a day #3
2007-12-12T23:25:39+00:00
I don't think I need to explain how concatenating your 5 stylesheets and 12 JavaScript files into single files</a> each makes your webpages load faster. Unless you're using multiple asset hosts (Rails 2 allows for multiple asset hosts</a>), then it becomes tricky to say for sure which method is better, but I digress.</p>
There're a bunch of really useful plugins that help you bundle your JS and CSS files, most of them offering minifying/packing of JS and stripping of comments and whitespace in CSS as well. I was a big fan (still love it) of Asset Packager</a>, but newer plugins like PackR</a> and Bundle-fu</a> work great too.</p>
With Rails 2.0 though, unless you want the minifying/packing/comment-stripping features, you can do away with installing a packager plugin. Remember your trusty javascript_include_tag</code> and stylesheet_link_tag</code>? They now accept a :cache</code> option:</p>
# :cache => true creates a cached javascript named all.js.
<%= javascript_include_tag :all, :cache => true %>
# This becomes:
# <script type="text/javascript" src="/javascripts/all.js"></script>
You can name your javascript too, by passing a name instead of true.</h1>
<%= javascript_include_tag 'jquery', 'swfobject', 'application', :cache => 'base' %></p>
This becomes:</h1>
<script type="text/javascript" src="/javascripts/base.js"></script></h1>
Same deal for stylesheets...</h1>
:cache => true creates a stylesheet named all.css.</h1>
<%= stylesheet_link_tag :all, :cache => true %></p>
This becomes:</h1>
<link href="/stylesheets/all.css"  media="screen" rel="Stylesheet" type="text/css" /></h1>
You can name your stylesheet like for javascript_include_tag.</h1>
<%= stylesheet_link_tag 'yui/reset-fonts-grids', 'application', :cache => 'styles' %></p>
This becomes:</h1>
<link href="/stylesheets/styles.css"  media="screen" rel="Stylesheet" type="text/css" /></h1>
</code></pre></p>
Of course, this only takes place if caching is turned on (ActionController::Base.perform_caching</code>), which is on by default in the production environment and off in the development environment.</p>
For those who want to look at some code, check out the changeset</a>.</p>
About the contributor, DHH</h3>
Well, DHH</a> hardly needs any mention. David has_one Wikipedia entry</a>. Nice little touch on this new feature though, I love the convenience.</p>
I promise, like I'd said before</a>, to cover contributions by someone less "mainstream" in the next Rails 2 "feature a day"</a> blog post.</p>


Rails 2.0 - a feature a day
2007-12-09T23:50:41+00:00
Now that Rails 2.0 has been baked to near-perfection, I'm sure all you Rubyists with Rails applications are considering updating or have already updated your applications to be Rails 2.0-compatible. And you've probably already pored through the massive list of new features and changes in Rails 2.0</a> or seen it on Ryan Daigle's Scraps</a>. Ryan also wrote a Rails2 mini eBook</a> that's been getting good</a> reviews</a>.</p>
I've been keeping track of the Rails Trac timeline</a> myself since my 1st committed Rails patch</a> mostly to keep track of Rails development (we</a> run several apps on edge) and to monitor any comments on my submitted patches. Turns out keeping an eye on the timeline and the rubyonrails-core mailing list</a> gives you a pretty decent "on the ground" view of new features and changes to the Rails trunk.</p>
So I'm gonna try something and see if helps anyone: I'll be running a near-daily series of blog posts about new Rails features or changes. I'll try not to repeat anything that's already been</a> mentioned</a>, and instead focus more on lesser-known changes. I think it's also a great opportunity to raise the profile of the core committers and contributors to the Rails community so look out for an "About the contributor" section in each post.</p>
Hop on over to the 1st post - Time#advance now uses :weeks, :hours, :minutes, :seconds options</a>.</p>


Rails 2.0 released
2007-12-08T00:02:09+00:00
Just go to the release announcement and major features blog post by DHH</a> already!</p>
If you're having trouble installing the Rails 2.0.1 gem, do a gem install rails -y --source http://gems.rubyonrails.org</code></p>
Now that the obligatory link to the Rails 2.0 release announcement is done, I'd like to urge anyone with any interest in improving Rails or seeing new features or fixes in Rails to try and contribute to Rails. I'm sure everyone of us Rails users have had "what if Rails could do this" or "why is Rails doing this, that's just wrong" moments. Well, roll up your sleeves and help by contributing instead of complaining about how "they"</a> won't/haven't/are too stupid to fix it..</p>
A good starting point is to read the Rails Trac wiki</a>, and after that be sure to check out John Susser's excellent guide to contributing to Rails</a> (read the presentation slides</a>, it won't take long). You should have enough information to start. I recommend just opening the base.rb</code> classes for ActiveRecord, ActionController and peeking around the ActiveSupport classes just to get a feel of things. After that crack open the relevant test for your issue and write your test-driven patch!</p>
It's really easy, since Rails is written purely in Ruby - if I can do it I'm sure you can too :) Your contribution doesn't even have to be a bona fide patch file with tests, documentation and bits of Ruby code - if you notice a bug and report it</a> not knowing how to fix it, that's good enough! Or even something as trivial as a new style (CSS and layout) for the Rails error pages (there isn't such a patch yet but I'd love to see prettier default exception pages instead of the current rather plain-looking ones).</p>
Anyway, that's enough of the sermon from me - enjoy your Rails 2.0! Congrats to the Rails Core team</a> and contributors on another solid release!</p>


Rails 2.0 - it's landed
2007-12-07T14:14:59+00:00
Update: Looks like it's going to be released as Rails 2.0.1 instead due to a bugfix</a> post-2.0 tagging.</ins></p>
Just a quick one - seems like Rails 2.0 has been tagged for release</a>. Rails 2.0 milestone</a> has just been completed.</p>
Expect a post on weblog.rubyonrails.com</a> soon.</p>


New in Rails: a request profiler for profiling your app
2007-10-26T10:01:30+00:00
Jeremy Kemper</a> (aka bitsweat) committed</a> a very useful tool into the Rails trunk not too long ago: a request profiler</a>! It's a human-friendly wrapper script around the ruby-prof library</a>, a nice ruby code profiler, that lets you run multiple requests against a URI in your application and get a detailed code profile report in text and HTML.</p>
Wanna try it out? Update your vendor/rails to at least revision 8016, run rake rails:update</code> to copy the new script/performance/request</code> script into your app's script</code> directory, install the ruby-prof gem (sudo gem install ruby-prof</code>), then let it loose on your app.</p>
The options are pretty simple, just pass the script the URI you wanna profile. There're options for specifying how many requests you want to process, and for profiling POST requests, there's one for

specifying a POST fixture file.</p>
USAGE: script/performance/request uri [options]
    -u, --uri [URI]                  Request URI. Defaults to http://localhost:3000/
    -n, --times [0000]               How many requests to process. Defaults to 1000.
    -b, --benchmark                  Benchmark instead of profiling
        --method [GET]               HTTP request method. Defaults to GET.
        --fixture [FILE]             Path to POST fixture file
        --open [CMD]                 Command to open profile results. Defaults to "open %s &"
    -h, --help                       Show this help</code></pre>
At the end of the run, you get a text and HTML report with the methods called and the time spent in them. If you haven't seen a code profile before, it looks something like this:</p>
</div>

</p>
Very nice stuff! It's extremely</em> convenient to have profiling like this built into Rails itself - personally I've not even run any profiling on my Rails code because it seemed like a hassle (though I do run httperf benchmarks and take note the number of requests per second). With code profiling, you can easily see which parts of your code are the bottlenecks and optimize away - it's a godsend that it's so easy to do it in Rails!</p>
Anyway, this is all still new stuff I imagine and subject to change (and improvements), but still very exciting for those of us who are hitting performance bottlenecks in our Rails apps (and are not already doing code profiling).</p>


Konata Izumi in Edge Rails
2007-10-15T16:25:50+00:00
You wouldn't think that Konata Izumi</a> (a character from the anime, Lucky Star</a>) and Ruby on Rails (a web MVC framework) would somehow be associated, but they are!</p>
I took the opportunity to fill in the missing ActiveRecord::Base#to_json</code> documentation</a> with examples using Konata Izumi and it got committed unchanged in revision 7905</a>. Cute. I hope no one changes them.</p>
Update: Managed to get more Konata Izumi documentation</a> into Rails ;)</ins></p>


New on edge Rails: JSON serialization of ActiveRecord objects reaches maturity
2007-10-10T00:13:02+00:00
The last time I wrote about ActiveRecord#to_json</code> on edge Rails</a>, it was missing some key functionality. For one, you couldn't include any associations. Another thing was you couldn't do something like this in your controller:</p>
@authors = Author.find(:all)
render :json => @authors.to_json(:only => :name)</code></pre></p>
Oh and did I mention it wasn't emitting valid JSON by default</a>?</p>
In the last few weeks, several patches to the Rails trunk have fixed all these issues (most of these patches are already on the Rails 2.0 Preview Release</a>). JSON serialization of ActiveRecord objects is finally</em> on par with XML serialization, and that old Jsonifier plugin</a> I wrote can finally be sent off to the plugin retirement home (though, I am thinking of porting all the JSON patches into Jsonifier to add Rails 2.0-like JSON serialization to Rails 1.2.4, but who knows, I am</em> lazy).</p>
Anyway, back to the new JSON stuff on edge Rails.</p>
No more invalid JSON from Rails</h3>
Yes it's true. No more changing of module attribute to get Rails to produce valid JSON</a>. Thanks to Choon Keat</a> with his detailed SVN history snooping</a>, we finally managed to get a patch to fix JSON encoding to quote all hash keys</a> into Rails</a>.</p>
:include option can be used to include associations with ActiveRecord::Base#to_json</h3>
At DHH's urging</a>, I submitted a patch that added the :include</code> option to ActiveRecord#to_json</code></a>. Of course, it was a sloppy first submission and DHH pointed that out</a> - a little bit of DRY love and it was really great to see it get committed</a> (I have a soft spot for JSON serialization from Rails, since I'd been trying to achieve the same thing with Jsonifier</a>). </p>
So yes, now you can do:</p>
json = @david.to_json(:include => :posts)
# or even...
json = @david.to_json(
  :include => {
    :posts => {
      :include => {
        :taggings => {
          :include => {
            :tag => { :only => :name }
          }
        }
      }
    }
})</code></pre>
Enumerable#to_json and Hash#to_json now accept options</h3>
One problem with Jsonifier that I often get emails about is how the to_json</code> options don't work for lists (Enumerables). And why is this important? Well, we often retrieve collections of ActiveRecord objects at a time with AR::B#find</code> so it's not too much to ask to be able to do this in your controller actions:</p>
@authors = Author.find(:all)
render :json => @authors.to_json(:only => :name)</code></pre></p>
But of course you couldn't, so I patched away</a> by changing the to_json</code> methods of Enumerable and Hash (and other types as well) to accept an optional options</code> argument. Enumerables will pass on any options</code> it receives to its elements. Hashes will respect :only and :except (as well as passing on the options</code> to its elements).</p>
Unambiguous (non-US-centric) dates and times</h3>
While Rails 1.2.3 (and 1.2.4) never supported encoding of Dates, Times and DateTimes, edge Rails has been happily supporting Date, Time and DateTime conversions to JSON since revision 6673</a>. Unfortunately, the date string format is in MM/DD/YYYY format:</p>
Time.now.to_json
=> "\"09/21/2007 12:15:02 UTC\""</code></pre>
Geoff Buesing suggested that Rails should change this</a> to the more unambiguous YYYY/MM/DD format. Finding the right date format is important not only for readability reasons, it's also important that the date string is directly parsable by the many browser JavaScript implementations using the JavaScript new Date(dateString)</code> function. There is no formal spec of how dates should be represented in JSON, but it's most convenient that strings representing dates can be directly converted into JavaScript Date objects.</p>
Testing in several browsers and on different platforms, albeit not extensively, we settled on the %Y/%m/%d %H:%M:%S %z</code> (strftime) format (more details in the comments of the Trac ticket</a>).</p>
Now it is:</p>
Time.now.to_json
=> "\"2007/09/21 12:15:02 +0800\""</code></pre>
Much better.</p>
What's left?</h3>
Documentation, for one thing. ActiveRecord::Base#to_json is still undocumented (docfix patch</a>). The to_json</code> methods for Enumerable and Hash need documentation as well (will patch that soon).</p>
ActiveRecord::Base#to_json</code> also doesn't deal with binary attributes, which can be easily resolved by Base64-encoding them (patch coming soon, it gets slightly complicated when trying to do a from_json</code>). And of course, optimization improvements are always nice (decoding from JSON especially).</p>
So, if you use JSON at all, please come in and help patch the remaining bits before Rails 2.0 rolls out. If you can't (or more realistically, don't have the time to) patch Rails yourself, do help out by verifying patches :).</p>


So apparently I'm a Rails Hackfest winner...
2007-10-03T02:19:29+00:00
Got an email not too long ago from Working With Rails</a> (my profile</a>) entitled "WWR September Hackfest Winner - Congrats!", and almost deleted it thinking it was spam. I read it in the end (after all, how often do you see spam with "Rails" in the subject title), and turns out that my</a> recent</a> patches</a> to Rails pushed me up to 6th position in the September Rails contributors rankings</a>.</p>
</div>

</p>
I vaguely remember seeing Rails Hackfest</a> mentioned somewhere but only just realized it's a "contest" run monthly. The winners are the top 10 contributors to Rails (contribution being determined by the number of accepted patches, docfixes, and even comments). That's really nice of the sponsors and Working With Rails</a>, since that wasn't really what I'd expected in return for contributing to an Open Source project (that would be a sense of satisfaction</em>, personally-speaking).</p>
I'm just really glad that the JSON patches went into Rails before Rails 2.0 and it is satisfying to see my code get into Rails (I'll blog about the patches in a separate post). There's still some more work</a> needed though - please help to verify and give suggestions or +1s ;).</p>


New in Edge Rails: helper for creating form labels
2007-09-25T10:40:55+00:00
Edge Rails now comes with a helper for creating form labels</a>, so in your views, instead of doing this:</p>
<% form_for(:user, @user, :url => user_path(@user)) do |f| -%>
<label for="user_login">Login</label></strong>
<%= f.text_field :login %>
<end></code></pre>
where the <label></code> is given a for</code> attribute of user_login</code> (since the convention for form input ids is {MODEL_NAME}_{ATTRIBUTE_NAME}</code>), you can instead now do:</p>
<%= label(:user, :login) %></code></pre>
Quite a bit neater. Makes it easier to explain to beginners how they should use <label></code>s appropriately since the syntax is similar to the other form helpers. Now give your <label></code>s proper for</code> attributes if you're not doing so already.</p>
This makes plugins like this form label helper plugin</a> obsolete.</p>


New in Edge Rails: Serialize ActiveRecord objects to JSON with ActiveRecord#to_json
2007-09-24T10:14:12+00:00
Converting ActiveRecord instances to their JSON representation has always been a topic that has been dear to me. I'd tried to get a patch that adds to_json</code> to ActiveRecord</a> into Rails (but the quality of my patch was lacking in a few respects). The Jsonifier plugin</a> that I wrote tried to address the lack of built-in JSON serialization by adding a ActiveRecord#to_json</code> method that acts much like ActiveRecord#to_xml</code>.</p>
So it is with mixed feelings when I discovered a couple of days ago when DHH</acronym></a> committed a changeset that added a native ActiveRecord#to_json</code> method</a>. Of course, I'm elated that JSON serialization is given first class attention now, since the raison d'être of Jsonifier and my Rails patch was to do just that. A little bit of me is selfishly disappointed since it means that Jsonifier has become quite obsolete!</p>
But it is an excellent change, I look forward to patching it up (if DHH doesn't beat me to it - there've been so much activity on the Rails trunk recently) so that the JSON serializer</a> supports an :include</code> options for including associations much like for ActiveRecord#to_xml</code> and Jsonifier's mixed in to_json</code>.</p>
Update: I've submitted a patch for adding :include</code> to ActiveRecord#to_json</code></a>. Please test it and give feedback or +1 ;).</ins></p>


ActiveRecord database :default "gotcha"
2007-09-19T21:37:21+00:00
Note to self:</p>
When a table column has a default value, such as for the type_category</code> column/attribute like so:</p>
t.string :type_category, :limit => 20, :nil => false, :default => 'tv'</code></pre>
a new instance of your ActiveRecord model will try and set the defaults from the database. Meaning:</p>
Anime.new => #<Anime id: nil, type_category: "tv"...</code></pre>
Courtesy of this in ActiveRecord::Base:</p>
def attributes_from_column_definition
  self.class.columns.inject({}) do |attributes, column|
    attributes[column.name] = column.default</strong> unless column.name == self.class.primary_key
    attributes
  end
end</code></pre>
So, don't get confused when your model validations (validates_presence_of :type_category</code>) don't seem to work when testing:</p>
it "should require a type_category" do
  @foo.attributes = valid_foo_attributes.except(:type_category)
  @foo.should have(1).error_on(:type_category)  # doesn't work since @foo.type_category = 'tv'
end</code></pre>
Explicitly set it to nil or a blank value.</p>
Sounds silly, but it's a true story.</p>


ActiveRecord attribute-related improvements on Edge Rails
2007-08-14T17:54:16+00:00
I just noticed a very fresh changeset committed into the Rails trunk that's pretty damn cool: changeset 7315</a>. Michael Koziarski (aka nzkoz") has refactored ActiveRecord's attribute-related methods that, among other things:</p>

caches typecasted attribute values</strong> in hashes. This avoids expensive typecasting (such as for Time-related attributes) which means access to these fields is significantly faster!</li>
moves generation of attribute methods to the class</strong>, instead of the instance.</li>
generates attribute reader and</em> writer methods (before, only reader methods were generated and writer methods relied on method_missing</code> magic).</li>
</ul>
The Ruby on Rails: Core Google Group thread on this patch</a> has more info on the changes and some of the rationale behind them.</p>
Here's a simple (read: totally unscientific) benchmark I ran to access a DateTime attribute 10000 times (I ran it that many times to reduce the effect of the City.find</code> call) with pre-revision 7315 edge Rails (I was using revision 7314):</p>
>> Benchmark.bmbm do |x| 
?>   x.report('test') { c = City.find(:first); 10000.times { c.created_at } }
>> end
Rehearsal ----------------------------------------
test   1.500000   0.010000   1.510000 (  1.568782)
------------------------------- total: 1.510000sec
       user     system      total        real
</code></pre>
test   1.500000   0.010000   1.510000 (  1.592264</strong>)</code></pre></p>
Post changeset 7315:</p>
>> Benchmark.bmbm do |x| 
?>   x.report('test') { c = City.find(:first); 10000.times { c.created_at } }
>> end
Rehearsal ----------------------------------------
test   0.100000   0.010000   0.110000 (  0.129514)
------------------------------- total: 0.110000sec
       user     system      total        real
</code></pre>
test   0.000000   0.000000   0.000000 (  0.009831</strong>)</code></pre></p>
Quite a bit faster!</p>


How to install Rails, the wrong way
2007-07-30T17:34:25+00:00
I've always thought the Rails installation instructions</a> on the official Rails website were pretty straightforward, so I couldn't help laughing when I saw this chat transcript a friend copied and pasted for me:</p>
[5:23:05 PM] X says: try so many times finally can le

[5:23:23 PM] X says: it is not about the version or wat

[5:23:46 PM] Y says: then what is the error?

[5:24:22 PM] X says: the gem install rails--include-dependencies

[5:24:37 PM] X says: between rails and --include got spacing</strong></p></blockquote>
I know it's mean to laugh but I'm not a carebear! I think it took him a day to install it despite having installed and uninstalled it for 2 whole months (don't ask me why, but his environment kept getting borked).</p>


God and your web server
2007-07-18T23:43:38+00:00
God</a> is a new process monitoring Ruby framework with a rather apt name (no, it's not that</em> God</a>). The config files looks something like that:</p>
God.meddle do |god|
  god.watch do |w|
    ...
  end
end</code></pre>
Interesting code to write. And feels safe too to have God watching over your mongrels. Oh and you can use it to clean up stale mongrel PID files without patching mongrel_rails</a>. Right now I use monit</a> a lot and it's really rather unDRY to have repeated configs for each mongrel on the server (is there a better way of doing this in monit?). God would be able to DRY it up.</p>


logrotate and mongrel (mongrel_cluster)
2007-07-16T13:45:21+00:00
I've never actually explored log rotation tools in Linux and merely knew of the existence of logrotate</a> and left it at that until log sizes really became a problem. Turns out logrotate is amazingly easy to configure, and thanks to this Logrotate and Mongrel blog post by Corey Donohoe</a> I have it setup for my Rails applications that are running on Mongrel</a>. Here's what my /etc/logrotate.d/mongrel_cluster</code> looks like:</p>
/var/railsapps/APP_NAME/shared/log/production.log {
  daily
  rotate 28
  missingok
  compress
  sharedscripts
  postrotate
    for i in `ls /var/railsapps/APP_NAME/shared/log/*.pid`; do
      kill -USR2 `cat $i`
    done
  endscript
}</code></pre>


Better JSON output from Rails with the Jsonifier plugin
2007-07-11T12:46:38+00:00
Update: Edge Rails now does whatever Jsonifier does (and more). Check out my blog post on JSON serialization maturity in edge Rails</a>. This means that this plugin is virtually obsolete if you're using edge Rails.</ins></p>
If you've tried to output JSON from your Rails applications before, you'd probably have noticed how inadequate it all seems. Let's look at the kind of output (pretty-printed for easier reading) you get from calling to_json</code> on your typical User model:</p>
{
  attributes: {
    id: 1,
    name: "Konata",
    awesome: true,
    created_at: "07/01/2007"
  }
}</code></pre>
Some of the common problems developers who write applications that speak JSON have with this are:</p>

The attributes</code> part is often unnecessary cruft when consuming ActiveRecord objects as JSON.</li>
There's no obvious way to control which attributes are shown in the JSON (e.g. you may want to hide private or lengthy attributes). The way to workaround this is either to write your own to_json</code> instance method for your ActiveRecord model, or to use a Rails plugin (like acts_as_json</a>) or a gem</a>.</li>
Including 2nd (or higher order) associations is tricky (as above, you can achieve this by defining your own to_json</code> instance methods).</li>
</ul>
Under the hood of the current ActiveRecord#to_json</h3>
The to_json</code> method for ActiveRecord objects falls back on using that defined in ActiveSupport's JSON classes</a>. The way it's currently done, there are a bunch of JSON encoder classes defined for various types - when you call to_json</code> on an ActiveRecord object it simply uses Object#to_json</code></a>.</p>
By the way, see that created_at: "07/01/2007"</code> bit in the example above which is the JSON output for a Date attribute? That's in MM/DD/YYYY format. Yup, 1st July 2007 not 7th January 2007 you "rest of the world you". Ouch, but at least you can use JavaScript's Date.parse()</code> on it directly as detailed in this patch</a>. And before you ask, yes, Date.parse()</code> doesn't understand the YYYY-MM-DD format.</p>
Can has Rails patch?</h3>
So about 2 days ago, I wrote a Rails patch to boost ActiveRecord#to_json with an options hash</a>. Yep much like what you can do with ActiveRecord#to_xml</code></a>.</p>
I hope it gets committed into the core some day. I mean, gosh, isn't Rails all about Web 2.0 mashups. It even has that fancy render :json</code> thing. I do believe JSON output needs to be treated more seriously in Rails rather than the half-hearted attempt at JSON encoding. No? Well, if the patch doesn't get accepted I'll still have my plugin</a> (see below</a>).</p>
Anyway, let's see some examples:</p>
Some examples, see?</h3>
Assuming User and Post models where User has_many Posts:</p>
david = User.find(1)
david.to_json  # {id: 1, name: "David", awesome: true, created_at: "07/01/2007"}
</code></pre>
No more attributes</code> cruft!</p>
:only</code> and :except</code> work the same way that as for ActiveRecord#to_xml</code>:</p>
david.to_json(:only => :name)                 # {name: "David"}
david.to_json(:only => [:id, :name])          # {id: 1, name: "David"}
david.to_json(:except => :created_at)         # {id: 1, name: "David", awesome: true}
david.to_json(:except => [:id, :created_at])  # {name: "David", awesome: true}</code></pre>
You can use the :methods</code> options as well to include any methods on the object.</p>
david.to_json(:methods => :permalink)
  # {id: 1, name: "David", awesome: true, created_at: "07/01/2007", permalink => "1-David"}
david.to_json(:methods => [:permalink, :interestingness])
  # {id: 1, name: "David", awesome: true, created_at: "07/01/2007", \
  #   permalink => "1-David", :interestingness => 666}</code></pre>
The :include</code> option lets you include associations.</p>
david.to_json(:include => :posts)
  # {id: 1, name: "David", awesome: true, created_at: "07/01/2007", \
  #    posts: [{id: 1, author_id: 1, title: "Welcome to the weblog"}, \
  #            {id: 2, author_id: 1, title: "So I was thinking"}]}</code></pre>
:only</code>, :except</code>, and :methods</code> works on the included associations as well:</p>
david.to_json(:include => { :posts => { :only => :title } })
  # {id: 1, name: "David", awesome: true, created_at: "07/01/2007", \
  #    posts: [{title: "Welcome to the weblog"}, \
  #            {title: "So I was thinking"}]}</code></pre>
Of course, 2nd level (and higher order) associations work too:</p>
david.to_json(:include => { :posts => { \
                              :include => { :comments => { \
                                              :only => :body } }, \
                              :only => :title } })
  # {id: 1, name: "David", awesome: true, created_at: "07/01/2007", \
  #    posts: [{comments: [{body: "1st post!"}, {body: "OMGWTFBBQ!"}], \
  #             title: "Welcome to the weblog"}, \
  #            {comments: [{body: "Don't think too hard"}], \
  #             title: "So I was thinking"}]}</code></pre>
Please do give any feedback at the Rails patch for ActiveRecord#to_json</a> or here. I wanna know what you feel about adding this functionality into the Rails core!</p>
Jsonifier plugin</h3>
I've rolled the patch into a plugin: Jsonifier. The Jsonifier Trac</a> is at http://trac.codefront.net/jsonifier/</a>.</p>
Git repository:</p>
git://github.com/chuyeow/jsonifier.git</code></pre>
Github project page:</p>
http://github.com/chuyeow/jsonifier/</code></pre>
To install the plugin:</p>
ruby script/plugin install git://github.com/chuyeow/jsonifier.git</code</code></pre>
 or git clone</code> the repository manually into the vendor/plugins</code> directory.</p>
A note on valid JSON</h3>
The JSON Rails spits out by default is not strictly valid JSON since the JSON specifications</a> require keys to be double quoted. To get strictly valid JSON, add</p>
ActiveSupport::JSON.unquote_hash_key_identifiers = false</code></pre>
in your environment.rb (or in the Rails initializers directory if you're on edge). See my blog post on how to get strictly valid JSON from Rails</a> for more info.</p>


How to get strictly valid JSON from Rails
2007-06-20T11:47:59+00:00
Update: Edge Rails (and the forthcoming Rails 2.0) will emit only valid JSON. Read JSON serialization of ActiveRecord objects reaches maturity for more details</a>.</ins></p>
If you've worked with JSON</a> long enough in Rails, you'd probably have noticed that the JSON the convenient Object#to_json</a> method spits out is not strictly JSON-compliant (according to the RFC 4627</a>, which states that object keys should be "strings", and "strings" should be double-quoted). Here's an example of what to_json</code> produces when called on an ActiveRecord instance:</p>
{
  id: 6589,
  code: "SIN",
  name: "Singapore",
  type: "City"
}</code></pre>
Notice how the keys (id, code, name, type) are not surrounded with double quotes. While this is generally not a problem if working purely in Rails, since Prototype and Rails itself can decode JSON like this, you'd run into problems with more finicky JSON parsers and decoders. PHP's json_decode</a> is a perfect example - it demands that the object keys be double-quoted (or it fails to decode your JSON, silently returning NULL).</p>
For a while I couldn't figure out why Rails was doing it and Google was of no help</a>. I decided to look at the Rails code since this can't be a huge oversight on the Rails community, can it? Sure enough, I found the "solution" in the encoding portion of the ActiveSupport::JSON</a> module:</p>

  # When +true+, Hash#to_json will omit quoting string or symbol keys
  # if the keys are valid JavaScript identifiers.  Note that this is
  # technically improper JSON (all object keys must be quoted), so if
  # you need strict JSON compliance, set this option to +false+.
  mattr_accessor :unquote_hash_key_identifiers
  @@unquote_hash_key_identifiers = true</code></pre>
Doh! All that's left to do is to put ActiveSupport::JSON.unquote_hash_key_identifiers = false</code> in your environment.rb</code> (or in the Rails initializers directory if you're on edge) and your Rails app will start producing strictly valid JSON (and is friendlier to other non-Rails applications):</p>
{
  "id": 6589,
  "code": "SIN",
  "name": "Singapore",
  "type": "City"
}</code></pre>
unquote_hash_key_identifiers</code> was added in changeset 5486</a>.</p>


Nginx, PHP and a PHP FastCGI daemon init script
2007-06-11T21:18:32+00:00
One of the things us ex-Apache httpd or ex-Lighttpd users have to get used to when installing nginx</a> is how there isn't built-in FastCGI support for process spawning. While these means nginx is more lightweight and faster, it does mean that you have to manage your FastCGI processes yourself.</p>
Having just upgraded to Ubuntu Feisty Fawn, I set to installing nginx and tried to get WordPress (which needs PHP, of course) running on it. Thanks to the new nginx package in the Feisty universe repository, getting nginx up and PHP (CGI version) and running is really straightforward. There're lots</a> of tutorials</a> to help you out as well.</p>
So that's that. The part that bugged me though, was how the tutorials always provided a script to start your PHP FastCGI processes, but never provided a way to ensure your FastCGI processes started up on a reboot (i.e. an init script). Once again, Google doesn't disappoint, turning up this php-cgi init script</a>. Tweak the init script a little, put it in /etc/init.d/php-fastcgi, sudo chmod +x /etc/init.d/php-fastcgi</code>, run sudo update-rc.d php-fastcgi defaults</code> and place the configuration for the script in /etc/default/php-fastcgi, and you're done. You now have a PHP FastCGI init script that spawns and kills your PHP FastCGI processes.</p>
Note:</strong> Lighttpd does come with a spawn-fcgi</code> binary that does the same, but I'm having trouble finding a suitable init script for spawn-fcgi (only the Gentoo emerge seems to have the init script). Still, this script works and I didn't really want to install lightty on my starving VPS</acronym>.</p>
</span>
The init script: /etc/init.d/php-fastcgi</strong></p>
#! /bin/sh
### BEGIN INIT INFO
# Provides:          php-fastcgi
# Required-Start:    $all
# Required-Stop:     $all
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Start and stop php-cgi in external FASTCGI mode
# Description:       Start and stop php-cgi in external FASTCGI mode
### END INIT INFO
Author: Kurt Zankl <[EMAIL PROTECTED]></h1>
Do NOT "set -e"</h1>
PATH=/sbin:/usr/sbin:/bin:/usr/bin
DESC="php-cgi in external FASTCGI mode"
NAME=php-fastcgi
DAEMON=/usr/bin/php-cgi
PIDFILE=/var/run/$NAME.pid
SCRIPTNAME=/etc/init.d/$NAME
PHP_CONFIG_FILE=/etc/php5/cgi/php.ini</p>
Exit if the package is not installed</h1>
[ -x "$DAEMON" ] || exit 0</p>
Read configuration variable file if it is present</h1>
[ -r /etc/default/$NAME ] && . /etc/default/$NAME</p>
Load the VERBOSE setting and other rcS variables</h1>
. /lib/init/vars.sh</p>
Define LSB log_* functions.</h1>
Depend on lsb-base (>= 3.0-6) to ensure that this file is present.</h1>
. /lib/lsb/init-functions</p>
If the daemon is not enabled, give the user a warning and then exit,</h1>
unless we are stopping the daemon</h1>
if [ "$START" != "yes" -a "$1" != "stop" ]; then
log_warning_msg "To enable $NAME, edit /etc/default/$NAME and set START=yes"
exit 0
fi</p>
Process configuration</h1>
export PHP_FCGI_CHILDREN PHP_FCGI_MAX_REQUESTS
DAEMON_ARGS="-q -b $FCGI_HOST:$FCGI_PORT -c $PHP_CONFIG_FILE"</p>
do_start()
{
# Return
#   0 if daemon has been started
#   1 if daemon was already running
#   2 if daemon could not be started
start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON --test > /dev/null 

|| return 1
start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON 

--background --make-pidfile --chuid $EXEC_AS_USER --startas $DAEMON -- 

$DAEMON_ARGS 

|| return 2
}</p>
do_stop()
{
# Return
#   0 if daemon has been stopped
#   1 if daemon was already stopped
#   2 if daemon could not be stopped
#   other if a failure occurred
start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --pidfile $PIDFILE > /dev/null # --name $DAEMON
RETVAL="$?"
[ "$RETVAL" = 2 ] && return 2
# Wait for children to finish too if this is a daemon that forks
# and if the daemon is only ever run from this initscript.
# If the above conditions are not satisfied then add some other code
# that waits for the process to drop all resources that could be
# needed by services started subsequently.  A last resort is to
# sleep for some time.
start-stop-daemon --stop --quiet --oknodo --retry=0/30/KILL/5 --exec $DAEMON
[ "$?" = 2 ] && return 2
# Many daemons don't delete their pidfiles when they exit.
rm -f $PIDFILE
return "$RETVAL"
}
case "$1" in
start)
[ "$VERBOSE" != no ] && log_daemon_msg "Starting $DESC" "$NAME"
do_start
case "$?" in
0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
esac
;;
stop)
[ "$VERBOSE" != no ] && log_daemon_msg "Stopping $DESC" "$NAME"
do_stop
case "$?" in
0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
esac
;;
restart|force-reload)
log_daemon_msg "Restarting $DESC" "$NAME"
do_stop
case "$?" in
0|1)
do_start
case "$?" in
0) log_end_msg 0 ;;
1) log_end_msg 1 ;; # Old process is still running
*) log_end_msg 1 ;; # Failed to start
esac
;;
*)
# Failed to stop
log_end_msg 1
;;
esac
;;
*)
echo "Usage: $SCRIPTNAME {start|stop|restart|force-reload}" >&2
exit 3
;;
esac</code></pre></p>
Config file for init script (the init script looks for this): /etc/default/php-fastcgi</strong></p>
START=yes
Which user runs PHP? (default: www-data)</h1>
EXEC_AS_USER=www-data</p>
Host and TCP port for FASTCGI-Listener (default: localhost:9000)</h1>
FCGI_HOST=localhost
FCGI_PORT=9000</p>
Environment variables, which are processed by PHP</h1>
PHP_FCGI_CHILDREN=4
PHP_FCGI_MAX_REQUESTS=1000</code></pre></p>
nginx config file: /etc/nginx/nginx.conf</strong></p>
location ~ \.php$ {
  fastcgi_pass   127.0.0.1:9000;
  fastcgi_index  index.php;
  fastcgi_param  SCRIPT_FILENAME  /var/www/chuyeow.wtf$fastcgi_script_name;
  include        /etc/nginx/fastcgi.conf;
}</code></pre>
My fastcgi.conf file (I'm not sure I need everything here...)</strong></p>
fastcgi_param  QUERY_STRING       $query_string;
fastcgi_param  REQUEST_METHOD     $request_method;
fastcgi_param  CONTENT_TYPE       $content_type;
fastcgi_param  CONTENT_LENGTH     $content_length;
fastcgi_param  SCRIPT_NAME        $fastcgi_script_name;
fastcgi_param  REQUEST_URI        $request_uri;
fastcgi_param  DOCUMENT_URI       $document_uri;
fastcgi_param  DOCUMENT_ROOT      $document_root;
fastcgi_param  SERVER_PROTOCOL    $server_protocol;</p>
fastcgi_param  GATEWAY_INTERFACE  CGI/1.1;
fastcgi_param  SERVER_SOFTWARE    nginx;</p>
fastcgi_param  REMOTE_ADDR        $remote_addr;
fastcgi_param  REMOTE_PORT        $remote_port;
fastcgi_param  SERVER_ADDR        $server_addr;
fastcgi_param  SERVER_PORT        $server_port;
fastcgi_param  SERVER_NAME        $server_name;</p>
PHP only, required if PHP was built with --enable-force-cgi-redirect</h1>
fastcgi_param  REDIRECT_STATUS    200;</code></pre></p>


'Mac vs PC commercials'.gsub(/Mac/, 'Rails').gsub!(/PC/, 'Java')
2007-05-15T00:22:19+00:00
The Rails Envy</a> guys have come up with a spoof of the Mac versus PC commercials</a>. Yes, it's Rails vs Java. Go watch it</a> or catch it straight on YouTube</a>.</p>


Sexy migrations on Edge Rails
2007-05-07T00:02:57+00:00
So it seems DHH</a> was inspired by the Sexy Migrations plugin</a> (which in turn was inspired by Hobo</a>) and committed changeset 6667</a>.</p>
Now, you can do this:</p>

create_table :products do |t| 
  t.integer :shop_id, :creator_id 
  t.string  :name, :value, :default => "Untitled"
  t.timestamps
end</code></pre>
Succinct!</p>


If you're having problems with script/console on edge Rails...
2007-04-11T10:27:56+00:00
If you're on edge Rails and are having problems starting script/console, it may be caused by spaces in your Rails working directory (see ticket 7955: Console environment load broken when RAILS_ROOT contains spaces</a>). Basically the lack of quoting on RAILS_ROOT causes console.rb to pass incorrect paths to IRB (it gets split on the spaces in your directory path).</p>
Just in case anyone runs into this problem and doesn't want to start debugging the problem like I did. Changeset 6512</a> fixes things. If you do update Rails to revision 6512 (or higher) though, be aware of changest 6507</a>. Ahh the joys of living on the edge.</p>

/opt/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `gem_original_require': no such file to load -- /Data/Working (LoadError)
        from /opt/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `require'
        from /opt/local/lib/ruby/1.8/irb/init.rb:252:in `load_modules'
        from /opt/local/lib/ruby/1.8/irb/init.rb:250:in `each'
        from /opt/local/lib/ruby/1.8/irb/init.rb:250:in `load_modules'
        from /opt/local/lib/ruby/1.8/irb/init.rb:21:in `setup'
        from /opt/local/lib/ruby/1.8/irb.rb:54:in `start'
        from /opt/local/bin/irb:13</code></pre>


Get your Rails tests results via Growl notifications
2007-04-01T14:25:05+00:00
I've been using Autotest (part of the ZenTest</a> package) while testing my Rails applications and never thought of asking for more. After all, getting my tests (well, specs</a> actually) run automatically whenever I make a relevant change and</em> having diff</code>-level granularity on which tests Autotest re-runs is pretty damn useful enough. That is, until I came across this RSpec and Autotest with Growl notifications blog entry</a> (on JavaBlogs</a>, no less!)</p>
How're these for red</span>/green</span> test results?</p>
Tests (specs) passing!</strong></p>
</div>

</p>
Tests (specs) failing :(</strong></p>
</div>

</p>
Much better! Now I don't have to glance at my terminal window (I recently realized how painful it is while coding with a single monitor) and get unobtrusive notifications.</p>
Unfortunately, this is Mac-only (or wherever Growl</a> is supported). I had to follow links to several blog entries to get it setup nicely (see Growl + Autotest Rails with Zentest 3.4.0</a> and Green goodness with autotest + growl</a> - those are my references).</p>
Basically you need Growl</a> installed, and the growlnotify</code></a> tool in your path. growlnotify</code> can be found in the Extras/growlnotify</code> directory in the Growl dmg (for example, after you've mounted the Growl-0.x.x.dmg, you can find it here: /Volumes/Growl/Extras/growlnotify</code>). Just copy the growlnotify</code> executable into your path (I copied it into /opt/local/bin</code> since I'm using Darwin Ports and don't have a /usr/local/bin</code> directory). Verify it's running by entering:</p>
growlnotify -m "Testing growlnotify" Boo Ya!</code></pre>
into a terminal window. You should see a Growl notification.</p>
Now, you need to create an Autotest hook by creating an autotest init file in your home directory named .autotest</code>, and copy this chunk of text in:</p>

module Autotest::Growl
  def self.growl title, msg, img, pri=0, sticky="" 
    system "growlnotify -n autotest --image #{img} -p #{pri} -m #{msg.inspect} #{title} #{sticky}" 
  end
Autotest.add_hook :ran_command do |at|
output = at.results.last.slice(/(\d+)\s.*specifications?,\s(\d+)\s.*failures?/)
if output =~ /[1-9]\sfailures?/
growl "Test Results", "#{output}", "/Data/Pictures/Icons/rails_fail.png", 2, "-s"
else
growl "Test Results", "#{output}", "/Data/Pictures/Icons/rails_ok.png"
end
end
end</code></pre></p>
Replace the paths to the pass/fail icons (as you can see, mine are in /Data/Pictures/Icons/</code>) with the correct paths to any images you want to display (grab them from Green goodness with autotest + growl</a> or roll your own). You can change the parameters passed to growlnotify</code> however you want (use growlnotify -h</code> to see what parameters it acccepts). The pri</code> parameter sets the priority level of the message (test failures come up with a priority of 2, hence the red background of the Growl notification). Passing -s</code> to sticky</code> tells Growl to keep the notification sticky. If you're running your (auto)tests on a remote server (e.g. in a Continuous Integration system), you can even use growlnotify</code> to send remote notifications (see the -H</code> switch) to your development workstations!</p>
Lovely! I love you, MacBook Pro serial no. W86280NAVWW (despite your broken DVD drive and you randomly freezing up on me when you get too hot).</p>


Testing rescue_action_in_public with RSpec
2007-03-31T01:34:05+00:00
After overriding rescue_action_in_public</code> in the ApplicationController</code> to deal with ActiveRecord::RecordNotFound</code> exceptions (a very common exception to rescue</code> in the canonical 'show' actions of your controllers), I decided to test it. I've been getting used to BDD</acronym> with RSpec</a> (and the Spec::Rails plugin</a>), so I stumbled a bit when writing the spec.</p>
I finally settled on this:</p>

class DummyController < ApplicationController
  def index
  end
end
context 'A child class of ApplicationController' do
controller_name :dummy</p>
specify 'should render a 404 error for ActiveRecord::RecordNotFound,
ActionController::UnknownController,
ActionController::UnknownAction,
ActionController::RoutingError exceptions (in public)' do</p>
exceptions_404 = [
  ActionController::RoutingError.new('test'),
  ActiveRecord::RecordNotFound.new,
  ActionController::UnknownController.new,
  ActionController::UnknownAction.new]

exceptions_404.each do |exception|
  controller.eigenclass.send(:define_method, :index) do
    raise exception.class, 'some message'
  end

  lambda {
    get 'index'
  }.should_raise(exception.class)
  controller.send :rescue_action_in_public, exception

  response.should be_missing
end
</code></pre>
end
end</code></pre></p>
Notice the use of a dummy controller so that we can actually make a request to it (and get all the Rails magic and environment set up ready for testing). Also, I had to use instances of the exceptions rather than their classes because I'm send</code>ing a rescue_action_in_public</code> message to the controller without knowing how to instantiate the exceptions (for example, ActionController::RoutingError</code> actually has a constructor which requires at least 1 argument). So I create the exceptions first.</p>
The eigenclass</code> method simply returns Ruby's canonical singleton class or metaclass, depending on who you talk to (i.e. class << self; self; end;</code>) and I modify the dummy 'index' action to raise the exception. And here's the stinky part:</p>

lambda {
  get 'index'
}.should_raise(exception.class)
controller.send :rescue_action_in_public, exception</code></pre>
Make a GET to the 'index' action, make sure it raises the exception and catch it (with should_raise</code> - the assertion is unnecessary since I did override 'index' to raise the exception), and then force rescue_action_in_public</code> to be called. Something's fishy here - why isn't the exception caught by default by rescue_action_in_public</code>? I've set these to make sure that rescue_action_in_public is called but it seems like it never is called:</p>

ActionController::Base.consider_all_requests_local = false
controller.eigenclass.send(:define_method, :local_request?) do
  false
end</code></pre>
I traced the code into ActionController::Rescue and everything seems to be in order. I'm stumped and weary, I think I'll look at this again tomorrow. Anyone see any obvious mistakes?</p>


Checking for duplicate ActiveRecord objects
2007-03-27T01:05:35+00:00
I've been writing a database importer plugin for a Rails application that needs to data on some "legacy" production databases (well, not really legacy, but the schema differs from ActiveRecord conventions) with the intention of scheduling a cron job to run the imports. Why not connect the Rails app to the legacy databases? Hmm, let's see:</p>

the records don't have to be up to date (so I can afford to, say, import yesterday's records today),</li>
less jumping through hoops molding ActiveRecord models to the legacy databases,</li>
the production database schema is liable to change - but this should not affect my Rails application,</li>
there will be lower loads on the legacy databases which are in full-blown production use, and</li>
most importantly, it gives me an excuse to figure out writing a data importer for a Rails application.</li>
</ul>
And I am surprised that it actually was rather fun writing the importer plugin (data importing stuff is normally one of the most unexciting things a programmer can do, right next to writing lengthy requirements documentation and any kind of contact sport). It's basically a plugin that defines ActiveRecord models on the source (legacy) databases and then creates our Rails app's models from these. Importer classes allow me to then run the imports using script/runner</code> like so:</p>

script/runner "HotelsImporter.import :start => 2.days.ago.to_date, :end => 1.day.ago.to_date" -e production</code></pre>
Put that in a cron job and there you go, scheduled daily (or hourly, whatever) imports.</p>
But I digress. What was I actually going to talk about? Oh yes, checking for duplicate ActiveRecord objects. Now, the importers I wrote were run daily but there was the risk of re-importing the same data again (due to failed cron jobs, running the same job twice, acts of god, etc.). To be defensive, I needed to check that there were no existing records before importing them from the legacy databases.</p>
At this point I could decide to run uniqueness checks on any natural keys of each table (and Rails makes this really easy with AR</acronym> validations, as we all know), or rely on a more convenient "the whole hog" field-by-field comparison. I settled on doing a field-by-field comparison after realizing that:</p>

it's easier and I don't have to specify which natural fields constitute the natural keys, and</li>
there are some tables which don't really have a natural keys (these generally belong to has_many side of an association).</li>
</ul>
Update: As choonkeat pointed out in a comment below, I can simply use Post.find(:all, :conditions => new_post.attributes)</code> since that stood out very clearly as the way to do it. This was actually the first way I tried to do this but it didn't work in the importer - I must have been doing something stupid! Doh! Thanks choonkeat for pointing out my blooper. Anyway you can mostly ignore what follows below but I'll keep it here to remind myself of my error.</ins></p>
So I went looking for an easy way or a Railism to check whether an existing new ActiveRecord object already exists in the database. Hmm, I couldn't find anything helpful - I guess everyone is relying on AR validations. Still, I went ahead and mixed in a to_conditions</code> instance method to ActiveRecord::Base - looks like my answer to everything nowadays is to re-open existing classes.</p>

module Bezurk #:nodoc:
  module ActiveRecord #:nodoc:
    module Extensions
      def to_conditions
        attributes.inject({}) do |hash, (name, value)|
          hash.merge(name.intern => value)
        end
      end
      alias :to_conditions_hash :to_conditions
    end
  end
end
...</h1>
ActiveRecord::Base.send(:include, Bezurk::ActiveRecord::Extensions)</code></pre></p>
So now in my importers I can easily check for potential duplicate entries:</p>

new_post.save! if Post.find(:all, :conditions => new_post.to_conditions).empty?</code></pre>
Now, I just have this nagging suspicion that there is a better way to do this...</p>


irb and script/console tab-completion
2007-03-26T20:33:00+00:00
Ugh, I wish I found this earlier: Tab Completion in IRb</a>. I only went googling for this after I realized I have been tabbing to get auto-completion on script/console</code> for a bit but it never sunk in that tab-completion wasn't ever working. Useful stuff, go set it up if you haven't already.</p>


DRYing up link_to_remote for degradable URLs
2007-03-24T23:20:08+00:00
I like to keep my links in my Rails applications that make AJAX requests degradable in non-JavaScript browsers so I often find myself doing this:</p>

link_to_remote 'Show details',
  { :url => { :action => 'show', :id => post.id } },
  { :href => url_for({ :action => 'show', :id => post.id }) }</code></pre>
This allows me to get HTML links like so:</p>

<a href="http://www.example.com/posts/show/123" onclick="...">Show details</a>
</code></pre>
instead of the usual (if the :href parameter is not specified):</p>

<a href="#" onclick="...">Show details</a>
</code></pre>
You've probably already noticed the duplication right there in the :url</code> key of the 2nd parameter (options) and the :href</code> key of the 3rd parameter (HTML options) that litters my Erb</acronym> templates where link_to_remote calls are prevalent. I got tired of editing and copying and pasting the url_for</code> parameters so I monkey patched Rails' PrototypeHelper class in ActionPack (actionpack/lib/action_view/helpers/prototype_helper.rb</code>).</p>
To do this, I had to replace Rails' link_to_remote</code> method definition. Thanks to living and breathing code examples in Rails that do this, I was able to promptly come up with this module that I placed into the lib/</code> directory of my Rails application and require</code> it in my environment.rb</code> file.</p>

module Bezurk #:nodoc:
  module ActionView #:nodoc:
    module PrototypeHelperExtensions
      def self.included(base)
        base.alias_method_chain :link_to_remote, :degradation
      end
  def link_to_remote_with_degradation(name, options = {}, html_options = {})
    html_options[:href] = url_for(options[:url]) if !html_options.has_key?(:href)
    link_to_remote_without_degradation(name, options, html_options)
  end
end
</code></pre>
end
end</p>
ActionView::Helpers::PrototypeHelper.send(:include,
Bezurk::ActionView::PrototypeHelperExtensions)</code></pre></p>
The modification to link_to_remote</code> itself is dead simple: it checks for the non-existence of a :href</code> key in the html_options</code> parameter and sets the :href</code> option in the html_options</code> parameter hash to the url_for</code> the :url</code> value in the options</code> parameter hash. It then calls the original link_to_remote</code> to do what it does best.</p>
I've submitted a (trivially simple) patch to Rails in my opened ticket #7904 - DRY up link_to_remote for degradable URLs</a>. Let's hope this makes it in so I can kill my monkey patch!</p>


BarCamp Singapore Jan 2007
2007-01-21T00:21:21+00:00
I just got back from BarCamp Singapore</a> a few hours ago. I was only vaguely familiar with the Rules of BarCamp</a> prior to this, and actually only found out about the event from Choon Keat</a> (of RssFwd</a> fame - check it out if you haven't already) 2 days ago.</p>
Anyway, props to the organizers for putting this together (especially the free BarCamp t-shirts from Yahoo!). Personally, I felt the icebreaker game took up too much time that could have been used for the sharing sessions - the tech track of sessions were crammed up towards the end of BarCamp.</p>
</div>

</p>
Notably, Harish Mallipeddi</a>, who interned at Bezurk</a> for a couple of months, shared with us an introduction to Django</a> together with some working code on a site he is working on. I didn't know a whole lot about Django before and was impressed that there is a "free" admin application for Django applications. We (Choon Keat, Harish, and I) had a small debate over Django's templating system (briefly, Django has it's own templating system for its views, whereas Rails ERB is basically Ruby code mixed in HTML). To this day I am still convinced that PHP is already a templating language despite my old Smarty card-carrying days</a>. Relating back to the Django templating system, Choon Keat and I didn't like the idea of having to learn to use a templating language when the base language itself (Ruby or Python) would suffice. Obviously Python syntax wasn't suitable for web designer consumption so Django had to come up with its own templating language.</p>
Michael from PetrolWatch</a> showed us some flashy scriptaculous effects on his site and demoed the Ruby on Rails-inspired CakePHP</a>. It's a nice framework if you had to use PHP and performance is a concern (it's true, Rails apps run more heavily than PHP scripts, and the difference in performance is very clear in servers with minimal resources). But the lack of a good testing framework was discouraging. Still, I must say I'd have used it (or a similiar framework) if Rails didn't exist or if I was tied to using PHP for web development.</p>
Choon Keat</a> showed the non-believers the power of Rails' script/console</code> as well as the flexibility of Ruby in allowing developers to make their own extensions to existing classes (aka "who needs hooks from God?"). I probably should have stepped in and showed some basic Rails migrations stuff that would have impressed (hopefully) the Django and CakePHP fanbase (all 2 of them) - but my laptop was running out of battery (and I was shy).</p>
Oh and I saw a good number of Macs there, and at least 3 laptops running a Linux distro of some sort. Cool.</p>


RubyGems 0.9.1 - required update
2007-01-20T23:02:35+00:00
RubyGems has been updated to 0.9.1</a> and is a required update due to a security issue. The blog announcement reveals more:</p>
The most important change in RubyGems 0.9.1 is that RubyGems no longer allows files to be installed outside of the installation directory.</p></blockquote>
It's a required update as the RubyForge gem repository will soon disallow installation of gems if you have an older version of RubyGems.</p>
Anyway, a new feature I found very useful is gem outdated</code>, which lists the gems you have installed that are currently not the latest versions (I just realized that mongrel is actually already up to 1.0 RC!). And don't forget multiple gem uninstallation with gem uninstall</code>.</p>
Update your RubyGems by running:</p>
gem update --system</code></pre>


Adding full text search to your Rails app in 1 hour and 10 lines of code
2006-12-04T19:19:17+00:00
Yup, it's that fast and simple, using Ferret</a>, a Ruby port of Lucene</a> (the de facto full text search engine written in Java) and the acts_as_ferret</a> plugin, I added "Did you mean this?" functionality to a small Rails application</a> (non-perma link) today rather quickly and painlessly.</p>
Adding full text search funtionality to your Rails applications</h3>
Install Ferret</a> via RubyGems.

sudo gem install ferret</code></p>
Install the acts_as_ferret</a> plugin for your Rails application.

ruby script/plugin install <ACTS_AS_FERRET_SVN_REPOSITORY></code></p>
Add the acts_as_ferret mixin method to your ActiveRecord model, specifying the fields you want indexed.</p>
class Location < ActiveRecord::Base
  belongs_to :country, :foreign_key => 'country_code'
  belongs_to :state
acts_as_ferret :fields => [:location_name, :country_name, :state_name]</p>
def country_name
country.country_name
end</code></pre></p>
If you have any associations that you want searched as well, one way (there is more than one way to do this) would be like what I did above with the country_name attribute of Country. For a more detailed discussion on Ferret and ActiveRecord associations, I found this thread in the Ruby forum</a> enlightening.</p>
In your controller, use Model.find_by_contents() to perform the full text search with your query. If you need fuzzy matching, append a tilde ("~") to the end of your query - if you're here, you probably needed fuzzy matching anyway as you're most likely creating "Did you mean this?"-type functionality.</p>
# In the controller...
@locations = Location.find_by_contents("#{@search_request.location_entered}~") # The "~" is for fuzzy matching.
</code></pre>
All that's left is to flash the appropriate message in your view and display your model objects as you normally would.</p>
Some gotchas</strong>:</p>

If you change the way your model is indexed, remember to clear out the existing one. acts_as_ferret stores the index by default in a 'index/' directory in the root of your Rails application. Stop your mongrel/Webrick process to remove the lock on the index files and delete the whole directory - Ferret will rebuild it the next time you perform a full text search.</li>
The first time you do a full text search, Ferret builds your index for you and this takes quite a while - don't be alarmed if your Rails application appears for freeze or returns a 500 internal server error. You can observe the contents of the 'index/' directory in the root of your Rails application to tell when Ferret has finished indexing (files stop appearing and disappearing). I found it easier to run a 'find_by_contents' call on my models via 'script/console' and waiting for some results to appear.</li>
Append a "~" to your query string for fuzzy matching! This allows you to retrieve results matching phonetically or are mispelled. There are more complex matching rules - check out the Lucene documentation.</li>
</ul>


Job Ad: Java Web Developer for Bezurk
2006-09-22T20:37:35+00:00
We</a>'re on the lookout for a Java Web Developer (ad on Craigslist)</a>. I managed to get "Ruby on Rails" into the ad copy somewhere heh - it gets kinda lonely working in a development team of Java heads. Anyway, we're looking for a great Java developer to work with us in Singapore - if you're up for it, send us your resume</a>. I would really like to get someone with some interest in Rails development to work together with on some upcoming (Rails) projects (you know, like after all the real work is done).</p>


Excluding specific tests with rake
2006-09-05T20:36:46+00:00
Sometimes, I just want to skip just that one test when I run my tests with rake test</code> because it takes much longer than other tests, and it gets in the way of rapid iterative cycles when coding. I looked around and haven't found a way to do that with rake</a>, so I set down to writing a custom rake task.</p>
namespace :test do
  namespace :units do
    Rake::TestTask.new(:excluding => 'db:test:prepare') do |t|
      if ENV['THESE']
        def t.file_list
          exclusion_patterns = ENV['THESE'].split(',')
          unit_tests = FileList['test/unit/**/*_test.rb'].select do |path|
            excluded = exclusion_patterns.select { |excl| /#{excl}/.match(path) }
            p "Excluding #{path}" if not excluded.empty?
            excluded.empty?
          end
        end
      else
        p 'Running all unit tests (specify THESE="pattern1, pattern2" to exclude files)'
        t.pattern = 'test/unit/**/*_test.rb'
      end
      t.libs << 'test'
      t.verbose = true
    end
    Rake::Task['test:units:excluding'].comment = 'Run unit tests with exclusions (specify exclusions with THESE="pattern1,pattern2")'
  end
end
</code></pre>
Of course, rake test:recent</code> and rake test:uncommitted</code> would suffice for most purposes, but there are times when I just want to not run that a particular test or tests because they just take too long (and by definition, get in the way) and I'm pretty sure they won't be broken. (Always run all the tests before a commit though, don't be naughty.)</p>
You can run the task like this:</p>
rake test:units:excluding THESE="item_test,atte\w*"</code></pre>
Update: As it turns out, the task descriptions weren't being set correctly. Revision 5016</a> fixes this so rake -T</code> shows the task descriptions properly.</ins></p>


Some functional testing gotchas in Ruby on Rails
2006-09-03T20:35:52+00:00
I've been writing lots of functional tests lately and came across several unexpected gotchas. Seeing as how forgetful I am recently, I'll jot them down here (and hopefully benefit anyone else who comes across the same problems).</p>
Testing flash.now</h3>
Testing the contents of the flash.now, somewhat surprisingly, can't be done with code like this:</p>
assert_equal 'Unable to activate your account.',
  flash.now[:error]
</code></pre>
flash.now[:error]</code> would be nil</code>, in your functional test, and a quick lookup on Google brought me to HowToTestFlash.Now on the Rails wiki</a>. Apparently, Rails renders the flash in the view and then proceeds to clear the contents of flash.now (so it isn't accessible in your functional test). So, you'd have to test the contents of the rendered page, instead of testing the flash itself:</p>
assert_tag :tag => 'div',
               :attributes => { :class => 'flash error' },
               :content => 'Unable to activate your account.'
</code></pre>
Asserting cookies</h3>
This one's particularly annoying - trying to assert that cookies are set by your controllers. Unlike what was written in the Rails manual on testing</a> (granted, it's rather well-known that the manuals are somewhat outdated), you cannot retrieve cookies using a Symbol as an index into the cookies</code> hash in your functional tests.</p>
cookies[:auth_token] = {
  :value => session[:user].remember_token,
  :expires => session[:user].remember_token_expires_at
}
assert cookies[:auth_token]  # nil
assert cookies['auth_token']  # This works.
</code></pre></p>
Thanks to Herry</a> for  pointing this out </a> - it saved me an exercise in frustration.</p>
Yet another cookie testing gotcha is testing for the deletion of cookies (example use case: deleting a users cookie after he logs out). So you may do this in your controller:</p>
cookies.delete :auth_token</code></pre>
And expect this to pass in your test:</p>
assert_nil cookies['auth_token']</code></pre>
But nope, instead of setting the cookie to nil</code>, the cookie is actually emptied.</p>
assert cookies['auth_token'].empty?  # This works.</code></pre>
I just used wrote my own custom assertion (there is an assert_cookie plugin around but I didn't think this justified adding another plugin to the application, not just yet):</p>
def assert_no_cookie(cookie_name)
  cookies[cookie_name].nil?
    || cookies[cookie_name].empty?
end
</code></pre>
Update: as it turns out, assert_no_cookie</code> and assert_cookie_equals</code> exist as custom assertions in ActionPack (source</a>), but have been deprecated in favor of the cookies</code> collection. Still, looking up the cookies</code> collection with a Symbol but having it return nil</code> is unexpected behavior considering the inline documentation says it should work.</ins></p>


From Typo to Mephisto
2006-09-01T20:34:25+00:00
So with the usual fickle-mindedness, I've changed my blog software from Typo</a> to Mephisto</a>. Well, it wasn't so much based on a whim - there were some reasons I wanted to stop using Typo:</p>

For some reason, Typo is very unstable for me on my VPS with 160MB RAM. I deploy Typo on a mongrel_cluster of 2 mongrels, fronting it with Apache 2.2 + mod_proxy_balancer, and all 160MB RAM and</strong> 192MB of swap is used up whenever I post an article or sweep the cache. Comments also take noticeably longer to post on my blog than on other Typo blogs. I'm not sure what exactly I've done wrong.</li>
I often get an obscure NilClass error that screws up the front page whenever pages are regenerated (often caused by someone posting a comment or an article).</li>
Changing the blog's design requires one to create or edit an existing Typo theme - I kinda missed WordPress's Web-based template editing. This was a significant roadblock to me ever changing the look and feel of my Typo blog.</li>
</ul>
Coincidentally, my urge to swap to Mephisto coincided with the release of mephisto 0.6 (Immortus)</a> just today, and after some minor hiccups, I managed to get Mephisto up and running with my articles imported from Typo. (Still couldn't get Capistrano to play well though, which I'm guessing is due to Rails version conflicts - I guess I'll just have to do with the release version.)</p>
Documentation</a> is rather sparse at the moment, especially on how to convert from Typo to Mephisto</a> (I updated that wiki page while I was there). I dug around in Mephisto 0.6â€™s source and found the converters in vendor/plugins/mephisto_converter. Not sure if there is a web interface to this - either way, things worked almost perfectly just running this command:</p>
script/runner "Mephisto.convert_from :typo" -e production</code></pre>
You need to create a typo entry in database.yml that points to your existing Typo database. Also, the conversion will fail if any of your Typo users and email addresses are the same as the default Mephisto user admin. To avoid this just change the Mephisto user(s) login and email to something else.</p>
So there's that, hopefully some time this year I'll update the look and feel.</p>


Application error (Rails) on Google search results
2006-08-15T20:09:22+00:00
I did a search on Google for "Rimuhosting"</a> today, some time after I signed up with them</a>, and hey, there's my blog in 3rd spot</em> - is that some mad SEO</acronym> skillz or what. And then "oooh, there's an 'Application error (Rails)' result coming out, that's not good".</p>
</div>

</p>
I thought it was amusing - Google must have crawled my site just as I had deployment troubles (yeah it was a smart</em> move leaving MySQL to it's default settings and</em> using the InnoDB storage engine on a memory-starved VPS). All seems fine now though I'm still somewhat amazed at the hungry Mongrels</a> (at 25-40MB per Mongrel process, these things run more like St. Bernards). (A shout out to Ryan Daigle</a> who has been giving me some Rails deployment advice.)</p>
By the way, the "mad SEO</acronym> skillz" comment was a joke, I wasn't at all surprised to be honest, Google just loves blogs (and they still do, after all this time of I've been not blogging).</p>


Moving to Rimuhosting VPS
2006-08-10T19:54:28+00:00
After being plagued with performance issues running Typo</a> (the blog software on which this blog currently runs) on Dreamhost</a>, I decided it was time to give in and get a VPS</acronym> once again. I was previously with Linode.com</a> (they have a great control panel where you can drop in the distro you want - still have screenshots somewhere for an unpublished post), and then JVDS</a> (good hosting, usually quick replies to my support tickets, but slow to push out a VPS control panel they've been promising), running Gentoo on both VPSs. Right now, I'm on a shared hosting plan with Dreamhost</a>.</p>
Well, Dreamhost</a> has been good to me - I got so many referral credits from them that they paid for my subscription many times over after I posted about their $0.77/month offer</a>. Unfortunately, Typo seems to be quite a monster (compared to Wordpress), and database access is purportedly (and observably) slow on Dreamhost</a>. Still, Dreamhost is a great host for shared hosting, I'm sticking with them for delivering more static content. A VPS just makes sense now that I've been tinkering more with Ruby on Rails, plus which geek wouldn't admit it just feels more right</em> to be in full control of your server (well, it's root on a virtual machine, but still root).</p>
This time around, I chose Rimuhosting</a>, a New Zealand-based hosting company (servers are US-based, of course), and here's why (I did some research once again on WebHostingTalk</a> and asked some people their experiences with their webhosts):</p>
Pros:</p>

Fairly affordable prices - I got their cheapest MiroVPS1 plan, which goes for $19.95/month and get 30GB of transfer and 96MB of RAM (which could</em> be a problem, but upgrading seems easy enough anyway from what they say on their site). Comparing to several other VPS hosts like unixshell</a>, Tektonic.net, ServerAxis</a>, their plans are somewhat mid-range.</li>
Their reputation is great. Yup, I've heard and read only good things about them, something that's quite hard to find in the world of web hosting. We use them at work to setup servers sometimes too.</li>
Seems to be run by competent people - they have a bliki</a> (blog + wiki) with some nice posts. The one that really caught my eye is the one on their Ruby on Rails hosting stack</a>. Not that I'd use it since I'm on Ubuntu, but it shows that the folks at Rimuhosting are up-to-date.</li>
They run Xen</a>, which Deepak</a>, among others, tells me is the most efficient server virtualization software. Yeah, whatever, score one for statistics (and lies).</li>
Support is reasonably fast - got replies to my pre-sales queries reasonably fast (more than a few hours, but it wasn't during working hours anyway). Of course, I'll have to see how it goes now that I'm a real customer.</li>
A simple web-based control panel where I can reboot the VPS. It's no Virtuozzo Power Panels</a>, but it's enough. JVDS didn't have one and it started to get old sending support tickets to do a reboot.
</div>


</li>
</ul>
Cons:</p>

They don't support Gentoo</a>, my Linux distro of choice. Only RHEL, Ubuntu, Debian and Fedora Core are supported. I went with Ubuntu, not having much experience with it (excluding a brief affair with Debian). I was wary of this at first, but my fears of bungling around with an unfamiliar distro have vanished after I saw how easy it is to install stuff with apt-get, and things are not</em> placed in weird places in the filesystem hierarchy. I think I could get used to it, this "not compiling everything that moves" idea ;).</li>
ServerAxis</a> supports Gentoo, and offers much better "value for money", except that their lowest priced plan is much higher ($30). But you get 512MB RAM</strong>, 200GB RAM, and 5 IP addresses</strong>... Too bad I'd rather pay out of my PayPal funds.</li>
</ul>
Well, less blogging, more server migration. Actually the application installs are mostly done. I've never had apt-get play so nice back when I was experimenting with Debian - just

apt-get install [package]</typo> and things are installed quite cleanly (keyword: "cleanly"). I think this may grow on me (yeah yeah laugh and point at the Ubuntu noob) - perhaps you don't need to compile everything (gasp</em>, I said it!).</p>


Rails 1.1.5 (security patch)
2006-08-10T19:46:24+00:00
For anyone who cares or who runs a production site on Rails, DHH</acronym> just announced the release of Rails 1.1.5 with an undisclosed security patch</a>. Time to</p>
gem install rails</code></pre>
and update your config/environment.rb to use the Rails 1.1.5</p>
# Specifies gem version of Rails to use when
# vendor/rails is not present
RAILS_GEM_VERSION = '1.1.5'</code></pre>


From Wordpress 2 to Typo 4
2006-08-06T19:33:05+00:00
It was a slow day so I decided to cross one thing off my to-do list, and that's getting Typo</a> installed and migrating from WordPress. I've been looking at getting Typo installed for awhile ever since I saw (and liked) its AJAX-y comments form, plus Typo 4</a> being just released did help.</p>
The install went straightforward enough, though I didn't get to try out the new installer gem. I didn't bother because I'm on a Dreamhost shared hosting account, though installing the gem without root privileges</a> seems like it should work. I simply followed this guide to getting Typo 4 running on Dreamhost</a>. Ran into some trouble running the Wordpress import script (found in /db/converters/wordpress2.rb), but Google turned up the solution</a> (basically a patch to the Articles model that tries to send pings when importing posts). This should already be fixed in Typo SVN, but it's not in release 4.0.</p>
Anyhow, Typo seems spiffy, though I am still getting the occasional "Application Error", but that's most likely a Dreamhost thing. Liking the near-minimalist theme as well - I'm already missing the green clover though heh.</p>
Things I'm already liking:</p>

Sidebar modules that you can add to your blog - for example, getting the del.icio.us links I have at the side to show is just a matter of dragging the del.icio.us sidebar item to the "Active" list and pointing it to my del.icio.us feed. There're sidebar items for Flickr, tags, 43things, Amazon, and even the categories and archives are sidebar items.
</div>


</li>
A Blacklist section where you can enter blacklisted words and regexes</strong>! Take that texas holdem poker!</li>
Live preview of your posts as you type - can get a little sluggish though.</li>
The ability to search and delete all comments - Wordpress was missing that and running SQL statements in phpmyadmin stopped being fun.</li>
The nice Scribbish theme</a> that comes with the Typo package.</li>
</ul>
Things that I don't like:</p>

Linking to uploaded files was confusing. I like the whole "Attachments" idea, but I didn't know how to link to them until I browsed to the Resources section and copied the link to the image I just uploaded (by saving the post I was making - there wasn't a way to upload an attachment while writing the post).
</div>

</p>
I'm probably doing things the wrong way though, seeing as this is way too obtuse. Would be nice to see improvements (such as, upload file as you write your post, click on uploaded file to include into post, all on the same page with AJAX).</li>
Um, nothing further!</li>
</ul>
Need to use it more to decide whether I'll like this or not.</p>

chuyeow.wtf

Rendering plists from your Rails app

Don't kill your app when using ActiveRecord in Rails Metal, release your database connections

Living on the Edge (of Rails) has a new home at the Official Ruby on Rails weblog

RailsConf 2008 Day 1 - pics and a summary

Living on the edge (of Rails) #22 - pre-Railsconf 2008 edition

Living on the Edge (of Rails) in Spanish

Living on the edge (of Rails) #21

Deploying with Capistrano via a gateway - some notes

Living on the edge (of Rails) #19 - change_table for migrations and more

Living on the Edge (of Rails) in French

Living on the edge (of Rails) #18

New in Rails: ActiveResource timeouts and why it matters

Timeouts and you</h3> If you're using Net::HTTP you can easily safeguard yourself against errors like this by setting a timeout on the socket connection. Like so:</p>

Living on the edge (of Rails) #17

ActiveSupport::Cache's mem_cache_store accepts options</h3> Even though Memcache-client was added to ActiveSupport recently, it didn't allow you to specify any configuration options beyond just the IP of the memcached server. Now you can pass along more configuration options like so:</p>

Living on the edge (of Rails) #16 - Github edition

Living on the edge (of Rails) #15 - the early edition

Living on the edge (of Rails) #14 - the extreme edition. Extremely late.

Install all required gems:</h1> rake gems:install</p>

Unpack specified gem to vendor/gems/gem_name-x.x.x</h1> rake gems:unpack GEM=chronic</code></pre></p>

Living on the edge (of Rails) #13 - Git script/plugin install, has_one :through

Living on the edge (of Rails) #12

In your view.</h1> javascript_include_tag :yui</code></pre></p> would result in:</p>

Living on the edge (of Rails) #11

Living on the edge (of Rails) #10

Living on the edge (of Rails) #9 - the sleeper edition

Living on the edge (of Rails) #8 - the code optimization edition

Living on the edge (of Rails) #7 - improved ActiveRecord::Base#attributes, time zone support

Living on the edge (of Rails) #6 - better performance, Git support, and more

ActiveCouch - a CouchDB library in the spirit of ActiveResource and ActiveRecord

Living on the edge (of Rails) #5 - better eager loading and more

Rails and penis enhancements

Living on the edge (of Rails) #4 - faster routes, easier form partials

Seen in the Rails source - Orcl nds shrt indx nms

Living on the Edge (of Rails) #3 - X-Sendfile and many other sexy enhancements

Access your named routes and the url_for helper.</h1> url = page_url(:permalink => 'foo') end</code></pre></p> And now it respects your relative_url_root</code> instead of blissfully ignoring it.</p>

Optimizations</h3> There're significant performance improvements for classic fixtures with HABTM data, due to some slightly clever caching model classes, and instantiating fixtures from the model class, instead of expensive constant lookups from the name of the class.</p>

Living on the Edge (of Rails) - 1st week of the year edition

self.plug :with => 'Rails Hackfest'

Living on the Edge (of Rails) - the pilot

=> ActiveRecord::StatementInvalid: Mysql::Error: Unknown column</h1> 'posts.category' in 'on clause'</code></pre></p> </li> </ul>

I can has feedback nao plz?</h3> Please leave any suggestions for improvements you may have - about anything really: format, level of detail, what you'd like to see, whatever. Until next week...</p>

Why I love RSpec nested example groups

DRY in your functional and ActionMailer tests - Rails 2.0 a feature a day #7

Generating migrations gets easier - Rails 2.0 a feature a day #6

Rails 2 a feature a day - update

Rails 2.0.2 released, so what's new?

Install all required gems:</h1>
rake gems:install</p>

Unpack specified gem to vendor/gems/gem_name-x.x.x</h1>
rake gems:unpack GEM=chronic</code></pre></p>
Credit goes to the prolific Rick Olson</a> for this gem of a patch.</p>
Related changeset: http://dev.rubyonrails.org/changeset/9140</a></p>

=> ActiveRecord::StatementInvalid: Mysql::Error: Unknown column</h1>
'posts.category' in 'on clause'</code></pre></p> </li> </ul>

I can has feedback nao plz?</h3>
Please leave any suggestions for improvements you may have - about anything really: format, level of detail, what you'd like to see, whatever. Until next week...</p>