Sam Ruby unveiled AtomEnabled.org site.  It's still in beta, but it looks pretty good already.  RSS should have a site like that.  At the moment, I don't have anything Atom-enabled so I didn't add to the Atom-enabled directory.

Hmm.  Is it just my imagination or is there is a strong invisible presence of Joi-centered social network behind Atom?  There is nothing wrong with it, of course.  I am just amazed at how knowing the same person can create synergy.  I don't think such effect is limited only to powerbrokers like Joi either because the effect doesn't require the 'center' to coordinate or even be aware of the synergy he or she creates.  Such passive effects of social networks are much more powerful than the kind of forced activities encouraged by services like Friendster and LinkedIn IMHO.

Of course, there are negative effects which are just as interesting.  For example, put two people like Dave and Mark together in a social network and something sour happens.  I don't get along very well with Mark either.  While I don't think my friendship with Dave has anything to do with it, the subconscious mind is called that for a good reason.  I should do some reading on group psychology.

More I think about the magic of social networks, more I am fascinated by the human angle of it.

When I changed web server at the end of last month, I didn't have time to move non-blog related pages and files.  Until I do, I'll post on my blog whenever someone ask for them.

Today it was the Flash SWT Plugin which I wrote long time ago.  The plugin basically allows you to play Flash animation within SWT applications and tools.  Here is a screenshot.

ZIP file with source code:

com.docuverse.swt.flash-0.4.zip (148.48 KB)

There is really only one class you need to learn about: FlashPlayer. Below is a code snippet that will play a Flash movie.

import com.docuverse.swt.flash.FlashPlayer;
…
FlashPlayer player = new FlashPlayer(container);
player.loadMovie(0, “http://somewhere.com/movie.swf“);
…

For a complete example, scan the FlashPlayerView class source code.

Dave Hyatt is adding obtrusive XML error reporting to Safari (screenshot) which jives with the approach I suggested in Biased Liberal.  While at it, he came up with the perfect term for the negative UI bias I mentioned: Badge of Shame.  Thanks Dave.

On the issue of whether to introduce a new URI scheme to allow one-click feed subscription, in spite of W3C Technical Architecture Group's position against new URI schemes, I am adding my vote to Dare Obasanjo's proposal which is already in fairly wide use.  While I understand W3C TAG's position, a less than ideal solution is better than expecting the world to accept the right solution.

If you are unfamiliar with this issue, Jon Udell has a post with links and words.

Update:

I should note that neither schemes address the need to support multiple aggregators at the same time.  I thought about writing a general feed subscription management plugin for IE but haven't found the time yet.

Here is a particularly useful information on ASP.NET: Application Instances, Application Events, and Application State in ASP.NET.  This is the line that surprised me:

The ASP.NET runtime creates as many instances of application classes as needed to process requests simultaneously.  … Application instances are used in a thread-safe manner, that is, one request at a time.

Gee, thanks for that curve ball.  If you didn't know this before, now you know why application instance variables were behaving weirdly.  Yes, you were sleeping with her twin sister, so to speak.

Here is another one, this time from Dr. GUI: Am I Losing Memory?

A key reason that the Application object exists in ASP.NET is for compatibility with classic ASP code … consider storing data in static members of the application class rather than in the Application object.

This begs the question “Why limit oneself to 'static members of the application class' instead of just 'static members'?”  That's just a good way to add unnecessary dependencies.

BTW, it's funny how many pure ASP.NET applications are using HttpApplicationState.  Old habits die hard.

Last year, these benchmark results became hot points of contention between Java and .NET developers.  What the results suggested was that Java regular expression engines are significantly faster than .NET's Regex.

I thought it might be fun to port one of the fastest Java regular expression engines to J# and see how it performs compared to .NET's Regex.  I chose the dk.brics.automaton engine because it seemed easiest to port.  It was.  When I ran a straight-forward C# port of regtest.java on the J# version of dk.brics.automaton and compiled singleline Regex, I got these results:

dk.brics.automaton	2303 milliseconds
Regex	2894 milliseconds

I also ran regtest.java on the original dk.brics.automaton and Java's built-in regular expression engine.  Results were:

dk.brics.automaton	511 milliseconds
java.util.regex	1061 milliseconds

While J# version of dk.brics.automaton's performance is muffled by J#, I think Regex's relatively slow performance should not be blamed entirely on its implementation.

IMHO, .NET performance is 'good enough' for server-side use at this time so please don't misinterpret this post as an attempt to pull .NET down in favor of Java.

BTW, I won't be using my port of dk.brics.automaton in production because it's under the GPL curse and it seems to miss some patterns that it should have found.  If you want to give it a try, here it is.  You must have J# to build it.  The project is misnamed because I thought I originally started porting JRexx.  Oh, well.

    NRexx.zip (33.86 KB)

Java is a mature proven language for non-GUI applications.  What it means is that it does what you expect it to and there is a large body of open source software you can leverage.  Carlos E. Perez's enumeration of Open Source Web Crawlers Written in Java is a good example.

C# and .NET, on the other hand, has a long way to go still and there is no easy to extend IDE like Eclipse for developers to rally around.  Working with .NET at this point is like working in a new town destined to grow, maybe like Chicago was around 1840.  As for my involvement with .NET, I enjoy the rough life.

One of the not often discussed cause of slow performance is careless naming.

When you are naming a method that does more than get or set some value, try to avoid a name that might mislead the caller into calling it multiple times instead of saving it to a local variable.  For example, if a method is named GetTopicName, the caller is not going to expect it to search for the value and instantiate many objects in the course of doing so.  Instead use a name that implies and warns the caller about the cost of the method, like FindTopicName or CalcPrime.

When using a language that supports properties like C#, try not to turn heavy methods into properties.  Property getters and setters should be light operations.  If you have to, then try to precalculate the value and update on change via event handlers.  Failing that, try to warn the developer using documentation so the developer can use the property accordingly.

One caveat: Guidelines are not meant to be straightjackets.  Don't do it if you can't do it.

Woo.  I just found this gem of an IIS 6.0 feature while hopping around for info prior to writing an ISAPI Extension for IIS 6.0.  It's called IIS 6.0 Enterprise Tracing for Windows:

Windows Server 2003 includes Enterprise Tracing for Windows (ETW), a new framework for implementing tracing providers that can be used for debugging and capacity planning. IIS 6.0 implements a number of providers to trace key transitions and the progress that an HTTP request makes as it moves through the IIS service framework. These providers include the following:

• HTTP Service Trace. This provider traces new connections, new HTTP requests from a given connection, HTTP kernel cache hits, application pool routing, and HTTP request completion.
• IIS: WWW Server. This provider traces the transition of a request from HTTP.sys to the worker process, start and stop events surrounding Common Gateway Interface (CGI) requests, and the transition of a request back to HTTP.sys from the worker process. This information reveals the type of request that is being processed.
• IIS: SSL Filter. This provider traces calls into and out of the SSL Filter, which is used for SSL traffic.
• IIS ISAPI Extension. This provider traces the transition of a request into and out of ISAPI extension processing.
• IIS ASP. Traces the start and completion of the execution of an ASP request.

These tracing providers allow you to follow a request through all of its phases. This information is very useful in the problem isolation phase of troubleshooting. For example, ISAPI filters can often cause delays or hangs in HTTP request processing. The tracing functionality can help to determine which ISAPI filter is causing the delay for a given request.

Nice!  It's a bit beastly to use and there isn't a GUI tool to display the trace logs prettily so my eyes won't cross, but it's will come in handy when I find myself up the creek wearing a blindfold.

It's amusing to me that so many bright engineers are fighting inside a paperbag over the issue of what to do with bad feeds.  For some reason, probably human nature, they have limited themselves into finding a solution at the spec and parser implementation level when there is no solution there and the discussion has devolved into exchanging “is so“ and “is not“.

The Biased Liberal post offers a solution at the UI level without irritating the user.  The problem can also be solved at marketing and legal level although I favor the UI level solution.

One rather amusing (?) thought I occasionally use to pull myself out of a hole is that the ultimate solution to every problem is world destruction.  All right, it's not funny, but it does shake me out of the box.  As to the implementation, it's easy if you believe a tree falling without an observer makes no sound.

Update:

Looks like the XML-DEV got thrown into the paperbag as well.  There is now a long ongoing thread on Postel's Law, exceptions, and what to do with bad feeds.  Elliotte Rusty Harold did mention my Biased Liberal solution, but XML-DEVers seems to prefer talking about parsers, specs, what the world wants and needs, theories, history, scenarios, etc.  Well, they seem to be enjoying themselves so let's not bother them.