Wednesday October 20, 2004

I've used Eclipse extensively in the past but since there was kinduva a long hiatus in Java development for me, it felt both novel and familiar to install it on my powerbook for the stuff I'm currently working on. I think that liberated feeling of knowing that That Thing Works So I Can Move On Now is referred to as being "Test Infected." Which, unlike the flu, is a good kind of infection. One of the things I've been trying to be more consistent about is writing tests prior to, or if not, concurrently with, application code. I strongly recommend reading Kent Beck's Test Driven Development (who BTW appears to have a work in progress about Eclipse), TDD is a quick read but more than any particular valuable agile techniques per se it offers a good outlook on how to think about what you're doing when you sit down to write code.

Well, I was writing a few initial test cases for a class I was working on and noticed something new (to me anyway) when I clicked on an error that Eclipse flagged. The non-existence of the method in the called class was identified and Eclipse offered to stub it out on my behalf, this is a huge win as far as expressing an API in a test case and continuously filling in the functionality development "TODO" list. Everytime I want to add a new public method, I'll write a new test case and let Eclipse bootstrap the implementation.
Read it:	Now if I could get that level of simplicity and automation working with Perl, Python or PHP, I'd be jammin'! Sure, there are testing frameworks for each of these but Eclipse really streamlines that whole TDD cycle.

Forget about the flu shot hysteria, get "Test Infected"

Saturday October 16, 2004

The objections on principal may be technical

1. Intrusive inheritance hierarchy and mandatory interfaces, narrowing and recasting, gratuitous class proliferation and so forth (does the framework work for you or do you work for the framework?)
2. Container managed debugging nightmares

The philosophical objections are perhaps a general complaint about the Software Industrial Complex

1. J2EE is handed down from The Cathedral
2. JSR's and the JCP don't constitute inclusive openness, it's a "club" that you're either in or out of
3. Java is not open source

The practical problems of EJBs

1. Using the containers can be a morass of deployment descriptors and dependencies, slowing down project spikes
2. Component dependency on the container requires extra plumbing for testing, which also anti-agile. Specifically, if you want to use CruiseControl and Cactus together, get ready for a visit from an old friend named the OutOfMemory exception
.

While the practical problems of test-friendliness seem to be addressed by IoC, it sounds to me like some of the morass-of-deployment-descriptors problem are inescapable. Mapping services into POJOs declaratively (as Spring, Hibernate and Struts all require) isn't a walk in the park; until there's a linter and/or metadata/xdoclet support for easing how services can be mapped in given a specific runtime context, the pain of diddling XML config files and finding errors at runtime are going to be part of the landscape. Nonetheless, automated unit testing without cactus is a huge win in my book -- leaving CruiseControl to run unit tests and having Cactus runs reserved for manually-invoked integration tests sounds like the way to go.

I'll be steering clear of the traditional J2EE containers such as JBoss or Weblogic.