Recently I have been revisiting my abandoned or neglected projects, including my VWJL (Virtual World Judo League) project, where the last commit seems to have been from 2004 and 2003. The VWJL was a grand rewrite of another Judo simulation game I had run on my website. And like all grand rewrites… it failed. I have not worked on the code since 2004, the following is my experience at working with 2003/2004 Lance’s code.

Getting started.

Problem one was that the original code is very old perl5 .cgi files. But I didn’t have a working LAMP stack on my laptop. A quick explore of the internet turned up various LAMP (with PHP) stacks, but nothing that seems to suit my perl need.

Then a colleague at my $dayjob reminded me about Miyagawa’s plack efforts, and a quick browse one evening let me to Plack::App::CGIBin

With Plack::App::CGIBin I was able to wrap the entire directory of .cgi files serve then with plackup.

Like so:

plackup -R ./ -MPlack::App::CGIBin -e ‘Plack::App::CGIBin->new(root => “/media/mac/Sites/vwjl”)->to_app’

The “-R” reloads the files when they change so, every time I save my edits the I can see it in the browser.

Style… or lack there of.

On first impressions… “Who wrote this rubbish!?!?”.

I am very pleased to say that 2017 Lance and 2004 Lance are very different developers and 2017 Lance is a lot cleaner coder than 2004 Lance.

I discovered I was a very big fan of commenting as many lines of code as humanly possible, Lots of comments saying what the line did. Not “why” literally things like comments on use lines saying that “use DBI;” allows me to use the DBI module.

Of course 2004 Lance was a huge fan of global variables as well. Putting all your variables at the top of the file and using and modifying them in the subs as you go… nice!

By the same token, I gave myself some credit for not writing all my html inside the .cgi scripts manually. Oh no, that would be daft! So I used the CGI module to do that for me:

print h1(‘VWJL’);

print p(‘Home page’);

Sigh…

Rule one of my development process back in 2004 seemed to be “RY”, as opposed to the dreadful “DRY” principle that swamps modern development. HUGE amount of repetition, including reading data from the “database” (more on that later) and rather than passing that data into teh display sub, nah, lets just pass the ID, then get it again in the sub and then display it! Excellent.

Database

So… I mentioned DBI earlier, but I didn’t mention the “AnyData” module. So back in 2004 I don’t think I had access to an actual database, so I used a module called “AnyData” which let me use .csv (yes comma separated value) files for storage using SQL commands via DBI. It is kinda lucky  this project never got popular; pretty sure locking might have been an issue… assuming Anydata did/does any form of locking.

Enjoying tidying up!

So, after having got the site up and running and cleaning up a little I took a look and started making changes. So I stripped a bunch of comments out and started to clean up the scripts enough to get them working.

After that I started making more fundamental improvements, reducing the repetition, getting rid of teh global variables, etc.

I have now made a bunch of commits and it’s almost at a stage where I think I can move forward. The code did create a reasonable schema for a Judoka and ideas on how you could simulate a Judo contest based on the skills, strengths and techniques of Judo.

I have started to pull some of the repeated code out into the modules where I can re-use them rather than having the same code repeated everywhere.

I have started (just) to write some tests.

I will post more updates as I go along.

Summary

In development, we always say that you are not a real developer until you have looked at your own old code and been embarrassed. Looking at my 2004 code, I have to say I am pleased I have had 12 years to hone my coding. I am also pleased to be able to say that my code is better now than it was then.

I was really pleased to find a way to get old .cgi code running locally for rapid/easy development. I had explored and even started looking at setting up a VM or just FTPing the code up to a shared server.

It has been educational to look at truly awful code I wrote myself and force myself to rewrite it. Sometimes in $dayjobs it’s too easy to look at code you don’t like and start saying unhelpful things like “who wrote this garbage?” or “who ever wrote this was an idiot!”.

Looking at my own code, I know it was the best code I could write at the time. I vaguely remember the effort I put in and how proud I was when it worked. 2004 Lance was doing the best he could and even though it is far from elegant; it actually worked and people did actually use it.

So I hope it is giving me some perspective for my $dayjob too. I hope it means the next time I read something I don’t like that I remember that this too was written by a old version of the person. That at the time it was the best they could do and that it worked. That despite today it looking bad, yesterday it was good code.

Wish me luck folks, and if you’d like to help write a Judo simulation game with me (in perl5) let me know.

Lance

Categories: Uncategorized

Lance