Recently I started experiencing a weird issue with my 2016 MacBook Pro.
I occasionally play Velocidrone FPV racing simulator on it. So far it worked fine. Although MacBook Pro doesn’t have enough power to run it in 4K resolution, it works reasonably well in 1280x1024.
However, this time it was a different story.
Once I started the game, the CPU went to 100% and the frame rate dropped from above 40FPS to one frame per few seconds. That lasted for about 30 seconds. Then everything sped back up, only to go back down in another 20 seconds. And so on.
When I looked at the CPU load chart it looked like this:
The CPU was consumed by “kernel_task” whatever that was
And this is what it looked like when it came back to normal:
No matter how much I tried, I wasn’t able to find a reason for that behaviour.
What was that mysterious “kernel task”? The search on the internet didn’t bring clarity. One thing was clear - something was hogging my CPU.
Another tech talk that struck me deeply - “Scaling Down” by Aslam Khan at Beauty in Code 2020 conference. It is about architecture complexity and domain complexity.
We have a tendency to over-complicate things when that complexity is not warranted. That is a trap that s very hard to find a way out of.
One of the quotes he had in his presentation which struck me was:
A complex system designed from scratch never works and cannot be patched up to make it work.
In my opinion, John Carmack is the greatest software engineer of our time. Unfortunately, he doesn’t talk much about what he does. His public appearances are limited to very occasional talks and his Twitter. @ID_AA_Carmack
This talk provides an insight in the way he thinks.
An interesting point he makes that resonated with me is that he “gets stuck” on ideas if he can’t test them.
He has lots of ideas. Some of them appear smart, other stupid. The only way for him to move on is to find a way to test them. The first step for him is to try to disprove an idea by theoretically scrutinising it. If he manages to disprove it - that’s great, he can move on. If not, he tries to execute the idea. Which means he tries a lot of stuff. Then he keeps what works and reject that doesn’t.
This site is built with Hugo static site generator. Being a static site, it doesn’t have a fancy back-end engine. No database either. Nothing breaks if left alone.
Still, Hugo team releases new versions from time to time. They add new features, fix some bugs and add new ones. I don’t upgrade to every new version. But occasionally I want to upgrade.
However, every time I do something breaks. Most often the thing that breaks is not on the front page, it somewhere else deep inside the site.
Time over time again I would upgrade the site and spin it up in a local environment. I would click around it, and everything would look ok. I’d push it to production. Then, days later, I would find a bug that affects quite a few pages. Because it is already in production, I would rush to fix it in the middle of the night till 3 am.
Having been through that a few time, I asked myself: can I do that better? Can I somehow test the entire site for regression and detect problems before I push the site into production?
