Successful Collocation Experiment

One of the common practices in most Agile methodologies is the idea of collocation. Tomorrow, 5 of my developers will move back to their home cubes from another building on our campus complete with machines and chairs.

The scenario was we had a nasty large project that had been in defect resolution for well over a year. There were lots of communication issues resolving defects and both sides had a tendency to throw things over the fence and let issues sit for days. Every time I talked about setting up a war room or bringing the QA testers over to sit with the developers I was essentially told it wasn’t going to happen. So this March I decided I probably had the power to move the developers out to the QA area in another building. While I think they were a little surprised I didn’t get that much flack for it. So 6 developers and myself in the afternoons moved over to sit next to the QA staff.

After a lot of missed deadlines on the project, we finally delivered at the end of July for the first time on schedule. While collocation wasn’t the only factor it was a definite contributor. QA and development finally got on the same page. At least one other project team has been collocated now, so hopefully this will be a continuing trend.

Simple Fitnesse Example

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 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

|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() {
    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.

Oracle 10g has a Recycle Bin

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.

Simple log4j.xml Example File

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 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 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="">
  <appender name="ConsoleAppender" class="org.apache.log4j.ConsoleAppender">
    <layout class="org.apache.log4j.SimpleLayout"/>
  <category name="com.springinaction.chapter01">
    <priority value="debug"/>
  </category><root><priority value="info"/>
    <appender-ref ref="ConsoleAppender"/>

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.

The Drunk and Retired Podcast

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.