chuyeow.wtf

A curl-ier Curb - better cookie support in Curb

2009-06-18T09:42:10+00:00

As of Curb</a> 0.3.7, Curb comes with slightly better cookie support that makes it more "curl</a>-like".</p>

It probably sounds like shameless self-promotion that I'm blogging about these changes since I'd contributed them. Well, yeah that's true, but I'm also doing so because I doubt these changes will ever be made known since Curb doesn't publicize any updates or changelogs. </p>

Curb is my current number 1 HTTP client for Ruby so the more love it gets, the better.</p>

Passing cookies as a string in Curb requests</h3>

Curl veterans will probably know how to do this with the curl binary:</p>

curl -b "auth=abcdef; ASP.NET_SessionId=lotsatext;" example.com</code></pre>
This sends a request to example.com with 2 cookies named "auth" and "ASP.NET_SessionId" (I hate those big-ass ASP.NET cookies btw). There wasn't a way to set this in Curb, so I looked up the libcurl C API docs</a> and replicated the same option in Curb (commit on Github</a>). An example:</p>
curl = Curl::Easy.new('http://example.com/')
curl.cookies = 'auth=abcdef; ASP.NET_SessionId=big-wall-of-text;'
curl.perform</code></pre>
Of course, the cookies will more often be retrieved/constructed rather than a literal like in the example above. In my case, I was proxying cookies while trying to wrap an API around a site that doesn't have one.</p>
Passing cookies as a file via the "cookiefile" option</h3>
The second change is the new cookiefile</code> option. This replicates curl commands like these:</p>
curl -b cookies-to-send.txt www.example.com</code></pre>
with something like this in ruby:</p>
curl = Curl::Easy.new('http://example.com/')
curl.cookiefile = '/path/to/cookies-to-send.txt'
curl.perform</code></pre>
The cookies file looks like this (you can get a sample with the --cookie-jar</code> option to curl, e.g. curl --cookie-jar cookies.txt www.wego.com</code>):</p>
www.wego.com	FALSE	/	FALSE	0	lang	
www.wego.com	FALSE	/	FALSE	0	user_country_code	SG</code></pre>
Check out the commit on Github</a> if you're interested.</p>
Why would I use these?</h3>
Now you might be wondering how these 2 changes are useful - well, they are</em> totally irrelevant to you if you're not expecting any cookie support in Curb. However, if you're accessing or scraping a site that uses cookie-based authentication</strong>, these changes allow you to keep your Curb client authenticated across sessions, even when doing HTTP POSTs (Curb doesn't send cookies properly in POST requests even if curl.enable_cookies</code> is set).</p>
I've found these changes to Curb particularly useful since I vastly prefer Curb to most HTTP clients for its speed and lightweight implementation, and heavier scraper-type HTTP clients like Mechanize</a> are a last resort.</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>


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>


Installing libmemcached and memcached gem on Ubuntu
2008-03-31T12:20:54+00:00
Quick notes for installing libmemcached</a> and Evan Weaver's memcached gem</a>, in case I forget (again):</p>

Get libmemcached source from http://tangent.org/552/libmemcached.html</a>. Configure, make, make install. Make sure you get a version compatible with the Ruby memcached gem by opening the COMPATIBILITY file in the memcached gem files.</li>
gem install memcached</code></li>
Create a symlink ln -s /usr/local/lib/libmemcached.so.2 /usr/lib/</code>.</li>
Try it out with irb -rubygems</code>, require 'memcached'</code></li>
</ol>


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>


UTF8 encoding with Ruby Sequel (and MySQL)
2008-03-15T23:12:17+00:00
Just a quick note to self. If you need to store Unicode and are using Sequel</a>, make sure you:</p>

Create the database with a default charset of UTF8: CREATE DATABASE my_db DEFAULT CHARSET utf8;</code>. I think then any tables you create uses the default charset of utf8 unless otherwise specified</a>.</li>
Pass an :encoding</code> option to Sequel's MySQL adapter:
DB = Sequel.mysql 'my_db', :user => 'root', :password => '', :host => 'localhost', :encoding => 'utf8'</code></pre>
</li>
</ul>
The Sequel documentation</a> and wiki were quite unhelpful but reading code</a> (see the connect</code> method definition) always helps!</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>


Trying code blocks in Ruby (aka Prototype's Try.these)
2008-01-28T23:30:50+00:00
Prototype's Try.these</code></a> is a really useful bit of code (though I doubt it sees much application outside of JavaScript libraries). I have this evil bit of code somewhere, for example:</p>
var results = Try.these(
  function() { return response.responseText.evalJSON(true); },
  function() { return eval('(' + response.responseText + ')'); }
);</code></pre>
Evilness personified in its eval</code>ed glory, but that's besides the point here.</p>
Just for fun, I tried to do this in Ruby, just to see how easy it was, and came up with this try</code> method:</p>
module Kernel
  def try(*these)
    raise ArgumentError, 'try requires at least 2 arguments' if these.size <= 1
    fallback = these.pop unless these.last.respond_to?(:call)
    these.each { |candidate| begin return candidate.call rescue next end }
    fallback || raise(RuntimeError, 'None of the given procs succeeded')
  end
end</code></pre>
Which you can (ab)use like this:</p>
try(
  Proc.new { open('http://finance.yahoo.com/foo/') },
  lambda { open('http://finance.google.com/bar/') },
  proc { open('http://finantiq.com/flomp/') },
  :fallback
)</code></pre>
Real world applications would be, like the example above, retrieving content from several unreliable websites to retrieve currency rates.</p>
You can find the specs for Kernel#try</code> here: http://pastie.org/144339</a>.</p>
So the question now is, is there a better way to implement this, or a more idiomatic Ruby way?</p>


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>


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>


Retrying code blocks in Ruby (on exceptions, whatever)
2008-01-14T18:13:47+00:00
I am not certain whether the ability to retry a code block when encountering exceptions was a feature available in Ruby, but I certainly couldn't find anything on that topic (what I did find were mostly about the retry</code> keyword for iterator loops).</p>
Before you ask why I need this, the motivation for this was because I was getting intermittent HTTP errors (503s mostly) trying to connect to a web service. Turns out it's really easy in Ruby to implement a retryable</code> method that does something like this:</p>
retryable(:tries => 5, :on => OpenURI::HTTPError) do
  open('http://example.com/flaky_api')
  # Code that mashes up stuff for your "social networking" site.
end</code></pre>
Here are the Kernel#retryable specs (pastie)</a>.</p>
And the code:</p>
# Options:
# * :tries - Number of retries to perform. Defaults to 1.
# * :on - The Exception on which a retry will be performed. Defaults to Exception, which retries on any Exception.
#
# Example
# =======
#   retryable(:tries => 1, :on => OpenURI::HTTPError) do
#     # your code here
#   end
#
def retryable(options = {}, &block)
  opts = { :tries => 1, :on => Exception }.merge(options)
retry_exception, retries = opts[:on], opts[:tries]</p>
begin
return yield
rescue retry_exception
retry if (retries -= 1) > 0
end</p>
yield
end</code></pre></p>
It's not hard to implement the same for checking return values as well, i.e.</p>
retryable_deluxe(:tries => 5, :on => { :return => nil }) { puts "working..." }
retryable_deluxe(:on => { :exception => StandardError, :return => nil }) do</p>
your code here</h1>
end</code></pre></p>
Ruby is nice.</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>


Ruby 1.9.0 has been released
2007-12-26T00:15:49+00:00
Just in the nick of time for the Christmas target, the Ruby core team has released Ruby 1.9.0 - Matz</a> announced the release on the ruby-talk mailing list</a> not too long ago.</p>
Rubygem and Ruby library developers, now's the time to get down to making your Ruby code compatible with 1.9.0.</p>
Rails is not too far from being compatible with 1.9, thanks to the efforts of Jeremy Kemper</a> and a few other contributors. Mongrel is not quite there yet though (I use mongrel for my Rails applications, and I think at least 50% of you do too). So while running your Rails apps on Ruby 1.9 is not an easy task right now (unless you enjoy lots of monkey patching), let's hope the full 1.9.0 release will inspire more Ruby developers to get their libraries compatible so we can all enjoy the big speed boost in Ruby 1.9</a>.</p>
Very nice (if somewhat geeky) Christmas present from the Ruby core and contributors!</p>


gchartrb = Ruby + Google Chart API
2007-12-12T00:22:27+00:00
Google Chart API</a> looks quite useful. I've used Gruff</a> to generate graphs before but this looks way easier (and much lighter on the server without all that ImageMagick magic!) I'll have to play with it someday - if only I didn't have to mess with those URL params</a>!</p>
Well, Deepak Jois</a> from singapore.rb</a> (the local Ruby user group) recently announced</a> a Ruby wrapper around the Google Chart API: gchartrb</a> (rdocs</a>). You can get it as a rubygem, just run:</p>
sudo gem install gchartrb</code></pre>
Looking good so far and I dig the familiarity - Deepak says the API is Gruff-inspired and it tells. If you need a charting solution (for reporting or whatever), this is a gem to consider.</p>
Ah yup, there'll be no Rails 2 feature</a> today - just submitted a couple of Ruby 1.9 compatibility patches for Rails and feeling a little bummed out now (dependency handling</a> is not that pleasant in Rails). Rails' Ruby 1.9 compatibility</a> needs you!</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>


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>


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>


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>


'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>


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>


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>


Ruby on Rails satire blog
2006-08-14T20:06:59+00:00
Javac programmers are Very Slow and he is Agile</h4>
My Rails Blob</a> pokes fun at the cult of Ruby on Rails via satire. Recommended blog posts: Rubby Links on the W.W. w.</a> and  Upgradeing Rails: Securiety through Obscenity</a> [sic</em>]. I've subscribed to the RSS feed.</p>
NO! - Bad User!!!</h4>
The Daily WTF</a> has this monthly collection of hilarious pop-up error blunders, and as usual this month's a gem: Pop-up Potpourri: Announced By God</a>. Must read.</p>
Developers would find this particularly funny (I did):</p>
</div>

</p>
And this one's for my boss, Gary (remember the 'Abort/Retry/Ignore' you saw at the MRT station?)</p>
</div>


Extract Any Archive with Ruby, Slimtimer, Feedalizer
2006-08-12T19:58:06+00:00
A bunch of cool stuff I found over the weekend that didn't individually deserve a blog post, but I thought would be worth sharing.</p>
Extract Any Archive with Ruby</h4>
This is really neat if you could never remember what commands or command-line arguments you need to extracting archives (.zip, .tar.gz, .tar.bz2 - those kinds of archives).</p>
With this Extract Any Archive</a> script written in Ruby, instead of</p>
tar jxvf DonkeyPr0n.tar.bz2</code></pre>
you can simply do</p>
e DonkeyPr0n.tar.bz2</code></pre>
Instant gratification!</p>
Slim Timer</h4>
SlimTimer</a> is one another of those productivity-keep-track-of-your-todo-list type applications - I like it because seeing the time ticking away gets you motivated on sticking to the task at hand. You can stick it into your Firefox sidebar and all that AJAX-y stuff makes it behave like a normal application.</p>
</div>

</p>
Feedalizer - transform web pages into RSS feeds</h4>
Choon Keat</a> pointed this out to me recently: Feedalizer</a> (backed by Hpricot</a>). I played around with it and it was so easy (and fun) to use. Whipped up a Mongrel news feed</a> (code</a>) for Mongrel news</a> (which didn't have an RSS feed). The hardest part was figuring out which Hpricot methods to use to parse the bits I needed.</p>
Served by Apache 2.2, mod_proxy_balancer, and Mongrel</h4>
I got off my butt and set up Apache 2.2 with mod_proxy_balancer to load-balance a cluster of Mongrel processes, if you're still seeing this, that means it hasn't crashed, yet :p. Just kidding heh - I'm finding this setup pretty stable, though there was once the mongrel processes seem to have been over-loaded with requests (with 96MB RAM I can only run 2 processes, and even then I run out of memory real fast due to automated comment spam - does anyone have any solutions to blocking automated comment spammers before they even hit your website?).</p>
In any case, I learnt quite a bit as I was setting up my deployment environment for Rails, and hopefully someone will be able to benefit from that when I finish my post on the topic.</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>


Easy introspection in Ruby
2006-08-09T19:43:40+00:00
Just some notes on reflection and introspection in Ruby</p>

someString = 'http://google.com'
Print the object's class, methods, superclass and</h1>
ancestors (mixins and superclasses),</h1>
p someString.class
p someString.methods
p someString.class.superclass
p someString.class.ancestors</p>
Print the methods of the String class.</h1>
p String.private_instance_methods(false)
p String.public_instance_methods(false)</p>
Pass true to recurse into parent classes.</h1>
p String.public_instance_methods(true)</p>
Calling instance methods with send().</h1>
"Random text".send(:length) # 11
-23.send(:succ) # 22</p>
Using Method objects and call().</h1>
length_method = "Random text".method(:length)
length_method.call # 11</p>
Another way, using eval().</h1>
length_method = %q{"Random text".length}
eval length_method
</code></pre></p>
Check out Distributed Ruby (DRb)</a>: it's a very neat, non-fancy way of exposing object methods as remote services.</p>


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>


RSpec and BDD
2006-08-05T16:08:33+00:00
RSpec</a>: Behavior Driven Development framework for Ruby. It's like writing your specifications in English that's executable. Eight tools in one</a>, and a really nice Mock Objects framework</a>.</p>

chuyeow.wtf

A curl-ier Curb - better cookie support in Curb

Passing cookies as a file via the "cookiefile" option</h3> The second change is the new cookiefile</code> option. This replicates curl commands like these:</p>

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

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>

Installing libmemcached and memcached gem on Ubuntu

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>

UTF8 encoding with Ruby Sequel (and MySQL)

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

Trying code blocks in Ruby (aka Prototype's Try.these)

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

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>

Retrying code blocks in Ruby (on exceptions, whatever)

your code here</h1> end</code></pre></p> Ruby is nice.</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

Ruby 1.9.0 has been released

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>

your code here</h1>
end</code></pre></p>
Ruby is nice.</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>