How I write unit tests in Go One of my favorite features of Go is that unlike many popular languages, it comes with it’s own testing framework, the testing package. Let’s say we have this trivial function in a file called numbers.go: package numbers func addNumbers(numbers …int) int { sum := 0 for _, number := range numbers { sum += number } return sum } The idiomatic way to test this function is to create a second file called numbers_test.

Spend any amount of time in programming circles, and just as the sun rises and falls, you are certain to hear someone complain about error handling in Go. These complaints are, anecdotally, rarely well thought out suggestions on what error handling could or should be like in a language like Go, but often merely boil down to “I don’t like having to look at it”. You’ll mainly see people complain about having to litter their apps with if err !

The premise Generating files is an inevitable consequence of writing most software, but in particular Go. For a very long time, the collective wisdom when asked about support for generics could be summarized as “just generate files for the types you need, that’s what generics support in the compiler would amount to,” and the ethos stuck with the community. In my primary side project, for instance, I generate service configs from Config literals, so that I know they will properly unmarshal when the service tries to load them.

I have a side project which, like most good software, uses a structured logger. Initially I used logrus, then I used zap, and then I found zerolog, which I’ve used now for a number of years. How did I switch loggers as many times without causing myself a headache? Easy, I maintained a simple Logger interface: type Logger interface { Info(string) Debug(string) Error(err error, whatWasHappeningWhenTheErrorOccurred string) WithValue(string, any) Logger WithValues(map[string]any) Logger WithRequest(*http.

The Life and Death of Sylvia Joyce My aunt Sylvia was my grandmother’s first child. My grandmother had married my biological grandfather against her guardians' wishes, he was in the military, so she was entirely alone when Sylvia came. My aunt Sylvia would live a full life of ups, downs, and the myriad things in between. She got married, divorced, had children, found love again, vacationed, sang, sewed, and more than anything, loved her family.

Context Recently I attended a 3-day seminar offered by a local venture capital firm called “Founder’s Academy,” hosted by Gordon Dougherty. I enjoyed my time in the lectures, and learned quite a bit, which I wanted to document here. I’m grateful to Mr. Dougherty for offering this free series of lectures, and was glad to have had the chance to attend. I’m also grateful to my managers at Allma, who gave me ample time off from work in the middle of the day to attend, and for being very encouraging of me when I was honest with them about what I was attending and why.

Preface I want to take the time before writing to note that I have great respect and appreciation for the folks who work at any of the companies mentioned and/or on any of the products mentioned. Computers are hard; making stuff that is primarily meant to be consumed by them is even harder. My goals here are similar to those of that post. I hope that there can be something constructive that comes out of this post, but at the very worst, I hope it simply doesn’t offend or disparage anybody.

Preface I intend for this post to serve as an experience report from a newbie AWS user. Hopefully you enjoy it and don’t feel like you’ve wasted your time at the end. I want to take the time to note that I have great respect for all the folks who make these companies work and who build these products. None of my opinions are directed at a human being who has a name and/or respirates.

A time gone by I’d like to tell the story of how I got into the software engineering field, but like any post I make on this website, I feel the need to justify the endeavor first. I’m sharing because whenever I’ve shared it with folks in the past, they seem to have enjoyed it and almost always ask clarifying questions in disbelief, which I think is a safe indicator that the story is maybe good.

A hammer wielded by a worker trained to hit things is a tool. A hammer wielded by someone intent on doing harm is a weapon. The hammer requires no metamorphosis yet starts as a tool and ends as a weapon. So, there must be a threshold where the tool becomes a weapon, what is it? When I write software, I don’t build things that do things, I build tools for doing things with.