Sedition·code

Sedition 3.0

Wednesday, 23 February 2011—subject to ongoing, unnanounced updates

Modern Perl Modern Perl at Powell’s, Modern Perl at Barnes and Noble, Modern Perl at Amazon.com, or download Modern Perl for free and then recommend it to your friends, write a great review, or otherwise spread the word.

Looks like it’s time for a rewrite.

Barnaby Hazen in regards to any number of things I’ve written over the years

Version 0.01 of the site can be called the hand rolled pages in plain HTML I did back in 1998. Did you know an HTML form can have a submit action to email without CGI? Those were the days.

Version 1.0 would be the first Template based version which came on the heels of first version of the Devil’s Dictionary X™ in 2001, IIRC.

Version 2.0, the current as of this date, is the Catalyst rewrite I did in 2006, in just about a month, after a fair amount of experience with the framework. Holy cats… I’ve been writing Catalyst for 6 years.

The 2.0 code is fine and doing great all things considered. It’s serving up to 180,000 visitors a couple million resources a month without any custom tuning or maintenance. It has, however, many problems.

  • Poorly abstracted. It follows early Catalyst design patterns and big sections are just where I wang it.
  • Too customized in too many small places. Just one example: I wrote the access control stuff. The modern plugins for it are far better.
  • No tests. This is so, so, so wrong… And so, so, so easy to fall into with your own code.
  • No docs. There are features I don’t even remember. I can’t make changes or additions sanely without reading pretty much all the code and templates.
  • As a consequence of several of the points above, adding features is dangerous and increasingly hacky.

The problem with a rewrite

I remember distinctly in 1990 looking down at the first poem of mine which I could objectively read and say, Holy fuck, that is a great poem… This followed, naturally, by I’m now a great poet. Let the ink flow!

I did not complete another poem for months and didn’t write many worth reading for a year and the following year was a painful exercise in learning to write as something other than an act of Muse given grace. Success had paralyzed me. Every time I wrote three words after each other, I’d analyze them: genius or shite. Since the conclusion was never genius, I stopped at the fourth word.

I’ve tried a few times times to abstract this site software into a general blog package. Each failed to be genius at the first stroke so each lies rotting in RCS.

This site code isn’t genius. It’s, mostly, workaday code. The problem is, I know what superior code looks like and how it’s coupled with tests, documents, and deployment flexibility. This site lacks those things. This site has features and abilities which I don’t even remember until I read source code because I wrote it four years ago on a lark and ended up not using it or burying it in a crontab somewhere.

The design suffered the same issue. The current code is quite specific; not generalized. The rewrites attempted to be, perhaps, over generalized, refusing to make necessary choices and thus prolonging the process in the quest for a perfect design.

The benefits of a rewrite

The functionality and the code itself can be documented. The code can be tested and expanded much more easily. The process of the rewrite can be documented here for the edification of others and myself when I forget something. The code can be released and shared. If it’s good enough, it might even repay in contracting work specific to it. It will be a nice résumé bullet.

The best reason to do it publicly is that it will expose shortcomings in the current software.

Looks like it’s time for a rewrite.