
Two feet of snow.
Looks like we got two feet of snow this week.

Two feet of snow.
Looks like we got two feet of snow this week.
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.
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:
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:
# 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.
I had a great time this weekend at DrupalCamp Austin, 2009. DrupalCamp was a “Barcamp” styled meetup with a strong emphases on Drupal. At the camp I was introduced to Drush. Drush is the Drupal Shell and provides tools for managing your Drupal projects with shell scripts. I can see great use for Drush at the office to help quickly create new Drupal sites in a standardized fashion. It can also be used to run maintenance scripts.
Other topics included Panels 3, Drupal SEO, and JQuery UI being added to Drupal 7 core. The improvements to Panels in Panels 3 are significant. The prevailing wisdom at the conference was that Panels 3 will replace blocks for most cases.
During the keynote talk, they performed a basic DISC personality assessment on everyone at the camp. The test performed was way over simplified (two questions) and the results over generalized. It was interesting seeing how people reacted to the test. One result that was curious is while about 75% of the attendees consider themselves to be introverts, the conference had their happy hour at a karaoke bar. That did not seem well thought out. Then again, several of us stayed their until 2 in the morning.
Overall, the camp was fun. I met a lot of good people. And I hope to go to another camp soon.
![]()
This week I improved the Amazon wishlist support in PriceChirp. One of the cool features of PriceChirp from the beginning has been how easy it is to import an Amazon wishlist into PriceChirp. The only problem with this feature is it was an all or nothing proposition. Now, we have the ability to view our wishlists in PriceChirp and select which items we wish to import. The old feature of importing everything is still thee, but now we have options.
To see this feature in action, log into your PriceChirp account and do a wishlist search. This is done by searching for the email address associated to your Amazon wishlist. Once your wishlists are displayed, you can select “view wishlist” to get a listing of your items. From this page you can easily select which item to import into your personalized tracker.
Have fun!
![]()
PriceChirp is growing. This week I added support to allow people to track prices and be alerted of changes for all the international Amazon sites. This includes Amazon US, Canada, France, Germany, Japan, and the UK. Just select the location of Amazon you are interested in searching, and use PriceChirp like normal. It was designed to make it easy to manage products from multiple sites at once. I’m hoping this design decision will pay off if in the future I add more vendors to PriceChirp.
Today I upgraded from Drupal 5.20 to 6.14. I’ve been dreading the upgrade to the Drupal 6.x series for almost 9 months because I had no idea how hard it would be or what I would lose in the migration.
The instructions on the Drupal site are fine, but they didn’t prepare me for what would be different.
If all has gone well, you have an upgraded core. Now for the tedious part. Start upgrading each module one at a time, running your update script between each one.
After upgrading every module that had a Drupal 6.x version, here is what I lost:
Differences of note:
In the end, I am very happy with the upgrade. I still have work as I will need to find / hack a new template sometime so I don’t look like a default Drupal install.
I created a module I am also using both in rails and for some batch processing outside of rails. In order to ensure my data was formatted the same with both environments, I needed to figure out how to get access to the active_view helper number_to_currency outside of rails. Here is how I did it:
require 'rubygems'
require 'action_view'
def number_to_currency(number, options = {})
ActionView::Base.new.number_to_currency(number, options)
end
Found an issue with open-uri because today Amazon’s API is wonky. The same issue will occur when accessing any remote data via open-uri (like a RSS feed) if the data source is going to slow. The relevant part of my ruby code looks like:
begin
doc = Nokogiri(open(api_url))
rescue
print "Connection failed: #{$!}\n"
next
end
For some reason, the rescue does not catch a timeout error.
/usr/lib64/ruby/1.8/timeout.rb:54:in `rbuf_fill': execution expired (Timeout::Error)
Explicitly catching the timeout error fixes the code.
begin
doc = Nokogiri(open(api_url))
rescue Timeout::Error
print "Timeout::Error: #{$!}\n"
next
rescue
print "Connection failed: #{$!}\n"
next
end
Good to know, as you never know when your remote data provider will be slow.
![]()
Gravatar is the globally recognized avatar run by the folks who run WordPress.com.
Your Gravatar is an image that follows you from site to site appearing beside your name when you do things like comment or post on a blog. This is done by associating an image to the users email address. Adding Gravatar to PriceChirp seemed like a fun thing to do.
The API is very simple, so adding it to a Ruby on Rails site is easy.
First, add a few lines to your application-helper.rb:
def gravatar_url_for(email, options = {})
url_for({
:gravatar_id => Digest::MD5.hexdigest(email),
:host => 'www.gravatar.com',
:protocol => 'http://',
:only_path => false,
:skip_relative_url_root => true,
:controller => '/avatar'
}.merge(options)
)
end
You may also need to add:
require 'digest/md5'
Now you can add the gravatar to your views like this:
# standard gravatar url
<%= gravatar_url_for 'user@gmail.com' %>
# gravatar url with a rating threshold
<%= gravatar_url_for 'user@gmail.com', { :rating => 'R' } %>
# show the avatar
<%= image_tag(gravatar_url_for 'email@gmail.com')%>
# change the size of the avatar
<%= image_tag(gravatar_url_for('email@gmail.com', { :size => 30 })) %>
Note: Gravatar is case sensitive on the user’s email address. They will match against an all lower case version of the email address. If you need to allow uppercase characters in your email addresses, you will need to .downcase the email address in the view or helper. I do not have this requirement, so I fix the case in the user.rb model at save time:
before_save :fix_email_case
protected
def fix_email_case
if !self.email.nil?
self.email.downcase!
end
end