What is good practice for understanding a system? What is the point of understanding a system? How and when does that understanding become outdated? These questions are relevant to system documentation - our topic. This article seeks to directly answer each of these in turn.

"Understanding a system" differs from "learning a system" in one key aspect: ownership. When we share ownership of a system we may successfully contribute to its change, which leads us to a crux of the problem: understanding a system is directly dependent upon its vectors of change. But to come back to ownership for a moment, that is the main point of understanding a system. If you have no need to own a system - there is no point in understanding it. On the other hand, the act of enhancing or fixing a system is certainly a reason for understanding a system.

The timing seems right to demonstrate a pattern for testing asynchronous processing. This follows up on Steve's assertion: Don't make assumptions, write the test.

For purposes of demonstration our user story will be: As a program I want to output a message after an event is raised. So let us start by writing a test. Our story implies an event reader and a writer. So let us use the runtime execution provided by test runner and make that the reader. The writer will be some other simple class.

namespace Test.AsynchronousProcessing
{
    [TestFixture]
    public class EventReader
    {
        [Test]
        public void CreateInstance()
        {
            Assert.IsInstanceOfType(typeof (EventWriter), new EventWriter());
        }
    }
}

If you run the tests for EventReader, CreateInstance will fail of course. So let us do the minimal necessary to make the test pass: create EventWriter class. By the way...by convention the code listings show only relevant material.

    public class EventWriter
    {
    }

Came across a gnarly difference in behavior between .NET runtime and Mono runtime. Take a look at this snippet.

[SetUp]
private void Setup()
{
  this.layout = new FeedLayout();
  this.layout.ActivateOptions();
  this.writer = new StringWriter();
}

Test-driven development using JUnit left me with the arguably proper habit of defining setup/teardown methods private. This practice works in nunit under .NET runtime - but not under mono. You must change the modifier to public - as in...

[SetUp]
public void Setup()
{
  this.layout = new FeedLayout();
  this.layout.ActivateOptions();
  this.writer = new StringWriter();
}

Closures are a powerful concept in some languages - a powerful tool in others. In my mind a tool is something I can ask for by name - as in, "I'd like a reciprocating saw, please." Languages where closures are truly a tool include Lisp, Python, Ruby, among others. For the time being I will use Ruby to discuss closures - although a switch over to Lisp may be necessary.

One of the most ubiquitous patterns in life is the template. It enables us to generalize behavior - thus ignoring or postponing complexity.

This ability to generalize behavior - deferring derivative details - turns out to be extremely useful in agile software development. It encourages mock-object practices. It encourages simplest possible solutions. It encourages test-driven development. And most importantly it embraces change.

What is the template-method pattern? A good example is found in JUnit. TestCase.run() defines a generic process: 1) setup before running test; 2) run test; 3) tear down after running test. The complexity is provided by derivative TestCase types - but the process is same for every run.

public class TestCase {
  // details elided
  public void run() {
    setup();
    runTest();
    tearDown();
  }
  protected void runTest() {
  }
  protected void setUp() {
  }
  protected void tearDown() {
  }
}

Primitive Obsession is a result of poor practices. Primitive Obsession is a byproduct the impedance mismatch between OOD and ERD. Primitive Obsession is a code smell indicating procedural design - encouraged by some heavyweight framework.

Okay. But what does that look like? And, more importantly, how do I code my way out of it?

    PersonTypedDataSet GetPerson(Int64 personIdentifier);

This is your basic primitive obsession in action: use of primitive types as keys to a map (ERD, HashMap). This causes a flacid integration point. The parameter is an integral type - it has primitive rules regarding its domain and range. What means -1? Where do I get this magic number from? How do I remember what the number indicates? How do I get more information about this person number?

This may wind up the shortest entry to date - yet I hope as valuable as any other post.

Several months ago I switched the host OS on my laptop - from Windows XP to Gentoo Linux. One of my many reasons for doing so was the ease of maintaining a performant system under Linux (esp. Gentoo). All those Windows services we so very rarely use add up to wasted memory and processor.

My Gentoo installation is loaded with only those components I regularly use. Recently I needed to crunch some financial figures. A calculator was not installed on my system but Ruby was! And that leads me to maybe the best calculator of all...

In software development process, one of the things that developer is afraid of is breaking the build. Usually I do is to create another source code tree, then get the lastest code, then manually copy over changes from my working branch; finially start a release build from this test branch to verify everything is compilable. This process is very lengthy and time consuming if you have tons of code.

After I moved to a new development environment, we have this "Build Farm" environment, I think it is a very good way for developer to verify their code changes before check in the code.

Just mention design patterns in a development setting and you may incite riot. Some dispute their taxonomy - many dismiss their utility - while others unaware of the topic entirely. So with proper expectations set I have solicited the PerCS authors to write about the various patterns.

These posts will not be high-level; they will be real-life application of patterns. They will contrast patterned design with random design. But most of all they will contain freely distributed, well patterned code.

Creational Patterns

• Abstract Factory
• Builder
• Factory Method
• Prototype
• Singleton

Structural Patterns

• Adapter
• Bridge
• Composite
• Decorator
• Facade
• Flyweight
• Proxy

Behavioral Patterns

• Chain of Responsibility
• Command
• Interpreter
• Iterator
• Mediator
• Memento
• Observer
• State
• Strategy
• Template Method
• Visitor

Do you run out of memory becuase everything is cached in memory and hit the limitation imposed by 32-bit machines?
Do you need to preserve objects when your application restarts?

If you answered yes, then I have a simple solution. Use serialization to cache objects to disk. When objects are added or updated to a collection then serialize it to disk and de-serialize when a retreive request is made.

I started this project called PersistentCaching and created a class called PersistentArrayList. The first step was to define methods I wanted to support, and I decided on the following: Add, RemoveAt, Clear, Item, and Count.