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.

Stupid Crusade - Block Firefox to protect your revenue!

Seems someone out there really thinks that a browser that blocks ads is theft. So they've outright blocked all Mozilla Firefox browsers and are advocating others do the same.

Software that blocks all advertisement is an infringement of the rights of web site owners and developers. Numerous web sites exist in order to provide quality content in exchange for displaying ads. Accessing the content while blocking the ads, therefore would be no less than stealing.

Their message gets richer too... so check out the entire thing:

http://whyfirefoxisblocked.com/

Never mind that ad-blocking is available for just about any browser, and most Mozilla users are savvy enough to work around being blocked... what boggles my mind is how these people think that blocking an entire browser will increase their ad revenue?

Of course, it seems clear that message is intended to drag the users into the politics of the issue, and is not an honest attempt to increase ad revenue. Sadly for them though, most users that see this message are going to be solidly on the other side of the argument... and pissed for being blocked!

Way to gain sympathy there guys!

GetOffMyCase!

One of those tired old arguments you see crop up again and again among programmers is that of case sensitivity in programming languages. The general trend currently seems to be that most are advocating a move towards case insensitive languages. These people tend to call case sensitivity a legacy of the “old” days. They then go on to cite that modern compilers have long been able to save us from the case sensitive buggy-man. Perversely the popularity of case sensitive languages seems to be rising while popularity of case insensitive ones is falling... and no, I have no empirical evidence of this, just something that seems true based on my own observations over many years in the field.

The arguments against case sensitivity range a bit, but one common complaint is that mistakes in case cause hard to detect errors or lead to having two different functions whose name differs only in capitalization. Another common complaint is that comparing strings or working with things that are strings in case sensitive languages often leads to bad behavior, especially when dealing with file paths or URLs where the underlying platform is not case sensitive but the language itself is.

Look, I’ll grant a couple of things:

• Scripting languages or any language that makes heavy use of late binding should avoid being case sensitive. JavaScript in particular would be a LOT better if it were not case sensitive. In fact, JavaScript is what I like to call a case-destructive language.
   
• String comparisons in ANY language should, by default, use case insensitive comparisons unless explicitly told otherwise. Most languages provide a mechanism to perform case sensitive or insensitive comparisons, but most C based languages default to doing a case sensitive match. Even C# (my language of choice) is guilty of this.

While there are a couple of points these advocates make that I can agree with, I disagree overall that case insensitivity is “better”. In case sensitive languages, after a little exposure, the use of case becomes a useful tool on its own.

Once you understand the conventions of the language you can usually tell a LOT about what is going on in code just by observing which case is being used.

For example, Identifiers in C# are camel cased when they are local variables, private fields or method parameters.  Pascal case is used for public members, class names, etc. The use of Case to distinguish meaning in C# is generally very consistent from one developer to another. The adherence to good naming conventions is partially due to the case sensitivity of the language itself, and is not a work around in spite of case sensitivity.

When I see something called myName in C# I KNOW I’m dealing with a local variable or private member. When I see MyName I know I’m dealing with a public member.

This is NOT confusing to me or most C# developers. On the contrary, it is  quite elegant and we get used to noticing the case of identifiers, and the case used tells us instantly something useful about the code.

But when I deal with VB code, I have to play guessing games when I see myName1 and myName2. Sure, conventions help some there too, but the conventions always feel like sloppy workarounds where the sole purpose is to support case insensitivity.

Of course, most of this relies on a decent understanding of the conventions of the language and the programmer being competent enough to follow those conventions. I’ve been working in C# for many years and I’ve never had serious problems with case induced errors. Sure, occasionally I have made a case related error, but I can’t say that this happens more often than the mistakes I’ve made in VB due to inconsistent and awkward naming. In both languages those kinds of mistakes usually get caught by the compiler or the IDE quickly.

Case sensitive languages have another side effect though, and in my mind this is THE most important thing. Case sensitivity makes programmers pay attention to detail. This may seem like a very simple thing, but attention to details is THE skill that I’ve discovered marks the difference between a decent programmer and a great one.

Local Coffee Shops Suck - Go Starbucks!

I have many friends and acquaintances that "hate Starbucks". Hating Starbucks might even be more popular than hating Paris Hilton.

They all have their pet complains, usually about some isolated unfair trade practices or injustice carried out by some mid-level area manager or something. The argument always trends to wrap up with how local coffee shops suffer when Starbucks comes to town (the Wal-Mart argument).

But the sad fact of it is that any company that size will have ass-hats that occasionally do bad things. I try not to hold that against a company unless that kind of behavior becomes the executive policy of the company as a whole (which is why I don't hate Wal-Mart or Starbucks but do hate Disney and Apple).

Anyway...

Let me tell you why Starbucks kicks ass... aside from the fact that they actually serve a decent enough cup of coffee.

The reason Starbucks kicks ass is because they understand this that you can't stir a 20oz cup of hot liquid with a fucking 4 inch tall plastic stick!

Starbucks has big sticks that fit down into the cup all the way to the bottom without burning your fingers! Out of dozens of local shops I've been to in dozens of towns, maybe one or two have had sticks that are appropriate for their larger size cups.

You'd think that if your fucking business IS coffee, then you'd take the time to notice that 4 inches of stick does NOT-the-fuck fit into 10 inches of cup!

How god-damned hard is it to understand ?!?!

See, Starbucks pays attention to those little details.

They provide this level of service in EVERY store.

So... I don't have to wonder if I'll have a way to stir my shit when I get to Starbucks because ALL of their shops have good sticks.

I don't have to wonder if I'll be stuck trying to open half a dozen tiny little packets of sugar (which is always messy) because Starbucks has both packets AND a free-pour canister of sugar on the counter (I know... almost unbelievable!)

That is why Starbucks is killing your local coffee shop.  

VS 2008 and .NET 3.5 Beta 2 Released

VS 2008 and .NET 3.5 Beta 2 Released - ScottGu's Blog

Been waiting on this for a while :) I haven't figured out if it shipped with a go-live license yet though.

I'm particularly eager to get a good look at the Team System stuff in 2008. I've been putting off testing of the beta team system stuff until it got more stable (deploying team server is a pain, even if you are using a virtual server).

Assuming this does have a go-live license, it will finally allow me to put together an update for the CCK project on the new platform too. More on that later...

Microsoft Robotics Studio

Microsoft Robotics Studio

Microsoft is a REALLY big company. Even for those of us that work in IT and make our livings off Microsoft's technologies exclusively, they still sometimes manage to slip products and technologies by us... but rarely does Microsoft have an entire development platform that manages to elude my notice.

I just came across this one. I wasn't even aware Microsoft was doing anything in robotics, much less actually had a development platform on the market.

Reddnet now powered by BlogEngine.net

I've replaced the reddnet site with a new blogging application based on the BlogEngine code base.

Most of the scribbles section made it over to the new application, but the old posts' formatting remains a mess. I didn't move the old comments or ratings over though. I'll be fixing the formatting, tagging, and categorization of the posts over the next few weeks.

BlogEngine is a pretty neat community application. It is very simplistic in scope compared to the CSK code-base that reddnet previously used, but simplicity is a good thing since I have very limited time to manage my personal site. I will of course switch reddnet over to the CCK code-base once I've finished writing it :)

I'll be reviewing BlogEngine.net here in the near future.