Archive for June, 2010

Drupal Linkshare Pixel Module Released

Monday, June 14th, 2010

I released a nice little module onto the Ubercart site today called “Linkshare Pixel.” This handly little module is will create an image tag that Linkshare requires you to put on your checkout page for tracking purposes. It takes care of building the URL out of the cart contents and store configurations, all you have to do is provide your Linkshare merchant ID.


Tags: ,
Posted in Information | 1 Comment »


Friday, June 11th, 2010

The Ruby community announced yesterday that August 19 will be “Why Day” (, in honor of whytheluckstiff. For most of use in the Ruby world, _why needs no explanation, for those who don’t, I demand you to go learn about him, and all the amazing work he did for this community. I can go into detail, and site resources, but he’s had such an impact, that learning about him will not be hard at all.

I will however, post a link to his song, “This book was made”, that came with his “Poignant Guide” book. This Book Is Made

Thanks _why.

Posted in Information | No Comments »

Working With Rack in Rails 3

Thursday, June 10th, 2010

While attending this year’s RailsConf in Baltimore, there was much excitement in the air about Rails 3. This was perpetuated by the fact that the Rails core team pushed Rails 3, Beta 3 & 4 during the conference. While there are so many awesome new things that Rails 3 is providing, and I strongly encourage everyone to move over to it as soon as they can, I want to talk today about Rack, and how it is allowing your to optimize your Rails app like never before.

Nice Rack.

If you are new to a lot of the things going on in Rails 3, you probably aren’t to familiar with the concept of Rack. The story goes like this: before Rails 3, all of the things that the Rails framework provides you, like session handling, parsing the parameters, and other conveniences that Rails provides you pertaining to requests, were tightly coupled to the Rails code base. In the early days of Rails, this was no big deal; we had these tools and we loved them. However, as Rails grew, and the apps built on Rails had more demanding requirements, we found situations where these conveniences add a lot of not needed overhead. For example, let’s say we wanted to have a Rails application whose sole responsibility was to accept uploaded files that we save to a server. You wouldn’t necessarily need session handling, cookies, flash, etc. Also, you may have written a great library that is better optimized or offers more hooks to certain ingrained Rails functionality for your application that you would like to use instead. Enter Rails 3.

In Rails 3, the framework gutted many of these great features out of the framework and into this concept of a Rack. We’ll talk about what Rack is in just a second, but it is important to note that the key advantage hear is that these awesome conveniences can be taken out of your application stack (or enhanced) to optimize them to suite your application’s need.

Anatomy of a Rack

Ok, ok … so what is a Rack? Rack is simply an interface that sits in between your web server and your application.

When a request comes into a Rails app, before it encounters your application code, it will run through your Rack. The rack is a daisy-chained library of classes, each of which have different responsibilities, all of which are the dominant set-ups that need to be done for every request (sessions, params, etc).


A Rack application is simply a class which defines a method, #call. This method receives a parameter, the current set up environment hash, commonly named “env”. The required return value of that method is an array composed of exactly three elements:

  • The status code (200, 404, etc.)
  • The headers for the request
  • The response body

Note: The response body must respond to #each, therefore you will commonly find it in an array ( [my_response]) or a class mixed in with Enumerable.

The next Rack application inline to fire in your middleware will make a call to #call when it initializes and will receive its return value (the response / header / body array) as a parameter to #initialize, commonly labeled “app”.

Enough talking, let’s looks at code.

module Rack

  # The Rack::Static middleware intercepts requests for static files
  # (javascript files, images, stylesheets, etc) based on the url prefixes
  # passed in the options, and serves them using a Rack::File object. This
  # allows a Rack stack to serve both static and dynamic content.
  # Examples:
  #     use Rack::Static, :urls => ["/media"]
  #     will serve all requests beginning with /media from the "media" folder
  #     located in the current directory (ie media/*).
  #     use Rack::Static, :urls => ["/css", "/images"], :root => "public"
  #     will serve all requests beginning with /css or /images from the folder
  #     "public" in the current directory (ie public/css/* and public/images/*)

  class Static

    def initialize(app, options={})
      @app = app
      @urls = options[:urls] || ["/favicon.ico"]
      root = options[:root] || Dir.pwd
      @file_server =

    def call(env)
      path = env["PATH_INFO"]
      can_serve = @urls.any? { |url| path.index(url) == 0 }

      if can_serve


So here is the first Rack application in a default Rails 3 stack, which is responsible for serving back static files. As you can see, it’s #initialize receives “app” as a first parameter, which would be the response of #call from the previous Rack app. For this Rack, the #call function doesn’t create it’s own array to return, it simply loads a static file if it finds it with Rack::File, or just passes the current environment silently if there is no static file.


The best way to learn what rack can do for you is to look into the code for the current Rails 3 stack and see what it does. You can get a list of your rack stack by running:

rake middleware

See also the Official Rack Project site for super easy documentation and explanations.

Tags: ,
Posted in Code | No Comments »