Here is a generic image of the sprite needed for the toolbar in a firefox extension. It has three states
as a part of the sprite.

Top: generic state of button
Middle: is the :hover state of the button
Bottom: is the :active state of the button

Just add your icon on top of these three states in the exact same place (so it does not jump on rollover, etc) and export as png.
This image works with the standard css provided by firefox, so no need for adjustment.

If you are using sIFR and have the requirement to have the generated flash file be transparent you will end up using the "wmode: 'transparent'" option. We ran into a tricky js bug in IE 6 that only happens when the browser window is resized. The only feedback you will receive is the dreaded IE 6 error box.

The solution to this heinous bug is very simple, but not easily found.

In the sIFR config file, add the following line just above sIFR.activate(..);

sIFR.repaintOnResize = false;

According to the sIFR documentation repaintOnResize "Determines whether sIFR updates the Flash movie when the window is resized. Necessary for page zoom as well."

Why this flag is defaulted to true and why sIFR needs to update the flash movie on browser resize is still a mystery . I have not noticed a change in behavior by disabling this flag (other than making the bug disappear).

So in conclusion if you need to support IE 6 and sIFR transparency then this should save you a headache or two.

I have been thinking lately about how many Rails controller actions I run into that are hard to read and do not reveal the actual intent of the person that wrote the software. This can be extremely frustrating for a developer working with code that they did not originally write.

Consider the following example:

We have an Article model that has an Article Type and belongs to a User. Any time a User creates/updates an Article, a Boolean "approved" attribute is set to false.

The Article migration file might look something like this:

class CreateArticles < ActiveRecord::Migration
  def self.up
    create_table :articles do |t|
      t.string  :title, :limit => 155, :null => false
      t.text :content, :null => false
      t.integer :user_id, :null => false
      t.integer :article_type_id, :null => true
      t.boolean :approved, :default => false, :null => false
      t.timestamps
    end
  end

  def self.down
    drop_table :articles
  end
end

So a simple requirement in this case might be for the site Administrator to be able to "approve" articles. The business refers to unapproved articles as "pending". To do this, we would need to find all of the Articles that have an "approved" value of false. We would also need to order the results by date to return the most recent article changes first.

Here is an example of how one could accomplish this query in the controller:

class PendingArticlesController <  ApplicationController
    def index
        @articles = Article.find(:all, :include => [:user, :article_type], :conditions => ["approved = ?", false], :order => 'updated_at DESC')
    end
end

There is nothing really wrong with the above find but there are a few things we can do to improve the code by revealing more intent and using the Projects Ubiquitous Language.

Enter named_scope:
From the Rails documentation, named_scope "Adds a class method for retrieving and querying objects. A scope represents a narrowing of a database query"

By using named_scope, we can refactor the controller code as follows:

Introduce named_scope into the Article model

class Article < ActiveRecord::Base
    named_scope :pending, :include => [:user, :article_type], :conditions => ["approved = ?", false], :order => 'updated_at DESC'
end

We can now update our controller code to use our new named_scope

class PendingArticlesController <  ApplicationController
    def index
        @pending_articles = Article.pending
    end

end

This is much better! Now we have a very simple controller action which is easy to read and understand at a glance. We have also moved the find logic into the Article, which is where it belongs.

While this is a very simple example, consider a controller action with many lines and very large find statements. These can become very difficult to understand and hard to maintain.

Any and all feedback is welcome.