This quick reference aims to demonstrate MiniTest's main concepts and provide real world examples to get you acquainted quickly. Let's start with MiniTest::Spec.

MiniTest::Spec

Provides RSpec-like matchers and contexts right out of the box.

require 'minitest/autorun'
        
        describe Hipster, "Demonstration of MiniTest" do
          before do
            @hipster = Hipster.new
          end
        
          after do
            @hipster.destroy!
          end
        
          subject do
            Array.new.tap do |attributes|
              attributes << "silly hats"
              attributes << "skinny jeans"
            end
          end
        
          let(:list) { Array.new }
        
          describe "when asked about the font" do
            it "should be helvetica" do
              @hipster.preferred_font.must_equal "helvetica"
            end
          end
        
          describe "when asked about mainstream" do
            it "won't be mainstream" do
              @hipster.mainstream?.wont_equal true
            end
          end
        end
        

Matchers (must | wont)

In most cases you can switch between must for positive expectations and wont for negative expectations.

MiniTest::Unit::TestCase

Provides a rich set of assertions to make your tests clean and readable.

require 'minitest/autorun'
        
        class TestHipster < MiniTest::Unit::TestCase
          def setup
            @hipster = Hipster.new
            @list    = Array.new
            @subject = ["silly hats", "skinny jeans"]
          end
        
          def teardown
            @hipster.destroy!
          end
        
          def test_for_helvetica_font
            assert_equal "helvetica!", @hipster.preferred_font
          end
        
          def test_not_mainstream
            refute @hipster.mainstream?
          end
        end
        

Assertions (assert | refute)

Toggle between assert for positive assertions and refute for negative assertions.

MiniTest::Mock

A simple and clean mock system. There two essential methods at our disposal: expect and verify.

require 'minitest/autorun'
        
        class Twipster
          def initialize(twitter)
            # A Ruby wrapper for the Twitter API
            @twitter = twitter
          end
        
          def submit(tweet)
            @twitter.update("#{tweet} #lolhipster")
          end
        end
        
        describe Twipster, "Make every tweet a hipster tweet." do
          before do
            @twitter  = MiniTest::Mock.new
            @twipster = Twipster.new(@twitter)
          end
        
          it "should append a #lolhipster hashtag and update Twitter with our status" do
            tweet = "Skyrim? Too mainstream."
            @twitter.expect :update, true, ["#{tweet} #lolhipster"]
            @twipster.submit(tweet)
            assert @twitter.verify # verifies tweet and hashtag was passed to `@twitter.update`
          end
        end
        

Resources

1. MiniTest on Github
2. MiniTest Rdoc
3. Using MiniTest::Spec with Rails
4. Ruby Inside: A MiniTest::Spec Tutorial: Elegant Spec-Style Testing That Comes With Ruby

I hope you found this quick guide valuable. Please let me know if you'd like to see anything else included and feel free to ask questions or give feedback in the comments section.

def foo(bar, &block)
          callback = block
          callback.call(bar)
        end
        
        foo(5) {|x| x * x} # => 25
        

But what do we do when a method needs two blocks of code or more? Consider the classic case where we want a method to execute a block of code if an action succeeds or call different code if an action fails.

In this article, I will demonstrate how we can pass multiple blocks to a method and with some metaprogramming, we can achieve a dynamic callback mechanism with just a few lines of code.

Let's add a method called callback to the Proc class:

class Proc
          def callback(callable, *args)
            self === Class.new do
              method_name = callable.to_sym
              define_method(method_name) { |&block| block.nil? ? true : block.call(*args) }
              define_method("#{method_name}?") { true }
              def method_missing(method_name, *args, &block) false; end
            end.new
          end
        end
        

That's it! The above Proc#callback method simply yields an anonymous class with methods defined to handle our callbacks. This allows for the capability of creating and storing dynamic callbacks, which can later be looked up and executed as needed.

Notice anything unusual? We're using the === operand to invoke the block. Proc#=== is an alias for Proc.call. Anything on the right side of === acts as the proc's parameter. Normally, this is to allow a proc object to be a target of a when clause in case statements, but we're using it as a super simple way of invoking our anonymous class.

Let’s try it with something useful. Let’s say we’re writing something which needs to happen in an all-or-nothing, atomic fashion. Either the whole thing works, or none of it does. A simple case is tweeting:

def tweet(message, &block)
          Twitter.update(message)
          block.callback :success
        rescue => e
          block.callback :failure, e.message
        end
        

The tweet method accepts a message string and &block parameters. We call callback on the block and give it a name. Any name will work :success, :error, :fail!, whatever. In addition, we can pass arguments to the blocks (more on that later). Now we can provide a status if the tweet was successful or not:

tweet "Ruby methods with multiple blocks. #lolruby" do |on|
          on.success do
            puts "Tweet successful!"
          end
          on.failure do |status|
            puts "Error: #{status}"
          end
        end
        

The advantage here is that we define our own mini DSL. We don't need to worry about passing too many or unexpected blocks. We could have easily said where.success or on.error or update.fail!. Also note the on.failure block includes a status parameter - this contains the exception message captured in the tweet method above. So if Twitter was down for whatever reason, the on.failure block would be invoked and printed 'Error: Twitter is down or being upgraded'.

Bonus: In addition to wrapping code in blocks, our Proc#callback method defines boolean style methods. So we could have call the tweet method like this if we wanted to:

tweet "Ruby methods with multiple blocks. #lolruby" do |update|
          puts "Tweet successful!" if update.success?
          puts "Sorry, something went wrong." if update.failure?
        end
        

Put the Proc#callback method in a utility library and your code will look neat and tidy.

As always, I welcome your thoughts and feedback. Let me know what you think of the techniques shown here, or share your own favorite code block tricks.

Update: After last week's launch, Nyan Cat received a great response from the Ruby world. Over the weekend, I released version 0.0.2. It includes a few bug fixes and some really cool enhancements. Most notably, Nyan Cat now spans multiple lines. In addition, it displays running totals of passing, pending, and failed specs. Thanks to everyone who contributed! Checkout the new screencast below.

-_-_-_-_-_-_-_,------,
        _-_-_-_-_-_-_-|   /\_/\
        -_-_-_-_-_-_-~|__( ^ .^)
        _-_-_-_-_-_-_-""  ""
        

Nyan Cat

Much like Nyan, Nyan Cat simply creates a rainbow trail of test results. It counts the number of examples as they execute and highlights failed and pending specs. The rainbow changes colors as it runs and if all the specs pass, Nyan Cat falls asleep. If there are any pending or failing specs, Nyan cat is concerned and can't sleep.

Here's a short demo of Nyan Cat in action.

Installing Nyan Cat is easy. Just install the gem nyan-cat-formatter and simply put the options in your .rspec file:

--format NyanCatFormatter
        

Checkout the code on Github and let me know how you like it. If you run into any issues, please create an issue on Github and I will be sure to get it fixed. Of course you can always fork the project and send me a pull request.

Have fun!

Built with Grit, Gaga supports SET, GET, KEYS, and DELETE operations. And since it's Git, we can easily enhance it to include other awesome Git features such as branches, diffs, reverting, etc.

Usage

@gaga = Gaga.new(:repo => '/path/to/repo')
        
        # SET
        @gaga['lady'] = "gaga"
        
        # GET
        @gaga['lady'] #=> "gaga"
        
        # KEYS
        @gaga.keys  #=> ['lady']
        
        # DELETE
        @gaga.delete('lady') #=> 'gaga'
        
        # Remove all items from the store
        @gaga.clear
        

That works pretty well. Now, we can harness the power of Git and enhance our data store. For example, we can get a history log for a specific key:

# LOG
        @gaga.log('lady')
        
        # Produces:
        [
         {"message"=>"all clear","committer"=>{"name"=>"Matt Sears", "email"=>"matt@mattsears.com"}, "committed_date"=>"2011-09-05..."},
         {"message"=>"set 'lady' ", "committer"=>{"name"=>"Matt Sears", "email"=>"matt@mattsears.com"}, "committed_date"=>"2011-09-05..."}
         {"message"=>"delete 'lady' ", "committer"=>{"name"=>"Matt Sears", "email"=>"matt@mattsears.com"}, "committed_date"=>"2011-09-05..."}
        ]
        

This is just a start. There's still a lot things we can add. If you are interested in more detailed information, check out the repo on Github.

Quick Start

First, you will need to register for a (free) developer account at Stamps.com. Once you receive your test credentials and integration id, just plug them into the configuration block:

Stamps.configure do |config|
          config.integration_id = 'XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXXX'
          config.username       = 'STAMPS USERNAME'
          config.password       = 'STAMPS PASSWORD'
        end
        

For a simple test, we can call Stamps.account to retreive information about the account. By default, Stamps will return all responses as a Hash.

Create a Stamp

First, we need to standardize the shipping address that complies with the USPS address formatting guidelines:

standardized_address = Stamps.clean_address(
          :address => {
            :full_name => 'The White House',
            :address1  => '1600 Pennsylvania Avenue, NW',
            :city      => 'Washington',
            :state     => 'DC',
            :zip_code  => '20500'
        })
        

Now that we have a clean address we can create a new stamp. The Stamps.create! takes the sender and receiver address along with parameters on the rate:

stamp = Stamps.create!(
            :rate          => {
              :from_zip_code => '45440',
              :to_zip_code   => '20500',
              :weight_oz     => '6.5',
              :ship_date      => Date.today.strftime('%Y-%m-%d'),
              :package_type   => 'Package',
              :service_type   => 'US-FC'  # Flat-rate
            },
            :to            => standardized_address,
            :from => {
              :full_name   => 'Littlelines',
              :address1    => '50 Chestnut Street',
              :address2    => 'Suite 234',
              :city        => 'Beavervcreek',
              :state       => 'OH',
              :zip_code    => '45440'
            }
        )
        

Hooray!

That's it! Stamps will return a url of the stamp. Print it and ship it!

stamp[:url]
        

If you are interested in more detailed information, check out the repo on Github.

Like a lot of folks, I keep work and personal items such as email, bank accounts, github, etc in separate accounts. Heroku doesn't really place nice with multiple accounts.

So how to do we effectively manage multiple Heroku accounts?

Prerequitites

The following assumes you are on the Mac OS or *nix system, own multiple Heroku accounts, and have installed the Heroku gem. I should also be point out that you will need to create separate ssh public keys for each account.

Custom Ruby Script

One option is we can use a script such as Keith Gaddis describes over at the Collective Idea blog. With his switcher script, we can switch between two accounts like this:

ruby switcher.rb personal
        ruby switcher.rb work
        

This essentially swaps the credentials file (used by the Heroku gem for authentication) for the account you want to use. This works well enough, however this can be tedious especially if you switch between work and personal projects frequently.

Enter Heroku Accounts Plugin

David Dollar of Heroku recently released an official Heroku plugin called heroku-accounts. With this plugin, we can switch Heroku accounts automatically.

To get started, we first install the plugin:

heroku plugins:install git://github.com/ddollar/heroku-accounts.git
        

The installation process will download the plugin from github and save it to the ~/.heroku/plugins directory. Now, we can setup each of our Heroku accounts with add command:

heroku accounts:add work
        

and for our personal account, we can run:

heroku accounts:add personal
        

The add command will ask you for your Heroku email address and password for each account. The plugin will maintain your account credentials in the ~/.heroku/accounts folder in your home directory. (Passwords are not saved in plain text)

To assign a project to a specific Heroku account, we run the following command in the project root:

heroku accounts:set personal # or work
        

This will assign a Heroku account to the project by adding an 'account' variable to the project's git config file.

Celebrate

Hooray! Now we can switch Heroku accounts automatically. Awesome.

Formtastic

If you're developing wep apps, more than likely it will include html forms. Forms can be a time-drain, not to mention very boring to build. Formtastic provides a more concise way of generating form views and includes inline error messages and is semantically rich.

Resource Controller

Resource Controller hides away the RESTful controller boiler plate code and make your controllers skinny. Skinny controllers help you to consolidate your business logic into one place, thus saves time on maintenance and testing.

Search Logic

Finding data can get messy. Sometimes we run into situations where we are concatenating strings to build SQL statements and this can lead to bugs. Searchlogic works by creating a number of named scopes that can be called on any ActiveRecord model. The best part, you can dynamically call scopes on associated classes and Searchlogic will take care of creating the necessary joins for you.

Alchemist

Occasionally, we work on projects dealing with conversions. Alchemist is a Ruby library that does conversions for you and thus making your code more readable and easier to maintain. For example:

Instead of:

miles = 8 * 1609.344 # converting meters to miles
        

We can write:

8.meters.to.miles
        

Alchemist includes a staggering array of conversions including distance, mass, volume, and more.

andand

andand is a handy gem that allows allows natural method chaining for methods that can return nil. This saves a lot of boilerplate code and improves readability. For example:

Instead of:

@body = (article = Article.find_by_title('test')) && article.body
        

We can write this:

@body = Article.find_by_title('test').andand.body
        

This will call find on the Article class and sends 'body' if the result is not nil. In addition, our methods are guarded from NoMethodErrors is the result is nil.

What is Clojure?

Simply put, Clojure is a functional programming language for the Java Virtual Machine with several powerful features for building concurrent applications. In addition, Clojure is fast, robust, and a powerful general-purpose programming language. A dialect of Lisp, Clojure embraces traditional code-as-data philosophy and a powerful macro system, plus some syntactic sugar tailored to Java.

Now that version 1.0 is out and Stuart Halloway's new book Programming Clojure just dropped, I've rounded up some of the best articles and tutorials on Clojure to you get you up to speed quickly.

Tutorials and Links

• A Clojure Tutorial by R. Mark Volkmann

• Programming Clojure book by Stuart Halloway

• Practical Common Lisp to Clojure by Stuart Halloway

• Clojure Series: Table of Contents by Eric Rochester

• Learning Clojure via Wikibooks

• Clojure Programming/Examples/API Examples via Wikibooks

• Clojure Programming/Tutorials and Tips via Wikibooks

Screencasts, Videos, and Presentations

• Functional Programming with Clojure by Phil Hagelberg (PeepCode)

• Clojure Series on Blip.tv by Rich Hickey

• Intro to Clojure by Brian Will (YouTube)

• Emacs with Clojure, Slime and Swank by Seth Buntin (Vimeo)

Tools and Setup

• Basic Clojure Setup by Telman Yusupov

• Setting Up Clojure for Mac OS X Leopard by Mark Reid

• Getting Emacs setup to write Clojure code by Phil Hagelberg

• Textmate Bundle for Clojure code by Scott Fleckenstein

• VimClojure, a Vim plugin for Clojure

Documentation

• Official Clojure site

• Official Clojure API

• Clojure Docs

• Clojure Coding Guidelines by Mark Volkmann

Much inspiration for Aerial has come from Marley, a minimal flat-file blog engine written in Sinatra. Like Marley, Aerial is built with Sinatra and uses plain text files. Unlike Marley, Aerial doesn't use a SQL database and uses Grit to retrieve article and comment files from a Git repository.

So how does it work?

Articles and comments are stored as plain text files in a local Git directory. Aerial parses each file and converts them the Article and Comment objects with their own set of attributes such as title, body, tags, and author. For example, this article looks something like this:

Title      : Git blogging with Aerial
        Tags       : projects, ruby, git, sinatra
        Published  : 03/28/2009
        Author     : Matt Sears
        
        Over the last few years...
        

Since Aerial reads the articles from the Git repository, the contents of article won't display in the browser unless the changes are committed to Git. Same goes for comments.

Working with remote repositories

Aerial uses local and remote Git repositories to sync data between the production web server and your local environment. For example, when comments are submitted on the production web server, they are checked for Spam via Akismet and saved to the same directory as the article. Then, the new comment file is added to the production web server's repository and pushed to the remote repository (Github in my case). To pull in user comments to our local environment, simply use the pull command:

git pull
        

Now we have all the comments that users have submitted.

Getting Started

For Aerial to work, you'll need Git installed and the following RubyGems:

sudo gem install sinatra grit rdiscount haml
        

Grab the source code from Github.

A small configuration file in config/config.yml is used to store information about your blog. You can add your info now or leave it as is and it will still work. To setup and run Aerial, we need to run the boostrap Rake task:

rake bootstrap
        

This will install the necessary directories (specified in the config.yml file), javascript files, and insert a sample article to get you started. If every goes smoothly, Aerial should be up and running at:

http://localhost:4567
        

Keeping in spirit with minimalism, all the pages use Haml for the templating engine. Of course, you may change this to the templating engine of your choice.

Creating new articles

Create a new folder in the app/articles directory. You can name this folder anything you want, but it may be helpful to number them so they display in the order you want them to. For example, the folder for this articles looks like this:

app/articles/011-introducing-aerial
        

Next, create a text file with the extension '.article' and save it to the new folder. The '.article' file extension let's Aerial know that this file should be converted to an Article object. The name of the article will be the article's permalink. Remember, the article will not display on the site until it's committed to the git repository. When the article is completed, we can push it to the remote repository with the push command:

git push
        

Now, we're ready to deploy it.

Deployment

Deployment tasks are handled with Vlad the Deployer. A simple deployment script is located at config/deploy.rb. It assumes your running Apache and Phusions Passenger, but you can edit this file with your own settings. Future enhancements may include auto-syncing with post-receive hooks so that 'git push' will make Aerial update itself, but for now we can deploy with a simple rake task:

rake deploy
        

This is by no means a comprehensive introduction. If you have any questions or run into any problems, please drop me a line.

This week marks the two year anniversary when I delivered my first professional Rails app. Today, I decided to take a look back at the code of that first project and see what's improved over the past two years. The result - not bad, but there were a couple areas that stood out. Here are a few:

1. The controllers in that first project were out of control. Not sure why, maybe coming from the J2EE world, my first instinct was to cram everything into the controller. It was apparent that the concept of REST wasn't completely baked into my brain yet. Not to mention the concept of fat models, skinny controllers.
2. Second, the views and Javascripts were a bit unorganized. I noticed excessive conditional logic and messy Javascript code in a few of the pages. If I was to re-write the app today, most of it could be cleanup with rendering partials with collections and using Low Pro to clean up the Javascript.
3. Finally, the sheer lack of plugins for that first project was surprising. It's true that the amount and quality of plugins have grown in two years, but I believe the lack of awareness was the main cause.

So this made me think of what I would say if I were to advise newcomers writing their first Rails app. I would have to say first, if you find yourself writing code in the controller, then ask yourself "Can I put this logic in the model?". And also be sure to familiarize yourself with the available plugins with sites such as Agile Web Development and Github. They can save you a ton of work.

Photo credit: Dan BenJamin

Day 1:

Gregg Pollack's talk on Scaling Ruby (without Rails) was really good. He touched on green and native threads, EventMachine, message queues, and profiling code with ruby-prof. My favorite part of the presentation was the performance tips and tricks of optimizing Ruby code. His talk is up at EnvyCast and I definitely recommend it.

Jamis Buck - "Recovering from the Enterprise" was probably my favorite presentation at the conference. The main theme of his talk was that working in the enterprise solves problems differently than those solutions in Ruby. Jamis worked in Java (like me) before Ruby and he told a story of how he written a library for dependency injection for Ruby but realized that he was trying to use Java solutions in a Ruby world that didn't need it. He said Java is like Legos and Ruby is like Play-doh and delivered the best quote of the conference "Just in time, not just in case"

Photo credit: Dan BenJamin

Day 2:

Effective and Creative Code by Eric Ivancich was awesome. He discussed how our minds work while programming - the differences between fascination and direct attention, the mental fatique and long periods of direct attention can have on you. Fascinating stuff.

Yehuda Katz taught us how to write code that doesn't suck with Interface Oriented Design. But first, he announced that Merb 1.0 was released just minutes before his presentation. Then he went on to say that unit tests are not regression tests and that writing regression tests should make sure that the API we are exposing to the world doesn't break while work is being done under the covers.

Photo credit: Dan BenJamin

Day 3:

I saw Neal Ford's talk on Advanced DSLs in Ruby - one of my favorite topics. This presentation was really good because Neal was very specific on how to build DSLs in Ruby and not just the basics. He covered various techniques on writing DSLs and provided a nice summary of his talk on his website.

I sat down next to Dave Thomas to listen to Gregory Brown's talk about Prawn, a pure Ruby PDF generation library. Prawn is cool, but how Prawn was born was the most interesting part of the talk. A community funded project called The Ruby Mendicant Project allowed Gregory to quit his job and work on Prawn full time - A Ruby community employee.

Overall it was an amazing conference. It was great to see and talk to people that I only get to see online. Looking forward to next year.

git add .
        git commit -a -m 'A description of the change'
        git push
        cap production deploy
        

It would be nice if I could do all of the above with just one command. So I created this shell script:

push() {
        
          # Defaults
          MINLEN=25
          DIRTY=false
          DEPLOY="production deploy"
          REMOTE_REPO = "origin master"
        
          # Check if we have any untracked files
          if git status | grep -q "modified:"
          then
             DIRTY=true
          fi
        
          # Make sure there is a message with the commit
          if [ -z "$1" ] && (test $DIRTY == true)
          then
            echo "You must specify a message with your commit"
            return
          elif [ ${#1} -lt $MINLEN ] && (test $DIRTY == true)
          then
            echo "Your message must have at least $MINLEN letters."
          return
          fi
        
          # Commit all the changes by default
          if (test $DIRTY == true)
          then
             echo "Adding new files to Git repository"
             git add .
        
             echo "Commiting to local Git repository"
             git commit -a -m "$1"
        
             # Push changes if a remote repository exists
             if git remote | grep -q "origin"
             then
                echo "Pushing changes to remote repository"
                git push $REMOTE_REPO
             fi
          fi
        
          # Deploy changes via Capistrano
          if ls | grep -q Capfile
          then
             cap $DEPLOY
          fi
        }
        

The 'push' function will first check to make sure you supplied a description if any recent changes were made. Second, it will commit all the code and push it to the remote repository (if one exists).

If none of the code was modified or added, it will skip the Git commands and simply run the Capistrano deploy command and not require a description for the changes.

To use this script, copy and paste the above function to the end of your ~/.bash_profile file. To run it, simply run the 'push' command.

push "The description for the committed changes."
        

That's it! All the code is added, commited, pushed, and deployed.

Photo credit: EdgeCase, LLC

What is legacy code and how do we avoid it? Stuart Halloway addresses these questions with his talk Ending Legacy Code In Our Lifetime. This was my favorite talk on the first day because the Enterprise is "full of it" and much my time was spent trying to avoid it. It's nice to see somebody calling attention to it.

Photo credit: EdgeCase, LLC

Very interesting talk on JRuby by it's creator Charles Nutter on the second day. I went back to the hotel room that evening and setup JRuby on my laptop. I wrote a quick rails app and with Warbler, had a working war file ready to be deployed to Java application server. Very impressive.

Photo credit: EdgeCase, LLC

Perhaps my favorite session at the conference was Jim Weirich's talk on concurrent software development. Something I don't think is talked about enough and is certainly important in the Enterprise. I've written multi-threaded apps in Java and it can be very difficult especially avoiding deadlocks. Is Ruby the answer? According to Jim, not really. Perhaps a Erlang or Clojure offers a better solution.

Photo credit: EdgeCase, LLC

And Finally, Chris Wanstrath, co-creator of GitHub talks about Git, GitHub, and a little about side projects. Oh, and did I mention I really love GitHub? It's really changing how we develop software.

Photo credit: EdgeCase, LLC

• All the photos above are provided by EdgeCase, LLC and more are available on their Flickr page.

Here is a rundown of the changes made:

1. Upgraded to Ubuntu 8.04 Hardy Heron
2. Installed Apache and Phusion Passenger (mod_rails)
3. Change and tweaked Mephisto theme

I'm still in the process of moving my old blog posts over. More big news coming soon.

The article can be seen here.

I had the opportunity to attend a few good sessions with pros like Bjarne Stroustrup, Herb Sutter, Martin Fowler, Eric Evans, Stephen Dewhurst, Ken Pugh, Allen, Hollub, and Bruce Schneier to name a few. There really is no substitute from learning hands-on from experts like these. I left each session feeling like I just learned an entire year's worth of knowledge. And of course, there were other things to do at the conference besides classes - Jolt awards, the expo, and Joel Spolsky was back to screen his documentary called Aardvarked.

This year, I made it point to get out of the hotel, convention center, and bar to explore Silicon Valley. I drove around town with no real plans except to search for better food. The hotel food is awful, which is ironic since it costs 3 times more. Twenty six dollars for a chicken sangwich, fries, and drink - get real. There are a lot more locally owned restaurants in Silicon Valley that are a lot cheaper. There are especially a lot of Thai restaurants, which is good, because I love Thai food. I think I had that like three times.

There are quite a few good restaurants in Sunnyvale too, but you have to know where to look.

Not going to make it back there this year. This is year is crazy busy and going to get busier and crazier, and any other 'ziers I can't think of right now.

Instead of installing the action_mailer_tls plugin and configuring each of our Rails apps, we can do a one-time setup of our local Postfix client to relay all SMTP outbound emails to our Gmail account. If your running a Mac OS Leopard or Linux, Postfix should already be installed. With a little configuration, we should be up and running in a couple minutes.

First create /etc/postfix/relay_password file with the server name, email account name and password as shown below. This configuration works with Gmail accounts as well as with Google Apps email accounts. I'm personally using my company's Google Apps with a special email account setup for outbound emails only.

smtp.gmail.com    example@yourdomain.com:yourpassword
        

Then tell Postfix about our google accounts information so it knows how and where to relay the email to. This can be done with the postmap command:

$ postmap /etc/postfix/relay_password
        

Since Gmail requires a TLS (Transport Layer Security) connection for certificate-based authentication, we'll need to download a free root certificate from Verisign https://www.verisign.com/support/roots.html to authenticate our remote SMTP client.

$ mkdir /etc/postfix/certs
        $ cd /etc/postfix/certs
        $ sudo cp roots.zip /etc/postfix/certs
        $ sudo unzip -j roots.zip
        $ sudo openssl x509 -inform der -in ThawtePremiumServerCA.cer -out  ThawtePremiumServerCA.pem
        $ sudo c_rehash /etc/postfix/certs
        

Now we are ready to configure Postfix. Postfix needs to know what host to relay the email to, the username and password to authenticate the Gmail account, and the path to our certificates for the encrypted session. Add these lines to the bottom of /etc/postfix/main.cf

relayhost = smtp.gmail.com:587
        # auth
        smtp_sasl_auth_enable = yes
        smtp_sasl_password_maps = hash:/etc/postfix/relay_password
        smtp_sasl_security_options = noanonymous
        
        # tls
        smtp_tls_security_level = may
        smtp_tls_CApath = /etc/postfix/certs
        smtp_tls_session_cache_database = btree:/etc/postfix/smtp_scache
        smtp_tls_session_cache_timeout = 3600s
        smtp_tls_loglevel = 1
        tls_random_source = dev:/dev/urandom
        

Restart (or start) Postfix to pick up our new changes.

$ sudo postfix stop
        $ sudo postfix start
        

That's it! Now we don't have to do any special installation or configuration to send email via Gmail for our Rails apps. We just need to set the delivery method to :smtp and we're ready to go.