Keith Casey's blog

[Admin] Holiday

Due to the holiday weekend here in the US, we're taking the afternoon off. Maybe you should do the same.

We'll be back tomorrow with the latest and greatest opinions.

Interview with QtRuby Author Caleb Tennis

In case any of our readers are interested in hearing a bit about the man himself, an interview with our very own Caleb Tennis is available on the website of Andy Hunt of the Pragmatic Programmers'.

Check it out and enjoy.

Which books do you keep on hand?

There are a handful of books that I make a point of keeping close to my desk as general reference guides. I thought I'd take some time to share my list and see if there are others out there that I'm missing. Suggestions for specific languages, concepts, or principles are welcome.

Paul Graham's Startup School

So who hasn't heard of Paul Graham?

For those you who don't know of him, he's a bit of a uber-geek in terms of a geek who made it big during the dot-com times, managed to walk away with a bit of cash, and now has a bit of a philanthropic goal of assisting other startups to give it a try. Whenever he writes, it sends ripples through the online world and generally gets on slashdot.

As the owner of a startup, I applied to his upcoming Startup School as a bit of a lark never thinking I would get an invite. I hit "Submit" and then promptly forgot about it and made plans to go to my other conference called Power your Business with PHP which starts three days later.

So I got an invite last night.... whoa.

Now I need to figure out how to close on a new place just outside Washington, DC on the 14th, make it to Boston on the 15th, and then make it to San Francisco on the 17th.... hmmm.

Edit: I just realized that I forgot to point out that I initially came across the Startup School info over at Dane Carlson's Business Opportunities Weblog. - Thanks Dane!

Book Review: Java Extreme Programming Cookbook

Since I've been talking about Unit Testing quite a bit recently, I thought I'd offer up a review on a book I read a while back. I thought it was a solid roundup of both the principles and the tools used to support Extreme Programming in Java. Overall, I'd give it a 9/10 and I deduct a point solely due to the fact that since it details the usage of numerous Open Source projects, it's halflife could be very short. Regardless, this is more than enough to get you started and will teach you the basics to be able to do even more interesting things.

Just to make this clear right off the bat, if you're not working in Java, only pages 11-27 are going to be of any use. These pages go over the different pillars that make up Extreme Programming (XP). Whether you're using XP or not, you can pick and choose the pillars you need and customize them to your project pretty easily. The principles are: Pair Coding, Unit Testing, Refactoring, Iterative/Minimal Upfront Design, and Regular Builds. I have yet to see a project that cannot benefit from having Unit Testing and Regular Builds in place. These two items serve as a great safety net for current and future development efforts by detecting errors soon after insertion.

I love Unit Testing

Alright, so I admit that I'm completely biased. I can't be impartial about it and I don't think you should be either. Once you begin writing Unit Tests - or better yet Test Driven Development - you don't want to go back. Once you have a series of Unit Tests for a particular class, method, etc, it's painful and scary to modify code lacking these tests...

But I also see the value in Unit Testing in a few other areas.

Off By 1 + Off By 1 = Off By 2

A while back, I was working on a particular project where the load was a magnitude higher than what we expected. It seemed to always be running and only rarely catch up with the backlog. The load on the system shot from nothing to 99% for long durations.

We hoped something was wrong, but the data was coming into the system just as expected. What was our problem? It was an Off By Two Error. Yes, normally they're called "Off By One Errors," but there's a bit more to it than that...

Enemy Unit Testing

I'm a big advocate of Agile Methods and principles. I believe quite simply that an evolutionary design, refactoring, user stories, and especially Unit Testing. So when I came across the concept of Enemy Unit Tests, I was dumbstruck by the logic of it.

Think about it. When we right code, we write Unit Tests (hopefully!) and run them as often as necessary. You may not run all of them all the time, but you run the important ones as often as possible.

Now what about all those libraries you're using? When was the last time you tested those?

CodeSnipers Generation-2 [Admin]

Good morning,

CodeSnipers has been growing like crazy. We're steadily getting more and more hits and I consider the launch a success. We have made it into the top 100k blogs on Technorati, so that means someone finds what we're saying interesting... even if they don't agree. As a result, I'm looking to expand the site a bit in selected areas.

Officially, no additional CodeSnipers will be added until the end of the month. But, in order to find the right people early in this process, I am extending an open invitation to be guest contributors. The same guidelines will apply (listed below) and we may not publish your piece, but I will make sure you get feedback. If your piece gets published, your personal blog/website will be mentioned along with a short (one paragraph) profile which you can submit.

We're 90% Done!

We're 90% complete with X and we'll be done in no time!

We all know it never happens that way, yet we hear it regularly, most of us have said it, and some of us have said it more than once.

Why does this sort of thing prevade software development?