Matthew Bass

“Affliction comes to us, not to make us sad but sober; not to make us sorry but wise.” — H.G. Wells

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.

“Hammond is insisting SG-1 needs a socio-political nerd to offset our overwhelming coolness.” — Jack O’Neill, Stargate SG-1

“I love this place at night. The stars… there’s no right or wrong in them. They’re just there.” — Sgt. Elias, Platoon

One of the Rails apps I’ve been working on formats times as HH:MM in the view. No seconds are displayed. This is a pretty common way to format things. When doing timestamp comparisons in SQL, however, the seconds are taken into account. This is bad since it can cause discrepancies in the view.

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.

“Only mediocrity can be trusted to be always at its best.” — Max Beerbohm

This year’s Ruby Hoedown is happening in Nashville again on September 3rd and 4th. I’m really looking forward to attending. The quality of the talks combined with the smaller attendance size makes for some great hallway conversations. Last year’s Hoedown was at the Opryland hotel which was a stellar venue. I have seriously never seen such a large hotel. Unfortunately, it can’t be used this year due to the recent flooding. But the new venue, the Hilton Downtown, looks really nice as well. As before, the Hoedown is completely free (as in beer) and talk proposals are currently being accepted. Are you going?

I’m curious about something. If you’re an independent contractor, consultant or freelancer, are most of your projects one-time gigs or do they more frequently involve long term maintenance? There is a lot of different thinking out there about how to handle ongoing work: batch it up and get it done all at once (and pay for it in one chunk too) or spreading it out over a longer period of time (the pain isn’t as severe, but lasts longer).

Most of my projects start as one-time gigs and then evolve into ongoing maintenance work (assuming the client is pleased with what has been produced, which they generally are). I can think of only two instances where a one-time gig was just that… one-time… and didn’t involve ongoing maintenance. What has your experience been?

“Sometimes I wonder whether the world is being run by smart people who are putting us on, or by imbeciles who really mean it.” — Mark Twain

July 29th will mark the fifth anniversary of this blog. I realized today that I have never properly thanked you, my readers, for continuing to support this endeavor. There are so many other things you could be perusing, but you choose to patronize my humble programming blog. For that, I am grateful. Thanks for reading!