Most any programming language has a way to express nothing, whether it's NULL, null, nil, or even None. But, what is nothing? Can nothing be something? More importantly should nothing ever be something?
For those coming from an Object Oriented language background to Go, it can be rather jarring to hear that there are no classes and thus no inheritance in Go. While this is strictly true, there are ways to "inherit" the same behavior and promote more code reuse in Go. Before we get started, it's important to understand why Go doesn't have inheritance - by design - and the problems that classical inheritance can create. We'll first approach a situation with inheritance and gradually move toward c…
Error handling is a critical aspect to making stable, maintainable software, and APIs are no exception. The single biggest source of ambiguity in API error responses I've found is the improper use of HTTP status codes.
There's one idea I've seen reiterated over and over again in relation to the Go language. What if it's actually fine?
Have you ever wondered how to translate some traditional design patterns to Golang, a language without classes or the OO concept of inheritance? Then you're in the right place. I'm going to go through a couple different ways to implement the Singleton pattern.
I really enjoy Go as a language and as a tool for making solutions. A key aspect of getting things done is making sure that a solution works. That's where testing comes in.
There's a huge difference between unit testing, and effective unit testing. I wanted to take the time to clarify such a critical (and often overlooked) practice in development.
I think that by now, most of us in the development community have heard about Test Driven Development and Behavior Driven Development, but how many people do you know that have consistently applied these practices and got the ROI from it?