Kindergarten diseases and golang – How to learn something while you die

My son has found a spot in a Kindergarten. In Berlin. In 2019. It’s a miracle that comes with a hefty price tag: Kindergarten diseases. Current record is three distinct illnesses in one week. To avoid going insane, I chose to use my new unscheduled down time by learning a new language – “Go” – and use my plight as inspiration for my first, small application: Giving my coworkers the opportunity to bet on the reason for my next absence.

Prologue – The Scope

For my first project, I want to keep it as simple as possible: Build a webservice where people can chose from a set of diseases or enter a new one into a form, submit said form and view the result. That means, we have to have some kind of routing and a way of persisting data. Everything else is on a list for bonus points.

Part I – IDE of choice

I am a huge JetBrains fanboy, ever since they got me hooked with a free student version of IntelliJ Ultimate that was so, so, so much better than eclipse or any other IDE I’ve ever used. Naturally, I would use goland then, right? Well, I would but there are two things holding me back:
  1. No option to develop directly in a container
  2. Also money
While I probably could afford the 9 Euros a month for a goland subscription, we have started using containerized development environments at work and I really like the idea of checking my whole dev workspace into a git. PHPStorm by JetBrains offers a nice vagrant integration with remote debugging, but goland has no such features … yet. But Visual Studio Code does. Somehow. It’s complicated. Basically it runs one instance of VS Code inside a docker container, mounting the source code and installing all necessary plugins and you connect to it via your installed VS Code instance. What you have to do is create a devcontainer.json and then … magic happens. Follow the tutorial. Here is how my file looks like:
{
    "name": "Go",
    "dockerFile": "Dockerfile",
    "runArgs": [
        "--cap-add=SYS_PTRACE",
        "--security-opt", 
        "seccomp=unconfined",
        "--name=amisickyet_develop"
    ],
    
    // Uncomment the next line if you want to publish any ports.
    "appPort": [8080],

    // Uncomment the next line to run commands after the container is created.
    // "postCreateCommand": "go version",

    "extensions": [
        "ms-vscode.go",
        "mhutchie.git-graph",
        "eamodio.gitlens"
    ],
    "settings": {
        "go.gopath": "/go"
    }
}
After quite some time (the docker image I ended up with is 1.3 GB big), you end up with a VS Code instance (minus most of your plugins) with your code ready for action. I had to go into the command palette and manually install all go tools via Go: Install/Update Tools and – I think – check Go: Use Language Server in the settings for some tools to work like renaming.

Part II: dep vs modules

I was alienated by the concept of one single path for all projects and no way to specify the version number of my dependencies per project. Although dep is much more like what I’m used to (composer), I decided to use the brand new go modules because I fear/expect that this is where we are all heading. To get started I entered go mod init gitea.danielroehrig.de/amisickyet into a terminal and left it at this.

Part III: Framework?

At work, I use Symfony, but I heard that using a framework is not the go way. So, I decided to use go core functionality as much as possible.

What’s next?

Everything. I haven’t written a single line yet. But my workspace is set up and I am very confident that within the next 3-4 months, I will have a “hello, world” staring back at me. I won’t document my whole journey here but whenever I get stuck or find something amazing or infuriating, I will write a post. Eventually.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.