git diff <branch name> – means what would change if we applied the current working HEAD of the branch we are on, including all unstaged/uncommitted changes, to the named branch.

git diff <branch 1> <branch 2> – means what would change if we applied <branch 2> onto <branch 1>

I encountered another problem now. When I ran my autotest but tried to shut it down by hitting Control-C twice in a row, the tests would just reset and run again. Double Control-C is supposed to interrupt the process and allow me to shut it down. This it did not do.

I am also running the autotest/menu plugin that is supposed to explicitly ask you whether you want to quit, restart or just keep going when you hit Control-C, even if it’s just hitting it once. This is the best possible option and is what I recommend, but it wasn’t happening. There were no prompts to quit, continue, or restart. Just restarting the entire test suite EVERY time I hit Control-C, whether it was two quick hits or 10 hits a row.

I originally looked at the code thinking that I should fix it there. Autotest provides hooks into it’s process. Run, interrupt, quit, etc. I figured it had to do with one of those so I first tried just commenting out the :interrupt hook code on lines 39-41 in ZenTest-4.0.0/lib/autotest/snarl.rb. This worked and I was happy. However it still didn’t feel right. I didn’t want to hack the code and ask them to fix it. It must be working for other people because I haven’t seen other people complaining about it.

Turns out the fix is a really easy one and requires no hacking on the gem code at all. It was just a problem with the order of my “require” lines in my .autotest file. My original .autotest file looked like this…

require 'redgreen/autotest'
require 'Win32/Console/ANSI'
require 'autotest/snarl'
require 'autotest/menu'
require 'autotest/timestamp'

The .autotest file that WORKS swaps the “snarl” and “menu” lines around, like so…

require 'redgreen/autotest'
require 'Win32/Console/ANSI'
require 'autotest/menu'
require 'autotest/snarl'
require 'autotest/timestamp'

NoMethodError: undefined method `admin' for #<Admin::RegistrationsController>

but what was the first line that came up in the backtrace?

app/controllers/admin/registrations_controller.rb:18:in `show'

This was giving me fits. There’s no call to ‘admin’ in the ‘show’ method. I knew there had to be something else so I searched for how to see more of the backtrace.

The BacktraceCleaner introduced in Rails 2.3.2 cleans out backtrace lines coming from the Rails framework (Railties, etc). This is usually what you want. However, I was sure that my error was coming from somewhere in the framework. Turns out it’s really simple to turn off the backtrace cleaner. Add this line in a ‘setup’ method in your test_helper.rb file.

Rails.backtrace_cleaner.remove_silencers!

Very simple, very easy. My name is Chef Tell.

NoMethodError: undefined method `assert_select_email' for #<UserMailerTest>

I posted to the rubyonrails-talk google group but never got a response, and I was not the first to post about this problem to that group. However I found someone else commenting on this in an rspec lighthouse ticket and they’d fixed it for their setup. It was an easy conversion to non-rspec and here’s the line you need to add to your test/test_helper.rb file

include ActionController::Assertions::SelectorAssertions

I’m not sure why it’s broken but it appears to have regressed in one of the Rails 2.3.2 RCs.

I uploaded this through

… when playing football, do not punt a brick!

I uploaded this through

Chris Coyier over at CSS Tricks uses the following code in his .htaccess file to block visitors.

RewriteEngine On
RewriteBase /
RewriteCond %{REMOTE_HOST} !^71\.225\.113\.171
RewriteCond %{REMOTE_HOST} !^71\.185\.239\.212
RewriteCond %{REMOTE_HOST} !^69\.253\.223\.254
RewriteCond %{REQUEST_URI} !/comingsoon\.html$
RewriteRule .* /comingsoon.html [R=302,L]


What he’s doing there is checking for specific IP addresses that are allowed to see the website but everyone else is sent to the “comingsoon.html” webpage. This is great for people who have specific IP addresses but if you’re behind a proxy like I am at work then everyone else with you behind that proxy can still see the site.

I find it much easier to redirect everyone but check for a custom cookie that I can set using the Webdeveloper Firefox extension. That way I can check to make sure that the redirect to the maintenance page is actually working. Here’s the relevant code that I use (taken from a RoR tutorial of old)

RewriteCond %{DOCUMENT_ROOT}/maintenance.html -f
RewriteCond %{SCRIPT_FILENAME} !maintenance.html
RewriteCond %{HTTP_COOKIE} !^.*access_cookie=1.*$
RewriteRule ^.*$ /maintenance.html [L]


where the text “access_cookie” (sans quotes) would be whatever cookie name you want to use. I just create a “session cookie” set to a value of “1″ (or whatever you want to make it) and check for it’s existence.

That gets around the problem of DHCP granted or spoofed IP addresses. Sure a cookie is easy to add but if you make the name and/or value sufficiently difficult to guess, no one is getting in.

Now just add your cookie.

Note in the image that I have set it to be a “session cookie”. This helps when you forget to delete the cookie. Just close your tab (FF) or browser (IE), reopen it and the cookie will be gone.

Oh yeah. The other thing that my .htaccess code does is, on the first line, check for the existence of the “maintenance.html” file. I don’t want to have to add and remove this code everytime I want to take the site down. It’s much easier to just have this code permanently in my .htaccess file and then upload the file that people will see when the site is down. I then delete it when the site is ready to be reopened. This is all performed using a custom Capistrano command that I run when I’m ready to deploy a new version.