Category: Technical

A while back, I wrote a little rails app for Thai food ordering at my work. My colleagues place orders using the system and then bring money to the nominated orderer of the week. Once all orders are in and paid for (this is also tracked in the app), the orderer rings up our favourite Thai restaurant (Laddas) and places the order.

I have the app running from fairly cheap shared hosting. At peak times during the ordering, I guess that they’d be 15 or so people simultaneously using the app. We’ve used it many times without problems. Thus, I was quite surprised and displeased (as were my colleagues), when my hosting account was suspended and we couldn’t see what had been ordered this morning. A hasty email to my hosting provider revealed that my account had been suspended due to high load and “ruby flooding”. They were kind enough to un-suspend my account and we completed the ordering process.

I remembered seeing something about production mode in ‘environment.rb‘. Some googling confirmed my hunch – in development mode, rails apps are much more resource intensive. Caching is not used, and every single file needs to be reloaded every time it is required. After changing my app to production mode, it seemed to run noticeably faster. Michael and I ran ‘top’ and it looked like each request used less CPU.

So, should you be in a similar situation, this is how to change your app to production mode on fast-cgi Apache shared hosting:

1. Confirm that ‘database.yml‘ in your app’s ‘config‘ directory has a section for production mode, and that it has up to date database connection details.
2. Edit ‘environment.rb‘ in your app’s ‘config‘ directory.
3. Add this line:

        ENV['RAILS_ENV'] ||= 'production'

4. Run ‘ps -u [your_user_name]’ to find if you have any ‘dispatch.fgi‘ processes running.
5. If so, kill all of them (they’ll restart and use your new config settings).
6. Browse to your app, it should now run faster.

I spent a bit of time this weekend on a pet rails project. I came across a strange error when trying to create new records through the application. Editing was working just fine, but creating a new record just seemed to hang.

Breakpoints came to my rescue. In Ruby, they’re really handy. You can put a ‘breakpoint’ call anywhere in your code, and if you have a breakpointer process running (start this with the command ‘ruby script/breakpointer’), you jump straight into an interactive ruby console debug session when the breakpoint is hit.

Using the development log and a few breakpoints, I found the that the error was:

ArgumentError: wrong number of arguments (1 for 0)

And that it was caused by a line similar to this:

@order = order.new(params[:order])

Ie, the controller was creating a new order from the post parameters.

Then all became clear – some time earlier, I’d overridden the initialize() method in the order to default some dates. My code was similar to this:

def initializesuper()
  if (@new_record)
    self.validFrom = Date.today
    self.validTo = 1.year.from_now.to_date
  end
end

Great for creating new objects in my tests and console sessions where I always just created the object and then set properties. However, the controller was relying on passing in the post parameters in the constructor.

The solution is to accept any number of params and pass these to the base class:

def initialize(*params)super(*params)
  if (@new_record)
    self.validFrom = Date.today
    self.validTo = 1.year.from_now.to_date
  end
end

That way, the order can accept the post parameters in its constructor.

I’m very pleased to say that I can now create new records again!

I’ve been doing a little rails of late.. Here’s a summary of the stuff that I’ve learnt.

What hosting should I use in Australia for rails?

NOT JUMBA – SEE UPDATED REVIEW BELOW

I’m using jumba (http://www.jumba.com.au). Jumba is very cheap (~$30AUD/year), and they give you shell access, mysql etc. However, there was a period of several weeks when they moved me to some server without an install of rails and kept promising to install rails and never did. I finally got them to move me back to their main server which has rails installed. It was a painful process, so I’m not sure if I would recommend them. That being said, things are going OK at the moment, and I’ve got a few development apps up and running on their service.

UPDATE 29 March 2006: Jumba summarily stopped rails support without notice and was rude when I contacted them about it. I would not recommend Jumba for web hosting anything – they have frequent down time, server switches and reboots and their low price is made up for by the amount of time you waste. They used to be OK, but no longer. I’m in the market for a new host, will post on how it goes.

How to set up rails applications in your home directory (in public_html) under a UNIX/Apache/cgi/fcgi environment

1. Upload or create your application in your home directory. Eg, ~/MyRailsApp/
2. In your public_html directory, create a soft link to the public directory of your app. Eg,
   ln -s ~/MyRailsApp/public ~/public_html/MyRailsApp
3. Make sure dispatch.fcgi in the ~/MyRailsApp/public directory is executable. If not, chmod it a+x.
4. Confirm that dispatch.fcgi has a valid path to ruby on the first line. If you’ve created this project on another machine, you’ll quite possibly need to update the path. The path is often something like ‘#!/usr/local/bin/ruby’, but check what it is under your system with ‘which ruby’. Special note for InstantRails users – you’ll always need to update the path when uploading to unix hosting, as instant rails uses a windows style path with the slashes the other way around.
5. Update your ‘database.yml‘ file (in the ‘config‘ directory of your app) with correct database names, user names and passwords.
6. Run ‘dispatch.fcgi‘ (in the ‘public’ directory of your app). If you see an ‘Internal Server Error’ message, you know things are going OK. If you’ve got the path to ruby wrong on the first line, or some other similar problem, you’ll find out about it here, where as if you run through the web, you don’t get these sorts of problems reported in an easy to understand way.
7. Check out your running system in the browser (eg, browse to http://myhostingcompany.com/MyRailsApp/)

Tips for trouble shooting rails errors

1. A good place to start is by reading your logs in the ‘log’ directory of your rails app. If you’re running a development configuration, have a read of ‘development.log’.
2. Try manually running ‘dispatch.fcgi‘ in the ‘public’ directory of your app. If you get an ‘Internal Server Error’ message printed out on the console, it’s probably working ok. Alternatives to this are reports of missing files and unable to find ruby – often these aren’t shown when browsing to your web site.

Rails problems and solutions

1. Browser and logs show: Application Error – Rails app failed to start properly ”

I got this after my app was moved from one unix host to another by my hosting company. I tried heaps of stuff to try and resolve this. Eventually I created a brand new dummy project on the unix host called ‘Test’ and Test worked fine from the browser. I then tried my original project again and suddenly it worked fine! It has been working fine since. I can only imagine that there was some sort of problem in temporary files or similar which got flushed. No good explanation for this currently.

2. in `start_engine’: undefined method `add_path’ for Controllers:Module (NoMethodError)

I got this one when migrating a project from rails 1.1 to a later version of rails. The solution is to force update your rails engines:

script/plugin source http://svn.rails-engines.org/plugins
script/plugin install engines –force
script/plugin install login_engine –force

3. My app works fine if there is a trailing slash on the url. Otherwise, I get a ‘Bad Request’ error page. Eg, ‘http://myhost.com/myapp/’ works, but ‘http://myhost.com/myapp’ does not work.

Add a RewriteRule to the .htaccess file in your application’s public folder:
RewriteRule ^.*myapp$ http://%{HTTP_HOST}/myapp/ [R=301,L]

My basic .htaccess rewrites are as follows:
RewriteEngine On
RewriteRule ^.*myapp$ http://%{HTTP_HOST}/myapp/ [R=301,L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ dispatch.fcgi [QSA,L]

I tried removing the RewriteCond !-f, and my pages lost their styles. I think the condition allows the rails framework to load .css files directly without having the requests go through dispatch.fcgi.