While I like the Fitnesse example built into the wiki, I really can’t get a feel for it until I hook the test fixtures into some of my own code. Stepwise:

1. Download Fitnesse.
2. Launch the run.bat or run.sh script to launch the Fitnesse web server on port 80.
3. On the front page click on Edit.
4. Copy the format for the Fitnesse.SuiteAcceptenceTests on a new line. In this case for Example Acceptence Tests. Click Save.
5. Click on the link for the new page and add the following code:

!path /edgibbs/example_project/build/classes

!|com.edgibbs.fitexample.PersonFixtureTest|
|firstName|checkFirstName?|
|Harry |Harry    |
|Irga | Irga     |
|null | null |

The path setting should point to the area where the classes are built. The firstName will set the firstName property, and the checkFirstName will return a String for the firstName from the fixture class.

1. Run test, it should fail because class won’t exist.
2. Create following class to test an overly simple javabean, Person. Person just has a firstName String property with getters/setters:

package com.edgibbs.fitexample;

import fit.ColumnFixture;

public class PersonFixtureTest extends ColumnFixture {
  private Person person = new Person();
  public String firstName;

  public String checkFirstName() {
    person.setFirstName(this.firstName);
    return person.getFirstName();
  }
}

1. Compile the class.
2. Run the Test again. You should get green rows, yeah! And yes, this example is pretty trivial, but I like to start small.

I learned about one of those wonderful issues that crop up in software development that are just about impossible to plan for. One of my senior developers who’s rolling out a small Hibernate project mentioned they had run into an issue with Oracle 10g. This was the first project we’ve used 10g on, but all of a sudden he started getting strange errors when he tried to generate the schema on the fly. After some frustration it turned out that DROP doesn’t really mean DROP in 10g. Oracle has added the idea of a recycle bin so that you can recover the table. A quick removal of the default setting and the problem was solved.

I’ve had to configure Log4J several times over the years and I’ve never particularly enjoyed the experience. Log4J is in general just not well documented, surprisingly so since it is used extensively in the Java world.

So I found myself going through some examples in the first part of Spring in Action and needing to configure Log4J. So off to the Log4J site only to run into familiar problems:

• Most of the documentation forgets to mention the easiest way to configure Log4J so that you don’t have to explicitly load a file is to add log4j.xml to the CLASSPATH.
• Almost all the documentation and tutorials show log4j.properties instead of log4j.xml
• The documentation and tutorials don’t explain most of the options for the XML tags.
• There just isn’t a good solid recent tutorial. (Or at least I haven’t run across it)

So I’m documenting my Log4J setup, mainly so I don’t have to research it again sometime down the road. The two best tutorials I could find were ‘Don’t Use System.out.println()! and Log4J Tutorial by Ashley J.S Mills. The first details most of the options for layout parameters and focuses on the log4j.properties format. The XML configuration is better covered Ashley J.S. Mills article.

Following below is my sample log4j.xml file:

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">

<log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/">
  <appender name="ConsoleAppender" class="org.apache.log4j.ConsoleAppender">
    <layout class="org.apache.log4j.SimpleLayout"/>
  </appender>
  <category name="com.springinaction.chapter01">
    <priority value="debug"/>
  </category><root><priority value="info"/>
    <appender-ref ref="ConsoleAppender"/>
  </root>
</log4j:configuration>

The appender section simply defines a Console Appender and a simple layout. The category section defines a package and a priority level. It’s important that you put this before the root section apparently in the file or you get errors. If you want to log all the debug statements just from your stuff you leave this set to debug. This overrides the root section. The root section is ‘required’ or again you get errors about Log4J configuration. In this case its set to ‘info’ for the priority so I don’t get a bunch of debugging messages I don’t care about in the Spring framework.

Finally you can then use Log4J in any class by adding the following instance variable:

Logger log = Logger.getLogger(Sample.class);

Then when you want to dump something to the logger a simple call:

log.debug("Entering printThis() Method");

This simple example doesn’t show File Appenders or nicely formatted statements with date and time stamps, but it does show the bare minimums to get up and running, so hopefully I’ll never have to research it again.

My actual opinion of loggers is that they often are signs of bigger problems such as insufficient unit tests. Loggers can be overused as a basic debugging strategy. I prefer to go back and write more unit tests rather than rely on logging to debug a problem. They also tend to clutter up code, though that will theoretically become less of a problem with AOP strategies. Still they’re generally handy especially for debugging production issues.

I’ve run across a few developer podcasts worth listening to on my morning walks. Drunk and Retired was a nice surprise. It has some low brow humor, cursing, and personal stories on non-software topics, but it manages to be a good back and forth between Charles and Cote. They’ve both been developers for 10 years or so. Charles is currently in Europe living the software developer’s version of the rock and roll lifestyle as an independent software developer, and Cote is recently married and working for a large corporate shop.

The topics cover wide ranging current topics from Rails to Domain Specific Languages. Cote and Charles tend to be disparaging of most of these bleeding edge technologies, but their criticisms stem generally from hard experience or at least based on wild speculation. Give them a listen if you’re geeky enough to enjoy development podcasts.

I came across yet more anecdotal evidence that actual JSF adoptions are coming along pretty slowly, from some commentary by Greg Luck. During a session on web frameworks with Craig McClanahan and Matt Raible at O’Reilly’s Open Source Conference apparently a question was asked about who in the audience was using JSF:

It is a little unclear what will happen with JSF. It has been coming for a long time, but only one person in the audience was using it.

This points again towards the idea that despite all the talk about JSF, there are still few people using it. And I’ll probably get flamed about this since the technology has some hardcore true believers. For me it’s on the wait and see list of new technologies. I’m still not convinced its worth the effort to adopt and that something better is likely to come along.