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). The year before, I had quit my job at an established firm, Grant Street Group, writing tax & billing and payment processing software. I worked as a full stack developer (though, I’m not sure we called it that in 2008 when I started). I quit that job to take a position working at a tiny startup, Bizowie, across the street making ERP software. The domains of both of these companies are pretty similar with lots of accounting for money and tracking how it enters and leaves the organization. The primary difference from my perspective as a software developer is that Grant Street Group works with local governments while Bizowie works with small to medium sized businesses. While this is not about either of those jobs, I want to talk about my last day at Bizowie as part of the setup for this story and part of how I got the job at ZipRecruiter involved a colleague I got to know at Grant Street Group.

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 have written hundreds or thousands of lines of Perl, but more than anything else, the past year has been the year of Go for me. I had dabbled briefly in Go since 2018 as I had also dabbled a bit in Dart, JavaScript, and read a little bit about Rust, but I have now transferred much of my expertise into Go. Virtually all of my O(fun) work is now being written in Go (except for microcontroller firmware).

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. The work journal is the one I use more regularly and is more structured, but both are pretty similar in overall form. I am focusing on the work journal here. My preferred notebook is the Rhodia Goalbook. This is an A5 size notebook with a dot grid, a table of contents, a monthly calendar, a daily calendar, and pre-printed page numbers. The paper in this notebook is thick and absorbent, which is very important to me since my preferred writing utensil is a fountain pen. I started collecting those a couple of years ago, but lets not get started there. This will be long enough already.

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.

I am going to be honest and upfront with you. I have almost no opinion about the name change of Perl 6 to Raku. I can see going to war for something meaningful, like religion. I cannot imagine doing so for something trivial, like a programming language. I won’t be upset if you call my hammer a mallet. There are certainly advantages and disadvantages to the name change, but as far as I’m concerned, it was inevitable as long as the issue kept being brought up year after year.

First, I want to say thank you to Andy Lester who has been project lead on vim-perl6 as well as the other contributors, especially Hinrik Örn Sigurðsson, Rob Hoelz, and Patrick Spek.

The plugin will now be homed in the new Raku organization on github here:

https://github.com/Raku/vim-raku

As of right now, it has been updated such that it will handle the old Perl 6 filenames as well as the newer ones, so far identified as .raku, .rakutest, and .rakudoc. It also handles .t6 which is something that the plugin didn’t handle previously.

I hope this calendar has been of some use to you all. In any case:

Merry Christmas!

Lots of big words in the title. In simpler terms, it means running a program in the background and interacting with it as input and output becomes available. The tool in Raku for doing this work is called Proc::Async. If you’ve ever dealt with the pain of trying to safely communicate with an external process, writing to its input and reading from its output and error streams and hated it, I think you’ll like what Raku has built-in.

Raku actually provides two different locking classes. A Lock object provides a very standard locking mechanism. When .lock and .unlock are used or .protect is called, you get a section of code that pauses until the lock frees up, runs while holding the lock, and then frees the lock so other code that might be waiting on the lock can run.

However, the Lock class works in such a way that blocks the current thread. As I’ve pointed out earlier in this advent calendar, the purpose of threads is to do stuff, so blocking them from running is preventing them from fulfilling their purpose. Luckily, there is a solution.