Why is it needed?

You’ve probably heard the following advice: functions expect to receive an interface and then return a specific type. I don’t remember where I saw this rule, and the exact wording may vary, but the point is that if a function’s argument is an interface, then the function is more generic and can accept arguments such as mock types for unit testing.

So whenever you feel like you’re missing an opportunity to have your function receive an interface instead of a structure, run Interfacer, and it’ll tell you the answer.

A case in point

Imagine one day you start writing a library of BBQ sensors to control the temperature of your Thanksgiving Turkey. The library contains an Alerter interface consisting of Alerter functions and a Sensor structure that implements Alerter.

type Alerter interface {
	Alert()
}

type Sensor struct{}

func (Sensor) Alert() {
	fmt.Println("Turkey is done!")
}

Copy the code

A few hours and a few thousand lines later (yes, you’re feeling productive for the day) you define a function sensorAlert that expects to receive a Sensor structure and call its Alert method.

func sensorAlert(s Sensor) {
	s.Alert()
}
Copy the code

You vaguely remember that Alert belongs to some interface, but not which one. You’re too lazy to search for it (it’s 11 p.m., after all), so you run

$ interfacer bbq.go
Copy the code

Got this advice:

bbq.go:15:18: s can be Alerter
Copy the code

You quickly adjust the sensorAlert function and go to bed, because now you know you can easily pass the MockSensor structure to sensorAlert when you write your test tomorrow.

Interfacer on GitHub

zb:Quickly connect to go’s toolchain

After you’ve finished some work on your latest project, run Gometalinter. It takes a while to complete, at which point you find that some Lint tools have gone deep into the Vendor directory, and the output now contains a lot of useless messages.

Then you run Go Build and observe that the test fails. Oh, forgot to run Go Generate.

When you solve this problem, you realize that time has passed, so you want your tools to be faster and smarter.

Zb can help you solve this problem.

In contrast to previous tools, the ZB is a miniature Swiss Army knife. It provides a bunch of commands to speed up your development/build/test cycle. Some of the highlights are:

• Run parallel go Install commands whenever possible to speed up builds.
• Speed up testing and Lint tools by caching results.
• Automatically call Go generate, in case you forgot.
• To understandvendorDirectory, and retains some operations that are not in Vendor (for example, linting).

I can’t list all the commands available here; Otherwise you end up rewriting the README file. If you’re curious, check out ZB’s README.

Note: I agree with the author’s description of this tool as individual. On the other hand, you don’t have to use every command available. Just choose what you find useful and doesn’t interfere with the way you work.

zb on GitHub

realize:Trigger your toolchain with CtrL-S

The standard GO tools – Go Build, Go Test, etc. – are fast and simple, but as your project gets bigger and more complex, you start to expect some degree of automation that triggers all the build and test tools every time you save a source file.

Realize is your friend.

Activating go Build, test, Run, generate, FMT, etc., simply reverses some Boolean switches in the configuration file (not specifying the full command line).

In addition, you can add custom commands for pre-processing and post-processing, set paths to ignore, save output, logs or error streams in the build, and more.

In addition to a colorful output shell (you can quickly tell a build’s success by color), Realize has a Web UI that monitors all build progress in a browser window.

realize on GitHub

binstale:Is my binary up to date?

Do you know if the binaries in the $GOPATH/bin directory are still up to date? Use the go get command to happily install binary after binary, and then they start to dust. At some point you remember that you installed a nice tool that did something for you, and eventually you found it in $GOPATH/bin, but it didn’t work and gave some incomprehensible error messages.

You’re sure it works fine, so maybe the binaries are out of date? You decide to try updating the source code.

You do a recursive search in $GOPATH/bin to find the repository with the same name as the binary. And eventually you find this repository and you execute go Get here. This fixes your binaries, you feel relieved…

. Until you realize there may be dozens of old binaries in your $GOPATH/bin directory!

Meet binstale.

This widget will instantly tell you if a given go-gettable binary needs to be updated.

$ binstale realize
realize
    STALE: github.com/tockins/realize (build ID mismatch)
Copy the code

If you spend a minute or two more, it can do the same for all binaries.

$ binstale
CanvasStreamTest
    STALE: github.com/cryptix/CanvasStreamTest (build ID mismatch)
Go-Package-Store
    STALE: github.com/shurcooL/Go-Package-Store (build ID mismatch)
aligncheck
    STALE: github.com/alecthomas/gometalinter/vendor/src/github.com/opennota/check/cmd/aligncheck (build ID mismatch)
    STALE: github.com/opennota/check/cmd/aligncheck (build ID mismatch)
asmfmt
    STALE: github.com/klauspost/asmfmt/cmd/asmfmt (build ID mismatch)
balancedtree
    STALE: github.com/appliedgo/balancedtree (build ID mismatch)
benchcmp
    STALE: code.google.com/p/go.tools/cmd/benchcmp (build ID mismatch)
    STALE: golang.org/x/tools/cmd/benchcmp (build ID mismatch)
benchstat
    STALE: rsc.io/benchstat (build ID mismatch)
binstale
    STALE: github.com/shurcooL/binstale (build ID mismatch)
bug
    STALE: github.com/driusan/bug (build ID mismatch)
...
Copy the code

You may have noticed that some binaries have multiple matching repositories (alignCheck and benchcMP in the example above). Therefore, Binstale currently does not automatically update any binaries. But as soon as you copy and paste the repository path into GET-u, the update is done.

binstale on GitHub.

conclusion

These are just a few examples of the steady growth of command-line tools that make things easier for developers.

If you have a cool idea, don’t hesitate to sit down and write it out. But first, be sure to check out the public library – chances are the tools you think of already exist somewhere, thanks to the thriving Go community.