Monthly Archives: February 2010

Bulletproof Web Design

Bulletproof Web Design — Improving flexibility and protecting against worst-case scenarios with XHTML and CSS by Dan Cederholm

Let me start off by saying I’m a programmer, not a designer. Before reading Bulletproof Web Design, I had a basic understanding of just enough CSS structure and concepts to get by. This approach lead to very inefficient markup that was hard to read and maintain. What I was missing was a deeper understanding as to when to use the different constructs and why. I found this and much more in this book.

Dan Cederholm used a brilliant format in Bulletproof Web Design. Each chapter takes a single concept illustrated by an example site that employees a traditional “unbulletproof” approach and explains the pitfalls of the traditional methods. He then deconstructs the page and rebuilds it step-by-step using semantic XHTML and CSS. The books step-by-step approach of modifying only a couple lines of CSS and explaining the results make the book a quick, yet informative read.

The book starts by explaining why and how to design your site for flexible text sizes. He uses this as the driving point for the rest of the book. How to make your navigation, tables, tabs, lists, widget boxes, rounded corners, and layouts flexible. How to design your site to be valuable to users who either can not or choose not to use images and / or style sheets. The book ends with the step-by-step approach of creating a page that ties every concept together.

Reading the book has made me feel much more confident in my CSS usage. I have already seen the payoff as I have used the methodologies in the book to both design new widgets and to refactor existing code. I feel lucky to have stumbled upon it and am looking forward to reading his sequel book, Handcrafted CSS — More Bulletproof Web Design.

ActiveRecord object caching in Ruby on Rails

Yesterday I started playing with basic caching for PriceChirp and tried what I thought would be easy. Boy was I wrong. It turns out what I was attempting to do is not supported by :memory_store in the development environment. Before moving to :mem_cache_store, I was able to find a work around. The work around is outlined below for those who do not have the option of using memcached. However, if you can use memcached, it is by far the better route to take.

My goal was to cut down on the number of database hit by caching the resultant ActiveRecord object in :memory_store.


#models/foo.rb
 def self.cool_widget
 Rails.cache.fetch('cache_object_name') { find_by_name('cool_widget') }
 end

#config/environments/development
 config.action_controller.perform_caching = true
 config.cache_store = :memory_store

#controler/foos_controllers.rb
 awesome_widget = foo.cool_widget
 logger.info awesome_widget.id

In script/console and in rails production, this works as you would expect. However, in the rails development environment, funny things happen. On the first page view, all looks good. On the second page view, as rails attempts to pull the object out of cache, rails cashes with the following error:

 .../activerecord/lib/active_record/attribute_methods.rb:142:in `create_time_zone_conversion_attribute?'

A google search lead me to:

https://rails.lighthouseapp.com/projects/8994/tickets/1290-activerecord-raises-randomly-apparently-a-timezone-issue

Here they talk known problems about caching Active Record objects on development servers. Something about the way the object are torn down between page loads to allow for every hit to get a new instance of the controller.

At the very end of the discussion (over the course of a year), I got the following work around:

http://gist.github.com/251886


# put this in lib/nil_store.rb:
 class NilStore < ActiveSupport::Cache::Store
 def initialize(location='//myloc'); end
 def read(name, options = nil); super; end
 def write(name, value, options = nil); super; end
 def delete(name, options = nil); super; end
 def delete_matched(matcher, options = nil); super; end
 end

# and then in environments/development.rb:

require 'nil_store'
 config.cache_store = NilStore.new

# or you could just turn on development class caching:

config.cache_classes = true

This “nil_store” routine basically prevent caching in the development environment which makes everything work. On production, I did not notice any problems.

Other work arounds to this bug include, not caching the ActiveRecord object or using a different caching routine, like memcached.