Craig Pardey

When I first started programming in object oriented languages I used inheritance to reduce code duplication. You know the deal - you have two classes that do the same sort of thing so you create an abstract superclass and extract the common code into methods in the superclass. Voilà. No more duplicated code.

But I was unwittingly creating an untestable codebase.

I have worked extensively with dependency injection containers over the last five years and have begun to rely on the clean code they facilitate. DI encourages loosely coupled classes and interface abstractions, so code re-use is typically achieved by extracting the common code into its own class and injecting that class as a collaborator.

-------------------------------------------------------
 T E S T S
-------------------------------------------------------
[INFO] --- maven-dependency-plugin:2.1:tree (default-cli) @ junit-categories ---
[INFO] com.craigpardey:junit-categories:jar:1.0-SNAPSHOT
[INFO] +- org.jmock:jmock-junit4:jar:2.6.0-RC2:test
[INFO] |  +- org.jmock:jmock:jar:2.6.0-RC2:test
[INFO] |  |  \- org.hamcrest:hamcrest-library:jar:1.3.RC2:test
[INFO] |  \- junit:junit-dep:jar:4.4:test
[INFO] \- junit:junit:jar:4.10:test
[INFO]    \- org.hamcrest:hamcrest-core:jar:1.1:test

See how jmock-junit4 depends on junit-dep:4.4, and that it appears before JUnit 4.10? That’s the cause of the error above. You can either exclude each of these conflicting dependencies or you can make sure that the versions of JUnit and/or JUnit-dep appear first in the classpath. The latter is achieved by putting them at the top of the dependency list in your pom.xml (or better yet, the parent pom.xml if you have one).
Here’s the dependency tree after moving the JUnit dependency above the jMock dependency in my pom.xml

I find it hard to remember all the .hgignore settings for a new Mercurial repository that I need, so here’s a bootstrap version

syntax: glob
.hgignore
*/target/**
*/.settings/**
*/.classpath
*/.project
*.log
*.orig

There was no stand-up this morning and it felt like my day never really started. It was my first day at my new job with CIBC and, even though I knew that the team was not agile before signing up for the gig, I had underestimated how much I depended upon our daily rituals practices at Intelliware. These practices provided a rhythm and cadence to the day that I had taken for granted.

I encountered this error while setting up a Jenkins job to automate our Maven release process.

[INFO] EXECUTING: cmd.exe /X /C "hg commit --message "[maven-release-plugin] prepare for next development iteration" c:\jenkins\jobs\Release\workspace\pom.xml"  
[DEBUG] abort: C:\Jenkins\jobs\Release\workspace\pom.xml not under root  
[ERROR] EXECUTION FAILED  
Execution of cmd : commit failed with exit code: -1.  
Working directory was:  
c:\jenkins\jobs\Release\workspace  
Your Hg installation seems to be valid and complete.  
Hg version: 2.0 (OK)  

Our Jenkins box runs on Windows. It turns out the Mercurial (HG) is case- sensitive in a way that hadn’t impacted our project in any way up until this point. Note the subtle differences in the first two log statements:

I encountered some code recently where a GUI client was listening for Object updates from a multi-threaded server, and it was using the version number on the Object to determine whether the incoming Object was the latest version. The server incremented the version of the Object by inserting a new row into a table in the database and using the primary key as the version number.

Now consider the case multi-threaded case where two threads, T1 and T2, are making updates to the Object.

If there was one piece of advice I could give to someone considering a career in software development it would be: Learn to f$%@cking type! Knowing how to touch type is the single most valuable skill that a developer can possess.

Typing allows you to concentrate on what you’re coding rather than how to get the characters on the screen. In other words, you’re able to think about the code rather than thinking about where to find the letters on the keyboard. Jeff Atwood and Steve Yegge both make the same point.

I recently embarked upon a performance investigation to figure out why a particular operation was slow. My theory was that it was the serialization/deserialization cost with a set of large objects; my colleague’s theory was the iteration over the set. We were both wrong.

The investigation became intriguing when we started measuring the elapsed time at various points in the application and noticed that the bulk of the time was being spent in a seemingly innocuous call to construct a HashSet from an existing Collection.

My ex-project and I had been together for ten months. We had our fair share ups and downs, particularly in the early days, but over the last few months we had settled into a nice routine. It wasn’t particularly exciting any more but at least it was predictable.

And then yesterday I was asked to lead a troubled project. It’s only six months old and already has quite a few warts, and it limped across the line into UAT last week. My first instinct was to cower in the corner in the fetal position but I resisted that temptation and quietly accepted the role.

Sometimes your code needs to call a static method in a 3rd party library and unit testing  suddenly becomes difficult, particularly when that static method requires context in order to work.

Enter the insulating class (also known as a Facade).

1. Create a new interface that declares a method with the same signature as the static method you want to delegate to
2. Create a new Facade class that implements the interface
3. Replace the calls to the static method with calls to your new Facade class

Let’s assume that the method you need to call looks like this