One of the shiniest new feature of Java 5.0 (aka Java 1.5) is a rich set of concurrent programming classes in java.util.concurrent (aka JSR 166), much of which is a direct port of Doug Lea's Concurrent Programming in Java library.  Since I don't have the luxury of using Java 5.0 yet, I've resorted to using Doug's original library which is, for the most part, functionally equivalent to java.util.concurrent but not close enough for comfort, particularly since concurrency code tend to be very sensitive to minor changes.

The good news is that Dawid Kurzyniec backported java.util.concurrent package to run under Java 1.4 and made it available as open source.  Apparently Sun is letting this happen because it's own code is based on Doug's open source library.

There are some shortcomings but nothing much to cry over.  My only complaint is that it doesn't use the java.util.concurrent package name which means I'll have to update the package names later (simple but still change nonetheless).  But that I can see the technical and legal issues preventing that from happening.  I am just glad someone did this.

I ran across SwarmStream and thought it was a wonderful piece of technology.  Basically, they took BitTorrent and slipped it under Java so that any Java application can trade bits as fast as BitTorrent can.

Unfortunately, not enough people needs it badly enough to make it a successful venture IMHO.  Same opinion applies to the grid technology.  If you can plug your feed tube into some government agency with a fat budget, excellent.  If not, your meals will be far and wide in-between.  If you took Google's wonderfully expansive service technology and turned it into a product, will it survive?  My opinion is that it won't.

Who Needs It?

Really.  Who needs server farms?  Google does.  Who else and how many of them are there?  More importantly, are they the kind of customers with the right sense of value?  Would Yahoo or Microsoft buy it?  I don't think so.  People who need it are few and most of them are too gung-ho to be interested in buying instead of building it themselves.  Banks?  Are banks prepared to own or even rent server farms?

Who Wants It?

Swaming requires third party participants.  That cuts entire financial services sector out.  And entertainment industry is, in some ways, more conservative than the banking industry.  Will they let their latest hot movie swarm?  What a joke.

Revolution is a lonely business if you jump the gun.  Swarming and grid technologies, active or not, are ahead of its time.  If you got enough money and marketing know-how, you can hurry time.  Otherwise, you are walking into a world of hurt.  Maybe you can prevail.  Most likely not.

Last night, I actually had a cinematic conference in my dream.  It was as I described it except I saw the UI and heard the people talking.  I don't know about other people, but I often have very vivid dreams that either solves problems I am working on or visualizes my ideas in full flesh.  Too bad I have little control over it.

Anyway, it took me a while to notice that voices of people talking were coming from different locations.  Location of the voice was in respect to where the speaker was seated in respect to the listener.  I was impressed enough with that to remember this morning clearly.

I don't think the actual locations of the attendence is important as long as they are consistent to the listener.  So the listener can sit in the bottom middle of the long side of a meeting table and other attendents are seated as they join in but grouped according to friends list (they are placed close to their friends).  A simplified overhead diagram of a meeting table with seats around it can be added below the video panel to aid the listener.  When a person speaks (and 'the scene' switches to that person), his or her seat highlights.  Each person's miniturized face shot can be used instead of seats.

I am not planning to implement this idea anytime soon but I thought my blog is a good place to keep my notes together just in case.

A very nice post for Java programmers wrestling with Python.  Python is not just another syntax plus a different set of libraries.  It's a whole new ball game.  I am now on the slippery part of Python learning curve, but at least I fell down enough to know it's slippery.

The exasperating part of Python is that seemingly insane features start making sense when put into practice.  This reminds of a fable where a King was concerned that most of his countrymen were going insane.  He solved the problem by going insane as well.  Ayaya.

Diego continues to plow ahead with his conversation engine (renamed from conversation finder) and he is now using Feedster search results to thread the conversation fragments.  Here is an example of the conversation engine output: a short conversation between Tim Bray and I.

Drools 2.0 beta 18 is out.  It's faster, more stable, and slightly easier to use.  Still very weak with debugging support though.

FYI, Drools is a nice open source Java rules engine which I have been using to build a forensic analysis system.  I ran into some irratic behaviors over the weekend but this update cleaned up the problems.  Whew.  That saved me the trouble of wandering inside stranger's code which can be messy.

Oh, Creole is another helpful Java tool you can use when you find yourself inside other people's nightmares.  It shows a zoomable diagram (not UML mind you) of Java code.  The zoomable part was implemented using Jazz.  If you are interested in ZUI (zoomable UI), skip Jazz and head directly to Piccolo.  It's open source and there is a .NET version as well.

I have been doing too much Java lately and not enough .NET and Win32 stuff.  It feels like a side of me is getting rusty like the Tin Man.

My Conversation Category post inspired Diego Doval to begin work on a conversation finder service.  Cool.  I hope he doesn't end up repeating what Technorati built because trying to be complete is unnecessary and very costly.

BTW, Diego is looking for an emotionally satisfying and financially rewarding job, hopefully in the Sillicon Valley (he is currently in Ireland).  Diego is one of the smartest guys I know so, if you want to join that group, hire him.  I would love to hire him to work on the stuff I am building but I can't afford to hire him yet because I am too busy just now to chase after investors.  Damn.

Bayesian inference is useful in practice yet it's difficult to grasp fully or explain clearly.  If you always wanted to learn about Bayesian inference, this article by Paul Meagher is probably your best bet.  I make a terrible teacher but, at least, I can recognize good ones.

Recently, Tim Bray suggested to Atom syntax mailing list that perhaps a 'victory' should be declared for Atom feed format:

The world can use Atom, sooner rather than later. The return-on-investment of further WG time invested in polishing something that's already pretty good is starting to be very unattractive. Particularly when the Protocol draft seriously needs work and progress.

Tim also asked Atom protocol mailing list whether dicussions were converging and ready to seek consensus.  So it looks like Atom WG is attempting to start the end game phase.

As I expected, the Atom feed format as it stands now is arguably not very different from RSS 2.0.  Dare Obasanjo wrote in response to Tim's victory suggestion:

So far Atom is a less featureful version of RSS 2.0.

…my internal data models in RSS Bandit haven't changed one whit because of Atom, just the parsing code.

In response, Tim enumerated the list of advantages current Atom feed format has over RSS 2.0:

1. There's zero ambiguity about single and double escaping, you can use whichever suits your publication process better and not worry about silent data loss.
    
2. You can include binary chunks right there in-feed, base64 encoded.
    
3. You get help for aggregate feeds using atom:origin.
    
4. You have a date, atom:updated, with cleanly-specified semantics ("publisher says something changed") that's *guaranteed to be there* per-entry.
    
5. It's in an XML namespace.
    
6. It's got a good accessibility story: you have to have an atom:summary if there's no src= or it's binary.
    
7. You have clean semantics for linking to the entry this describes or the entry it's talking about.

Well, I wasn't exactly impressed with the list and neither was Dare.  Are you?

So it doesn't look like Atom is ready for Prime Time any time soon.  Even if victory is declared now for the Atom feed format, it will just start a Brand War since feature differences are minor, leaving only the brand as the primary differentiator.

As I pointed out seemingly ages ago, the area Atom could have made the biggest impact is in the protocol/API.  But as you can see by the level of activities in the Atom protocol mailing list, work on the protocol haven't gained much ground, let alone converge.

I don't think it's too late to use RSS 2.0 as the starting point and build on it without breaking backward compatibility.  Most of the items in Tim's list of advantages can be added to RSS 2.0 as extensions, either individually or as a set called Atom.  This will allow the Atom WG to focus on the protocol instead of getting angry.