Digging into it, it turns out the way  for validates_presence_of relies on Object#blank which of course when sent

false.blank? # returns true

Reading up on the documentation, it is suggested to use validates_inclusion_of when dealing with booleans.

The one line change solved the problem:

validates_inclusion_of :accepted, :in => [true, false]

For low traffic sites (like mine), this idle timeout may be reached causing the next visitor to our website to experience a really long delay before page load. What we really want is an option to set a minimum number of instances. This would allow us to automatically spin up an instance during start up and keep it around. Unfortunately at this time, it doesn’t look like there is a way to set this.

As a workaround, I’ve setup a crontab that makes a request to my application every 5 minutes to prevent mod_rails from killing off all application instances.

To do this just run:

crontab -e

And then specific the following cron

*/5 * * * * wget -O /dev/null http://www.myapp.com 2>/dev/null

You can verify this is working correctly but just tailing your application logs and verify every 5 minutes you get a request.

You can also run

 passenger-status

You should see at least the count variable to be at least 1 instance.

Note, this workaround will not immediate start up an instance upon restart. You can add an initial request as part of your post deploy capistrano task though. You probably should be making sure your application is up after deploying or restarting the application anyways.

The process was dead simple.

1. Install the passenger gem

   sudo gem install passenger

2. Install passenger as an Apache module

   passenger-install-apache2-module

3. Load the passenger apache module by editing the Apache config

   LoadModule passenger_module /usr/lib/ruby/gems/1.8/gems/passenger-2.0.5/ext/apache2/mod_passenger.so
   PassengerRoot /usr/lib/ruby/gems/1.8/gems/passenger-2.0.5
   PassengerRuby /usr/bin/ruby1.8
   

4. Restart Apache

If all things went well, you have everything installed you need. If there were some missing dependencies, you should be presented with how to install those dependencies.

In the installation output, it tells you how to mod_railsify your apps by creating a vhost as such:

<VirtualHost *:80>
    ServerName www.mywebsite.com
    DocumentRoot /home/deploy/mywebsite/public
</VirtualHost>

That’s it! No more of this proxy balancer and mongrel_cluster.yml configuration.

There’s some magic going on in the background. As requests come in, passenger will spin up more application instances. For more tweaking your configuration options check out the user guide.

Go to your website and you should see your rails app up and running.

So now we have your app up and running, how do we update or restart our app? Passenger provides two ways for us to do this.

The first is whenever apache is restarted, your application is restarted.

The second way allows us to restart a specified application without affecting Apache. Whenever passenger detects tmp/restart.txt, it will restart the application instances for us. We can integrate this into our Capistrano deploy flow by adding the following our config/deploy.rb

namespace :passenger do
  desc "Restart Application"
  task :restart do
    run "touch #{current_path}/tmp/restart.txt"
  end
end

after :deploy, "passenger:restart"

This will create that restart.txt after the cap:deploy task gets executed, causing the application to restart.

Finally, passenger comes with some pretty useful utilities.

Check out passenger-status which produces output showing current passenger server statuses.

Sample output:

----------- General information -----------
max      = 6
count    = 1
active   = 0
inactive = 1
Using global queue: no
Waiting on global queue: 0

----------- Applications -----------
/home/deploy/www.myapp.com/releases/20081206183156:
  PID: 30784     Sessions: 0

Another utility passenger-memory-status gives you insight into how much memory is being used by apache and passenger.

Sample output:

-------------- Apache processes ---------------
PID    PPID   Threads  VMSize    Private  Name
-----------------------------------------------
12841  1      1        225.9 MB  0.0 MB   /usr/sbin/apache2 -k start
28294  12841  1        248.4 MB  21.4 MB  /usr/sbin/apache2 -k start
28300  12841  1        243.7 MB  0.5 MB   /usr/sbin/apache2 -k start
28306  12841  1        248.4 MB  4.4 MB   /usr/sbin/apache2 -k start
28357  12841  1        249.1 MB  19.8 MB  /usr/sbin/apache2 -k start
29400  12841  1        249.4 MB  3.7 MB   /usr/sbin/apache2 -k start
29788  12841  1        249.3 MB  21.7 MB  /usr/sbin/apache2 -k start
29834  12841  1        245.8 MB  18.9 MB  /usr/sbin/apache2 -k start
29836  12841  1        245.8 MB  9.3 MB   /usr/sbin/apache2 -k start
29868  12841  1        245.8 MB  2.4 MB   /usr/sbin/apache2 -k start
29870  12841  1        246.5 MB  5.2 MB   /usr/sbin/apache2 -k start
### Processes: 11
### Total private dirty RSS: 107.44 MB

--------- Passenger processes ----------
PID    Threads  VMSize    Private  Name
----------------------------------------
28031  10       15.3 MB   0.1 MB   /usr/lib/ruby/gems/1.8/gems/passenger-2.0.5/ext/apache2/ApplicationPoolServerExecutable 0 /usr/lib/ruby/gems/1.8/gems/passenger-2.0.5/bin/passenger-spawn-server  /usr/bin/ruby1.8  /tmp/passenger_status.12841.fifo
28032  2        48.7 MB   0.6 MB   Passenger spawn server
29161  1        114.8 MB  0.7 MB   Passenger FrameworkSpawner: 2.1.2
30461  1        122.8 MB  32.3 MB  Passenger ApplicationSpawner: /home/deploy/www.myapp.com/releases/20081206183156
30784  1        129.3 MB  33.4 MB  Rails: /home/deploy/www.myapp.com/releases/20081206183156
### Processes: 5
### Total private dirty RSS: 67.08 MB

Pretty sweet.

I always forget where it is. So, I’m writing it down.

/var/run/mysqld/mysqld.sock

You can also grep for it from mysql like so

>>  mysql -? | grep mysqld.sock
socket                            /var/run/mysqld/mysqld.sock

<% if @user && not @user.errors.empty? -%>
#do stuff
<% end -%>

This resulted in a syntax error. Huh? What’s wrong with this?

Turns out it’s an outstanding Core Ruby bug.

As shown in the ticket if we have a method foo

def foo(parameter)
  puts parameter.to_s
end

using the ! and the not operator on various method calls show us that the ! and not operator are not interchangeable in practice.

foo(!(1 < 2)) # works fine
foo(not(1 < 2)) # generates syntax error
foo(not 1 < 2) # generates syntax error
foo((not 1 < 2)) # works fine

Changing the my code to the following fixed my issue:

<% if @user && !@user.errors.empty? -%>
#do stuff
<% end -%>

Unfortunately, this syntax is not supported by Ruby. As a language design choice, Ruby opted to not support this syntactic sugar to increment/decrement a variable.

I will have to break my habit and start going with:

// increment x
x+=1
// decrement x
x-=1

Another thing to note is that the prefix increment/decrement operators like ‘–x’ or ‘++x’ do nothing. The signs are interpreted as unary operators.

One of the features that came out of the box in previous releases was support for autocomplete using scriptaculous. This has now been moved from the core rails install to an install via plugin.

Just install the plugin via:
script/plugin install http://svn.rubyonrails.org/rails/plugins/auto_complete

Then, you have to turn off the cross-site request forgery protection that comes with Rails 2.0.

You can do this at the Controller level by adding something similar to the following:

class UsersController < ApplicationController
protect_from_forgery  nly => [:update, :delete, :create] // exclude the auto_complete method
...
end

If you don’t do this, your autocomplete actions will throw an ActionController::InvalidAuthenticityToken exception which caused me hours of confusion.

At first I had the proxy module enabled but was getting a 403 page. After adding logging to the vhost config, I see

[Mon Sep 10 22:57:00 2007] [warn] proxy: No protocol handler was valid for the URL /. If you are using a DSO version of mod_proxy, make sure the proxy submodules are included in the configuration using LoadModule.

I go ahead and find out I didn’t have proxy_http enabled. After executing sudo a2enmod proxy_http and bouncing apache, TA-DA!

References:

• Mongrel: Apache
• Deploying Rails on Ubuntu
• Time For a Grown-Up Server

It was even easier to get a Rails app up and running on WEBrick on default port 3000.

Next steps will be to serve Rails content through Apache.