My roommate, John Ragin Miller, a man of acid wit and cynical humor, died one year ago today. It was Monday, February 14, 2005. Ragin, whom I sometimes called "Johnny Ray-Gun" was 30 years old when he died of, among other things, complications from his long battle with diabetes. Those other things include untreated acute and chronic depression, poverty, frequent alchohol use, and a street "counterculture" completely devoid of the power to instill hope and promise to a young man in dire straits.

Those who knew him will agree that he died of a broken heart. When a man's heart breaks, romantic love is only the first thing to go. The weight of debt, poverty, sickness and anger can drive one beyond dispair, and break the very will that makes us human. I believe that Ragin expressed his will in his spirited and blistering wit, but that it failed in the end to keep him afloat.

Ragin, despite his many troubles, was a talented actor and critic, with a sense of irony that far outstrips that of most people. Moreover, he possessed an ability to acknowledge and directly confront the uglier aspects of human life. I count my conversations with him during his lucid moments among the most rewarding of my life.

Ragin was a terror in the kitchen. He was a gifted cook, and he employed his encyclopaedic memory to excellent use in his distinctly southern cuisine. His tyrannical manners in the kitchen only contributed to his charm. He was a proud American from beneath the Mason-Dixon line, a fact he never let his "Damned Yankee" roommates forget.

I can't say enough about Ragin. He remains unforgettable. Today, one year after his death, I wish to remember him and send my warm regards to his mother and father.

Requiem Eternitum, Ragin.

Posted by Alexander Saint Croix on 13 February 2006 at 07:00 AM | Permalink | Comments (3) | TrackBacks (0)

I've been working on a Sample Iteration of an eXtreme Programming project, using the XpTrackerPlugin. This tool takes me close enough to what I need to leave me very disappointed. I don't wish to obey the old maxim not to look a gift horse in the mouth. Instead, I'll give what I think is a fair and useful critique of the plugin.

1. Obey XHTML. The XHTML standard should be rigorously obeyed at every step, so that it doesn't break other skins. I tried to use the program with the Nat skin, but it breaks the Nat skin on the iteration pages, probably because of failures to close block-level elements like div or table tags. There might also be failures in the Nat skin, but I haven't found them anywhere else.
2. Do not require Wiki Words for topic names. This precludes you from using names for iterations such as "Snapshot01", and makes the tool nearly unusable. Wiki words are for the weak.
3. Mind your table widths. The default tables wander waaaaay off my screen, again making the software nearly unusable. I have to shrink my font to see and edit table contents, and even then I can't see it that well.
4. Never hard-code colors into your HTML. You should always use a .css style for this, so that the user can override it. The default colors practically ensure a headache, unless you have partial ocular monochromatism, in which case you'll be completely lost and without hope. The alternate option to define colors in the WebPreferences is a nice touch--use that or CSS exclusively.
5. CSS: Use more of it. Every block level, at the very least, should be stylable. That means naming classes for these elements. Use a central style sheet that people can edit for their personal tastes.

I might add more as I think of it. For now, these are the chief improvements I can recommend for this plugin. If I manage to implement any of these customizations, I'll be sure to give them back to the community. Although much of the trouble I'm having evaporates when using the Pattern skin, I think these forms and tables should all be more stylable. Please, don't anyone take this critique as my failure to appreciate Rafael's contribution or stemming from any delusions that I'm somehow entitled to more for nothing.

Summary

Posted by Alexander Saint Croix on 11 February 2006 at 07:00 AM | Permalink | Comments (0) | TrackBacks (0)

Having satisfied myself yesterday on the question of whether or not PicoContainer can pick specific object instances of the same type out of the container while building other components, I now turn to the question of whether it can perform with the same precision while working with objects of differing type. I am happy to find that it is indeed possible and simple.

Let's say that the example I've been using so far, involving the Juice object, has an optional third constructor, which accepts two Fruit objects and a Cup object. I need to distinguish between specific instances of Fruit, and add a different type as the third constructor parameter. Here's how you accomplish that in PicoContainer.

    public void testMultiplePicoParamTypes() throws Exception {
        addFruit("lemon");
        addFruit("lime");
        addFruit("bubble", "tapioca");
        c.registerComponentInstance(
                "teacup", 
                new Cup("teacup"));

        c.registerComponentImplementation(
                "lemonbubbletea",
                Juice.class, 
                new Parameter[]{
                    new BasicComponentParameter("lemon"),
                    new BasicComponentParameter("bubble"),
                    new BasicComponentParameter("teacup")});

        Juice lemonbubbletea = getJuice("lemonbubbletea");

        Assert.assertEquals(
                "lemon", 
                lemonbubbletea.getType());

        Assert.assertEquals(
                "tapioca", 
                lemonbubbletea.getSecondIngredient());

        Assert.assertEquals(
                "teacup", 
                lemonbubbletea.getCupType());

        claimVictory();
    }

This permits one to keep a broad level of abstraction for the object instances, while maintaining specifically how they are assigned to be used by another object later on. Soon, I will illustrate why this is useful and in fact crucial to certain types of programming.

Posted by Alexander Saint Croix on 10 February 2006 at 07:00 AM | Permalink | Comments (0) | TrackBacks (0)

One of the most important features in an Inversion of Control container for me has been the ability to bootstrap components from the container that have multiple constructor parameters of the same type, without running into amiguity problems. I want to be able to direct which specific component gets loaded first, which specific instance loads second, and so on. Some contend that my need to do this points to bad design, but I don't particularly care. I know why I need to do it this way and no other way.

Besides, PicoContainer can do this easily, so obviously I'm not the first to require this type of feature. Here's a code snippet that shows how it's done.

    public void testMultiplePicoParams() throws Exception {
        c.registerComponentInstance(
                "lemon", new Fruit("lemon"));
        c.registerComponentInstance(
                "lime", new Fruit("lime"));
        c.registerComponentInstance(
                "bubble", new Fruit("tapioca"));

        c.registerComponentImplementation("lemonbubble",
                Juice.class, new Parameter[] {
                    new BasicComponentParameter("lemon"),
                    new BasicComponentParameter("bubble")});

        Juice lemonbubble = getJuice("lemonbubble");

        Assert.assertEquals(
                "lemon", lemonbubble.getType());
        Assert.assertEquals(
                "tapioca", lemonbubble.getSecondIngredient());

        System.out.println("w00t!  Pico can properly " +
                "create complex component instances.");
    }

I ran this test today and it worked perfectly as I expected. The container can create objects with as many or few objects of whichever type I need in the constructor. It Just Works (TM).

Did I mention yet how happy I am with PicoContainer? Inversion of Control exactly how it should be.

Posted by Alexander Saint Croix on 9 February 2006 at 07:00 AM | Permalink | Comments (0) | TrackBacks (1)

After all these years, I still love PicoContainer. I can't help it. It does exactly what I need it to do, and no more. About six months ago I found out that I could use PicoContainer to build components at runtime from specific instances of other objects in the container. For example, you ask the container for a type of Juice that is made from a specific type of Fruit in your container, based on a name you've previously given that specific instance of Fruit. This allows you the twin comforts of abstraction in your class implementation and precision in your runtime targeting of those objects in the container. It's the best of both worlds.

/**
 * COMMERCIAL OBJECT RELATIONAL MAPPING  (CORM) PROJECT

 * This document is Copyright (C) 2004-2006 
 * Alexander Saint Croix.  All rights reserved.
 *
 * THE CONTENTS OF THIS FILE MAY BE USED 
 * UNDER THE TERMS OF THE
 * ACADEMIC FREE LICENSE, VERSION 2.1.
 *
 * See http://opensource.org/licenses/afl-2.1.php 
 * for details.
 */
package org.eremite.examples;

import junit.framework.TestCase;
import junit.framework.Assert;
import org.picocontainer.MutablePicoContainer;
import org.picocontainer.Parameter;
import org.picocontainer.defaults.DefaultPicoContainer;
import org.picocontainer.defaults.BasicComponentParameter;

public class PicoContainerTest extends TestCase {
    private MutablePicoContainer c;

    public void setUp() throws Exception { 
        super.setUp();
        c = new DefaultPicoContainer();
    }
    
    public void tearDown() throws Exception {
        super.tearDown();
    }
    
    
    public void testPicoBehavior() throws Exception {
        c.registerComponentInstance(
                "lemon", new Fruit("lemon"));
        c.registerComponentInstance(
                "lime", new Fruit("lime"));
        c.registerComponentInstance(
                "bubble", new Fruit("tapioca"));
        
        c.registerComponentImplementation("lemonjuice", 
                Juice.class, new Parameter[] {
                    new BasicComponentParameter("lemon")});
        c.registerComponentImplementation("limejuice", 
                Juice.class, new Parameter[] {
                    new BasicComponentParameter("lime")});
        c.registerComponentImplementation("bubbletea", 
                Juice.class, new Parameter[] {
                    new BasicComponentParameter("bubble")});

        Juice lemonade = getJuice("lemonjuice");
        Juice limeade = getJuice("limejuice");
        Juice bubbletea = getJuice("bubbletea");

        Assert.assertEquals("lemon", lemonade.getType());
        Assert.assertEquals("lime", limeade.getType());
        Assert.assertEquals("tapioca", bubbletea.getType());
        
        System.out.println("w00t!  Pico works.");
    }
    
    private Juice getJuice(String s) {
        return (Juice) c.getComponentInstance(s);
    }
}

What happens in the code above is great. First, I feed a handful of Fruit components into the container, giving each of them names and distinguishing them from each other by a String. Then, I register a handful of Juice components in the container, each according to a different type of Fruit.

Later on, when I need some Juice, I can get it by name, and the type of Fruit that it contains is also pulled from the container. This allows me to feed abstract concepts of objects into a container, and ask for a fully constructed object that contains other objects in the container.

It's great Inversion of Control. Elegant, simple, lightweight. Gotta love Pico.

Now, a further question I'm wondering is whether I could make a JuiceMix object out of two types of Juice, and be able to ensure that the first one is a lemon and the second is a lime. Both objects are Fruit--can the container recognize the difference, or is it too ambiguous? If I could do this, it'd allow me to do very complex action processing in a declarative runtime environment in response to changing state conditions. It'd be very powerful.

PicoContainer 1.1, at only 75Kb, is a much sweeter deal for raw IoC than Spring at 32Mb. There used to be a SpringContainer available, but it required a lot of XML configuration and overhead that I didn't want to trouble myself with at the time, when I can get what I need from PicoContainer. I've recently heard of something cleverly dubbed "femtocontainer", which uses java.beans.XMLDecoder to accomplish much of what Spring does. Now that's an interesting idea that I'll look into more.

Posted by Alexander Saint Croix on 8 February 2006 at 07:00 AM | Permalink | Comments (0) | TrackBacks (0)

I'm still working on actually getting the XpTrackerPlugin to work with my TWiki installation. Now that I've gotten the plugin to install, I'm on to some runtime errors, two of which I've posted below.

First, there's the missing function reference:

TWiki detected an internal error
please check your TWiki logs and
webserver logs for more information.
Undefined subroutine &TWiki::isWikiName called

That's on line 631 of the XpTrackerPlugin.pm file. I contacted Rafael Alvarez about it, and he made a quick update to the SVN repository, which I downloaded and installed. Now I get a different error:

TWiki detected an internal error - please
check your TWiki logs and webserver logs
for more information.
Insecure dependency in open while running
with -T switch

This seems to indicate some kind of security or trust issue. I thought at first that this might be somehow related to these files being in their own Tracking web, and not integrated with another web, so I created a new web called "Obscure", which I'll use for quietly testing new features like this one. I was hoping that having it in another web would fix it--perhaps there was some permission problem? Unfortunately it did not. I've replied to Mr. Alvarez and I eagerly await his reply.

He said that he was going to update the code in SVN and conduct some more testing over the weekend. I'll be waiting anxiously for the results while he does. I'm really looking forward to using this for working on my software development projects. I also think it might prove useful for the UMWiki project, and the computer science department might find it very useful for running classroom software projects.

What would be great is if we could get some of the folks in Carlson School of Management working on Agile development projects with the folks in Computer Science, so that both sides learn good development methods. The question hinges on whether CSoM knows about Agile Development processes or not. I'm sure if the infrastructure is there for us to easily engage in Agile projects, then more people will give it a try.

Update, 2006-02-06

Eureka! The ever-diligent Rafael Alvarez has checked in a fully-functional revision to SVN. I've installed it on my server and it works as expected. Now I can turn my attention to improving the quality of the templates, fully integrating it with the NatSkinPlugin and working on my software.

I'd like to give a special thanks to Rafael Alvarez for his excellent attention to his users. He actually apologized to me for my trouble when his software didn't work--and it's free software! This is what makes Open Source so special to me--I've nothing but respect and admiration for the man. Thank you, Mr. Alvarez! You do great work.

Hopefully in the future I'll be able to help iron out these kinds of wrinkles in TWiki, instead of merely reporting them.

Posted by Alexander Saint Croix on 3 February 2006 at 07:00 AM | Permalink | Comments (0) | TrackBacks (0)

I had a great conversation today with a wikiuser about how turf grabbing and secrecy could greatly hinder the collaborative benefits of the UMWiki project. The chat transcript follows.

Posted by Alexander Saint Croix on 2 February 2006 at 07:00 AM | Permalink | Comments (0) | TrackBacks (0)

For the life of me, I could not get the XpTrackerPlugin for TWiki installed last night. I was up until 1:00 AM trying, though. What I wouldn't have given for a Java-style exception stack trace. I found an obscure reference somewhere online about a bad directory structure hindering the installation, so I'm probably going to go back over the Perl code by hand and see if I can track down the problem.

I don't want to write my own plugin for this, so I'm seeking help from Rafael Alvarez. For the record, here's what headaches look like in January:

TWiki::Plugins::XpTrackerPlugin could 
not be loaded.  Errors were:
Can't call method "getPreferencesValue" on
an undefined value at .../lib/TWiki/Func.pm line 458.
Compilation failed in require at
.../lib/TWiki/Plugins/XpTrackerPlugin.pm line 32.
BEGIN failed--compilation aborted at
.../lib/TWiki/Plugins/XpTrackerPlugin.pm line 32.
Compilation failed in require at (eval 40) line 1.
BEGIN failed--compilation aborted at (eval 40) line 1.

Update

So, hats off to Rafael for his lightning fast response to my question. Now I can track XP projects with ease.

Posted by Alexander Saint Croix on 1 February 2006 at 07:43 AM | Permalink | Comments (1) | TrackBacks (0)