Day-to-day management (moving from WordPress, part 3)

Part 1 - An overview and discussion about Static Site Generators - Part 2 - Setting up the infrastructure on Microsoft Azure

I had planned on today’s post being about how I converted all my content from WordPress to something Jekyll could use. Unfortunately, I realized that code was never pushed to GitHub and it’s currently stuck on a machine that’s not running due to some heat issues. I’ll be getting some thermal paste tomorrow and attempting to remedy that situation.

So, for today, I want to go over how I work on this blog day-to-day.

Visual Studio Code

I use Visual Studio Code to write every bit of content for this blog. It’s not configured in any special way, and the only extensions I use that matter are Vim and Word Count (mentioned in this post).

Starting a new post

I normally start by copying the last post of the type of post I want to create and renaming it - in other words, if I want to create a new Interesting Links post, I’ll copy the one from the previous week and rename it.

The files are created in my _posts folder and follow a specific naming convention:

yyyy-mm-dd-title of the post.markdown

The date matters - it’ll be the date you want the file to be generated. That means if I have a filename like

2024-07-13-blah.markdown

If I generate the site on July 12, that file won’t be generated. If I generate the site on July 13, it will be included.

That can be overridden in the “front matter” section I’m about to talk about.

The front matter is a block at the top of each piece of content that let’s you control a variety of things. For example, here’s the front matter for this post:

---
layout: single
classes: wide
title: "Day-to-day management (moving from WordPress, part 3)"
header:
  image: /assets/images/blogging.jpg
  teaser: /assets/images/blogging.jpg
date: 2024-07-13 07:00:00.000000000 -04:00
type: post
published: true
comments: true
categories: article
tags:
- Leadership
- Technology
- Blogging
- Azure
excerpt: The one where I talk about moving away from WordPress and walk through how I manage things day-to-day.
---

You can see that I set the layout of the page, along with the title, image I want displayed at the top of the post, the date I want it published (overriding the filename), the category, tags, and the excerpt that’s displayed in different views on this site.

Many times, I start with a title of “TBD” and an excerpt of “The one where I talk about things…” and then once I figure out what I’m going to write, I’ll fill that information in.

At that point, I start typing my content in markdown. I could easily write my content using straight HTML, but that sucks. I don’t want to muck around with all that extra typing. If I want something bold it’s easy. If I want a link, it’s much easier to type than building a full anchor tag.

[Link description](url)

Some automation

I also have a few snippets set up to handle a lot of the repetetive work:

"Markdown Link": {
    "prefix": "mlink",
    "body": [
        "* [$1]($2){:target=\"_blank\"}"
    ]
},

That one allows me to create a link, primarly used when I’m creating my Interesting Links of the Week posts. In my editor tab, I type

mlink <tab>

and it creates the markdown needed for a link, placing the cursor where you see $1. This allows me to have something in the clipboard, type the shortcut, hit tab, then paste. Easy.

The other one I use frequently is for highlighting C# code.

I am working on a console application that will remove the necessity for those snippets, but for now, they are used pretty heavily.

Testing and Deployment

In part 1, I talked about how easy it was to set up Jekyll and serve up pages locally, so I want to show my setup and dig into how I move from editing to testing to deployment.

First things first - I do NOT use the Terminal in Visual Studio Code. I always have a terminal running, and for my blog, I have a tab with a horizontal split. By the way, I’m running iTerm2 with oh-my-szh.

The top pane is where I’m running

bundle exec jekyll serve --future --drafts

That allows me to see future-dated posts along with posts in my _drafts folder. When it’s running, I can also see any errors during generation.

The bottom pane is where I do all my git work. In this case, I haven’t created the branch yet, but that’ll be as simple as:

git checkout -b move-from-wordpress-part3
git add _posts/2024-07-13-how-i-moved-away-from-wordpress-part3.markdown assets/2024/blog-management-shell.png

I’ll make my changes, committing along the way. Because Jekyll rebuilds the site every time I save the file, I will flip to my browser window to make sure things are looking like I expect them to look. Once I’m happy, I’ll do a final commit and push to the GitHub repository.

After I’ve pushed to GitHub, I’ll hit my browser again, navigating to my repo so I can create the Pull Request. As soon as I create the PR, the workflow kicks off, building the site and giving me a preview site on Azure so I can make sure I haven’t missed anything big.

It takes about 10 minutes between the time I create a PR and the time the preview is available to me on a special URL that Azure generates.

Once I’ve read, re-read, and know for sure the content is good-to-go on the preview site, I’ll merge the pull request. Many times, I’ll have to go back and fix a typo, or change some text, and that means going through the commit/push/build/test process again. Once I merge the PR, the workflow runs again, but this time, publishing the site to production instead of the preview site.

More process stuff

This process works really well for me, but I know there are some things that could be more efficient. The copy-paste beginning of each post will hopefully be a thing of the past once I get a utility finished to automate the creation of specific types of posts (articles, links, or TIL).

As for the content itself, to write a post like this one takes me, on average, about 2 hours. Long posts, believe it or not, take longer. Part 2 of this series was written in about 90 minutes while my wife was driving.

My Interesting Links of the Week post is built in a similar fashion, but because I’ve been doing them every week for a couple years, that process is a bit more efficient, although the process of collecting the links is still a manual process.

Oh, I do keep a backlog of ideas in Trello to make sure no ideas get lost along the way. I have many posts that are in draft form. Some only stay that way for a short time, but others have been in draft for a LONG time, waiting for the right words to come to me.

Final Thoughts

I’m happy with my move to Jekyll and for the processes I’ve developed over the past couple years. I hope to write at least a couple more installments - one about some customizations I’ve made, and of course, the one about converting the content from WordPress. That was actually a fun project, and once I get access to the code, I’ll have some C# code to show.

Thanks for reading!

---