Blog Specs

Between work and Patrick, I haven’t had much time to blog. Plus, I’ve been rethinking the backend of this blog. Thus, the more I blog now, the more I’ll have to migrate later. <sigh>

I want to upgrade by backend so I can more easily keep up with Don and Sam and changes in blogspace. Here is the list of blog-related enhancements I want to make:

What am I missing? Is there a definitive list of all the blog related specs?

I’m Indexed, Therefore I Am

Feedster’s blog indicates they have been “heavily revising the crawler architecture“. I would guess they’ve actually been revising the design (a rant for another time). Either way, it’s nice to see they are indexing me once again. Thanks for getting that fixed, Scott! Also, I slightly updated my blogroll. Mostly adds, one or two subtractions.

Tools, tools and more tools

I don’t know who pointed it out to me, but I dig Fabrice’s list of .NET Tools. I added a link to that page from my paltry list of tools.

varchar(???)

I’m thinking about redoing the backend of this website. I started to do pingback/trackback support and got discouraged by the fact that I would again have to pick an arbitrary length for the database columns. Of all the annoyances with databases, that’s my biggest pet peeve. Maybe SQL “Yukon” with it’s ability to natively store XML will solve this problem.

However, until then, I need to use something to store my entries in. BlogX uses XML files, which seems like trading one evil for another. Picking a max length for a column is annoying, but I don’t relish rolling my own database. Bamboo.Prevalence is interesting, but I don’t like the fact that everything is kept in memory all the time. I’ve read the Prevalence Skeptical FAQ with their entries on Breakthroughs in Memory Technology (which haven’t happened yet) and their Scalability Test Results (testing a paltry 1 million rows in a single table – though obviously DevHawk has much less data than that) and I’m still skeptical.

I am impressed with the implementation of Prevalance – especially the transparent engine feature of Bamboo. From what I can tell from the outside, it serializes the methods calls against the Prevalyent (?) object so on app restart, the engine can return to when it left off. It also can serialize the Prevalyent object itself for snapshot purposes. Simple, but elegant – except for the memory usage. I tested a simple Bamboo.Prevalence app with a snapshot of DevHawk’s database. The entry list wasn’t too bad but the referrals list was huge – an order of magnitude bigger in memory than the entry list! Given that I do nothing with the referrals list but archive it keeping it in memory seems like a waste. What I want is something like Prevalence but with more flexibility with regard to memory usage. I only want to keep the past month’s worth of entries and the past day’s worth of referrals in memory all the time.

I’m thinking that you could build something similar to Prevalance that used Weak References to enable the GC to clean up memory of infrequently used objects but then use Proxies to reload them transparently from disk on command. Resurrection could be used to avoid collecting objects that are likely to be used in the near future (i.e. recent entries).

Discrimination against the Bozos

The truth is that I discriminate against irrational people. If I eventually find out that someone who I have discussions or debates with makes irrational arguments to defend a personal bias then I tend to pigeon-hole this person in my mind and set up a mental note to redirect future commentary by this person to my mental “Deleted Items” folder unless those comments are referenced by some other person whose credibility is not suspect. [Dare Obasanjo aka Carnage4Life]

I like how Jim McCarthy described this in his landmark book Dynamics of Software Development: Flipping the Bozo Bit.

And on the subject of must reads from Jim McCarthy, check out Software for Your Head and the Core Protocols v1.0.