Mike Ferrier

Rescuing multiple exception types in Ruby and binding to local variable

2012-05-19T00:00:00-04:00

Took me a few minutes to figure this out and wasn't easy to Google, so hopefully this helps someone out.

Rescuing multiple exceptions in one rescue clause is pretty intuitive:

begin
  i = rand(2)
  i == 0 ? ([] + '') : (foo)
rescue TypeError, NameError
  puts "oops"
end

I wanted to also bind the exception, whatever it is, to a local variable. To do that for a single exception is like:

begin
  [] + ''
rescue TypeError => e
  puts "oops: #{e.message}"
end

To combine the two, list the exceptions and then name the local variable with the last type in the list:

begin
  i = rand(2)
  i == 0 ? ([] + '') : (foo)
rescue TypeError, NameError => e
  puts "oops: #{e.message}"
end

Using Google Latitude to map your travel

2012-01-14T00:00:00-05:00

Melissa and I just got back from our mini-rtw trip to Asia, during which we had data roaming on our phones. I kept the Google Latitude app open in the background, which pings your location to Google every so often.

When I got back and took a look at the map, the results were pretty cool. Some highlights:

Here's us going all over the place in Tokyo, with our home base in Shibuya. You can see the Yamanote Line loop mapped out clearly. You can also see our trip to the Imperial Palace in Chiyoda for the Emperor's New Year's address.

During our Hong Kong stop we took the Turbo Jetfoil to Macau -- you can see the ferry's path above.

In Hong Kong we stayed in Aberdeen, which is on the south side of Hong Kong island. Every day we would take a taxi up to the north side which would cost about $60 HKD, or around $8 CAD. As you can see, sometimes the cab took the toll tunnel, other times the winding mountain roads. Also apparently we hung out in Wan Chai and Causeway Bay a lot.

Here's the entire trip if you'd like to play around with it:

View Asia Trip 2011 in a larger map

Fake Cookie Store for Rails Unit Tests

2011-11-25T00:00:00-05:00

While writing tests for an AB testing library, I needed to simulate a Rails cookie store, but I didn't want to do any controller requests. Without doing a controller request, you aren't given any cookie store to test with, so I whipped up this fake cookie store that seems to work pretty well.

class FakeCookieStore < Hash
  # allow for things like cookies.permanent.signed etc
  def method_missing(name, *args, &block); self; end

  def []=(key, value)
    # simulate cookies[key] = {:value => 'foo'}
    if value.is_a?(Hash) && (v = value[:value])
      super(key, v)
    else
      super
    end
  end
end

Granting access to a single S3 bucket using Amazon IAM

2011-10-27T00:00:00-04:00

If you've ever used Amazon's AWS console then you probably know that though sometimes it can be clunky, it has a ton of functionality for interacting with the various AWS serivces. So when I needed to give one of my coworkers at 4ormat access to one of our S3 buckets, I immediately investigated the laziest option: figuring out how they could login to the S3 console and use that to manage the bucket.

The S3 console is pretty great. Uploading, downloading, creating folders, managing permissions, even copying and pasting buckets between files is a snap. If I could figure this out, I would save myself all the work of setting up S3Fox or even worse, writing an interface from scratch.

After some trial and error, success! I've written a quick guideline on how to do this below.

1. Login to the IAM AWS console

2. Create an account alias

This step is optional, but it gives you a nice login URL for your users. Add an account alias in the AWS Account Alias section of the IAM console. Then, your login URL will be youralias.signin.aws.amazon.com.

If you don't do this, your login page URL will be a bunch of random numbers.

3. Create a new group or a new user

With IAM you can create a group that has certain permissions, and then assign users to that group. Or, you can just create users piecemeal, but then you can't reuse permissions.

If you want a group, create it first. Then create a user and assign it to that group.

4. Set a password for the new user

Click the new user you've created and then click the Security Credentials tab. On that page, you can click Manage Password to add a password for your user. Without a password, the user won't be able to login to the AWS console.

Make sure your user knows to use the login page from step #2 in order to login — they can't use the regular AWS login page.

You'll notice your user also has a AWS access key created: API clients using this key will have the same permissions as the user would in the AWS console.

5. Add permissions for your user

Permissions are added either on the group the user is in, or if you decided not to create a group, the user account itself.

Click the user or group, then click the Permissions tab. Here you can see which permissions policies are currently attached to the group or user. Click the Attach Policy button. You'll get a pop-up where you can Manage User Permissions. Here you can select a prerolled policy, use the Policy Generator, or just paste in a custom policy.

There are two permissions that need to be added in order for your user to be able to login, see the bucket list in the S3 console, and manage the one bucket you've assigned.

To manage the bucket, you need to grant the s3:* action for the bucket you designate. AWS policies designate resources by their Amazon Resource Name, or ARN and for S3 buckets, they look like: arn:aws:s3:::bucket-name-here. So to grant your user full access to your bucket, you'd paste the policy:

{
  "Statement": [
    {
      "Action": "s3:*",
      "Effect": "Allow",
      "Resource": [
        "arn:aws:s3:::4ormat-knowledge-base",
        "arn:aws:s3:::4ormat-knowledge-base/*"
      ]
    }
  ]
}

Now, you would think that this would be enough to enable the user to use the S3 console to manage the bucket, but you'd be wrong. Turns out the user needs one more permission to do the initial listing of the buckets in order to be able to select a bucket, and its called s3:ListAllMyBuckets. You need to add that permissions too, and it looks like this:

{
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:ListAllMyBuckets",
      "Resource": "arn:aws:s3:::*"
    }
  ]
}

6. Done!

You're done. Give the user their credentials and the login page, and then bask in the glory of laziness.

Vintages Values October 2011, Part Deux

2011-10-23T00:00:00-04:00

As promised in the previous post, I wrote a little widget so you can weight the different ratings sources that the LCBO uses. The table will re-sort when you change a weighting.

Value is still calculated as critic rating points per dollar per millilitre, but then that value is multiplied by the source weighting.

Any more suggestions, let me know in the comments.

Thanks to @modernmod for the idea.

Vintages Values October 2011

2011-10-01T00:00:00-04:00

It's that time again. Vintages' October releases are here, and so is my faithful scraper script: bringing you the best values in the latest batch of Vintages releases.

As with the previous post, value is calculated as critic rating points per dollar per millilitre. I'm working on a little something that will let you, faithful reader, set weightings per critic.

I should have something interested hooked up for next month. Watch for that!

Without further ado...

Compiling EEE for Rubyscript2Exe on Mac OSX

2011-05-29T00:00:00-04:00

If you're having problems compiling EEE for Rubyscript2Exe or AllInOneRuby on OSX, this post will explain how to modify the source to compile properly.

Rubyscript2Exe is a framework to "transform your Ruby application into a standalone, compressed Windows, Linux or Mac OS X (Darwin) executable." To do so, it depends on a little Pascal program called Environment Embedding Executable, or EEE. It doesn't look like this stuff has been updated in a while, because I had problems compiling it on my OSX system. It seems that the EEE source code is not compatible with the latest FreePascal compiler.

After downloading and installing the latest fpc, compiling barfs out some errors:

$ fpc -Xs -B eee.pas
Free Pascal Compiler version 2.4.4 [2011/05/01] for i386
Copyright (c) 1993-2010 by Florian Klaempfl
Target OS: Darwin for i386
Compiling eee.pas
eee.pas(151,49) Error: Parameters cannot contain local type definitions. Use a separate type definition in a type block.
eee.pas(172,29) Error: Parameters cannot contain local type definitions. Use a separate type definition in a type block.
eee.pas(204,43) Error: Parameters cannot contain local type definitions. Use a separate type definition in a type block.
eee.pas(395,52) Error: Parameters cannot contain local type definitions. Use a separate type definition in a type block.
eee.pas(395,70) Error: Parameters cannot contain local type definitions. Use a separate type definition in a type block.
eee.pas(395,90) Error: Parameters cannot contain local type definitions. Use a separate type definition in a type block.
eee.pas(421,52) Error: Parameters cannot contain local type definitions. Use a separate type definition in a type block.
eee.pas(421,70) Error: Parameters cannot contain local type definitions. Use a separate type definition in a type block.
eee.pas(421,90) Error: Parameters cannot contain local type definitions. Use a separate type definition in a type block.
eee.pas(444,52) Error: Parameters cannot contain local type definitions. Use a separate type definition in a type block.
eee.pas(444,70) Error: Parameters cannot contain local type definitions. Use a separate type definition in a type block.
eee.pas(444,90) Error: Parameters cannot contain local type definitions. Use a separate type definition in a type block.
eee.pas(489,52) Error: Parameters cannot contain local type definitions. Use a separate type definition in a type block.
eee.pas(489,70) Error: Parameters cannot contain local type definitions. Use a separate type definition in a type block.
eee.pas(489,90) Error: Parameters cannot contain local type definitions. Use a separate type definition in a type block.
eee.pas(512,52) Error: Parameters cannot contain local type definitions. Use a separate type definition in a type block.
eee.pas(512,70) Error: Parameters cannot contain local type definitions. Use a separate type definition in a type block.
eee.pas(512,90) Error: Parameters cannot contain local type definitions. Use a separate type definition in a type block.
eee.pas(535,52) Error: Parameters cannot contain local type definitions. Use a separate type definition in a type block.
eee.pas(535,70) Error: Parameters cannot contain local type definitions. Use a separate type definition in a type block.
eee.pas(535,90) Error: Parameters cannot contain local type definitions. Use a separate type definition in a type block.
eee.pas(1164) Fatal: There were 21 errors compiling module, stopping
Fatal: Compilation aborted
Error: /usr/local/bin/ppc386 returned an error exitcode (normal if you did not specify a source file to be compiled)

$

Turns out fpc has a problem with local type definitions in function parameters, and it considers static-length string identifiers, such as string[255], to be type definitions. Apparently this was not so when eee.pas was first written, because the function definitions are full of string[1]s and string[255]s.

To fix, we simply have to define both of those types on their own, and then replace all references to these types with the name of the defined types. Here's how I did it.

First I added the types, one for string[1] and one for string[255]:

type
  string255 = string[255];

type
  string1 = string[1];

Then I replaced all occurences of string[1] with string1, and string[255] with string255, e.g.:

type

  header =  record
    klasse  : string1;
    tekst    : string255;
    datalength  : longint;
  end;

Once these changes are made, compiling is no problem:

$ fpc -Xs -B eee_fixed.pas
Free Pascal Compiler version 2.4.4 [2011/05/01] for i386
Copyright (c) 1993-2010 by Florian Klaempfl
Target OS: Darwin for i386
Compiling eee_fixed.pas
Assembling (pipe) eee_fixed.s
Linking eee_fixed
1169 lines compiled, 0.4 sec

$

You can download eee.pas with these changes made here.

My pascal is pretty rusty, so if anyone has any pointers on improving this code, please let me know in the comments.

My beautiful dark twisted reverse-proxy LRU cache

2011-05-14T00:00:00-04:00

Reverse-proxy caching is generally one of the low-hanging fruit of scaling a site. If your reverse proxy is nginx, then you've probably seen the modules HttpMemcachedModule and HttpRedis, both of which are pretty good at fetching from memcached or redis based on a simple key.

The config would look a little something like this:

server {
  location / {
    set $memcached_key $uri;
    memcached_pass     redis_server:11211;
    default_type       text/html;
    error_page         404 @fallback;
  }
 
  location @fallback {
    proxy_pass backend;
  }
}

But what if you want to do something a bit more complex? Say you wanted to do namespaced caching, where there are two cache operations per request: one to fetch the version number of the requested resource, and a second to fetch the actual cached data from a key which interpolates the value of the first operation. Since HttpRedis only allows you to fetch values from redis based on a key computed in your nginx script, this isn't possible.

Enter the nginx modules Redis2 and Lua. The former allows you to make any call you like to redis, as opposed to HttpRedis which only allows the plain old GET command. The latter allows you do embed Lua scripts in your nginx config, effectively giving nginx a bigger brain and allowing you to do some pretty fancy stuff.

In this post we'll set nginx and redis up to serve as a reverse-proxy LRU cache. We recently started using this setup on 4ormat and it's sped up our site considerably and offloaded the hits to the application server by around 91%!

Install lua and redis.parser
Build nginx with module support
Redis structure
Configure nginx
Cache script
Configure Redis
Configure your app
Conclusion and Benchmark

1. Install lua and redis.parser

In order to build the nginx lua module, you'll need lua installed on your system. We also need the redis.parser library in order to easily parse raw redis responses.

On most systems, lua is already installed or is easily installed with your local package manager.

OSX:

brew install lua

Ubuntu:

sudo apt-get install lua

Gentoo:

sudo emerge lua

Once that's done, you just need the redis.parser library:

$ curl https://github.com/agentzh/lua-redis-parser/tarball/v0.04 -s -L -o lua-redis-parser.tar.gz

$ tar zxvf lua-redis-parser.tar.gz
...untar output...

$ cd agentzh-lua-redis-parser-ceffe35

On Linux, you can just type make to build, but on OSX I found you have to do it by hand:

# linux:
$ make
# osx:
$ gcc -I/usr/local/Cellar/lua/include/ -O2 -fPIC -Wall -Werror -o parser.lo -c redis-parser.c
$ gcc -o parser.so -bundle -undefined dynamic_lookup -fomit-frame-pointer parser.lo

Then, install the library:

$ sudo make INSTALL_PATH=/usr/local/lib/lua/5.1/ install

2. Build nginx with module support

Nginx does not support dynamic module loading, so in order to build new functionality into nginx you need to recompile it with the appropriate modules.

Here's how I do it:

$ curl http://nginx.org/download/nginx-1.0.0.tar.gz -s -O
$ curl http://mdounin.ru/hg/ngx_http_upstream_keepalive/archive/tip.tar.gz -s -o ngx_http_upstream_keepalive.tar.gz
$ curl https://github.com/chaoslawful/lua-nginx-module/tarball/v0.1.6rc5 -s -L -o lua-nginx-module.tar.gz
$ curl https://github.com/agentzh/set-misc-nginx-module/tarball/v0.21rc3 -s -L -o set-misc-nginx-module.tar.gz
$ curl https://github.com/simpl/ngx_devel_kit/tarball/v0.2.17rc2 -s -L -o ngx_devel_kit.tar.gz
$ curl https://github.com/agentzh/redis2-nginx-module/zipball/v0.06 -s -L -o redis2-nginx-module.tar.gz
$ for f in *.gz; do tar xzvf $f; rm -f $f; done
...untar output...

$ ls -1
agentzh-redis2-nginx-module-62f5b6a
agentzh-set-misc-nginx-module-4b0512a
chaoslawful-lua-nginx-module-0e0b0fc
nginx-1.0.0
ngx_http_upstream_keepalive-c6396fef9295
simpl-ngx_devel_kit-bc97eea

$ cd nginx-1.0.0
$ ./configure \
>     --prefix=/opt \
>     --conf-path=/etc/nginx/nginx.conf \
>     --add-module=../agentzh-redis2-nginx-module-62f5b6a \
>     --add-module=../agentzh-set-misc-nginx-module-4b0512a \
>     --add-module=../chaoslawful-lua-nginx-module-0e0b0fc \
>     --add-module=../ngx_http_upstream_keepalive-c6396fef9295 \
>     --add-module=../simpl-ngx_devel_kit-bc97eea \
>     --add-module=/usr/local/rvm/gems/ruby-1.8.7-p330@default/gems/passenger-3.0.6/ext/nginx

...configure output...

Configuration summary
  + using system PCRE library
  + OpenSSL library is not used
  + md5: using system crypto library
  + sha1: using system crypto library
  + using system zlib library

  nginx path prefix: "/opt"
  nginx binary file: "/opt/sbin/nginx"
  nginx configuration prefix: "/etc/nginx"
  nginx configuration file: "/etc/nginx/nginx.conf"
  nginx pid file: "/opt/logs/nginx.pid"
  nginx error log file: "/opt/logs/error.log"
  nginx http access log file: "/opt/logs/access.log"
  nginx http client request body temporary files: "client_body_temp"
  nginx http proxy temporary files: "proxy_temp"
  nginx http fastcgi temporary files: "fastcgi_temp"
  nginx http uwsgi temporary files: "uwsgi_temp"
  nginx http scgi temporary files: "scgi_temp"

$ make
...make output...

$ make install
...install output...

A lot of these modules were written by the very awesome agentzh, so a big thanks to him. He's working on something very exciting, a full fledged web application server in nginx and lua! Will definitely be keeping my eye on that project.

You'll notice I add the Phusion Passenger module in with the path to my gem. You can omit that if you're not using Passenger.

3. Redis structure

This is a good time to figure out where things are going to live in redis. We have two bits of information we need to store:

Resource versions, which will be numbers that we increment when something changes in the app in order to invalidate the cache
Cached content, which will be written by the app after a cacheable request is complete, so that future requests can be served from cache

For this post, I'm storing the resource version numbers in "resource_versions", which will be a hash keyed by the request URI. The cached content itself will live in the root of the redis database, keyed by the request URI plus ":version=n", where n is the resource version. Like this:

{
  "resource_versions": {
    "http://myproject.dev/": 1,
    "http://myproject.dev/foos": 2,
    "http://myproject.dev/foo/123": 3,
  },
  "http://myproject.dev/:version=1": "<html>...</html>",
  "http://myproject.dev/foos:version=2": "<html>...</html>",
  "http://myproject.dev/foo/123:version=3": "<html>...</html>",
}

Why not also store the cached content in a hash? The redis LRU eviction policy evicts keys from the root of the hash when the memory limit is reached; if there were only two keys, then either all our cached content would be evicted, or all our resource versions. Storing the cached content in the root ensures that it will be a least recently used bit of HTML that gets evicted.

4. Configure nginx

First thing you need to do is an an upstream block in your nginx.conf pointing to your redis server:

# keepalive connection pool to a single redis running on localhost
upstream redis {   
  server localhost:6379;

  # a pool with at most 1024 connections
  # and do not distinguish the servers:
  keepalive 1024 single;
}

Keepalive connections are more efficient than creating a new connection to redis every time; this is enabled by the the ngx_http_upstream_keepalive module compiled into nginx.

Nginx has a powerful internal system called subrequests. It basically allows complex request rerouting internally to nginx that remains transparent to both the client and application. In this nginx config, internal locations are used to pass off requests further down the chain as necessary.

server {
  listen 80;
  server_name myproject.dev;
  root /Users/mferrier/dev/myproject/public;
  
  location / {
    # try to serve files directly from root, otherwise pass to @cache
    try_files $uri @cache;
  }

  location @cache {
    internal;
    default_type   text/html;

    set $full_uri $scheme://$host$request_uri;

    content_by_lua_file '/Users/mferrier/dev/myproject/config/nginx.cache.lua';

    error_page     404 = @app; 
  }

  location @app {
    internal;
    passenger_enabled on;
  }
}

First we check for the existence of the requested file in the filesystem. If it doesn't exist, we pass control to @cache. @cache uses the content_by_lua_file directive from the Lua nginx module to specify that the content for this request should be generated by an external lua script. If that script returns a 404, then we pass control down to @app. @app is our application, in this case a Rails app handled by Passenger.

The equals sign = after the error code specifies to ultimately use the response code returned by @app rather than the 404 returned by @cache.

We also need some internal locations to simplify the querying of redis. Our structure will require GET requests for the cached content in the root of the database, and HGET requests for the resource versions stored at resource_versions.

# requires the "key" argument
# http://redis.io/commands/get
location /redis_get {
  internal;
  set_unescape_uri $key $arg_key;
  redis2_query get $key;

  redis2_connect_timeout 200ms;
  redis2_send_timeout 200ms;
  redis2_read_timeout 200ms;
  redis2_pass redis;
  
  error_page 500 501 502 503 504 505 @empty_string;
}

# requires the "hash_key and "key" argument
# http://redis.io/commands/hget
location /redis_hget {
  internal;
  set_unescape_uri $key $arg_key;
  redis2_query hget $arg_hash_key $key;

  redis2_connect_timeout 200ms;
  redis2_send_timeout 200ms;
  redis2_read_timeout 200ms;
  redis2_pass redis;
  
  error_page 500 501 502 503 504 505 @empty_string;
}

# returns an empty string
location @empty_string {
  internal;
  content_by_lua 'ngx.print("")';
}

Both /redis_get and /redis_hget are meant to be used in an ngx_lua block with ngx.location.capture and redis.parser.parse_reply (more on that in the next step.)

You'll also notice some sensible timeouts, and we pass control of any errors to the @empty_string internal location, defined last. This location serves as a rescue, and returns an empty string back to @cache, which treats an empty string as a cache miss. So if the redis server goes away or takes too long, it ends up being a cache miss rather than a 500 on the request.

All that is needed now is the lua script which will check for cached content in redis, and either return that content or return a 404 if it wasn't found.

5. Cache script

In the previous step, we specified that the content for the @cache internal location was to be handled by the script nginx.cache.lua. Every incoming request which isn't a request for a static file will be handled by this script, and it will either return some cached content, or pass the request along to @app.

This script needs to:

Determine if the request is cacheable based on the request method and request path, and return HTTP_NOT_FOUND if it isn't
Try to grab the current version of the requested resource from redis, and return HTTP_NOT_FOUND if it doesn't exist
Construct the cached content key for the requested resource from the result of the previous step
Try to grab the cached content from redis using the cached content key from the previous step, and return HTTP_NOT_FOUND if no cached content is found Otherwise, we have a cache hit and can return the cached content

Remember, a 404 response code in the @cache location causes control to be passed to @app.

if (ngx.var.request_method ~= "GET" and ngx.var.request_method ~= "HEAD") then
  ngx.log(ngx.NOTICE, "@cache: skipping uncacheable request method: ", ngx.var.request_method)
  ngx.exit(ngx.HTTP_NOT_FOUND)
end

-- lua patterns, not regexes
local cacheable_resource_matchers = {
  "^/$",
  "^/foo",
}

-- whether the request is cacheable
local cacheable = false

for i, matcher in ipairs(cacheable_resource_matchers) do
  if (string.find(ngx.var.uri, matcher)) then
    ngx.log(ngx.NOTICE, "@cache: cacheable request found: ", ngx.var.host, ngx.var.uri)
    cacheable = true
    break
  end
end

if (cacheable == false) then
  ngx.log(ngx.NOTICE, "@cache: skipping uncacheable request: ", ngx.var.host, ngx.var.uri)
  ngx.exit(ngx.HTTP_NOT_FOUND)
end

-- parser object that will receive redis responses and parse them into lua objects
local parser = require("redis.parser")

-- key in redis that stores the resource version numbers
local version_hash_key = "resource_versions"

-- full uri of the request, used to construct the cache key
local full_uri = ngx.var.scheme.."://"..ngx.var.host..ngx.var.request_uri

-- key under which the current version of this resource is stored
local version_key = ngx.var.request_uri
local response_body = ngx.location.capture("/redis_hget", 
    {args = {hash_key = version_hash_key, key = version_key}}).body
local res, typ = parser.parse_reply(response_body)

if (typ == parser.BULK_REPLY and not(res == nil) and (#res > 0)) then
  ngx.log(ngx.NOTICE, "@cache: cache HIT on version key ", version_key, ", value: ", res)

  local version_value = tonumber(res)
  local cache_key = string.format("%s:version=%s", full_uri, version_value)
  local response_body = ngx.location.capture("/redis_get", 
      {args = {key = cache_key}}).body
  local res, typ = parser.parse_reply(response_body)

  if (typ == parser.BULK_REPLY and not(res == nil) and (#res > 0)) then
    ngx.log(ngx.NOTICE, "@cache: cache HIT on cache key: ", cache_key, ", content length: ", #res)
    ngx.print(res)
    ngx.exit(ngx.OK)
  else
    ngx.log(ngx.NOTICE, "@cache: cache MISS on cache key: ", cache_key)
  end
else
  ngx.log(ngx.NOTICE, "@cache: cache MISS on version key: ", version_key)
end

ngx.exit(ngx.HTTP_NOT_FOUND)

In this script we do opt-in caching: only the locations we specify in cacheable_resource_matchers are eligible to be cached. The opposite of this would be opt-out caching, where everything is cached unless we specify it shouldn't be. I find opt-in caching to be safer, because it's generally worse to cache something that shouldn't be rather than not cache something that should be.

The cacheable resource matchers are Lua Patterns, which are kind of like regular expressions, but a bit less powerful: you can't use the logical OR operator "|". If you need full blown regular expressions, there are lua regex libraries you can install.

One of the great things about the lua nginx module is that code is automatically cached between requests. That means you don't have to worry about the require statement in the lua script; it will only ever happen once.

6. Configure Redis

Adding these two lines to your redis config will ensure that your memory usage never exceeds the limit you set:

maxmemory 64mb
maxmemory-policy allkeys-lru

7. Configure your app

All that remains to be done at this point is to set up your app so that it will do two things:

Write back the result of a cacheable request to redis
Increment the resource version when a resource is updated

Most of this should be customized to your particular app, but here's the basic framework I use in Rails.

First we need to set up redis and the around_filter in ApplicationController:

config/initializers/redis.rb

REDIS_CONFIG = YAML.load_file(Rails.root.join('config', 'redis.yml'))[Rails.env].with_indifferent_access
$REDIS = Redis.new REDIS_CONFIG

app/controllers/application_controller.rb:

class ApplicationController < ActionController::Base
  around_filter Cache
end

app/controllers/cache.rb:

module Cache
  CACHEABLE_RESOURCE_MATCHERS = [
    "^/$", 
    "^/foo",
  ]
  
  VERSION_HASH_KEY = "resource_versions"
  CACHE_KEY_FORMAT   = "%s:version=%s"
  
  def request_cacheable?(request)
    return false unless (request.method == "GET" || request.method == "HEAD")
    CACHEABLE_RESOURCE_MATCHERS.any? do |pattern|
      request.path =~ /#{pattern}/
    end
  end
  
  def response_cacheable?(response)
    response.status == 200
  end
  
  def version_key_for_request(request)
    "#{request.scheme}://#{request.host}#{request.fullpath}"
  end
  
  def version_value_for_request(request)
    query_safely do |cache|
      cache.hget(VERSION_HASH_KEY, version_key_for_request(request))
    end
  end
  
  def cache_key_for_request(request, version = 0)
    full_url = "#{request.scheme}://#{request.host}#{request.fullpath}"
    CACHE_KEY_FORMAT % [full_url, version]
  end
  
  def cache_response(request, response, version_value)
    query_safely do |cache|
      cache.multi do
        # if version value is nil, ensure it hasn't been set since the beginning
        # of this request so that we don't clobber it
        version_value ||= version_value_for_request(request)
        if version_value.nil?
          version_key = version_key_for_request(request)
          log %{initializing version key "#{version_key}" with value "0"}
          cache.hset(VERSION_HASH_KEY, version_key, 0)
          version_value = 0
        end

        cache_key = cache_key_for_request(request, version_value)
        log %{writing cache: key = "#{cache_key}", content length #{response.body.length})}
        cache.set(cache_key, response.body)
      end
    end
  end
  
  
  def filter(controller)
    if request_cacheable?(controller.request)
      version_value = version_value_for_request(controller.request)
      yield
      if response_cacheable?(controller.response)
        cache_response(controller.request, controller.response, version_value)
      end
    else
      yield
    end
  end
  
  def invalidate_cache_for_url(url)
    query_safely do |cache|
      cache.hincrby(VERSION_HASH_KEY, url, 1)
    end
  end
  
  def log(msg, level = :info)
    Rails.logger.send(level, %{[CACHE] #{msg.to_s}})
  end
  
  # yields the redis client, but catches connection errors. use this when you 
  # don't mind if your cache operation fails silently.
  def query_safely
    begin
      yield $REDIS
    rescue Errno::ECONNREFUSED
      log %{ERROR: Connection refused while connecting to redis! Discarding query silently.}, :warn
    rescue Errno::EAGAIN
      log %{ERROR: Connection timeout while querying redis! Discarding query silently.}, :warn
    end
  end
end

It has been said that there are only two hard problems in computer science: naming things and cache invalidation. Implementing effective cache invalidation for your particular application is left as an exercise for the reader, but as an example let's say you have a Foo model whose current state affects the paths /foos and /foo/:id. You could write an observer like this:

app/models/foo_observer.rb:

class FooObserver < ActiveRecord::Observer
  def after_save(record)
    return unless record.changed?

    afftected_urls(record).each do |u|
      Cache.invalidate_cache_for_url u
    end
  end
  
  def after_destroy(record)
    afftected_urls(record).each do |u|
      Cache.invalidate_cache_for_url u
    end
  end
  
  def affected_urls(record)
    [
      "http://myproject.com/foos",
      "http://myproject.com/foo/#{record.to_param}",
    ]
  end
end

config/application.rb

module MyProject
  class Application < Rails::Application
    config.active_record.observers = :foo_observer
  end
end

8. Conclusion and Benchmark

By serving content from nginx, you can easily see 1000% improvement in requests per second served. From a baseline Rails app served on a High CPU Medium instance on EC2 that serves around 100 requests per second, here's a benchmark once the caching is added:

$ ab -n 1000 -c 100 http://testserver/
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking ocadportfolio.com (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests


Server Software:        nginx/0.8.54
Server Hostname:        testserver
Server Port:            80

Document Path:          /features
Document Length:        8357 bytes

Concurrency Level:      100
Time taken for tests:   0.970 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      8540096 bytes
HTML transferred:       8394800 bytes
Requests per second:    1031.12 [#/sec] (mean)
Time per request:       96.982 [ms] (mean)
Time per request:       0.970 [ms] (mean, across all concurrent requests)
Transfer rate:          8599.47 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        9   11   2.5     10      41
Processing:    22   83  32.2     84     263
Waiting:       11   73  32.4     74     254
Total:         32   94  32.6     95     274

Percentage of the requests served within a certain time (ms)
  50%     95
  66%    117
  75%    119
  80%    121
  90%    129
  95%    142
  98%    163
  99%    168
 100%    274 (longest request)

Over 1000 requests per second, with a 96ms mean request time, and less than 1ms mean time across all concurrent requests. This setup also has the nice side effect of being able to serve cached content even if the application is completely down. Not too shabby!

It's also worth noting that recently Salvatore Sanfilippo, author of redis, added experimental lua scripting to a side branch of redis. This seems to have gotten a lot of positive feedback from the community, and it should find its way into the master branch pretty soon. This basically adds the same embedded lua scripting support to redis, which means the same sorts of things implemented in nginx in this post could be achieved on the server side of redis without any special nginx modules.

Code for this post can be found here. If you have any questions, feel free to post in the comments.

If you enjoyed this post, feel free to upvote on hackernews.

Blogging with Jekyll, Haml, Sass, and Jammit

2011-04-29T00:00:00-04:00

It seems anyone who uses Jekyll to run their blog ends up blogging about the particular way they've set it up. So here's mine.

I came to Jekyll from Wordpress, which I found easy to set up but way too hard to change when something wasn't quite right. The great thing about Jekyll is that it doesn't generate anything on the fly — all HTML is generated at once, meaning your web server only has to serve raw files. Less moving parts, less things that can break.

Haml/Sass for both templates and layouts

First thing I noticed was a lack of Haml and Sass support, which simply wouldn't do. Once you've had a taste of concise HTML/CSS, you never want to go back. While Jekyll doesn't support either out of the gate, a quick Googling revealed a very simple Haml/Sass converter script, which I added in _plugins/haml_converter.rb:

module Jekyll
  require 'haml'
  class HamlConverter < Converter
    safe true
    priority :low

    def matches(ext)
      ext =~ /haml/i
    end

    def output_ext(ext)
      ".html"
    end

    def convert(content)
      engine = Haml::Engine.new(content)
      engine.render
    end
  end

  require 'sass'
  class SassConverter < Converter
    safe true
    priority :low

     def matches(ext)
      ext =~ /sass/i
    end

    def output_ext(ext)
      ".css"
    end

    def convert(content)
      engine = Sass::Engine.new(content)
      engine.render
    end
  end
end

So far, so good. One problem though, Jekyll doesn't evaluate layouts through markup converters the same way it does with posts, so my layouts will have to be in plain HTML. Or will they? I stuck my haml layouts in _layouts/haml, and added a rake task, also lifted from Google, to Haml-ize any layouts:

desc "Parse haml layouts"
task :parse_haml do
  print "Parsing Haml layouts..."
  system(%{
    cd _layouts/haml && 
    for f in *.haml; do [ -e $f ] && haml $f ../${f%.haml}.html; done
  })
  puts "done."
end

Add a pair of rake tasks to run jekyll one-time or in preview mode:

desc "Launch preview environment"
task :preview do
  Rake::Task["parse_haml"].invoke
  system "jekyll --auto --server"
end

desc "Build site"
task :build do |task, args|
  Rake::Task["parse_haml"].invoke
  system "jekyll"
end

Minify assets with Jammit

Jammit is an "industrial strength asset packaging library for Rails" which combines groups of js scripts and css files into single asset files, then runs those assets through minifiers which shrink them and hopefully makes your pages load a bit faster. Jekyll is not Rails, but you can get Jammit working without too much trouble.

First off, you need a YAML config file to configure Jammit. I put mine in _assets.yml with the following contents:

javascript_compressor: closure

javascripts:
  application:
    - _site/js/jquery-1.5.2.js
    - _site/js/jquery.cookie.js
    - _site/js/jquery.twitter.js
    - _site/js/app.js

stylesheets:
  screen:
    - _site/css/screen.css
    - _site/css/syntax.css

Now when I run jammit -o assets -c _assets.yml, I get nice streamlined javascript and css assets. However, one of the things Jammit does with Rails is add in helper methods for including the groups of assets into your template files. To emulate this, I had to add some special tags to Jekyll.

Jekyll uses Liquid for templating, and adding new tags in Liquid is easy. _plugins/asset_tag.rb:

class AssetTag < Liquid::Tag
  CONFIG = YAML.load_file("_assets.yml")
  
  def initialize(tag_name, name, kind, tokens)
    super tag_name, name, tokens
    @name   = name.to_s.strip
    @kind   = kind.to_s
  end

  def render(context)
    if Jekyll::ENV == 'production'
      markup "/assets/#{name_with_ext}"
    else
      (assets_for_name.map do |asset|
        markup "#{@path}/#{asset}"
      end).join("\n")
    end
  end
  
  def name_with_ext
    "#{@name}.#{@ext}"
  end
  
  def assets_for_name
    if CONFIG[@asset_type].include?(@name)
      CONFIG[@asset_type][@name].map do |asset|
        asset.gsub(/_site\/(css|js)\//, '')
      end
    else
      name_with_ext
    end
  end
end



class IncludeJsTag < AssetTag
  def initialize(tag_name, name, tokens)
    @path = '/js'
    @ext = 'js'
    @asset_type = 'javascripts'
    super tag_name, name, 'js', tokens
  end
  
  def markup(src)
    %{<script src='#{src}' type='text/javascript'></script>}.to_s
  end  
end

Liquid::Template.register_tag('include_js', IncludeJsTag)



class IncludeCssTag < AssetTag
  def initialize(tag_name, name, tokens)
    @path = '/css'
    @ext = 'css'
    @asset_type = 'stylesheets'
    super tag_name, name, 'css', tokens
  end

  def markup(src)
    %{<link href='#{src}' media='screen' rel='stylesheet' type='text/css' />}.to_s
  end
end

Liquid::Template.register_tag('include_css', IncludeCssTag)

And then in my layout: I can use {% include_css screen %} and {% include_js application %}.

You may have noticed Jekyll::ENV == 'production' in there. I don't want to use my minified assets while I'm writing posts because if there's a javascript or css problem, it's much harder to debug minified code. So I introduce the concept of a Jekyll environment variable in _plugin/env.rb, where I simply check for the variable in the shell environment:

Jekyll::ENV = (ENV['JEKYLL_ENV'] || 'development')

And then we bring it all together in a rake task, to be run when I'm ready to push my latest changes up to my live blog:

desc "Package app for production"
task :package do
  ENV['JEKYLL_ENV'] = 'production'
  
  Rake::Task["build"].invoke

  print "Compressing assets..."
  system "jammit -o assets -c _assets.yml"
  puts "done."
end

Lastly, I have a rake task to deploy:

desc "Deploy latest code in _site to production"
task :deploy do
  system(%{
    rsync -avz --delete _site/ deploy@mikeferrier.com:/srv/www/mikeferrier.com/
  })
end

So my post-writing routine basically looks like this:

Start up jekyll with rake preview
Write a post
When I'm satified, run rake package deploy

Nice and simple. So far I'm loving the ease and flexibility, and not missing Wordpress one bit. Maybe one day I'll be able to convince Melissa to switch too (not bloody likely.)

Vintages Fancy Wine Deals May 2011

2011-04-28T00:00:00-04:00

I really don't know much about wine, except that I like drinking it. To help people like me, Vintages includes the ratings of the various wine critics in their upcoming release list, which, though clearly subjective, are somewhat of a good indicator of the highs and lows of the list. When I'm looking for the catalog's best values, I like to compare price vs. rating.

So for anyone else in Ontario who enjoys the value of a highly rated wine for cheap, here's the output of a script I wrote to pull down the latest VCC releases, calculate the value of each (as defined as rating points per dollar per millilitre), and sort descending by value. Enjoy!

Incidentally, my most knowledgeable wine buddy Duarte hinted that some critic points are more valuable than others. Next release I'll see if I can weight certain critic points higher than others. Snobbery!

Also, for general LCBO searching, skip the official website and go right to Carsten Nielsen's lcbosearch.com (based on his awesome lcboapi.com). It's about 1000% better looking and easier to use.

Sailing to Norway

2011-04-24T00:00:00-04:00

Gmail tried to auto-translate a test email I sent myself:

I always suspected Norwegian was a fake language.

Using Pow for local development

2011-04-22T00:00:00-04:00

Shortly after my post on setting up wildcard DNS on localhost domains on OSX, there was a much-needed breakthrough in the realm of ruby localhost development. Sam Stephenson introduced Pow, which aims to simplify the running of multiple development apps on localhost.

Rather than manually run standalone webservers (ugh), or add entries to an nginx+passenger config file (less ugh), with Pow you can simply symlink your myproject directory into ~/.pow and then hit http://myproject.dev and things will just work.

How's this work? Well, Pow is a node app running on localhost which has two functions:

Serving rack apps
Serving DNS requests

When you symlink a project directory into ~/.pow, you're telling Pow that a Rack app lives there. Pow listens on localhost:80 for http requests, and based on the hostname requested, serves the appropriate Rack app.

Pow uses an interesting trick to get the *.dev URLs resolving to localhost: on installation it adds the file /etc/resolver/dev which on OSX acts as a DNS resolution config for the .dev domain. It instructs your computer to use the namserver at 127.0.0.1:20560 to resolve any domain with the TLD of .dev. The Pow server binds to that port and serves DNS for .dev domain requests — it resolves all hostnames to 127.0.0.1.

Pow also supports RVM and Bundler, so you can simultaneously run projects with different ruby versions and gemsets, a feat not currently possible with nginx+passenger without adding upstream proxying to standalone Passenger instances.

Overall a very welcome contribution to the ruby developer community. I'll be sticking with nginx+passenger for now as I require some special nginx modules for a few projects, but the next time a designer needs to get up and running on a project, it'll be much easier to get this done. I might even be able to do it without having to take over the keyboard.

Setting up a VPN for secure networking while traveling

2011-04-12T00:00:00-04:00

My wife and I tend to do a lot of traveling, both on business and for pleasure, and if you've ever spent time in airports, you know that internet access tends to come in the WEP flavour, usually with no password.

When Firesheep was released last year, it demonstrated how easy it is for those listening in on a wireless network to steal session cookies for popular sites, allowing them to login as the victim.

One way to protect yourself is to run all your traffic through a VPN while using an insecure network. I set mine up on my Linode using their instuctions "Secure Communications with OpenVPN", especially the part about "tunnelling all connections".

Once you've got that set up, you just need to install a VPN client; on OSX, I recommend Tunnelblick. It sits up in your menu bar, and connecting is as simple as choosing a dropdown option. Once connected, all your internet traffic is seamlessly routed through the VPN.

Since Firesheep was released, almost every site targeted has switched to enforcing https on all connections, but I still appreciate this extra layer of security while laptopping on the road. As an extra added bonus, it also allows me to access geo-restricted US sites like Hulu, but you didn't hear that from me.

Setting up wildcard DNS on localhost domains on OSX

2011-04-04T00:00:00-04:00

Like many other Rails developers, I've made the switch to using nginx+passenger for my local development on OSX. It's super easy to compile and install, especially if you use brew and having your nginx process serving all your development sites is a snap to configure.

The workflow for a new project generally goes like this: add your project directory, give that directory its own server{} block in nginx.conf, and then picking a local (i.e. fake) domain and pointing that domain at 127.0.0.1, or localhost. For instance, if I were to start projectx in ~/dev/projectx, I would then have to add the appropriate server{} block in nginx.conf, and then add projectx.local to my /etc/hosts file. When I hit http://projectx.local in my browser, it'll resolve to localhost and hit my local nginx, serving me my development site.

The one place where this kind of fails is when you need wildcard subdomains. That is to say, when you need *.projectx.local to point to localhost.

While working on 4ormat, we do a lot of testing on our local machines, and since we give users their own subdomains on 4ormat.com, it comes in handy to be able to map *.4ormat.local in our web browsers to the localhost. While nginx supports wildcard hostnames in its configuration file, /etc/hosts does not.

So what's the answer? Set up your own local nameserver. It's easier than you might think. OSX Snow Leopard ships with ISC Bind (the de facto standard for serving DNS) and it's pretty easy to get going. Here's how to do it.

(big thanks to Geoff Hankerson's post which helped kickstart this process)

1. Generate an rndc key

rndc is a utility that allows you to admin the bind server remotely, and by default the Bind config looks for a key, so start by generating one:

$ sudo rndc-confgen -a -c /etc/rndc.key
wrote key file "/etc/rndc.key"

2. Add your .local top level domain as a zone

Edit /etc/named.conf and add the following block, called a "zone":

zone "local" IN {
type master;
file "local.zone";
allow-update { none; };
};

Add it on its own lines right after one of the existing "zone" blocks.

3. Add the .local zone file

The line file "local.zone" in named.conf sets the name of the file where bind will look for information on that zone. Those zone files live in /var/named so next we add the file /var/named/local.zone

Here's what mine looks like:

$TTL  60
$ORIGIN local.
@      1D IN SOA  localhost. root.localhost. (
          45    ; serial (d. adams)
          3H    ; refresh
          15M    ; retry
          1W    ; expiry
          1D )    ; minimum

      1D IN NS  localhost.
      1D IN A  127.0.0.1

*.local. 60 IN A 127.0.0.1
4ormat.local. 60 IN A 127.0.0.1
*.4ormat.local. 60 IN A 127.0.0.1

In a nutshell, this config says:

The authority on .local domains is localhost
The domains anything.local and anything.4ormat.local resolve to 127.0.0.1

The important line is the one that starts *.4ormat.local. That allows us to use wildcard domains that will all resolve to localhost which is something we can't do with /etc/hosts.

You'll want to replace 4ormat with the domain of your choice, and local with the suffix you want.

By the way, the trailing dots are no typo — they're Fully Qualified Domain Names. It's a good practice when dealing with DNS settings to use FQDNs, as they remove any ambiguity that might arise when referencing domain names.

4. Check your config and zone files

Bind comes with some handy utilities for checking your config and zone files.

$ sudo named-checkconf /etc/named.conf
$ sudo named-checkzone local /var/named/local.zone
zone local/IN: loaded serial 45
OK

The first command will have no output if your config is set up properly. The second should say "OK".

5. Start bind

An easy way to start up bind is to add it to the Launch Daemons of the root user:

sudo launchctl load -w /System/Library/LaunchDaemons/org.isc.named.plist

After running this command, launchd should have started up named automatically:

$ ps aux | grep named
root 2467 0.0 0.2 2441740 8380 ?? Ss 6:43pm 0:05.48 /usr/sbin/named -f

As an added bonus, this command makes sure named is automatically started on boot, too.

6. Verify things are working

dig is the swiss army knife of DNS tools, and is distributed with Bind, so it's already around on OSX. Asking localhost to resolve a few domains will verify things are working:

$ dig @localhost foo.local

; <<>> DiG 9.6.0-APPLE-P2 <<>> @localhost foo.local
; (3 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53309
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;foo.local. IN  A

;; ANSWER SECTION:
foo.local.    60  IN  A  127.0.0.1

;; AUTHORITY SECTION:
local.   86400  IN  NS  localhost.

;; ADDITIONAL SECTION:
localhost.    86400  IN  A  127.0.0.1

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Apr  4 17:13:51 2011
;; MSG SIZE  rcvd: 82


$ dig @localhost 4ormat.local

; <<>> DiG 9.6.0-APPLE-P2 <<>> @localhost 4ormat.local
; (3 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1431
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;4ormat.local.      IN  A

;; ANSWER SECTION:
4ormat.local.    60  IN  A  127.0.0.1

;; AUTHORITY SECTION:
local.      86400  IN  NS  localhost.

;; ADDITIONAL SECTION:
localhost.    86400  IN  A  127.0.0.1

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Apr  4 17:13:54 2011
;; MSG SIZE  rcvd: 85


$ dig @localhost foo.4ormat.local

; <<>> DiG 9.6.0-APPLE-P2 <<>> @localhost foo.4ormat.local
; (3 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43030
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;foo.4ormat.local.    IN  A

;; ANSWER SECTION:
foo.4ormat.local.  60  IN  A  127.0.0.1

;; AUTHORITY SECTION:
local.      86400  IN  NS  localhost.

;; ADDITIONAL SECTION:
localhost.    86400  IN  A  127.0.0.1

;; Query time: 0 msec

;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Apr  4 17:13:57 2011
;; MSG SIZE  rcvd: 89

The important part of each of those three queries is the IN A response in the ANSWER SECTION. In each, we see that the domains resolve to 127.0.0.1, which is exactly what we want.

7. Add 127.0.0.1 to your list of DNS servers

Open System Preferences and open the Network pane. On the left side, select the network adapter you use (most likely your wireless adapter), and then click Advanced. Under the DNS tab, click the + button under the DNS Servers list, and add 127.0.0.1. Click OK, then click Apply.

That's it, you're done.

Reloading Bind and flushing DNS

If you ever change anything in your config or zone files, you can signal Bind to reload its config using:

sudo rndc -p 54 reload

It's also a good practice to increment the serial field in your zone file any time anything changes. This lets any DNS client know to invalidate its DNS cache for that zone. So in our example, our serial is set to 45. So if you made any change, you'd change it to 46 before saving the file and reloading Bind.

Some people also reported that they needed to flush their local DNS cache after doing this (I didn't.) If you feel you need to, you can by issuing the command:

dscacheutil -flushcache