2016/11/12

GDG Berlin Golang "Movember Gophers" に行ってきた

昨日ドイツのベルリンについたばかりで、少し時差ボケってたんですが、なんとなくGDG Berlin Golang "Movember Gophers"に参加できました。

ちなみに「Movember」というのが「Moustache」と「November」の組み合わせなというわけで、イベントページのゴーファー君も立派な口ひげしてますね。

僕、カナダ人ですが、実はプログラミングや開発に興味を持ち始めたのが日本にきてからなので、こんな感じに日本の外で勉強会に参加するのって初めてでした。世界中の勉強会で何が普通なのか全くわからないんですが、とりあえずピザとビールが決まりみたいです。

ただ昨日は折り畳めて食べる巨大なピザでした・・・

あと、日本ではいつもトークを聞いてから、懇親会を行うんですが、このイベントではピザとビールが最初から出してあって、みんなが集めるの待ってるうちに飲む感じでした。トークとトークの間にみんながビールを取りに冷蔵庫にダッシュしたところ面白かったですww

さて、ピザとビールの件をほといて、トークの内容の話をしましょう。


最初の発表者が@matryer というイギリスの方でした。GoでTDDをする話をしてくれました (スライドはこちらです)。

TTDを行うときに便利なTIPを色々紹介してくれました。例えば:

  • Silk というマークダウンで書かれたドキュメントからHTTPのテストを実行できるパッケージ
  • go test -cover コマンドでテストのカバレージを確認する方法
  • 特別な理由がなければ、テストヘルパーを使わないで標準testパッケージをそのまま使おう (Go作者の意見)
  • 外部dependencyを避けるため、実際のオブジェクトじゃなくてモックしたオブジェクトを利用する (つまりinterfaceでtypeを柔軟にする)
  • interfaceを元にモックのstructを自動生成ツールの紹介
  • あるパッケージを外部からテストしたいとき、テスト専用のパッケージを作ってもいい(テストの場合同じディレクトリに複数パッケージをおいても大丈夫)


2番目の発表がに@konradreicheによるConsumer Driven Contract Testing in Goでした。

マイクロサービスのインテグレーションテストで出てくる問題を解決しようとしているPactの紹介でした。(概要から日本語で説明する自信ないので、クックパッドの記事を参考にするといいでしょう)

Pact for Goが実際にTape.tvでどういうふうに使われているかも説明してくれました。Box Officeというチケット購入システム(Ruby)とBouncerという認証用API(Go)の違うチームによって管理されているマイクロサービスがあるそうですが、共通のAPIをPactで定義することで管理のところを一部自動化できてて安心らしいです。

ただConsumer Driven Contractを使えるまでのプロジェクトのセットアップやチームが新しい仕組みになれるまでの時間の面で少し大変らしいです。


最後に@fortytw2watneyというRubyのvcrの移植の紹介をしました。HTTPリクエストをキャプチャーし、次回に実行した際にHTTPリスポンスを再利用することで、ネットワーク障害の影響でこける確率を低くしたり、テストを早くしたりするとても便利そうなパッケージです。

2016/11/02

Minna no Go Gengo: A Summary / Review in English (chapter 3)

Here's a continuation of my summary of the Japanese Go programming book: Minna no Go Gengo. This is chapter 3.

For anyone who has missed my other summaries, here are chapter 1 and chapter 2.

How to Make practical applications

Author: Fujiwara Shunichiro (aka @fujiwara)

3.1 Opening

First of all what does the author mean by "practical applications"?
A practical application...

  • makes it easy to look up what kind of operations it performs
  • has good performance
  • can support different inputs and outputs
  • is easy for humans to use
  • is easy to maintain

The two github repos below are referenced frequently throughout the chapter as real-world practical applications written. Both are applications created by the author.

3.2 Version Control

Many Go programs can be shipped as a single binary, so in comparison to interpreted languages, the deployment process is generally much simpler. However since we're dealing with binaries it's a good idea to make it easy to programmatically obtain the version number of the binary so users can check if they have the latest version. Using the flag package to capture whether the program was invoked with -v or --version flags is common, but instead of hardcoding the version into the source code, the author recommends making use of git tags to store the version number and then passing it to the code using the build argument ldflags. A Makefile could for example do something like this:


#!/bin/sh

GIT_VER=`git describe --tags`
go build -ldflags "-X main.version=${GIT_VER}"


The Makefile for fluent-agent-hydra seems to make use of this very technique.

3.3 Efficient Use of I/O

This section demonstrates why and how bufio should be used when dealing with I/O operations.

The first point the author makes is how useful bufio.Reader.Peek can be when you run into a situation where you want to validate data coming in from STDIN, but don't want to read everything in the buffer quite just yet. An example of this kind of scenario is in the application stretcher which expects to receive a valid JSON string via STDIN. Although it's possible to read the entirety of the input into memory and then check whether it is valid JSON or not, it's more efficient to pass the input in io.Reader directly to encoding/json.Decoder. This is where bufio.Reader.Peek comes in. A call to Peak() can be used to check if the first character looks like the beginning of a JSON array ("[") , and if not we can simply return an error without bothering to read the rest of STDIN.

Another important point the author brings up is the difference between buffering in Go as opposed to in interpreted languages such as Ruby, Perl and Python. Interpreted languages generally handle the buffering of text output automatically at run time when their enclosing program is handed to a pipe, thereby reducing the number of costly system calls. Go, on the other hand, doesn't automatically buffer anything.

For example, try inspecting the following program using strace -e trace=write ./filename | cat


package main

import (
  "fmt"
  "os"
  "strings"
)

func main() {
  for i := 0; i < 100; i++ {
    fmt.Fprintln(os.Stdout, strings.Repeat("x", 100))
  }
}


Checking the output of strace on the above program reveals that a total of 100 system calls are recorded, indicating that no buffering has taken place. The bufio package can help us improve this example.


package main

import (
  "bufio"
  "fmt"
  "os"
  "strings"
)

func main() {
  b := bufio.NewWriter(os.Stdout)
  for i := 0; i < 100; i++ {
    fmt.Fprintln(b, strings.Repeat("x", 100))
  }
  b.Flush()
}


By wrapping os.Stdout with a *bufio.Writer we can delay the system calls until Flush() is called. The default buffer size is 4096 bytes, but it can be increased as necessary. Inspecting our new and improved program in strace will show that the number of system calls has been reduced to 2 whether we pass our program to a pipe or not.

3.4 Handling random numbers

This section mostly just explains the difference between math/rand (pseudo random number generator) and crypto/rand (cryptographically secure pseudo random number generator) and shows how they can be used. I think this topic is pretty well covered in English.

3.5 Human readable numbers

The package recommended for converting file sizes and time stamps to human readable format is: go-humanize. Again the documentation for this package is in English, so probably I don't need to summarize. Just if you need to convert numbers to a more readable format, use this package rather than wasting time trying to do it yourself.

3.6 Executing external commands through Go

Generally speaking executing other programs through Go incurs a penalty in terms of starting up other processes in the background and sending data to external commands, so performance-wise, it's often preferable to implement a lot of things in pure Go. However there are of course instances where it is better to delegate the work to an existing program. This section mostly just models how to use the os/exec package to call external programs. One thing I didn't know is that if you call sh through os/exec you can use redirects and other shell sigils (>, ||, &&, etc) as normal.


exec.Command("sh", "-c", "some_command || handle_error").Output()


3.7 Timing out

While a lot of existing packages like net/http handle timeouts for you, sometimes you might want to implement a timeout yourself. This section demonstrates how you can use the time package and channels to implement a timeout yourself.


// A 10 second timer
timer := time.NewTimer(10 * time.Second)
// a channel to receive the result
done := make(chan error)

go func() {
  // call the function you want to run asynchronously in a goroutine
  done <- doSomething() // a function that returns an error
}

// use select to wait for a response from multiple channels
select {
case <-timer.C:
  return fmt.Errorf("timeout reached")
case err <-done:
  if err != nil {
    return err
  }
}


3.8 Working with signals

Go's default handling of signals is documented in os/signal. This section demonstrates how you might change the default behaviour in your own programs. A few examples of why you might want to do this is for example you have a server application and want to finish processing all incoming requests before closing or you want to make sure your program finishes writing everything currently in the buffer and properly closes open files before exiting itself. The example in the book is relatively close to the example from the os/signal docs for Notify(), so a read through that will give you the gist.

3.9 Stopping goroutines

It's easy to start a goroutine, but stopping one goroutine from inside another can be a bit tricky. There are two main ways to do this: using channels, or using the context package provided by go 1.7 and later.

The example code on page 80 shows how to use channels to stop a goroutine. The code demonstrates a program that implements concurrent workers which can process data from a queue.


package main

import (
  "fmt"
  "sync"
)

var wg sync.WaitGroup

func main() {
  queue := make(chan string)
  for i := 0; i < 2; i++ { //make two workers (goroutines)
    wg.Add(1)
    go fetchURL(queue)
  }

  queue <- "http://www.example.com"
  queue <- "http://www.example.net"
  queue <- "http://www.example.net/foo"
  queue <- "http://www.example.net/bar"

  close(queue) // tell the goroutines to terminate
  wg.Wait()    // wait for all goroutines to terminate
}

func fetchURL(queue chan string) {
  for {
    url, more := <-queue // more will be false when this closes
    if more {
      // process the url
      fmt.Println("fetching", url)
      // ...
    } else {
      fmt.Println("worker exit")
      wg.Done()
      return
    }
  }
}


When you call close() on a channel from the sending side, the second variable passed to the receiving side (the variable more evaluates to false. The goroutine is then able to close itself (by calling return) when there is no more data to receive.

The context package can be used to achieve much the same thing. The advantage that context brings to the table is a function called context.WithTimeout() which lets you handle timing out and cancellation in one fell swoop. Go Concurrency Patterns: Context from the official golang blog covers its usage extensively.

That wraps up the topics introduced in this chapter. A lot of the content was new to me, so hope to make use of some of the techniques in the future.