There are some out there in the industry that will swear by the criticality of test coverage. The conclusion seems to be that 100% test coverage equates to 100% correctness. However, that simply isn't true in all cases.
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.