It looks like the book, Fit for Developing Software: Framework for Integrated Tests is out. Since we’re just about to embark on a project to make our largest application more testable and especially more testable for QA I hope this book has some good examples. I’ve spent some time with Fitnesse and been able to get a basic understanding at this point, but I feel like I need to see some more real world examples to really get a handle on how you best implement it. Should be interesting to see how our QA department, which is largely used to manual testing, adjusts to it.

I came across a post on a Ruby feature that Todd Huss would like to see in Java:

Native getter/setter support: declaring a list of variables as attr_reader or attr_writer allows getter/setter functionality of a variable without writing/maintaining any redundant getter/setter code, yet if necessary, you can override the default getter/setter behaviour without affecting the API. In Java it drives me crazy that we waste time and clutter our classes unnecessarily with hundreds of lines of getter/setter methods that all do the same thing. Java really needs a construct for default getter/setter behaviour on selected variables that can be overriden when necessary.

I agree that all the clutter and extra lines from getter/setter methods are really annoying within Java code. My preference though is to simply drop the getter/setter methods altogether and make the variable public. Better yet keep it private and don’t expose it to anything, it should be data only the class makes use of to implement behavior.

Allen Holub has an article entitled Why Getters and Setters Are Evil that argues that the getter/setter idiom in java is really not a good idea. If you haven’t read it basically it argues that the getter/setter methods are procedural hangovers that should largely be abandoned.

I remember back when I taught an Intro to Java course or two that there was a wonderful discussion of encapsulation and that one of the examples were the getter/setter methods that encapsulated the private variables. Everytime I covered this topic I felt it was a really weak argument. If you have a private instance variable, but then you just implement default public getter/setter methods, esentially you’re making the variable public again. If that’s the case why not just use the dot syntax and make the instance variable public.

Holub talks about this in his article, but the obvious thing is that the getter/setter paradigm has become standard in Java both by procedural programmers who were used to objects that look like just collections of data and by the default JavaBean implementation. Indeed I occasionally try to leave off getter/setter methods only to find in many frameworks like Struts, Spring, and others that they assume they can use reflection and the get/set methods to implement functionality.

I sat through a session as SD 2005 this year and found Allen’s presentation pretty refreshing since he was taking on established practices in Java. What was amazing was the amount of flak he took for bringing this up from much of the audience.

Anyway I still end up implementing a lot of get/set methods since a lot of frameworks require it, even if it isn’t very object oriented.

Getting email from cruisecontrol turned out to be a little more work than planned. Turns out sendmail has been eliminated in favor of Postfix on 10.4 and maybe 10.3, a mail server I know nothing about. After a short run through this article I was up and running.

For now I’m just running it in the background just running it in the background with root seems reasonable enough:

sudo /Applications/cruisecontrol-2.2.1/main/bin/cruisecontrol.sh &

That way it runs most of the time and I can kill it if I need do by issuing a

sudo kill #

command. Since I’m really just running it so I can help my development team understand it instead of relying on a single expert it should work well enough.

Came across an interesting idea in a directory structure for the examples in a Spring tutorial at Zabada Technologies. I’ve never seen it before, but it does solve a common problem I’ve had with mixing jars that were only needed for testing or things like the servlet-api.jar which would already be in any container.

The solution is simple. The main top level

directory just contains all the jars that are actually needed to run the app. Another top level

is just used for dependent jars like the servlet-api.jar and the junit.jar that would only be used for building.

Since I still haven’t looked into AppFuse and it’s directory structure I don’t know whether I’ll adopt this as a default for the team yet, but it is a nice simple solution. I just have to run it by our development practices committee, and convince them of the usefulness.

After another frustrating session with the example code in Spring: A Developer’s Notebook was the last straw. As a manager I don’t really code for a living anymore. On good days I get to do some coding at work, but often the day can be eaten up with meetings and taking care of problems so my programmers can work relatively interruption free.

My goal is to always stay technical, but what that means is spending a lot of my own time after hours coding, reviewing tools and frameworks, and keeping up with things like this blog. Add in that I have a family with two young daughters and I don’t have time for much else. So when some example code goes wrong it’s doubly frustrating.

So I’m off to try some online Spring tutorials at Zabada Technology.