はてなブックマーク

Photo Credit: blaahhi Some concepts have names, and sometimes we care about those names, even (or especially) in our code. const ( CCVisa = "Visa" CCMasterCard = "MasterCard" CCAmericanExpress = "American Express" ) At other times, we only care to distinguish one thing from the other. There are times when there’s no inherently meaningful value for a thing. For example, if we’re storing products in

Lesser-known features of go test Most gophers know and love go test, the testing tool that comes with Go’s official gc toolchain. It is quite possibly the simplest thing that works, and that is beautiful. They know that running go test runs the tests for the package in the current directory, looking for *_test.go files, and within those files, looking for functions following the TestXxx(*testing.T

Photo Credit: t1ggr Dependencies. They’re knotty, and there really is no straight-forward, one-size-fits all solution. Dependency hell is a colloquial term for the frustration of some software users who have installed software packages which have dependencies on specific versions of other software packages. —Wikipedia I recently saw a comment on GitHub: When I run [the tests] they always pass, but

In Go, interfaces are implemented implicitly, meaning that the developer doesn’t need to declare the interfaces it implements. While this is usually very convenient, there are cases where you might want to explicitly check the implementation of an interface. The best way to do that is to rely on the compiler. Imagine that we have the following code: package main type Jedi interface { HasForce() bo