Entries from February 2008 ↓

Overriding Time.now to Control the Server Time

I just recently worked on a project in which I needed to modify what time the Ruby on Rails server thought it was. I was able to change this very easily with the help of court3nay while on #rubyonrails.

def Time.now
  Time.parse("2010-02-30", nil)
end

With this I am able to change the server time whenever I want! The system was one in which user interface capabilities changed at different times of the month. Obviously I didn’t want to wait 20 days to see something different!

I placed this code snippet in my config/environments/development.rb file so that everything in my application could access it, and it wouldn’t affect the test or production environments. The only downside to this is that you have to restart the server in order to change the time. Of course, in RoR this takes like 5 seconds so it was no big deal for me.

In my specs I used stuff like

date = "2008-01-01"
Time.stub!(:now).and_return(Time.parse(date))

which of course made it very easy to write effective specs that covered all of my functionality. Thank you RSpec!

Voila, now you too can control time!!

Persistent Instance Variables in Ruby on Rails

I just recently built a rake task in my project where I wanted to loop through a list of Users, queue up some data for each one, then loop back through them again to process the data that had been queued. I didn’t need the data to live for very long, but I needed it for 2 separate requests.

The problem with this is that in Ruby on Rails, instance variables are not persistent across requests. This means their scope is limited to one usage of an object and the next time you call for that object, the variable is gone.

Unfortunately, the only solution I could imagine for my problem without persistent instance variables was to create a massive join table to connect my generated data between Users. Not only would this have been a lot of work, it would have been a big waste considering the data would have only lived for about a minute as the rake task was executed.

I wanted to improve/increase the scope of instance variables, and so my solution was to take advantage of Class Variables.

At the bottom of my User class, I now have the following:

  protected
    def late_employees
      @@late_employees ||= {}
      @@late_employees[self] ||= {}
      @@late_employees[self]
    end
    
    def late_team_members
      @@late_team_members ||= {}
      @@late_team_members[self] ||= {}
      @@late_team_members[self]
    end
    
    def clear_late_emails
      @@late_employees[self] = {}
      @@late_team_members[self] = {}
    end

As you can see, each element of the Class Variable hashes are referenced by the current instance. So when I call u.late_employees, it’s always the same across requests until either I call u.clear_late_emails or the server dies.

To use them, just treat them like any normal instance method/variable. Here is an example of how you can do that:

def employee_late(user, days)
  if user.manager == self
    late_team_members[user] = days
  else
    late_employees[user] = days
  end
end

def has_late_employees?
  !(late_employees.empty? and late_team_members.empty?)
end

def send_late_employee_emails
  if has_late_employees?
    EvaluationNotifier.deliver_late_employee_notification(self)
  end
  
  length = late_employees.length + late_team_members.length
  clear_late_emails
  
  length
end

Voila, instance variables that are persistent across requests!

Deploying Ruby on Rails with Capistrano on DreamHost

When I set up my latest application on DreamHost, I had a real pain of a time. Most of the references I found for help were written in 2006 and referred to outdated commands. Since top Google results for “dreamhost capistrano ruby on rails” are mostly no longer adequate, I hope to help out anyone else who finds themselves in my shoes!

I first got good help from this resource at Rubynoob which references the Dreamhost Capistrano Wiki article.

With those two links and a bit of help from me, you should be all set. To make things quick, let me summarize the key points:

  • Set up your app with Fast-CGI enabled
  • Set up your own RubyGems following this resource
  • Also check out this resource for general Ruby on Rails + DreamHost concerns
  • “cap –apply-to .” is now “capify”
  • Download my deploy.rb file or read from it below for good explanation of what most of the items do.
  • Set up your processes as shown below
  • Make sure every file in your /script folder has the first line: #!/usr/bin/env ruby
  • Make sure every file looking like /public/dispatch* has the first line: #!/usr/bin/env ruby

My deploy.rb file:

# The host where people will access my site
set :application, "test.gamelizard.com"
set :user, "my dreamhost username set to access this project"
set :admin_login, "my admin login name"

set :repository, "http://#{user}@svn.gamelizard.com/rgamelizard/trunk"

# If you aren't deploying to /u/apps/#{application} on the target
# servers (which is the default), you can specify the actual location
# via the :deploy_to variable:
set :deploy_to, "/home/#{admin_login}/#{application}"

# My DreamHost-assigned server
set :domain, "#{admin_login}@ajax.dreamhost.com"
role :app, domain
role :web, domain
role :db,  domain, :primary => true

desc "Link shared files"
task :before_symlink do
  run "rm -drf #{release_path}/public/bin"
  run "ln -s #{shared_path}/bin #{release_path}/public/bin"
end

set :use_sudo, false
set :checkout, "export"

# I used the handy quick tool to set up an SVN repository on DreamHost and this is where it lives
set :svn, "/usr/bin/svn"
set :svn_user, 'my svn username'
set :svn_password, 'my svn password'
set :repository,
  Proc.new { "--username #{svn_user} " +
       "--password #{svn_password} " +
       "http://svn.gamelizard.com/rgamelizard/trunk/" }

desc "Restarting after deployment" 
task :after_deploy, :roles => [:app, :db, :web] do
  run "touch #{deploy_to}/current/public/dispatch.fcgi" 
  
  run "sed 's/# ENV\\[/ENV\\[/g' #{deploy_to}/current/config/environment.rb > #{deploy_to}/current/config/environment.temp" 
  run "mv #{deploy_to}/current/config/environment.temp #{deploy_to}/current/config/environment.rb"
end

desc "Restarting after rollback" 
task :after_rollback, :roles => [:app, :db, :web] do
  run "touch #{deploy_to}/current/public/dispatch.fcgi" 
end

My script/process/reaper file:

#!/usr/bin/env ruby
require File.dirname(__FILE__) + '/../../config/boot'
require 'commands/process/reaper'

My script/process/spawner file:

#!/usr/bin/env ruby
require File.dirname(__FILE__) + '/../../config/boot'
require 'commands/process/spawner'

The permissions in the script/process folder should look like:

-rwxr-xr-x  1 Malohkan  staff  108 Jan  7 19:06 reaper
-rwxr-xr-x  1 Malohkan  staff  109 Jan  7 19:06 spawner

If they look like “-rwxr-xr-x@” as can happen on a Mac you’ll want to kill the file and re-create it with the same content. I think this happens due to copying files and is representative of the notion that only the current logged-in user can access that file. As a result, when Capistrano deploys the file, it will not have permission to run it.

If you have other issues or concerns that are not addressed here, please leave a comment and I’ll do my best to help further!

If you don’t like the trouble caused by dealing with Ruby on Rails on DreamHost, check out this article for some ideas of good alternatives!