Using validates_presence_of on a boolean field? Should use validates_inclusion_of!

rsvp.theoandpat.com had boolean flag to marked whether or not a visitor was going to be able to make it to our wedding. Unfortunately, if you selected you were not able to make it and submit the form, the application would return saying it could not process your submission because you have to say that you are going to make it. I argued, this is an RSVP form so you have to accept if you are RSVPing. That’s the point of the RSVP! Only people RSVP would bother submitting the form!  Pat wasn’t too happy about that and ask/told me to fix it. 

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]
Using validates_presence_of on a boolean field? Should use validates_inclusion_of!

Rails initial request slow with mod_rails

Following up on my previous post , I’ve been experience slow load times (10-15 secs) on the initial request after application restarts. This has to do with the way mod_rails manages application instances (Although, I experienced this when using mongrel_cluster and proxy balancers). It will spin up instances on page request and each instance has an idle timeout. This just means after the timeout expires, mod_rails will shutdown that instance to conserve memory allocation. While you can change timeout value (see PassengerPoolIdleTime), this will only cause all instances that get spin up to live longer. After high load times, these instances will stick around longer than neccessary.

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.

Rails initial request slow with mod_rails

Setting up Phusion Passenger (mod_rails) with Capistrano support

I had heard of mod_rails awhile back but never had the time to take a closer look at it. While setting up a new rails app, I was getting frustrated with all of the configuration I needed to do to get the mongrel clusters and proxy balancers setup. So I decided to give passenger a chance. I’m a fan now 🙂

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.

Setting up Phusion Passenger (mod_rails) with Capistrano support

Where is my sequel sock?

I was looking for where mysql.sock was since running rake db:bootstrap was complaining with “No such file or directory – /tmp/mysql.sock”. Rails looks for the mysql.sock file under /tmp/mysql.sock by default. Ubuntu using an apt-get install of mysql puts the mysql.sock file at /var/run/mysqld/mysqld.sock.

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
Where is my sequel sock?

Ruby: ! versus not operator

I was writing some code in an erb template that looked like this:

<% 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 -%>
Ruby: ! versus not operator

Breaking Java Habits: Ruby increment/decrement operators

My background in C++ and Java has instilled in me some programming habits that don’t play nice in Ruby. When I want to increment or decrement a number, my fingers instinctively go to ‘++’ and ‘–’’.

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.

Breaking Java Habits: Ruby increment/decrement operators

Autocomplete in Rails 2.0

I’ve been trying out the newly released Rails 2.0. Lots of cool new stuff. However, it takes some time to get used to doing things the new way if you haven’t been working from EdgeRails.

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 :only => [: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.

Autocomplete in Rails 2.0

Mongrel + Apache = rails.notedpath.com

After fighting apache for a couple hours, I finally have mongrel set up to proxy through apache.

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!

Rails - Hello, World!

Mongrel + Apache = rails.notedpath.com

I need mod_proxy_balancer?

I have been trying to get a rails app served up by a mongrel cluster through apache. All the documentation I’ve looked at says this can be done with an Apache module mod_proxy_balancer. Looks like my apache install using apt-get does not come with that module. Blah! Guess I have to pull down the source and build from source. Hopefully, I don’t break anything!

References:

I need mod_proxy_balancer?

Apache, Tomcat, Rails

It was easier than I thought it would be to install Java and Tomcat. With a few apt-get commands, I had both Java and Tomcat up and running. The next step was to serve Tomcat through Apache. This was done by using the AJP Connector. Tomcat is running with AJP connector port 8009 and I can serve up JSPs and servlet content through Apache who is listening on port 80. Pretty slick 🙂

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.

Apache, Tomcat, Rails