Override default find conditions for model

Here is a little trick I use when I want to override a find method for a model, instead of adding the conditions option to my association. While I don’t think you should avoid using the conditions options in your associations, this will provide an alternative:

class ModelName < ActiveRecord::Base
  def self.find(*args)
    with_scope(:find=>{ :conditions=>LIMIT_CONDITION }) do
      super(*args)
    end
  end
end

Basically what is happening, is that you are overriding the default find function for a model, and wrapping its own find method with a with_scope call. So now every time you call Model.find(:all) or whatever options you want, it will execute it under that scope, with the conditions you specify.

Rails Log Analyzer (RAWK)

Came across a sweet rails log analyzer. Doesn’t require that you use syslog or anything like the other log parsers that are out there. This one will work right on your development or production log files. Its called RAWK and you can find it here: http://rubyforge.org/frs/?group_id=2517&release_id=15246

Application Error – Rails application failed to start properly

If you’re like me at all, you have run into this issue many times trying to upload your favorite Rails app to your webhost. This can be a very annoying and painful process if you do not understand what is going on exactly so I am going to outline a few tips to follow when attempting to release your new app, and if those tips do not work, I have my final tip that is actually quite useful. Here is my checklist:

  • Uncomment ENV[‘RAILS_ENV’] ||= ‘production’ in environment.rb
  • log and tmp directories have CHMOD 777 access.
  • ALL dispatch files in the public directory are CHMOD 755 at least.
  • Make sure the RAILS_GEM_VERSION is set to something installed on the server.
  • If you have unpacked any custom gems, make sure your app is loading them properly.
  • Make sure any gems you are using are installed on the server.
  • Make sure database.yml file is pointed to correct database.

These usually get the job done, and if you still have issues, feel free to comment here and I’ll try and help. One thing I have done in that past that helps out really well is to use a “skeleton” app. Basically what I do is the following:

  1. Run rails <appname>_skeleton where your actual app is going to run. This is the app that your domain name will actually use.
  2. Upload the app your working on to some directory on your host.
  3. The key part is here. You are going to symbolically link folders from inside your skeleton app and the folders you would like to do are:
  • app
  • config (Sometimes I link everything inside except the database.yml file and manage it only on the host)
  • db
  • lib
  • test
  • vendor
  • Everything inside public folder except the dispatch files.

This has come in very useful for me as I do not have to worry about permissions on the dispatch files everything I svn up the public directory and my logs are contained by them self. I can also go into my actual app(not the skeleton one) and just run an svn up. You may have to work with the links a little bit to get it working. If anyone has any comments on this idea or improvements, I would love to hear them.