To use helpers with email templates specify in the model the helpers you want to use.

class FooMailer < ActionMailer::Base

  helper :Foo, :Application

For text fields one typically wants to allow some HTML tags, add support for link breaks and even auto link URL’s and emails.

This method which I got from this forum thread, Adding a line break … safely, does all of this and is a must add to my application_helper.rb.

def format_content(content)
  # allow only tags specified in tags options, likewise in attributes
  content = sanitize(content, :tags => %w(b strong i em img), :attributes => %w(src))

  # add support for line breaks
  content = simple_format(content)

  # auto link URL's and emails
  content = auto_link(content, :all, :target => '_blank')

  return content
end

Recently I tried running my RoR applications on Oracle.

I noticed that when I ran rake db:migrate it would hang. Specifically it would hang during the schema dump phase.

E:\work\sandbox>rake db:migrate --trace -v
(in E:/work/sandbox)
** Invoke db:migrate (first_time)
** Invoke environment (first_time)
** Execute environment
** Execute db:migrate
** Invoke db:schema:dump (first_time)
** Invoke environment
** Execute db:schema:dump

I realized later that this was because the schema dump phase is very slow and the database I was using had many other tables from other applications. When I left it running it finally completed after 10 minutes.

You can see the slow progress of the schema dump phase by tailing schema.rb in the db directory.

Twitter has become the poster child of why not to use Ruby on Rails.  Recently a friend of mine started a company and when I noticed he used PHP I asked why he didn’t use Rails.  He responded “Twitter uses Rails and they keep going down.  Facebook uses PHP.  We’ll use PHP.”

There is an interesting interview w/ Twitter developer Alex Payne about the issues Twitter has had with Ruby on Rails.

The common wisdom in the Rails community at this time is that scaling Rails is a matter of cost: just throw more CPUs at it. The problem is that more instances of Rails (running as part of a Mongrel cluster, in our case) means more requests to your database. At this point in time there’s no facility in Rails to talk to more than one database at a time. The solutions to this are caching the hell out of everything and setting up multiple read-only slave databases..

All the convenience methods and syntactical sugar that makes Rails such a pleasure for coders ends up being absolutely punishing, performance-wise. Once you hit a certain threshold of
traffic, either you need to strip out all the costly neat stuff that Rails does for you (RJS, ActiveRecord, ActiveSupport, etc.) or move the slow parts of your application out of Rails, or both.

It’s also worth mentioning that there shouldn’t be doubt in anybody’s mind at this point that Ruby itself is slow. It’s great that people are hard at work on faster implementations of the language, but right now, it’s tough. If you’re looking to deploy a big web application and you’re language-agnostic, realize that the same operation in Ruby will take less time in Python. All of us working on Twitter are big Ruby fans, but I think it’s worth being frank that this isn’t one of those relativistic language issues. Ruby is slow.

In April 2007, former Chief Architect Blaine Cook made a presentation called Scaling Twitter.  It’s a well done presentation, even if everything is black.

In May 2008 there were rumors that Twitter was abandoning Rails.  SitePoints believes it is not a framework issue but rather an architectural issue that is causing Twitter’s problems.

There are many large sites that run Rails well and many smaller ones that do not.  It seems like another case of the “leaky abstraction” where we have such a nice framework that we think we can abstract away issues like scaling but in the end when the site becomes big enough we have to look under the covers.

Ruby has been documented to have I/O issues and general performance issues.  Like PHP before it looks like Ruby needs to mature more and deal better with scaling and I/O issues.  I am confident though this will happen because of the tremendous momentum of Ruby on Rails.  However I am keeping on eye on Django, especially now that Google has thrown its large hat into Django’s ring.

Today I took the plunge and installed Rails 2.0.2. Notes on the Rails 2.0 release can be found here.

Here are the steps I took.

1. Upgrade Ruby Gems to the latest version (in this case 1.0.1).
   gem update --system
2. Install Ruby on Rails 2.0.2.
   gem install rails -v 2.0.2
3. Install MySQL gem (as of March 5, 2008, it is version 2.7.3) and add MySQL executable to path.
   gem install mysql
4. Create prayer application.
   rails prayer -d mysql
5. Install Restful Authentication plugin.
   cd prayer
ruby script/plugin install http://svn.techno-weenie.net/projects/plugins/restful_authentication/
6. Create scaffold for prayer model.
   ruby script/generate scaffold Prayer title:string body:text

   The first thing I noticed different about Rails 2.0 is that the scaffold now also generates the model and data migration file with title and body as columns in the prayer table. Also the format of the data migration file is slightly more compact.
7. Create user model with authentication. The --include-activation flag is to create the mailers for activation and signup notification.
   ruby script/generate authenticated user sessions --include-activation
8. Configure config/database.yml and then create prayer and user tables in DB.
   rake db:migrate
9. Configure SMTP settings.
10. Modify app/models/user_mailer.rb, replacing the place holders with constants which you can configure with different values for different environments using config/environments/development.rb, config/environments/production.rb.
11. Modify user_observer.rb to incorporate the reset and forgotten password features.
12. Create scaffold for role model. Add an admin user.
    ruby script/generate scaffold Role rolename:string
13. Create permission model. Modify role and permission models to know about each other.
    ruby script/generate model Permission
14. Modify user model to use permissions.

Much of this post is based on this excellent post, Restful Authentication with all the bells and whistles.  At this point I did not continue with much of the tutorial, especially with parts like password forgotten, separate account controller, etc.

I tried to update the restful_authentication plugin by doing this.

$ ruby script/plugin update restful_authentication

Unfortunately it didn’t do anything.

I know I don’t have the latest version because in another project I pulled down the latest restful_authentication code and it was different.

To get around this I forced an install with the latest code.

$ ruby script/plugin install -x \
    http://svn.techno-weenie.net/projects/plugins/restful_authentication/

Fortunately I received an answer about this on the rails mailing list. Apparently update only works if the plugin is in svn:externals. To do this you would install it with the -x flag (see list of flags by doing ruby script/plugin install -h’).

However if you try this with the restful_authentication plugin you’ll see this.

$ ruby script/plugin install -f \
    http://svn.techno-weenie.net/projects/plugins/restful_authentication/
Cannot install using externals because this project is not under
subversion.