The curse of the spreadsheet!

Note: The RichText blog has moved to www.ricroberts.com

I recently wrote about the misuse of spreadsheets on the Swirrl blog.

Spreadsheets are great for some tasks. People love the informality, the flexibility and the instant results: in skilled hands, they can be very powerful. But “when all you have is a hammer, everything looks like a nail”... Read the full article.

Swirrl on Rails

Note: The RichText blog has moved to www.ricroberts.com

Just a quick announcement about the current rails project I'm working on:

It's called swirrl and you can read about it here.

Handling Errors in Ajax & Rails

Note: The RichText blog has moved to www.ricroberts.com

A while ago, I was wondering how I should deal with errors that are encountered in rails controllers, while processing an Ajax request. I played around with some alternatives and eventually came up with one that has been working great for a few months, so I thought I'd share it.

You've probably all heard of overriding 'rescue_action_in_public' in your ApplicationController to deal with errors. (See simple example below).

def rescue_action_in_public(exception)
  # render the error page.
  render :file => "public/error.html"
end

This works great in regular methods, but what if something happens in an ajax request?

If you take no action, then the controller will fail 'silently' (well, some stuff appears in the log, but the user is unaware).

The way I got around this was to add a method to the ApplicationController, similar to that below (irrelevant code stripped out, so apologies if this code has a typo!).

  def perform_ajax_action
    
    if block_given?
      begin
        if (request.xhr?)
          yield
        else
          raise RuntimeError.new('Not in an ajax request!')
        end
      rescue Exception => error
        logger.error("#{Time.now}: Error performing ajax action: #{error.inspect}")
        logger.error(error.backtrace.join("\n"))
        ajax_aware_redirect_to "/error.html"
      end      
    else
      logger.error("perform_ajax_action called with no block!");
      ajax_aware_redirect_to "/error.html"
    end
    
  end

(You were probably wondering what this 'ajax_aware_redirect_to' business is all about. It's just another method in the ApplicationController which helps with redirecting during ajax processing. It looks a bit like this: Again, irrelevant stuff removed.)

  def ajax_aware_redirect_to(options = {}, *parameters_for_method_reference)
    if request.xhr?
      render :update do |page| 
        page.redirect_to( options, *parameters_for_method_reference) 
      end
    else
      redirect_to( options, *parameters_for_method_reference)
    end
  end

Now, in order to get this to catch your errors, you need to add an :around_filter to your controller. e.g.

class MyController < ApplicationController
  
  around_filter :my_around_filter, :only => [:my_action]
  
  # controller code here....

  def my_around_filter
    perform_ajax_action do
      # do other useful stuff here if you like.
      # in an 'around filter' yield calls the method wrapped in the filter
      yield
    end
  end
end

MySQL Temporary Tables and Rails

Note: The RichText blog has moved to www.ricroberts.com

According to the Rails documentation, all active record classes by default use the same database connection.

As the Agile Web Development With Rails book rightly says, Ruby on rails is not thread safe (2nd Edtn p 649). A Mongrel server uses one thread per request (i.e. multithreaded), but is synchronised around the calls to Dispatcher.dispatch. This means that everything is threaded right before and right after Rails runs. While Rails is running there is only one controller in operation at a time. This is why people typically have to run a small set of Mongrel processes (a “Pack of Mongrels”) to get good concurrency (from Mongrel FAQs).

MySQL temporary tables are only visible inside the connection from which they are created, and they are automatically dropped when the connection is dropped (see the MySQL docs). Along with the above, this means that any rails active record class will be able to see temporary tables created by other active record classes (within the same server process).

However, since only one controller operation is running at a time within each server process (and therefore only one for each connection), I think you can safely do the following in a rails active record model class if you want to use temporary tables:

begin
  connection.execute("DROP TEMPORARY TABLE IF EXISTS my_temp_table")
  connection.execute("CREATE TEMPORARY TABLE my_temp_table")
  # do stuff with temp table here
ensure
  # this drop is here to help keep the size of the data base down 
  # between calls to this method
  connection.execute("DROP TEMPORARY TABLE IF EXISTS my_temp_table")
end

NetBeans Intervenes

Note: The RichText blog has moved to www.ricroberts.com

Regular readers of this blog will know that I'm not averse to trying new IDEs for my rails development.

I recently came across this post by George Cook about an app I hadn't considered.... NetBeans.

George does a great job of explaining NetBeans's virtues, so I won't repeat them all here, but to sum up, it does everything I need a rails IDE to do plus a little bit extra. The most impressive feature for me is the in-IDE fast debugging (more on how to set this up below).

NetBeans does have it's down points. With its default settings it doesn't look as slick as TextMate, but after some fiddling around with the preferences you can rectify this. It does use more memory than TextMate but even on my MacBook with 1GB RAM and lots of other applications open, I still have a little bit free. Besides, compared with something like Microsoft Visual Studio 2005 (which eats RAM for breakfast) NetBeans is a veritable size zero.

There is a ruby-only build of NetBeans available which helps to keep the memory footprint down. The exact version I installed was build 3533, which seems to work fine.

UPDATE (26 Sep 07): Netbeans 6 Beta 1 is now out! Get it from the Sun web-site.

Getting started with NetBeans

Here are few quick pointers to get you going.

To begin, all you have to do is do:
-> File -> New Project
.. and then choose "Ruby on Rails Application with Existing Sources"
and browse for your rails folder.

You need the ruby-debug-ide gem installed (sudo gem install ruby-
debug-ide) to do fast debugging.

Before trying to debug, you need to go to:
-> Preferences -> Ruby -> Platform
... then choose the location of your ruby interpreter (e.g. /usr/local/bin/ruby)
You should then be able to select the Fast Debugger radio button for the
Debugger engine. (If you can't, try restarting NetBeans - this worked for me).