August Lilleaas

Homebrew Is Awesome

Wed, 02 Sep 2009 19:48:12 GMT

Homebrew by Max Howell is an awesome OS X package manager. It makes Macports and Fink feel like a thing of the past, vastly outranking both of them in awesomeness.

Why is Homebrew awesome?

If Homebrew is Ruby, Macports and Fink is PHP.

Instead of only relying on it’s own dependencies, it uses the software that comes with OS X. When you install Git, Homebrew uses the existing perl install rather than downloading and installing it’s own. Awesome! I created a formula for fish in about 2 minutes. It installed without dependencies, because just like Git, OS X has all the dependencies fish requires.

No sudo! You can sudo if you want to, but why should you? More on that later.

It leverages existing package managers, such as cpan, easy_install and rubygems. Why do the job that these package managers already does brilliantly?

It’s social. Since the formulas are on github, you get the social aspects of github baked right into Homebrew. Wrote a formula? Fork the repo, add a pull request!

And last but not least, formulas (or packages) are in Ruby. Double-awesome!

Installing with git

Run sudo chown -R `whoami`:staff /usr/local
cd /usr/local
git init
git remote add origin git://github.com/mxcl/homebrew.git
git pull origin masterbrew

Installing without git

This process is a bit tedious.

Run sudo chown -R `whoami`:staff /usr/local
Run curl -L -o homebrew.tar.gz http://github.com/mxcl/homebrew/tarball/masterbrew
If nothing happens here, run a few times until it works. Github randomly drops these requests for some reason.
Run tar xzf homebrew.tar.gz
Run cp -f mxcl-homebrew-[long sha here]/* /usr/local/
Run rm -rf mxcl-homebrew-[long sha here]

Usage

Install: brew install git
Remove: brew rm git
List available: ls /usr/local/Library/Formula/
List installed: ls /usr/local/Cellar/
Info: brew info git
Create formula: brew make http://url.com/to/something-2.2.tar.gz. Yes, it’s that easy.

You shouldn’t use sudo

Brew suggests you install it to /usr/local, and promptly chmod /usr/local so that you have permissions to it. That makes sense. Why should /usr/local require sudo? You can use sudo if you like, but unless you don’t have a particular reason to do so, Homebrew suggests that you don’t.

Run sudo chown -R `whoami`:staff /usr/local to set the permissions.

Fetching new packages, updating existing.

Homebrew stores the list of packages in git. It doesn’t have a brew update command yet.

Use steps in bold only if you installed with git.

brew install git
cd /usr/local
git init
git remote add origin git://github.com/mxcl/homebrew.git
git pull origin masterbrew

S3 Upload Snow Leopard Service

Sun, 30 Aug 2009 21:58:43 GMT

Snow Leopard, the latest addition to the OS X family, has ~~a new and very powerful feature called services~~ revamped the Services system, and made it a whole lot more useful. In short, services are contextual aware actions, and Apple has made it easy for users to create their own services with an updated Automator.

I wanted to familiarize myself with how the services system works, and create something useful. I created a service that lets you upload documents (images, mp3s, text documents, …) to an Amazon S3 bucket. Short summary:

Install
Right click image, choose “Upload to S3”
URL of uploaded image is pasted to your clipboard.

Awesome for sharing images on IM, email, irc, and so on.

Installing

Download the service.
Extract and copy to ~/Library/Services. Create the directory if it doesn’t exist.

That’s all there is. The next time you right click an image, there’ll be a “Upload to S3” option in the right click menu.

When you run the script for the first time, you will be prompted for your S3 login credentials. Don’t worry, they will be safely stored in your keychain, just like all your passwords are on OS X.

How it works

The service/Automator workflow uses a combination of Applescript and Ruby to get the job done. The applescripts handles the dialog boxes and fetches info from the keychain. The ruby script uses the aws/s3 gem to upload the file to S3. It installs the gem if it isn’t already installed. When the ruby script has uploaded the file, it will pass on the URL to a 2nd applescript which pastes the URL to the clipboard and provides feedback to the user.

The ability to execute ruby scripts out of the box from automator is new in Snow Leopard. So are the contextual services. Snow Leopard was released mere days ago, we can only begin to imagine the different ways people will make use of this new and powerful feature.

If you want to have a look at the source code, download the service (link above) and open it with Automator.

CHANGELOG

Sep 2. 2009: Checking if the bucket name is blank when the bucket name storage file exists.
Aug 31. 2009: Updated to use “documents” instead of “images”, to enable uploading of text files, audio files, and more.

How I Would Improve That New Tv Guide

Fri, 14 Aug 2009 17:00:02 GMT

The twitterverse very recently made me aware of se.no. It’s a complete overhault of this old TV guide, which is one of the most popular online TV guides in Norway.

I am a big fan of the lack of flash. Dagbladet, the Norwegian newspaper owning and maintaining this TV guide, has used jQuery and jQuery UI to create their revamped guide by using HTML, CSS and Javascript. If I were to present my argument for why I prefer Javascript to Flash, I’d be derailing this post and ended up with a wall of text. Short summary: I like standards and high performance. Flash is owned by Adobe, doesn’t exist on the iPhone, performance is dependent on Adobe alone so the awesome and speedy Safari 4 is still slow when flash is being around, and so on and so forth.

I’m not here to sweettalk about se.no, though. We’re on the internet, after all. I have some issues with the choices they have made when it comes to the interaction of this TV guide. More about that in a sec. First:

That mockup is mine, and it is a demo of how I would have designed the interaction. Before you read on, open both of them and get a feel of how they work.

The scroll wheel scrolls vertically.

One of the major pillars in interaction design is that you don’t want your users to be surprised. Users have habits when it comes to common and frequently used design elements, and not honoring these habits breaks the interaction.

In this sense, se.no breaks the scroll wheel. The user’s habit is that when a site has a vertical scroll, it can be scrolled with the scroll wheel. se.no has a vertical scroll, but using the scroll wheel makes the site scroll horizontally. In my opinion, it’s only (somewhat) OK to set the scroll wheel to the horizontal scroll if no vertical scroll is present.

I can certainly see why the se.no crew made the desicion they made, though. The visual layout of the TV guide is horizontally biased, and it’s very logical to have the scroll wheel scrolling what is considered the main scroll on the page. Regardless, I think that vertical scroll is more important than main scroll for a scroll wheel, especially when there is a vertical scroll present, for the reasons mentioned above.

In my mockup, you scroll horizontally by clicking and holding the main list of entries, and moving the mouse around. Regular drag and drop. This is how a scrollbar normally works, and perhaps a even better alternative would be to have a horizontal scroll bar at the bottom of the page. That was a bit hard to implement, though, so I went for the full hit are a scroll. The vertical scroll uses the normal browser scroll bar. No javascript magics whatsoever.

Smooth scrolling when dragging

On se.no, you can in fact scroll by dragging the mouse. You can scroll horizontally by dragging the black line of time-stamps on the top, and scroll vertically similar to how I scroll horizontally in my mockup (by clicking and dragging the main timeline).

The scrolling isn’t smooth, though. I’m not talking about the subjective kind of smooth (smoooooooooth!), but the grid the scrolling on se.no is locked on to. I can’t think of upsides of having a grid like that on a page like this, so I’m not going to try to justify se.no’s desicions here. The grid makes it harder to keep the context while scrolling, since you might loose grasp of where you are for a few moments right after you have jumped a step in the grid, and generally less pleasant to look at.

In my mockup, the scrolling is smooth (both subjective and objective).

Summary

When it comes to interaction design, you don’t want to re-invent the wheel. Messing with users preconceived habits and expectations makes it hard to interact with your product. Your goal should be to create an easy interaction, and you do this by giving users what they actually expect, not what they ought to expectfrom a logical standpoint. If amazon.com uses tabs a way tabs shouldn’t be used from a logical standpoint, you should too.

Pluginized Jquery Google Maps

Sat, 27 Jun 2009 05:54:26 GMT

In my recent article on dynamically loading interactive Google maps on top of static maps, I wrote a whole lot un-idiomatic jQuery code. That doesn’t matter, because the article was about fast page loads and fancy techniques, not jQuery conventions.

I do like to follow conventions, though, which is why I created a jQuery plugin for loading interactive Google maps on top of static maps. It is basically the same code as in the article, but is a lot easier to drop-in and use in your project (install a plugin instead of copy/pasting code from a web page). It is also maintained and kept up to date, which the article should be too but that’s in an ideal world where people don’t have green avatars and everyone uses ruby 1.9.

Oh crap, this just became a politically charged post. Please forget about that and click the Github link, kktnx.

Unobtrusive Google Maps With Jquery

Fri, 26 Jun 2009 15:22:20 GMT

Google Maps is a great tool for displaying maps on webpages. Using them on your page doesn’t come without a price, though. Typically, you want a webpage to have finished loading in about 200-300 milliseconds. Loading a Google map can take up to a second, effectively tripling the load time of your page.

This article is about keeping your page speedy when you use Google Maps, avoiding the long page load times you’ll get with vanilla Google Maps integrations.

Here’s the final result we’re aiming for. A static map that, when clicked, loads a interactive map. Why this is a good thing is explained in the article below.

Click the map!

Open in a new window

Update: the plugin

I created a pluginized version of this code. It’s available here, on Github. Because installing a plugin is much better than copy/pasting text from a web page. Read the article, though, so that you grok why you should use this plugin in the first place.

Using the Static Google Maps API

Since the main goal of showing a map is to show a map, all you really need to do that is a flat JPEG. That is exactly what the Static Google Maps API provides: A flat JPEG version of their interactive maps.

<img src="http://maps.google.com/staticmap?center=40.714728,-73.998672&amp;zoom=13\
&amp;size=500x300&amp;maptype=mobile&amp;markers=40.714728,-73.998672\
&amp;sensor=false&amp;key=MAPS_API_KEY" />

One single image loads way faster than the javascript and image heavy interactive Google maps.

Obviously, you can’t pan and zoom this flat JPEG. So what do we do in order to get the best from both worlds; fast load times and interactive maps?

Loading interactive maps on demand

The first thing a user does with a map is to look at it. At this time in the interaction, you don’t need a pannable and zoomable map. The abiliy to pan and zoom is not required until the user actually clicks on the map, attempting to perform these operations.

Loading the interactive map on demand means loading it at this time; when the user clicks the static map. When this happens, it is replaced with a interactive map.

This interaction flow is a big win. Your page will load faster, because displaying images is faster than loading interactive Google maps. Clicking the map isn’t something users want or can do until the page has loaded completely anyway, and some users might not want to browse an interactive map at all. Holding back the interactive maps untill they are needed makes sense in a lot of cases.

Implementing

We need to hook the click event of the image. In this event, we need to load the Google Maps javascripts, and replace the image with a div that contains the interactive map.

Here’s a basic skeleton:

// Only a skeleton!
  
window.googleMapsLibraryLoaded = function(){
  var target = $(document.createElement("div")).css({width: 500, height: 250});
  $("#map").replaceWith(target);

  var point = new google.maps.LatLng(40.714728, -73.998672);
  var map = new google.maps.Map(target[0], {
    zoom: 13, center: point,
    mapTypeId: google.maps.MapTypeId.ROADMAP
  });
  new google.maps.Marker({position: point, map: map});
}

$("img#map").click(function(){
  var url = [
    "http://maps.google.com/maps/api/js?",
    "sensor=false",
    "&callback=googleMapsLibraryLoaded"
  ]

  $.getScript(url.join(""));
});

In the click event of the image, $.getScript loads the external Google Maps scripts .The callback parameter contains the name of our function, googleMapsLibraryLoaded. When the Google Maps scripts has finished initializing, it will call this callback function. In this callback, we replace the image with a new div that contains the interactive Google map.

Using the data from the image to load the map

In the basic implementation above, the longitude, latitude, map size and zoom level is duplicated in the scripts. A sensible implementation would use the data already provided by the static image. The URL to the image (the src attribute) contains all these parameters, and since we are good unobtrusive javascript citizens, we will use these parameters in our javascripts instead of passing it on via <script></script> tags.

The full URL is just a string, so we will have to parse it. This adds some overhead, but not too much to be a real problem. We will also use this opportunity to move all the code into an object which we will name UnobtrusiveGoogleMaps.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
	"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
  <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
  <title>Unobtrusive Google Maps</title>
</head>
<body>
  
  <img src="http://maps.google.com/staticmap?center=40.714728,-73.998672&amp;zoom=13&amp;size=500x300&amp;maptype=mobile&amp;markers=40.714728,-73.998672&amp;sensor=false&amp;key=ABQIAAAAXYawz0HUhQEfK4yV1l2SWxQqCyHoT6LEDbPCa7oX2Mha8N4j1RSNHHsyBLVjnkvsR4rLjrpwwQWLKA" id="map" />
  
  <script src="http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js"
    type="text/javascript"></script>
  <script>
    window.UnobtrusiveGoogleMaps = {
      initialize: function(selector){
        this.targetDomObject = $(selector);
        this.targetDomObject.click(function(){
          UnobtrusiveGoogleMaps.loadInteractiveMap();
        });
        
        this.options = this.getOptionsFromQueryParameters();
      },
      
      getOptionsFromQueryParameters: function(){
        var src = this.targetDomObject.attr("src");
        var options = {}
        var queryParameters = {};
        $.each(/\?(.+)/.exec(src)[1].split("&"), function(i, x) {
          var r = x.split("="); queryParameters[r[0]] = r[1];
        });
        
        options.zoom = parseInt(queryParameters["zoom"]);

        var sizes = queryParameters["size"].split("x");
        options.width = parseInt(sizes[0]);
        options.height = parseInt(sizes[1]);

        var latLong = queryParameters["center"].split(",");
        options.latitude = parseFloat(latLong[0]);
        options.longitude = parseFloat(latLong[1]);
        
        return options;
      },
      
      loadInteractiveMap: function(){
        var url = [
          "http://maps.google.com/maps/api/js?",
          "sensor=false",
          "&callback=UnobtrusiveGoogleMaps.googleMapsLibraryLoaded"
        ];

        $.getScript(url.join(""));
      },
      
      googleMapsLibraryLoaded: function(){
        var target = $(document.createElement("div"));
        target.css({width: this.options.width, height: this.options.height});
        this.targetDomObject.replaceWith(target);
        
        var point = new google.maps.LatLng(this.options.latitude, this.options.longitude);
        var map = new google.maps.Map(target[0], {
          zoom: this.options.zoom, center: point,
          mapTypeId: google.maps.MapTypeId.ROADMAP
        });
        new google.maps.Marker({position: point, map: map });
      }
    }
  
    $(function(){
      UnobtrusiveGoogleMaps.initialize("#map");
    });
  </script>
  
  <script type="text/javascript">
  var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
  document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));
  </script>
  <script type="text/javascript">
  try {
  var pageTracker = _gat._getTracker("UA-9100016-1");
  pageTracker._trackPageview();
  } catch(err) {}</script>
</body>
</html>

window.UnobtrusiveGoogleMaps makes it a global variable. UnobtrusiveGoogleMaps alone would also be a global variable, but I prefer to be explicit about it, so that it is obvious that it is global, and I didn’t just forget to add a var in front of it.

googleMapsLibraryLoaded gets it’s data from this.options instead of being hardcoded. this.options contains the values parsed out of the static map image’s URL.

That is all there is to it!

Check out the working finished example!

Global Gitignores

Thu, 25 Jun 2009 08:00:17 GMT

On Mac OS X, the Finder creates a .DS_Store file in all the directories it displays. If you happen to browse your git repository with the Finder, you’ll get these files in your repo, and they’ll show up as untracked files in git status. A common workaround is to add .DS_Store to the .gitignore. Here’s one of my gitignore files for a Rails project:

.DS_Store
*.log
*.sqlite3
config/database.yml
db/schema.rb
tmp/**/*

I have a slight problem with this, though. The .DS_Store isn’t related to your project, it is related to the system you’re coding on. Yor .gitignore file will be a lot more elegant if it only lists files that are related to the projects. For a Rails app, log files and db/schema.rb is definitely app related. .DS_Store isn’t, though.

This is why I have a global gitignore file for my system, that ignores system related files.

> git config --global core.excludefiles ~/.gitignore

This file contains the following:

.DS_Store

And voila, you no longer have to add .DS_Store to all your .gitignore files.

While this article might seem OS X specific, it applies to all systems. A good example is thumbs.db on Windows systems. I’m sure some Linux distros has similar system files. Global gitignores are not limited to .DS_Store on OS X, but all system files that shouldn’t be allowed to sneak into your repositories or your .gitignores.

Time Calculations In Javascript

Sat, 20 Jun 2009 20:48:57 GMT

I just released JS-Time! http://github.com/augustl/js-time/tree

JS-Time is a javascript library for performing time calculations. It is completely framework agnostic, so you can easily drop it to any existing project already jQuery, Prototype, Motools, or something else. The tests are passing on IE6 to 8, Firefox, Opera and Safari.

new Time(2008, 5, 17);
time.month() // 5

new Time(2006, 1, 30).advanceMonths(1).day()      // 28 (February 28th)
new Time(2008, 5, 17).beginningOfYear()           // January 1st 2008
new Time(2008, 5, 17, 22, 30).beginningOfDay()    // May 17th 2008, 00:00
new Time(2008, 5, 17, 16, 30).endOfHour()         // May 5th 2008, 16:59

new Time(2008, 1).firstDayInCalendarMonth()       // December 30th 2007
new Time(1804).isLeapYear(); // true
new Time(2008, 2).weeksInMonth()                  // 5
new Time(2008, 1).daysInMonth();                  // 31

You can set the first day of the week with Time.firstDayOfWeek = 2. It defaults to 1, Sunday.

Please let me know if you encounter any problems.

Styling Rails Urls

Sun, 14 Jun 2009 21:06:44 GMT

This article explains how you can alter the looks of your URLs in a Rails friendly way. I assume that you know how to use map.resources and named routes.

Adding .html to all pages

ActionController has a default_url_options method that it uses for all URL generation tasks. It returns an empty hash by default, but can be overridden.

class ApplicationController < ActionController::Base
  def default_url_options(options = nil)
    {:format => "html"}
  end
end

Note that the options to your individual route calls gets predesence, posts_path(:format => "xml") will append .xml, not .html.

Custom route names

For a projects controller’s show action, the default URL looks like this:

/projects/5

What if you want to localize it?

/prosjekter/5

One way is to name the controller “prosjekter” instead of “projects”. That isn’t very Rails friendly, though, you’ll end up fighting with pluralization conventions. Thankfully, there is a Rails friendly way to do this, via routes.rb.

map.resources :projects, :as => "prosjekter", :path_names => {:new => "nytt", :edit => "rediger"}

That will give you these URLs:

/prosjekter/5
/prosjekter/nytt
/prosjekter/5/rediger

You can also set :path_names globally, by adding the following to config/environment.rb.

config.action_controller.resources_path_names = { :new => 'ny', :edit => 'rediger' }

URLs without the ID of the record

Normaly, Rails URLs look like this:

/posts/5
/projects/239
/users/39/favorites/2

Perhaps you want more descriptive URLs, though, such as having the title of the post in the URL instead of just the ID. Here are a few altervatives.

The easy way with compromises

/posts/5-a-post-about-rockets
/projects/239-new-website
/users/39-augustl/favorites/2-that-book

The compromise is that the ID still is in the URL. It is unlikely that a visible ID is a problem, but if it for some reason is, you can learn how to do it without the ID in the next section.

What makes Rails use the ID alone in the first place? The answer is to_param. It’s an instance method in all models, and it looks like this:

def to_param
  id
end

We can override it to include the title of the post as well as the ID.

class Post < ActiveRecord::Base
  def to_param
    "#{id}-#{title.parameterize}"
  end
end

Rails will now use the id, a dash, and and URL friendly version of the title. We need to make it URL friendly with parameterize, so that "Foo and bar!" turns into "foo-and-bar". If we don’t, we’ll get invalid URLs, and browsers will blow up.

The reason this is the easy way, is that this is all there is to it. Our finds will still work, because of the way Ruby handles to_i on strings.

"5-a-post-about-rockets".to_i
# => 5

The find method that we use in the controllers calls to_i for us.

Post.find("5-a-post-about-rockets")
# equals
Post.find(5)

The hard way

/posts/a-post-about-rockets
/projects/new-website
/users/augustl/favorites-that-book

Because the ID is no longer in the URL, we have to change the code a bit.

class Post < ActiveRecord::Base
  before_create :create_slug
  
  def to_param
    slug
  end
    
  def create_slug
    self.slug = self.title.parameterize
  end
end

When a post is created, the URL friendly version of the title is stored in the database, in the slug column. We also have to update the finds to find records using the slug column instead of using the ID.

class ProjectsController < ApplicationController
  def show
    @project = Project.find_by_slug!(params[:id])
  end
end

Apply the same tactic to all relevant finds, and you’re good to go.

No controller names

Instead of /users/augustl/projects/a-project, you might prefer this:

/augustl/a-project
/some-user/another-project

Just a heads up: Most people don’t care about how the URLs looks. In my opinion, it only makes sense to do this kind of routing if your users are typing in the URLs by hand, or if the URL is commonly linked to. Github projects is a good example of sensible use of short URLs. If not, I advise you to leave the controller names in there.

Anyhow, here’s how you do it:

map.short_user ":id", :controller => "users", :action => "show"
map.short_project ":user_id/:id", :controller => "projects", :action => "show"

This gives you two very handy named routes.

short_user_path(@user)
short_project_path(@user, @project)

The example above only handles those two show actions. I advise using regular map.resources for create, edit etc. Users will never have to link to the URL that creates a new project, so it’s pointless to style those routes.

Option Hash Fetishes

Sat, 13 Jun 2009 09:37:43 GMT

I love to write code! I also like being in control of my code and it’s end result. This often leads me to write everything from scratch. Too many plugins have an option hash fetish, rendering me unable to do things the way I want to do them.

So why do I use Rails, you say? Because option hashes are fine as long as it’s on a low enough level. has_many using an option hash makes perfect sense. I don’t care how it works, so an option hash is sufficient. I do however really care how the flow of signing up works, and how the UI looks and feels. That is why I never use restful authentication and jQuery UI. They are option hash mongers.

I’m not saying that nobody should use restful authentication or jQuery UI. If that’s what you want, then fine. Far beyond on the other side, we have people that wants to write their webapps in C. It’s all about how much control you want to have, and is willing to give away. Deciding how high and low level you want stuff to be is your call.

My call is at the level of the user interaction. I want to be in complete control of that. I don’t mind writing some code in order to be able to customize what I want to be able to customize.

Which is why I wrote Authenticish.

Update: Even though it’s kind of off topic, I’ll mention it. I wasn’t aware of Authlogic. It’s awesome, and is exactly the kind of library I like to use.

Combining Named Scopes

Mon, 08 Jun 2009 20:28:27 GMT

Named scopes are awesome. First, short recap of named scopes.

class Post < ActiveRecord::Base
  belongs_to :author
  
  named_scope :published, :conditions => {:published => true}
  named_scope :ordered, :order => "created_at DESC"
  named_scope :with_author, :include => [:author]
end

The scopes are invoked through chainable class methods.

Post.published
Post.published.count
Post.published.ordered.with_author.each {|p| ... }

ActiveRecord doesn’t have any functionality for grouping scopes, though. That can be useful in some cases, e.g creating a orderly scope that is a combination of published and ordered. Adding that functionality is trivial, here’s the monkey patch:

class ActiveRecord::Base
  def self.named_scopes(name, &block)
    metaclass.send(:define_method, name) {|*args| block.call(*args) }
  end
end

If you’re unsure where to put this code, read and understand my Extending Ruby and Rails article.

We can now do named_scopes(:orderly) { ordered.published.with_author }. The scope can be called like any other scope, e.g. Post.orderly.count. Here’s a real-ish example:

class Post < ActiveRecord::Base
  belongs_to :author
  
  named_scope :published, :conditions => {:published => true}
  named_scope :ordered, :order => "created_at DESC"
  named_scope :with_author, :include => [:author]
  named_scope :by_author, lambda {|author| {:conditions => {:author_id => author.id}} }
  
  named_scopes(:orderly) { ordered.published }
  named_scopes(:for_author) {|author| ordered.published.by_author(author) }
end

Post.orderly.count
Post.for_author(an_author).with_author.each {|a| ... }

A brief explanation of the implementation

It piggybacks heavily on the existing named scopes implementation. Because named scopes are chainable, we don’t have to implement anything. The code just executes the method calls in the block passed to named_scopes in the class scope. That is the equivalent of calling the methods explicitly on the class.

For your information, metaclass.send(:define_method, "foo") { ... } is metaprogramming for defining class methods.

Deadlier And Simpler Rails Deployment

Mon, 01 Jun 2009 17:51:20 GMT

Disclaimer: In order to satisfy the masses, “Rails” is in the title of this article. The article is really about deploying through Github’s post receive hooks, though, so it applies to Rails, Sinatra, Camping, PHP apps, or whatever.

Capistrano is huge. However, even though this article is about not using Capistrano, I would like to emphasize that I don’t think you should scrap Capistrano alltogether. Capistrano has a ton of sensible use cases.

An example: At work, we have a Rails app that processes SMS and MMS messages from an asynchronous queue. We don’t want that Rails app to be down, because that means people won’t receive their SMS and MMS messages. Because of the realtime nature of SMS and MMS, being down is nasty. So, we use Capistrano to deploy, because Capistrano makes deployment less error prone. For instance, it is awesome to be able to rollback failed deploys with a single command.

For smaller apps, though. I find Capistrano vastly overkill. I never use the rollback functionality. All I do is SSH-ing into the server, git pull-ing, and restarting passenger. SSH-ing is not that elegant, though. Apparently, Zed Shaw said "if you’re SSH’ing into a machine more than once a week you’re doing it wrong.". I strongly agree with that.

This page is definitely a “smaller app”. The content is plain text files, version controlled with Git. When I deploy, I’d normally SSH to the server, cd to my homepage, git pull and then touch tmp/restart.txt in order to restart the web server.

I don’t do that, though.

How I deploy this page

I use pushmaster. Pushmaster utilizes Github’s post receive hooks. When pushmaster is installed and configured, all I do and all you have to do in order to deploy your application is:

git push

What’s the magick trick?

I run pushmaster (obviously) on http://pushmaster.lilleaas.net.
http://my:password@pushmaster.lilleaas.net/ is added as a post receive hook on the Github repository for this page.
When i git push from my local box, pushmaster will git pull and touch tmp/restart.txt on the server.

It really is that simple. No more manual SSH!

How you can use pushmaster to deploy your application

Deploy pushmaster on your server
Add a handler (see below).
Add pushmaster as a post receive hook in the Github repository for your application.
git push from your local box.

Your handler will look like this:

Dir.chdir "/path/to/rails/application" do
  git "pull"
  touch 'tmp/restart.txt'
end

On Mongrel? No worries.

Dir.chdir "/path/to/rails/application" do
  git "pull"
  run "mongrel_rails cluster::restart"
end

Are you deploying a PHP app? Pushmaster handlers are ruby scripts with a small DSL added to them, and you are in a secure environment, so you can do anything you want.

run "whatever_you_want"
log "I just ran the command."

Dir.chdir "/path/to/awesome/php/app" do
  run "a_command"
  Net::HTTP.get_response(URI.parse("http://wtf.com"))
end

What about sending messages to your companies internal project manager?

require 'net/http'
require 'cgi'

url = URI::HTTP.build({
  :host => "localhost", :port => "5892",
  :query => "num_commits=#{data["commits"].length}&ref=#{data["ref"]}"
})

Net::HTTP.get_response(url)

Endless possibilities

Pushmaster is not really a deployment tool, it is a listening-to-github-post-receive-hooks tool. Because pushmaster is password protected, it also runs in a secure environment. As shown above, you don’t have to limit pushmaster to re-deploy your apps only, you can use it for whatever you might come up with.

How do you use pushmaster?

Extending Ruby And Rails

Mon, 01 Jun 2009 08:00:57 GMT

It can be useful to add methods directly to internal Ruby and Rails classes.

Let’s say you want to be able to calculate the average from an array of numbers. Compare these two examples:

[1, 2, 5, 8, 199].average
  
  --
  
array_average([1, 2, 5, 8, 199])

The first example is how it looks if you extend Array with a median method. The last example is none object oriented — a helper, perhaps. Almost all rubyists will tell you the first example is more elegant. This article explains how you can do just that: extending existing classes instead of creating none-object oriented helpers.

How to extend classes, in general

So how do you add methods to existing classes? You do that simply by opening it, and adding methods, similar to how you create new classes.

class Array
  def average
    sum / length
  end
end

Despite how similar this looks to creating new classes, the Array class won’t be re-defined alltogether, Ruby will just add whatever you add. You can now call .average on all arrays.

PS: Ruby doesn’t have a built-in Array#sum. If you’re in Rails, ActiveSupport adds that method, though. If you for some reason are outside of Rails, use inject(0) {|avg, i| avg += i } instead of sum.

Adding the hooks in Rails

Back to a Rails application. We are going to place the core extensions in lib/ext/[class name].rb. Copy the Array#average implementation from above into lib/ext/array.rb.

That is not enough, though. The file will have to execute in order to add the method to Array, but it won’t execute because files in lib/ aren’t executed when you boot the app. They are just added to the load path (more here). The files in config/initializers/, however, executes when the app boots, so we’ll add this code snippet to an initializer (such as config/initializers/extensions.rb) to make the files in lib/ext/ execute as well:

Dir[File.join(Rails.root, 'lib', 'ext', '**', '*.rb')].each {|ext| require ext }

Rails will now execute (require) every file in lib/ext/ when it boots.

That is all

That is everything you need in order to be able to extend Ruby and Rails core classes. Here are a few examples of how you could extend existing classes to get you started.

lib/ext/array.rb

class Array
  def median
    if length.odd?
      self[length / 2.0]
    else
      self[(length / 2 - 1)..(length / 2)].average
    end
  end
  
  def average
    sum / length
  end
end

Usage:

[1, 5, 10, 32, 501, 100000].median
# => 21

[1, 5, 10, 32, 100000].median
# => 10

lib/ext/active_record.rb

class ActiveRecord::Base
  def self.case_insensitive_find(one_or_all, attribute, value)
    find(one_or_all, :conditions => "LOWER(#{attribute}) = ?", value.downcase)
  end
end

Usage:

Author.case_insensitive_find(:all, :name, "august LiLLeAas")
Book.case_insensitive_find(:first, :title, "Hitchhikers GUIDE TO THE GALAXy")

lib/ext/string.rb

class String
  def randomcase
    split(//).map! {|char| rand(2) == 0 ? char.downcase : char.upcase }.join
  end
end

Usage:

Array.new(10) { "Hello, World!".randomcase }
  
# => ["HellO, wOrLd!", "HellO, WoRLd!", "HeLLO, woRlD!", "hElLo, woRlD!", "HEllo, WoRLD!", 
"HEllo, world!", "helLO, WorLd!", "HellO, WoRld!", "Hello, woRlD!", "hElLO, wORLD!"]

How Rails Selects Which View To Render

Sun, 31 May 2009 16:32:20 GMT

Rails uses a special mapping of action name and mime type to determine which template it should render.

[action_name].[mime_type].[template_type]
  
  -- or --
  
[action name].[template type]

You already know what the action name is. The MIME type and template type is usually quite confusing for newcomers, though.

Mime type

MIME types are content types or file types, such as xml, html, js and json. You specify the MIME type by appending a dot and the mime type extension to the URL, such as /posts.xml and /people/5.json. Since Rails usually serves HTML pages, HTML is the default mime type if none is specified, e.g. /posts.

When Rails sees a MIME type in the URL, two things happen.

1) It looks for a respond_to block. If one is found, it calls the correct block and signs off. If there is no respond_to block, the controller contiues to the next step.

2) It uses the mime type to determine which view it should render, as shown in the diagram above.

Here’s a diagram with URLs and the view that each URL will render.

/posts: app/views/posts/index.html.erb
/users.xml: app/views/users/index.xml.erb
/projects/1.js: app/views/projects/show.js.erb

All these examples use erb as template type. This leads us to…

Template types

I was lying to you earlier. Rails doesn’t actually use the template type to determine which view it should render. The action name and the MIME type is all Rails needs to determine that. The purpose of the template type, not surprisingly, is to determine the template type.

Here are the various template types in Rails:

ERb: The default template type, with <%= erb %> tags.
RJS: A DSL for generating Javascript.
Builder: A DSL for generating XML.
HAML: A 3rd party plugin, fairly common. An alternative to ERb. Google it.

In most cases, you will use .html.erb, .js.rjs or .xml.builder. Those are the mimes these template types are designated to handle. However, any action/mime combination can use any template type, and you are free to mix and match as you like. Although most other combinations are pretty silly, there are exceptions. For example, .xml.erb is commonly used, so that ERb generates the XML instead of Builder.

No mime type

You can leave out the mime type and have Rails use that template for all mimes, e.g. show.erb. Both /people/1 and /people/1.js will render that same template.

Creating Your Own Validations

Sun, 31 May 2009 16:32:20 GMT

It is easy to create custom validations in Rails. Here’s your full list of recipes.

class Post < ActiveRecord::Base
  validate :any_method, :on => :create
  
  validate do |record|
    record.errors.add_to_base("This sucks.") if record.does_it_suck?
  end
  
  def does_it_suck?
    false # do something real here.
  end
  
  private
  
  def any_method
    errors.add.to_base("I refuse to be saved!") if my_condition?
  end
end

You can also define a validate method, but that is widely considered unelegant and oldschool. Use validate :any_method or validate {|record| ... }.

Validates each

You can use validates_each to run the same validation on multiple attributes.

class User < ActiveRecord::Base
  validates_each(:home_email, :job_email) do |record, attribute, value|
    if value !~ /my fancy email regexp/
      record.errors.add(attribute, "My error message!")
    end
  end
end

Custom validation methods

Deep down below, all the built-in validation methods also uses validates_each. This makes it trivial to implement your own validation methods that you can use across your models.

# lib/validates_email.rb
class ActiveRecord::Base
  def self.validates_email(*args)
    validates_each(*args) do |record, attribute, value|
      if value !~ /my fancy email regexp/
        record.errors.add(attribute, "is not a valid e-mail address")
      end
    end
  end
end

# config/initializers/[anything].rb
require "validates_email"

This code passes on all the arguments as-is to validates_each. This means that you can use all the various options that are common to the built-in validation methods, such as :on => :create, :if => :a_method and so on.

Congratulations, you got yourself a professional looking custom validation!

class Contact < ActiveRecord::Base
  validates_email :home_email, :work_email, :on => :create
end

Load Path

Sun, 31 May 2009 16:32:20 GMT

When you require something, Ruby looks for a matching file in all the directories in the load path. The load path is stored in the global variable $LOAD_PATH.

Consider the following directory structure:

top_level.rb
underlings/
  slave.rb
  equal.rb

You’ll get an error if you try to require "slave" from top_level.rb. When you require something, Ruby looks for a matching file in the directories of the $LOAD_PATH. The directory underlings/ is not automatically added to the $LOAD_PATH by Ruby, so the require fails.

If you on the other hand add underlings/ to the $LOAD_PATH, it will work. Adding directories to the load path is easy.

# top_level.rb
$LOAD_PATH << File.join(File.dirname(__FILE__), "underlings")
require "slave"

File.dirname(__FILE__) and File.join is used to get the full absolute path to the underlings/ directory. You should only put absolute paths such as "/usr/local/foo" (or "C:\foo\bar" on Windows) in the $LOAD_PATH, and avoid things like $LOAD_PATH << "lib/foo".

The snippet above will run successfully, because the require statement is able to handle "slave" based on what’s in the $LOAD_PATH. As you can see, $LOAD_PATH is an array, and the directory names it contains are strings.

The current directory is in the load path

If you inspect $LOAD_PATH in IRb, you’ll find "." in it. That dot reperesents the current directory, and lets you require a file that is in the same directory as the file you require from. If foo.rb and bar.rb, you can require "bar" from foo.rb without modifying the $LOAD_PATH.

That $: thing

$: is a shorthand for $LOAD_PATH. So now you know.

(In fact, $LOAD_PATH is longhand for $:. Yeah! Thanks, bryanl.)

Git Submodules

Sun, 31 May 2009 16:32:20 GMT

Git uses submodules to store links to other repositories.

> git submodule add [repository] [local path]
> git submodule add git://github.com/foo/bar.git local/path

In this case, Git will clone the repository into local/path. Git now stores a reference to the most recent commit in that repository in .gitmodules. You have to add .gitmodules and the submodule itself to the repository.

> git add .gitmodules
> git add local/path
> git commit -m "Adding my first submodule!"

This is what’s in .gitmodules:

[submodule "local/path"]
	path = local/path
	url = git://github.com/foo/bar.git

git submodule with no arguments will list all the submodules with their SHA refs.

> git submodule
 dc88847e5ce392eed210b97525c14fca55852867 local/path

Using a specific commit or tag

In most cases you don’t want to use the HEAD at the time you create the submodule, you want to use a particular commit or tag. You can cd to the submodule and use git checkout to specify which commit or tag you want to use for your submodule.

> cd local/path
> git checkout 58926a0077d9f3df66af3460eb8fe3bd0e68814d

In order to checkout a tag, you have to run git tag first. Then, you can checkout to any tag you like.

> cd local/path
l/path > git tag
0.1
0.2
0.3b
0.3
l/path > git checkout 0.2

You can also use git pull to get the most recent commit.

>cd local/path
l/path > git pull

You must then commit your changes.

l/path > cd ../..
> git add local/path
> git commit -m "Updating the submodule."

Important: git add on a submodule.

When you use git add on a submodule, make sure you don’t have a tailing slash.

> git add local/path
  -- adds the submodule
  
> git add local/path/
  -- adds all the files in the submodule directly into your repository, big no-no

Cloning a repository that uses submodules

When you clone a repository that utilizes submodules, you have to run two commands in order to fetch the submodules. Git doesn’t do that automatically when you clone.

git submodule init
git submodule update

Rails particulars

Since this site targets Railsers, I deem it sensible to have a Rails specific section. Here are a few useful commands:

> git submodule add git://github.com/rails/rails.git vendor/rails
> cd vendor/rails
v/rails > git tag
  ... a whole bunch of tags are listed...
v/rails > git checkout v2.1.2
v/rails > cd ../../
> git add .gitmodules
> git add vendor/rails
> git commit -m "Adding rails as a submodule"

> git submodule add git://github.com/mislav/will_paginate.git vendor/plugins/will_paginate
> git add .
> git commit -m "Adding will_paginate as a submodule"

Sources

Active Record Anywhere

Sun, 31 May 2009 16:32:20 GMT

You can use ActiveRecord anywhere!

require 'rubygems'
require 'active_record'

ActiveRecord::Base.establish_connection({
  :adapter => 'postgresql',
  :user => 'foo',
  :password => 'bar',
  :database => 'whatever'
})

class Task < ActiveRecord::Base
  set_table_tame "a_legacy_thingie"
  
  def utility_methods
    update_attribute(:title, "yep")
  end
end

Task.find(:first)

Etcetera. It’s ActiveRecord, you know what to do. Going wild:

ActiveRecord::Base.establish_connection(:adapter => "sqlite3", :dbfile => ":memory:")

ActiveRecord::Schema.define(:version => 1) do
  create_table :posts do |t|
    t.string :title
    t.text :excerpt, :body
  end
end

class Post < ActiveRecord::Base
  validates_presence_of :title
end

Post.create(:title => "A new post!")
Post.create(:title => "Another post", :excerpt => "The excerpt is an excerpt.")

puts Post.count
# => 2

Procs And Blocks And Anonymous Functions

Sun, 31 May 2009 16:32:20 GMT

This is a Big Picture™ post. I will attempt to give you a thorough understanding of how blocks and procs works in Ruby by showing examples and explaining basics. I will also show some examples from other languages, namely Javascript and Lua, in order to really expand on the Big Picture™ in this article.

Storing pieces of code

In Ruby, you can store pieces of code and execute them on demand; methods. You define the method, add code to the method body, and run the method whenever you want.

In addition to methods, there is another way in Ruby to store code that you can call later; procs.

say_hello = Proc.new { puts "Hello!" }

Contrary to what you might expect, the puts doesn’t run. Ruby only stores the code inside the proc, it doesn’t run it. Not yet, at least. It runs when we tell it to. Let’s run it right away. Remember, we stored the proc in the say_hello variabe.

say_hello.call
# => "Hello!"

So, there you go. That’s what procs are, and that is all there is to it. But how the fsck is this useful to anyone? Why not just use methods?

Organizing your code with procs

Procs are useful code organization tools. Let’s say that you want to calculate the running time for a few code snippets, in order to benchmark them. To do this elegantly, you want to be able to call a method and pass some code to it, and have the execution time returned.

Here’s how you can use procs to do just that:

def time(a_proc)
  start = Time.now
  a_proc.call
  puts Time.now - start
end

time(Proc.new { code_here })
time(Proc.new { more_code_here })

The execution times of the code inside the procs will be neatly displayed as you run this code. Try it yourself, right now! You can use sleep(2), 1000.times { 5 + 5 }, or anything else you might want to speed test.

Blocks!

In addition to method arguments, a method can also take a block. Passing a block is essentially the same as passing a proc, except that the syntax is different (and nicer), and you don’t have to type as much. Other than that, procs and blocks are essential the same thing: code that you can call later on.

def time
  start = Time.now
  yield
  puts Time.now - start
end

time { code_here }
time { more_code_here }

Looks a lot nicer, doesn’t it? Upon further inspection, it is easy to see where procs and blocks differs. Comparing the two examples, we can see that the time method no longer takes an argument. A block is a special internal thing in Ruby, so you don’t need to specify a method argument for the block. Also, we use yield instead of a_proc.call. yield is a special keyword in Ruby, telling Ruby to call the code in the block that was passed to that method. Lastly, actually passing the code to the method has a different syntax. No parentheses, because the block is not an argument. No Proc.new either, because we aren’t creating a proc, we are passing a block.

Passing arguments to procs and blocks

When you yield or call, you can pass arguments to the proc or block at the same time. A dumb example:

def dumb_hello_world_test
  yield(5)
end

dumb_hello_world_test {|i| puts i * 2 }
# => 10

my_silly_proc = Proc.new {|name| puts name.upcase }
my_silly_proc.call("August Lilleaas")
# => "AUGUST LILLEAAS"

You have probably seen blocks taking arguments before: each, map and other enumerable methods does this.

[1, 2, 3].map {|i| puts i * 2 }
# => 2
# => 4
# => 6

That’s right: map takes a block. The block gets an argument: the number in the array. Now, for something hardcore. Let’s play with an implementation of Array#each.

class Array
  def each
    i = 0
    while(i < self.length) do
      yield(self[i])
      i += 1
    end
  end
end

my_array = ["a", "b", "c"]
my_array.each {|letter| puts letter }
# => "a"
# => "b"
# => "c"

We iterate the items in the array, and call the block — yield — for every item in the array. When we yield, we pass the current array iteration to the block.

The big picture: blocks and procs in other languages.

Ruby isn’t the only language that lets you pass around chunks of code. Here are some examples in Javascript and Lua. Despite their obvious use case differences, these two languages are pretty similar.

Remember how you can use both methods and procs/blocks to store chunks of code in Ruby? In JS/Lua, methods and procs/blocks are replaced by functions. This is possible because, unlike Ruby, you can refer to a function by name without calling it, or create anonymous functions.

// javascript
var sayHello = function(){
  alert("Hello, World!");
}

sayHello    // a reference
sayHello()  // calling it

-- lua
local function sayHello()
  print("Hello, World!");
end

sayHello    -- a reference
sayHello()  -- calling it

Again, unlike Ruby, sayHello won’t execute the function, while sayHello() will. Let’s create an implementation of the time method in JS and Lua.

// javascript
var time = function(callback){
  var start = new Date();
  callback();
  alert(new Date.getTime() - start.getTime());
}

time(function(){
  // run some code here..
});

-- lua
local function time(callback)
  local start = os.time();
  callback();
  print(os.time() - start);
end

time(function()
  -- run some code here..
end);

As you can see, you can pass an anonymous function definition directly to the two time functions, as an argument — similar to the way you Ruby lets you pass procs as method arguments.

Just to elaborate, and as mentioned, you can pass a reference to a function as well as an actual function definition.

time(sayHello)

And just to make sure you’re with me: time(sayHello()) will break miserably. sayHello will execute before time, which causes time to use whatever executing sayHello returns, instead of the function reference.

Lastly, a Ruby recap. In Ruby, foo and foo() are equivalents.

def say_hello
  puts "Hello, World!"
end

say_hello
# => "Hello, World!"
say_hello()
# => "Hello, World!"

So, while other languages are able to pass around chunks of code by using references to other functions, Ruby doesn’t allow that. Ruby has a separate feature for this, though; procs and blocks.

Relevant boring facts: Blocks to procs to blocks

You can convert a block passed to a method into a proc by using special syntax for this.

def time(&block)
  puts block
end

time
# => nil
time { foo }
# => #<Proc:0x00029bbc>

You can also do this the other way around: pass a proc to a method and make it look as if you passed a block.

def time
  yield
end

my_proc = Proc.new { puts "I was called!" }
time(&my_proc)
# => "I was called!"

The ampersand is the key here, which tells Ruby that block and my_proc isn’t a method argument but a reference to the block passed to that method. Leave out the ampersand, and it’ll be treated as a regular method argument.

def time(block)
  puts block
end

time { foo }
# => ArgumentError: wrong number of arguments (0 for 1)
# Because the ampersand was left out in the method definition, the method now expects an
# argument, and it is given none (a block is not a method argument).

def time
  yield
end

time(my_proc)
# => ArgumentError: wrong number of arguments (1 for 0)
# Because the time method doesn't take any arguments, and without the ampersand, my_proc 
# is passed as a regular method argument.

Block syntax

do ... end and { ... } are equivalents. These two calls to time are identical.

time { code_here }
  
time do
  code_here
end

The ideom is to use do ... end on multi-line blocks, and { ... } for one-liner blocks. It is entirely up to you, though. Following the ideom is recommended, but Ruby doesn’t enforce it.

A note on lambdas

Short answer: lambda { foo } and proc { foo } is essensially the same thing, you can use both interchangeable in your code.

There is two differences, though: One is how it handles return. I suggest reading this article.

The other is how it handles arguments. This is really lame and strange. lambda and proc are equivalents, while Proc.new differs. You’d think Proc.new and proc were equivalents, but they aren’t. I’ll let this code speak for itself.

a_lambda = lambda {|a| a.inspect }
puts a_lambda.call
# => nil
puts a_lambda.call("foo", 5)
# => ["foo", 5]

sumlam = lambda {|a, b| a + b }
sumlam.call
# => ArgumentError: wrong number of arguments (0 for 2)

sumproc = proc {|a, b| a + b }
sumproc.call
# => ArgumentError: wrong number of arguments (0 for 2)
sumproc.call(4, 5)
# => 9

orlyproc = Proc.new {|a, b| a + b }
orlyproc.call
# => NoMethodError: undefined method `+' for nil:NilClass
orlyproc.call(4, 5)
# => 9

Where To Put Those Codes

Sun, 31 May 2009 16:32:20 GMT

You got app/ for your MVC, and vendor/ for your plugins, gems and what not. But what about everything else?

There are two magic folders in a Rails app where that “everything else” goes:

config/initializers/
lib/

They differ in behaviour. The code in config/initializers runs when the application loads for the first time. The code in lib/ is only made available to your application, and doesn’t execute until you explicitly call it.

Confusion time. What’s the difference between executing it on startup and making it available? The answer is ActiveSupport::Dependencies.

ActiveSupport::Dependencies

Normally, in order to make code available, Ruby has to execute the code. This is usually done with the require keyword.

# my_module.rb
module MyModule
  def my_method
    # a hardcore method that takes 10 seconds to run
  end
end

# my_file.rb
require "my_module"

Ruby will execute the code in my_module.rb. It will see the module declaration and know that there now is a MyModule module. It will see the method declaration (def), and know that the module has a method called my_method. It won’t run the method my_method, which is good. It will only run the file to the extent that it is aware of the method.

The magic ActiveSupport::Dependencies changes that, though. You won’t have to require files by hand to make the code in them available, it will require the files for you, automagically. ActiveSupport::Dependencies.load_paths is an array of directory names. lib/ is in that list. Let’s pretend that you have this file in lib/:

# lib/some_module.rb
module SomeModule
  def self.do_something
    # yeah, do something..
  end
end

In a model, or in a controller, or anywhere, you call SomeModule.do_something.

If this wasn’t a Rails app, you would get an error message. You haven’t explicitly required lib/some_module.rb, which means that Ruby isn’t aware of the SomeModule module. It would raise NameError, and fail miserably.

Rails, however, captures this NameError, and handles it with ActiveSupport::Dependencies. It will look through all the directories in it’s load_paths. When it encounters the file some_module.rb in either of those directories (the file name is based on the module name, SomeModule turns into some_module), it will require that file, and avoid the NameError entirely.

Back to my point: this means that the code in lib/ won’t execute when you boot your app. You can raise "OMG silly" in a file in lib/, and your app will still boot. It will only execute when you call it.

The code in config/initializers, however, will execute when you boot the app. A raise "dude.." in an initializer will make your app inbootable.

Summary

config/initializers/ executes when the application boots. The name of the file does not matter, all the files in that directory will execute.

It’s good for plugin configuration such as API keys and various plugin settings, setting Rails configuration settings, adding inflections (for pluralize and singularize) and so on. It’s basically a cleaner alternative to having code at the bottom of config/environment.rb. Whenever old tutorials tells you to put something in environment.rb, be smart, and put it in an initializer instead.

Rails 2.1 and beyond comes with a set of default initializers. Look at them for some inspiration and examples.

lib/ stores code and makes it globally available to your app. It’s great for extracting behaviour common to controllers and models, extracting common behaviour across multiple models or controllers into modules and so on.

It’s also good for code that aren’t going to be re-used but perhaps only called in one of your models, but doesn’t really belong in app/models because it doesn’t do anything with the database at all. If you write some code that fetches data from web services, for instance, tuck it in lib/ instead of making a none-ActiveRecord::Base-class in app/models.