October 1, 2020
More Bad Programming II
October 1, 2020
A while ago I said I couldn't find where the new Nivo Slider slideshow plugin (above) keeps its data. That's because it doesn't keep it anywhere. It generates each slideshow on the fly from scratch, with lord-knows how many database calls. I suspected that it was grossly inefficient, and I was right.
Since the original author has abandoned it, and I have already made changes, I decided to make it a lot better by adding my caching functionality to it. This was actually relatively easy. It is now lightning-fast after the first access. You have to wonder why they didn't do this in the first place, they already had a perfect place staked out to store the data, that was just wasting space in the databass. ** I even retained the capability for a random start slide, by changing that one line from server-side PHP to client-side javascript.
** Ha ha ha - databass! Get it? Get it? Awww ...
The quality of most computer programming is so bad, it's a wonder the whole world doesn't go up in flames. And what these poor kids get taught in universities is scary and sad. They teach how to write tricky code, but they don't teach how to write GOOD code. I know, I went back and went through it, after already working as an engineer for a few years. I honestly couldn't work up a lot of respect for most of my CompSci professors, let alone the awe that they are used-to from the kiddies. I think, most of them, if you gave them a broom and a dirty room, and came back in an hour, you'd have a fine theory on optimal sweeping patterns, and a dirty floor.
I also smartened up the caching logic so it doesn't blow out the whole cache over a little page edit. For a cache to be useful, you have to actually fill it up, otherwise, it is just more useless overhead.
Update:
To see what the cache is actually doing, I added a convenient debugging log that I can display in the control panel. As long as the site is actually running, I can view it right in the Dashboard. I should have done that a long time ago. The cache now only invalidates what it needs to when it needs to, not everything all the time. In a few days, it should fill up and become very useful. That was a little bit tricky, and the debugging log made it much easier.
Update:
I finally worked out all the details of cache filling and invalidation.
I had to make some compromises on the blog side for efficiency. If each blog post had its own cache, you would have to clear them all every time you add a new post. That defeats the purpose of caching. So instead, each blog post uses the cache of the main blog page. That one cache can be very easily cleared and refilled, and it has the side effect of making the blog caching blistering fast. The downside is that I can no longer light-up selected entries in the menu for the blog. What the hell am I talking about? Exactly - so what?
There are still some rare cases where caches that should be cleared are not. The best way to handle that is probably to empty the entire cache periodically and start over, which is probably not a bad idea in any case. I can also do it manually from the back end. Speaking of which, during all this caching business, I added some nice features to the back end for managing large numbers of pages and posts, which WordPress does rather clunkily.
Another University CompSci memory:
I was forced to take a graduate-level class that was a requirement because the university had just hired a big name and had to fill his classes, despite the fact that there was little interest in his specialty, and he didn't actually teach anything himself ( his English was marginal. ) His algorithm was a breakthrough at the time and widely publicized, but was quickly supplanted by better ones.
Out of curiosity, I decided to code-up his famous algorithm ( that nobody uses. ) I got to a tricky part, and went to the lesser prof who was actually teaching the class to see if he could help. He was taken aback, and finally admitted that he had never actually programmed the algorithm he was teaching! Never, not even out of curiosity! ( Although he had published theoretical papers on the subject. ) I was shocked. It was not that hard, I figured it out on my own.
Now I understand that at the PhD level, you are not going to be in the nitty-gritty of coding much. But if you're not going to keep one foot in the real world, you could at least dip your toe in once in a while. I could count the number of CS professors I've had, that I could hire and expect to do real work, on the fingers of one hand. ( There were a few that really were sharp, but just a few. ) I've had enough school, I never want to go back, except maybe for wood shop.
Sadly, the big professor died at a very young age. On the plus side, that may spare future generations from being forced to take a completely useless class.
