Web Development on Chrizzle23.net

Setting up my writing environment

Fri, 11 Sep 2026 00:00:00 +0000

Setting up my writing environment

A major project that I took on over the summer was fixing my rather flat home network to include separate VLANs for me, the family, the various smart devices around the house, the DMZ, and my server network. During that project I thought, “how can I make this harder on myself?”

I am not a particularly smart individual, so I like to keep things simple, so I assign a class C subnet to each VLAN, and I use numbers that I can easily remember:

Git Hooks pt2

Wed, 11 Jun 2025 00:00:00 +0000

The Meat Grinder

Git makes it possible for me to only have to worry about my MarkDown files. Or, someday I will only have to worry about MarkDown files. But it is not this day.

Hugo templates are fussy tools. They’re awesome when I can get them work, but getting to that point is maddening. And Git might as well be black magic for how well I understand it. Once I push my MD files up to the remote repo, the git hook calls ‘stage.sh’ and IT’S SAUSAGIN TIME!. The following is my cobbled together shell script to eat MD and vomit up websites. I should probably use python or something, but I am too jacked up on Mountain Dew to take on another growth opportunity.

Git Hooks pt3

Wed, 11 Jun 2025 00:00:00 +0000

Actual Deployment

This whole “development pipeline” is a massive clunk. A collection of clunks, working together. Clunkware. I haven’t attached this deployment script to a git hook. I want a chance to look at the staging site before I push it to production. “Production” for me is when the files are updated on The VPS. Pushing a non-working site to production is, as the Irish would say, not the best. So I run the deployment script manually, which I will detail at the end of the post.

The Shell Script From Hell

Wed, 11 Jun 2025 00:00:00 +0000

IT’S TAKEN ME 60 HOURS TO SAVE 2 MINUTES OF TYPING

Git hooks are scripts of some kind that run when you do something in Git. Real developers (not me) use them to kick off a bunch of crap like QA tests, validation tools, sending messages to people, pretty much anything you can imagine. They do all kinds of things, but I am going to do the thing that I always do and barely scratch the surface of its potential. AND I am using it to run Bash scripts. If you are a proper dev, or DevOps type, this is your opportunity to look away.

Gitting back to Git

Tue, 10 Jun 2025 00:00:00 +0000

Git for Windows is Trash

As you may recall, I find that having a dedicated writing environment is more productive. Getting this blog launched is a serious undertaking because I am building self-hosted infrastructure, while attempting to write about the self-hosed infrastructure, using the self-hosted infrastructure. It’s like writing about building a house from bricks while sitting in a house made of sticks that is actively falling down.

Why is the house falling down? Well, my idea of running a home lab works like this: hack, crash, patch, repeat. Most of the time I am half-way down the rabbit hole before I realize that I took a wrong turn at Albuquerque.

Blogging Workflow

Tue, 03 Dec 2024 18:21:08 -0400

Writing is hard

The whole reason that I write a blog is to cope with depression. I do little tech things, and then write about those tech things, and it serves a few purposes.

It’s a kind of journal, only instead of my feelings, I document the things I have learned. A big source of my depression is feeling like I don’t accomplish much. A lot of things in my life haven’t turned out the way that I wanted them to, and having a digital record of my accomplishments, even the small ones, helps me to look back and see that I am actually doing things.

Hugo Themes Part 4

Tue, 17 Sep 2024 18:47:19 -0400

Just like the last post, here is the TL;DR

Without git, you should use 7zip or tar to make backups of your working site on your workstation.
There is a very specific order you should use to create new content.
Some of this mystery behavior is me not understanding what I am doing when creating “new” posts that are actually old.
IDK why, but I get better results with the Hugo test server by using the –disableFastRender flag.

When we last saw our heroes…

I had decided to remove git from my workflow. It has definitely solved the disappearing template problem. Of course, if I need to regenerate my work directory for the site, I am out of luck. So I have taken to making compressed snapshots of the directory in case I have to delete the directory and start from my last checkpoint.

Hugo Themes Part 3

Wed, 11 Sep 2024 16:13:15 -0400

Just like the last post, here is the TL;DR

Using git to store your entire Hugo file structure is probably a bad idea.
Using git as cloud storage for markup files is probably also a bad idea, so I’m going to stop doing that too.
Dude, you gotta run the hugo command all by itself before you copy files up to the webserver.

When we last saw our heroes…

I was complaining about the theme files randomly disappearing. I think it comes down to git doing what it’s told to do, and me simply not understanding what I am telling it to do. That’s really the only thing that I know about computers: they do what they are told to do, not what they’re supposed to do, not what you want them to do. If a computer isn’t doing what you want, you should probably take a close look at what you are telling it to do.

Hugo Themes Part 2

Mon, 09 Sep 2024 15:44:21 -0400

Just like the last post, here is the TL;DR

Git and Hugo are intertwined. So instead of working on your local copy of the site and updating that, I have had success with deleting the local branch and cloning it. This is a workflow issue with git, not necessarily a Hugo problem, but it’s been a source of inconsistency.
Hugo can be a bit fiddly. I have had situations where the theme just vanishes. I think this is an issue of cloning the theme locally vs. adding the theme as a git sub module. Who fucking knows?
Speaking of fiddly, I have been adding markdown files with the “Hugo new content posts/newpost.md” command one at a time.
Deploying the updated site is an issue I have yet to tackle. Once I am comfortable with the development process, THEN I will take on automated staging and deployment. For now, I just copy the “Public” directory up to my webserver with SCP.

When we last saw our heroes…

I was complaining about consistency. I read somewhere a long time ago that when testing new video games, the game behaving unpredictibly was more stressful than losing the game. That has been my issue with Fallout 4, and it’s my issue with Hugo.

Hugo Themes Part 1

Thu, 05 Sep 2024 09:49:45 -0400

If you are experiencing frustration with Hugo templates, here’s what I know so far

Unlike a recipe blog that tells you a long story about studying abroad in Europe before giving you the recipe, here is the TL;DR up front:

Running the Hugo test server doesn’t actually do anything. Yes, it runs a test server and serves pages on your workstation. But it doesn’t actually make the site. Once the test site looks good, terminate the server and run the Hugo command with no options. Then deploy the public folder.
Hugo doesn’t like when you add multiple MarkDown files to the site. Work on one at a time. Also, keep a backup copy of your content files outside of your main branch in git. I have broken things so badly that it’s easier to just start over from scratch with a new git repo.

If you are interested in the tale of this quest for this knowledge, please read on: