How I Built This Blog

The first post of this blog must be on how I built this website, because I tried some innovative approaches and I think it is worth the effort.

We need to start from the beginning.

Windows Subsistem for Linux

The Blog I’m writing into is made with Hugo which is a really powerful engine to produce static websites. It is written in golang and is extensible with a huge community and many themes that can be applied.

I usually work on Windows machines, if you check the About page, you’ll see that I am a Dynamics CE consultant, many if not all the tools needed to work with Dynamics were historically “windows only”.

That is not a problem for Hugo, it is available for Windows too. So why I’m talking about Windows Subsistem for Linux (WSL)?

For many years since I first heard about WSL I wondered why should i need it. Then I came into some awesome speech by Scott Hanselman. In particular i suggest this one:

After I saw that video, I understood that WSL was not just an emulation of Linux, and another thing I understood was that Docker took advantage of it. Now, I’m a very beginner in Docker, but I’ve always perceived it was a huge help for me to have a clear machine (clear, in the sense that I would not have many SDKs and resources installed locally).

VSCode Remote Host

I use VSCode as my primary IDE since it was generally available. A feature I’ve wanted so badly to try and to find the benefits of having it was the Remote Host development.

If you put together WSL, Docker and VSCode you will have a lightweight and extremely powerful development environment.

Basically, you spin a new Docker VM that takes advantage of the WSL kernel to execute. On this you can attach a VSCode remote host session and work direcly on the VM with all the benefit of being in your principal machine (No rectangle inside a rectangle, as Scott Hanselman would say).

But i wanted to make a step further.

Docker Dev Environment

NOTE: Probably there are tons of way to do this thing, i’m just saying how a complete beginner could approach the problem. So, please do not consider this an expert point of view.

One thing I found frustrating with the approach i was choosing is that to work on my source code i would have to clone the repository locally, spin the Docker VM and “map” my local folder inside the VM. Something like this:

docker run -v C:\Local\codethingsblog:/src -p 1313:1313 -it myhugo

Once I’ve finished working on my code, I would need to push it to my repository from the local machine.

Then i saw Dev Environments.

Dev Environments lets you create a configurable developer environment with all the code and tools you need to quickly get up and running.

It uses tools built into code editors that allows Docker to access code mounted into a container rather than on your local host. This isolates the tools, files and running services on your machine allowing multiple versions of them to exist side by side.

To make it work in a very easy manner I just needed to add a compose-dev.yaml file:

services:
  compiler:
    build: .
    restart: always
    tty: true
    ports:
      - 1313:1313

and a Dockerfile

FROM klakegg/hugo:0.101.0-ext-alpine
WORKDIR /src
COPY ./ ./
EXPOSE 1313
ENTRYPOINT bash

Those two files will have to be in the main git folder. After that you can push into the repository.

If you, like me, work with VSCode, be sure to have some extensions installed:

This will make your life easier.

If your Docker is running, then restart it.

You’ll should see something like this when you try to create a new dev environment:

Put the name, the url of your gir repository and select VSCode, everything should be automatically set for you! Enjoy!

I still have a lot to learn about this, this is just the beginning for me in this world!

The end

The rest is just HTML and CSS, Hugo has everything I need just out of the box, so for the moment I don’t need to extend it or to add fancy things to make it as I wish.