For example, this is how you would display linked titles for the top 5 videos from my YouTube account (“pelargir”) using the Radius tags provided by the extension:

<ul>
  <r:youtube user="pelargir">
    <r:videos count="5">
      <li><a href="<r:video:url />"><r:video:title /></a></li>
    </r:videos>
  </r:youtube>
</ul>

To install in your own project, visit the youtube_tags profile in the Radiant extension registry.

For example, say I have a table of records with created_at timestamps. My view displays all records with timestamps equal to or before the current time. Let’s assume the current time is 15:00:00 precisely and I happen to have a record with a timestamp of 15:00:00 in the database. The SQL comparison would work fine in this case.

SELECT * FROM records WHERE created_at <= "2010-06-25 15:00:00"
=> 1 row in set

What if the timestamp in the database is 15:00:03 though? Let’s run the query again.

SELECT * FROM records WHERE created_at <= "2010-06-25 15:00:00"
=> Empty set

Since 15:00:03 is greater than the current time of 15:00:00, the record doesn’t get returned. This would be fine if we were displaying seconds in the view, but we’re not. From the user’s perspective, the timestamp on the record is still 15:00 and should appear in the view since it’s equal to the current time. But it doesn’t.

One way to fix this would be to handle the time comparisons in Ruby. This is certainly a legitimate option. For this particular project, though, performance was a big issue. (And we all know that Rails can’t scale.) I needed a way to continue letting the database handle the comparisons while disregarding seconds.

The solution I ended up with isn’t ideal (it relies on a couple of functions built into MySQL) but it works fine and runs fast:

SELECT * FROM records WHERE (created_at - INTERVAL SECOND(created_at) SECOND) <= "2010-06-25 15:00:00"
=> 1 row in set

The number of seconds is extracted from the created_at timestamp and then subtracted from the timestamp. So if the timestamp was 15:00:03, MySQL subtracts 3 seconds to end up with 15:00:00.

This solved the comparison problem for me and made my client very happy. Double win.

February 17 of this year: RubyGems 1.3.6 is released and my apps begin suffering from deprecation warnings. They’re all over the place: when I run a test, when I launch script/console… when I sneeze.

/Users/pelargir/Projects/teascript/config/../vendor/rails/railties/lib/rails/gem_dependency.rb:119:Warning: Gem::Dependency#version_requirements is deprecated and will be removed on or after August 2010.  Use #requirement

Rumor has it the deprecation warning will go away with 2.3.6. And 2.3.6 is expected to drop any day. Yay! Problem will be solved soon… or so I thought. I begin waiting.

May 23: 2.3.6 finally drops.
May 24: 2.3.7 drops because of a bug in 2.3.6. What the heck?
May 25: 2.3.8 drops because of a bug in 2.3.7. Okay, this is getting crazy.

Was anyone else embarrassed about the 6-month delay for 2.3.6 followed by two more point releases over the span of three days? This is exactly the kind of anecdote an exec at a Fortune 500 would raise to prevent a move towards Rails and keep the company locked into Java or .NET for another decade. Ugh.

We can do better than this.

It’s actually pretty easy to build a custom Cucumber step that triggers Lindo from your cukes. First, install the Lindo gem in your Rails app. Then create features/steps/lindo_steps.rb and insert this code:

Then /^render the current page$/ do
  extend Lindo
  vr
end

The step can be named whatever you like best, but “render the current page” works for me. To trigger Lindo from within your cukes, simply reference the step like so:

Given I am logged in
When I follow "some link"
Then render the current page

When Cucumber hits the last step, the default browser window will open and the contents of the page at that step in the scenario will be displayed. This is very handy when troubleshooting why a specific scenario is failing. It’s also useful for determining what you should be testing for on a given page.

before_update do
  if started_at.to_s(:abbrev_date) != started_at_was.to_s(:abbrev_date)
    errors.add :started_at, "cannot be set to a different day"
  end
end

The started_at date was coming back in the Eastern time zone as expected. The started_at_was attribute, which was supposed to reflect the value prior to the update, was coming back as a UTC date/time. I would expect it to be returned in the Eastern time zone too. Apparently, I’m not alone in this assumption because a ticket was opened for this issue last month.

An official fix hasn’t been made yet, but I got around the problem by calling in_time_zone on my dirty attribute:

before_update do
  if started_at.to_s(:abbrev_date) != started_at_was.in_time_zone.to_s(:abbrev_date)
    errors.add :started_at, "cannot be set to a different day"
  end
end

To move to a new API version, I copy all of the existing integration tests and rename their prefix to the new version. Instead of renaming the files by hand, there is a nifty UNIX command that handles it for me. For example, to rename all the “v2_*.rb” files to “v3_*.rb” I would type:

for file in *; do mv "$file" "v3_${file#v2_}"; done

sudo gem install test_spec_on_rails

Add to your Rails app’s test.rb like so:

config.gem 'test_spec_on_rails'

Enjoy the goodness of test-spec helpers from inside your Rails tests. Fork and submit patches via the GitHub project. Tell your friends. Donate money. Vote for Pedro.

sudo gem install time-zone-warp

To configure in your Rails app, add this line to the bottom of test.rb:

config.gem 'time-zone-warp', :lib => 'time_zone_warp'

You can also fork the code from the project on GitHub.

module ZoneWarp
  def pretend_zone_is(zone)
    original_zone = Time.zone
    begin
      Time.zone = zone
      yield
    ensure
      Time.zone = original_zone
    end
  end
end

Test::Unit::TestCase.send(:include, ZoneWarp)

Simply stick this code in a file inside your config/initializers directory (or include it from test_helper.rb or spec_helper.rb if you insist on doing it the right way) and you’re all set to write tests like this:

test "code works in other time zones" do
  pretend_zone_is "Mountain Time (US & Canada)" do
    # assertions go here
  end
end