bricker

Auto-Expiring cache keys in Rails - easy, but what about performance?

September 7th, 2012

This was sparked by this post by DHH: http://37signals.com/svn/posts/3113-how-key-based-cache-expiration-works

At first I was excited to read about a new method I hadn't seen before, ActiveRecord's cache_key. It seemed like I was going to restructure our entire cache strategy to take advantage of this cool technique.

bricker

##
# Unique By validator
# Makes sure an attribute is unique by a specified day, month, year, etc.
# This validator is heavily based on ActiveRecord::Validations::UniquenessValidator
#
# It uses the `beginning_of_*` methods to fake the extraction of the filter (day, month, etc.) 
# ActiveSupport::CoreExtensions::Date::Calculations
# http://apidock.com/rails/ActiveSupport/CoreExtensions/Date/Calculations
#
# `scope` must be a datetime field

bricker

##
# Simple script which generates 20 "random" pastel colors and 
# creates a (horrifically invalid) HTML template
# demonstrating those colors as blocks.
# Also provides the array of colors used.
#
# ruby ./pastel-blocks.rb
# open ./pastel-demo.html
#
require 'erb'

bricker

  # Wrapper around link_to to help with event tracking links.
  # Adds the `track-event` class (even if another class is present)
  # and adds the tracking data to the data attributes hash.
  #
  # Usage:
  #
  #   tracking_link_to "Events", event_path, category: "Events", action: "Visit Events", label: "Events"
  #
  # If you need to pass html_options, be sure to let it know where one hash ends and the other begins:
  #

bricker

The RSS Parser in Ruby's standard library is too strict, and is therefore, I believe, unfit for production. Feedzirra is tolerant of invalid XML, and I recommend it over the RSS module in Ruby.

However, if you know the RSS you're dealing with valid XML 100% of the time, and that you won't get 404 errors or anything else unexpected, then you might like to use it. Here's a little monkey patch to make it slightly safer:

module RSS
  class Parser
    def self.safe_parse(url, &block)
      begin
        open(url) do |xml|

bricker

I programmed thirds, with the help of SuperCollider. This is the dumbest thing I've ever wasted 20 minutes on.

(
SynthDef.new("thirds", { |base=440|
	var outArray, third;
	third = base * 1.3;

	outArray = [
 SinOsc.ar(base, 0, 0.2),

bricker

# Django Admin's auth system, represented using ActiveRecord

module Django
  #--------------------------
  # User
  class User < ActiveRecord::Base
    self.table_name = "auth_user"
    
    has_many :django_user_permissions, class_name: "Django::UserPermission"
    has_many :django_user_groups, class_name: "Django::UserGroup"

bricker

# A simple, stupid script that counts how many times a letter occurs 
# in the english translation of each number from 0 to MAX_NUM.
# Doesn't include the joining word "and" in numbers like "one hundred and two"
#
# NOTE: You need to install two gems to run this script:
# * loggability (linguistics depends on it but doesn't install it as a dependency for some reason)
# * linguistics
require 'linguistics'
Linguistics.use(:en)

bricker

"Russian-Doll Caching" is great. It embraces the Rails (and Ruby) goal to "make the developer happy". And it does. Not having to worry about cache expiration is superb.

It has its limits, though. If you're trying to avoid any database queries, russian-doll caching will not work for you. If you are trying to represent thousands, or even hundreds, of objects under a single cache fragment, russian-doll caching is not the best option.

We use it whenever it makes sense, but sometimes we just have to bite the bullet and expire a cache fragment manually. When you want to start manually expiring cache on a fairly busy website, you have to start considering race conditions. I recently ran into the following scenario:

class Post < ActiveRecord::Base
  after_save :expire_cache
  

bricker

##
# Unique By Date validator
# Makes sure an attribute is unique by a specified day, month, year, etc.
# This validator is heavily based on ActiveRecord::Validations::UniquenessValidator
#
# It uses the `beginning_of_*` and `end_of_*` methods to
# specify the range of dates for which the attribute must be unique
# ActiveSupport::CoreExtensions::Date::Calculations
# http://apidock.com/rails/ActiveSupport/CoreExtensions/Date/Calculations
#