Simplify for (Kusaba) X

In other entries I’ve talked about how much of a mess the site’s source code can seem like—a constant lack of comments, duplicated code instead of functions, unclear variable names, functionality spread across multiple files without clear relationships and so forth. It makes working on new things daunting as not only do you have to write your code, but you have to figure out where in that jumbled mess it belongs. As I’ve added stuff, I’ve added comments and made notes of how files and code relate to one another.  

Still, there’s one obvious way make things easier as you go along: simplify and rewrite where needed. A lot of the time I’ve spend working on things behind the scenes has involved stripping out and otherwise getting rid of a lot of code. Functionalities that were half-implemented, become broken over time and things we outright don’t use on THP. There’s the obvious example of the oekaki board that was fiddly even back in 2011 and finally became unservicable with newer versions of software over the years. But other than that there’s tons and tons of very niche and specific bits of code that are just outright irrelevant.  

Removing them adds clarity. Makes files shorter and easier to read. It’s one less variable that you have to worry about when passing into a function or invoking a class. With less moving parts, as it were, it’s easier to modify the rest. Or add new things for that matter.  

The problem is that you can’t just hack away at all this code like you would tangled vines with a machete. Due to the aforementioned messy and intertwined existing code, getting rid of things is more akin to plucking hairs with tweezers—it’s painful and if you pluck the wrong one, everything else can start looking off. So you have to dismantle these useless bits of code slowly, methodically, finding every single instance of a reference across multiple files and working out if anything else depends on it and how altering will affect the overall code. Being overzealous and changing too much, too quickly, can mean that everything about the board breaks as whole files can no longer be parsed correctly by the php interpreter.  

Troubleshooting that can be straightforward, sometimes. Web servers can occasionally offer exact lines in exact files where errors occurred. It’s just that when everything is so interconnected, it’s not always obvious that there’s deeper underlying problems at stake and even if you make sure the format of input is alright, a function in another file might be the actual culprit in breaking everything. All because it had no conditional statement on what to do in case a variable was null or because its conditional statement always assumed one thing (‘if $whatever==10 {’ and there’s no ‘}else{‘).

Hours of work can seem useless when you’re not sure why things aren’t happening the way they should be. There’s only so much actual debuggers can do. Some of it comes down to scanning files manually, looking for anything that feels off.  

So, I suppose if there’s any one point I’m trying to make about all this is that this sort of work is very time-intensive. In order to avoid breakages I have to edit little by little, bit by bit, plucking with tweezers. If there’s any possibility of something I’m changing affecting other bits of code (basically anything but the template files that output html), I go through a somewhat thorough testing process. In my own local environment, I test out whether posting still works, if images are uploaded ok, if you can delete things, if cookies are set, if you can access management tools etc etc. Depending on what I’m changing, I may focus on one aspect of testing more than the other but the bottom line is that it’s always going to be tasking.  

This isn’t the sort of thing I can outsource to others, either. When you pay people by the hour, you have lower returns on things that take a lot of man hours without adding anything new. Well, I don’t really mind the work when I space it out but it’s something that definitely does slow down the pace of work on the site, overall. In the following image you can see the type of changes I’m talking about and do note that in many cases removing things can mean changing hundreds of line of code (gettext was for translating UI on the site, and had hundreds of entries in the management section alone).  

As an example, APC has been unmaintained for years now.

We’re getting there. Things are getting simpler and the code is getting easier to manipulate. In the meanwhile, I do work on new code when I can. Aside from the mystery box, the most obvious example that you can appreciate is the implementation of new captcha (see for yourself on coriander, where it’s enabled but the board is locked anyhow). Yeah, we haven’t really needed to use captcha and it’s not something that I would put by default on the boards. But it’s something that may be necessary in case of determined spammers (over the years I’ve had to deal with them in other ways) one day.  

The old Google recaptcha will no longer work come April and we would have to upgrade to the newer system. I really don’t feel like relying on Google for anything and I’m unimpressed by the fact that you have to register an API key to use the service. The new captcha system is something that’s hosted on the site itself and doesn’t depend on any third parties to serve content. No one else that can track you or sniff your data. I’ve always been a privacy-focused person and a libre software advocate so this solution kills two birds with one stone. There’s still some kinks to iron out, like getting rid of inline scripts or changing colors/wordlists but that’s relatively minor and can wait at the bottom of my to do list. For the moment, I’m comforted that this is working properly and something that can be used if shit ever hits the fan.

There's a few other small things that have been done over the last few weeks. The reply delay when you post/create a new thread has been reworked internally. Checking for just posts (not threads) had been broken in the original board software. I ended up keeping the two separate checks in a single function. A practical result is that I make the delay for new threads less punishing without compromising the ability to fight would-be spammers. 

I'm a little behind my initial schedule to roll out some other changes that I in my testing branches, which should also be pretty exciting once they're out. I've yet to make a few decisions about some things that are currently broken on the site (for example watched threads and something in the management section) and so that needs sorting out too. It'll probably start coming into place near the end of this month, at the earliest, since I won't have that much time to code in the next week or so. 

If you want to guess what it is, here's a hint: it's something big but not something you normally notice, is complex but easy to parse, optional but definitely improves usability.

Until next time, take it easy guys!