Coming from the world of Perl, one thing I find to be a weakness of most languages is their lack of CPAN. Having a comprehensive archive of all the code that is shared and mattered is amazing. You can cache locally. You can carry it with you on a laptop (at least, if you just want the most recent versions of everything). You can grep it. You can run a local documentation repository easily.

This is just to settle a dispute that mostly exists in my own head. It likely matters very, very little. However, it matters enough. I am currently interviewing for new jobs and during one interview, I was asked to design an algorithm for which I needed a set data type. Golang provides no built-in set data type, but it does provide a map, so I defined my set as follows:

Almost exactly two years ago, I began a little side project to create an email parser. I wanted to port an email sorting system I had previously written in Perl to Go. There was no particular reason to have my own email sorting system or to port it to Go except that I could and because I wanted to learn more practical skills in Go. However, in the process I was unable to find an email message parser which was able to meet all of my requirements.

The headline is a little bit click-bait-y, but I want to highlight one of the easily overlooked risks of using slices in Golang. First of all, there’s nothing really wrong with the way slices work. A trade-off was made. It is not necessarily the same trade-off I would make, but such is engineering. Consider Arrays First, let’s map what a slice is because it might not be obvious unless you’ve been writing Golang programs for a while.

Updated 2023-01-11: This update is looooooong overdue. I had it dated as of May of last year and then never published it. My mistake. However, thanks to a reader, c0nscience, I am coming back around and geetting this correction made. He also suggested another implementation for reference by Jeff Linse on Github. After writing this post, I started working on some other projects and also started on another branch. Apparently, my testing of this change was very inadequate.

For the past seven years, I have been working for ZipRecruiter, helping them build their software platform. My time there has now come to an end. I have had a most excellent time at ZipRecruiter, and I want to take some time to reflect on my experience there and share some gratitude. The start of my employment at ZipRecruiter takes me back to 2015 (the picture here is of me from my first week).

I recently decided it was time to finally get around to upgrading my old 1.16 Kubernetes cluster to something modern. I mean, I’d been applying incremental upgrades via kops for years, but it was now getting to the point where moving forward would be difficult without updating the practices used to manage and run the cluster. So my cluster consists of a few minor bits of work I do on the side:

What a year, right? I had a whole load of blog posts planned for 2020, a talk to prep for YAPC, but the Lord decided that He had a better plan. I don’t know that anyone is going to read this, but I want to take some time to process what happened to the technical arm of it along the way. The biggest change to my life technically is that I don’t think I have written more than a dozen edits to a Raku program in the last 15 months.

I recently had some friends ask me to describe my work-journal, so here we go. I am here giving a snapshot of my current journaling practices. When it comes to organization, I am not very consistent. In fact, between the first draft and publishing, I changed some of the details already. So, let’s hurry this up before I change something more drastically. The Tools I keep two separate journals: one for work and one personal.

One of the earliest modules I wrote for Raku (then Perl 6) was ArrayHash. ArrayHash is basically a Hash that preserves key insertion order. I don’t remember what I originally wrote it to do, but I do still use it in one application I use every year or so to help me with a complicated task at work. I don’t actually think the work itself is very interesting, but you might learn some bits about Raku internals through my work, so I hope this is useful to someone.