About a week ago I signed up with our local Java Users Group to do a talk on Fitnesse, since they hadn’t been able to line up any speakers. The talk went fairly well and there were quite a few questions which is always a good sign. It did force me to bone up on my Fitnesse knowledge.
The community seems to be getting more sophisticated at least locally. In the open discussion things like AspectJ and profiling code came up. One nice thing was that many of the audience actually had some unit testing exposure. Many of them weren’t doing hardcore TDD, but trying to move in that direction. All told it’s a nice sign that unit testing adoption is picking up in the general java community.
OK, I admit it I’m a simpleton when it comes to scoping things in Java. Out of all four possible keywords for scoping access I manage to use two:
I realize there’s probably a good reason where I’d want to use protected or default scope, but I just haven’t run across one. I find sticking to private and public simplifies my designs. It is very clear whether the variable or method was supposed to be encapsulated by the class. Since I don’t do APIs if I need access then it generally might as well be public.
When I do run across a protected or default in example code I often wonder if there was an explicit reason for it. It turns out that IBM’s RAD 6.0 writes all its JSF backing bean methods as protected scope, though I still don’t get why.
Of course I may also just be missing some blindingly obvious OO concept that makes protected really cool.
My personal recharging battery techniques, for those times when you just can’t stomach another article on the newest web framework.
- Disconnect where reasonable. Sometimes on vacation this is pretty easy, but since you’re a bit burned out and still probably at work, concentrate on some of the non-technical aspects of your job that don’t get looked at enough.
- Take a temporary ban on reading technical books, listening to podcasts, etc.
- Play mindless games. I prefer to play mindless card games like Munchkin or Nuclear War with a group of friends, but since I don’t have that many old geek friends who still play these games nearby, a mindless video game will often suffice. Just not a mindless massive multi-player online game, because I have a dangerous propensity to get sucked into those.
- Hang out more with the fam.
- Remind yourself that some personal project can wait a week while you have some downtime.
- Read a fiction book. I rarely read anything but technical books, given how much I try to keep up on, but sometimes it’s good to take a break and read some fiction.
I got a pleasant surprise recently when I checked out the Fitnesse.org site and found a fleshed out Hunt The Wumpus example. Up until now the basic examples on the Fitnesse site were really too simple. The examples in the FIT book are more elaborate, but I found the book itself to be one of those I put down because I just couldn’t get into the text.
Hunt the Wumpus brings back memories as a kid typing the code in from one of those big books of BASIC games.
I’ve held off using a tool for our code reviews because I didn’t see one that was available that supported a fairly lightweight process. One exception to this was the Eclipse Jupiter code review plugin which we can now use because almost all of our developers have migrated to RAD. (Also suggested by Tim Shadel over at Zdot.)
We tried out Jupiter on our last code review. It installs like any other Eclipse based plug-in. We reviewed about 12 classes from one developer and there were a total of two reviewers. (This was a few too many classes, but it was an experiment).
It uses a XML file based approach to contain all the review information. You simply pick the classes you want to review, add the names of the reviewers and check in the XML file into version control. Simple enough, but you’ll still have to inform everyone about the review via email or in person.
Then you right click on the code and add issues. When you meet up to go through the issues you can simply drive the review from someone’s laptop with an overhead projector. As it turned out I was the only one who had time to actually review the code, so it was just my issues to review. Actually neither of them had gone as far as installing the Jupiter plugin.
It was really nice to have some organization around the review. When you select an issue it can jump right to the code and you have the comment in front of you to jog your memory. If it turns out to be something that needs to be changed, you just select ‘Valid’ from the pull down menu and flag the issue. Then you jump to the next issue.
At the end of the process the developer can just open up all the valid changes and work through them offline.
The best part of the tool was using it for the actual review since it was much easier to focus and drive through the agenda in a single hour. The weak point was as a plugin and file based system it didn’t offer a lot of automation support. For now the vote among the developers is to give Crucible a chance when it shows up soon as a beta.