eWeek says that IBM is set to being using AOP technology in products within 12 to 15 months.

My earlier comments still hold, but I believe that software development companies (as opposed to the other 99% of the programming world) are the best place for AOP, because of the high quality of their development staff.

The best and worst of San Francisco, starting with the highlights:

1. Barry Bonds 665 and 666!
2. Alcatraz. Coming from London, I found myself thinking "those cells aren't so small. They should see my place."
3. Marv Albert working again. This has nothing to with SF, but the playoffs would be poorer without Marv behind the mic.
4. It looks great. I am a sucker for corny stuff like cable cars, and those hilly streets are amazing.
5. Giant foam hand. I now own a SF Giants foam hand. Photos to come.

And the lowlights:

1. Crazy guy menacing me with a baguette. The city seems to have an unnaturally high number of pan handlers and homeless people. Most of them were pretty well behaved, except for one guy who went all Barry Bonds on me with a loaf of bread.
2. Giants lose 7 - 6. With Barry on deck and two men on, which really hurts.
3. Warriors miss the playoffs. Baseball is cool, but I would have much preferred some hoops.
4. SF MOMA, closed on Wednesdays. Why close at all?

I am a few days away from a world tour of the US and Australia. It goes London to San Francisco to Brisbane (via LA with some dead time in Auckland) to NYC (via LA again) and back to London.

Sunday in SF is going to be cool – we are going to Alcatraz early in the morning, before taking our (cheap) seats at the Giants vs. Dodgers game. I am going to squeeze a week in at PLAS somewhere in there, as well as meeting up with Rinzen in New York.

And I am leaving enough room in my luggage for at least one giant foam hand.

We've had the death march and cargo cult programming. I'd like to propose another addition to the programming lexicon: the Colonel Kurtz project.

How do we spot Kurtz projects? Try the following:

1. Scanty information: Nobody is saying anything, documentation is non-existent or irrelevant, ship dates are not seriously discussed
2. Messianic leader, whispers of insanity
3. Total collapse in the chain of command
4. The project team has 'gone up the river', and nobody knows when they are coming back

I caught a conversation yesterday along the lines of “work intiated by QueueUserWorkItem won’t complete if the main thread exits, but work initiated by Thread.Start will.” The .Net threading APIs are a pleasure to use, but there are a couple of little catches for the unwary. One of these is the difference between foreground and background threads.

The behaviour described above is certainly the way it looks out of the box: pool threads (the threads used by QueueUserWorkItem) are background threads by default, whereas threads created by the programmer are foreground threads.

The thing to note here is that threads can be switched from foreground to background mode. Consider the following example¹, which creates a foreground thread via QueueUserWorkItem:

/*
1. Uses QueueUserWorkItem, waits for second thread to complete before unloading app domain 
*/ 
class ThreadTest {
	static void Main() {
		System.Console.WriteLine("Main method 1");
		System.Threading.WaitCallback callback = new
System.Threading.WaitCallback(Work);
		System.Threading.ThreadPool.QueueUserWorkItem(callback);	
		System.Threading.Thread.Sleep(0);
		System.Console.WriteLine("Main method 2");
	}

	static void Work(object state) {
		System.Threading.Thread.CurrentThread.IsBackground = false;
		System.Console.WriteLine("New thread work 1");
		System.Threading.Thread.Sleep(10000);
		System.Console.WriteLine("New thread work 2");
		System.Threading.Thread.CurrentThread.IsBackground = true;
	}
}

By manipulating the IsBackground property, I can also manually create a background thread, which will not stop the app domain from unloading:

/*
2. Uses Thread.Start, does not wait for second thread to complete before unloading app domain 
*/ 
class ThreadstartTest {
	
	static void Main() {
		System.Threading.ThreadStart start = new System.Threading.ThreadStart(	
			ThreadstartTest.Work
			);
		System.Console.WriteLine("Main method 1");
		System.Threading.Thread newThread = new System.Threading.Thread(start);
		newThread.IsBackground = true;
		newThread.Start();
		System.Console.WriteLine("Main method 2");

	}

	private static void Work() {
		System.Console.WriteLine("New thread work 1");
		System.Threading.Thread.Sleep(10000);
		System.Console.WriteLine("New thread work 2");

	}
}

¹This example produces the desired effect, but might not work all the time in the wild: the second thread becomes foreground once the Work method is called. If the first thread yielded, but the QueueUserWorkItem was not serviced, it might never run.

I am planning on hiding out for the weekend to get through some books:

1. Kevin Mitnick's The Art Of Deception
2. K&R The C Programming Language (retro, I know)
3. XQuery from the Experts

No way am I dodging my literature review / research project.