Matthew Bass

Git is a wonderful SCM with some very powerful features. But as a programmer, it’s very easy to aquire a rudimentary working knowledge of Git and never learn anything more. For example, how would we fix our repository if we committed the wrong piece of code? What if our commit had an error in it? How do we fix things without reverting or introducing a second commit?

It turns out this is very easy to do. The latest versions of Git have an amend command. Amend lets us alter the last commit we made. All that’s necessary is for us to arrange our working directory the way we want the last commit to look and then execute:

git commit --amend

This will update the most recent commit based on the state of our working directory. For example, say we changed our README file in the last commit and accidentally introduced a typo. To fix the last commit, we would edit the README again, git add the change, and instead of running git commit which would create a second commit, we run git commit --amend which patches the last commit. This can be repeated as many times as necessary.

Note that rewriting history like this can have serious implications if you’ve already published the most recent commit. But if you’re the only developer using the repository, or if you haven’t published yet, this can be a great way to fix minor mistakes without introducing an entirely new commit.

You can read more about amend in the documentation.

Lindo is great for verifying your Rails tests by opening the HTTP response body in a browser for inspection. It works with most popular testing frameworks including Test::Unit and RSpec. But what about Cucumber?

It’s actually pretty easy to build a custom Cucumber step that triggers Lindo from your cukes. First, install the Lindo gem in your Rails app. Then create features/steps/lindo_steps.rb and insert this code:

Then /^render the current page$/ do
  extend Lindo
  vr
end

The step can be named whatever you like best, but “render the current page” works for me. To trigger Lindo from within your cukes, simply reference the step like so:

Given I am logged in
When I follow "some link"
Then render the current page

When Cucumber hits the last step, the default browser window will open and the contents of the page at that step in the scenario will be displayed. This is very handy when troubleshooting why a specific scenario is failing. It’s also useful for determining what you should be testing for on a given page.

I recently upgraded my blog to WordPress 2.9.1 and I’m very pleased with the results. The upgrade itself was very straightforward. It was just a matter of replacing the correct files in my project. I have my project checked into GitHub so I was able to immediately see what had changed. I also had a safety net in case I wanted to back out of the upgrade.

One nice benefit to upgrading was that I’m now able to leverage the Syntax Highlighter plugin. It does nifty stuff like this:

class HelloWorld
  def say_hello
    puts "Hello world!"
  end
end
HelloWorld.new.say_hello

If you run a WordPress blog, I would definitely recommend checking it into some sort of source control. Also, being able to run the blog on my development system is very beneficial. I was able to verify that the upgrade hadn’t borked my layout before making everything live. I use Apache to serve it up locally.

What platform do you use for blogging? What do you like about it?

If you’ve ever performed a fresh install of Ubuntu, you’ve probably noticed that the delete/backspace key doesn’t work correctly in nano. This is frustrating, but easy enough to fix.

This problem also occurs quite frequently for me when logging into a remote server. For example, a default Slicehost instance usually suffers from this behavior.

If you truly want to understand what causes the problem, check out this article.

Lindo helps you write and verify Rails functional and integration tests by opening the HTTP response body in the default browser for inspection. This can be a real time-saver when you’re trying to figure out why your assert_select or have_tag calls aren’t passing.

In its initial version, Lindo assumed that your app was running at localhost:3000 (a fair assumption given the prevalence of Mongrel last year). Now that Passenger is on the scene, something better needed to be done. The reliance on a running app server was a disadvantage to begin with. Now Lindo doesn’t require anything to be running. It dumps the HTML to disk, fixes any relative asset URLs, and opens the file using your default browser.

Once you’ve written your first test with the assistance of Lindo, you won’t want to go back!

Lindo was developed by my company, Adeptware, and can be pulled from GitHub. I’ve also posted a brief introduction to Lindo and some basic installation instructions.

I released the initial version of my auto-session-timeout plugin for Rails at West End Ruby tonight.

Have you ever wanted to force your users off your app if they go idle for a certain period of time? Many online banking sites use this technique. If your app is used on any kind of public computer system, this type of functionality is essential for maintaining the privacy of your data.

After installing the plugin, a small snippet of JavaScript is placed on each page. The JS polls the server every minute to see if the session is still active. If the user has been idle for at least an hour, they are immediately redirected to a timeout page. The session will not timeout as long as the user keeps clicking around. The timeout and polling intervals are both configurable.

The plugin is dead simple to install and configure. To get started:

script/plugin install git://github.com/pelargir/auto-session-timeout.git

Then hit the README for step-by-step instructions.

After spending nearly an hour tracking down where a particular TextMate bundle was coming from, I have surmised that there are no less than four places on my Mac’s hard drive where bundles may be lurking. In no particular order, they are:

~/Library/Application Support/TextMate/Pristine Copy/Bundles
~/Library/Application Support/TextMate/Bundles
/Applications/TextMate.app/Contents/SharedSupport/Bundles
/Library/Application Support/TextMate/Bundles

I’m really enjoying using Brightkite. It’s a location-based social networking tool that lets you see what other people in your vicinity are doing. A GPS unit isn’t required and it integrates fairly well with Twitter and GMaps. (I’d love to see even tighter Twitter integration in the future.) Drop a comment on this post if you want an invite.

I began getting a strange error message from git earlier this week:

key_read: uudecode (random SSH key junk here)
 ssh-rsa (more random SSH key junk here)
 failed

The error message only showed up when I ran git pull. Google didn’t find much to help me, but acting on a hunch I removed the IP address of my git repo from my known hosts. The error immediately went away.

If you’re getting the same message, determine the IP address or domain name of your git repo. Search for those values in your ~/.ssh/known_hosts file and remove them. You should be good to go after that.

Being at RubyConf this weekend has provided the necessary motivation for me to finally release a new Ruby gem I’ve been building. It’s an extraction from a project I’ve been working on for Relevance.

I’m a regular user of assert_select in my functional tests. I find myself frequently doing something like this when the assertion is failing and I can’t figure out why:

def test_something
  post :something
  raise @response.body.inspect
  assert_select "div[id=header]"
end

Inspecting the response body usually leads me to a solution, but it’s tedious parsing through the huge amount of HTML that gets returned, often in a semi-unreadable format. Enter the response_visualizer plugin (which has since been renamed Lindo):

script/plugin install http://github.com/adeptware/lindo/

Or clone the project directly:

git clone http://github.com/adeptware/lindo/

The plugin provides a vr method to your functional tests. When this method is called, the response body is automatically opened in the default browser allowing for easy visual inspection of the page’s content:

post :new
vr
...

If you’d prefer to jump straight to the source code, passing the :html symbol will open the formatted HTML in the default text editor:

post :new
vr(:html)
...

This has saved me a lot of time in figuring out why a specific assertion is failing. Instead of parsing through the HTML, I can view the entire page and immediately tell if something is missing or out of place. I find myself calling vr even before I write my assertions now.

After installing, check out the README file for additional documentation. There is also a GitHub project if you’d like to contribute a patch or fork the code. Enjoy!