Rails Illustrated

How to be Lazy in Ruby and Why You Should Be

2012-09-02T19:47:49Z

Ruby borrows many ideas from functional languages, allowing for readable, terse methods without side affects. There are sometimes significant drawbacks to writing functional Ruby code, including inadvertent memory consumption. Fortunately these drawbacks can be avoided by making use of Ruby's Enumerator objects to implement lazy sequences.

When writing ruby scripts for data munging, a common problem is to read a character separated data file into a Ruby hash. If we have a data file with two columns, say user_id and group_id and we wish to read that into memory as hash with user_id as the key and group_id as the value we could use something like the following:

result = File.open("data") do |f|
  f.readlines.map{|l| l.strip.split(/,/)}.inject({}){|h,l| h.merge(l.first.to_i => l.last.to_i)}
end

This implementation is functional but has one major drawback: readlines will return an instance of Array and so the entire file will be read into memory before constructing the hash. If the file is of appreciable size this will quickly become a serious performance bottleneck. One way to rectify this problem is to change the implementation to the following:

result = File.open("data") do |f|
  h = {}
  f.each do |l|
    l = l.strip.split(/,/)
    h[l.first.to_i] = l.last.to_i
  end
  h
end

While this no longer reads the entire data file in memory, addressing the memory concerns of the original implementation, it is certainly more verbose than the original implementation. In particular, many might argue that the first implementation is the idiomatic Ruby implementation, and that the second implementation should be avoided unless there are known to be memory related performance problems.

The Lazy Way

There is a way to have the best of both worlds: a function style implementation that avoids loading the entire input file into memory at once by making use of Ruby's Enumerator class. An Enumerator objects encapsulates the traversal of an enumerable, without performing the complete traversal. Thus, by using an Enumerator we can express the loading of the file in a functional way, without loading the file all at once into an Array at the very first step.

It is easy to construct an Enumerator for many of the methods defined in the Enumerable module using the enum_for method:

[:a, :b, :c].enum_for(:reject) # => #<Enumerable::Enumerator:0x1011f5d40>

In fact, the File.each method will return an instance of Enumerator if no block is provided:

File.open("data") {|f| f.each} # => #<Enumerable::Enumerator:0x1011ca640>

Knowing this we can re-write our original implementation:

result = File.open("data") do |f|
  f.each.map{|l| l.strip.split(/,/)}.inject({}){|h,l| h.merge(l.first.to_i => l.last.to_i)}
end

Now f.each will return an Enumerator. Assuming that map will also return an Enumerator we will have succeeded in constructing a lazy sequence from the input file.

Unfortunately map does not return an instance of Enumerator, instead returning an instance of Array. This is considered a bug in Ruby 1.9 (and in Ruby 1.8.7) and should hopefully fixed sometime soon. As a work around we can monkey patch Enumerable to fix the map method:

module Enumerable
  class Enumerator

    def map(&block)
      self.class.new do |yielder|
        each do |e|
          yielder << block.call(e)
        end
      end
    end

 end
end

Now map will return a new Enumerator, which will yield an enumeration of the result of calling the block provided to map on the original sequence provided by the original Enumerator instance. Many other methods in the Enumerable module can also be modified to return an instance of Enumerator. For implementation details see lazy_enum.rb as attached to the original bug report.

This code is Ruby 1.9 specific as Enumerator.new doesn't take a block in Ruby 1.8.7. We can use the Ruby facets gem to make Enumerator in Ruby 1.8.7 behave like Enumerator in Ruby 1.9.

Putting it all together

We can now write a completely lazy functional implementation of our original problem which works in Ruby 1.8.7:

require 'facets/enumerator'

module Enumerable
  class Enumerator

    def map(&block)
      self.class.new do |yielder|
        each do |e|
          yielder << block.call(e)
        end
      end
    end

 end
end

result = File.open("data") do |f|
  f.each.map{|l| l.strip.split(/,/)}.inject({}){|h,l| h.merge(l.first.to_i => l.last.to_i)}
end

These Aren't the Deprecation Warnings You Are Looking For

2012-09-02T19:47:49Z

Ruby prints some helpful deprecation warnings when using some deprecated features of the Ruby language. However, you won't find these errors when they occur within a rake task run inside Rails.

Warnings Often Indicate Bugs

I prefer to treat warnings as errors, as warnings often indicate the presence of a bug. For example, in Ruby 1.8.7, the id method is deprecated and calling id on an Object that doesn't define an id method prints an error:

warning: Object#id will be deprecated; use Object#object_id

A warning like that is probably a good sign I am calling id on the wrong Object. These deprecation warnings are, surprisingly, explicitly turned off in Rails rake tasks in both Rails 2.3 and Rails 3.

Missing Warnings

A Rake task like the following will output nothing when run from lib/tasks:

namespace :deprec do
  task :test do
    nil.type # => no deprecation warning
    nil.id # => no deprecation warning

    A = Class.new
    a = A.new 
    a.id # =>  no deprecation warning
    a.type # =>  no deprecation warning
  end
end

To add back the warnings, simply put $VERBOSE = true at the top of the rake task:

$VERBOSE = true
namespace :deprec do
  task :test do
    nil.type # => deprecation warning
    nil.id # => deprecation warning

    A = Class.new
    a = A.new 
    a.id # => deprecation warning
    a.type # => deprecation warning
  end
end

A Long History

I'm not sure why silencing warnings is the default behavior for Rails rake tasks. The $VERBOSE = nil seems to originate in the very first commit.

Rails Logger Tricks

2012-09-02T19:47:49Z

Here are a few quick tricks for using the Rails logger.

Save disk space by rotating logs in the config/environments/test.rb and config/environments/development.rb

config.logger = Logger.new(Rails.root.join("log",Rails.env + ".log"),3,5*1024*1024)

which will rotate the log files every 5 megabytes and leave only the three most recent log files. This will limit the total spaces used by the logs at 15 megabytes.

To log to STDOUT while using the console use this trick:

if $0 == "irb"
  config.logger = Logger.new(STDOUT)
else
  config.logger = Logger.new(Rails.root.join("log",Rails.env + ".log"),3,5*1024*1024)  
end

For more tips on Rails logging see this post: Rails Logging Tips.

Getting Started with Tokyo Cabinet

2012-09-02T19:47:49Z

Tokyo Cabinet is an extremely fast key-value store. It's a lot like memcache: only better.

Advantages over Memcache

Tokyo Cabinet can be run as a server (called Tokyo Tyrant) but it can also be used without running as a server.
Tokyo Cabinet understands the memcache protocol, but also has its own protocol that has a smaller network footprint.
Tokyo Cabinet is more flexible supporting different types of stores.
Tokyo Cabinet stores can be easily persisted to disk.

Installation

First, you must install the Tokyo Cabinet libraries:

wget http://tokyocabinet.sourceforge.net/tokyocabinet-1.4.23.tar.gz
tar xvzf tokyocabinet-1.4.23.tar.gz
cd tokyocabinet-1.4.23
./configure
make
sudo make install

Ruby bindings installation

Next install the Ruby interface. Unfortunately, Tokyo Cabinet is not currently bundled as a gem. To install:

wget http://tokyocabinet.sourceforge.net/rubypkg/tokyocabinet-ruby-1.25.tar.gz
tar xvzf tokyocabinet-ruby-1.25.tar.gz
cd tokyocabinet-ruby-1.25/
ruby extconf.rb
make

Installation on Mac OS X Leopard

If, on Mac OS X Leopard, you get an error like this:

ld: warning in /usr/local/lib/libtokyocabinet.dylib, file is not of required architecture

Then replace the instructions above with:

wget http://tokyocabinet.sourceforge.net/rubypkg/tokyocabinet-ruby-1.25.tar.gz
tar xvzf tokyocabinet-ruby-1.25.tar.gz
cd tokyocabinet-ruby-1.25/
ARCHFLAGS="-arch i386" ruby extconf.rb
make clean
make
sudo make install

Now you should have the Ruby interface to the Tokyo Cabinet.

Using Tokyo Cabinet

To use Tokyo Cabinet within Ruby it is as simple as:

require 'tokyocabinet'
include TokyoCabinet

hdb = HDB::new
hdb.open("has-db.tch", HDB::OWRITER | HDB::OCREAT)
hdb.put("this-is-a-key","this-is-a-value")
puts hdb.get("this-is-a-key")

Weird Session Issues in Rails 2.3 and Passenger

2012-09-02T19:47:49Z

Are you having weird issues associated with sessions using Rails 2.3 and Passenger? Perhaps you have problems like repeated flash messages and the inability to logout by destroying a session variable.

There is a simple fix: upgrade passenger. This lighthouse ticket has some more details about session problems.

To upgrade passenger:

sudo gem install passenger
passenger-install-apache2-module

After installing the new Passenger Apache module you will probably have to edit the httpd.conf to include the new version of the Passenger module.

After restarting Apache everything was working correctly.

Is the Diggbar Impacting Your User's Experience?

2012-09-02T19:47:49Z

The recently launched Diggbar from digg.com can wrap your site in a frame if the user visits a special URL on digg.com. Your user's experience is negatively impacted:

the URL in the address bar is 'digg.com'
your site title could be changed
content is moved down the page (leaving less 'above the fold')
it adds visual noise to your site
it changes your finely crafted visual design
your site's personality is affected

Many sites (like the NY Times) are, with good reason, blocking this Diggbar. There is a Rails plugin to do this for your site: acts_against_douchebar.

Browsing the Rails Documentation online

2012-09-02T19:47:48Z

There is a great new searchable version of the Rails documentation online at http://voloko.ru/sdoc/rails/rdoc/. This version is very fast and can even be downloaded for offline (airplane?) use. What a nice usable search interface with embedded browsing capabilit. I have used http://www.railsbrain.com/ but I find the search experience to be suboptimal. (Thanks to Rails Inside for the link.)

Safari version 4 and tabs in the title bar

2012-09-02T19:47:48Z

If you haven't already seen the beta version of Safari 4 you might be in for a little surprise when upgrading from Safari 3. The tabs have moved into the title bar of the window, just like Google Chrome.

I haven't decided if this is a good idea or not yet. What I find the most interesting is that this has generated a lot of spirited discussion. The most important conclusion from this whole ordeal is probably that sometimes making user experience decisions is very hard. Fortunately, most user experience decisions are pretty easy.

Arguments in favor of tabs in the title bar

There are a couple of arguments that placing tabs in the title bar more closely matches the metaphor that a modern web browser uses.

Google Chrome's Explanation
Matching Users' Mental Models
Defending Safari 4 tabs with several good criticisms

Arguments against tabs in the title bar

There are those that find good reason not to put tabs in the title bar:

Changing the tabs back

To change back the tab behavior to be like Safari 3 use:

$ defaults write com.apple.Safari DebugSafari4TabBarIsOnTop -bool NO

More configuration options are also available.

Reloading is now harder

One complaint that I do have is that clicking the reload button is now much harder. In Safari 4 the reload button is only 30% of the size of the Safari 3 button. This makes it much more difficult and much slower to click.

A Simple Improvement to Twitter

2012-09-02T19:47:48Z

I'm sure that many have seen the Twitter user page. I would guess most common use of this page is to:

decide if to follow a user, and then
to follow that user

If that is the case, why isn't the page optimized for these tasks?

What works well

In order to meet the first need: "decide if to follow a user" I think the page works well.

The following are probably of most interest in deciding if to follow a user:

number of followers
number following
bio
recent tweets

All of these items are shown in a prominent place in the page. It is easy for a user to scan and find all of these items in a matter of a couple of seconds.

What can be improved

Now that you have decided to follow a user. The next action to take is to click the 'Follow' button. Think back to the first time you clicked on the 'Follow' button. Was the click successful? How did you know?

There are two problems with the interaction design of the 'Follow' button:

the 'Follow' button does not change state
the spinner is 700 pixels away from the button

A simple improvement

By changing a few lines of HTML and Javascript the design could be changed to:

In the redesign, after clicking 'Follow' the reaction is entirely in the visual field of the user and linked by proximity to the 'Follow' button.

In this case: - the 'Follow' button changes state and indicates this change visually - the spinner is right next to the button

Note: It may be the case that the spinner is used for multiple actions on the same page. If this is the case, place a spinner appropriately near each interface element that initiates an action.

Reasonable, but can be improved

This use of proximity is already used by Twitter to indicate that the follow action has been successful.

I think the placement of the success message is appropriate, as is the change in state of the 'Follow' button.

Now suppose that the user wants to stop following someone. They will click the 'Following' button and see:

There are a few issues:

to unfollow requires two clicks
the unfollow process is not symmetric with the follow process
the language is not consistent: click 'Follow' to follow, click the 'Following' to stop following
unfollow is called 'remove'

I suspect the design is like this to prevent a user from spuriously unfollowing someone. In cases like these it is almost always better to replace confirmation actions with an undo, i.e. Never Use a Waring When you Mean Undo.

Interaction '09 Conference in Bullet Form

2012-09-02T19:47:48Z

Luke Wroblewski, the writer of the book Web Form Design: Filling in the Blanks, has a synopsis of some of the talks at this years Interaction Conference. The talks include:

How to Change Complicated Stuff
Designing the Viral App
Mobile UX Patterns
Carpe Diem (growing the profession of interaction design)
Designing Natural Interfaces
Irrational Behavior
Fiona Raby (interaction between people and things)
Coming Into Your Own (growing the discipline of interaction design)
Experiencing Sustainability

More Rails Speed with asset_packager Plugin

2012-09-02T19:47:48Z

One of the many strategies for speeding up your Rails application is to serve exactly one CSS file and exactly one Javascript file. It is often more convenient to have multiple files in development and only package these files into one file in production. It doesn't hurt to also minify these files when in production mode. This is exactly what Scott Becker's great asset_packager original plugin is for.

Asset Packager Plugin with YUI Compressor

The standard asset_packager is a great plugin. It has a couple of issues:

It has a bug: it mangles CSS with multiline comments.
It uses a sub optimal Javascript and CSS compressor.

YUI Compressor

The Yahoo YUI Compressor is "100% safe" and does a great of job of reducing both Javascript and CSS file size.

The goal of JavaScript and CSS minification is always to preserve the operational qualities of the code while reducing its overall byte footprint (both in raw terms and after gzipping, as most JavaScript and CSS served from production web servers is gzipped as part of the HTTP protocol). The YUI Compressor is JavaScript minifier designed to be 100% safe and yield a higher compression ratio than most other tools. Tests on the YUI Library have shown savings of over 20% compared to JSMin (becoming 10% after HTTP compression).

I have modified the asset_packager plugin to use the YUI compressor, if available, for both CSS and Javascript minification.

Compression

The YUI compressor provides some serious savings:

prototype.js uncompressed: 54K
prototype.js compressed with jsmin.rb Ruby compressor: 41K
prototype.js compressed with YUI compressor: 33K

Requirements

A java run time environment should be installed on the server. If it is not available the asset_packager will still function but won't use the YUI compressor.

Installation

Until the official version includes the changes to support the YUI compressor you will have to use my fork.

Install with

./script/plugin install git://github.com/eandrejko/asset_packager.git

Generate the config/asset_packages.yml configuration file with

rake asset:packager:create_yml

Modify the configuration file to include the necessary Javascript and CSS files:

--- 
javascripts: 
- base: 
  - prototype
  - effects
  - dragdrop
  - controls
  - application
stylesheets: 
- base: 
  - reset
  - text
  - screen

In your layout file use:

<%= javascript_include_merged :base %>
<%= stylesheet_link_merged :base %>

When your application is in the production environment all of the files will be automatically merged and compressed.

Check Javascript Files

To check your Javascript files for issues that might inhibit compression use the rake task

rake asset:packager:check

Use the Google version

Most browsers make at most two simultaneous connections to each web server. If you place the following in your application layout file:

<script src="http://ajax.googleapis.com/ajax/libs/prototype/1.6.0.3/prototype.js" type="text/javascript" charset="utf-8"></script>
<%= javascript_include_merged :base %>
<%= stylesheet_link_merged :base %>

The prototype.js file will be loaded from Google and it may be loaded in parallel with your compressed Javascript files. With any luck the user will already have it cached. You will want to remove the prototype from the config/asset_packages.yml file.

A Simple Class Based Logger in Rails

2012-09-02T19:47:48Z

In a project I was working on there were several classes that were involved in a lot of background processing. In order to monitor the behavior of this background processing I wanted a separate log file for these classes. The result: class_logger is a simple plugin that creates a separated log file for an ActiveRecord model.

Installation

./script/plugin install git://github.com/eandrejko/class_logger.git

Usage

In your model use

class Email < ActiveRecord::Base
    has_own_logger
end

which will by default create a log file log/email.log. To write to this log file use:

email = Email.create
email.log("sending")

or use the class method:

Email.class_logger("connecting to server")

Specifying the directory

If you want to keep the log file in another location specify the directory with:

class Email < ActiveRecord::Base
    has_own_logger :in => 'log/emails'
end

which will create the log file in log/emails/email.log.

Potential Applications

There are some advantages to having a separate log file. You can log many more events without cluttering up your production.log. This is potentially helpful for

troubleshooting background processing in production
recording and analyzing performance of long running processes in your application

Screencast: Hover Content in Rails and Prototype (Part 1)

2012-09-02T19:47:48Z

Screencast: Hover Content in Rails and Prototype from Erik Andrejko on Vimeo.

It is often a good idea to show content when the user hovers the mouse above a link or an element in a page. This technique has been abused by some, but when used correctly it can enhance the user's experience. This is particularly the case when you have a lot of information that may be relevant to the user's interests but is too much to display all at once.

Screencast

View a quicktime version: full, iPod.
The complete code can be downloaded from GitHub.

Required

LowPro for unobtrusive javascript for Prototype

Optional

Firebug for Javascript debugging

Basic Strategy

We want to place the content that appears when the mouse is hovered as near as possible to the element that generates the hover (the affordance). We accomplish this by means of a wrapper div around each row of contacts.

1. Controller

In the controller the contacts are grouped into groups of 4 so that they can be wrapped in a div.

def index
  @contacts = Contact.find(:all, :order => 'last_name asc, first_name asc')
  @contact_groups = @contacts.in_groups_of(4,false)
end

def show
  @contact = Contact.find(params[:id])
end

2. View

The trick is to wrap each each row of contacts with the wrapper div. This accomplished by the contact_group partial.

<% content_for :scripts do %>
<%= javascript_include_tag 'hover_content' %>
<% end %>


<div id='contact-names'>
<%= render :partial => 'contact_group', :collection => @contact_groups %>
</div>

The contact_group partial wraps the row in a div.

<div class='contact-group'>
    <%= render :partial => 'contact_name', :collection => contact_group %>
</div>

3. Unobtrusive Javascript

The javascript is fairly straightforward. When the mouseover event is received, we load the content to display with an Ajax call.

Bubbling Event Problem

The div that we watch for mouseover events has child elements. When any of those elements received a mouseover event it will be sent to the parent elements. This means that the div will receive extraneous events. We must ignore these extra events to provide smooth visual effects.

The check for bubbling mouseover events from child elements with Protoype:

// from http://groups.google.com/group/prototype-scriptaculous/browse_thread/thread/badf3974a0dd5ac6
function bubbledFromChild(element, event)  {
  var target = $(event).element();
  if (target === element) target = event.relatedTarget;
  return (target && target.descendantOf(element));
}

This check is used on each function that handles either the mouseover or mouseout events. The rest of the Javascript is fairly routine:

Event.addBehavior({
  ".contact-name:mouseover" : function(e){
    if(!bubbledFromChild(this,e)){
      $(this).setStyle({backgroundColor:"#f0f0f0"});
      var id = $(this).readAttribute("id").match(/[0-9]+$/)[0];
      var container = $(this).up(".contact-group");
      $$(".contact").each( function(e) {
        e.hide();
      });
      if($(container).down("#contact-"+id)){
        new Effect.Appear("contact-"+id, {queue: 'end', duration: 0.7})
      }else{
        if(Ajax.activeRequestCount == 0){
          var url = $(this).down("a").readAttribute("href");
          new Ajax.Request(url,{
            method: 'get',
            onSuccess: function(xhr){
              container.insert({bottom: xhr.responseText});
            }});
        }
      }      
    }
  },

  ".contact-name:mouseout" : function(e){
    if(!bubbledFromChild(this,e)){
      $$(".contact").each( function(e) {
        e.hide();
      });      
    }
  }
})

Optional Enhancements

Over the next couple of weeks we shall continue this screencast by enhancing this hover technique to improve usability.

Credits

Intro music thanks to Courtney Williams via Podcast NYC.

User Testing Exposes Hidden Assumptions

2012-09-02T19:47:48Z

Design is all about assumptions. If you don't assume anything how can you get started? Good design means getting those assumptions correct. Often times these assumptions will be wrong, and many of those assumptions will be hidden: the designer doesn't realize the assumption is being made. This is not a problem if the assumption is correct, but becomes an unknown problem if the assumption is incorrect.

Identify Assumptions with User Testing

One of the best ways to expose those hidden assumptions is through user testing. You can't fix something you don't know is broken. That is what makes User Testing so powerful.

To see an example of how user testing can expose hidden assumptions watch the screencast "A Lesson Learned in Accessibility" at CSS Tricks. If you are like me you would have assumed the same things about how screen readers work and how visually impaired users will use your site.

Some Hidden Assumptions

Here are some assumptions that I have unknowingly made in the past. Some of these are pretty obvious usability issues. Some of them are more subtle and were made very obvious during user testing.

My users mostly use this version of Browser X.
The input validation is sufficient.
My users have flash installed.
This javascript will run fast enough.
My users have javascript enabled.
The order of my html doesn't matter.
My users will read this block of text.
This functionality meets the needs of my users.
My users have this purpose when visiting my site/using my product.
This feature is important to my users.
My visually impaired users will have javascript disabled.
This interface element is clearly understandable.
My users will scroll to the bottom of this page.
The information architecture of this site is correct.
My users will fill out these fields in this order
The state of the application is clearly indicated.
My users will navigate the page using a mouse.
The application will be used generally in the way it was intended to be used.
My users don't need this feature.
This affordance is recognizable.

The Biggest Assumption of All

The biggest assumption is the meta-assumption: I know what I am assuming and am correct about those assumptions. No matter how many usability tests you do or how much experience you have there is always another assumption you won't realize you have made. That is, until it becomes very obvious during user testing.

What are your hidden assumptions?

What assumptions have you made and how were they made obvious? Please share your stories in the comments below.

Blazing Fast Speeds with Sinatra and Memcached

2012-09-02T19:47:48Z

Sinatra is a wonderful small Ruby web framework built on top of the Rack interface. Sinatra is very fast out of the box making it perfect for light weight tasks. Sinatra does not come with support for memcached out of the box but adding support for memcached is fairly straightforward.

Requirements

Download the file cache.rb.
You will need to have installed memcached and also the memcache-client gem:

sudo gem install memcache-client

Installation

At the top of your Sinatra application should be

require 'sinatra'    
require 'cache'    

CONFIG['memcached'] = 'localhost:11211'

# add caching to Sinatra
class Sinatra::Event
  include CacheableEvent
end

Usage

A standard Sinatra controller method looks like this:

get '/:name' do
    ...
    erb 'name'
end

To add caching change to:

get '/:name', :cache_key => Name.cache_key do
    ...
    erb 'name'
end

You will want Name.cache_key to return a string and to change whenever the content returned by name.html.erb view will change. You do not have to invalidate any caches directly. Furthermore the computed cache_key will automatically include details of the parameters of the request.

If you want to cache anything else inside your application use:

result = Sinatra::Cache.cache(cache_key) do
    this_is_an_expensive_method
end

How it Works

There are essentially two modification that must be made. Override the way Sinatra stores blocks that make up the controller methods and also to override the way Sinatra calls those stored blocks.

Overriding the block storage

When you declare a controller method in your application file like

get '/:name' do
    ...
    erb 'name'
end

Sinatra stores the block provided and saves it to be executed when responding to a request. The caching mechanism replaces this block with another block. This replacement block uses the caching mechanism. The cache_key and original block are saved by means of Proc.new which creates a closure and allows the block to access these values at the time of execution.

def _invoke_with_caching(*args)
  if options[:cache_key]
    # replace the block with another block that can be cached
    def wrap_block(key,block)
      Proc.new do
        Sinatra::Cache.cache(key + "/" + params.to_a.join("/")) { instance_eval(&block) }
      end
    end
    @block = wrap_block(options[:cache_key], block)
  end
  _invoke_without_caching(*args)
end

How fast is it?

This depends on how long it takes do generate your cache_key. There is also additional overhead in accessing memcached. In my case it usually takes about 15 milliseconds to respond from the cache.

It doesn't matter

However it doesn't matter that much. You web application speed usually doesn't depend on how fast your application responds, especially when the response time is less than 150 milliseconds. To understand why see this explanation of where your application is really slow.

Rails Illustrated

How to be Lazy in Ruby and Why You Should Be

The Lazy Way

Putting it all together

Further reading

These Aren't the Deprecation Warnings You Are Looking For

Warnings Often Indicate Bugs

Missing Warnings

A Long History

Rails Logger Tricks

Getting Started with Tokyo Cabinet

Advantages over Memcache

Installation

Ruby bindings installation

Installation on Mac OS X Leopard

Using Tokyo Cabinet

Further Reading

Weird Session Issues in Rails 2.3 and Passenger

Is the Diggbar Impacting Your User's Experience?

Browsing the Rails Documentation online

Safari version 4 and tabs in the title bar

Arguments in favor of tabs in the title bar

Arguments against tabs in the title bar

Changing the tabs back

Reloading is now harder

A Simple Improvement to Twitter

What works well

What can be improved

A simple improvement

Reasonable, but can be improved

Interaction '09 Conference in Bullet Form

More Rails Speed with asset_packager Plugin

Asset Packager Plugin with YUI Compressor

YUI Compressor

Compression

Requirements

Installation

Check Javascript Files

Use the Google version

A Simple Class Based Logger in Rails

Installation

Usage

Specifying the directory

Potential Applications

Screencast: Hover Content in Rails and Prototype (Part 1)

Screencast

Required

Optional

Basic Strategy

1. Controller

2. View

3. Unobtrusive Javascript

Bubbling Event Problem

Optional Enhancements

Credits

User Testing Exposes Hidden Assumptions

Identify Assumptions with User Testing

Some Hidden Assumptions

The Biggest Assumption of All

What are your hidden assumptions?

Blazing Fast Speeds with Sinatra and Memcached

Requirements

Installation

Usage

How it Works

Overriding the block storage

How fast is it?

It doesn't matter