Alex Chaffee's blog
Now that I'm starting to use DelayedJob to perform jobs in the future in my Heroku Sinatra app, its important that they happen at the scheduled time. But unless you pay attention, you'll find that times get mysteriously changed -- in my case, since I'm in San Francisco in the wintertime, by +/-8 hours -- which means that some conversion to or from UTC is being attempted, but it's only working halfway.
Trying to keep a handle on which libraries are attempting, and which are failing, to convert times is a losing battle, so I'm trying to do the right thing and save all my times in the database in UTC, and convert them to and from the user's local time as close to the UI as possible. Unfortunately, a variety of gotchas in Ruby and ActiveRecord and PostgreSQL makes this trickier than it should be. Here's a little catalog of my workarounds.
The following monkey patch gives a bit more information in the ActiveRecord SQL logs. Instead of just saying "User Load" it also says the file and line number in your code that asked AR to perform the operation. That way you can have a hope of tracking it down and optimizing it away if at all possible.
User Load (0.2ms) views/main_page.rb:107:in `filters_box' SELECT * FROM `users`
Code after the jump. I guess you put it in environment.rb with all the other monkeys.
[Update: 10/15/07 - incorporated changes by David Vrensk (and a few more from me). Now it merges in associations into the arc, and also deals with inheritance (e.g. STI).]
While googling for articles on Rails associations, I happened upon this gem of a script by Matt Biddulph. I loved it so much I made it a rake task! Once you install GraphViz like this:
sudo port install graphviz
and put dot.rake in your lib/tasks directory, then running this:
rake dot
produces diagrams like this:
And you can also import the DOT source into OmniGraffle for further editing, like this:
open -a "OmniGraffle" model.dot