I’ve been doing my best to keep up with the latest tooling trends for Java development. I think for the vast majority of people, there is a great one-stop resource out there: Java Power Tools. But any good “one-stop” book is not going to try to cover everything, and that’s what I’m going to try to do over the next few posts. My goal is to scour my del.icio.us and some of the tidbits that I have laying around to highlight some of the more obscure or newer tools that didn’t make it into JPT, and in addition, some tools that should just be on your radar as a developer in general.  I’ll be bundling them into groups and shooting to release them in a few parts over the coming month. Stay tuned!

You’re relegated to using JPA/Hibernate because of an outstanding bug BEA and Sun seem to be both pointing fingers at each other over, but it’s not a big deal.  At least for now, all of the persistence in this app is going to be offloaded to services.

I’ll work on writing this up more formally, but here was a running list of issues I had to deal with.  If you need more information, let me know.  I apologize that this is kind of rough, but it’s better than nothing.

1. Follow steps outlined in reference guide. (http://docs.jboss.com/seam/2.0.2.SP1/reference/en-US/html_single/#weblogic)
2. Change the build.xml’s jboss.home’s to bea.home’s, and redefine them like so:

   <property name="deploy.dir" value="${bea.domain.dir}/autodeploy" />
   <property name="jboss.deploy.dir" value="${jboss.home}/server/default/deploy" />

3. Remove the library-ref from weblogic.xml (that you put in following the ref guide).
4. Remove the Namespace, Schema, and Version definitions for the web-app tag in web.xml - there’s a problem trying to add version 2.5… (https://jira.jboss.org/jira/browse/JBSEAM-2247)
5. Remove JSF/MyFaces deployments from WL domain if there are any (JSF 1.1 libraries conflicting with 1.2)
6. Add jsf-api.jar, jsf-impl.jar, commons-collections.jar, persistence-api.jar, el-api.jar, el-ri.jar (needed to pull out of seam fisheye) to deployed-jars.list.  You should be seeing Seam trying to start up at this point, IOW, you’re in “whack-a-jar” mode.

One other funky thing — and I’m not sure what error exactly was causing this (probably related to the interceptors and JSF problems causing the deployment to suspend) but WL was causing some locks to occur that I had to clear out of my domain/server/tmp/* and basically “clean” everything out.  It was quite annoying, but things seem to be better now.

While I was reading “The Reuse Trap In Software Design” I found myself thinking,”Me too! Me too!” like a giddy kid on the playground that’s found a new pal with a mutual interest in “pet snakes and/or tarantulas.”  As with many of the problems Basil writes about in his blog, I experienced the same problem, investigated it and found the same root causes, and came to many of the same conclusions as those outlined.  He describes the “reuse trap” as:

…[A] term I coined to describe the situation when one becomes stuck trying to design new functionality while simultaneously attempting to reuse existing code that needs some modifications.

He then goes on to describe why it’s a tough problem for n00bs and outlines a strategy he uses to get out of the trap–one that’s best described as a two-step process: copy-paste to reuse/refactoring to remove duplication.  I encourage you to read his article if you’re not familiar with the terms, or how this strategy can solve the problem described above.

My preferred technique for mitigating the problems involved isn’t copy-paste reuse/refactoring; it’s stubbing the calls to the code-to-be-reused (C2BR) that needs modification.  If I can fake out the behavior I need, it lets me focus on the nature of the dependency that exists between the two objects/components.  When I go to modify the C2BR, my inputs and outputs (or other consequences that occur as a result of a call to the C2BR) translate directly into a test that I can use to drive the changes I make to that code.  It also ensures that the coupling that exists between the objects is loose and legit.

The only thing to watch out for is that care must be taken to then remove the (small) duplication of the stubbed out inputs/outputs and actually wire the two pieces together when finished with the reused code.  I usually do that by throwing a TODO:WIRE marker in when I stub something.

I’ve found this is the approach I take more often, though I do take the copy-paste reuse/refactoring route from time to time.  This stub/rewire approach is a bit more advanced, but it’s how I envisioned solving the “reuse trap” when, as Basil puts it, “I became aware of it” and all that it entailed.

Do you ever come across this problem?  How do you get out of this “trap” or avoid being caught up in it in the first place?

So far, it seems like a good choice.  As mentioned in Tim’s post, I notice my typing speed has dramatically increased immediately, when compared to the built in keyboard, or the stock Dell keyboards I’ve been typing on when not at my Mac recently.

I didn’t think the num pad warranted the extra space it’ll take up when I carry it around with me.  The super big command key doesn’t concern me quite as much, because I’ve gotten used to slipping my left thumb down to hit it from hovering over the spacebar, and it’s easier/more natural to do that on this keyboard compared to the one built into the MBP.

And this all goes without saying that the wireless features are a big plus.  Whenever you sit down to do something, having to plug in an extra wire is nothing short of a pain in the ass (not to mention taking up valuable port space on my precious laptop).

So far I’m pretty happy with the purchase.  If my opinion changes, I’ll let you know, but the spot judgement is that it’s exactly what I was expecting.

If you didn’t know about ALA, well now you know.  If you do know about them, give something back by participating in their survey.

In our vast build-tool landscape, there tend to be some zealous cults out there, entrenched deeply in their own camps and unwilling to venture out to explore what the rest of the landscape has to offer.   Thus, there have been some religious-like differences of opinion about which build tools are better and why.  Sadly you run across these types of biases all too often, which only pollutes the landscape and makes it more difficult to wrap your head the most basic questions underlying all tools:

• What does it accomplish?
• When is it (or isn’t it) right for the job?
• How do I use it effectively and efficiently?

With a pragmatic view, we can try to cut through a lot of the BS and figure out if a tool is worth its weight in:

1. dependencies/design complexity.
2. ease of use/interface complexity.
3. architectural decisions/compromises that it brings to the table.

Does the tool get us to the goal of a single button build/deploy?  If the answer is yes, I’ll welcome it with open arms.  Does it add me a form of feedback or some kind of statistic that could be a kind of gauge on a dashboard?  Then I may be interested in it, but it’s not nearly as vital.

Here’s an outline of what I typically look to include in a project’s build before I am satisfied:

• Compile - Obviously your build script would be for naught if you didn’t include this piece.  There’s also something to be said about some dynamic/interpreted languages (that run on the JVM) taking the hit on this step and producing compiled versions.  The argument is akin to compiling your JSPs back in the day.
• Unit test suite - Another one of those no-brainers!  You’ll obviously want to integrate your ability to run a single test or test suite from a build tool quickly and easily.
• Test reports - Test reports are an important way of visualizing the health of your project and are usually the first place you’ll go when you see something wrong.  A must have.
• Transitive dependency management - This is one of those sticky subjects that people like to argue about religiously.  Really the important thing to note here is that a crucial part of keeping your build clean and manageable is figuring out how to represent and resolve transitive dependencies, or second-level dependencies.  If your code directly depends on a library, odds are that library has its own run-time dependencies that need to be satisified in order for it to work properly.  Since managing the different versions of many different libraries can become tough when you start to look at different “stacks” of software, many people advocate having a tool help you resolve these dependencies so it’s not as daunting a task to get the entire stack to work again when you need to upgrade a single library.  Maven and Ivy solve this problem by introducing repositories that will house and dynamically resolve these versioning issues, in much the same manner as yum or apt-get does in the Linux world.  A lot of newbs will make the mistake of thinking this type of functionality will let them turn off their brain when it comes to think about their project’s dependencies.  They will be sorely mistaken!  The point of these to make resolving conflicts in transitive dependencies easier, they do not replace your brain, nor your obligation to know the dependencies in your project and how they fit together!
• Utility ant tasks - the daunting part of learning how to write good builds has a bit to do with how much you know about the ant task landscape.  Nearly all libraries have tools that plug into ant, but which ones do you really need to know about?  I’ve found a few are quite powerful, particularly replace, uptodate, cvstagdiff (and corresponding svn’s), xmltask and dbdeploy.  I think these tools should be looked at when you are trying to figure out how to accomplish something specific, and for that reason, they’re a bit more like “bells and whistles” than anything else.  The same goes for the next category, which arguably doesn’t even need to live in your build (but if you’re a team player, it’s a definite nice to have):
• Static analysis - There have been a barage of slick static-analysis tools that have entered the Java landscape recently.  A few are FindBugs, PMD, CheckStyle.  While most of these tools have plugins that integrate nicely into an IDE, it’s also helpful to have them plugged into your build, too.  Just to make sure everyone is following the rules.  A few others I’ve seen that focus on cyclomatic complexity, cohesion/coupling are Metrics and JDepend.

What build tools fit into your pimped out script?

A nice byproduct of the genius of Seam's design is that many common problems can be solved by using EL as veritable swiss-army knife. We'll look at this through a logging example specifically, though it's just one of many different innovative ways of solving problems using Java5 features and EL as a general approach.

WTF is a code guard?

What goes without saying in most of the discussions regarding logging is that excessive logging can be the largest and most common performance bottleneck in code that meets its functional requirements. Thus, logging APIs introduce the idea of log levels, to ease the burden of excessive logging. Generally, log levels are a configuration setting on a per-environment basis. Development environments will typically log most dependent code at the info level, and cut that up to the debug level for custom code or when things go awry with a piece of dependent code. Testing environments typically log at info while production will often just log at the warn level.

While this is all well and good, we find that for a lot of the logging we do, we typically run across an ugly little flaw in this approach that's produced an equally ugly hack as a work-around. Enter the code guard. From the log4j docs:

Code guards are typically used to guard code that only needs to execute in support of logging, that otherwise introduces undesirable runtime overhead in the general case (logging disabled). Examples are multiple parameters, or expressions (e.g. string + " more") for parameters. Use the guard methods of the form log.is<Priority>() to verify that logging should be performed, before incurring the overhead of the logging method call. Yes, the logging methods will perform the same check, but only after resolving parameters.

What's all this business about resolving parameters? Let's look at an example:

So, we need this cluttered if/else around only to ensure that our expressions (concats, usually) won't get resolved unless we actually want them to. Why is there no other recourse? The answer isn't surprising – it comes down to the way the API was designed. All log4j logging methods take a single argument -- which made a lot of sense, I suppose when the powers that be first designed logging APIs. They soon realized that in order to use their API, one has to use an expression to resolve all parameters into a single argument prior to calling the method! This is why a code guard is needed.

Java5 introduces a feature that allows for varargs, and taking advantage of this can help us with our ugly little logging problem, e.g.

With this approach, our expressions won't get resolved until after we're in debug(), and we can let it do the dirty work inside the method. The first thing that our logging method does is check to see if its level is valid, otherwise it'll fall out immediately. Because the concatenation happens inside the log method, we don't need a code guard to protect us.

This is the approach that Seam takes to logging. Seam's Log interface provides not only a solution that removes the need for code guards, it also allows you to use EL in your log messages (if you're trying to dive into a Seam component...) - e.g.

Much better. By and large, this is the way you do logging in Seam. Because binding occurs late, you never really run into the problem where you need to even think about using something like a "code guard." Code what you're supposed to; not noise! This is just one of many novel ways to use EL in Seam, and why it really deserves a look as a way to write better code, faster and as a far more productive platform for Java programmers (fed up with JavaSE/EE 1.4) than Rails/Grails.

See the Web Beans Manifesto for much more on this approach.

A lot gets written about Continuous Integration, particularly on which is the best visual cue to let you know your build is broken or that a test is failing – lava lamps, Beta Brights, Ambient Orbs, and some even suggest traffic lights. But aside from this extraneous (at least to business) nerd-banter, a lot of what I find written about the actual topic of CI is fluffy, ivory tower, or pie-in-the-sky jibber-jabber that leaves out important parts of the big picture or confuses people more than it helps. In hopes of clearing up confusion on what exactly CI is and how it's supposed to work, I'm ripping out a description that I wrote for a client proposal recently (so my apologizes for the dry-tone). I hope sheds some light on the true nature of CI, why it's important and how to implement it from a birds-eye point of view.

Continuous Integration Dissected

Any large scale development project needs an automated, repeatable build process. Following best practices while developing a build process properly separates environment-specific configuration concerns from the codebase. This allows new environments to be created quickly and easily by simply overriding any environment-specific configuration values when first executing the build process. Whatever build tool is being used, builds should share a common, consistent process and interface. A consistent, repeatable build will know all of its dependencies and the goal is to be able to build any given module anywhere, independently, at any time.

Automated, repeatable build processes typically begin by obtaining dependencies (which can be specified using a dependency management tool) and a specific working-copy of the codebase ("checking out") from a SCM system like CVS or Subversion. It is important to note that this codebase includes any code that is responsible for performing automated testing in addition to source code and configuration (and possibly other source-like artifacts).

Once the checkout has completed, the process will compile code and run automated unit test suites for each module in the system. At this point, all automated unit tests should pass, and custom development can begin. Any changes to code must be adequately covered by unit tests (either by changing existing tests or creating new ones), must fully compile without any errors and pass all automated unit test suites before being committed to the repository. The practice of always keeping the code committed to the SCM repository in this state (no compilation or unit test errors) is known as Continuous Integration and ensures that new development is safe to proceed at any point without fear of integration errors.

Subversion (and CVS) support concurrent development by following a Copy-Edit-Merge paradigm; any contention over files is usually caught when a developer tries to commit their changes and notices the underlying files have changed since they obtained their copy. In many cases, Subversion is capable of performing a merge automatically, if there was no contention over the same piece of a file. Sometimes, however, a manual merge will be required. Merging becomes more painful as the number of differences in the conflicting files increase. A good rule of thumb is that every developer should commit their changes at least daily.

Designating a single machine as a Continuous Integration (CI) environment provides many added benefits to a large scale development project. There are many operations which are good candidates to have run "continuously" but quite often are too expensive for developers to perform before every commit. Examples include executing automated in-browser system tests (which, if maintained over multiple releases, can serve as a "mini" regression test suite), performance tests/profiling, producing test metrics, generating documentation, etc. CI servers are an ideal place to schedule these processes to occur in an automated fashion.

Indulge me in a brief aside... I saw Full Metal Jacket recently on cable for the up-teenth time; the first act of the film, the part that is set on Paris Island, is hard for me to flip away from. I usually end up catching at least the first quarter of the movie. If you've seen it, you'll probably remember the part where the main characters recite, as new recruits, the Marine Corps prayer – it ends with "Without me, my rifle is useless; without my rifle, I am useless." I think the prayer metaphorically makes sense if developers were reciting it and replaced the rifles with their automated tests.

To figure out why, let's answer the burning questions that first come to mind:

Why should a developer care about doing their own testing?

1. It alerts you of problems (duh).
2. You'll have a check in place in case a bug ever comes back to life.
3. It gives you the opportunity to fix things before anyone else finds out about them.
4. It's the best way to demonstrate that your code meets its requirements!

Why don't you want testers (or worse, end users) to find your bugs?

First of all, let's be honest, this is an ideal to strive toward, even though actually achieving 100% test coverage and catching every possible bug is a definite pipe-dream. But we have to keep in mind that bugs discovered by people other than a developer cause a lot of speculation, confusion, and in general, overhead work for everyone – time that could be better spent doing more productive things. We'd like nothing better than to hand testers (and ultimately users) squeaky-clean code. What happens if we don't? (and you won't!)

Imagine taking a class of third graders outside to find an insect in the "wild" and learn about (not burn) it with a magnifying glass. You're even able to get everyone to concentrate long enough to take a peek at a would-be critter. The first candidate you find turns out to be a piece of bark that looks like a beetle. As you're searching for another, two of your students get in a fight over claim to a partially decomposed boot they find. Another gets a nose bleed. When you finally manage to find another potential insect, you pass it over, mistaking the critter for a leaf. Little do you know it is actually a very well camouflaged member of the family Phyllidae. By this time a child has fallen face first into a mud puddle and another has peed in his pants (which, one would think, should start to attract some insects).

Imagine that you do manage to find an insect in the wild; how would you get the whole class to observe it properly? There's just one magnifying glass. The moment you get it under the glass, it darts away. It's a struggle to keep track of. Not everyone is going to have a good viewing angle. If it disappears, then it might just as well be dead to you (did you hear that tree fall in the woods?).

Enough already with the horrible analogy? Okay, okay. The comparison of users to third graders in our thought experiment was purely coincidental – but you get the point. Having a group of people focus on a moving bug in "the wild" is tough! It'd be much easier to bring a captured critter into a controlled class environment to observe - our analog of a bug that we have caught with nifty our automated test net.

Bug Detective?

Given the fact that a tester's job is to find defects, odds are sometimes you'll get a defect report filed that looks like it's written in cuneiform and requires a wizard's hat, cauldron and lizard eyeballs to reproduce it. Sometimes a tester might not be giving you a legit bug – sometimes. There are a few scenarios that come to mind:

1. A requirement is incomplete, misunderstood, miscommunicated or changed.
2. An external system was down.
3. An admin fat fingered something.

This comes with the territory and you're just going to have to suck it up. You're ultimately the gumshoe on the case. A good way to think of it is that testers and users are like the police of our system – they're responsible for being the first on the scene, drawing chalk outlines, "booking" the suspects we arrest, etc. What the tester is explaining is probably going to confuse you at least a few times before it makes sense. If you have good testing support, this might not be that painful. But you could have the Super Troopers on the case, and each clue that comes in is going to waste more and more of your time. And heaven forbid an end user finds this problem, and then tries to communicate this to a support rep – your job then becomes ten times harder because you have to decode 2-3 levels of miscommunication that's occurred. Sometimes no good comes of all this, sometimes you find and squash a bug. In cases where you don't know what to do, write some tests – ask what the outcome should be, let the answers create more questions and more tests. And be sure to hold onto them!

Whatever the outcome, because good developers are lazy, we want more than anything else to prevent this from ever happening again. Worse case, you've spent a lot of time addressing something and should have at least a documented set of work you've done and decisions made. Make sure others know about this. Best case, you are able to add an automated test so you don't have to think about this ever again (or tell anyone about it - you'll know the moment when something goes wrong).

Conclusion

So let's recap –

1. Bugs that slip to production are costly!
2. Automated tests help us exercise code before and after it goes into production.
3. If we work on a defect, our automated test net can help us catch a bug, or examine something that looks like a bug more closely.
4. Whenever we work on a bug (even if it's something that isn't truly a bug, but is being tracked as one) we should do our best to produce an automated test so we don't have to reinvestigate in the future. A test beats an email- or source control commit-trail any day!