As an aside, I didn't realize how expensive Lionel trains had become. You can spend a fortune on these things.

One thing I can take a lot of credit for is our organizations name - See a New Sun Foundation or SANS Foundation for short. This name came to me during my drive to work one morning. My wife Jayne had mentioned the word Sun in one of the previous brainstorming sessions and it had stuck in my mind. We wanted a name that offered hope. I thought See a new Sun did that. It spoke to the goals of the organization to help people live another day, fight the darkness of depression and see a new sun. But the clincher for me was when I realized the acronym spoke to the pain that drove the board members and volunteers who would make the organization. We all had lost someone dear to suicide - we were sans someone - without someone. The board was quick and nearly unanimous in adopting the name.

It's was a small contribution but I'm proud of it.

Is everyone working in Java so enamored of the Bean style setter pattern? Personally, I think it stinks. The Bean pattern creates a lot of surface area on the class. All those setters often obscure the functional API. A problem that is even worse is the issues related to state transition. Because the setting of the configuration isn't atomic, the object is left in an odd state while the setters are being called. Not good.

One alternative technique I've seen employed is the use of a sibling configuration interface that defines a class’s configuration requirement. Something like:

interface MyConfig {
    int getPort();
    String getUserName();
    double getFraction();
}

I pondered these issues and can up with a simple solution to deal with configuration in my latest project. I don't know if the pattern has an official name, but I call it 'Key Based Configuration'. The core of it looks like:

/**
 * Supply configuration
 */     
interface Configurations {
    Object get(String key)
}
/**
 * Consume configuration
 */
public interface Configurable {
    void configure(ConfigurationSource configSource);
}

The pattern is not without flaws, but the following examples show how I deal with some basic problems. 1. The interface is not type safe. Personally, I don't think this is a big issue. I've seen the arguments. Configuration parsing is most often done early and any class cast type exceptions between the producer and consumer will usually show up at startup. If your concern is usability, a simple helper class that adds type semantics can be used to wrap the core configuration source..

public class TypedConfigurationSource  {
    private ConfigurationSource root;
    public TypedConfigurationSource( ConfigurationSource root) {
	this.root = root;
    }
    public String getString(String key)
 	return root.get(key).toString();
    }
    public integer getInt(String key)
 	return Integer.parseInt(root.get(key).toString());
    }
    etc...
}

public class NamespaceConfigurationSource implements ConfigurationSource {
    private String namespace;
    private ConfigurationSource root;
    public NamespaceConfigurationSource(String namespace, ConfigurationSource root) {
	this.namespace = namespace;	
	this.root = root;
    }
    public Object get(String key) {
 	return root.get(namespace + "." + key);
    }
}

Given the title: Master and Commander - The Far Side of the World, Its hard to say what book (if any) it will follow. The question arises because these are titles from two different books in the series. Its possible that they just chose Master and Commander as the hook onto which possible sequels could be hung and that the plot follows that of The Far Side of the World. I've speculated with other fans in the past about who might play in a movie version of the book and the names that came up where, Brian Dennehy for Aubrey and F. Murray Abraham as Maturin. They may have been able to pull it off in the 80s but given the passing of time, I think the choice of Russel Crowe and Paul Bettany is inspired. Its also interesting that this is a A Beautiful Mind reunion for the two.