Category: Programming

  • Amending git commits

    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.

  • Drop seconds when querying MySQL timestamps

    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.

  • Registration for BarCampRDU 2007 is open

    Registration for this year’s BarCampRDU is now open. This is an event I unfortunately had to miss last year due to a prior commitment. I’m really looking forward to attending this year. It’s shaping up to be a fantastic experience.

  • Deploying PHP apps with Capistrano

    Capistrano is a wonderful tool. I have this really old PHP-based web site, TolkienMovies.com, that I needed to make a change to earlier today. (The spam bots had finally found my news submission form.) I decided this was as good a time as any to automate deployment of the app. This article was very helpful. Staring at a task like this can be daunting, but once I actually got in there and started hacking it wasn’t half as bad as I thought it would be. And now I have a warm, fuzzy feeling knowing that deployment of this stinkin’ PHP app is only one “cap deploy” command away. Hallelujah.

  • First Agile RTP meeting tonight

    This is just a reminder from your friendly neighborhood agilist that the new Agile RTP user group has its first meeting in Cary tonight. Read more about it on Jared’s blog. This sounds like a great opportunity to meet other agile-minded people in the area and listen to an interesting talk. Oh, and let’s not forget the bragging rights secured by those who participate in the first meeting of a new user group.

  • Agile RTP: A new user group in Raleigh

    Agile RTP is a new user group started in the Raleigh area by Jared Richardson. The first meeting will be on March 22nd where we’ll be video conferencing with the agile group in Charlotte to hear Dr. Laurie Williams speak about test-driven development. I was actually considering driving to Charlotte for this speech, so when Jared told me we’d be able to enjoy it right here in Raleigh I was totally psyched. Get more details on the event and don’t forget to mark your calendar.

  • Mind blowing Ruby

    I’ve been writing Ruby code for over four years now. I’ve been getting paid to do so for about two years. Prior to that, the bacon I brought home came mainly through the careful crafting of lines of Java, PHP, and C# code. Matz spoiled the party for me in the mid-90s, however, by releasing such a wonderfully beautiful language that it made Java tedious and uninteresting in comparison.

    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…

    (more…)

  • The importance of code reviews

    Have you ever done a code review? Most developers haven’t. It doesn’t seem to be a regular practice in many parts of the software industry, yet by ignoring the importance of code reviews we miss out on the benefits that they can provide.

    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!

  • NFJS 2006 wrap-up

    It was with mixed sadness and relief that NFJS 2006 came to a close last Sunday evening. Two and a half solid days of listening to some of the best technical speakers in the country can be draining, but the knowledge and enthusiasm one picks up is priceless.

    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.

  • NFJS Expert Panel podcast

    I noticed today that the NFJS web site now has a podcast. One of the audio clips available is the entire Expert Panel session from the New England NFJS in March. I’ve started listening and it’s quite good. In fact, it’s making me hungry for more great discussion at the RTP NFJS this weekend. Oops, excuse me. I need to wipe that drool off my keyboard.