I’ve always hated the ways that I figured out where my main was in Go. There was never a good way of doing it across all of my projects. I’ve hard coded my build scripts to the root of the project or build every directory under the cmd folder. Your main can live anywhere though, and this has always been an issue for me larger projects. Why not have a main deeper in your project to show how to use a particular package.

Learning Rust I first learned about Rust when Mozilla announced they were developing an experimental browser engine in the language in 2010. I was a sophomore in college and thought it was an interesting project. It was the first time I learned about the difficulties of programming in C and C++ and thought that creating a new language to get rid of the problem entirely was a novel solution. My only experience in programming was from my intro classes, which were taught in Java and Perl.

Task 2: Unique ID Workload The unique-id workload is the second workload we’re going to create. It’s to be a globally unique ID generation system that must create non-duplicating IDs. It has no requirements besides being available even in the face of network partitions. Requirements Our system must be globally unique and return unique results in the face of a network partition. These requirements mean: We can’t return duplicate results We can’t coordinate The first requirement should be reasonably straightforward.

Task 1: Echo Workload The echo workload is the “hello world” of Maelstrom. It allows us to get a handle on how to get a request and how to respond to maelstrom’s request. The workload is extremely easy to implement and the total implemenation is included in the fly.io workload explanation. Maelstrom basics First we’ll go over a reminder of what Maelstrom is and how it works. Maelstrom is a workload execution engine for creating toy workloads for different kinds of distributed systems.

Introduction In February, 2023 Fly.io published a blog post introducing a series of exercises for distributed systems. They are ways for people to exercise their understanding, practice and debugging of their systems. Here we’ll go over the exercises, how communication works and creating the initial “hello world” binary. The exercises are called gossip glomers and uses maelstrom to test the different systems that we’re going to write. Any distributed system communicates with clients and nodes over the network and can run into any number of issues depending on what the system is supposed to do and how it’s written.

Dynamic Docker builds in GitHub Actions I recently decided to turn my Docker image builds from on-demand (manual) builds something that GitHub actions can take care of for me. I’ve already setup Docker builds for singular applications. By this was a bit different. I had several docker containers with on code, just container modifications. The git repository was a monorepo with several directories, one for each container. Some directories held source files for managing a container but no Dockerfile itself.

Using vim or neovim as an IDE What makes an IDE There are a number of features that I think are generally found in an IDE. Starting with the simplest to the ones that are more complicated. All of the following features are generic and can live directly in the editor. Navigate and edit different parts of a file (Editor as opposed to writing directly to a file) Find and Replace Opening multiple files, either by splitting the page or by using tabs Viewing multiple files and directories in reference to the open files (directory tree) Syntax highlighting Triggering an action periodically ** Test or build on save ** Periodically save Displaying information about version control, the file, and system settings in the editor Editing a file in multiple lines at the same time Remapping functionality to different keys The following ones are more language specific.

Building a Docker Container with GitHub Actions This builds off of my previous post Getting Started with GitHub Actions At the end of my last post we have an initial GitHub actions workflow that we can use to build and test our application. We can build off of this to create a slightly more complicated workflow. After this is done we’re going to create a docker container with our application inside.

I’ve been wanting to run a local docker registry cache and go module cache for a while. It wouldn’t necessarily speed up initial image pulls but when I want to clear out the local cache or do a fresh build. It can also be used for testing local development services while also running our services in something that’s a little easier to setup (in my opinion) than docker-compose. It’s also easier for me to reason about than using something like minikube because it’s using my local network instead of a virtual machine.

GitHub Actions provide a way to execute tasks in a series of workflows. It can be used to build a CI/CD service using custom code or code that was built by the community. The workflows are generally limited by the number of jobs, API requests and execution time. It’s also possible to host your own runner which would allow access to private resources such as locked down services. We’re going to use GitHub actions to test, build and release our Go Vanity URL service that we talked about previously.