While I was looking at the data storage portion of DasBlog for improvements, a low hanging fruit hit me on the forehead: XmlSerializer.  XmlSerializer is a major feature of .NET Framework that makes it really easy to read and write data structures from and to XML.

To use XmlSerializer, all you have to do is mark some members of the data structures with .NET attributes — .NET attributes are just source code comments for programs instead of people – that provide hints like this member should be an element and the element name should be such and such.

Ease of use encourages ease of abuse.

XmlSerializer is a rather complex beast so the class takes a while to instantiate.  What hit me on the forehead was that DasBlog was using it everywhere and XmlSerializer was being instantiated substantial number of times per request: a juicy low hanging fruit indeed.

So I implemented XmlSerializerFactory which maintains a pool (as in car pool) for XmlSerializer instances and rewired DasBlog to use it whenever it needs an XmlSerializer.  There are actually multiple pools because XmlSerializer instances are target data structure specific.

All that took no more than 30 minutes but the result was very rewarding.  DasBlog with XmlSerializer pooling was noticeably faster.  My guestimate is that it's 20%-30% faster depending on the page type being accessed.  Woohoo!

Update:

It turns out that .NET 1.1 version of XmlSerializer uses an internal cache already although it depends on which constructor is used.  So the speed improvement I saw was either a hallucination or due to some other changes I made.

An irony of the blogosphere is that permalinks are not permanent.  Whenever a blog changes service or software, its permalinks breaks.  While breaking of permalinks is not worth crying over, it's pretty annoying because internal links break as well.

Unless you are prepared to get your hands dirty, changing blog service or software means you are better off leaving your old posts where they are.

Having your own domain name doesn't protect you either if you decide to switch blogging software.  This is why bloggers are leaving a trail of blogs behind them like a breadcrumbs.  Nice huh?  This is the situation I am in and I did get my hands dirty by writing an ASP.NET HttpModule to redirect date-based Radio URLs to DasBlog's URL format.

It's working pretty well except for the anchor part of URLs which is used by Radio to pinpoint a post in a page containing  multiple posts.  Since those anchors are not sent to the server, I can't map a Radio URL to a page dedicated to a single post.  Oh, well.  At least my permalinks are permalinks.

My next task in the blog transition is building a flexible RSS feed service framework while preserving old feed URLs.

There is something pathetic about getting enthusiastic over a geeky article on Christmas Eve but, if you are a .NET pervert, you should read Aleksandr Mikunov's Rewrite MSIL Code on the .NET Framework Profiling API.  The article doesn't say whether the technique still works under .NET 1.1, but it looks promising.

While mutating and hooking managed code is not exactly encourageable behavior, sometimes you have to do it and you can't argue with Gotta.

Scott Watermasysk asks what the hands-down best FTP tool is.  I have been using FileZilla for the past year and have been very happy with it.  It's fast, free, and trouble-free.  Don't let the 'zilla part bother you if you are a softie.

Speaking of FTP tools, here are some features I want in my FTP tool:

1. Persistent synchronization – intelligently monitor and update local directories to match remote directories or remote directories to match local directories.
2. Delta archives – automatically record and archive changes.
3. Integrity checker – detect illegal modifications or additions to remote directories.

Everytime I use XSLT, it leaves a really bad taste in my mind.  I just spent 3 hours writing an XSLT stylesheet for a new XML-based signature verification result format I created for my client recently.

The format itself is designed to capture data associated with signature verification so that it can be used as legal proof of verification at some later date.  This means capturing data hash, signature, certificates, and OCSP request/response pairs for each cert in the chain; basically bagging every scrap of data on the table.  End result should be routed automatically to a backend repository, but some customers will opt to stored them on local drives which means they need to view it locally.

That's where XSLT comes in.  By associating an XSLT stylesheet with the XML file, users can view the file with just a browser (well, IE).  It's a nice solution except writing XSLT can be a real pain in the ass.  Take one little step outside the simple stuff and you are in a jungle and it doesn't get better over time unless you use it everyday.  Since what I had to do involves fairly advanced XSLT, I was not in a good mood by the time I finished.

If you have a choice, avoid XSLT like the flu.  I didn't.  If you really have to, make sure you have a XSLT debugger.  XSLT being a declarative language is a joke.  It might look declarative, but if you do any serious work with it, you will start thinking procedurally in order to make sense of it.  Like I said, it's a joke.