発売されたのは約1年前だけど，最近仕事で Golang を書いているので，実践的なテクニックを学ぶために今さらながら「みんなのGo言語」を読んだ．WEB+DB PRESS のようなカジュアルさのある本で，1日でサクッと読むことができた．読み終わった後に，学んだことを実際に試してみたりもして，とにかく即戦力のある1冊だと感じた．

作者: 松木雅幸,mattn,藤原俊一郎,中島大一,牧大輔,鈴木健太,稲葉貴洋
出版社/メーカー: 技術評論社
発売日: 2016/09/09
メディア: 大型本
この商品を含むブログ (4件) を見る

`golint -min_confidence`

今までも golint は使っていたけど，各項目に Confidence というレベル設定があって -min_confidence オプションで閾値を決められるというのは知らなかった．golint の README にも書いてなかったけど，実際に golint.go を読んだら実装があり，デフォルトは 0.8 になっていた．もっと厳しくても良いのではないかなと思って，さっそく 0.6 に変更した．0.8 → 0.6 に変更したことによって追加で検知できたのは以下で，エラーメッセージの1文字目も小文字にするのがお作法なのかぁー，という気持ちだった．

error strings should not be capitalized or end with punctuation or a newline

`golint -set_exit_status`

デフォルトのまま golint を実行すると，コマンドの終了ステータスが 0 で返ってきてしまうため，今までは CircleCI で以下のようなワークアラウンド実装をしていた．

test:
  override:
    - test -z "$(golint $(glide novendor) | tee /dev/stderr)"

しかし -set_exit_status オプションを使うと，指摘が出た場合に 1 が返ると本書に書いてあった．よって，以下のように書き換えることができて非常に助かった．

test:
  override:
    - golint -set_exit_status $(glide novendor)

Makefile

最初は golint と go vet を circle.yml に直接書いていたけど，僕のチームに Golang のアドバイザーとして入ってもらっているメンバーに「Makefile で書きましょう」と教えてもらって，今は Makefile を使っている．まさに同じことが本書にも書かれていて，参考になった．なお make help の部分は本書で紹介されていた make2help は使ってなくて，以下の記事で紹介されていた方法を使っている．

postd.cc

ザッとこのような感じになり，CircleCI でも make lint を実行するだけで良いという状態になっている．

help:
    @grep -E '^[a-zA-Z_-]+:.*?## .*$$' $(MAKEFILE_LIST) | sort | awk 'BEGIN {FS = ":.*?## "}; {printf "\033[36m%-30s\033[0m %s\n", $$1, $$2}'

setup: ## Setup some tools
    go get -u github.com/Masterminds/glide
    go get -u github.com/golang/lint/golint

lint: ## Run the Golint in all directories without /vendor
    go vet $$(glide novendor)
    golint -min_confidence 0.6 -set_exit_status $$(glide novendor)

goroutine の停止

goroutine をどのように停止するかという話があり，まさに似たような実装を書く予定があって，チャネルをクローズするイメージで考えていたので，Go 1.7 以降だと context を使うのが推奨であると知れたのは非常に良かった．

実際に本書に載っているコードを写経して動作確認をしてみて，これだけだとあまりチャネルをクローズする実装と変わらないと思ったけど，最後に context.WithTimeout を使えば，タイムアウトの考慮もできるようになるメリットがあるという紹介があった．

とは言え，本書だけだと記載が少なく概要レベルの紹介だったため，以下の記事を読んで，より理解を深められたような気がする．

ベンチマーク

テストの章では，ベンチマークの機能を知った．実際に写経をして試したりもした．

cat.go

package cat

import "bytes"

func cat(ss ...string) string {
    var r string
    for _, s := range ss {
        r += s
    }
    return r
}

func buf(ss ...string) string {
    var b bytes.Buffer
    for _, s := range ss {
        b.WriteString(s)
    }
    return b.String()
}

cat_test.go

package cat

import "testing"

func seed(n int) []string {
    s := make([]string, 0, n)
    for i := 0; i < n; i++ {
        s = append(s, "a")
    }
    return s
}

func bench(b *testing.B, n int, f func(...string) string) {
    b.ReportAllocs()
    for i := 0; i < b.N; i++ {
        f(seed(n)...)
    }
}

func BenchmarkConcatenate(b *testing.B) {
    benchCases := []struct {
        name string
        n    int
        f    func(...string) string
    }{
        {"Cat", 3, cat},
        {"Buf", 3, buf},
        {"Cat", 100, cat},
        {"Buf", 100, buf},
        {"Cat", 10000, cat},
        {"Buf", 10000, buf},
    }
    for _, c := range benchCases {
        b.Run(fmt.Sprintf("%s%d", c.name, c.n),
            func(b *testing.B) { bench(b, c.n, c.f) })
    }
}

サブベンチマークという機能を使って書くことで，テーブルドリブンに書けるのは良かった．以下のような結果となり，文字列結合をする要素数が多くなればなるほど bytes.Buffer を使った方がパフォーマンスが良いということを確認することができた．すぐに仕事に活かせる知見だった．

$ go test -bench .
BenchmarkConcatenate/Cat3-8            10000000          164 ns/op         54 B/op         3 allocs/op
BenchmarkConcatenate/Buf3-8            10000000          181 ns/op        163 B/op         3 allocs/op
BenchmarkConcatenate/Cat100-8            300000         5794 ns/op       7520 B/op       100 allocs/op
BenchmarkConcatenate/Buf100-8           1000000         1938 ns/op       2160 B/op         4 allocs/op
BenchmarkConcatenate/Cat10000-8             200      7414202 ns/op   53327801 B/op     10000 allocs/op
BenchmarkConcatenate/Buf10000-8           10000       188879 ns/op     211424 B/op        11 allocs/op
PASS