SmartLogic Solutions Blog

This past weekend I released v0.1.0 of the Timecop gem. Timecop makes it dead simple to travel through or freeze time for the sake of creating a predictable and ultimately testable scenario.

The gem is derived from a plugin I wrote a while back to achieve more or less the same functionality for an extremely time-sensitive application. My goals for the gem included:

1. Drop-in-ability: The primary goal is to allow your app to continue to use Time.now, Date.today and DateTime.now as normal within your application. No overloading of functions with optional arguments (a la today=Date.today) just so you can write test cases.
2. Environment independence: I wanted the gem to work (a) w/ rails (ActiveSupport actually), (b) w/ plain ruby when the ‘date’ library has been loaded, and (c) w/ plain ruby when the ‘date’ library had not been loaded.
3. Library independence: I could have utilized mocha to achieve the mocking functionality found under the hood, but because I wanted this to work with plain vanilla ruby, libraries like mocha are out.
4. Short-term time travel: I wanted to expose the ability to temporarily change the concept of “now.” This is particularly helpful when writing tests where time needs to pass.
5. Long-range time travel: I wanted to expose the ability to change the concept of “now” for an indeterminate period of time. This is particularly helpful when setting up a rails test environment along with the test data.
6. Nested time travel: I wanted to provide the ability to nest traveling, allowing the state to be kept within each block (we’ll see an example later).

The gem is hosted on RubyForge and can be installed by simply running:

sudo gem install timecop

(more…)

ActiveRecord provides a powerful method to all its records called to_xml. Most web developers using RoR should be familiar with its usage and hopefully use it for their simple xml production needs. But what do you do when you need to produce xml that is selective, includes associations, or contains custom tags? There are many ways to manipulate to_xml’s output and I’ll explain a few below.
(more…)

OR “Beware of pick pockets and loose link_to’s”

I hope most rails dev’s out there take advantage of RESTful routes and the url-generating helpers so readily available these days and actually enjoy them. But for some of you who are lucky enough to inherit a legacy app (you know, 1 year olds) or for whatever reason encounter loosely defined link_to’s [exemplified below], you can easily update the code to avoid some gotchas.

This is what I consider a loosely defined link_to:

link_to 'Destroy', some_record, :confirm => ‘Are you sure?’, :method => :delete

It lacks parentheses, option grouping, and most importantly, expects the helpers to generate a specific kind of link (in this case a destroy action) from just the record itself. Now, rails is pretty smart these days and will probably generate the correct link without a hiccup if your app isn’t employing a custom RAILS_RELATIVE_URL_ROOT, or setting skip_relative_url_root => false.

Well, my latest app is. And this is how that loosely defined link_to renders:

ArgumentError in Controller#action
wrong number of arguments (0 for 1)

The stack trace will provide evidence that some thing’s a mess in url_for related to the default_url_options, defined in application.rb (or elsewhere). Rails’ helpers cannot correctly produce a url due to lazy linking.

So, make your code more readable and keep the helpers happy and define your link_to’s like this:

link_to ( 'Destroy', record_path(some_record), :confirm => ‘Are you sure?’, :method => :delete )

Refresh that error page and voila! Happy links again! Stricter coders may even group the options with curlies, and that doesn’t hurt either.