But first, let’s talk about defensive coding and how we do it. For example:

/**
 * frobs the bar and baz.
 * @param bar the bar to frob; may not be null
 * @param baz the baz to from; must be positive
 */
public String frob(String bar, int baz) {
  if (bar.length() > baz) {
    return bar.substring(baz);
  }
  else {
    return bar;
  }
}

If the contract is violated by the caller, we will get a NullPointerException or some other StringIndexOutOfBoundsException. Not too helpful. Instead, we use an internal validator helper class to provide useful messages. This is crucial for properly understanding bugs that occur in production; there’s nothing worse than coming into work to find a NullPointerException in your inbox and no clue what went wrong.

/**
 * frobs the bar and baz.
 * @param bar the bar to frob; may not be null
 * @param baz the baz to from; must be positive
 */
public String frob(String bar, int baz) {
  Validate.notNull(bar,"bar must not be null to frob");
  Validate.isTrue(baz > 0,"baz must be positive");
  if (bar.length() > baz) {
    return bar.substring(baz);
  }
  else {
    return bar;
  }
}

Validate.* methods essentially throw IllegalArgumentException if what they are checking for fails.
We use this pattern extensively, even in constructors of simple data-structure style objects. This (plus keeping this things immutable) allows users of these objects to safely rely upon the get methods behaving properly. I had need of a class to hold both a Person (representing a website user) and a Customer (representing a utility-company customer). This class (called, naturally, PersonAndCustomer), takes both objects in its constructor and requires that they are both non-null. As a further sanity check, I wanted to make sure that the Person’s customerId matched the id of the Customer that was being passed in (i.e. that they represented the same actual human in the real world):

public PersonAndCustomer(Person p, Customer c) {
  Validate.notNull(p,"Person may not be null");
  Validate.notNull(c,"Customer may not be null");
  Validate.isTrue(p.getCustomerId() == c.getId(),
    "Person %d's customer id %d didn't match passed-in customer's id %d",
    p.getId(),
    p.getCustomerId(),
    c.getId());
  ...
}

Looks pretty inocuous, right? Well, because these objects are Hibernate-managed, all of our ids are Long and not long. So, my isTrue validation is really checking that the person’s customerId object is the same object as the customer’s id object. What’s worse, in several months of development and production deployment, these two objects happened to be the same.

Until this week; we were testing our application for a new client and I got the error posted above (“Person 1001’s customer id 109032 didn’t match the passed-in customer’s id of 109032″). It seems that much like how the JVM will re-use string objects, it also will sometimes re-use boxed objects as well. But not always. The fix for this is obvious, but I wanted to make sure I could actually recreate this situation. So, I created a test that gave both the Person and Customer the same value for the customer id, but as different objects. and verified that the class could still be constructed. Sure enough, the test failed. The fix:

public PersonAndCustomer(Person p, Customer c) {
  Validate.notNull(p,"Person may not be null");
  Validate.notNull(c,"Customer may not be null");
  Validate.isTrue(p.getCustomerId().equals(c.getId()),
    "Person %d's customer id %d didn't match passed-in customer's id %d",
    p.getId(),
    p.getCustomerId(),
    c.getId());
  ...
}

What’s interesting is that if one end of the == is a primitive, the JVM will unbox the other one and the test succeeds:

Long l1 = new Long(45L);
Long l2 = new Long(45L);

System.out.println(l1 == l2);      // false
System.out.println(l1.equals(l2)); // true
System.out.println(l1 == 45L);     // true!

The moral of the story is to always know what you are comparing. Might even be best to always use .equals() unless the compiler complains.

To the disgust of myself and my wife, I collected shavings for approximately 4 months in a plastic cream cheese jar labeled “Not Cream Cheese.”

This last weekend, I took a trip to AC Moore Arts & Crafts and bought some clay.  I fashioned a mold into that clay of a mustache that would dominate all other mustaches.

Into that mold, I poured elmer’s glue, hair shavings, 14 gauge electrical copper wiring, more hair, more glue, more hair.

This morning, the plan was to simply glue the assembled mustache on to my real mustache.  Unfortunately, the plan involved entirely too much super glue and the assembled mustache pieces proved to be entirely too heavy.  My previous experience with krazy-glue-on-skin is probably like most people’s…stick your thumb and index finger together.  Thanks to callouses, a lack of hair on your fingertips and the relative strength of your digits, it’s not that big of a deal.  I also don’t remember the glue burning like lava on contact.

A split second before squirting a liberal does of krazy glue on the mustache I wondered: “is this really a good idea?”  But not wanting to pysch myself out, I quickly brought the assembled mustache up to my lip and pressed down hard.

The first thing I remember thinking is that this was going to look really good.  Like, maybe champion-quality entry.

That thought was quickly replaced with a rising alarm about the rapidly increasing burning sensation I was experiencing between the mustache and my lip.  That alarm was then replaced with the growing realization that I was inhaling quite a bit of vapor and that my throat was starting to burn.

Not-quite-panicked, but not totally calm either, I gently tried to remove the mustache and got as far as pulling my lip about an inch off my face before giving up.  Over the next 10 minutes I was able to saw, snip and shave the ’stache down with a combination of electric shaver, electrical pliers, scissors and razor blade.  By that time, of course, the fumes had dissipated and the burning was just a low heat and my grand mustache plans were wrecked.

The redness of my eyes is due to the fumes and pain.

There’s always 2011…

Nacho Cheese Doritos.

Honorable Mentions: Fritos and Cool Ranch Doritos.

Still, the “everyone else” paint brush was wearing thin.  In addition to the “web team”, we had “the scale team” (a.k.a “Ops R&D”) and “the AMI team” and “the core team” and “the report team”. . .but most of those were “teams” averaged size 1 and their membership varied from iteration-to-iteration.

Sick of referring to ourselves with a hand-wave and a “you-know. . .the non-web-team,” I plugged our names in to an acronym engine and we found the perfect name for ourselves:

The Cheated Frogs of Vim

While I put in my fair share of vi time in previous development gigs, I’m a little too fond of modern debuggers to go whole-hog with Vim as my “IDE.”  Dave, on the other hand, is pretty hard-core with his Vim skills, so our new team name may have some sticking power.

Our wizard graphics guy even cooked up a logo for us:

New dev team logo!