For more content like this, buy my in-progress eBook, Data Serialization in Go⁠, and get updates immediately as they are added! Have you ever found yourself writing a custom JSON marshaler in Go, because you needed something only slightly different than what the standard JSON marshaler provides? Maybe the consumer of your JSON payload expects an array where you have a single item. Or maybe you need to nest your object one level deeper in your JSON than is used in your application.

How often do you find some code like this in your production code base? form.submit(function(event) { console.log("Submit hit"); var formData = { It’s obvious case of stray debugging code that never got cleaned up during code review. Or have you ever seen something like this, perhaps in your CI config? script: # - npm install # - npm test - ./script/test.sh This one is especially dangerous. It appears that someone commented out the core functionality of the automated test stage of CI!

One habit that I think every software developer, if not practically every professional in any field, can benefit from is that of solving every problem twice. Watch my video on this topic, too! I remember first reading about a similar concept in Joel Spolsky’s blog, Joel on Software, where he wrote back in 2007: Fix everything two ways Almost every tech support problem has two solutions. The superficial and immediate solution is just to solve the customer’s problem.

Go’s interfaces and “duck typing” makes it very easy to create simple mock or stub implementations of a dependency for testing. This has not dissuaded a number of people from writing generalized mocking libraries such as gomock and testify/mock, among others. Here I want to describe a simple alternative pattern I frequently use when writing tests for an interface, that I think is generally applicable to many use cases. No Silver Bullet Of course neither this approach, nor any other, is a one-size-fits-all solution.

In my programming practice, peer code review has become such second nature to me that it’s sometimes a challenge to articulate why I think it is important. I was recently asked this question, which forced me to think about it, and so now I want to put it into writing, lest I forget my answers. It’s just to reduce bugs, right? Before I jump into the list proper, let me address what I believe is a common misconception about code review.

Watch my video on this topic, too! In response to my previous article, Solo DevOps, a reader asked me to recommend a Continuous Integration (CI) tool to use with GitHub-hosted repositories. My choice is GitLab-CI, which integrates nicely with GitHub, even if you don’t want to switch to GitLab entirely. In this post, I walk through configuring GitLab-CI for a GitHub-hosted repository. I have chosen one of my real repositories, github.

I’ve been thinking a lot lately about how DevOps scales. DevOps, and related practices, get a lot of attention when it comes to scaling up at large organizations like Google and Netflix. But what about the other extreme of very small teams? This is a list of DevOps practices I use on the tiny scale: Solo projects. While most of these practices offer an immediate benefit, even for a single-person team, in most cases, the benefit grows as the team grows.

You’re building a complex piece of software. Then it comes time to deploy, so you spend a couple weeks stuffing it into a Docker container or a .deb or .rpm package, and debugging the build and deployment process. Then you add some sort of monitoring or logging, set up email or SMS alerts to tell you when it crashes, and probably a dozen other things to make it “production ready.”

This is the second installment in my series The False Dichotomies of Automated Testing. If you’ve ever met a recent test convert, you’ve probably heard them talk about the mythical creature that is “100% test coverage.” As with most benevolent mythical creatures, this one is highly sought after, and possibly even worshiped. It is claimed to have magical powers, although the precise nature of these powers is often hotly debated even among the most ardent of believers.

This is the first in a series of posts about automated testing for software developers. I’ve been fascinated by this thing called “programming” since I first learned I could enter BASIC programs into my family’s Commodore 64 when I was 8 years old. I became a full-time software developer in 2006. And I “got religion” about automated tests shortly after that. But still not everyone is as “enlightened” as I am when it comes to writing automated tests.

go-spew is a very handy library used for dumping arbitrarily complex data structures in a (roughly) human-readable format. This is immensely helpful when debugging or writing automated tests in programs. Coupled with a package like go-difflib, it can make comparing the expected and actual results of a test not only easy, but into something approaching fun. Much of my time lately is spent hacking on projects to be compiled by GopherJS, the Go-to-JavaScript compiler.