Tired of rake hiding your error stack trace?

rake aborted! Build failed

(See full trace by running task with --trace)

You can have rake always show your error stack trace by going into your project's Rakefile and setting:

Rake.application.options.trace = true

Now you never need to worry about passing --trace again.

I just released Cacheable Flash 0.1.4. This version includes test helpers so you can easily test your cache messages. It works by allowing you to make assertions on the flash cookie.

Here is a test/unit example:

  require "cacheable_flash/test_helpers"

  class TestController < ActionController::Base
    def index
      flash["notice"] = "In index"
    end
  end

  class ControllerTest < Test::Unit::TestCase
    include CacheableFlash::TestHelpers

    def setup
      @controller = TestController.new
      @request = ActionController::TestRequest.new
      @response = ActionController::TestResponse.new
    end

    def test_cacheable_flash_action
      get :index
      asset_equal "In index", flash_cookie["notice"]
    end
  end

Here is a rspec example:

  require "cacheable_flash/test_helpers"

  class TestController < ActionController::Base
    def index
      flash["notice"] = "In index"
    end
  end

  describe TestController, "#index" do
    include CacheableFlash::TestHelpers

    it "writes to the flash cookie" do
      get :index
      flash_cookie["notice"].should == "In index"
    end
  end

You can install Cacheable Flash by running:

ruby script/plugin install svn://rubyforge.org/var/svn/pivotalrb/cacheable_flash/trunk

See the Cacheable Flash blog post, Show Flash Messages on Cached Pages, and the README for more information.

Page caching is an easy way to get massive performance and scalability increases with little up front effort. Of course, when page caching, a number of design changes are necessary. For example, server side session data cannot be used to render data on cached pages.

Rails provides the flash hash to easily render alert messages and errors. In the controller you can write to the flash hash:

flash[:error] = "You cannot go there"
# or
flash[:notice] = "Welcome to eternity"

and render the flash hash in the view. Typically the rendering happens on a layout:

<div id="error_div_id" class="flash flash_error"><%= flash[:error] %></div>
<div id="notice_div_id" class="flash flash_notice"><%= flash[:notice] %></div>

There are some strange quirks with using flash such as needing to use FlashHash#now when rendering the response without redirecting.

Everything works great until you need to page cache the landing page.

For example, lets say you page cache your home page. After logging in, you are redirected to the home page with the flash notice "Logged in successfully". When page caching, this solution does not work because the request is responded to by the Web Server (i.e. Apache) and does not reach the Rails App server (i.e. Mongrel).

This means the view does not get a chance to render the flash error and notice.

There are a couple of solutions to this problem.

• Do an AJAX request back to the server to render the flash error and notice (i.e. using RJS)
• Send the flash error and notice from the server with cookies and render it during page load

Introducing Cacheable Flash

To solve the problem using cookies on Peer to Patent, we wrote the Cacheable Flash plugin. The plugin allows you to set the flash hash as normal on the controller. It handles converting the flash hash into cookies. All you need to do is include the CacheableFlash module into your controller.

class ApplicationController < ActionController::Base
  include CacheableFlash
  # ...
end

On the view side, you will need to add some javascript.

<div id="error_div_id" class="flash flash_error"></div>
<div id="notice_div_id" class="flash flash_notice"></div>
<script type="text/javascript">
  Flash.transferFromCookies();
  Flash.writeDataTo('error', $('error_div_id'));
  Flash.writeDataTo('notice', $('notice_div_id'));
</script>

The Flash.transferFromCookies method:

• Grabs the flash data from the cookies and saves it to Flash.data
• Deserializes the flash hash from JSON to Javascript
• Erases the flash data from the cookies

The Flash.writeDataTo method:

• Writes data from the passed in key in Flash.data to the passed in element or element id

Here is how the life cycle of the login works:

1. The user enters the correct login information

2. Rails handles the web request. In the Login controller, flash[:notice] is written to

     if current_user
       flash[:notice] = "Welcome to Eternity"
     end
   

3. An after filter serializes contents of the Flash Hash as JSON into cookies

4. The after filter clears the flash hash
5. The cached page is rendered
6. The client side receives and clears the flash cookie data
7. The client side javascript renders the flash messages

There is also a side benefit -- you don't have to use FlashHash#now because storing the flash in cookies to be rendered and erased by the client makes this unnecessary.

The Cacheable Flash plugin is on the Pivotal RB project page (http://rubyforge.org/projects/pivotalrb). You can install it by running:

ruby script/plugin install svn://rubyforge.org/var/svn/pivotalrb/cacheable_flash/trunk

It will copy flash.js, cookie.js, and json.js if you do not already have these files.

Happy Page Caching!!

Thanks to Josh Susser for pairing with me on this.

I have a few gems on Rubyforge and I want to track how many of them were downloaded. I found Firefox's search tools lacking to find my gem rr.

To fix this issue, I made a sake task, named gems:downloads:list, that prints the gem downloads in text.

The source is on caboo.se.

You can install it by using:

sudo gem install sake
sake -i http://pastie.caboo.se/79547.txt gems:downloads:list
sake gems:downloads:list | less

This will give an output like:

------------------------------------------------
|                              Gem | Downloads |
------------------------------------------------
|                            rails |   1194471 |
|                     activerecord |   1121778 |
|                       actionpack |   1054718 |
|                    activesupport |    990851 |
|                     actionmailer |    960759 |
|                 actionwebservice |    948640 |
|                             rake |    860824 |
|                            mysql |    593476 |
|                             fcgi |    230394 |
|                          mongrel |    220370 |
|                          daemons |    167443 |
|                          rmagick |    164537 |
|                       gem_plugin |    153505 |
|                         RedCloth |    147182 |
|                  rubygems-update |    119615 |
|                          net-ssh |    114369 |
|                     sqlite3-ruby |    105796 |
|                       fastthread |     95534 |
|            cgi_multipart_eof_fix |     95399 |
|                           needle |     87718 |

Sake is way cool. It was just too easy to implement and deploy this. Have fun making your own sake tasks.

We all like a good oxymoron, like redefining constants. There are times where we need to redefine a constant to test an edge case in the application code. Before I go into this example, please note that redefining constants is generally not a good way to have maintainable software. If you find yourself needing to redefine a constant, it may be an indication that refactoring is needed.

Given that, lets get into an example where you may need to redefine a constant. Lets say an app has does file uploads to Amazon's S3 service. A common practice to upload to a real S3 account made for the production, development, or demo environment.

When in the test environment, a fake S3 service would be used instead. The fake service is useful to keep your tests fast and running predictably.

To get a different File Upload service object in each of your environments, one can have the S3 configuration in the environment files:

test.rb

STORAGE_SERVICE = FakeStorageService.new

development.rb

STORAGE_SERVICE = S3StorageService.new("development_service", "access_key", "secret_access_key")

production.rb

STORAGE_SERVICE = S3StorageService.new("production_service", "access_key", "secret_access_key")

The File Upload service objects can be set to constants in the environment file. This works great when testing the logic of the objects that use the File Upload service. However it is a good idea to run an integration test that does a real upload.

Since the tests are running in the test environment, a fake File Upload service is being used. Well now we want to use a real service that points to a test S3 account. An easy trick is to redefine the constant to the S3 service in setup and then redefine the constant back to the fake service on teardown.

There are a few ways of doing this...

Just Reset the Constant

context "A real S3 call" do
  setup do
    STORAGE_SERVICE = S3StorageService.new("test_service", "access_key", "secret_access_key")
  end
  teardown do
    STORAGE_SERVICE = FakeStorageService.new
  end
end

This is the simplest approach, but it produces an error:

warning: already initialized constant STORAGE_SERVICE

###Use silence_warnings

context "A real S3 call" do
  setup do
    silence_warnings do
      STORAGE_SERVICE = S3StorageService.new("test_service", "access_key", "secret_access_key")
    end
  end
  teardown do
    silence_warnings do
      STORAGE_SERVICE = FakeStorageService.new
    end
  end
end

This solution removes the warning, but now a certain section of your code will not have warning at all. Also, one could argue that you lose semantic meaning. It also feels like a hack.

Redefine the Constant

class Module
  def redefine_const(name, value)
    __send__(:remove_const, name) if const_defined?(name)
    const_set(name, value)
  end
end

context "A real S3 call" do
  setup do
    Object.redefine_const(
      :STORAGE_SERVICE,
      S3StorageService.new("test_service", "access_key", "secret_access_key")
    )
  end
  teardown do
    Object.redefine_const(
      :STORAGE_SERVICE,
      STORAGE_SERVICE = FakeStorageService.new
    )
  end
end

Calling redefining the constant does not generate a warning. Also it does provide semantic value because you are actively declaring that you are redefining the constant. If there are other warnings, you will also see them.

Its all Dirty

Redefining constants is a non-standard tatic, especially for those new to Ruby. Since this is unconventional and is often contrary to assumptions, it may lead to unpredictable behavior.

Maybe the storage service can be an attribute that can be changed for individual tests.