はじめに

この記事はGo5 Advent Calendar 2019 4日目の記事です。

Go Modulesがデフォルトで有効になったGo1.13がリリースされてはや３ヶ月。皆さんいかがお過ごしでしょうか。私は「Modules何もわからん」となっててんやわんやでした。
この記事ではModulesの変化の影響を受けやすいGoプログラムの静的解析について、入門〜中級者向けに解説していきます。

静的解析とは？

プログラムを実行せずにその内容を解析することを静的解析と言います。コンパイラによる構文解析や型チェックをはじめ、エディタがタイポを検出したり補完機能を提供したりするのも静的解析です。これらとは逆に、ユニットテストや性能評価などはプログラムを実行しているので動的解析と呼ばれます。
Goはgofmtやgoimportsなど静的解析ツールが豊富なことでも有名です。

Go Modulesとは？

Go公式の依存パッケージのバージョン管理システムです。Go 1.11から導入され、Go 1.13よりデフォルトで有効になっています。
初期のGoは「常に最新版を使えばええやろ！互換性のない変更を加えるなら別のパッケージを作れ！」と強気な姿勢をとっていましたが、色々あってvendorやgo depsなど準公式ツールでの試行錯誤の末ついに公式に導入されたのがGo Modulesというわけです。

静的解析とModulesの関係

静的解析に際してソースコードまたはパッケージファイル(*.a)を読み込むわけですが、当然依存しているパッケージの情報がないと解析を行えないので、静的解析の実行はパッケージ管理システムに依存します。
つまり、Go 1.10以前の静的解析プログラムはModulesに対応していない場合があるということです。そこで本稿ではModulesに対応済みの(標準・準標準)ライブラリとその使い方を紹介します。

TL; DR

• レールに乗っかりたい、モジュール化された静的解析ライブラリを作りたい → analysis
  • Mercariのブログが参考になる
• とにかく動かしたい、基礎を理解したい → go/*, packages

Package go/*

Goが公式にサポートする静的解析用のパッケージ群です。基本的にこの後に紹介するパッケージの内部で使用されるため、ast, token, typesの型を提供するパッケージをメインにさわることになります。

go/*	説明
ast	ASTを構成する型とそれらに対する操作
build	GOPATHやビルドタグなどの情報
constant	型の指定されていない定数に対する操作
doc	ソースコードからドキュメントを収集
format	Go標準のフォーマッタ
importer	コンパイラ実装(gc, gccgo)ごとのimport処理を抽象化
parser	文字列/ファイル/ディレクトリを読み込んでASTを返す
printer	ASTを整形して表示
scanner	字句解析の実装
token	字句解析結果の型とそれらに対する操作
types	型チェッカーの実装と結果の型

注意：これらのうち、importerはModules対応で変更が入っており、importer.For()はimporter.ForCompiler()に修正する必要があります……が、そもそもimporter.Default()を使っている場合が多いと思うのでそんなに影響はないのではないでしょうか。

Package golang.org/x/tools/go/*

Goの準標準パッケージです。上記の標準パッケージを利用したハイレベルな機能が数多く提供されています。ここではその中でも特に知っていると得するパッケージを紹介します。
標準ライブラリではないため後方互換性が保証されていないと注意書きされてますが、それこそModulesを使えば勝手にアップデートされて動かなくなるということはないので大体の人は心配しなくてもいいでしょう。
Modules対応に際し大きな変更が入り、loaderパッケージが廃止されて代わりにpackagesパッケージが新たに用意されました。

Package analysis

analysis - GoDoc

静的解析プログラムを抽象化し、再利用可能性を高めて他の解析と簡単に組み合わせられるようにします。サブパッケージanalysis/analysistestでは複雑になりがちな静的解析プログラムのテストの記述を支援します。また、サブパッケージanalysis/passes/*としてよく用いられる解析処理を提供しています。
analysis/passes/*の多くはgo vetコマンドにより利用できます。例外であるbuildssa, ctrlflow, inspectは他のAnalyzerに利用されることを前提としたAnalyzerで、新たに静的解析ツールを自作する場合も利用できます。それぞれ後で解説するssa、cfg、ast/inspectorが実装の本体となっています。

このパッケージに関してはGoにおける静的解析のモジュール化について - Mercari Engineering Blogが非常によくまとまっていて分かりやすいので一読をおすすめします。

Package ast/astutil

astutil - GoDoc

既存のASTを改変して新しいASTを作る関数Apply()や式(Expr)の括弧を外して中身を取り出す関数Unparen()などASTに関するをユーティリティ提供します。

Package ast/inspector

inspector - GoDoc

ASTをトラバースするためのデータ構造を提供します。標準パッケージのast.Inspect()に比べて、メモ化による複数呼び出しの高速化とノードのフィルタリング、探索スタック付きのトラバースをサポートします。analysis/passes/inspectで利用されているのはこちらになります。
メモ化のためのオーバーヘッドがあるので、同じASTに対して数回しか呼び出さない場合はast.Inspect()のほうが高速なことに注意です。

Package callgraph

callgraph - GoDoc

関数Aの内部で関数Bが呼び出されている、といった関係をグラフとして表現します。グラフの生成の実装はサブパッケージとしてcha, rta, staticの３種類のアルゴリズムが提供されています。

Package cfg

cfg - GoDoc

ある関数内でのifやswitchによる分岐をグラフで表現します。ある処理が必ず呼び出されているか検査したいときなどに便利です。ただし論理演算子の短絡評価やpanicによる分岐などはサポートされていないため、それらが必要な場合後述するgolang.org/x/tools/go/ssaを使います。

Package packages

packages - GoDoc

ファイルの探索から字句解析、構文解析そして型チェックを一括で処理してくれる上位APIです。analysisパッケージを用いない場合はこのパッケージが解析の起点になると思います。

Package ssa

ssa - GoDoc

静的単一代入(Static Single-Assignment: SSA)形式の中間表現を生成します。これによりコード解析が容易になります。例えば次のようなコードを解析したときに、strに代入されうる値が"Hello, world!"か "Hello, 世界!"のどちらかであることが分かります。こういった複数部分にまたがる解析を実行するにはほぼ必須と言えるでしょう。

func hello(world string) {
    str := "Hello, " + world + "!"
    fmt.Println(str)
}

const DEFAULT_WORLD = "world"

func main() {
    var lang string
    fmt.Scan(&lang)
    if lang == "Japanese" {
        hello("世界")
    } else {
        hello(DEFAULT_WORLD)
    }
}

analysisを使わない場合のサンプルコード

analysisを使う場合は上記のMercariさんのブログを見れば十分なので、ここではpackagesを起点にコードを解析するサンプルプログラムを紹介します。
簡単に説明すると、関数とそれを呼び出している関数を見つけてprintしています。ssaパッケージを使うと同じことがより簡単かつ正確にできますが、あくまでサンプルとして見ていただければ幸いです。

package main

import "fmt"
import "go/ast"
import "go/types"
import "golang.org/x/tools/go/packages"

func main() {
    dir := "."
    conf := &packages.Config{
        Dir: dir,
        Mode: packages.NeedName |
            packages.NeedFiles |
            packages.NeedImports |
            packages.NeedDeps |
            packages.NeedTypes |
            packages.NeedSyntax |
            packages.NeedTypesInfo,
    }
    pkgs, err := packages.Load(conf)
    if err != nil {
        fmt.Println("failed to parse dir %s: %w", dir, err)
        return
    }
    if packages.PrintErrors(pkgs) > 0 {
        fmt.Println("Some packages have errors")
        return
    }

    for _, pkg := range pkgs {
        for _, file := range pkg.Syntax {
            scope2fn := make(map[*types.Scope]*types.Func)
            // スコープの情報にアクセス
            filescope, _ := pkg.TypesInfo.Scopes[file]
            // 定義情報にアクセス
            for _, obj := range pkg.TypesInfo.Defs {
                fn, ok := obj.(*types.Func)
                if !ok {
                    continue
                }
                if fn.Scope().Parent() == filescope {
                    // トップレベルの関数定義を集める
                    scope2fn[fn.Scope()] = fn
                }
            }
            // ASTを探索
            ast.Inspect(file, func(n ast.Node) bool {
                switch expr := n.(type) {
                case *ast.CallExpr:
                    var caller, callee string
                    callee = types.ExprString(expr)
                    scope := pkg.Types.Scope().Innermost(expr.Pos())
                    if scope == nil {
                        return true
                    }
                    // forやif、無名関数のスコープは無視
                    for scope.Parent() != nil {
                        if fn, ok := scope2fn[scope]; ok {
                            caller = fn.Name()
                        }
                        scope = scope.Parent()
                    }
                    fmt.Println(caller + " -> " + callee)
                }
                return true
            })
        }
    }
}

まとめ

Goはシンプルな言語仕様のために静的解析がとてもやりやすい言語だと思います。ぜひ皆さんもGoで静的解析に入門しましょう！

aetestとは

https://cloud.google.com/appengine/docs/standard/go/tools/localunittesting/reference?hl=ja
GAE/Go用のローカルテストのためのパッケージです。
GAEも第2世代へ移り変わり最早今後は新規に使われることもそう無いであろうパッケージですが供養として過去の苦労を記しておきたいと思います。

以下はGAEのテストサンプルコードです。aetestはテスト実行時にGAE特有の機能をローカルで利用する際のサーバーを立ち上げてくれます。そのサーバーの情報を含んだcontextを利用することでテストが可能になります。

サンプルコードではGAEのMemcacheの機能を利用しています。

main_test.go

package main

import (
    "google.golang.org/appengine"
    "google.golang.org/appengine/aetest"
    "google.golang.org/appengine/memcache"
    "testing"
)

func TestAeTest(t *testing.T) {
    inst, err := aetest.NewInstance(nil)
    if err != nil {
        t.Fatal(err)
    }
    defer inst.Close()

    req, err := inst.NewRequest("GET", "/", nil)

    ctx := appengine.NewContext(req)

    it := &memcache.Item{
        Key:   "some-key",
        Value: []byte("some-value"),
    }
    err = memcache.Set(ctx, it)
    if err != nil {
        t.Fatalf("Set err: %v", err)
    }
    it, err = memcache.Get(ctx, "some-key")
    if err != nil {
        t.Fatalf("Get err: %v; want no error", err)
    }
    if g, w := string(it.Value), "some-value" ; g != w {
        t.Errorf("retrieved Item.Value = %q, want %q", g, w)
    }
}

aetest.NewInstance() の中で何が行われているかというと、簡素なGAEアプリケーション設定を一時領域に作っています。

設定は内部に定義されており、GAE/goのアプリケーションとして最低限の設定で起動されています。

https://github.com/golang/appengine/blob/master/aetest/instance_vm.go#L278-L292

const appYAMLTemplate = `
application: %s
version: 1
runtime: go111

handlers:
- url: /.*
  script: _go_app
`

const appSource = `
package main
import "google.golang.org/appengine"
func main() { appengine.Main() }
`

GAEの開発用サーバーのコマンドが組まれ、
dev_appserver.py dev_appserver.py /var/folders/1w/9n3yj1g95g12zgjhm9xxcypc0000gp/T/tmp4C_Mm8appengine-go-bin/app.yml のようなコマンドを子プロセスで立ち上げています。

開発用サーバーが起動するとAPIなどのURLが標準出力にでるので、正規表現ですっぱ抜いてきてそこにdatastore等の命令を投げるようにしています。結構ワイルドな実装ですね。

INFO     2019-10-10 06:39:59,912 devappserver2.py:278] Skipping SDK update check.
WARNING  2019-10-10 06:39:59,912 devappserver2.py:294] DEFAULT_VERSION_HOSTNAME will not be set correctly with --port=0
INFO     2019-10-10 06:40:00,098 datastore_emulator.py:155] Starting Cloud Datastore emulator at: http://localhost:21206
WARNING  2019-10-10 06:40:00,100 simple_search_stub.py:1196] Could not read search indexes from /var/folders/1w/9n3yj1g95g12zgjhm9xxcypc0000gp/T/appengine.testapp.hoshina/search_indexes
INFO     2019-10-10 06:40:01,231 datastore_emulator.py:161] Cloud Datastore emulator responded after 1.132465 seconds
INFO     2019-10-10 06:40:01,232 api_server.py:275] Starting API server at: http://localhost:64020
INFO     2019-10-10 06:40:01,237 api_server.py:265] Starting gRPC API server at: http://localhost:64022
INFO     2019-10-10 06:40:01,312 dispatcher.py:256] Starting module "default" running at: http://localhost:64023
INFO     2019-10-10 06:40:01,316 admin_server.py:150] Starting admin server at: http://localhost:64025
INFO     2019-10-10 06:40:03,328 stub_util.py:357] Applying all pending transactions and saving the datastore
INFO     2019-10-10 06:40:03,328 stub_util.py:360] Saving search indexes
INFO     2019-10-10 06:40:04,252 instance.py:294] Instance PID: 57474

https://github.com/golang/appengine/blob/master/aetest/instance_vm.go#L150-L151

var apiServerAddrRE = regexp.MustCompile(`Starting API server at: (\S+)`)
var adminServerAddrRE = regexp.MustCompile(`Starting admin server at: (\S+)`)

最初勘違いしていたのですが、aetestは対象のアプリケーションを立ち上げてくれるわけではなく、appengineAPIを利用するのに最低限必要なものを用意してくれるだけです。
なのでアプリケーションのルーティングを再現してくれるわけでもないので、テストで実際のアプリケーションを想定したリクエストを作ってhttp.ClientでDo(req)しても動いたりはしないので注意が必要です。

という挙動をしているaetest.NewInstance()ですが、毎回子プロセスを立ち上げるのでかなり遅いです。
下記のテストでは、2件のテストでそれぞれ5秒程度かかってしまい、実行時間の大半はdev_appserver.pyの起動に費やされています。

main_test.go

package main

import (
    "google.golang.org/appengine"
    "google.golang.org/appengine/aetest"
    "testing"
)

func TestAppID(t *testing.T) {
    ctx, done, err := aetest.NewContext()
    if err != nil {
        t.Fatal(err)
    }
    defer done()
    val := appengine.AppID(ctx)
    if val != "testapp" {
        t.Fatalf("got: %v\nwant: %v", val, "testapp")
    }
}

func TestDefaultVersionHostname(t *testing.T) {
    ctx, done, err := aetest.NewContext()
    if err != nil {
        t.Fatal(err)
    }
    defer done()
    val := appengine.DefaultVersionHostname(ctx)
    if val != "" {
        t.Fatalf("got: %v\nwant: %v", val, "")
    }
}

インスタンスは基本的に使い回せるはずなので、パッケージ変数に作成したインスタンスを保持して、インスタンスを要求された時設定が同じであれば以前に作成したインスタンスを返すことで毎回起動することを避けることができます。

main_test.go

package main

import (
    "context"
    "fmt"
    "google.golang.org/appengine"
    "google.golang.org/appengine/aetest"
    "os"
    "testing"
)

func TestAppID(t *testing.T) {
    ctx, done := NewContext(nil)
    defer done()
    val := appengine.AppID(ctx)
    if val != "testapp" {
        t.Fatalf("got: %v\nwant: %v", val, "testapp")
    }
}

func TestDefaultVersionHostname(t *testing.T) {
    ctx, done := NewContext(nil)
    defer done()
    val := appengine.DefaultVersionHostname(ctx)
    if val != "" {
        t.Fatalf("got: %v\nwant: %v", val, "")
    }
}

var instances map[string]aetest.Instance

func NewContext(opt *aetest.Options) (context.Context, func()) {
    var err error
    key := fmt.Sprintf("%#v", opt)
    //設定が異なる場合違うインスタンスを作成する
    if _, ok := instances[key]; !ok {
        instances[key], err = aetest.NewInstance(opt)
        if err != nil {
            panic(err)
        }
    }

    req, err := instances[key].NewRequest("GET", "/", nil)
    if err != nil {
        panic(err)
    }
    ctx := appengine.NewContext(req)
    return ctx, func() {
    //なにもしない
    }
}

func TestMain(m *testing.M) {
    instances = map[string]aetest.Instance{}
  //パッケージ内のテストを終了
    status := m.Run()

    //goroutineがインスタンスの終了を待っているので最後に終了する
    for _, i := range instances {
        i.Close()
    }
    os.Exit(status)
}

注意が必要なのは、aetest.Instanceは起動した子プロセスが終了するのをgoroutineで待ち続けているため、インスタンスが一つでも起動しているとgoroutineの終了を待ってしまいテストのプロセスを終了することができません。

https://github.com/golang/appengine/blob/master/aetest/instance_vm.go#L114-L120

そのためテストを終了させるためには、必ず最後にインスタンスを終了させる必要があります。

しかしここで問題があります。テスト内でpanicを起こすと、m.Run()の後に行っているインスタンスの終了が行われないため、テストが終了できなくなってしまうのです。

main_test.go

func TestPanic(t *testing.T) {
    panic("from TestPanic")
}

ですのでpanicが起きたらrecover()で捕まえてインスタンスを終了すればいいので、TestMainのdeferすればよいと考え、TestMainを以下のように変更しました。

main_test.go

func TestMain(m *testing.M) {
    status := 0

    defer func() {
        for _, i := range instances {
            i.Close()
        }
        os.Exit(status)
    }()
    instances = map[string]aetest.Instance{}
    status = m.Run()

    //goroutineがインスタンスの終了を待っているので最後に終了する
    for _, i := range instances {
        i.Close()
    }
}

しかしこの変更は無意味です。

通常、テストの中でpanicが起きた場合、テスト結果を出力し即終了しようとしますが、testingとは別のgoroutineでchannelが入力待ちの状態などで停止していると、テストの完了シグナルが送られずにテストプロセス自体が終了できなくなってしまいます。

仮に終了シグナルが返ったとしても、そもそもtestingの各テストはgoroutineで実行されており、goroutineをまたいでrecoverすることはできないので二重に意味のないコードでした。

結局どうしたらいいのかというと、goroutineがサーバーの終了を待たなくて良いようにするか、panicしても制御が戻って来れるようにする必要があります。

前者でやるとすればTestMainで全パターンのサーバーを作成しておくことで解決が可能です。ただし設定のパターンが多いと難しいでしょう。
後はpanicしても明示的にtestingの制御を返すことで親のgoroutineに終了を伝えることができます。

main_test.go

func TearDown(t *testing.T) {
    if err := recover(); err != nil {
        debug.PrintStack() //スタックトレースが出ないので自分で吐いている
        t.Fatal(err)
    }
}

func TestPanic(t *testing.T) {
    defer TearDown(t)
    panic("from TestPanic")
}

マイナーな話なのですが、テストが外部プロセスに依存してテスト実行時にその状態も管理しようとすると似たようなケースに陥るかもしれません。(テスト実行時にデータベースをいろんなパターンで起動したいとか)
その場合、TestMain等で共通の前後処理を行おうとすると例外時にハマることになるというお話でした。

この記事はJsys Advent Calendar 2019の記事です
Qiita初投稿になりますので色々と突っ込みどころがあるかもしれないです

やったこと

Go+Nuxt+その他諸々を使ってリアルタイムにライブ配信サイト10種+Twitterの特定のハッシュタグでつぶやかれた内容を自動的に表示するソフトフェアを作った

目次

• 使った言語+フレームワーク
• 実行に必要な前提要件
• 使い方
  
• 実装方法
• 感想的な何か

使った言語+フレームワーク

フロントエンド

• Nuxt.js
  フロントをモダンに書きたいのと使い慣れてるので採用

サーバーサイド

• Go
  個人的な慣れで採用
  オブジェクト指向のような手続き型のような謎の言語
  モダンな書き方が大体採用されてる
  青いホリネズミがキモカワイイ

• フレームワーク

  • Gin
    高機能なHTTP/HTTPS通信用フレームワーク
    Nuxtから吐き出した静的ファイルを一行でルーティングできたりする
  • Melody
    小機能のWebsocket通信用ライブラリ
    Javascriptライクな実装ができたり、セッション情報を一時的に保存できる機能が元々あるなど地味に便利

前提要件

• IFTTT
  スプレッドシートにTwitterのデータをぶっこ抜くのに使用
  Twitter・Google Driveとのインテグレーションをオンにしておくこと
• Google Service Account
  スプレッドシートからローカルサーバーへデータを転送するのに使用
• MultiComment Viewer
  Youtube等の配信サイトからのデータをぶっこ抜くのに使用
• HTML Comment Generator
  コメントのデータをひっぱるのに使用

使い方

1. マルチコメントビューワーでHTML5コメジェネのパスを通す
2. マルチコメントビューワーで通常通りコメントを収集する
3. localhost:8080にアクセスする
4. コメントが表示されるようになる
5. カラーキーを指定して背景をぶっこ抜くことでOBS上で一定時間以上コメントがない場合は自動的に透明になるよ！

実装方法

1. localhostにアクセスされたらconfigを読み出し、Websocketでの通信に切り替える
2. TwitterからIFTTTを通してスプレッドシートに送られたデータと、マルチコメビュから出力されたxmlを読み込む
3. 2で得られたデータの今までに送信したデータとの差分を取って残りをwebsocketで送る
4. 受け取ったらキューに格納して一定時間ごとに取り出す
5. キューの中にデータが一定時間以上なくなったら表示部分をopacity: 0;にして消去

感想的な何か

そもそもローカルでしか動かないのにサーバーサイドとは()
現在アプリケーションとして開発中です・・・

はじめに

私は現在Ruby on railsやJavaScript(jQuery)の学習を行っていますが、今回息抜きを兼ねてGoの学習を始めてみました。
学んだ基本事項を、自分なりにかみ砕いて解説していこうと思います。

実行

Goの最も簡単なコードは下記の通りです。

package main

func main() {
   println("Hello World")
   println(2019)   
}

これを実行すると、

Hello World
2019

と出力されます。

package mainの部分をパッケージ定義部分、func main()の部分を関数定義部分といいます。（これの詳しい解説は今の私にはできないので、いつかの記事で行います）

println()が二つ並んでいますが、これは()の中身を出力するというものでRubyでいうputsやJSでいうconsole.log()に相当します。
（ちなみに、printInではなくprintlnなので注意を）

今回は()の中身にそれぞれHello Worldと2019が入力されているので、出力は前述の通りとなります。

TL;DR

今からFirebase Authenticationを使ってソーシャルログイン機能を30分くらいで検証用に実装します。
各種SNSのデベロッパーサイトへの登録はしてあるものとします。
要件として作成するのは、トップページと、ログイン後ページの２画面のシンプルな構成。

コードは置いといた。(secret.yamlは準備してくれ・・・)
https://github.com/spre55/firebase-auth-sample/

今回使う主な技術・ツール・サービス

• HTML/CSS/JavaScript
• Go 1.13
• Firebase Authentication
• Google App Engine (Standard Edition)

Google App Engine(以下GAE)はGCP上で提供されるPaaSです。
デプロイ時にバージョンを指定でき、トラフィックを別バージョンに切り返すことで、Blue/Greenデプロイなども簡単に行えます。
今回はGAEのStandard Editionを使います。Goをサポートしているので、バックエンドはGoを使ってみます。

更に、今回はソーシャルログイン機能ということで、認証を簡単に実装できるようにしてくれるFirebase Authenticationを使います。
アプリはもちろん、クライアントSDKはWebもサポートしているので、JavaScriptを使用して、簡単に認証機能を実装することができます。複雑な要件がなければ、ドキュメントのコピペで終わることでしょう。

実装する機能

• メール/パスワードサインアップ・ログイン
• Twitterログイン
• Googleログイン
• Facebookログイン
• Githubログイン
• ログアウト

アプリケーションの構築

今回は以下のようなシステム構成を目指します。
赤い部分が我々がコードで表現するアプリケーション部分です。
それ以外の部分は各種コンソール画面から、ボタンポチポチで実現できます。

各種ソーシャルプロバイダの登録

まずは以下のソーシャルプロバイダのデベロッパーサイトへ登録し、APIキーなどを使用可能な状態にしてください。詳細な手順は省きます。

• Twitter Developers : https://developer.twitter.com/content/developer-twitter/ja.html
• Facebook for Developers : https://developers.facebook.com/?locale=ja_JP
• Github developers: https://github.com/settings/developers

GAE/Go で Hello World !

以下からGoogle Consoleにログインしてチュートリアルを行えば、10分経たずで全世界にHello Worldできるかと思います。(実際にタイムアタックを試したら、クレジットカード登録も含め8分程度でできました)
https://cloud.google.com/appengine/?hl=ja

まずは、チュートリアルを終え、GoのアプリケーションをGoogle App Engineでデプロイしてみましょう。話はそれから。

GCPは一年間の無料期間が設定されてます。まだ触ってない人はこれを機にいじってみましょう。

ドキュメントに記載されているクイックスタートにもあると思いますが、公式のGithubアカウントにて、最小構成のhelloworldアプリやその他もろもろが公開されているので、これをそのままクローンしてデプロイできますね。
https://github.com/GoogleCloudPlatform/golang-samples/tree/master/appengine/go11x/helloworld

Firebase Consoleでの認証の設定

https://console.firebase.google.com/u/0/

Firebaseのクラウドコンソールにアクセスしてみましょう。

"ログイン方法"のタブにいくと、各種プロバイダのログイン方法が指定できますので、必要なものを有効にしましょう。今回は最初に述べた、「メール/パスワード」、「Google」、「Twitter」、「Facebook」、「Github」の５つを有効にしましょう。
ここで有効にするために、プロバイダによっては、APIキー及び、シークレットキーなどを求められるので、最初に各種デベロッパーサイトで設定して入手したAPIキーとシークレットキーを入力しましょう。

とりあえず画面を２つつくる

すでに作成したGAEにてHello Worldを表示するアプリケーションが存在する前提で進みます。

とりあえずGoからサーバサイドレンダリングでHTMLの内容を表示するだけでいいので、一旦、今回作りたいトップページと、ログイン後ページのガワを作ります。

構成はこんな感じ。

├── app.yaml
├── main.go
└── templates
    ├── my.html
    └── signup.html

各ファイルは以下の通り。

app.yaml

runtime: go113

templateディレクトリを作り、その配下に
サインアップ前のトップページと、

signup.html

<!DOCTYPE html>
<html>
<body>
    <h1>Welcome to Sign Up Page!</h1>
</body>
</html>

サインアップ後に入れるマイページを作って、

my.html

<!DOCTYPE html>
<html>
<body>
    <h1>Welcome to My Page!</h1>
</body>
</html>

main.goには、ルーティングまわりを記述。

main.go

package main

import (
    "fmt"
    "log"
    "net/http"
    "os"
    "text/template"
)

func main() {
    http.HandleFunc("/", indexHandler)
    http.HandleFunc("/my", myHandler)

    port := os.Getenv("PORT")
    if port == "" {
        port = "8080"
        log.Printf("Defaulting to port %s", port)
    }
    log.Fatal(http.ListenAndServe(fmt.Sprintf(":%s", port), nil))
}

// indexHandler ... サインアップページ(トップページ)
func indexHandler(w http.ResponseWriter, r *http.Request) {
    if r.URL.Path != "/" {
        http.NotFound(w, r)
        return
    }

    t := template.Must(template.ParseFiles("templates/signup.html"))
    if err := t.ExecuteTemplate(w, "signup.html", nil); err != nil {
        log.Fatal(err)
    }

}

// myHandler ... サインアップ後のマイページ
func myHandler(w http.ResponseWriter, r *http.Request) {
    if r.URL.Path != "/my" {
        http.NotFound(w, r)
        return
    }

    t := template.Must(template.ParseFiles("templates/my.html"))
    if err := t.ExecuteTemplate(w, "my.html", nil); err != nil {
        log.Fatal(err)
    }
}

https://github.com/spre55/firebase-auth-sample/tree/feature/20191203_page_only

GAEにデプロイして、動作するようならオッケー。

Firebase を使える状態にする

Firebaseを使えるようにするため、まずはクライアントSDKをCDNで呼ぶ。そのためにFirebaseコンソールからコードをコピってきてアプリケーション内に埋め込みたい。

まずFirebaseコンソールプロジェクトの設定をみる。

Settingページへ遷移するので、「アプリを追加」ボタンを押す。

今回はWebアプリなのでWebを選択。

適当にアプリの名前を決めると、以下のような画面になるので、ここで表示されたコードを、自分のアプリケーションに埋め込む。(今回はFirebase Hostingは使わないので未チェックでOK)

アプリケーションに上記のコードを埋め込んで動作させる

上記コードはGithubで公開とかしないならベタ書きでもいいのですが、あんまり見られたくないので、secret.yamlに環境変数として記述し、それをapp.yamlで読み込むようにします。
また、secret.yamlをGithubに公開したら意味ないので、.gitignoreにsecret.yamlを記載して、git管理対象から除外します。
複数人で共有する場合は、secret.yamlを暗号化するか、別の仕組みを使うかする必要がありますが、今回のアプリケーションではそこまではやりません。

最終的なディレクトリ構造はこんな感じ。

├── app.yaml
├── go.mod
├── main.go
├── secret.yaml
├── .gitignore
└── templates
    ├── my.html
    └── signup.html

secret.yamlはこんな感じで書いておいて、

secret.yaml

env_variables:
  API_KEY: "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
  AUTH_DOMAIN: "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.firebaseapp.com"
  DATABASE_URL: "https://XXXXXXXXXXXXXXXXXXXXXXX.firebaseio.com"
  PROJECT_ID: "XXXXXXXXXXXXXXXXXXXXXXX"
  STORAGE_BUCKET: "XXXXXXXXXXXXXXXXXXXXXXX.appspot.com"
  MESSAGING_SENDER_ID: "XXXXXXXXXXXXXXXX"
  APP_ID: "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"

app.yamlでそれを読み込みます。

app.yaml

env_variables:
runtime: go113

includes:
- secret.yaml

secret.yamlは.gitignoreに。

secret.yaml

secret.yaml

次にmain.go内にてos.Getenvで環境変数を読み込み,signup.htmlとmy.htmlに渡したいので、

main.go

 ... (略)
    if err := t.ExecuteTemplate(w, "signup.html", getEnvVars()); err != nil {
 ... (略)

func getEnvVars() map[string]string {
    return map[string]string{
        "apiKey":            os.Getenv("API_KEY"),
        "authDomain":        os.Getenv("AUTH_DOMAIN"),
        "databaseURL":       os.Getenv("DATABASE_URL"),
        "projectId":         os.Getenv("PROJECT_ID"),
        "storageBucket":     os.Getenv("STORAGE_BUCKET"),
        "messagingSenderId": os.Getenv("MESSAGING_SENDER_ID"),
        "appId":             os.Getenv("APP_ID"),
    }
}

signup.html

...(略)
    <script>
        const config = {
            apiKey: "{{.apiKey}}",
            authDomain: "{{.authDomain}}",
            databaseURL: "{{.databaseURL}}",
            projectId: "{{.projectId}}",
            storageBucket: "{{.storageBucket}}",
            messagingSenderId: "{{.messagingSenderId}}",
            appId: "{{.appId}}",
        };

        firebase.initializeApp(config);
...(略)

こんな感じ。

各種機能の実装

ここまでで、各プロバイダとFirebaseを使う準備はできました。
あとは機能の実装です。

今回実装するのは以下の機能でした。

• メール/パスワードサインアップ・ログイン
• Twitterログイン
• Googleログイン
• Facebookログイン
• Githubログイン
• ログアウト

firebaseuiを使って実装してみたいと思います。

signup.html にて、uiConfig.signInOptionsに各種PROVIDER_IDを指定してあげれば、ソッコーで
ログインボタンのUIが出来上がります。

signup.html

...(略)
        const uiConfig = {
            callbacks: {
                signInSuccessWithAuthResult: function (authResult, redirectUrl) {
                    return true;
                },
                uiShown: function () {
                    document.getElementById('loader').style.display = 'none';
                }
            },
            signInFlow: 'popup',
            signInSuccessUrl: 'my',
            signInOptions: [
                firebase.auth.GoogleAuthProvider.PROVIDER_ID, // Google
                firebase.auth.FacebookAuthProvider.PROVIDER_ID, // Facebook
                firebase.auth.TwitterAuthProvider.PROVIDER_ID, // Twitter
                firebase.auth.GithubAuthProvider.PROVIDER_ID, // Github
                firebase.auth.EmailAuthProvider.PROVIDER_ID, // Email/Password
            ],
        };
        // サインアップ/サインインフォームのUI
        const ui = new firebaseui.auth.AuthUI(firebase.auth());
        ui.start('#firebaseui-auth-container', uiConfig);
...(略)

firebaseuiを使用すると、自分でCSSとかをいろいろいじったりする必要はありません。

サインイン状態は以下のように、firebase.auth().onAuthStateChanged()を使用してとってこれます。
ログアウトも、firebase.auth().signOut()を呼ぶだけですね。

my.html

... (略)
        // ユーザのサインイン状態の判定
        firebase.auth().onAuthStateChanged(function (user) {
            if (user) {
                // サインインできてるとき
                console.log('sign in');
            } else {
                // No user is signed in.
                console.log('sign out');
                location.href = "/";
            }
        });

        // ログアウト
        function signOut() {
            firebase.auth().signOut().then(function () {
                console.log('success sign out.');
            }).catch(function (error) {
                console.log('error: ', error);
            });
        }
... (略)

ログインページができました。
まあ、検証用では十分ですね。

まとめ

GoogleAppEngineとFirebaseAuthenticationを使うと簡単にソーシャルログイン機能が作れます。
レンタルサーバーとか借りようと思ってる人、ためしに使ってみては？

困ったら

信頼性の高い公式ドキュメントを見ましょう。
ただし翻訳のタイムロスが無い分、ドキュメントは日本語のものより英語のもののほうが情報が新しかったりするので注意してください。

Goの勉強も含めて、Twitter APIを利用して、「アオキ大好き！最高！」とツイートしている人を全員フォローしてみせます。

anacondaというパッケージを使います。

anacondaとは

Pythonのあれじゃないです。

anacondaとは、Twitter APIにアクセスするためのGoパッケージです。便利！

Twitter APIの利用申請

間違いなく一番めんどくさい過程。
こちらを見ながら頑張りましょう。結構テキトーでも通ります。

実装

main.go

package main

import (
    "encoding/json"
    "fmt"
    "io/ioutil"
    "net/url"
    "strconv"

    "github.com/ChimeraCoder/anaconda"
)

type TwitterAccount struct {
    AccessToken       string `json:"accessToken"`
    AccessTokenSecret string `json:"accessTokenSecret"`
    ConsumerKey       string `json:"consumerKey"`
    ConsumerSecret    string `json:"consumerSecret"`
}

func main() {
    raw, error := ioutil.ReadFile("./twitterAccount.json")
    if error != nil {
        fmt.Println(error.Error())
        return
    }

    var twitterAccount TwitterAccount
    json.Unmarshal(raw, &twitterAccount)

    api := anaconda.NewTwitterApiWithCredentials(twitterAccount.AccessToken, twitterAccount.AccessTokenSecret, twitterAccount.ConsumerKey, twitterAccount.ConsumerSecret)
    v := url.Values{}
    v.Set("count","10000")
    // v.Set("exclude","retweets")
    searchResult, _ := api.GetSearch(`"アオキ大好き！最高！"`, v)
    fmt.Println(strconv.Itoa(len(searchResult.Statuses))+"件ヒットしました！！")
    for _, tweet := range searchResult.Statuses {
        fmt.Printf("%d\n", tweet.User.Id)
        api.FollowUserId(tweet.User.Id,v)
        fmt.Println("--------------------------------------------------------------")
    }
}

twitterAccount.json

{
  "accessToken": "*****************",
  "accessTokenSecret": "*****************",
  "consumerKey": "*****************",
  "consumerSecret": "*****************"
}

結果

   0件ヒットしました！！

今回作成したリポジトリはこちらから

参考:
anaconda github
anaconda Doc

ZOZOテクノロジーズ #5 Advent Calendar 2019の記事です。
昨日は @satto_sann さんの「Alexaのアカウントリンクをデバッグする方法」でした。

本記事では、Go言語の標準パッケージでの画像処理について書いていきます。

はじめに

最初に明言しておきますが、これはGo言語での画像処理を勧める記事ではありません。
あくまで、自分にメリットがありそうという方のみ参考にしていただければと思います。

自分はZOZOテクノロジーズの中でも、アパレル生産におけるファクトリーオートメーションという分野を担当しています。

担当分野が広いというのと、自動化の対象がアパレル関係ということもあり、
開発環境を実行環境に入れることができなかったり、実行環境により使う言語を変えたりと手間がかかってしまう場面がよく発生します。

特に画像処理関係でプロトタイプをサクッと作る際には、開発環境をその都度作るのが面倒だったりします。

そんな手間を無くせないかなーとふと思い、本記事シリーズを書くことにしました。

Go言語 image パッケージ
Package image

ファイルの入力

filepathを利用することで、os間のパス違いを意識せずにコードが書けます。
自分は以下のソースのようにdataファイルを用意し、その中に処理したい画像を置いて読み込ませる方法をよく使います。
プロトタイプを軽く動かす時なんかは便利です。

package main

import (
    "image"
    "log"
    "os"
    "path/filepath"
)

func main() {

    // 実行ファイル直下のパスを取得
    path, _ := os.Getwd()
    dataPath := filepath.Join(path, "data")
    // dataフォルダ直下の画像を一括で読み込む
    jpgPath := filepath.Join(dataPath, "*.jpg")
    jpegPath := filepath.Join(dataPath, "*.jpeg")
    pngPath := filepath.Join(dataPath, "*.png")

    fileList, _ := filepath.Glob(jpgPath)
    f, _ := filepath.Glob(jpegPath)
    fileList = append(fileList, f...)
    f, _ = filepath.Glob(pngPath)
    fileList = append(fileList, f...)

    // 画像を１枚づつ読み込む
    for _, file := range fileList {
        // 画像を読み込む
        img := Input(file)
        println(file, " : " , img)
    }
}

// 画像を読み込む処理
func Input (filePath string) image.Image {

    // 画像を読み込む
    file, err := os.Open(filePath)

    // 画像が読み込めなかった場合
    if err != nil {
        log.Fatal(err)
    }

    // 変換
    img, _, err := image.Decode(file)

    return img
}

ファイルの出力

出力したい拡張子によって処理を分けます。
ここではjpgとpngの出力を紹介します。

const imgQt int = 60

func Output (outputImage image.Image, filePath string, format string) {

    dst, err := os.Create(filePath)

    if err != nil {
        log.Fatal(err)
    }

    switch format {
    case "png":
        // PNGの場合
        err = png.Encode(dst, outputImage)
        if err != nil {
            log.Fatal(err)
        }
        break
    case "jpg":
        // JPGの場合
        qt := jpeg.Options{
            Quality:imgQt,
        }
        err = jpeg.Encode(dst, outputImage, &qt)
        if err != nil {
            log.Fatal(err)
        }
        break
    default:
        // 標準で対応していないフォーマットの場合
        log.Fatal("Unsupported format.")
    }
}

画素値の参照

以下では読み込んだ画像から画素値を参照したり、操作を行なったりしています。

func EditPixel(img image.Image) image.Image {

    // アウトプット画像を定義
    size := img.Bounds()
    // 画像のサイズを変える場合
    // size.Max.X = "任意の数値"
    // size.Max.Y = "任意の数値"
    outputImage := image.NewRGBA(size)

    // 画像の左上から順に画素を読み込む
    for imgRow := size.Min.Y; imgRow < size.Max.Y; imgRow++ {
        for imgCol := size.Min.X; imgCol < size.Max.X; imgCol++ {

            // 画素を取得
            pixel := img.At(imgCol, imgRow)
            println("pixel : ", pixel)
            r, g, b, a := pixel.RGBA()
            println("r : ", r, "g : ", g, "b : ", b, "a : ", a)

            // 画素を操作
            var outputColor color.RGBA64
            // 例（真っ黒な画像にする）
            outputColor.R = 0
            outputColor.G = 0
            outputColor.B = 0
            outputColor.A = 100

            outputImage.Set(imgCol, imgRow, outputColor)
        }
    }

    return outputImage
}

おわりに

ZOZOテクノロジーズ #5 Advent Calendar 2019
明日は「Go言語の標準パッケージだけで画像処理をする その２ （回転、反転）」という記事を書きます。

この記事はチームラボエンジニアリングアドベントカレンダー10日目の記事です。
昨日の記事は、bonobono555さんによるCompletableFutureの公式ドキュメントを読んでも分からないので Java逆引きレシピを片手に理解するでした。

はじめに

趣味でGoを触るようになって半年ぐらいは経ったと思います！
こんなにハマったのは並行処理がめちゃくちゃ面白かったからです。

関数型でも基本的に上から処理されますよね？
(手続き型だと、基本上から、関数型は高階関数多用してると上からでは無くなりますが)
それがgoroutineを使うことによって簡単に並行に処理をさせる事が出来るんです！
これを、他の言語で同じ事やろうとしたらすごく難しいんです！（やった事ないから知らんけど）

とりあえずムチャクチャ楽しいんでこの記事がその入り口にでもなってくれたら嬉しいです！
この記事では詳しい説明より要点をまとめた並行処理パターンを紹介します！

並行処理とは？ 並列処理と混ざってない？

突然ですが、並行と並列の違い分かりますか？？

一言で言うと、
並行処理は1人がその場の判断で沢山の仕事をこなす事
並列処理は複数人が仕事を同時にこなす事
です！

並行処理はあくまで処理を同時に行ってはいないんです。
この様に処理を切り替えて行います。(人の目には同時に見える)

それに比べ、並列処理は処理を同時に行っています。

これが並行と並列のザックリとした違いです。

goroutineとは？

goroutine (ゴルーチン) は Go ランタイムによって管理される軽量スレッドです。スレッドのようでスレッドでなく、coroutine のようで coroutine ではありません。しかし、スレッドで coroutine を実行するかのごとく利用することが可能で、かつそれを簡単な構文で実現できます。

個人的にはこの説明が一番しっくり来ました！

詳しい説明はここでは行いませんが、goroutineの大元はメルヴィン・コンウェイさんのcoroutineの考え方を参考にしているみたいです！

syncパッケージ

まあ大枠はここまでにして(自分が説明するより良記事がある)早速実際に動かしてみましょう！

syncパッケージはGoの標準パッケージに用意されています。
相互排他ロック(チャネルのブロックの様な動き)をしてくれたり、複数のゴルーチンを扱う上でブロックを提供してくれたりします。
goroutineってほっとくと簡単に終わってしまったり(厳密には消えないけど)想定と違うタイミングで変数を上書きする事もあります。

これは説明するより見る方が早いです！

これ↓を実行するとどうなると思いますか？？

func main() {
  go func() {
      fmt.Println("Hello")
  }()
}

"Hello"が出力されないんです！
ここでのgoroutineはメインゴルーチン(main関数)によって生成されているので、メインゴルーチンが終わると終わってしまいます。

こんな風に並行処理を始めると今まで見ないタイプの想定外に出くわすことが多いです！

syncパッケージを実際に使って解決してみましょう！

WaitGroup型

WaitGroupを使うとWait()を呼び出すと内部のカウンターが0になるまでブロックしてくれます！

func main() {
  var wg sync.WaitGroup

  wg.Add(1) // 内部のカウンターを1インクリメント
  go func() {
      defer wg.Done() // 内部のカウンターを1デクリメント
      fmt.Println("Hello")
  }()

  wg.Wait() // 内部のカウンターが0になるまで待機
}

先ほどのコードをこのように書き直すと出力される様になりましたね！

他にも頻出するのは
- Mutex & RWMutext型
- Cond型
- Once型
- Pool型
などなどが挙げられると思いますが、ここら辺の記事はたくさんあるのでそちらを見て見てください。

channel

並行処理を使う上で通信によってメモリ共有を提供してくれる代物です。
チャネルの説明としてとても分かりやすかったのが

水が流れる川のように、チャネルは情報の流れの水路として機能します。値はチャネルに沿って 渡され、そこから下流に読み込まれます。

本当にこの通りでストリームの考え方と近いかも知れません。

また、Goの設計思想でも下記の様に述べられています。

Do not communicate by sharing memory; instead, share memory by communicating.

メモリを共有することで通信しようとしないこと。代わりに通信することでメモリを共有すること。

チャネルのクセとか並行処理で気をつける事とかあれこれ

この後からはすぐに使える並行処理パターンを紹介していきます！

その前に最低限のチャネルの特性や並行処理で気をつける事などを抑えておきましょう。

ブロック

チャネルはブロックして、待つ事が出来ます。

(読み込みの場合)
↓で書き込みの処理(3行目)が無いと5行目でデッドロックを引き起こしてしまいます！

stringStream := make(chan string)
go func() {
  stringStream <- "Hello, World" // チャネルに流す
}()
fmt.Println(<-stringStream) // stringStreamに何か(string)が流れるまでブロックされる

チャネルのブロックを解消する方法は他にも

close(stringStream)

の様にチャネルを閉じてあげる事で <-stringStreamの部分が検知する事が出来ます。

また、配列と同じ様にチャネルもrangeで回す事が出来ます。

for str := range stringStream {
  fmt.Println(str)
}

rangeのfor文も先程と同じ様に、closeを検知してループが終了します。

また、バッファ付きチャネルは宣言時に決めたn個が入るまでブロックされます。

intStream := make(chan int, 5) // バッファが5
for integer := range intStream { // intStreamに5つ流れるまでブロックされる(ループが始まらない)
  fmt.Println(integer)
}

select文

これから紹介する並行処理パターンではselect文も欠かせません！

select {
case <-channel1:
  fmt.Println("channel1 set up")
case <-channel2:
  fmt.Println("channel2 set up")
}

select文はどのチャネルが準備出来たかを評価します。
どのチャネルも準備出来ていない場合はselect文全体がブロックします。
これはイメージ湧きづらいと思うので、並行処理パターン紹介の時に出て来た時にみて見てください！

チャネルには読み込み専用と書き込み専用とその両方行えるものがあります。
どのチャネルにどの権限を与えるかもしっかりと考えた方が良いです。
しかし、便利な事に以下の様にして権限の割り振りが出来ます。

ch := make(chan string) // 書き込み、読み込み両方できる
hoge() := func(stringStream <-chan string) { // 引数に取ったチャネルが読み込み権限のみ
  fmt.Println(<-stringStream) // 書き込みは出来ない 
}(ch) // 普通に渡せる！

使ったら片付ける！

goroutineってほっとくと簡単に終わってしまったり(厳密には消えないけど)想定と違うタイミングで変数を上書きする事もあります。

先程上で厳密には消えないと述べましたが、これには理由があります。
ゴルーチンはランタイムによってガベージコレクションされないので片付け無ければなりません。
いくら軽量だからと言って放置する事は思わぬメモリリーク(ゴルーチンリーク)を引き起こす事になりかねません。

あるgoroutineがgoroutineの生成の責務を担うのであれば、そのgoroutineを停止出来るようにする責務も担わなくてはなりません。（名言）

goroutine生成元(親)から子への終了のシグナルには慣習としてdoneという名前の読み込みチャネルにします。
インターフェイス型はgolangのコミュニティでも敬遠されるイメージがありますが、doneチャネルに関しては問題無いかと思ってます。

doSomething := func(done <-chan interface{}, stringStream <-chan string) {
  for {
    select {
    case s := <-stringStream: // 今回は関係無いです
      fmt.Println(s)
    case <-done: // close(done)を検知し、doSomethingのgoroutineを終了する
      fmt.Println("doSomething 終了")
      return
    }
  }
}

done := make(chan interface{})

go func() { // 5秒後にdoneチャネルを閉じる
  time.Sleep(5 * time.Second) 
  close(done)
}()

doSomething(done, nil) // 5秒後に終了する

こんな風に親から子を終了させます。
任意のタイミングで複数のgoroutineを(ほぼ)同時に終了させることも簡単に出来ますね！

並行処理パターン

お待たせしました！
ちょっと長くなりましたが、明日から使える並行処理パターンを紹介していきます。
並行処理パターンではステージを並べたパイプラインを意識します。
ステージは受け取るものと返すものが同じ型でなければなりません。
パイプラインを使う事で各ステージでの懸念事項を切り分けることが出来ます。

いきなりステージとか言われてもなんやよう分からんですよね。。
そこで最初に意識して欲しいのはジェネレーターです。
パイプラインの始めにはチャネルへの変換を必要とするデータの塊が必ずあるはずです。
その責務を担うのが、ジェネレーターです。

// intを受け取り、intのチャネルを返す
generator := func(done <-chan interface{}, integers ...int) <-chan int {
  intStream := make(chan int, len(integers)) // generator goroutineの中で返却用のチャネルを作る
  go func() { // 別goroutineでintStreamへ値を流していく
    defer close(intStream)
    for _, i := range integers {
      select {
      case <-done:
        fmt.Println("generator goroutine終了")
        return
      case intStream <- i:
      }
    }
  }()
  return intStream
}

これだけでも並行処理の恩恵に感動しませんか！？
今まで「配列作って、値入れて、そこからfor文で処理する」としていた物が「配列(チャネルだけど)に値を流しながら、順番にfor文で処理する」出来るんです！
単純に考えて早くなりそうですよね！

このチャネルを使ってパイプライン処理を書いてみましょう！

// ただintStreamから流れてきた物に引数の値(multiplier)を乗算しているだけです笑
// 今までfor文で回していたような処理ですね！
multiply := func(done <-chan interface{}, intStream <-chan int, multiplier int) <-chan int {
  multipliedStream := make(chan int)
  go func() {
    defer close(multipliedStream)
    for i := range intStream {
      select {
      case <-done:
        return
      case multipliedStream <- i * multiplier;
      }
    }
  }()
  return multipliedStream
}

done := make(chan interface{})
defer close(done)

intStream := generator(done, 1, 2, 3, 4, 5)
pipeline := multiply(done, intStream, 2)

for v := range pipeline {
  fmt.Println(v)
}

これが並行処理の基本の一連の流れです！
雛形とまでは言えませんが、中の処理を変えるだけで、様々な処理が出来ると思います。
- ステージ
- パイプライン
- ジェネレーター
- doneチャネル
この要点を抑えるだけで綺麗な並行処理を行う事が出来ます！
これがパターンです！！！笑
ステージをもっと増やして組み合わせても問題ありません。

素数を5000まで出力すると、並行処理とブロック処理で2倍以上早かったです！

generator := func(done <-chan interface{}, num int) <-chan int {
  intStream := make(chan int)
  go func() {
    defer close(intStream)
    for i := 0; i < num; i++ {
      select {
      case <-done:
        return
      case intStream <- i:
      }
    }
  }()

  return intStream
}

// 素数判定(あってるかな？)
isPrimeNum := func(num int) bool {
  if num == 1 || num == 2 {
    for i := 2; i < num; i++ {
      if num%i == 0 {
        return false
      }
    }
  }

  return true
}

primeFinder := func(done <-chan interface{}, valueStream <-chan int) <-chan int {
  intStream := make(chan int)
  go func() {
    defer close(intStream)
    for v := range valueStream {
      if isPrimeNum(v) {
        intStream <- v
      }
    }
  }()

  return intStream
}

done := make(chan interface{})
defer close(done)

// ステージを複数使う時は重ねて記述しましょう！
for v := range primeFinder(done, generator(done, 5000)) {
  fmt.Println(v)
}

自身もまだまだなので間違いがあるかも知れませんが、温かく見守って頂ければと思います。
最後までありがとうございました！

明日の記事はyanananaさんによるジェネリクスを見ても逃げないです。

参考

• Go言語による並行処理

こんにちわ。ゴリラです。
最近GoでシンプルなTUIファイラーを作ったので、軽く紹介して実装の話をしていきます。

以前書いたこちらの記事でも軽く紹介しています。

機能

ざっくり以下の機能を持っています。

• ディレクトリ、ファイルの作成、削除、コピー、リネーム、プレビュー
• ディレクトリのブックマーク

詳しくはREADMEを参照してください。

実装について

筆者はTUIツールを作るときに、いつもtviewというライブラリを使っています。
tviewの基本的な使い方については別途記事を書く予定なので、本記事ではそれ以外でいくつかの機能の実装について解説していきます。

ファイル一覧

ioutil.ReadDir(dirname string) ([]os.FileInfo, error)を使ってパス配下のディレクトリ・ファイル情報を取得しています。
戻り値のos.FileInfoは以下のようにインターフェイスになっていて、ディレクトリ及びファイルの情報を取得できます。

// A FileInfo describes a file and is returned by Stat and Lstat.
type FileInfo interface {
    Name() string       // base name of the file
    Size() int64        // length in bytes for regular files; system-dependent for others
    Mode() FileMode     // file mode bits
    ModTime() time.Time // modification time
    IsDir() bool        // abbreviation for Mode().IsDir()
    Sys() interface{}   // underlying data source (can return nil)
}

FileInfoのメソッドについて解説していきます。

• Size()
Size()で取得できるのはバイト数になっていますが、そのままだと分かりづらいです。
  そこで、サイズを人間が読みやすい形に変換するdustin/go-humanizeといライブラリを使って読みやすい形式に変換しています。
  こちらのライブラリはサイズ以外にもいろんな情報を人間が読みやすい形に変換したりパースできます。詳細はREADMEを参照してください。

• Mode()
Mode()はファイルモードの情報os.FileModeを返しますが、そのまま出力すると上位1bitしか表示されません。
  ディレクトリならd--------が表示されます。os.FileModeにはString()が生えているので、それを使うとlsコマンドでみるような形式drwxr-xr-xが表示されます。

• OwnerとGroup
Sys()をsyscall.Stat_tに型アサーションしてOwnerとGroupを取ります。Sys()の実態はOSによって異なります。Windowsの場合はsyscall.Win32FileAttributeData型にアサーションします。
  Stat_tからはUidとGidを取得できるので、それをもとにos/userパッケージのLookupIdとLookupGroupIdを使用してユーザIDとグループIDから名前を取得します。

// get file owner, group
if stat, ok := file.Sys().(*syscall.Stat_t); ok {
    uid := strconv.Itoa(int(stat.Uid))
    u, err := user.LookupId(uid)
    if err != nil {
        owner = uid
    } else {
        owner = u.Username
    }
    gid := strconv.Itoa(int(stat.Gid))
    g, err := user.LookupGroupId(gid)
    if err != nil {
        group = gid
    } else {
        group = g.Name
    }
}

もう少し詳しく知りたい方はGoならわかるシステムプログラミングを読んでみてください。

ファイル、ディレクトリの操作

ファイル、ディレクトリのリネーム、新規作成などはosパッケージの関数を使用すれば簡単です。

操作	関数
ファイル作成	os.Create(name string) (*os.File, error)
ディレクトリ作成	os.Mkdir(name string, perm os.FileMode) error
ファイルの削除	os.Remove(name string) error
ディレクトリの削除	os.RemoveAll(path string) error
リネーム	os.Rename(oldpath, newpath string) error

1つ問題なのはファイル、ディレクトリのコピー関数が用意されていないことです。そもそもコピーのシステムコールがないからだと思います。
で、io.Copyを使えば中身のコピーはできますが、属性のコピーまではできないです。面倒だったので属性のコピーも含めてやってくれるotiai10/copyというライブラリをを使いました。

ブックマーク

ffはbでディレクトリをブックマークしておくことができます。ブックマークはデフォルトでは無効になっているので、
以下のようにconfig.yamlに設定を追記する必要があります。

bookmark:
  enable: true
  file: $XDG_CONFIG_HOME/ff/bookmark.db

このブックマークはsqlite3のDBを使っています。ffを起動するときにfileに設定したファイルをDBファイルとして使います。このファイルはなくても自動で作成するようになっています。以下の実装はブックマークの初期化処理になっています。

file = os.ExpandEnv(file)
// if db file is not exist, create new db file
if !system.IsExist(file) {
    if _, err := os.Create(file); err != nil {
        log.Println(err)
        // if can't create new file, use in memory db
        file = ":memory:"
    }
}

db, err := gorm.Open("sqlite3", file)
if err != nil {
    log.Println(err)
    return nil, err
}
db.SetLogger(DBLogger{})
db.LogMode(true)

if err := db.AutoMigrate(&Bookmark{}).Error; err != nil {
    log.Println(err)
    return nil, err
}

ファイルを作成できないときは:memory:で、インメモリにしています。メモリ上に一時的にDBを作成して使います。
正直インメモリのメリットは皆無なので、ここは改善しようかなと思っています。

ちなみに、sqlite3は面白いことに、空のファイルをDBとして使うことができます。
モックアプリを作る時にとても便利だなと思いました。

DBの操作はGORMというORMを使っています。標準のパッケージでも使おうかなと思いましたが、慣れているライブラリに頼りました。ちゃんとdatabase/sqlを勉強したい…

プレビュー

ffは引数-previewもしくは以下の設定をconfig.yamlに追加することでプレビュー機能を有効にすることができます。

preview:
  enable: false
  # preview colorscheme. you can use colorscheme following
  # https://xyproto.github.io/splash/docs/all.html
  colorscheme: monokai

プレビューではファイル、ディレクトリの中身をプレビューできます。ファイルはシンタックスハイライトされます。
ただ、大きすぎるファイルを開くと固まってしまうのでプレビューしないようしています。

シンタックスハイライトはalecthomas/chromaというライブラリを使っています。
ライブラリの使い方についてはREADMEを参照してください。
GoでソースコードをANSIエスケープシーケンスでハイライトしたいときに便利です。

具体的な実装は次のようになります。chromaはANSIの文字列を返しますが、そのままtviewに出力しても色がつかず、ANSIもそのまま出力されます。tviewでも色が表示できるようにtview.TranslateANSI()を使う必要があります。

func (p *Preview) Highlight(entry *Entry) string {
    // Determine lexer.
    b, err := ioutil.ReadFile(entry.PathName)
    if err != nil {
        log.Println(err)
        return err.Error()
    }

    ext := filepath.Ext(entry.Name)
    l := lexers.Get(ext)
    if l == nil {
        l = lexers.Analyse(string(b))
    }
    if l == nil {
        l = lexers.Fallback
    }
    l = chroma.Coalesce(l)

    // Determine formatter.
    // TODO check terminal
    f := formatters.Get("terminal256")
    if f == nil {
        f = formatters.Fallback
    }

    // Determine style.
    s := styles.Get(p.colorscheme)
    if s == nil {
        s = styles.Fallback
    }

    it, err := l.Tokenise(nil, string(b))
    if err != nil {
        log.Println(err)
        return err.Error()
    }

    var buf bytes.Buffer

    if err := f.Format(&buf, s, it); err != nil {
        log.Println(err)
        return err.Error()
    }

    return tview.TranslateANSI(buf.String())
}

ファイル編集

eで$EDITORを使ってファイルを編集できますが、Vimの場合は少し面白い動きをします。
Vimにはターミナルの機能があり、Vim上でターミナルを開きコマンドを実行することができます。
通常のターミナルなのでその中で更にVimを立ち上げることもできます。つまりVim in Vimになってしまうんです。
ffをVimのプラグインとして使う時、選択したファイルを起動中のVimで開きたいと思う方が多いかと思います。

そこで、Vimのterminal api機能を使って、選択したファイルを実行しているVimで開くようにします。
詳細は省きますが、Vimのターミナル上でsh -c 'echo "\x1b]51;[\"drop\",\"main.go\"]\x07"'を実行するとmain.goが開きます。便利ですね。
Goの場合はexecパッケージを使って実行します。

// if `ff` running in vim terminal, use running vim
if os.Getenv("VIM_TERMINAL") != "" && editor == "vim" {
    cmd := exec.Command("sh", "-c", fmt.Sprintf(`echo '\x1b]51;["drop","%s"]\x07'`, file))
    cmd.Stdout = os.Stdout
    return cmd.Run()
}

何を言っているのかよくわからない方もいると思いますが、以下のgifを見てみてください。
それでもよくわからんって方はぜひ試してみてください。

コマンド実行

ffは任意の外部コマンドを実行する事ができます。内部では単にexec.Commandを使っているだけです。

text := cmdline.GetText()
if text == "" {
    return
}

cmdText := strings.Split(text, " ")

// expand environments
for i, c := range cmdText[1:] {
    cmdText[i+1] = os.ExpandEnv(c)
}

cmd := exec.Command(cmdText[0], cmdText[1:]...)

buf := bytes.Buffer{}
cmd.Stderr = &buf
cmd.Stdout = &buf
if err := cmd.Run(); err == nil {
    cmdline.SetText("")
}

result := strings.TrimRight(buf.String(), "\n")
if result != "" {
    gui.Message(result, cmdline)
}

例えばmkdir -p a/b/cというようにディレクトリ階層を作りたい場合はコマンドのが早いです。そういった柔軟な使い方が出来るようにしたいためコマンド機能を実装しましたが、1点問題があります。
それは標準入力、出力を使用できないことです。
それによりVimといった標準入力を使うようなコマンドを実行するとffが固ります。
実装側で防ぐ方法があるなら良いのですが、今のところベストな対処法は思いつかないです。

一応READMEに記述していますが、ユーザに気をつけてねっていうような機能は果たしてどうなんだろう？というモヤモヤ感は自分の中にあるので将来的にはこの機能を廃止するかもしれないです。

まとめ

ざっくりですが、実装について軽く解説しました。ファイラーを作ることで、ファイルシステムまわりについて知見を得られたので、作ってよかったと感じています。
ただ、ファイルシステムの深いところは全然わからないので（例えばなぜコピーのシステムコールがないのかなど）、そこは引き続き勉強していこうと思います。

本稿は、Go2 Advent Calendar 2019 の 2 日目の記事です。
@pankona という名前でやっています。よろしくお願いします！

prealloc という linter について紹介します。

効率の悪い append

さて、Go を書いていると一度はやってしまうであろう "あまりよくないプラクティス" のひとつとして、いわゆる "append の連打" があるかと思います。
append を何度も何度も繰り返すようなコードは、ひらたく言えば "処理効率の悪いコード" になってしまう可能性があります。

package main

// append を繰り返すことによって効率が悪くなってしまう例

func AppendAndAppend() {
    var a []int

    // 1000 万回の append が行われていく
    for i := 0; i < 10000000; i++ {
        a = append(a, i)
    }
}

上記のスニペットには、以下のような問題点・改善点があります。

• append の際、配列の cap が足りないときは内部配列が確保しなおされます。内部配列の確保し直しは比較的コストの高い処理であり、何度も行うと時間が掛かります。
• 可能限り少ない回数で済ますのが (できれば一度で済ますのが)、処理効率の観点では良いと考えられます。

この例の場合は繰り返しの回数 (＝作られる配列の長さ) が分かっているので、以下のように書き換えることができます。

package main

// append による内部配列の再確保を抑える書き方

func MakeEnoughLen() {
    // make にて len をあらかじめ確保しておく
    a := make([]int, 10000000)

    for i := 0; i < 10000000; i++ {
        // append せずに直接代入する
        a[i] = i
    }
}

あるいは、以下のように書いても同等の処理速度が得られそうです。

package main

// append による内部配列の再確保を抑える書き方

func MakeEnoughCap() {
    // make にて cap をあらかじめ確保しておく
    a := make([]int, 0, 10000000)

    for i := 0; i < 10000000; i++ {
        // append を呼ぶが、cap が十分に確保されているので内部配列の再確保は行われない
        a = append(a, i)
    }
}

上記の 3 関数を Benchmark すると、以下のような結果が得られます。

BenchmarkAppendAndAppend-12     58911350            18.0 ns/op        42 B/op          0 allocs/op
BenchmarkMakeEnoughLen-12       624822230           3.49 ns/op         8 B/op          0 allocs/op
BenchmarkMakeEnoughCap-12       618240639           3.91 ns/op         8 B/op          0 allocs/op

最初にあげた例 (AppendAndAppend 関数) がダントツで遅いのがお分かりいただけるかと思います…！

golangci-lint で検出できるよ！ (ただし要有効化)

さて、効率の悪い append があるのは分かりましたが、これらは人間が目ヂカラを使って検出し、手ずから直していく必要があるのでしょうか。
否、実はこのパターンは lint によって発見することができます…！(手ずから直す必要はある)

取り出だしたるは、みなさんご存知 golangci-lint です。
golangci-lint は、最大で 40 個弱くらい (2019/12 現在) の Go の linter を一気に実行してくれる便利ツールです。

golangci-lint の中には prealloc と呼ばれる linter が含まれています (ただし、デフォルトでは無効になっています) 。

prealloc は、前項で紹介したような "ループ内で append を行っている、かつ繰り返し回数が明らかである" ような append にまつわる効率を改善できそうなコード を検出します。

まず、デフォルトで無効にされてしまっている prealloc を有効にするための golangci-lint の設定ファイルを紹介します。

# prealloc はデフォルトで無効なので、設定ファイルで有効にする
# prealloc を有効にするような golangci-lint の設定ファイルはたとえば以下

linters:
  enable:
    - prealloc

linters-settings:
  prealloc:
    simple: true
    range-loops: true
    for-loops: true

いざ、以下のソースコードを実験台にしてみます。

package main

func AppendAndAppend() {
    var a []int
    for i := 0; i < 10000000; i++ {
        a = append(a, i)
    }
}

件の設定ファイルを置いた状態で golangci-lint を実行すると、以下のような指摘があがります。

$ golangci-lint run
main.go:4:2: Consider preallocating `a` (prealloc)
    var a []int

a は事前に確保したほうがええやろ、と怒られました。なるほど便利…。

指摘を踏まえて、以下のように十分な cap を確保するようにしたところ、linter に怒られることはなくなりました。

package main

func AppendAndAppend() {
    a := make([]int, 0, 10000000)
    for i := 0; i < 10000000; i++ {
        a = append(a, i)
    }
}

なるほど便利…。

注意事項

prealloc という便利な linter について紹介しましたが、
実は golangci-lint の README.md の prealloc の項には以下のように注意書きがされています。

prealloc:
    # XXX: we don't recommend using this linter before doing performance profiling.
    # For most programs usage of prealloc will be a premature optimization.

要約すると、

• この linter を使う前に、まずパフォーマンスのプロファイリングをするのが先でしょう
• prealloc を使うのは多くの場合において早すぎる最適化だろう

とのことであります。わかる。

個人的には、常に append を効率良く書いておくことは早すぎる最適化の話とは違うんではないかと思わないでもないですが、
そもそも Go の append が雑な書き方でも割と速いこともあり、気にするのは後にしても良かろうというのはそのとおりかもしれません。

まとめ

prealloc という linter について紹介しました。早すぎる最適化はいかがでしょうか…！
気になった方は、ぜひちょいと試してみたらいいんじゃないかなと思います！Let's give it a try！

Go2 Advent Calendar 2019、3 日目は shibukawa さんです！

◇ 流れ

【Go言語】packageを作成
↓
importに「./XXXXX」でパス指定
↓
実行
↓
「cannot find module for path」と怒られる
↓
解決

◇ ディレクトリ構成

GOPATH
　┣━ bin
　┣━ pkg
　┗━ src
　 　　┗━ test
　 　　 　　┣━ route
　 　　 　　┃ 　 ┗━ route.go
　 　　 　　┣━ go.mod
　 　　 　　┗━ main.go

◇ go環境

ターミナル

$ go version
go version go1.13.4 windows/amd64

$ go env
set GO111MODULE=on
set GOBIN=C:\GOPATH\bin
set GOENV=C:\Users\XXXXXX\AppData\Roaming\go\env
set GOEXE=.exe
set GOHOSTARCH=amd64
set GOOS=windows
set GOPATH=C:\GOPATH
set GOROOT=C:\Go

◇ go.mod を作成。

プロジェクトルートに、$ go mod initでgo.modを作成。

ターミナル

$ cd C:\GOPATH\src\test

$ go mod init
go: creating new go.mod: module test

go.mod

module test

go 1.13

◇ main.go と route パッケージを作成。

main.go

package main

import "./route"

func main() {
    route.Route()
}

route/route.go

package route

import (
    "github.com/labstack/echo"
    "net/http"
)

func Route() {
    e := echo.New()

    e.GET("/", getHandler)

    e.Logger.Fatal(e.Start(":1323"))
}

// サイトを表示させる
func getHandler(c echo.Context) error {
    return c.String(http.StatusOK, "Hello, World!")
}

◇ 実行

ターミナル

go run main.go
go: finding golang.org/x/crypto latest
build _/c_/GOPATH/src/test/route: cannot find module for path _/c_/GOPATH/src/test/route

cannot find module for pathとエラーがでて怒られた。。。

パスはあっているのに何故か、
package の読み込みが出来ていないのでかなり詰まりました。

↓↓↓↓↓　解決策　↓↓↓↓↓↓

go.modにmodulの名前があるので
「./route」を「test/route」に置き換える

go.mod

module test ←　modulの名前

go 1.13

main.go

package main

import "./route" →　"test/route"  に変更

func main() {
    route.Route()
}

参考サイト

go 1.11のmodules(vgo)が有効な環境で相対importが cannot find module for path でエラーになった話。
https://pod.hatenablog.com/entry/2018/12/26/074944

概要

GolangでServiceを作る中で感じたunittestおよびClean Architectureという壁についてまとめてみた。

Golangにおけるテストとモック

『Unittestのために、モジュール間参照はインターフェースを使わなければならない』

Golangでunittestを書こうと思ったとき、困るのがモックだ。
例えばJavaであれば、どんなClassもそれを継承したClassを（無理やり）作る事ができるので、対象のコードの中の依存オブジェクトをモックに差し替える事ができる。
例えばPythonやJavaScriptであれば、そもそも型がないので自由にモックに差し替える事ができる。

ところが、Golangでは、

type Sample struct{}
var hoge = &Sample{}

としてしまうと、hogeにはSample構造体以外のものに差し替える事ができなくなる。構造体への参照には多態性はないのだ！

このことは、あるモジュールをテストするとき、そのモジュールが他のモジュールを構造体直参照していると「モックに差し替える事ができない」事を意味する。

だから、我々はこう書かなければならない。

type Sample interface {
   hoge()
}
type sample{} struct
func (s *sample) hoge() {
   // hoge
}
var hoge Sample = &sample{}

このように参照を構造体ではなくインターフェースを通した参照にしなければならない。

これがまずGolangでプログラムを書く際のきまりごとである。

Dependency Injection by Constructor

モジュールが別のモジュールを参照しているとき、モジュール間連携は必ずConstructによってDIしよう。

type A interface {
   Hoge() string
}
type a struct {
}
func (*a) Hoge() string {
   return "hoge"
}

type Sample struct {
   a A
}
func NewSample(a A) *Sample {
   return &Sample{a}
}

こうすれば、テストコード内でNewSample関数によって自由にmock_aを差し込んだSampleを作成できる。

def main(){
   a := &mockA{}
   sut := NewSample(a)
}

そして、production codeでは、一番外側のmain.goの中でDIしよう。

DIコンテナが欲しくなる時もあるが、それは別の話で

関数をモックと差し換えるOptionを用意する

例えばメソッドの中でtime.New()していたりuuid.NewV4()していたりするコードは多いと思う。これをテストでモックしようと思うと、monkey.Patchする必要が生じる。だがmonkey.Patchはどうも動作が不安定な気がしている。これは例えば

type Sample struct {
   uuid : func() (uuid.UUID, error)
   now : func() time.Time
}

func NewSample(opts ...SampleOption) *Sample {
   s := &Sample{
      uuid: uuid.NewV4
      now: time.Now
   }
   for _, f := range opts {
      f(s)
   }
   return s
}
type SampleOption func(*Sample)

func WithUUID(uuid : func() (uuid.UUID, error)) SampleOption {
   return func(s *Sample){
      s.uuid = uuid
   }
}
func WithNow(now : func() time.Time) SampleOption {
   return func(s *Sample){
      s.now = now
   }
}

func (s *Sample) Hoge() Fuga {
   now := s.now()
   id, err := s.uuid()
}

こんな風にして、、テストするときは

   s := NewSample(
      WithUUID(func() {
         return uuid.FromString("aaaa-aaaaa-...aaaaaa-aaaa")
      }),
      WithNow(func() {
         return time.Date(2000, 1, 1)
      }),
   )

これで、モジュールの依存先がstructであろうがfuncであろうが、コンストラクタを通してモックと差し換える事ができる。

Cyclic importとディレクトリ分割

Golangを書いていると、頻繁にcyclic import（循環参照）が発生する。
最もよく見るのが以下のようなパターン。

interfaceがimplを参照している

// interface

type Sample interface {
  hoge(options ...Option)
}

// impl
type sample struct{}
func (s *sample) hoge(option Option){
   // hoge
}
type Option func(s Sample)

例えばこんな風に書いてしまうと

interface ==> impl ==> interface

と循環参照になる。つまり

『implは必ずinterfaceを参照するのだから、interfaceはimplを参照してはならない。interfaceに登場するoptionやenumのような値は、interfaceで定義しなければならない』

cyclic import問題から、以下のことが言える（まあこういう言語は珍しくないのでGolang独自とは言えないかもしれないが）

『ディレクトリ内のファイル間では依存性問題は発生しない。ディレクトリを分割するなら、あらかじめディレクトリ間の依存の方向性を決定しておかなければならない』

言わずもがなと思うが、あるディレクトリ下に配置されるファイル間では、インポート問題は発生しないので、cyclic import問題は、プロジェクトを複数のディレクトリに分割しようとしたときにはじめて発生する。

そして、各ディレクトリを定義して、それぞれのディレクトリ間の参照の方向性を事前に決定しなければならない、ということがcyclic import問題から「Golangにおける開発の前提」であるという事が言える。

Clean Architecture in my opinion

以上を見ると、Clean Architectureというのは実はGolang開発の前提条件＋αに見えないだろうか？

Clean Architectureについて解説はしないが、
同心円の絵は、結局cyclic importを避けるためにディレクトリ間の依存の方向をコントロールするための提案である。これらの名称であったり、それぞれのモジュールが必要という事ではない。必要ないならhandlerだけでもいいし、handler ==> repository参照していても構わない。

右下の絵はモジュール間連携は必ずinterfaceを経由しようと言っているに過ぎない。Goland開発では当たり前のことだ。

結論

Golangの言語仕様は特殊のため、開発するうえで制限がある。その制限と戦うためには、どうしてもClean Architectureのような概念が必要なのだろうと思う。

Sprint bootやDjangoのようなフレームワークを使えば、フレームワークがディレクトリ構成を規定してくるが、Golang開発ではそういう規定はないっぽい

主要なライブラリ（aws-sdk-goも含めて）には、たいていインターフェースが含まれている事が多いと感じる。使用したい外部ライブラリがあったら、直接参照せずに済まないかインターフェースを探してみよう。

VISITS Technologies Advent Calendar 2019 3日目は@istshが担当します。

最近業務で、echoからgRPC-Gatewayに移行することになり、interceptorやmetadataについていろいろ調べたので、
gRPC Serverの実装(前編)とgRPC Clientの実装(後編)に分けてお送りしようと思います。

以降の説明は、サンプルコードを使って行います。

gRPC-Gatewayとは

gRPC-Gatewayとは、gRPCで書かれたAPIを、JSON over HTTPのAPIに変換して提供するためのミドルウェアです。

(よく見る図)

インストール

$ go get -u -v github.com/grpc-ecosystem/grpc-gateway/protoc-gen-grpc-gateway
$ go get -u -v github.com/golang/protobuf/protoc-gen-go

protoc-gen-validate

$ # fetches this repo into $GOPATH
$ go get -d github.com/envoyproxy/protoc-gen-validate
$ # installs PGV into $GOPATH/bin
$ make build

protoファイル

user.proto

syntax = "proto3";

package user;
option go_package = "github.com/istsh/go-grpc-sample/app/pb/v1/user";

import "google/api/annotations.proto";
import "validate/validate.proto";

service UserService {
    rpc CreateUser(CreateUserRequest) returns (CreateUserResponse) {
        option (google.api.http) = {
            post: "/v1/user"
            body: "*"
        };
    }
}

message CreateUserRequest {
    string email = 1 [(validate.rules).string = { min_len: 3, max_len: 254 }];
    string password = 2 [(validate.rules).string = { min_len: 8, max_len: 64 }];
}

message CreateUserResponse {
}

goファイルを生成

$ protoc \
    proto/v1/login/login.proto \
    -I . \
    -I $GOPATH/src/github.com/envoyproxy/protoc-gen-validate \
    -I $GOPATH/src/github.com/grpc-ecosystem/grpc-gateway/third_party/googleapis \
    -I $GOPATH/src/github.com/grpc-ecosystem/grpc-gateway \
    --go_out=plugins=grpc:$GOPATH/src \
    --validate_out="lang=go:$GOPATH/src" \
    --grpc-gateway_out=logtostderr=true:$GOPATH/src

これを実行すると、login.pb.goとlogin.pb.validate.goが生成されるはずです。

gRPC Serverの実装

ここからは実際のコードを見ながら解説していきます。
一部抜粋して説明するので、コード全体が見たい場合はサンプルコードを見てください。

main.go

package main

// 省略...

func main() {
    db := connectDB()
    defer db.Close()

    r := persistence.NewDBRepository(db)
    u := usecase.NewUserUsecase()

    listenPort, err := net.Listen("tcp", ":9090")
    if err != nil {
        logrus.Fatalln(err)
    }

    s := newGRPCServer(r, u)
    reflection.Register(s)
    s.Serve(listenPort)
}

上記のコードは、gRPC Serverをポート9090で起動するコードです。
DBの部分は説明する必要はないと思うので割愛します。

newGRPCServerが*grpc.Serverを返してくれるので、それを用いて任意のポートでサーバーを起動します。
ではnewGRPCServerの実装を見てみましょう。

main.go

func newGRPCServer(r repository.Repository, u usecase.UserUserCase) *grpc.Server {
    s := grpc.NewServer(
        grpc.UnaryInterceptor(grpc_middleware.ChainUnaryServer(
            interceptor.RequestIDInterceptor(),
            interceptor.AuthenticationInterceptor(),
            grpc_validator.UnaryServerInterceptor(),
            grpc_recovery.UnaryServerInterceptor(),
        )),
    )

    loginpb.RegisterLoginServiceServer(s, server.NewLoginServiceServer(r, u))
    userpb.RegisterUserServiceServer(s, server.NewUserServiceServer(r, u))

    return s
}

上記のコードは、インターセプターを4種類定義し、loginとuserで使うように設定しています。
RegisterLoginServiceServerとRegisterUserServiceServerは、前述のコマンドで生成したgoファイルに実装されているので、それを呼び出すだけです。
また、生成されたgoファイルには、LoginServiceServerやUserServiceServerといったインターフェースが定義されいます。
それを実装したうえでそれぞれを初期化する関数がNewLoginServiceServerやNewUserServiceServerになっています。

ここまではいろんな解説ページに載っていることですが、インターセプターに関しては情報が少ないのと、導入するプロジェクトに必要なインターフェースを選択したり、場合によっては実装することになるので、以降は上記の4種類のインターセプターについて解説します。

RequestIDInterceptor

requestid_interceptor.go

// RequestIDInterceptor is a interceptor of access control list.
func RequestIDInterceptor() grpc.UnaryServerInterceptor {
    return func(ctx context.Context, req interface{}, info *grpc.UnaryServerInfo, handler grpc.UnaryHandler) (interface{}, error) {
        requestID := requestid.RequestID(ctx)
        ctx = context.WithValue(ctx, log.CtxRequestIDKey, requestID)
        return handler(ctx, req)
    }
}

requestid.go

// RequestID takes a request id from metadata.
func RequestID(ctx context.Context) string {
    md, ok := metadata.FromIncomingContext(ctx)
    if !ok {
        return unknownRequestID
    }

    key := strings.ToLower(DefaultXRequestIDKey)
    header, ok := md[key]
    if !ok || len(header) == 0 {
        return unknownRequestID
    }

    requestID := header[0]
    if requestID == "" {
        return unknownRequestID
    }

    return requestID
}

上記のインターセプターは、contextからmetadataを取得し、そこにx-request-idというキーがあれば、その値を返し、なければ<unknown>を返すというコードです。
後編で不足分は解説しますが、gRPC ClientとHTTP Request Headerなどの情報を連携する為にmetadataを使います。

AuthenticationInterceptor

authentication_interceptor.go

// Authenticator provides Authenticate method.
// Each service should implement this interface, otherwise, all requests will be rejected with authentication error.
type Authenticator interface {
    Authenticate(ctx context.Context, req interface{}) (context.Context, error)
}

// AuthenticationInterceptor is a interceptor of authentication.
func AuthenticationInterceptor() grpc.UnaryServerInterceptor {
    return func(ctx context.Context, req interface{}, info *grpc.UnaryServerInfo, handler grpc.UnaryHandler) (interface{}, error) {
        authenticator, ok := info.Server.(Authenticator)
        if !ok {
            // If Service doesn't implement Authenticator, return InternalServerError always.
            return nil, status.New(codes.Internal, "Authenticator is not implemented").Err()
        }

        ctx, err := authenticator.Authenticate(ctx, req)
        if err != nil {
            return nil, status.New(codes.Unauthenticated, fmt.Sprintf("Not authenticated: %v", err)).Err()
        }

        return handler(ctx, req)
    }
}

上記のインターセプターは、Authenticateインターフェースを実装したサービスで認証の処理を実行するコードです。
非常にシンプルですが、各サービス毎に認証の処理を実装できるようになっています。

grpc_validator.UnaryServerInterceptor

これはgithub.com/grpc-ecosystem/go-grpc-middleware/validatorのインターセプターです。
goファイルの生成コマンドで、--validate_outオプションをつけることで生成される*.pb.validate.goの検証処理をやってくれます。
protoファイルでvalidateを使っている場合はこのインターフェースは必ず使いましょう。

grpc_recovery.UnaryServerInterceptor

これはgithub.com/grpc-ecosystem/go-grpc-middleware/recoveryのインターセプターで、panicをハンドリングしてくれます。

ChainUnaryServer

s := grpc.NewServer(
    grpc.UnaryInterceptor(grpc_middleware.ChainUnaryServer(
        interceptor.RequestIDInterceptor(),
        interceptor.AuthenticationInterceptor(),
        grpc_validator.UnaryServerInterceptor(),
        grpc_recovery.UnaryServerInterceptor(),
    )),
)

これまでの4つのインターセプターを順番に実行するために、grpc_middleware.ChainUnaryServerを使います。

まとめ

これでgRPC Server側の実装は一通り解説しました。
大切なのは、これはgRPC Serverについての説明であって、gRPC Client(gRPC-Gateway)についての説明は別ということです。
また、コードをみて気がついたかもしれませんが、紹介したインターセプターはgRPC Server用のものです。
後編でgRPC Clientのインターセプター(ログ、リクエストIDの採番など)も解説するので、お楽しみに。

別の記事で永続ディスク（Persistent Disk）設定方法を紹介しましたが、永続ディスクの制限は複数ノードからマウントして同時に読み書きできない。
本記事では、NFS（Network File System）を利用して、その制限を解決する方法を紹介致します。

実施手順

• Persistent Disk作成
• Persistent Diskフォーマット
• Persistent Diskを使って、NFSサーバ立ち上げ
• NFSを使って、GKE中にストレージを作成
• GKEのストレージマウントのPod作成

最初の２つのステップ（Persistent Disk作成、とPersistent Diskフォーマット）は別の記事で紹介したため、それらの記事を参照してください。

※本手順はGCPとgcloudコマンドの利用経験があることが望ましいです。

ワークフォルダの構成

nfs_on_gke
├── README.md
├── cloudbuild.dummyjob.yaml
├── deployment
│   ├── dummy_job_01.deployment.yaml
│   └── dummy_job_02.deployment.yaml
├── dummyjob.Dockerfile
├── job
│   └── dummyjob.go
├── nfs-container.deployment.yaml
├── nfs-service.deployment.yaml
└── nfs-volume.yaml

1. Persistent Diskを使って、NFSサーバ立ち上げ

nfs-container.deployment.yaml

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nfs-server
spec:
  replicas: 1
  selector:
    matchLabels:
      role: nfs-server
  template:
    metadata:
      labels:
        role: nfs-server
    spec:
      containers:
      - name: nfs-server
        image: gcr.io/google_containers/volume-nfs:latest
        ports:
          - name: nfs
            containerPort: 2049
          - name: mountd
            containerPort: 20048
          - name: rpcbind
            containerPort: 111
        securityContext:
          privileged: true
        volumeMounts:
          - mountPath: /exports
            name: mypvc
      volumes:
        - name: mypvc
          gcePersistentDisk:
            pdName: gce-nfs-disk
            fsType: ext4

nfs-service.deployment.yaml

apiVersion: v1
kind: Service
metadata:
  name: nfs-server
spec:
  ports:
    - name: nfs
      port: 2049
    - name: mountd
      port: 20048
    - name: rpcbind
      port: 111
  selector:
    role: nfs-server
  type: LoadBalancer

GKEにデプロイ

# クラスタ作成
gcloud container clusters create ds-gke-small-cluster \
    --project ds-project \
    --zone asia-northeast1-b \
    --machine-type n1-standard-1 \
    --num-nodes 1 \
    --enable-stackdriver-kubernetes

# k8sコントロールツールをインストール
gcloud components install kubectl
kubectl version

# GKEのクラスタにアクセスするため、credentialsを設定
gcloud container clusters get-credentials --zone asia-northeast1-b ds-gke-small-cluster

# デプロイ NFSサーバ
kubectl apply -f nfs-container.deployment.yaml

# 外からアクセスするため、NFSサービスをデプロイ。クラスタ内でアクセスしかない場合、このステップをスキップ
kubectl apply -f nfs-service.deployment.yaml

デプロイ後の確認

2. NFSを使って、GKE中にストレージを作成

nfs-volume.yaml

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-data-volume
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteMany
  nfs:
    server: "xx.xx.xx.xx"
    path: "/exports"
---
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: nfs-data-volume
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: ""
  resources:
    requests:
      storage: 10Gi

ボリューム定義実施

# PersistentVolumeとPersistentVolumeClaimを作成。複数接続で読み書きできるaccessModes（ReadWriteMany）
kubectl apply -f nfs-volume.yaml

定義実施後確認

3. GKEのストレージマウントのPod作成

golangで簡単なジョブを作成する。
ジョブ処理はoutput-pathにサンプル１０ファイルを作成する。予定は複数ジョブを稼働して、共有用のNFSにファイルを作成する。

dummyjob.go

package main

import (
    "flag"
    "fmt"
    "io/ioutil"
    "log"
    "os"
    "time"
)

var jobName = flag.String("job-name", "", "specify job name")
var outputPath = flag.String("output-path", "", "specify output path for job")

func main() {

    flag.Parse()

    outlog("Dummy Job start ...")

    for i := 0; i < 10; i++ {
        unixtime := time.Now().Unix()
        fileName := fmt.Sprint(*jobName, "_", unixtime, ".txt")

        // make a file
        file, err := os.Create(*outputPath + "/" + fileName)
        if err != nil {
            log.Fatal(err)
        }
        outlog("created a file: ", fileName)

        // out some
        file.WriteString("hello from " + *jobName)
        file.Close()

        // sleep to delay process
        time.Sleep(2 * time.Second)
    }

    // list all file in path
    outlog("List all files:")
    files, err := ioutil.ReadDir(*outputPath)
    if err != nil {
        log.Fatal(err)
    }

    for _, file := range files {
        outlog(file.Name())
    }

    outlog("Dummy Job finished.")

}

func outlog(args ...string) {
    log.Println(*jobName+":", args)
}

dummyjob.Dockerfile

FROM alpine:latest
WORKDIR /app
COPY ./dummyjob /app

cloudbuild.dummyjob.yaml

steps:
# go build
- name: golang:1.12
  dir: .
  args: ['go', 'build', '-o', 'dummyjob', 'job/dummyjob.go']
  env: ["CGO_ENABLED=0"]

# docker build
- name: 'gcr.io/cloud-builders/docker'
  dir: .
  args: [
         'build',
         '-t', '${_GCR_REGION}/${_GCR_PROJECT}/${_GCR_IMAGE_NAME}:${_GCR_TAG}',
         '-f', 'dummyjob.Dockerfile',
         '--cache-from', '${_GCR_REGION}/${_GCR_PROJECT}/${_GCR_IMAGE_NAME}:${_GCR_TAG}',
         '.'
        ]

# push image to Container Registry
- name: 'gcr.io/cloud-builders/docker'
  args: ["push", '${_GCR_REGION}/${_GCR_PROJECT}/${_GCR_IMAGE_NAME}']

substitutions:
  # # GCR region name to push image
  _GCR_REGION: asia.gcr.io
  # # Project ID
  _GCR_PROJECT: project-abc123
  # # Image name
  _GCR_IMAGE_NAME: dummy-job
  # # Image tag
  _GCR_TAG: latest

イメージをビルドして、２つのジョブをデプロイする

# build dummy-job image on Container Registry
gcloud builds submit --config cloudbuild.dummyjob.yaml

# deploy job
kubectl apply -f deployment/dummy_job_01.deployment.yaml
kubectl apply -f deployment/dummy_job_02.deployment.yaml

ビルドイメージの確認

デプロイジョブはGKEの中に確認

２つのジョブはNFSを共有利用できることを稼働ログで確認できます。

NFSを共有して読み書きできることを確認できました。

本記事で利用したソースコードはこちら

https://github.com/itdevsamurai/gke/tree/master/nfs

最後まで読んで頂き、どうも有難う御座います!

DevSamurai 橋本

関連記事：GKEの中で永続ディスク（Persistent Disk）の利用方法

Go言語入門者向けの簡単なチェックテストについて解説します。

まずはテスト１！

package main

func main() {s
    as := []struct{ N int }{{N: 10}, {N: 20}}
    for _, a := range as {
        a.N *= 10
    }
    println(as[0].N, as[1].N)
}

この表示結果はいくつになるでしょうか？

実行結果は以下になります。

$ go run main.go 
10 20

皆さん、シングルバイナリ サイコーですかー！（挨拶）

この記事は Go4 Advent Calendar 2019 の3日目の記事です。
今日は「ぼくのかんがえたさいきょうのシングルバイナリ生成ツール」を紹介したいと思います。

ことの発端

毎回言ってるのでもうご存知かもしれませんが、自分はシングルバイナリ大好きな人です。そして、コマンドをパイプでつなげるのが大好きな人でもあります。

そんな私が、あいも変わらずアクセスログの分析をしていました。
全体の処理はこの↓シェルスクリプトのようなかんじです：

pipeline.bash

#!/usr/bin/env bash

xz -cd "$@"                             \
  | jsonize                             \
  | jq -c 'select(.method == "GET")
         | select(.user_agent != "-")'  \
  | paw-ua                              \
  | insert-db

圧縮されたログを受け取って、解凍して、JSON形式にして、不要な行をjqでフィルタして、UserAgentをごにょごにょ¹して、DBにインサートするというだけです²。

上の jsonize、paw-ua、insert-db は、もちろんGoで実装しています。
で、実装したコマンドたちを、本番環境にコピーして使うわけです。こんなふうに：

$ scp pipeline.bash jsonize paw-ua insert-db prod-server:~/bin
$ ssh prod-server
prod-server> pipeline.bash /var/log/archive/*.xz

コピーするだけで動くシングルバイナリまじサイコーですね！

さてここで、ログデータに位置情報を付加してほしいという要望がありました。
というわけで、GeoIp2を使ってサクッと ip2geo コマンドを実装しました。
これをpipelineに追加しまして：

pipeline.bash

#!/usr/bin/env bash

xz -cd "$@"                             \
  | jsonize                             \
  | jq -c 'select(.method == "GET")
         | select(.user_agent != "-")'  \
  | paw-ua                              \
  | ip2geo -db ./GeoLite2-City.mmdb     \
  | insert-db

また本番環境にコピーして実行しましたらば・・・

$ scp pipeline.bash jsonize paw-ua insert-db prod-server:~
$ ssh prod-server
prod-server> pipeline.bash /var/log/archive/*.xz
pipeline.bash: ip2geo: command not found

あっ、ハイ、すみません・・・新しいコマンドをコピーするの忘れてました。。。

やっぱり、コマンド履歴にばかり頼ってちゃいけませんね・・・気を取り直しまして、

$ scp pipeline.bash jsonize paw-ua ip2geo insert-db prod-server:~/bin

今度はちゃんとコピーしましてから、実行してみますに～

$ ssh prod-server
prod-server> pipeline.bash /var/log/archive/*.xz
ip2geo: open GeoLite2-City.mmdb: no such file or directory

あゔぁゔぁゔぁゔぁゔぁゔぁ・・・
デスヨネー！GetLite2データベース³をコピるの忘れてましたよねー！！すいませんでしたよねー！！！

事ここに至るに当たり、気がついてしまったのです。おかしい、こんなはずじゃない、と。

僕らが夢見ていたシングルバイナリの世界はこんなはずじゃなかった！僕らが夢見ていたのは、バイナリ１つをコピーするだけで動くお手軽便利な世界ではなかったのか！？そうだ、今こそ取り戻そう！僕らの理想の世界を！！

というわけでWhole-In-One、略してWIO（わいおー）というのを作りました。

Whole-In-One なバイナリを作ってみよう

では、WIOの使い方の紹介です。まずはインストールから↓

Installation

ちょっと面倒なのですが、 go get ではなく、次のようにビルドスクリプトを使ってビルドしてください：

$ git clone github.com/Maki-Daisuke/go-whole-in-one
$ cd go-whole-in-one/cmd/wio
$ ./make.sh install

なお、Windows用にPowerShell版もあります⁴：

> git clone github.com/Maki-Daisuke/go-whole-in-one
> cd go-whole-in-one\cmd\wio
> .\make.ps1 install

これで wio コマンドが使えるようになりました。

Init

では、さっそく上の例をシングルバイナリにしていきましょう。
今回作成するシングルバイナリなコマンド名は mylog とします。安直ですねー

なにはともあれ、プロジェクト用のディレクトリを作りましょう：

$ mkdir mylog
$ cd mylog

そして、このディレクトリで wio init を実行します：

$ wio init
$ ls
main.go  pack.go  packing-list

すると、このように３つのファイルが出来上がりました。とりあえず、ファイルはこのままにしておきます。

Generate

次に、上の例にあった pipeline.bash、jsonize、paw-ua、ip2geo、insert-db を、それぞれ次のように頭に mylog-がつくようにリネームして、PATHの通っているところに置いておきます：

mv pipeline.bash mylog-pipeline
mv jsonize       mylog-jsonize
mv paw-ua        mylog-paw-ua
mv ip2geo        mylog-ip2geo
mv insert-db     mylog-insert-db

ファイル名の先頭に mylog- とつけておくことで、これから作るバイナリに中に含まれるようになります⁵。

リネームしたのに合わせて、pipelineの中身もファイル名を書き換えました：

mylog-pipeline

#!/usr/bin/env bash

xz -cd "$@"                                       \
  | mylog-jsonize                                 \
  | jq -c 'select(.method == "GET")
         | select(.user_agent != "-")'            \
  | mylog-paw-ua                                  \
  | mylog-ip2geo -db $WIOPATH/GeoLite2-City.mmdb  \
  | mylog-insert-db

おっと、GeoLite2データベースもバイナリに含めるのをわすれないようにしましょう。packing-listファイルを開いて、末尾にファイル名を追記しておきます：

packing-list

# This file was generated by wio-init.
mylog-*
./GeoLite2-City.mmdb  # ←この行を追加

ここまでできたら、ビルドしましょう：

$ wio build

これで、mylog コマンドができました。

Deploy

できたコマンドはこんなふうに使えます：

$ scp mylog prod-server:~/bin
$ ssh prod-server
prod-server> mylog pipeline /var/log/archive/*.xz

mylog と pipeline の間に-（ハイフン）がない点にご注意ください。mylog-pipeline が mylog のサブコマンドのようにして呼び出されていますね。これは、mylog-jsonize など他のコマンドについても同様です。

また、GeoLite2データベースも含まれているので、なんらかの外部ファイルに依存しているようなコマンドもシングルバイナリの中に押し込むことができます。なので、バイナリ１個コピーするだけでお手軽便利にコマンドが実行できる世界がやってきました！

やっぱり、シングルバイナリ サイコーですね！

しかしさらなる問題が…

もしかしたら、上のスクリプトを見た人の中には気づいてしまった人もいるかもしれませんね。そう、mylog-pipelineスクリプトは jq がインストールされている環境じゃないと動かないということを！！⁶
これでは真のシングルバイナリとは言えないのではないか！！！?！！！

しかし案ずるでない、迷える子羊よ。そなたは如何なるファイルでもバイナリに埋め込むことができる！ほれ、このように packing-list に追加するのじゃ：

packing-list

# This file was generated by wio-init.
mylog-*
./GeoLite2-City.mmdb
jq  # ←この行を追加

そしておもむろにビルドしてコピーすれば、あら不思議・・・

$ wio build
$ scp mylog prod-server:~/bin
$ ssh prod-server
prod-server> mylog pipeline /var/log/archive/*.xz
jq: error while loading shared libraries: libonig.so.2: cannot open shared object file: No such file or directory

エラーで怒られるのである・・・orz

デスヨネー。jq さんには 鬼車 が必要ですもんねー！

気を取り直して

はいはい、鬼車がいるんなら、libonig.soを埋め込んであげればいいんでしょ⁷：

packing-list

# This file was generated by wio-init.
mylog-*
./GeoLite2-City.mmdb
jq
/usr/lib/x86_64-linux-gnu/libonig.so.2  # ←さらに追加

というわけで、再チャレンジ：

$ wio build
$ scp mylog prod-server:~/bin
$ ssh prod-server
prod-server> mylog pipeline /var/log/archive/*.xz

今度は動きました！⁸

仕組み

ちょっとだけWIOの仕組みについて書いておきましょう。

と言っても、とても単純で、packing-list で指定されたファイルを tar形式にかためて、バイナリに埋め込んでいるだけです。
mylogコマンドが実行されたときに、tarファイルをtempディレクトリに展開して、そこにPATHを通すなどの下準備をしてからサブコマンドに execしているというわけです。ちなみに、tarの展開はコマンドの初回起動時のみで、２回目以降はtempディレクトリのキャッシュが使われます⁹。

wio init は、デフォルトで コマンド名-サブコマンド名 という名前のコマンドをPATHから探索して実行する main関数を出力しますので、上記のように mylog-サブコマンド という命名規則にしておくと、埋め込んだコマンドがサブコマンドのように呼び出せるようになるのです¹⁰

で、実際どうやってバイナリに埋め込んでんの？

それは、ソースコードのこのへんを見てもらえればわかると思うのですが、pack.go のひな形の中に %q というフォーマット文字列が見えるかと思います：

func WritePackGo(data []byte, codec string) error {
    ...(中略)...
    _, err = fmt.Fprintf(out, `// DO NOT EDIT! This file was generated by wio-init.
package main
import(
    ...(中略)...
)
var(
    data = %q
    hash = "%X"
)
    ...(中略)...
`, data, md5.Sum(data), codec)
    return err
}

で、ここにtarで固めたデータをドカドカっと流し込んで、Goコンパイラに文字列としてコンパイルしてもらっているだけです。
そうなんですねー。こんな乱暴な方法でも、ちゃんとGoコンパイラはコンパイルしてくれるんですねー。すごいですねー！（小並感）¹¹

Let's enjoy シングルバイナリ

というわけで、皆さんもお手軽便利なシングルバイナリ・ライフを楽しんでください。

詳しい使い方は WIOのドキュメントを参照してくださいね。

それでは、シングルバイナリまじサイコー！（別れの挨拶）

---

1. ギョーム内容につき、お察しください。 ↩

2. ちなみに自分は、とりあえずログをJSONに変換してしまって、LDJSONをパイプラインでひとつひとつ変換処理かけていくのが好みです。こうするとパイプラインの各コマンドが並列で走るので、自然とマルチコアの恩恵を受けられますしね。 ↩

3. MaxMaind社の提供するIPアドレスと地点情報の紐付けデータベースです（https://dev.maxmind.com/geoip/geoip2/geolite2/ ）。 GeoIp2 で使います。 ↩

4. ちなみに今のところ、Linux（Ubuntu 16.04）、macOS (Mojave)、Windows 10 (1909) で動作確認してあります。たぶん、BSDとかの他のUNIX系OSでも動くとは思いますが、確認環境がないためビルドタグはつけていません。どなたか興味がある人は、誰か試してみてほしいです。 ↩

5. あとで紹介しますが、ファイル名を変えなくてもバイナリに含む方法もあります。 ↩

6. まぁ、それを言ったら xz もなんですが、イマドキは xz は標準で入っていることが多いので、横においておきます。 ↩

7. ちなみに、作業環境は開発環境・本番環境ともにUbuntuです。（ただし、開発環境はUbuntu on WSL） ↩

8. 今回はたまたまjqの依存ライブラリが少なくてうまくいきましたが、現実にはこんなふうにうまくいくケースは少ないと思います。依存ライブラリが大量にある場合もありますし、そのライブラリがさらに他のライブラリに依存していたりするので、ただしく必要なライブラリのリストを抽出するのはかなり大変です。従って、シングルバイナリで動くGo製のコマンドか、シェルスクリプトを埋め込むのが現実的な範囲です。複雑な依存関係をデプロイしたいなら、素直にDockerみたいなコンテナで配布するのがいいと思います。だだし、Dockerを使うためにはroot権限が必要なんですよね。root権限なしに、ホームディレクトリにコピるだけで動くのが、シングルバイナリの利点ですよね！ ↩

9. お気づきの方もいるかもしれませんが、これは古式ゆかしい(？)PAR::Packaer と同じ仕組みです。 ↩

10. ご想像のとおり、サブコマンドをPATHから探索して実行する様式はGitサブコマンドをマネたものです。このあたりのmain関数の挙動は main.go を書き換えれば好きなように変更できます。詳しくは WIOのドキュメントを参照してください。 ↩

11. ちなみにこの手法は、今一番主流のバイナリ埋め込みツールと目されるstatikを参考にしています。なので、こんな乱暴な方法でも問題はないと思います。 ↩

はじめに

[CA Tech Dojo/Challenge/JOB Advent Calendar 2019]の3日目はハゲが書かせていただきます。私は今年の夏に「CA Tech Dojo (Go)」に参加させていただきました。自走力が鍛えられる内容で、その後の学習の生産性が向上するのでおススメです。その時の「参加レポート」があるので、興味のある人はぜひ見てください。

本題

今日はFIDOと呼ばれる新しい認証の仕組みについて紹介します。時間が無くて実装まで手が付けれなかったので、後日更新します。

IDとパスワードを用いた認証の問題点

• リスト攻撃に弱いこと
  あらかじめ入手してリスト化したID・パスワードを利用して、アクセスされてしまう。

• フィッシング攻撃に弱いこと
  ユーザが正規のサイトによく似たサイトにIDとパスワードを入力してしまい、盗まれる。

• 利用しているサービスの数だけパスワードを記憶しておかなければならないこと
  紙媒体に書いてしまったり、同じものを使いまわしてしまったり、忘れてしまったりする。→ユーザ体験の品質が下がる。

• 入力する手間がめんどくさいこと
  ユーザ体験の品質が下がる。

FIDO（Fast IDentity Online）とは

セキュリティとユーザ体験を共存させる認証技術を提供する仕組みのことです。パスワードレスな認証にすることでパスワード認証の問題を解決しました。

FIDOの余談

現在ではFIDO2も誕生し、Web認証やデバイス間連携に対応したことでFIDO認証が広く使われるようになりました。今後はAndroidなどのネイティブアプリ上でFIDO認証ができるようにするそうです。今回扱うのはFIDO2です。

FIDOの登録・認証モデル

①利用者は事前に認証器を認証サーバに登録する。

②この際に、認証器は秘密鍵と公開鍵のペアを生成し、公開鍵とユーザIDを紐づけて認証サーバに送付する。

③認証の際には、認証サーバが一度だけ有効なランダムな文字列（challenge）を生成し、認証器に送付する。

④認証器が生体情報などで本人性を検証したら、このchallengeに対して秘密鍵で署名を生成し、署名付きchallengeを認証サーバに送る。

⑤認証サーバは公開鍵によって復号し、適切な署名であることを検証出来たら認証が成功する。

従来の認証モデルとFIDOの認証モデルの違い

従来の認証は、利用者が通信路を介して、ID、クレデンシャル情報(パスワードや生体情報など)を認証サーバに送付する仕組みだったので、利用者と認証サーバでクレデンシャル情報を共有していました。

しかし、FIDOは、認証器によってローカルで本人性を認証するプロセスと、認証サーバに検証結果を送付するというプロセスを分離しているので、ネットワーク上にクレデンシャル情報が流れることはないという強みがあります。

生体認証に関する余談

生体情報を用いた認証は、パスワードを用いる認証に比べて、パスワードを記憶する必要が無かったり、入力する手間が省けたりと最高のユーザ体験を提供していましたが、生体情報は変更が難しいため、一度流出すると二度と使えなくなることから、管理コストが高くなってしまうという問題点がありました。しかし、FIDOを用いることによって通信経路で生体情報が流出する可能性がなくなったので生体認証が普及しやすくなりました。とてもありがたいです。

FIDO2のサーバサイド実装（Golang）

環境
Ubuntu18.04LTS
Golang1.11.5

今回はFIDO2を使ってWeb上でFIDO認証をできるようにします。
まずはライブラリをインポートします。
go get github.com/duo-labs/webauthn
また、軽量なWebツールキットのgorillaを使います。
go get github.com/gorilla/mux
次にオープンソースのFIDO2サーバをインストールします。
インストール手順は「こちらを参考」にしてください。

実装は認証サーバに登録する処理と認証する処理の二つの手順を説明します。

①登録のフロー

アテステーションがよくわからないと思うので[こちらの記事]を参考にしてください。

②認証のフロー

登録と認証でフローにあまり差がないのでまとめて解説しますが、ここではFIDOの解説論文の引用をします。

（ 1 ） 利用者は PC のブラウザで RP の登録ページへのリンクをクリック若しくは URL を入力する．
（ 2 ） ブラウザは指定されたアドレスへ要求を行う．
（ 3 ） RP サーバは FIDO 鍵登録を開始する旨を FIDO サーバへ伝える．
（ 4 ） FIDO サーバはメタデータを利用してポリシーの一覧とチャレンジを作成し，RP へ応答する．
（ 5 ） RP も UAF と同様にポリシーを追加し，ブラウザにJavaScript とチャレンジとともに送信する．
（ 6 ） PC とスマートフォンは例えば Bluetooth のペアリングのような初期接続作業を事前にしておく，若しくはまだ接続されていない状態であればこのときに行う．RP が送信した JavaScript によって PC からスマートフォンへmakeCredential()（鍵生成要求）が呼び出される．(CTAP)
（ 7 ） 対応する認証器に鍵生成要求が届けられ，利用者にジェスチャを求める．
（ 8 ） 利用者は認証の内容を確認した上で，ジェスチャを入力する．
（ 9 ） 認証器は利用者の認証が成功したら RP 固有のアテステーション用秘密鍵を使ってチャレンジに署名する．
（ 10 ） 作成した署名とともに認証用公開鍵をブラウザ，RPサーバを通じて FIDO サーバへ送信する
（ 11 ） FIDO サーバはアテステーション用公開鍵を使って署名を検証し，成功した場合，認証用公開鍵を利用者とひも付けて登録する．
（ 12 ） 上記までの手順でエラーがなかった場合，登録完了ページをブラウザに表示する．

[5][解説論文 FIDO認証とその技術]

Golangで実装する部分はRPサーバの部分で、基本的にブラウザやFIDOサーバとの通信がメインです。時間なかったのでソースコードは後日乗っけます。

Step1. RPサーバはブラウザから利用者のIDを受け取り、FIDO鍵登録を開始する旨をFIDOサーバへ伝える。

Step2. FIDOサーバのAPIにアクセスし、FIDOサーバで作成されたポリシーとチャレンジを受け取る。

Step3. RPもポリシーを加え、ブラウザに送信する。

このあと、認証器で生体情報による認証がおこなわれ、チャレンジに署名を加えたものと認証用の公開鍵をRPに送る。

Step4. 署名付きのチャレンジと認証用公開鍵をブラウザから受け取り、FIDOサーバへ送信する。

Step5. FIDOサーバ上で検証に成功したら、公開鍵と利用者のIDを紐づけて登録する。

Step6. エラーが無ければ登録完了ページをブラウザへ返す。

認証のフローで登録のフローと違う部分は、認証器による認証後、つまりStep4の署名付きのチャレンジと認証用公開鍵をブラウザから受け取りFIDOサーバへ送信する部分です。登録時に公開鍵はすでにFIDOサーバに保管されているため、ブラウザからは公開鍵は送られず、署名付きのチャレンジを送付するだけで済みます。

参考文献

[1]GitHub duo-labs/webautun
[2]WebAuthnでパスワードレスなサイトを作る。安全なオンライン認証を導入するFIDOの基本
[3]FIDO認証によるパスワードレスログイン実装入門
[4]Mercari Engineering Blog
[5]FIDO 認証とその技術
[6]アテステーションとは