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.

For example, say I have a table of records with created_at timestamps. My view displays all records with timestamps equal to or before the current time. Let’s assume the current time is 15:00:00 precisely and I happen to have a record with a timestamp of 15:00:00 in the database. The SQL comparison would work fine in this case.

SELECT * FROM records WHERE created_at <= "2010-06-25 15:00:00"
=> 1 row in set

What if the timestamp in the database is 15:00:03 though? Let’s run the query again.

SELECT * FROM records WHERE created_at <= "2010-06-25 15:00:00"
=> Empty set

Since 15:00:03 is greater than the current time of 15:00:00, the record doesn’t get returned. This would be fine if we were displaying seconds in the view, but we’re not. From the user’s perspective, the timestamp on the record is still 15:00 and should appear in the view since it’s equal to the current time. But it doesn’t.

One way to fix this would be to handle the time comparisons in Ruby. This is certainly a legitimate option. For this particular project, though, performance was a big issue. (And we all know that Rails can’t scale.) I needed a way to continue letting the database handle the comparisons while disregarding seconds.

The solution I ended up with isn’t ideal (it relies on a couple of functions built into MySQL) but it works fine and runs fast:

SELECT * FROM records WHERE (created_at - INTERVAL SECOND(created_at) SECOND) <= "2010-06-25 15:00:00"
=> 1 row in set

The number of seconds is extracted from the created_at timestamp and then subtracted from the timestamp. So if the timestamp was 15:00:03, MySQL subtracts 3 seconds to end up with 15:00:00.

This solved the comparison problem for me and made my client very happy. Double win.

Ruby is a fantastic tool. But it’s not just a tool, it’s also an art medium. I had never truly seen beautiful code until I met Ruby. All that being said, when I was first introduced to the language it was a lot like trying to breathe while standing under Niagara Falls. The “wow-that’s-cool-but-I-don’t-quite-grok-it” moments came fast and furious. Ruby was blowing my mind on a daily basis.

It doesn’t anymore. At least, not every day. But at least once a month, I see a code snippet or read a blog post or hear about a new way to do something and… well, there goes my mind again. For example…

Classes Are Constants

The fact that classes are constants in Ruby doesn’t seem particularly remarkable on the surface, but when you need to do something like this it sure comes in handy:

class Widget
  def self.name
    "I'm a nice Widget class"
  end
end

class Doohickey
  def self.name
    "I'm an even nicer Doohickey class"
  end
end

class ObjectRenderer
  def self.render(klass)
    puts klass.name
  end
end

ObjectRenderer.render(Widget)        => I'm a nice Widget class
ObjectRenderer.render(Doohickey)     => I'm an even nicer Doohickey class

Once I grokked the usefulness of classes and constants being interchangeable, I began coming across lots of places in my code where I was able to refactor a complex bit of logic into a shorter, more simpler form. That’s one of the neat things about Ruby: once you learn a given Rubyism, it can be applied all over the place.

Iterating Over Collections

Let’s face it: iterating over a collection in Java, or even in C#, is bulky and painful. When I ran across Ruby’s beautiful Enumerable module, my mind was once again totally blown by the simplicity and elegance:

animals = ['dog', 'cat', 'bird']
animals.each { |a| print a + ' ' }       => dog cat bird
puts animals.select { |a| a =~ /do/ }    => dog

I’ve never been much of a fan of Perl. I’m guessing something similar can be done there. But for me, a young developer fresh out of college, the ability to iterate (not to mention define an array or a hash) in a single line of code was a big draw away from my world of statically typed languages. The readability of Ruby’s syntax is immensely gratifying.

Ruby’s Vibrant Community

Perhaps the most mind-blowing thing of all is the Ruby community itself. I have never come across a more intelligent, passionate, and close-knit group of developers as those who call Ruby their language of choice. The wild Rubyist used to be a rare breed, but we’re quickly becoming more common as Ruby’s fame continues to spread. Whether I’m meeting new folks at the local Ruby Meetup, doing some late night hacking in Chicago at RailsConf 2006, or just chatting in Campfire with fellow Terraliens, the openness and technical savvy of these people is stunning.

It’s truly a humbling experience to be part of this movement. And that’s really what it is: a movement aimed at refactoring the norms of software development. Ruby and the frameworks built with it continue to grow and evolve. The community, myself included, grows and evolves along with it.

Here’s hoping that Matz, DHH, and the other brilliant people behind these wonderful technologies continue blowing our minds with creative innovations for years to come.

My friend and former co-worker Sri has written an article about code reviews that was published on java.net today. Here’s a teaser:

Need to be sure your program really runs right? Oh sure, testing’s a part of it, but so are code reviews. Sri Sankaran argues that research and experience prove that a standardized, effective code review process mitigates costs and produces better code.

Coming from an agile development background, I’ve participated in several code reviews myself. Properly used they can be an effective way to ensure that the software being shipped is solid, and that the team is on the same page when it comes to standards and organization.

Read the full article at java.net!

The highlights from day three were Andy Hunt’s “Refactoring Your Wetware” and “Pragmatic Learning” talks, along with Jared Richardson’s “Software Tools.” I had heard Andy’s wetware talk at the local .NET Users Group last year, but he has since revised and lengthened it, splitting it into two different NFJS talks.

The first talk covered how the brain works (it’s a dual CPU, shared pipe architecture) and how developers can make incredible productivity gains by using more of their right brain instead of their left. In the second talk, Andy gave tips on how to learn more effectively.

One point that struck home for me was the need to write all your ideas down the moment you get them. If you’re not writing your ideas down, you’ll start forgetting you have them. I’ve been using a plain old ballpoint pen (not all of us have enough cash kicking around to buy a Fisher Space Pen) and some index cards. They work quite well, and I get the added benefit of more right-brain activity. I wouldn’t otherwise have that if I were typing.

Jared’s talk centered around CruiseControl, an open-source continuous integration tool. In a matter of minutes, he installed the tool on his laptop and configured it to build and test a couple of Java classes he had written. I was familiar with CruiseControl before attending his presentation, but the demo was still impressive. I’m sure if I were a newby attending his talk I would be eager to set up my own CI server the very next day.

Jason posted a comment to my NFJS day 2 post requesting more information on Ramnivas’ demo of Selenium. Selenium is a JavaScript-based tool that can be used to generate and run cross-browser functional tests for web applications. Tests can be defined as HTML tables, Ruby scripts, and so on. Element locators are quite flexible, allowing widgets on the page to be looked up by ID, name, XPath, or directly through the DOM. Selenium also has a Firefox plugin that can be used to “record” interaction with a web app. This is a fast way to generate functional tests for an existing application.

One tip Raminvas gave was to instruct testers or other people submitting bugs to include a Selenium recording with their report. That way, you as a developer can play back the exact steps they made to discover the bug. Handling of browser-specific code doesn’t seem to be a problem with Selenium. It’s certainly the most promising open source web application testing framework to be produced in a long time. Remember that it’s only at version 0.7 so it will continue evolving and (hopefully) improving over time.

Next stop this month: RailsConf 2006! See you there.