Modernization and streamlining

There comes a time where old code becomes more than just unwieldy. It starts to become incompatible with new technology and it even starts to fail and produce errors. There’s usually a couple of solutions to that: never update, alter enough code that it can keep chugging along, or rewrite from scratch. You get the first one a lot on legacy systems that are isolated from the world, like ICBM silos. The second is where a lot of programmers make bank, think COBOL in bank computing systems. And the third is usually impractical unless you have a lot of resources.  

THP and its board software, Kusaba X, mostly falls into the second category. Over the years, there have been a lot of new developments in the underlying technologies that keep the site chugging along. Things like MariaDB overtaking mysql, PHP getting new versions and HTML and CSS getting new specs. As the site admin I’ve made sure to alter where needed, making sure things keep on working.  

For the most part this hasn’t been that much trouble, as a lot of new developments have kept backwards compatibility. It’s just a matter of reading release notes and a migration guide and putting in a few hours’ work. Not too bad in the grand scheme of things.  

There are a few exceptions. When syntax changes too much and libraries are deprecated, you’re forced to either drop features or rewrite from scratch. This is why the drawing board on the site had to be dropped. It depended on code that was written for PHP3—a version that was initially released nearly 20 years ago! At a certain point you have to break compatibility to move on which sucks for /i/ but is entirely understandable from a developer’s perspective. I tried to see if I could salvage and update the code but I ended up more or less starting to rewrite from scratch. Once I realized that, I decided to stop working on it and simply drop the board since it wasn’t popular to begin with (most months saw no posts and only a handful of views). It’s something that I’d like to get back to some day, but it’s unlikely that it’ll be anytime soon.  

In the past few weeks, I’ve updated some other legacy code that was long overdue. The template engine the board software uses was almost a decade old and so I took it upon myself to research either a replacement or upgrade. Luckily, the original project was forked and continued. So, after reading up on all the changes they’ve made on the years, I edited a lot of files on our end to account for the new idiosyncrasies and syntax. It might not seem like much, but it feels good to be up-to-date, as it makes modifying and adding my own code much less painful when I have current resources and community I can consult. 

Several other libraries needed for some functions have also been updated or replaced wherever possible and it’s still an ongoing process. As it’s something that usually requires a lot of careful reading and testing, progress is slow. I’ve used this work as an excuse to streamline a few bits and bobs, including user-side scripts so it’s been a generally productive experience.  

There’s still a few really annoying things I want to get rid of, including the use of the protoaculous js framework. I’d like to replace it with stuff I’ve written myself but as I first have to figure out all the places where it’s used. Then see what are realistic replacement options and workarounds so that site functionality isn’t compromised. I’ve got to dedicate at least a whole weekend to this and haven’t had the time to wrap my head around all the code since, as usual, there isn’t really anything in the way of comments in the site code to help guide me. I have to map things out through reading uncommented source code, intuition, and trial and error.  

In the end, all of this is not stuff that users will likely notice. By some metrics the site is more responsive and lighter on resources but we’re talking about milliseconds and only a few Kbs in most cases. It adds up, though, particularly if you’re on a slow connection. That said, the greatest benefit is that removing old bits helps keep me sane and grants me more insight on the inner workings of it all. Adding my own comments and refactoring code where necessary makes future changes all the easier.  

I wish I could talk about some of the sexier stuff I’m working on (new features, that is) but some of that depends of having logical and well-understood fundamentals before implementing. Not to mention fixing a few annoying bugs that have become obvious as I look through code. Next time I think I’ll talk a little more about the state of the site code itself and trying to divine the design philosophy behind it. Hopefully this hasn’t been too dry, let me know if I need to spice these posts up a bit.