Guide to Hiring Developers - Part II

This is the second of a three-article series that touch upon the subject of hiring developers. The first part discussed the whole process and then focused on the issue of CV screening. This part discusses the process of the 1st interview, which is the equivalent of the phone screening that several companies do.

Why *you* need to learn Ruby on Rails

Editor's Note: For those of you who may have missed it, the Pragmatic Programmers have just launched a new series called "Pragmatic Fridays" and their first book was released last week. As an even more interesting note, the first one entitled "Rapid GUI Development with QtRuby" was written by our own Caleb Tennis.

In the movie "The Shawshank Redemption", after the character Brooks Hatlan got out of prison (after being cooped up for a very long time), he opines that: "...The world went and got itself in a big damn hurry". He wasn't able to cope in the outside world after living in prison for so long. He liked his old lifestyle better.

The same thing exists in software/tech world. In order to survive, you've got to stay afloat with knowing something about the latest and greatest happenings. No doubt you know that Microsoft is releasing a new version of Windows next year called "Vista". I'm sure you're aware of lots of the latest gadgets coming out of Steve Jobs' hands.

Well, if you're a web developer, no doubt you've heard of Ruby on Rails. But, more importantly, have you tried it?

Oh No! Mojibake!

Say "moajee bockay!" (MOH-JEE-BAH-KAY) when you've got a string of characters displaying incorrectly all scrambled and corrupted. It is a great exclamation word like Eureka! and Geronimo! (but likely to never gain broad usage outside of the programmer community of course!). The Wikipedia entry for Mojibake 文字化け gives a good definition:

Mojibake is a Japanese loanword which refers to the incorrect, unreadable characters shown when a piece of computer software fails to render a text correctly according to its character encoding.

The Saga Continues: Language tidbits in Ruby Vs. PHP

I wrote a simple math quiz game in Ruby, its one of the first things I wrote as a kid when I was learning GW-Basic (sigh, those were the days!). I found a few surprising differences in Ruby that I'm used to in PHP. Here are a few tidbits I discovered.

Increment Operators
You know these, its what you have in every for statement and quite often used in other looping structures. It PHP its used like $var++ and $var-- … which as we know, is to increase the value in the variable by one or subtract by one respectively. Well to my surprise (and failed Ruby code when I tried it) they aren't in Ruby. You have to use var += 1 and var -= 1 . weird huh? I wonder if this will change in future versions of Ruby. It's not THAT big of a deal, but I was surprised. I suppose it makes it easier later when you want to increase by 2 or 3. But, having a standard way to only increase by ONE is a good idea as a check against the programmer. What if they accidentally hit the 2 or 3 instead of a 1?

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.

Sick or not?

How sick do you have to be before you stay home from work?

I've been on the verge of a coming down with a cold all weekend. As I write this it is Sunday night, I've got a bit of a sore throat, a headache, and the sweats, but I would bet I go in to work tomorrow.

Compared to my own very superficial observations of my coworkers treatment of my dilemma, I would have to say that I am more likely to take a sick day than average. Still, am I sick enough to stay home? Back in my youth, my dear mother would always take my temperature - if it wasn't over 99, and I wasn't vomiting, then I'd have to go to school. Should I use that axiom still?.

Establishing a Baseline

Whenever my company receives a new project, many times we are requested to establish a baseline set of data, which is used as a comparison to make sure something isn't amiss with our setup.

The customer can use this information to draw a conclusion that we are either matching their own data well (meaning our setup must be fairly similiar to theirs), or we are totally off and need to find the problem.

I can tell you that the latter is no fun at all. But it's even LESS fun to get three months into a project only to find that one very small installation error has completely ruined all of the generated data.

Excel from C#: An Introduction

A slight change of direction for me this week: a summary of the options available when you need to produce Microsoft Excel compatible output from C#.

I used to write Office-based VBA systems, but it’s been a few years since I really needed to work with Excel. Even so, when a customer requested some Excel export features for one of my products, I focused on compiling the appropriate data and didn’t give the actual export process a lot of thought. Obviously, I was forgetting that built-in Office functions and macros always made moving data between applications much too easy.

I realised I had to get back up to speed, and thankfully there were still plenty of options.

The Prophet's Dilemma

No real substantive post today; what started as a busy week has turned into a nightmare, complete with some very bad news about a very old friend.

Well, life goes on, and with it, work. On that front, my company is in the process of our first ever project post-mortem. One of the questions that's come up is the amount of hours spent unit testing vs. improvements to code quality. We had to fight to get hours in the schedule for UTs, and we got them. But now we're faced with the "Prophet's Dilemma": we predicted quality would suffer without unit tests, and we got unit tests, and now we can't prove that code quality would have suffered without them.