Go Modules is the official dependency management solution for the Go programming language. Recently, I finally converted over my personal projects. I had been putting it off for some time, since I was waiting for the Go team to finalize everything and work out all the kinks. Go 1.11 was when Modules was first released as a beta. Go 1.12 still had Modules in beta mode and Go 1.13 was when Modules came out of beta. After Go 1.14 came out, I figured it was probably time to transition over from dep (which is deprecated now). It was a mostly smooth experience, but I did run into some snags. For example, upgrading a package that has already had its major version incremented to 2 or greater requires a bit more work. In an effort to share my findings, here are some common commands I found useful.

When I attended AWS re:Invent at the end of 2019, I attended a workshop for using machine learning via Amazon SageMaker to teach an AI how to play blackjack. Seeing as re:Invent was held in Vegas, I decided to take the spirit of Vegas home with me and create my own text-based blackjack game in Go. I added a simple interface so it would be easy to create different AI opponents. I had another hackathon coming up at work and I thought it would be cool to try and train a model to play a better game of blackjack using SageMaker. This would be different from the workshop I attended in that they were mostly focused on recognizing a card’s rank and suit, whereas I wanted to look at dealer/player hand combinations and retrieve predictions on the outcome of various actions.

Another late post, but that’s just how it goes. I attended AWS re:Invent with some collegues back in December of 2019 in Las Vegas. The conference spans multiple hotels on the main strip and has something like 70-80k attendees. Since it was my first time attending, I wasn’t really sure what to expect. Turns out, I had a lot of fun! There were lots of opportunities to try out different AWS technologies.

This is waaaay overdue, but we had another hackathon at work back in September of last year and even though I’m waaaay behind on blog posts, I wanted to make sure I did a short writeup on my project. During GopherCon, I received a small Arduino Nano 33 IoT. Not exactly a powerhouse, but I wanted to do something with it. I bought a breadboard, sensors, wires, and other various components. I still didn’t know exactly what to create, just that I wanted the programming component to use TinyGo.

I recently spent some time figuring out how to gracefully shut down a Go service. The goal was to allow in-flight transactions to complete successfully before shutting down, but return Unavailable for any new requests. I found the solution to be fairly straightforward for Linux, but a little bit more tricky for Windows, specifically when running in a Windows Docker container.

General solution for handling termination signals (Linux/Darwin) #

For most use cases, the os/signal package works for capturing termination signals:

Another year and another GopherCon, this time in sunny San Diego! As usual, there were a lot of high quality talks across a breadth of subjects. I highly recommend browsing through the GopherCon videos on YouTube, but I’ll highlight what I thought were the interesting bits below.

The last year or so has seen a LOT of discussion around dependency management for Go, particularly around dep and Go Modules (formerly vgo). Previously, dep was the “official experiment” for dependency management for Go, but was superceded by a proof of concept called vgo that became what we now know as Go Modules. Go Modules is being actively developed in the Go toolchain and is the future of dependency management for Go. While dep is a fine choice, it’s clear that the Go team will be pushing Go Modules hard. This was made clear in Russ Cox’s introductory talk regarding the future of Go 2.0. I’ve always been more in the dep camp, but a lot of my concerns were alleviated by what I heard from Russ. Also, there was a fantastic talk later on by Aaron Schlesinger about Athens, a free, open source mirror for Go Modules. It seems to me that Go Modules will be in a good place to take over dependency management for Go in the near future.

My brother and I are in the early stages of development and design for a game we are making together. He’s the genius artist and I’m the programmer guy. Everything in-between we share, including map making. There’s an excellent free tool called Tiled that can be used to make 2D maps. It supports layering, automapping, animations, and even collision boundaries. In short, it’s a fantastic tool for creating 2D maps.

Unity is the game engine we are using. It’s very popular, full featured, has an excellent store for assets/plugins, and, most important of all, it’s free for small developers. We wanted to see if we could use Tiled maps in our Unity project and I was completely willing to write a script to load an exported Tiled map into our project. Turns out, there is already a fantastic free tool (you can make a donation to support the author) for doing just this. SuperTiled2Unity is a plugin for Unity that allows you to just drag and drop your Tiled map file and textures into the project assets folder and they get automagically imported.

We had yet another hackathon at work. This time around, I wanted to do something with Python. Since we have a gap in test data at work, I decided to create a script to generate oodles of fake test data using a Python library called Faker. It has a number of default providers for generating different types of data. It can generate fake addresses, names, dates, phone numbers, etc.

This simple code block:

When the theme for our latest company hackathon was revealed to be “Need for Speed”, I went straight to Best Buy after work and picked up a DJI Tello drone. I had been wanting one ever since I went to GopherCon and saw the presentation by Ron Evans where he used Gobot and GoCV to make a Tello drone follow his friend’s face around. Now that I had a drone, I needed to figure out what to do with it.

Something that Go does very well is multi-platform support. You can build a binary for just about any system without much hassle. On a single build machine, you can build binaries for Windows, macOS, and many flavors of Linux. All that is required is to change the GOOS and GOARCH env variables to the desired OS and architecture. I made a Makefile to take advantage of this.

First I started with a few variables. EXECUTABLE is the name of the program to build. WINDOWS, LINUX, and DARWIN are the actual names of the binaries to be created, based off of EXECUTABLE. VERSION is a version string derived from the latest git tag and commit hash, something like v1.1.1-8-g99740b5.

Recently, I had the need to process a near infinite number of messages asynchronously. You can’t just throw all the messages into separate goroutines when there are that many of them and more incoming. One solution is to use some sort of worker pool to manage the number of concurrent goroutines that can run. Here’s how I went about creating a worker pool (I’ve called it a task pool) in Go.

I had the privilege again this year to fly out to Denver and attend GopherCon, the premier gathering of “gophers” (people who program in Go). It’s a lot of fun and I learn something every time. After spending the weekend hanging out around town with my wife, enjoying Hammond’s candy and exploring the Denver Museum of Nature and Science, I started the conference with a machine learning workshop. It turned out to not be quite what I expected. I was hoping to spend more time with deep neural networks and current tools of the trade, like Tensorflow. Instead we spent most of our time going over machine learning basics, which I was already marginally familiar with. They did go over the math behind a few concepts, like linear regression and k-nearest neighbors. I found that to be interesting enough. Afterwards, they started setting up some arcade classics that could be played for free, so I knew the conference was going to good.