Weighted Obsolescence: Phone book season

Few things annoy me quite like having phone books delivered to my house. There was a time when the phone book was pretty important --a time when taking a decent sized ad out in the yellow pages was the difference between a successful small business and a fire-sale. But between the internet and 411, phone books are obsolete now.

There are still a small number of people, mostly older ones, that consider this whole internet thing to be a fad. They would still prefer a printed phone book... old habits. But for most people the phone book is just a huge waste of paper. And they must be terribly expensive. Someone has to spend large amounts of time composing the contents, doing the layouts, and overseeing a massive printing and distributing operation. The books have to be printed, and that's a LOT of printing. Then they have to be physically delivered, which must represent a truly staggering cost since each one is bulky, heavy, and has to be shipped individually to a different location. Massive costs, and massive waste. Wouldn't it be better to just charge a nominal fee to people that WANT a printed phone book, and just not bother the rest of us?

Despite the irrelevance of phone books though, there is an active war in the business between several different companies. Each of them has, for reasons that still elude me, decided that the phone company isn't qualified to maintain and distribute the directory of phone numbers. Instead, these motards decided that they could do a better job and that it is their moral imperative to bring competition to the phone book market!

So every year, I get two or three huge bricks of useless paper delivered to my door. Well, more precisely, delivered to some random part of my yard that I probably won't go into for at least four or five months after the phone book has been delivered to it... not actually delivered to the door you know. For reasons even more screwed up than the basic business plan, all of these companies decided that they had to deliver their brand of awesomeness at the same time of year.

So last week I got three massive, but irrelevant phone books littering my yard. Of course, by the time I noticed two of them, they had been sitting there collecting water and bugs for a few days making them even more massive. The water and bugs don't make the book any more useless though, that would be an impossibility given their very nature.

Its bad enough that I have to dispose of these relics of hate, but what REALLY chaps my ass is this... I don't have a phone line. In fact, there is not and NEVER has been a phone line at my address. So WHY do I get three damned phone directories that I wouldn't need even if I did have a phone?

You guys seriously need to talk to Maxxum. At least they put half-naked girls on the cover of the unsolicited, irrelevant crap they drop off at my house.

Review - BlogEngine 1.2

I’ve put off reviewing BlogEngine until their development team finished up the 1.2 release. Up until now, I've been using incremental versions between the 1.1 and 1.2 release, but those were unstable at best. But now that 1.2 is out, and I’ve deployed two sites on it, I think its time for that review.

BlogEngine is an asp.net 2.0 application. As the name suggests  it is for people that want a blog site.

As a blog, BlogEngine is quite good. It provides the expected features: content postings (duh), comments, RSS/ATOM feed(s), archives, tagging, categorization, etc. It has a slew of extras like “gravatars”, content ratings, support for coComment, DZone, KickIt, and del.icio.us. And of course, BlogEngine takes care of pingbacks, trackbacks, custom tracking, endorsement (bLink), etc too.  The new version also has multi-author support, comment moderation, and several other nice touches.

In short, it does what a blog should do, and it does most of that very well.

Despite the name though, this is not really an “engine” in the classic software definition of the word. Part of the application could be described as an “engine” but it isn’t well designed for use within other applications. There are two source assemblies, one for the web site itself and the other is a class library. But the class library has some tight coupling and a reliance on the hosting asp.net web context.

The class-library contains the HttpHandlers and HttpModules that the web site uses to process the incoming requests. These don’t seem to really belong in the class library since they have questionable value to other web applications that might want to use the class library and would have no value at all in a non-web application. The class library also contains server controls that provide UI for the web site. Again, these have limited usefulness to other apps that might use the class library, and no use if the app isn’t a web application.

The most useful part of the engine would be the actual blog providers. These are responsible for building entity classes that represent the content of the blog, and persisting the content within a permanent data store. BlogEngine ships with an XML provider and a SQL Server provider. The providers could be useful to a wide variety of applications, but unfortunately there is still a heavy assumption of a web site context within the providers and the entity classes.  So, if you wanted to write a windows application to manage content within your blog, these providers and the entity classes will probably not work out too well for you without re-architecting to eliminate the reliance on web context.

Architecturally, I always have reservations when I see the provider design pattern being applied to an entire tier like this. Providers work great when applied to a specific and narrowly defined “service”, but providers used as whole tiers don’t scale very well, they overcomplicate things, and they can make maintenance or later extension much too difficult and cumbersome. Fortnatly BlogEngine's DAL is fairly small, so it doesn't suffer too much from these problems yet.

Having criticized the code, please let me say that the programmers that wrote this code are VERY good. This is not the work of armatures or idiots. The code is clean, neat, and organized. While I dislike how the code was architected, I have to acknowledge the development team’s skill and professionalism too. The code is very well written.

As for the web site itself, it follows a simplistic approach to skinning. The UI code is a mix of asp.net pages, master pages, user controls, and server controls. Quite a lot of the content displayed on the UI is generated by direct method calls with the output directly injected into the HTML. You’ll see a LOT more <%= GetSomeHtmlOutputAndPutItHere() %> type things within the pages than is typical in most asp.net apps. This simplicity gives a lot of freedom in skinning the application, but it also tends to get a little chaotic. The skins resembles php or classic asp apps a little more than I personally like.  You’ll have to use existing skins as a guide to build your own skins, and you wont get as much use from Visual Studio designers either.

On the plus side, the skinning is usually a matter of just editing a master page and two user controls within the theme folder. I’ve implemented two sites on BlogEngine now, and with both I found several things that required editing code outside the theme though. And some of those changes were in code within server controls from the class library assembly too. While this is fine with me, it does mean that the site ends of being hard-coded to the one theme I created. This isn't a problem, but it does indicate that the skinning appraoch could still use some work.

Another issue that I’ve not investigated is performance and scalability, but I suspect that this app would have trouble with large amounts of content. I suspect that the XML provider would suffer performance issues much sooner and more severely than the SQL provider would. But performance will be great for most blogs since they don't tend to get that large.

The verdict:

• If you want a good personal blog, and want to host it on your own server or web hosting account, then BlogEngine is a good choice. It will provides all the functionality you’d need and a few good extras too. It will not be too difficult to create a custom theme for your site as long as you are good with HTML/CSS and are somewhat familiar with asp.net.
  
• If you want code that you can use in your own application to help you with blog or blog-like functionality, then move along. Also, if you need multiple blogs hosted within one web site or have a high-volume blog, then BlogEngine is probably not for you.