EJBs considered harmful, once more with feeling

Though not his point Piotr Nowicki in his post, EJB Inheritance is Different From Java Inheritance, reminds me why EJBs should be considered harmful.

More Bob: Sat ci sat bene

More of the indisputable Uncle Bob, The Frenzied Panic of Rushing:

James and I had just ordered Gin and Tonics from the airport bar and returned to the waiting area, when we saw a group of the TWers frantically working on their laptops. We asked someone what was going on, and were told that they were racing to see who could implement Langton's Ant quickest.

James and I looked at each other, nodded, opened a laptop, and quietly began to pair-program. We followed our disciplines, wrote test-first, kept the code clean, got it working after a few minutes, and then closed the laptop. We looked up, and the young twenty-thirty-something TWers were still expending copious energies in a fit of frantic coding. The frenzied intensity of their effort, driven by the panic of potential loss, was evident in their gestures and expressions. We, the two fifty-something programmers, smiled, clinked our Gin and Tonics, and sat back to enjoy the show being put on by all those young turks who never even guessed that they had been calmly bested by two of their seniors who had the experience and wisdom to know that the only way to go fast is to go well.

I am happy I joined ThoughtWorks after the story took place lest I have been one of the frantic foragers.

The JUnit forest

Edmund Kirwan damns the ubiquitous JUnit in JUnit's evolving structure. What's the problem? — galloping interdependencies. As a bonus, a spiffy graphical timeline of JUnit's structure.

Skipping TDD

Uncle Bob, as usual, is a pleasure to read, to wit, The Pragmatics of TDD. Highlights:

• I don't write tests for getters and setters. Doing so is usually foolish. Those getters and setters will be indirectly tested by the tests of the other methods; so there's no point in testing them directly.
• I don't write tests for member variables. They too will be tested indirectly.
• I don't write tests for one line functions or functions that are obviously trivial. Again, they'll be tested indirectly.
• I don't write tests for GUIs. GUIs require fiddling. You have to nudge them into place by changing a font size here, an RGB value there, an XY position here, a field width there. Doing that test-first is silly and wasteful.
• In general I don't write tests for any code that I have to "fiddle" into place by trial and error. But I separate that "fiddling" code from code that I am surer of and can write tests for.
• A few months ago I wrote an entire 100 line program without any tests. (GASP!)
• I usually don't write tests for frameworks, databases, web-servers, or other third-party software that is supposed to work. I mock these things out, and test my code, not theirs.

Plugging a leaky ship

Plumbr's Nikita Salnikov-Tarnovski writes Hunting down memory leaks: a case study. Quoting:

A week ago I was asked to fix a problematic webapp suffering from memory leaks. How hard can it be, I thought – considering that I have both seen and fixed hundreds of leaks over the past two years or so.

But this one proved to be a challenge. 12 hours later I had discovered no less than five leaks in the application and had managed to fix four of them. I figured it would be an experience worth sharing. For the impatient ones – all in all I found leaks from

• MySQL drivers launching background threads
• java.sql.DriverManager not unloaded on redeploys
• BoneCP loading resources from the wrong classloaders
• Datasource registered into a JNDI tree blocking unloading
• Connection pool using finalizers tied to Google’s implementation of reference queue running in a separate thread

Of course, there's more.