One aspect I did not include in My Personal Ecosystem is the way I use AWS Lambda to perform certain tasks using serverless code. I will start off by saying that I do not think serverless code is a good idea as a general purpose solution. It has been my experience that such solutions tend to be more expensive than running a pod in a cluster I already have in place.
I want to document for myself and for anyone who might be interested (probably mostly me, but maybe a prospective employer will find this interesting) the current state of my personal ecosystem of software, devops, and what I consider state of the art within my personal projects. This article is primarily concerned with ops, but will touch on aspects of software development too.
I will have to divide this up into major bits.
Someday I am going to finally get around to describing how I’ve build the ticketing system I have built for our local Bethlehem Revisited project, which I call Bert or (for the most recent implementation) Gobert. However, in lieu of a full post on that, I’m going to just talk about one aspect of what I did to complete my work porting the system to Golang. One of the problems I ran into this time around was a maintenance issue with the website, which is quite a simple Vue.
I am struggling to come up with a witty introduction to this topic, so let me just start by telling the origin story. Several years ago, I added some tooling to help me manage secrets related to my dotfiles. The first incarnation was a simple .netrc type solution where I stored the secrets in plain text in files that only my user could read. I added some scripts to help reading and managing these a bit.
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).
