lolwtf

The above is probably your face right now. Understandably so because the site looks very different than it used to.

Hi, hello, welcome to the new kalecreates.com. New year, new site, same me. So, what’s changed exactly? Well, the short answer to that is “yes”.

Let’s do a quick rundown of what’s changed, both behind the scenes and not:

  • no longer using Flask, using Hugo
  • no longer run by Python script
  • no longer a cobbled together mess of code, gum, and paperclips
  • no longer using outdated themes and libraries

So, I realized I never actually got around to making a post about what ran the site before, but here’s a short and to the point of how it worked:
I wrote a Python script that utilized Frozen-Flask, Flask, and a few other libraries to take Markdown files and turn them into HTML files and save essentially an in-place snapshot of the files and serve that up as a static site. It’s uh… a little more complicated than that sorta, but that’s like 90% of how it worked.

There was nothing wrong with how it worked, but I was running into issues more often than I wanted to I started looking for an alternative. Some of the issues that were plaguing the old site were the fact that I was relying on BootStrap as my CSS framework. I like BootStrap, there’s nothing wrong with it, but with BootStrap you have to understand that if a major release comes around and you’re relying on certain classes that are updated or no longer function how they did, you’re going to encounter a lot of issues. This is exactly what happened when I updated from BootStrap 5.0 to 5.3. I was also relying on another JavaScript framework called DataTablesJS to render the list of posts. It’s still updated, it still gets used, but it’s another puzzle piece that could end up becoming a potential issue. Couple that with the libraries required on the Python end, and you run into over-reliance on external libraries that you have little to no control over. So what’s the solution? Rely on a single framework that you have little to no control over! I kid, I kid. I mean, it’s true, but I kid.

So what IS Hugo? Hugo is basically what I needed all along with the old setup. It takes all of the stuff I had to figure out manually and throw libraries at and just does it under the hood using Go. It’s effectively a one stop shop for static site generation. And it does it damn well. It mostly appealed to me for a few reasons: it’s boring, it’s simple, and it just does what it says it will do. I don’t need all these fancy bells and whistles that CMS (content management systems - think WordPress) comes with, I don’t need all the hassle of maintaining a script and various library reliances, I just need something that works. Thus, Hugo.

So, that’s the long and short of what’s changed on the front end (I guess? It’s all backend honestly… You just don’t see the back of the backend, which is the whole how it’s hosted part). What about the backend? Or, rather like I just spelled out in parentheses, the “back of the backend”? Yes, that’s kinda changed a little too.

So, let’s dive into how all this worked before, the basic flow was like this:

  • I’d write a post, save it to a local folder
  • I’d run a script to freeze the contents of the folder (which were Markdown files) and then turn that Markdown into HTML (there’s tons of ways to do this, if you’re really really curious I can send you a newer variant of how the script does things and you can fiddle with it)
  • I’d then run ANOTHER script (well, a separate function in the script really) to generate the RSS feed
  • I’d then have to rerun the original function to put the new XML file into the directory that would be served with the HTML files (was probably an easier solution to this, I just never bothered)
  • I’d push all of those changes to a private Github repo
  • DigitalOcean’s AppPlatform would see the new push and would run build tasks to rebuild the site

So, how’s it different now?
Now I do kinda a similar process, but it’s less of a headache to do it:

  • I still write a post locally and save it
  • I now just have to issue a single command “hugo build” and Hugo takes care of all the stuff my script used to do (RSS included)
  • I push any changes to a local Gitea repository that is mirrored to a Github repo
  • DigitalOcean sees that mirrored push and redeploys the site using Hugo

So you may be asking “why make the change at all if it’s basically the same”? Well, here’s the thing. The 2nd bullet point? Completely unnecessary. I don’t HAVE to build local at all because the “public” directory isn’t even pushed to the repos. I build as a safety to make sure it looks fine before I push. All of the building and stuff is handled by DigitalOcean. So really all I have to do it write a post, save and push, then sit and wait for the rebuild.

All in all, this change was made to hopefully respark my desire to actually use this blog. I fell into a bit of a content hiatus for months at a time because every time I’d want to post I’d end up having to fight my own code to do it. This became even more of a thing when I started adding new features (remember the copy button? The theme toggle? Yeah.). I fell out of love with the whole process. I’m hoping to be able to leverage this simpler process to move towards a less ranty, less essay-esque posting cadence where I don’t go radio silent for months. But, like I said before, new year, new site, same me. So we will see :)