With a new year, it’s time for a new look! Over time, I found the old design too busy. I didn’t have a good idea for a new theme until I happened across Thomas A Caswell’s site. Drawn in by the clean design (inspired by Blue Penguin), I created a new Hugo theme!

I had to make some changes to preserve existing links from the old theme and to maintain the banner images on a smattering of posts.

No Javascript and a lot less markup and CSS.

And if I ever want to switch back, it’s a config.yaml away!

I’ve listened to Mike and Grey talk about their yearly themes since 2017, but this year I’ve finally felt motivated enough to commit to a theme.

If you don’t have the time to listen to dozens of hours of podcast episodes, Grey has a great video explaining “yearly themes”:

2020 was a rough year for more than just the pandemic. My parents were diagnosed with cancer. I felt like my life stopped as my attention focused on their care. Mom recovered: dad didn’t.

With my father gone, I picked up the pieces for my mom and helped with all her issues. I deprioritized myself and began to languish. Days spent working as nights devolved into mindless Youtube videos, endless refreshing of my RSS feeds, and bite-sized articles saved to Instapaper.

I created nothing.

After almost three years of this same grind, I can’t keep going on the same path. I started replacing Youtube with books and read almost 20 books since May.

While reading is better than watching, it’s not the same as making.

Therefore, 2023 is the year of creation!

Using Scriptable, I created a yellow sticky note in my phone’s today view to remind me of the year’s theme.

My years’ first act of creation: writing today’s post!

I was looking at my old development projects recently when I noticed that all of them predate 2005. In 2005, I started work at ePublishing as a Perl developer. In the past 17 years I’ve been:

• a Ruby and Rails developer
• VP of Software Engineering
• Chief Software Architect

In all that time, I’ve written hundreds of thousands of lines of code (maybe more than a million), but it’s locked away.

It’s a bit depressing that almost two-decades of creativity is forever hidden from view. It’s the curse of corporate development: we can write blogs, give talks, and prepare papers, but we can’t show the code itself. All anyone sees are shadows on the wall.

More companies should release their source code. Most of what we write is not the company’s crown jewels. Let people see how you solved that weird 3rd-party integration! Or how you monitor some obscure open-source service.

Every company is standing on a mountain of open-source code. Give back and let your developers have the opportunity to show off!

In a recent twitch stream, Gary Bernhardt showed a bit of behind-the-scenes in how he prepares his development environment for recording a screencast.

One of the tools he showed in passing was gem_home by Hal Brodigan.

gem_home is a simple script that manipulates Ruby’s GEM_HOME and GEM_PATH environmental variables in order to keep separate ruby gem locations.

By using gem_home, there is no longer a requirement to prefix all ruby commands with bundle exec. All the gems for a project are local to the project, which eliminates conflicts that might arise when gems for multiple projects are mixed together in one location.

Eliminating the need for bundle exec allows commands such as rspec to execute much quicker!

Unfortunately for me, I recently switched over to using fish shell from ZSH. Hal’s gem_home only supports Bash and ZSH. 🙁

One nice thing about gem_home is how simple and straightforward it is. In a few hours I was able to replicate its functionality as a fish shell compatible script!

• https://github.com/rjkaes/gem_home

If you’re using ruby and fish shell, I would highly recommend using my implementation of gem_home along with Jean Mertz’s wrapper around chruby. Both of these play well together.

vim-rails is enabled only if config/environment.rb is present in the Rails working directory.

At work, we have an engine based working directory that does not contain this file (as there’s an embedded application within the engine.)

To enable vim-rails, I need to do:

echo "load ::File.expand_path('../../embedded-app/config/environment.rb',__FILE__)" >> config/environment.rb
mkdir -p .git/info
echo "config/environment.rb" >> .git/info/exclude

Within the repo to enable vim-rails support.

Spiro Sideris writes:

To write understandable code, always ask the question of who your audience is. What level of experience do they have? What are the prerequisites they should know before reading this function? There are even differences in the semantics between programming languages, so knowing the best practices, and the language coding style, will ensure you are writing readable code for developers in that language.

Rule 1. You can’t tell where a program is going to spend its time. Bottlenecks occur in surprising places, so don’t try to second guess and put in a speed hack until you’ve proven that’s where the bottleneck is.

Rule 2. Measure. Don’t tune for speed until you’ve measured, and even then don’t unless one part of the code overwhelms the rest.

Rule 3. Fancy algorithms are slow when n is small, and n is usually small. Fancy algorithms have big constants. Until you know that n is frequently going to be big, don’t get fancy. (Even if n does get big, use Rule 2 first.)

Rule 4. Fancy algorithms are buggier than simple ones, and they’re much harder to implement. Use simple algorithms as well as simple data structures.

Rule 5. Data dominates. If you’ve chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming.

SSH is the backbone to how I’m able to work remotely.

Periodically, it’s important to review both my SSH config settings and regenerate my SSH keys.

From my perspective, Mozilla has put together the best recommendations for both server and client configurations. For now, I’m concentrating on the client configuration (within ~/.ssh/config and my SSH keys.)

OpenSSH Client Configuration

Below is Mozilla’s Modern SSH client configuration recommendation:

# Ensure KnownHosts are unreadable if leaked - it is otherwise easier to know which hosts your keys have access to.
HashKnownHosts yes
# Host keys the client accepts - order here is honored by OpenSSH
HostKeyAlgorithms ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-ed25519,ssh-rsa,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp521,ecdsa-sha2-nistp384,ecdsa-sha2-nistp256

KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr

Note these are the “modern” recommendations which assumes the services you are connecting to have been updated recently. I’ve noticed I’ve had to modify these for services like Github with:

KexAlgorithms diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1

OpenSSH Key Generation

ED25519 is recommended for all new keys, but not all services support it. For those services we need to fall back to RSA. Using Mozilla’s SSH key generation guidelines, I created a keygen script that defaults to ED25519:

#! /bin/bash
#
# Generate a new ED25519 or RSA SSH key using Mozilla's
# (https://wiki.mozilla.org/Security/Guidelines/OpenSSH#Key_generation)
# recommendations.
#
# Usage: keygen {service_name} [ed25519|rsa]
#
# Defaults to the more secure ED25519.
#

set -e
set -u

service=$1
type=${2:-ed}

case $type in
    ed*)
        ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_${service}_$(date +%Y-%m-%d) -C "Key for ${service}"
        ;;

    rsa)
        ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa_${service}_$(date +%Y-%m-%d) -C "Key for ${service}"
        ;;

    *)
        echo "Usage: keygen {service_name} [ed25519|rsa]"
        exit 1
        ;;
esac

Now you’ll need to send your new key to the remote server. For example:

ssh-copy-id -i ~/.ssh/id_ed25519_wormbytes_2017-12-08 robert@server.wormbytes.ca

Finally update your ~/.ssh/config and modify your IdentityFile to reference the key that was generated. Something like:

IdentityFile ~/.ssh/id_ed25519_wormbytes_2017-12-08

Conclusion

My recommendation is to review your SSH keys and configuration once a year. While the above configuration is the recommendation today (December 2017) it might not be the recommendation next year. Be sure to check back with Mozilla to see if anything needs to be updated.

Back in August I rebuilt the site using Jekyll and Minimal Mistakes for the theme. This worked great for a few months, but even a small site was taking too long to generate (10-15 seconds!)

While 15 seconds per build isn’t much, it was just enough friction to make updating not fun. That’s when I remembered that Julia Evan’s had posted her experience switching to Hugo. A zero second build time was very attractive!

Unlike her, it took me longer than four hours to migrate my site to Hugo! I had used a bunch of helpers provided by Minimal Mistakes that I had to either replace or rebuild. Plus, I had also written a couple of my own custom Jekyll plugins which were converted to Hugo shortcodes.

Migrating to Hugo

Like Julia I started with:

1. run hugo import jekyll
2. import a random theme

Getting to this point took no time and a hugo run to build the entire site took 150ms! Milliseconds! Awesome!

Then I hit the hard part. :(

Rebuilding the Existing Theme

I had spent a lot of time before settling on Minimal Mistakes as my Jekyll theme. It’s a great design with lots of functionality (some of which I even used.)

Rather than trying to port the underlying Jekyll templates, layouts, etc. I did what Julia did and copied the generated HTML and assets into the layouts directory of the new site and started digging into the Hugo documentation: while extensive, it’s not exactly user-friendly.

It took me three days of intermittent hacking to ensure all the content was present, with the right URLs, and with all the old Minimal Mistakes helpers removed and my custom plugins written as Hugo shortcodes. (Lots of NeoVim editing to replace the old markup.)

Once the HTML looked right, the last step was to update my workflow scripts.

Gotchas

Parsing dates.

Hugo has the .Format function to parse dates into human readable strings. What I didn’t grasp is that the reference format is very specific. If you don’t format the string using the exact times mentioned in the documentation your rendered dates are all messed up!

Success!

With everything in place I can now publish to the site with way less overhead and friction. Effectively, I go from saving the post to publishing to the Internet in under a second!

The only way it could be better is if I didn’t have to do the pesky writing as well!

Update

Still using Hugo, but switched out Minimal Mistakes for a theme I found online and then customized to suit my preferences!

As a remote worker in a rural community, I’ve found it difficult to find other technology workers in the area. After speaking with Brett, we decided to start the Norfolk Techies Slack group.

If you’re a technology worker in the Norfolk County area please contact Brett or myself for an invitation link.