Tuesday 31 May 2016

Formatting Go code

One of the best features of the Go tool portfolio is the "go fmt" command, in my opinion. This takes a file or a directory as parameter, and formats the Go code in a predetermined coding style. This has several advantages (see go fmt your code):

  • it becomes easier to write code - never again worry about how to format code, just run the formatter
  • it becomes easier to read code, since all Go code easily can be formatted to the same style
  • it becomes easier to maintain for the same reason
  • all discussions or bickering about code formatting issues goes away instantly

All of this makes for easier development and removes "coding noise". Best of all, the Go formatter can be integrated into lots of editors and IDEs. Then the formatting becomes transparent, so all that needs to be done is saving the code, and the formatter is run automatically.

Wednesday 20 April 2016

Go 1.6

Go 1.6 was released in February 2016, with an update to 1.6.2 in April. Some major improvements are support for HTTP/2, changes to vendoring and important changes to cgo usage. Also some performance improvements to the garbage collector, and some packages.

Have a look at the release notes for more information.

Sunday 6 March 2016

Understanding GOPATH

During the process of writing the Bing Web API in Go, I learned a lot about how to use the GOPATH environment variable properly, and assembling all my projects in the same project path. Doing this makes all Go development easier. It actually took me a long time to accept that this was the best way to do it, but now I'm reorganising all my code to fit this pattern. 

For those who want to have a better understanding of GOPATH, have a look at the go environment variable and the go build package. It basically says


            bar/               (go code in package bar)
            quux/              (go code in package main)
        quux                   (installed command)
                bar.a          (installed package object) 
In my case "foo/" is "github.com/borglefink/" and "bar/" is "bingapi/". All new projects hosted at my github.com account are added as siblings to "bar/" (like the suggested "quux/" above). Each of those "siblings" are connected to their own git repository. If I don't have my projects open-sourced, I can keep them on the "foo/" or the "bar/" level, whatever works for me.

If you don't quite "get" the structure, I really recommend looking at the documentation mentioned above.

Bing Search API in Go

In my thesis work I'm currently using Node.js (with Express etc, etc) as a client for doing web search with the Bing Search API under the hood. This works fine, it is snappy and a delight to work with.

However, under the hood there is more than meets the eye. Bing Search API has a "page size" limitation of 50, and a overall search limit of 1000 (searching through the API will give 1000 results as a maximum). This means that to get the 1000 results, 20 searches รก 50 results is necessary. 

This is not entirely straight forward due to Node.js' asynchronous nature. Some plumbing is needed to be sure that all 20 search results have arrived before presenting this to the user. There are ways around this (like showing the first 50, and putting the rest in storage when they arrive), but I wanted to get all results at the same time. So some synchronisation was needed.

As a part of testing the API, a set of offline (batch) routines was devised, and I decided to use Go for this. Using a language for this designed for concurrency must be smart, yes? Only there wasn't a full Bing API for Go. 

So I wrote one. Have a look at the source code at GitHub, and the documentation at GoDoc.