DEV Community: Kai

Getting Going with Go, Day 4

Kai — Thu, 28 Jan 2021 20:28:01 +0000

Today I thought I’d look into static typing of variables, as it’s a fundamental quality of Go as a language.

So, in languages like Python, you could very easily do the following with variables:

>>> a = "bc"
>>> a
'bc'
>>> a = 3
>>> a
3

In languages such as these, a variable is just a container for stuff. You can change what stuff goes in mid-stream, dynamically changing the type of the variable.

In comparison, Go is a statically typed language. You can either declare a variable explicitly with its type for use later (var x int for integer) or inferred at creation time (x := "hello" for a string containing “hello”) So of course I’m going to try the same exact hijinks as above:

package main

import "fmt"

func main() {
    a := "bc"
    fmt.Print(a)
    a = 3
    fmt.Print(a)
}

Trying to build or go run prog.go spits out an error message:
./prog.go:8:4: cannot use 3 (type untyped int) as type string in assignment

Okay. But what happens if we try to dynamically reassign to the existing variable a?

package main

import "fmt"

func main() {
    a := "bc"
    fmt.Print(a)
    a := 3
    fmt.Print(a)
}

Unsurprisingly, we get the same error as before, but also a complaint about trying to assign a variable using the type-inferring := operator:

./prog.go:8:4: no new variables on left side of :=
./prog.go:8:4: cannot use 3 (type untyped int) as type string in assignment

OK, so what if we redeclare the variable as a different type after we use it?

package main

import "fmt"

func main() {
    a := "bc"
    fmt.Print(a)
    var a int
    a = 3
    fmt.Print(a)
}

No dice:

./prog.go:8:6: a redeclared in this block
    previous declaration at ./prog.go:6:2

Just as an aside, what I do really like about the stack trace here is that it doesn’t just bomb out with “type mismatch” or whatever. It’s actually quite friendly - it tells us that on line 8, position 6 a redeclaration of a variable occurs, and even where it was originally declared.

But why all this hassle about typing? I just want to cram stuff into my variables

The reason for static typing is, unsurprisingly, efficiency of execution. Because the program isn’t constantly checking the type of information in variables that it processes to see what it can do with them, it’s simply faster to run. This plays right into the fact that Go is a compiled language, so all of that checking and translation into machine code is done once at the compilation stage, not every single time the program is invoked. Efficiency!

So, while it makes little sense to have your little script that you use to sift through information that you pass it on occasion written in Go, if you’re having something chomp on lots of data or be invoked lots of times, the efficiencies become clear.

But there isn’t one type of programming paradigm that’s dominant at the expense of others. If all you have is a hammer, then everything looks like a nail. You’re going to need the right tool for the right job, and statically typed and compiled languages like Go are the right tools for particular jobs.

Getting information out of variables

Let's declare a few variables and use Go's syntax of printing information about them (fmt.Printf()):

package main

import "fmt"

var (
    DemoString string  = "Hello, world!"
    Boolean    bool    = true
    FloatingPt float32 = 1234.567
)

func main() {

    fmt.Printf("DemoString is a variable of type: %T. It has the value of %v", DemoString, DemoString)
    fmt.Printf("Boolean is a variable of type: %T. It has the value of %v", Boolean, Boolean)
    fmt.Printf("FloatingPt is a variable of type: %T. It has the value of %v", FloatingPt, FloatingPt)
}

This gets you:

DemoString is a variable of type: string. It has the value of Hello, world!
Boolean is a variable of type: bool. It has the value of true
FloatingPt is a variable of type: float32. It has the value of 1234.567

It's important to note here that you cannot print the name of a basic declared variable in Go. As the human-readable names are discarded at compile time, you're left with just their values and types. That's why in the above example I had to manually put the name in to the string I was printing, and then get the value and type from the program itself. Also notice that the interpolation proceeds left to right with references at the end of the line, so for every interpolation you have to declare the variable to be used at the end of the expression.

References and further reading

A Tour of Go - Basic Types
I Finally Understand Static vs Dynamic Typing and You Will Too!
Cover image: Photo by Mika Baumeister on Unsplash

Tomorrow, who knows? It’s a Friday, so I might be doing this with a glass of wine…

Getting Going with Go, Day 3

Kai — Wed, 27 Jan 2021 18:53:51 +0000

Compiled files in Go

A slight digression today. I noticed that the compiled size of my “hello, world!” program from yesterday was a whopping 2 megabytes, so I’m going to explore reasons for that along with what happens at compilation time.

kai:~/helloworld/$ ll
total 4200
-rwxr-xr-x  1 kai  staff   2.0M 26 Jan 15:12 helloworld*
-rw-r--r--  1 kai  staff    74B 26 Jan 16:43 main.go

So, of course, the first thing I did was to create an “empty” program that does absolutely nothing. Its source code is as follows:

package main

func main() {

}

After running go build on that, turns out the Mac executable is still 1.1MB. So, the base minimum size for any Go program is over a megabyte. Still, they compile and run extremely quickly, so maybe that’s not a bad thing? We have plenty of bandwidth and memory these days…

But what are the reasons for such relatively large binary files for things that are so simple, or in the case of the above example, do nothing at all? Turns out, unsurprisingly, it has to do with what’s bundled into the executable. The official Go FAQ goes into this in a bit more detail, and compares the build size of a Hello World program in C (750KB or so) and in Go (2MB). The key here is in the concept of static linking. All the packages and required assets are bundled into one thing that gets compiled for a specific computer architecture. That means that my compiled Go program can be sent to anyone with a Mac and it will just run. No requirements to check “oh, do you have X installed?” or “make sure you are running version X of Y”. It just runs. The file size is the price you pay for that.

The bundled information alongside the raw "this is what your program will do" includes some clever debugging and stack trace information, according to the Go FAQ. This is borne out by the analysis done by Raphael 'kena' Poss at Cockroach Labs which shows that the runtime information, as in "this is what your computer needs to know about running this code" is 900K of any given Go program.

If I'm only using one (the Println) method of the fmt package, is it worth importing the whole thing? The answer, at least to me today, right now, is "yeah". There is zero incentive for me to start learning inventing the wheel to implement some sort of "print to screen" functionality in order to shave off some Kilobytes. I'm not programming for the Demoscene anyway.

This interesting sidetrack has got me reading about all the Go standard library. There's implementations for everything from zipping and unzipping files, as well as encoding and decoding jpeg files. Personally, I've always found it a bit of a mental challenge to find out "has X already been implemented, and how to find out about it?" as well as remembering all of it. I think a good rule of thumb might be to rubber duck as I go and google "how to do in " pretty much before I do anything new to avoid an embarrassment of "uh, why have you implemented a horrendously inefficient way to do this when there's a perfectly good internal method provided by the standard library?"

References and further reading

Go Standard Library
“Why are my Go executable files so large?” on Cockroach Labs
“Why is my trivial program such a large binary?"
Cover image: Photo by freestocks on Unsplash

Short one for today, as I have had a headache all day. Hopefully more in-depth tomorrow.

Getting Going with Go, Day 2

Kai — Tue, 26 Jan 2021 17:21:59 +0000

Yesterday, I outlined what I was looking to do and achieve with this learning diary, and got set up with Go by installing it and an extension for VSCode to help us along.

Today, I'm going to write my first Go program. Baby steps!

Hello, World!

Writing the program

Today's task is to be writing the classic starter program for any language, one that outputs a "hello world" message to the screen. I'll try to go through the code line by line and come to an understanding of what it does. Of course, this is only scratching the surface, but shows the structure of the language.

Let's start in a directory called helloworld, where we will create a file called main.go. Into main.go we'll put the following, which I've marked with line numbers. You'll need to leave them out when you type your program in:

1 package main
2 
3 import "fmt"
4 
5 func main() {
6   fmt.Println("Hello, World!")
7 }

Before we get antsy and run the program, let's run through what we've written line by line.

Line 1, package main is our definition where we say that this package we are writing is to be the main executable of our program. If we were to create other packages that we use in our program, we would have to declare them as such in their own files.

Line 3, import "fmt" says that within this program of ours, we'd like to use the fmt package. fmt is part of the Go standard library. It provides for formatting functionality of input and output, which means that we can use it to print to the screen. Fairly fundamental stuff. If your program wasn't ever going to print any output or take in any input, you wouldn't need to import the fmt package, saving on your program's footprint.

Line 5 is the start of our main function. main() is a special type of function , which is the one that gets executed first when the program is called. Think of it as the doorway into the program. Having this structure makes sense, as Go aims to build and improve on standards and structure set by the C family of languages.

Functions in Go are defined with the syntax func functionname() and a pair of braces / curly brackets ({}). In the case of our program above, the function main, including its declaration and delimiter braces, encompasses lines 5-7.

Line 6 is the command to print our message to the screen. It uses the Println (print line) method of the fmt package, with the contents to be printed enclosed in parentheses. Because we are printing text, it needs to be enclosed in quotation marks. You can of course play around with the contents of the string "Hello, World!" to have it print whatever you want. Just make sure that you enclose everything you need to be shown on the screen by the Println method in quotation marks. It won't work if you don't.

Line 7 rounds out our main function by closing it off with the closing brace. If you wouldn't, the computer wouldn't know where the thing is meant to end, and running the program would fail.

Running our program

Unlike interpreted languages like Python or Ruby, we can't "just run" our program. Instead, we'll have to build it to an executable:

kai:~/helloworld/ $ go build

This packages everything we need to run the program into machine-readable code. If there were no errors, you should see no output, but when you list the files in the directory, you should see an executable file called helloworld, the same as the directory it's in.

If you run the executable, you should see your program output a friendly greeting!

kai:~/helloworld/ $ ./helloworld
Hello, World!

Editing our program

If you wanted to change the output of the text from "Hello, World" to something else, you would need to save the file and run go build again. Changes to your compiled program won't appear if you just make them in the source code.

References and Further Reading

How To: C/C++ Main
James Mills' "Learn Go in Five Minutes" GitHub gist
Package fmt documentation
"Understanding Golang Packages" on The New Stack
Cover image: Photo by Dominik Scythe on Unsplash

Next, I think we'll look a little bit deeper into compiling our program and Go modules.

Getting Going with Go, Day 1

Kai — Mon, 25 Jan 2021 16:05:30 +0000

The Why of this exercise

Yesterday, on my birthday, I decided to start documenting my daily progress on exploring a new programming language: Go. It’s not going to be quite a #100DaysofCode, as I aim to have it be more concise than a hundred days, but I will try to document every day’s progress, no matter how small or inconsequential-seeming at the time. I will include references to materials I used, as well as further reading at the bottom of each article (I did spend years in academia, after all…) so hopefully you will find something of interest there.

This is the first instalment, where we get set up and ready to Go. I am using a Mac, so any instructions and code below will be from that vantage point, but similar commands will exist for Linux and other operating systems as well. But first, a bit on the dual reasons I am pursuing this GOal (and why you have to deal with these strained puns).

Go, sometimes referred to in hashtags as Golang, is a modern programming language originally developed at Google to take in some of the best parts its designers liked in other programming languages, namely static typing, high performance and usability. As a project, it tries to marry the three strands of programming not often seen as available together: "One had to choose either efficient compilation, efficient execution, or ease of programming; all three were not available in the same mainstream language". So we’re looking at a robust and performant language that aims to not be esoteric or demand deep knowledge of issues such as memory management and garbage collection from a programmer. Sounds good.

I am a relatively newly-minted software developer. On a daily basis, I chiefly work with Ruby (and Ruby on Rails) meaning I am used to working with an interpreted language, duck typing, a big friendly framework with lots of syntactic sugar giving me nifty helpers, and a robust codebase in my workplace’s application to which I can refer and from which I can crib.

The chief focus of the company I work for is managed Kubernetes. While I haven’t worked on the underlying infrastructure layer or the operators that make our particular offering work, both they and Kubernetes itself are written in Go. You can see where this is going: I want to be able to understand what is going on when I peek behind the curtain, as well as maybe in the longer term even be able to contribute!

So, to summarise: I am looking to improve my knowledge of different types of programming languages. With Go being statically typed and compiled, as well as both well-documented and the language used in an element of what my company works with, it makes sense to pick it for study. Nothing quite like diving in head-first, right? At least this way the worst we can do is write programs that just don’t work, rather than hurt ourselves.

Installing Go

As mentioned, I’m on a Mac, so I was able to install the tools to build Go code into programs using Homebrew: brew install go. If you are on another operating system, or are not using Homebrew, your first port of call should be the binary distribution for your OS.

At the time of writing this, brew installed version 1.15 of Go:

$ brew install go
==> Downloading https://homebrew.bintray.com/bottles/go-1.15.5.mojave.bottle.tar.gz
==> Downloading from https://d29vzk4ow07wi7.cloudfront.net/70969a6147bad6960136bdea78063d39b527c993a725ad525a3cf6e9f8ad6
######################################################################## 100.0%
==> Pouring go-1.15.5.mojave.bottle.tar.gz
🍺  /usr/local/Cellar/go/1.15.5: 9,784 files, 494.2MB

Let’s make sure everything is set up. If the following command does not work for you, you may need to set your $GOPATH variable to make sure your operating system will know where to look for Go when you run it. Try running go in your home directory:

kai:~ $ go
Go is a tool for managing Go source code.

Usage:

    go <command> [arguments]

The commands are:

    bug         start a bug report
    build       compile packages and dependencies
    clean       remove object files and cached files
    doc         show documentation for package or symbol
    env         print Go environment information
    fix         update packages to use new APIs
    fmt         gofmt (reformat) package sources
    generate    generate Go files by processing source
    get         add dependencies to current module and install them
    install     compile and install packages and dependencies
    list        list packages or modules
    mod         module maintenance
    run         compile and run Go program
    test        test packages
    tool        run specified go tool
    version     print Go version
    vet         report likely mistakes in packages

Use "go help <command>" for more information about a command.

Additional help topics:

    buildconstraint build constraints
    buildmode       build modes
    c               calling between Go and C
    cache           build and test caching
    environment     environment variables
    filetype        file types
    go.mod          the go.mod file
    gopath          GOPATH environment variable
    gopath-get      legacy GOPATH go get
    goproxy         module proxy protocol
    importpath      import path syntax
    modules         modules, module versions, and more
    module-get      module-aware go get
    module-auth     module authentication using go.sum
    module-private  module configuration for non-public modules
    packages        package lists and patterns
    testflag        testing flags
    testfunc        testing functions

Use "go help <topic>" for more information about that topic.

Setting up our IDE for Go

The next thing is to prepare my editor to deal with Go. I am using Microsoft’s VSCode, which has a big plug-in/extension for Go available, along with lots of other extensions that I might explore later. Go code can be edited in any text editor, though, so go wild with whatever you’re comfortable with.

You can get the official VSCode Go extension by searching for “go” in the extensions menu, or from this site. I am especially looking forward to utilising the IntelliSense code completion suggestions and the integrated linter.

That’s it for today. Coming up next: Taking our setup for a spin and writing our first lines of Go!

References and further reading

Go (Programming language) on Wikipedia
The official Go Wiki
How I Start: Go
If you’d like to try playing with Go without setting anything up locally, the Go Tour runs in your browser: https://tour.golang.org/welcome/1
Go FAQ, specifically the section on reasons for creating Go, and its historical antecedents
VSCode Go extension features documentation

2020 Working From Home Equipment Retrospective (and What I Aim to Upgrade in 2021)

Kai — Mon, 04 Jan 2021 14:31:11 +0000

Introduction

I am thankful that in 2020 I was able to transition to working from home and that the Covid-19 pandemic didn't affect my employment situation. In fact, I learned a lot about what sorts of things I appreciate about working from an office, and what things I really could do without. This post aims to document some of the equipment I used throughout 2020 to get work done, what I thought about it, and what I hope to upgrade or change in the year that has just started.

Hardware

My daily driver computer is my work Macbook Pro from 2015. I am absolutely a fan of the pre-touchbar Macbooks and their longevity. The laptop itself does everything I need it to do as both a web developer and developer advocate. In daily use, I keep it connected to power, on a stand housing my audio interface and USB hub.

The interface itself is a Focusrite Scarlett 2i2 3rd generation. I bought it in the summer as a way of plugging in my guitar and being able to play with effects without having to turn on amplifiers and driving the neighbours crazy. I later also plugged in an XLR microphone, more of which later, and I have zero complaints about the Scarlett overall.

Also evacuated from the office when the UK lockdown started in March 2020 is a Samsung U28E590 HD monitor. I keep the laptop screen on for things like Slack and email that I only look at occasionally, and have my terminal, IDE and the like on the big external screen.

Furniture

This is the one section where I dreaded spending money when the situation with working from home was uncertain: would it be worth splashing out on office furniture if it was all going to blow over in a few months? Turns out it didn't blow over, and I'm glad I put in a bit more money than I initially wanted. Three weeks of working at a dining room table was more than enough, thank you.

I bought a Mercury Row computer desk for two chief reasons: Adjustable feet, as not a single surface in my house is level, and a reasonable 75cm surface height. I'm not especially tall, but I just can't abide dinky desks that I have to slouch over. I have bad enough posture already.

I threw an "executive chair" into the same order, and it's okay. The gas spring started sagging within a few months, for which they partially refunded me and I've been too lazy to get a third-party replacement. What annoys me is that the armrests have zero adjustment possibility, meaning I have to change seats or stand up if I want to play some guitar at lunch or after work.

Peripherals

I joined the clicky keyboard crew in 2020, when I wanted a smaller form-factor keyboard to not require me to reach so far for the trackpad. So I bought a Keychron K6 with Gateron Brown switches, which I promptly customised with uniform-height DSA profile keycaps. I like that it is a multi-device Bluetooth keyboard and has separate modes for MacOS, Windows and Android.

For a mouse, I have an Apple Magic Trackpad 2 configured with tap-to-click. It's the first thing I turn on with any trackpad, and wouldn't want to live without it. As I don't do any precision work with the mouse, having a stand-alone trackpad is great because I don't have to change the orientation of my hand or anything when moving from the keyboard to it. I'd still like to minimize the use of a mouse and the rotation from the elbow and shoulder further, though.

My headphones are a pair of Sony's WH-1000XM3 noise-canceling headphones, but I tend to use them wired up to the Focusrite Scarlett rather than wireless or with the noise-canceling turned on. I know a lot of people swear by the Bose QC series, but they just didn't feel as nice to my head as the Sonys do. My main gripe with the WH-1000XM3s are the absolutely dreadful touch panel controls that I had to just turn off when using them wirelessly, followed by the fact that the 3.5mm jack socket is set so deep that most cables aside from the one supplied with the headphones won't fit.

My microphone, not pictured above as it was a later purchase, is a Tonor TC-20. Given my office room isn't treated in any way for acoustics, it sounds lovely. The boom arm and mount feel solid, and the clamp to the desk has been improved and increased from pictures I've seen online. For a £45 (US$60) combo, it was a really good purchase. Even if I were to upgrade the mic itself the shock mount and boom can be used. Obviously, being an XLR microphone it requires an external interface, but for that I have the Scarlett.

Software

I use VSCode as my main IDE. Whether it's doing Ruby on Rails work for Civo's website, or writing scripts or YAML, I find that the various linters, theming options and source control tools are really helpful. Picking changes in code merges is actually about as pleasurable as I can imagine it ever being. It is heavy and occasionally takes a while to get started, but I guess that's the price you pay for all the tooling loaded in. (If anyone wants to help me set up vim to look and feel like VSCode, I'm all ears.)

I'm bad at using the integrated VSCode terminal. Instead I tend to Command-tab to iTerm. One of the things I'd like to learn to do more with in 2021 is tmux and the like. I've always been super impressed when colleagues do demos of multiple panes running commands and updating with changes.

After far too many years of memorizing increasingly complex passwords, I went all in on 1Password this past year. It's an absolute godsend, really. I honestly feel good about the fact that I don't even know what my passwords are anymore. Being able to store occasionally-useful strings like frequent flyer numbers (LOL remember when those were useful?) in the same app is really useful. I can't recommend it enough, plus their support is world-class.

I use Firefox to browse the web in normal use, but obviously dabble in Chrome and Safari when I'm doing web dev stuff to make sure it all looks like I need it to.

For streaming music I use Spotify. I can't say I know of any other streaming service that offers the type of discovery mechanic they have developed. I have my issues with songs repeating on Discover Weekly with suspicious regularity as if labels can pay to get on there, but overall being able to sync across devices and have it everywhere is pretty neat.

Other

My home network, before being routed to the Internet via Virgin Media's hub, has a Raspberry Pi 3 running PiHole to provide DNS-level ad blocking to all devices in the house. It's a thing you get so used to and don't think about until you see what pages look for others not on your network.

Upgrades and changes

As mentioned above, I'd absolutely want to get a different chair. Having adjustable armrests is something I miss a surprising amount, and being on the heavier side of human I worry about all the creaks and other noises from the chair.

You may notice the conspicuous lack of a camera being mentioned in this post. While I've done a few online meetups, my camera setup does need work and I'd be up for hearing recommendations. I ordered a green screen in November but ended up canceling that order because of reviews that weren't as glowing as I was led to think.

If I was made of money, I'd absolutely want to get a split ergonomic keyboard like the ZSA Moonlander. I think they're gorgeous.

One of my personal 2021 projects is also to integrate PiHole-style ad blocking to the VPN I use while out and about. Obviously, that's not been a priority in the past year given I've hardly left the house!

Moving conditionally-rendered DOM elements to a dynamic location on a page with jQuery

Kai — Fri, 27 Nov 2020 17:00:21 +0000

For my own reference, and perhaps of help to you, here is how I manipulated the position of DOM elements (a <div> tag displaying a status message) on a page when it gets rendered, based on the currently active element on the page. This allows for a shorter feedback loop from user action to status update, and keep user focus on what they are doing.

For this project, I had a controller action check status on the back end based on user input. The status message returned by the controller was best served directly in the relevant element that the user had tested, out of multiple possibilities.

As the project runs Rails, it displays status messages in the "Flash" message element in the view. It was this flash element I wished to move from the usual place at the top of the screen to the relevant "active" form the user had clicked on to check. So as to not repeat code conditionally and render flash messages specific to each controller method, I decided to use a quick JavaScript/jQuery hack to move the rendered message, encapsulated in its own HTML element, to within the currently-active page element, to give the user the closest feedback to what they needed to do.

The code itself is a declaration to run a function moveAlerts once the page loads. The moveAlerts function is a conditional that checks if there is an element called alert in the DOM, and if there is, it uses jQuery's prependTo method to add it to the top of a <div> that is classed as open.

The code is as follows, and in my case is in a in a "page-specific javascript" block in my view file:

<script>
{
  $( document ).ready( moveAlerts );

  function moveAlerts() {
    if (document.getElementsByClassName('alert').length) {
      $( 'div.alert' ).prependTo( 'div.open' );
    }
  }
}
</script>

To use something like this yourself, you would need to edit it to correspond to elements in your document - you may want to move an element with a different name to "alert", or not have a <div> called "open" to move the alert into. Of course, if you are not using Rails, you would just need to put the <script> block in the HTML for your page rather than dealing with page-specific javascript blocks.