After wrapping up my last Task for my server migration yesterday, I was left with my first actual totally free night in more weeks than I can count. Honestly, when did my life get this busy? I sure don’t remember stepping through that door.

One unfortunate side effect of the server migration was the breaking of my custom-written IRC bot. I don’t have a fracking clue what the problem is. It’s just like connecting to any other public IRC server in existence, and yet the bot fails to identify with NickServ and join its default channels.

Since debugging errors in that horrible mass of code that has slowly evolved into a tangled web of insanity over the course of 3 years is nearly impossible (think about 3,000 lines of code, all of which was written in about 10% stints seperated by 3 to 6 month breaks), I decided it was time to bite the bullet and set aside some time to do a major overhaul of the bot’s code.

Several of my goals for this rewrite include:

• Cleaner, more function-centric code.
• More modular and re-usable code.
• Adapting Wordpress’ magnificent options, actions and filters system of plugin APIs to make it easier to add and remove additional functionality.
• Centralizing administration - admin users, settings for connection, channels to join, etc. They should all be in the database, not just half of them.
• Add user registration to increase security for some of the user-based features, instead of assuming a user is who their nick says they are (ie: NickServ’d). Relies on above point.

So there it is. I actually wrote the base system (socket connection, database handle and socket looping) tonight, so at this point the bot will connect to the network and promptly get axed by the server when it fails to respond to the first ping request. Or at least it would if I had the back-end functions ready to pull the IRC connection settings from the database. Oh well, we’ll just assume it works…

Next up on my list is to map-out the structure of this code, splitting functions into appropriately named categories (ie: files) and deciding the best way to handle initial connections and their associated required responses versus later data that’s received and the possibility that we’ll act on it. Thus far, it’s looking easiest if I were simply to hand off everything to a do_action() statement that would, essentially, plugin-ize (is that a word?) the entire process.

If I work under that assumption, I should be able to start planning out my steps in different Tasks tomorrow morning before things get rev’d up at work and set myself up for about 3 good nights worth of work before I get to my real goal. Now, where do I find those 3 nights…?