If you saw my previous article, why I chose Hexo for my Technical Blog you may be wondering, why the move to Hugo now?

I’m not going to spend a ton of time recapping all of the various options as I already did that in the previous article. Hugo was the close second last time around, I even mentioned it could be a coin flip!

I spent a bit of time kicking the tires on Hugo for some test projects and really liked how the templating worked. I was also a fan of the various themes that were out there and available and decided to go with Mainroad which I’ve modified a bit to suit my needs.

I also wanted to check out a few other things - which finally caused me to make the switch!

• Azure Static Web Apps - This was launched a while back, and I’ve been following it since. I was previously using Static website hosting in Azure Storage. It has some nice integration I wanted to try which brings me to…
• GitHub Actions - I’ve not had the opportunity to use it yet, and since it has direct integration with Static WebApps - it was an opportunity kick the tires.

So switching to Hugo has given me the chance to check out three new pieces of tech! Hard to argue with that!

I’ll go a bit into detail on the process and steps I took to make it happen.

Over the years I have managed my notes in many different ways. I’ve used Notion, OneNote, Evernote, and probably more that I don’t even remember. At the same time I was writing a lot more code, and creating documentation for web applications and APIs. This naturally got me using a whole lot more Markdown.

At this point Markdown truly is ubiquitous and it’s the defacto standard for writing technical documentation. Naturally, the more I used it the more I began to enjoy it. I started to wonder how I could incorporate it into my normal note taking activities. As an engineer, I take a lot of notes - many of them are technical in nature. It felt only natural to start using this in my normal workflow. I finally ended up settling on Visual Studio Code in combination with several plugins. I’ll take you through what I’m using, and also what I tried previously.

Read on to learn more!

Originally when I setup my blog on Static website hosting in Azure Storage I went with Azure CDN because I wanted to have an SSL endpoint. As of right now, you cannot do custom SSL with static website hosting unless you use Azure CDN.

But then I hit another snag, you cannot redirect the root domain and redirects in general were a bit too complex for a simple project like this one. There is a user voice suggestion for this feature but it remains under review. This started to bother me because I wanted to do redirects with SSL but couldn’t because the I could not install the certificate generated by Azure CDN on the Linux VM I decided to do the rewrites on. All my previous articles were on https://hammertime.tech breaking all of my links from places like Google and Bing, or even worse resulting in the dreaded SSL error.

Fast forward a bit to Cloudflare. In a previous life I used their free plan to protect against attack but that free plan also offers 3 free redirects AND a free SSL endpoint. This meant I could now redirect https://hammertime.tech to www. where my CNAME is setup for Azure Storage. It also meant I could redirect a bunch of my other domains like hammertimetech.com and have all my URLs work how I wanted. Nobody else will probably notice this.. but it’s one of those things I wanted in place - I am weird like that!

One of the things that I wanted to be able to do was setup a full CI/CD pipeline for my blog. As someone once said If it’s worth doing, it’s worth overdoing and it was in that spirit I configured Azure DevOps to deploy Hexo.

First off a short intro to Azure DevOps. Previously known as Visual Studio Team Services (VSTS) it is a service that allows you to manage code repositories, boards, pipelines (which we’ll cover here) and even test plans. You can also use Azure Pipelines with GitHub and while I did not do that here because I wanted all my repos to be private, there is no reason you cannot use GitHub as your source repo. Especially since two weeks ago they announced free private repos.

I had initially intended to publish this as part of my Azure DevOps entry, but it felt like it needed its own dedicated article. For my Hexo workflow I decided I wanted to use the Windows Subsystem for Linux from here on referred to as WSL. This works best for me because I am primarily a Windows user and I also have a fair bit of experience with Linux. Getting Started The first thing you’ll need to do is get Hexo configured locally so that you can generate the static content for later deployment, and also run your local server to test your content.

When the time came to relaunch my blog I spent a fair amount of time researching options. I wanted something that worked well for me that didn’t require too much infrastructure. I also wanted to keep costs fairly low and not take on a large monthly recurring cost.

• Ideally, I wanted static content that I could host in an Azure Storage account or some sort of static website hosting.
• I wanted something that felt comfortable for me. I spend a fair amount of time authoring articles in Markdown and it has really grown on me over the past few years.
• An application with a fair amount of plugin and theme options, I don’t really want to get involved in creating a custom template. A reasonably sized community was a plus.

When deploying Windows Server as a hypervisor host for virtual machine workloads there are a variety of best practices that should be put in place. Running Hyper-V on Windows has special considerations when it comes to workload. For example, Virtual Machine Queues and Hyper-V Specific hotfixes. This is blog entry serves as an overview of important checks you should ensure are in place. General Host Considerations Starting with your base operating system you should strongly consider Windows Server Core.