Hobby Projects

As I blogged heavily about a month ago I've been working on a wide variety of hobby projects again. I don't know how best to explain it, but the drive to work on these hobby projects comes in waves.

When Halo Infinite was released near 2 years ago - Leaf became my real drive and focus for an open source hobby project. Since this project exploded in popularity in comparison to the predecessors I had the drive to continue working on. It gained over the last year:

• Automatic image optimization from the upstream assets.
• Optimized top 100 leaderboards for medals
• Badges for achievements
• Detection of "farmers"

However, it struggles at the moment for larger changes because two of the most requested features are no easy task.

Dark Mode

Unfortunately my CSS library (Bulma) does not support this. Since I built Leaf with near zero custom CSS - introducing something as large as dark mode is holding me off.

Season Support in Top Ten

Querying a database that has grown past 50 million rows and still runs on a cheap Linode instance has its challenges. It takes nearly 11 hours to regenerate the top ten stats. This means that if I introduced per season stats (5 seasons at the moment) I'm looking at roughly 2.3 days per generation.

However, the stats should update daily so we have a problem. If I add indexes to make the site much faster at generation I'm looking at an extra 20-30gb of database space. I clearly am missing something why my indexes are so large, but doing any work with a database this big has become a challenge.

Thankfully in the terms of Leaf I made one choice that has helped immensely in preventing this project from decaying. It still has 100% code coverage, which means I have extreme confidence in every single change to the codebase.

I blogged about this before, but the main gain I've noticed with this project is it doesn't matter how long passes between working on it. I'm confident when I sit down it'll have the latest tools and still work. When I have un-merged pull requests I know exactly where I can start working.

So when I swapped to a different private PHP project that decayed a bit - I hit some extreme challenges.

It seemed using a latest version of Composer just didn't work with this project due to some namespace issues on some dependencies. So before I could even work on the thing I wanted to - it took a bit to get the project running again.

Ecosystems don't sleep and always move forward. Sometimes at the cost of breaking tools/programs that once worked in them. This is normal behavior, but it has two different extremes.

Python 2 to 3 was a horrible upgrade path. It fractured the community between Python 2 and Python 3 and took almost a decade to finally resolve itself.

Golang on the flip side has pledged to avoid breaking changes at all costs. They have an immense amount of automated tests that attempt to compile some of the earliest programs. This might grow to become some "cruft" over time, but the model of not breaking user-land is very much appreciated.

Thankfully for the project above I was only looking at a few hours of work and I had the CI/CD pipeline working again with fresh deploys. This project is far from getting to 100% code coverage to enable some automation like Leaf, but at least it deploys now.

I then started working on an older Android application that is privately shared between a few folks. Peeking the commits it had been over a year since a commit had came in, so I gave it a shot to build to my device.

* What went wrong:
Could not compile settings file 'settings.gradle'.
> startup failed:
  General error during semantic analysis: Unsupported class file major version 61

Of course my Java version was too new and Gradle refused to work on it. Upgrading Gradle without upgrading Gradle Tools led to a new issue, so then I had an upgrade going in progress for that.

That upgrade led to a requirement to adapt some build files, which led to a requirement to target modern SDK versions. It seems like the easier path would have been to downgrade to Java 8 or 11.

It seems the Android ecosystem decays fast and it's in your best interest to stay in line with the SDK changes and Gradle upgrades.

Finally I was working on another PHP project that did a partial transition between Gitlab and Github where the CD system was on Gitlab, but the CI system on Github.

This project was still using Bootstrap 4 which after the last few years of project development was pretty dated. However, instead of reaching for Tailwind I just did the upgrade to Bootstrap 5.

It went pretty well and outside of renaming a ton of classes from "left" to "start" and "right" to "end" - it looked great. I think this upgrade went pretty easy because the project was sitting at roughly 70% code coverage. This meant I had a good amount of confidence that nothing was broken after all these upgrades.

All in all - the drive to work on some hobby projects is back and I'm knocking out some bugs and upgrades.