It is time to look over 2019 to see if or how I have grown, what or where I put my focus, and determine whether or not I need to re-align myself for the coming year.

Blog

I migrated from BitBucket Pages to GitLab Pages for various reasons. There were a few hiccups along the way but overall it seems to have been a pretty smooth transition.

Part of my goal after the migration was to consistently produce content. Perhaps I was too ambitious with my goals/expectations. I was able to produce consistently throughout October but fell off in November due to numerous issues and frustrations with my Raspberry Pi-Hole project.

Over this next year, I would like to keep the goal of producing content regularly and personalizing and/or creating a blog theme. At this time, I want to focus on the content to be more how-to’s, and notes, and improve my communication.

Books

One of my goals for 2019 was to read 12 books. I thought a book a month was reasonable and achievable. And for the first quarter of the year, it seemed like it was going to be. I was able to make my way through the following:

• Clean Code: A Handbook of Agile Software Craftsmanship
• Clean Coder: A Code of Conduct for Professional Programmers
• Pragmatic Programmer: From Journeyman to Master
• Test-Driven Development by Example
• and a few fantasy books

I am not sure what happened after that to cause me to get off track. I started reading Getting Things Done to re-emphasize some of the techniques he provides. The irony is not lost on me that this was the book to break my trend.

Although important, I am not sure I want to have a reading goal for 2020 - except for finishing Getting Things Done.

Pluralsight Courses

PluralSight may be part of the reason I was unable to complete my reading goal for 2019. Throughout 2019, I completed the following PluralSight Courses and started several others:

• Advanced Unit Testing
• Microservices Architecture
• Clean Architecture: Patterns, Practices, and Principles
• Design a Tech Logo That Stands Out
• Code Analysis in Visual Studio 2019
• Increasing Productivity by Beating Procrastination
• Introduction to PRISM
• What’s New in Prism 5.0
• Prism Problems & Solutions: Showing Multiple Shells
• Prism Problems & Solutions: Loading Modules Based on User Roles

I planned on creating posts reviewing each one containing my notes to keep them in a central location. Unfortunately, I was not happy with the format/quality of the few courses that I did create reviews for. While I still want to create those entries, I need to figure out how to communicate the review effectively.

I also took the C# Skill IQ Evaluation and scored in the 95th percentile with a 248. I plan on improving this score in 2020, but also want to take courses to build other skills.

Programming Languages

I have worked with C# for a decade. While I love the language, I have started to feel as though the problem space has become stagnant and repetitive. It seems as though I am not the only one feeling this way either.

This is not to say that I think .NET is dying/dead. I still very much enjoy it and have much left to learn about it - particularly with the quality of life changes .NET Core is providing. I simply want to expand my thinking and skill set and learning a new programming language may be better suited to that.

Specifically, I am considering Go and Functional Programming. Begrudgingly Pragmatically, I am considering JavaScript/TypeScript and React/React Native.

Projects

I have no shortage of projects. My problem is in finishing them and/or making them public.

One of those projects this year was my Raspberry Pi-Hole, but have not circled back to it yet. Once that project is completed, I plan on making a Raspberry Pi Development Server. The idea is for it to contain a dockerize Jenkins, Redmine, SonarQube, and/or other software used in my development lifecycle. It is portable enough that it can be brought with me on the go or can be configured with a VPN and accessed remotely.

In December, I started JHache.Enums to experiment with BenchmarkDotNet and write high-performance C# code.

Software Setup

On a day-to-day basis, I use:

• Visual Studio
  • CodeMaid
  • Editor Guidelines
  • File Icons
  • File Nesting
  • Power Commands
  • Productivity Power Tools
  • Roslynator
  • Shrink Empty Lines
  • SonarLint
  • StyleCop
  • VSColorOutput
• Visual Studio Code
• SourceTree
• LINQPad

I started trying to learn Rider.

With the announcement that Google Chrome would be making it more difficult for ad-blockers, I looked at alternatives. I tried Brave and Vivaldi, but due to several issues, I am switching back to Firefox.

I looked at Fork and GitKraken as SourceTree replacements. GitKraken is my favorite, if I only had a single account it would probably be my daily driver. Overall, Fork looks like a good replacement for SourceTree but I have not spent enough time with it. I can say its merge tool is one of the best.

For productivity, I settled on TickTick for task management and Dynalist as my work journal.

I gave up on trying to get HyperJS to work the way I wanted. Initially, I tried Windows Terminal but ended up returning to Cmder.

I am starting to use Docker for Windows but still need more exposure to using it.

Tech Setup

I upgraded my wife’s computer so she could do her design schoolwork. Given the programs, she needs to run and that she does not game too much I opted for an AMD Ryzen 3700X and NVIDIA 2070 Super. She also got a Secret Lab Omega

My computer (~10 years old) and desk are due for an upgrade this year. Additionally, we are looking to soundproof my office to get a streaming setup started.

Work

I accepted a new opportunity working on a WPF Prism application (as evidenced by blog posts and Pluralsight history).

Lacking

Going over this year I realize three areas are lacking: family, relaxation, and exercise. These are areas I will need to make time to focus on in 2020.

Introduction

At the end of the GitLab Pages Setup post, I described an issue I encountered with GitLab CI generating the static site. The issue is caused by Hexo themes being linked as Git submodules - which means the default theme configuration is used. At the time, I only had a single idea - but was not sure whether or not it would work. Since then I have had a few more ideas about possible solutions and this post will describe them.

Overwrite Default Theme Configuration

The most straightforward approach was to add the modified configuration file to the repository. Using the GitLab build configuration, the configuration file could be copied to the themes folder overwriting the default theme configuration.

The only benefit of this approach is its simplicity. Adding the file is trivial and the modified GitLab build configuration would look something like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

image: node:10.15.3

variables:
  GIT_SUBMODULE_STRATEGY: recursive

cache:
  paths:
    - node_modules/

before_script:
  - npm install hexo-cli -g
  - test -e package.json && npm install
  - mv themes/_config.yml themes/icarus/_config.yml
  - hexo generate

pages:
  script:
    - hexo generate
  artifacts:
    paths:
      - public
  only:
    - master

In case it isn’t clear because it’s only a line, the change is:

1

- mv themes/_config.yml themes/icarus/_config.yml

This approach has a few problems though. The first inconvenience is if the theme allows the configuration of branding images or avatars that utilize a path in the theme structure these files must also be copied or moved into the theme after the submodule has been initialized. This could probably be overcome by mirroring the structure of the theme and modifying the command to move a folder into the theme during the build process. Changing themes requires updating the theme config file, the GitLab build configuration file, and adding the theme as a submodule reference. Most troubling however is that if the submodule is updated, there is no way to detect conflicts or updates that may break the theme except at runtime. Overall, this does not seem like a good approach anymore.

Include Theme Contents

The second option could be to include the theme contents directly instead of referencing them as a submodule. Doing so would eliminate the first two issues described with the previous method above. However, it still suffers from the final issue, although slightly different. Updates now are a completely manual process, which will likely entail overwriting the files - potentially leaving orphaned files. Additionally, it also adds bloat to the Hexo content repository which probably is not necessary. Overall, this solution is better than the previous one but still is less than ideal.

Fork and Update

The final idea I had is to fork the theme being used. Updates can be made to this new repository that is specific to the Hexo instance. Updates can be applied by merging the original master repository into this forked copy. If the update changes something unexpected, a conflict will occur that the user will have to resolve to finish the merge. The Hexo content repository would then have the Git submodule reference the forked copy. Another great part about this is that the submodule can be edited directly and changes committed for it from the parent module.

Summary

I think the final solution eliminates most of the major risks associated with the other options and is what I will be using. I can even make my forked repository private and have the GitLab runner still able to access it thanks to GitLab’s CI build permissions. The only differences are that my submodule name will need to be the project name and the URL will need to be changed from an absolute URL to a relative URL:

1
2
3

[submodule "hexo-theme-icarus"]
  path = themes/icarus
  url=../hexo-theme-icarus.git

The other solutions should work fine but they seemed wrong for one reason or another. Choose whichever option has risks that you can live with.

Introduction

Depending on the referrer (Twitter), it may be easy to find out that I used to publish articles on BitBucket pages. I initially chose BitBucket pages because they were the only repository provider that supported free Private Repositories. However, I am looking at alternatives because BitBucket does not support domain forwarding (anymore) for BitBucket pages.

This is a problem because if BitBucket were to go out of business (which doesn’t seem likely but hypothetically) then all my links die with them. While I appreciate the ‘free’ server, I am also not keen on my URL structure being a sub-domain of theirs - it just seems unprofessional of me. This is why I never really considered options like WordPress.com or BlogSpot. There is nothing wrong with these companies or the services they provide. On the contrary, it is great that they provide these services because it opens up options for people to choose from.

My biggest issue though is if I were to switch service providers (which I am doing), I now have to either go edit all previously published links to use the new URL or abandon them. Either option is not a good option. This is what prompted me to look into service providers that support domain forwarding so that the platform I publish my articles to is irrelevant.

The two big contenders I know about are GitHub Pages and GitLab Pages.

Why GitLab?

I ended up settling on GitLab because I am more familiar with their organization setup and I wanted to get some exposure to their CI/CD pipeline. GitHub may be a viable option for CI/CD with the release of GitHub Actions but as of this time, it is still in beta. GitHub’s major appeal for me was how simple it seems to set up a custom domain and their documentation is superb. I had a few issues with GitLab, some of which seemed to stem from NameCheap, my domain registrar.

GitLab does have static site generator templates that can be forked as a starting point.

While you can create a project from scratch, let’s keep it simple and fork on of your favorite example projects to get a quick start. GitLab Pages works with any static site generator.

This is also visible when creating a new project:

My pain may have been less had I used one of these.

Setup

The first step is to create a new repository project on GitLab. This project should follow the naming convention of organization/user.gitlab.io As embarrassing as it is, I have to admit that this was my first mistake. I am not sure why, since BitBucket follows a similar naming convention but for whatever reason, I named the project jhache.me.

In case others make this same mistake, it is not the end of the world. Go into General Settings and rename the project.

This does not change the URL however, so it may be a good idea to update this before progressing as well. In the General Settings area expand the Advanced section and look for the Change Path section taking note of the warnings:

This should allow the project to be referenced directly with the GitLab URL (such as www.gitlab.com/jhache/jhache.gitlab.io). I am not sure if this is necessary though since I was troubleshooting 404 errors that may have been caused by the next step not being run.

With the repository created, the local Hexo folder should be committed and pushed. This differs from my previous workflow on BitBucket where I had a repository containing the Hexo folder and another repository containing only the site content that I would hexo deploy to. Since I want to leverage the GitLab CI/CD this is a necessary change.

CI/CD

GitLab CI/CD uses a YAML configuration file called .gitlab-ci.yml, much like Appveyor or TravisCI. The file tells the CI/CD pipeline how to build the repository. This file can be copied from the Hexo Pages Template:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

image: node:10.15.3

cache:
  paths:
    - node_modules/

before_script:
  - npm install hexo-cli -g
  - test -e package.json && npm install
  - hexo generate

pages:
  script:
    - hexo generate
  artifacts:
    paths:
      - public
  only:
    - master

Note: If this is a migration (as in my case) from another service provider, be sure to commit the contents of your local repository (if you want to save the history) before doing this or you will have conflicting heads that you will need to resolve somehow.

Since Hexo themes are added as Git submodules (if done according to the Hexo documentation), using one required a change to the configuration file to checkout the submodules. The final configuration file up to this point looks like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

image: node:10.15.3

variables:
  GIT_SUBMODULE_STRATEGY: recursive

cache:
  paths:
    - node_modules/

before_script:
  - npm install hexo-cli -g
  - test -e package.json && npm install
  - hexo generate

pages:
  script:
    - hexo generate
  artifacts:
    paths:
      - public
  only:
    - master

Committing this file should trigger a GitLab build. Once complete, the GitLab page should be able to be accessed from the name template described above (jhache.gitlab.io). If not, troubleshoot this issue before continuing.

Custom Domains

As explained above GitLab supports (multiple) custom domains to be routed to their pages. This is configured/set up in the Pages Settings of the GitLab repository.

Add a New Domain:

Once done, a screen will appear that must be taken to a Domain Registrar to configure the details of:

This must also be done for www domains since www is technically a subdomain.

I use NameCheap as my Domain Registrar so the remaining steps will use their Advanced DNS page for the domain. Other Domain Registrars may have a similar setup but I cannot guarantee this. GitLab does provide documentation from some Domain Registrars but NameCheap was not one of them. Fortunately, I was able to find one article that helped me configure my DNS Host Records:

The A record redirects jhache.me to GitLab pages. The first CNAME aliases jhache.gitlab.io as jhache.me. The second CNAME record aliases jhache.gitlab.io as www.jhache.me. The first TXT record is the verification code provided by the Pages Domain Details for jhache.me. The second TXT record is the verification code provided by the Pages Domain Details for www.jhache.me.

Since the Pages Domain Details contain the raw TXT record that should be used, the NameCheap user interface contains a substring of the value. The TXT records should be left so that certbot can verify ownership of the domain when certificates are regenerated - in case the domain name is transferred.

Once your domain has been verified, leave the verification record in place: your domain will be periodically reverified, and may be disabled if the record is removed.

• Verify the Domains Ownership

Depending on the TTL settings for the host record, this could take some time to propagate. You can use the dig command or Online dig to check the DNS records associated with a domain.

Back in the Pages Domain Details refresh the verification until it is green. Once verified, wait for a certificate to be generated - the Pages domain settings will look like this when it has been acquired:

Once acquired, the Force HTTPS setting can be set. With that requests to the configured domain should redirect to GitLab pages over HTTPS.

Outstanding Issues

Because GitLab CI/CD checks out themes as part of the build process, my theme configuration settings have been lost. I have an idea to resolve this by modifying the .gitlab-ci.yml to copy the desired _config.yml from a directory in the main repository, but I have not verified if this will work.