The Challenges Of A Code Monkey

I haven’t been able to post to Lockergnome, or my own site, as much as I’ve wanted to in these past few days. You see, for the past week or so I’ve been converting from one host to another - from PowWeb to a temporary home. During this transitional period, I’ve had to seriously rework my content management system, which I had built from the ground up in PHP; however, I had not anticipated any problems that might arise if and when I had to switch hosts, and simply coded on my merry way.

That was a huge mistake.

While the main site was not complex (a simple template system that I patched together in a couple of days), the backend was heavily dependent upon some of the features that PowWeb offered; for example, PowWeb would forward unknown subdomains to the main domain, so if you wented to go to reviews.geekstreak.com, you were actually on www.geekstreak.com, but with a different subdomain, which aided in MySQL queries.

It’s a small problem now to handle (I just create a new subdomain), but it’s those small problems that compounded into one huge problem: how in the hell do I transfer this highly machine-dependent CMS to another machine without breaking the damn thing? My usual approach to attack the problem until it’s solved just wouldn’t cut it, because getting the site up and running as fast as possible was essential.

So I sat back, took a deep breath, and decided to take my time. I decided that the best option would be to take this project on in three separate phases:

1 - Get the site functional again

This first phase was essential, as the Web site would still be running. This would keep the users of the site happy, as well as me, since I wouldn’t have to worry about a flood of “your site is down” e-mails. During this phase, the site on the old host would remain up until I could confirm that the site was functional on the users’ end.

For the most part, this was simply a matter of transferring files from one host to another, reconfiguring some scripts, and creating a whole ton of subdomains (I think we’re up to 12); however, there are several issues that arose during this process:

The comments system was broken. It actually worked fine on PowWeb, but the comments system relied on the PHP configuration, which allowed scripts to send headers whenever they darn well pleased. I had labeled this as a “must-fix” issue, since a blog isn’t much of a blog without user comments.

Trackbacks were broken as well. Don’t get me wrong: the original trackback system didn’t work, since Web sites couldn’t ping geekstreak.com with trackback information; however, the reverse did work as I was able to send trackbacks to other sites. Since this was not an essential feature, I placed on the “to-do” list, and will get to it during phase 2.

Finally, there are various errors in the MySQL database that cause some odd icons to appear. This one is a pain in the ass since I can’t be sure which icons are representing what, so I can’t write a script to replace them; however, it’s only a minor inconvenience to the users, so this was placed on the backburner until I could get the rest of the site up and running.

With all of the bugs placed in a queue, I looked at them and went to work, systematically fixing each one until it “just works” from a user’s point of view. It actually didn’t take too long to sort out most of the end-user issues (only about two days, tops); however, it was something that needed to be done.

So, now I had a site that, from a user’s point of view, worked - on to phase two.

2 - Rewrite the code

This is the phase where I’m currently stuck. I say stuck because rewriting code is a pretty ugly thing to do: you’ve got a well-established system that just isn’t susceptible to having large parts of its code rewritten.

I had made plans, drawn diagrams, and even went so far as to complete a flow chart; however, none of it seemed right: I would still be hacking together some seriously unorganized code, which could lead to serious security issues, and future maintenance nightmares. To top that off, the nice little template system I had created would have to be scrapped in favor of integrating the HTML with PHP - something I hate. I also wanted to add several new features to the site, so adding those features to a quagmire of code did not seem like a “fun time.”

Since I’ve decided on scrapping the old code for new, I had a couple of choices. For starters, I could use a well-established content management system like Moveable Type or WordPress, however, transferring my old database over to theirs would be painful at best, and downright suicidal at worst. Another option I had was to write my own system (again).

I chose to write my own code.

Since I’ll be building this beast from the ground up, I’ll need a very clear path, otherwise the project could get bogged down in feature creep. So, I made a list of must have, wanted, and unimportant features. I’m not going to bore you with that list (especially since I want to keep some of the planned features hidden until they’re implemented), but you can imagine what it includes.

This is where my story ends, however, I still have a third phase to go through.

3 - Audit and Convert

Originally, I had planned on an audit of the old code, which worried me because it was such a mess and a maintenance nightmare. Now that I’ll be auditing new code - with new features - I’m worried even more. While it shouldn’t be as much of a hassle as it would’ve been with the old code, new code means new points of attack, which means that the methods I used earlier in the Web site’s life will either have to be reworked or scrapped altogether in favor of new testing methods.

Apart from ideas and theories, I’ve not worked out how this audit is going to take place. Obviously, I don’t want to do this on the main site working on the main database, but I also don’t want this phase to take so long that the Web site will languish as a result of the added workload.

After the code audit, I’ll have to actually convert the site from using the old system to the new system. This is the only phase of the project where I anticipate any downtime caused by the upgrades. As I’ll have to actually transfer everything over in one fell swoop.

While simply uploading new files to a server doesn’t sound like that much of a big deal, it can be cause for concern, as problems can (and always manage to) arise.

Beyond that, I have not had the time to give this project much thought; however, if you’re an aspiring programmer, you may want to take this little adventure into account and realize that future maintenance of code can be just as important as getting the job done. So, plan your project’s life ahead of time - from initial use, to maintenance, to decommissioning - and you’ll save yourself a huge headache when it comes time to rewrite or replace your code.

[Provided by Geekstreak]