Coding in Style

With my blog “going public” I can finally start writing. My next step was going to be adding TailwindCSS, I started working on that and immediately noticed that my editor, neovim, applies the wrong indentation, so we are going to fix that first.

I can update the indentation configuration in neovim, but I think a much nicer option and better convention would be to set up .editorconfig.

EditorConfig

1.  $ touch .editorconfig
   

2. Configure EditorConfig for available file types.

   diff --git a/.editorconfig b/.editorconfig
   new file mode 100644
   index 0000000..2a0efbf
   --- /dev/null
   +++ b/.editorconfig
   @@ -0,0 +1,21 @@
   +# EditorConfig is awesome: https://EditorConfig.org
   +
   +# top-most EditorConfig file
   +root = true
   +
   +[*]
   +# Unix-style newlines with a newline ending every file
   +end_of_line = lf
   +insert_final_newline = true
   +charset = utf-8
   +trim_trailing_whitespace = true
   +
   +[*.md]
   +# Two or more spaces at the end of the line are parsed as hard line break
   +trim_trailing_whitespace = false
   +indent_style = space
   +indent_size = 4
   +
   +[*.{html,css,js,yaml,yml,toml}]
   +indent_style = space
   +indent_size = 2
   

3. Commit our changes.

   $ git add .editorconfig
   $ git commit -m 'configure EditorConfig'
   

Neovim supports .editorconfig out of the box¹, but it doesn’t automatically enforce specified coding style. To ensure better code consistency, let’s set up pre-commit with the editorconfig-checker hook.

Helping Github and Cloudflare Shake Hands

I am using Cloudflare DNS for my domain, and I did not know that there were additional steps I needed to take for the domain to work properly and have HTTPS enabled.

Show Your Work

Our blog is a few steps away from being ready to see the world¹.

1. Configure the site

   diff --git a/site/hugo.toml b/site/hugo.toml
   index 4dba0ec..7d59855 100644
   --- a/site/hugo.toml
   +++ b/site/hugo.toml
   @@ -1,6 +1,6 @@
   -baseURL = 'https://example.org/'
   +baseURL = 'https://imomaliev.com/'
    languageCode = 'en-us'
   -title = 'My New Hugo Site'
   +title = 'Blog'
   
    [module]
      replacements = 'github.com/imomaliev/blog/theme -> ../../theme'
   

2. Follow all the steps in the Host on GitHub Pages guide.

Almost Ready to Write

We have the site, we have the theme, and according to the quickstart guide, we are ready to add content. But in actuality, not quite yet.

1. Start by deleting skeleton posts that were added with the theme.

   $ git rm -r theme/content/posts
   $ git add -u
   $ git commit -m 'delete skeleton posts'
   

2. Default Hugo site and theme skeletons use TOML front matter, but I prefer using YAML, mainly because GitHub does not support TOML and JSON rendering in front matter¹.

Dogfooding a Theme

We’ve already created the Hugo site and pushed it to GitHub. Now is the time to set up our theme.

Quickstart suggests using an existing theme, but I want to create a custom one. I will store it in the same git repo because I do not have current plans of sharing it but still want it to be in a separate folder from the site.

1. Create a theme skeleton in the project root.

Create a Site

I will start at the very “beginning” and go through the official quickstart guide. My goal is to achieve the same results as so I can start blogging ASAP but I will be doing it a bit differently than how it is outlined in the guide. I will explain my decisions along the way. So let’s create the Hugo site.

The quickstart docs suggest creating a new site skeleton and initializing git in the created site’s root.

Fresh Start

I tend to be overly obsessive and pedantic when it comes to finding answers, especially when I’m looking for a “better” way to do something. I sometimes spend hours falling deeper into the rabbit hole of a perfectionist’s spiral: a quick web search for one question can lead to dozens of open tabs. I constantly get sidetracked by the cascade of follow-up questions that appear one after another, steering me further and further from my original goal. I’d describe it as an unshakeable belief that there must be a better option, which causes intense frustration when you can’t find it—or worse, when you know it’s just out of reach.