On the Soapbox

As you've probably already figured out by the name, kBlog is a blogging system that I wrote. And if you're familiar with blogging, then you probably know that there are already a lot of blogging systems out there, from services like Blogger and LiveJournal to pre-packaged install-on-your-own-server systems like WordPress and many others. So, given that, why the heck did I bother to create kBlog? Because I can (i.e., for fun) and because it suits my needs. :)

For fun?

I needed something to do in my spare time. Watching movies was getting boring, so a fun personal programming project seemed like a good thing to do at the time. Although I've done a few large programming projects over the past couple of years, I haven't done a major web-based programming project since mid-2001 (I've done a few smallish web-based things, but nothing that required a major backend). That's a long time in the Internet world. So this was a chance for me to roll up my sleeves and get my hands dirty with relatively new things, like CSS for layout (not just for formatting), the idea of using a blog as the main component of a site (rather than a half-forgotten tacked-on novelty, which was what my circa-2001 blog was like), etc.

Necessity?

Getting my hopelessly-outdated behemoth of a website updated and modernized was always something that was on the back of my mind. I finally decided on just throwing the damn thing out and starting over from scratch, and using a blog as the core. Given the low volume of visitors, using a database seemed overkill. I wanted something lightweight and portable--something that I can easily throw onto just about any web server running Apache without changing much. And so I started to look at the many pre-packaged blog systems, but the few that used a non-database backend were unsuitable for me--either too ugly or didn't offer the kinds of customization and flexibility that I wanted. Ultimately, this contributed significantly to my decision to write my own blogging system.

Never say "How hard could it possibly be?"

Writing kBlog was certainly an interesting experience. I started out in late November, right before Thanksgiving. After finishing the backend and a mock-up of the layout in less than a week, I thought that this would be something that I could finish pretty quickly. Well, seeing as how it's now late January, it's not hard to see that I was a wee bit off on that estimate. Long story short, I hit a few snags, got sidetracked, and let the project collect dust on the shelf for over a month. I'll write about the development process in more depth in another post.

About kBlog

kBlog is written entirely in Perl because Perl is such a great and powerful language.* The Perl requirements are very lightweight: only the POSIX and XML::Simple modules (the latter will be removed for version 1.0) are used. Formatting is done entirely using CSS for layout (okay, that was a bitch to get right, no thanks to Microsoft). The backend data is stored in XML files, but this will change with version 1.0 (XML is used for the beta because I wanted to explore the viability of XML for storage, but it is too inefficient for my tastes). To speed things up in the unlikely event of a /.-like effect (I've actually been /.ed once, but that was also on a dedicated server and not this dinky thing sitting in my room), all served pages cached on the server side so that there is data-access and page-generation processing done only the first time a page is accessed by anyone. Whenever a change is made to the data, the cache is cleared. Since most /. effects involve only page serving and not much interaction (like comment-posting), I feel that this should be able to hold up fairly well.

* One of the things that changed since 2001 is what I call the "downfall" of Perl. It's being slowly supplanted by Python (and recently, by Ruby) as the scripting language of choice, so the reader may wonder why I stuck with a dinosaur like Perl. The first major downside to Perl is that it's difficult for people to read/parse and thus not suitable for team projects, enterprise settings, or other situations where code maintenance is important. Fortunately, I am fluent enough in Perl that I can even think in it (that's what happens when you've used a language for nearly a decade), that downside didn't affect me enough to choose another language. The other downside is that the OO component of Perl is somewhat tacked-on and a bit awkward, but there's no need for OO in a project such as this.