2017/01/12


この記事には幾らか正しくない部分がありました。後で訂正していきますが、ひとまず shogo82148 さんの解説記事も確認下さい。

http.Client はリクエスト毎に名前を引くので連続したアクセスはあまり速くない。

Go 1.8 からは Resolver が提供されるので、自前で簡単に名前引きのキャッシュを実装出来る。

Go 1.9 だった様です。

Go 1.8 Release Notes - The Go Programming Language

DRAFT RELEASE NOTES - Introduction to Go 1.8 Go 1.8 is not yet released. These are work-in-progress ...

https://beta.golang.org/doc/go1.8#more_context

ただそれまで待てないという人には nett がオススメ。

GitHub - abursavich/nett: Package nett steals from the standard library's net package and provides a dialer with a pluggable host resolver.

Package nett steals from the standard library's net package and provides a dialer with a pluggable host resolver.

https://github.com/abursavich/nett

これを http.ClientDialer として設定すれば、指定期間内の名前引きをキャッシュできる。

dialer := &nett.Dialer{
    // Cache successful DNS lookups for five minutes
    // using DefaultResolver to fill the cache.
    Resolver: &nett.CacheResolver{TTL: 5 * time.Minute},
    // Concurrently dial an IPv4 and an IPv6 address and
    // return the connection that is established first.
    IPFilter: nett.DualStack,
    // Give up after ten seconds including DNS resolution.
    Timeout: 10 * time.Second,
}
client := &http.Client{
    Transport: &http.Transport{
        // Use the Dialer.
        Dial: dialer.Dial,
    },
}
urls := []string{
    "https://www.google.com/search?q=golang",
    "https://www.google.com/search?q=godoc",
    "https://www.google.com/search?q=golang-nuts",
}
for _, url := range urls {
    resp, err := client.Get(url)
    if err != nil {
        panic(err)
    }
    io.Copy(ioutil.Discard, resp.Body)
    resp.Body.Close()
}

※ README から引用

実際にどれくらいパフォーマンスが出るかベンチマークを取ってみました。

package main

import (
    "io"
    "io/ioutil"
    "net/http"
    "testing"
    "time"

    "github.com/abursavich/nett"
)

var (
    urls = []string{
        "https://www.google.com/search?q=golang",
        "https://www.google.com/search?q=godoc",
        "https://www.google.com/search?q=golang-nuts",
    }
)

func BenchmarkNet(b *testing.B) {
    b.ResetTimer()
    client := http.DefaultClient
    for _, url := range urls {
        resp, err := client.Get(url)
        if err != nil {
            panic(err)
        }
        io.Copy(ioutil.Discard, resp.Body)
        resp.Body.Close()
    }
}

func BenchmarkNett(b *testing.B) {
    b.ResetTimer()
    dialer := &nett.Dialer{
        Resolver: &nett.CacheResolver{TTL: 5 * time.Minute},
        IPFilter: nett.DualStack,
        Timeout:  10 * time.Second,
    }
    client := &http.Client{
        Transport: &http.Transport{
            Dial:  dialer.Dial,
            Proxy: http.ProxyFromEnvironment,
        },
    }
    for _, url := range urls {
        resp, err := client.Get(url)
        if err != nil {
            panic(err)
        }
        io.Copy(ioutil.Discard, resp.Body)
        resp.Body.Close()
    }
}

URL 3つしかアクセスしていませんが、如実に結果が出ています。(およそ2倍)

BenchmarkNet-4                 1        1053105300 ns/op
BenchmarkNett-4                2         506050600 ns/op
PASS
ok      _/C_/dev/go-sandbox/slowdns     3.268s

リクエスト毎に毎回設定していられないって人はデフォルトの http.DefaultTransport を書き換えてしまえばシステム全体がこの恩恵を得られます。

http.DefaultTransport.(*http.Transport).Dialer = &nett.Dialer{
    Resolver: &nett.CacheResolver{TTL: 5 * time.Minute},
    IPFilter: nett.DualStack,
    Timeout:  10 * time.Second,
}

追記

この後、他の環境でベンチマークを取り直してみましたが、結果が出ない事もある様です。

$ go test -count=3 -test.bench BenchmarkNetP
BenchmarkNetP-4                1        1116008300 ns/op
BenchmarkNetP-4                2         900440950 ns/op
BenchmarkNetP-4                2         890325100 ns/op
PASS
ok      github.com/mattn/go-sandbox/nett        6.844s

$ go test -count=3 -test.bench BenchmarkNettP
BenchmarkNettP-4               2         952601050 ns/op
BenchmarkNettP-4               2         960558450 ns/op
BenchmarkNettP-4               1        1010136400 ns/op
PASS
ok      github.com/mattn/go-sandbox/nett        6.925s

あまりおすすめできませんね。すみません。。。


2017/01/11


おそらく golang を暫く使っておられる方であればご存じだと思いますが今日は crypto/ssh を紹介します。

Windows で ssh と聞くとどうしても msys やら cygwin やら入れないといけなくて

  • ランタイムを入れるのが嫌だ
  • 特殊なパス形式とか嫌だ
  • そもそも業務で使いづらい

といった個人的もしくは政治的な事柄が起きてなかなか実現しづらかったりします。でも golang なら msys や cygwin に頼らず ssh コマンドを、しかもライブラリとして扱う事が出来るので golang で作ったウェブサーバやバッチから UNIX ホストに対して ssh コマンドを送る事が出来るのです。

ssh - GoDoc

package ssh import "golang.org/x/crypto/ssh" Package ssh implements an SSH client and server. SSH is...

https://godoc.org/golang.org/x/crypto/ssh

しかも openssh に依存していないので、openssh の実装に脆弱性が発見されたとしても影響を受けません。インタフェースも netos/exec がうまく組み合わさったイメージで扱う事が出来て非常に便利かつ拡張性のあるパッケージになっています。どれくらい簡単で拡張性が高いかを分かって頂ける様にオレオレ ssh コマンドを作ってみました。通常 ssh コマンドはユーザ名、ホストおよびオプションを指定して ssh コマンドを起動し、パスワードプロンプトにパスワード(パスフレーズ)を入力してログインしますが、この例ではパスワードをコマンド引数から得られる様にしてあります。

package main

import (
    "flag"
    "fmt"
    "os"
    "strings"
    "time"

    "golang.org/x/crypto/ssh"
)

var (
    user     = flag.String("u""""user")
    password = flag.String("p""""password")
    port     = flag.Int("P"22"port")
)

func run() int {
    flag.Parse()
    if flag.NArg() == 0 {
        flag.Usage()
        return 2
    }

    config := &ssh.ClientConfig{
        User: *user,
        Auth: []ssh.AuthMethod{
            ssh.Password(*password),
        },
        Timeout: 5 * time.Second,
    }

    hostport := fmt.Sprintf("%s:%d", flag.Arg(0), *port)
    conn, err := ssh.Dial("tcp", hostport, config)
    if err != nil {
        fmt.Fprintf(os.Stderr, "cannot connect %v%v", hostport, err)
        return 1
    }
    defer conn.Close()

    session, err := conn.NewSession()
    if err != nil {
        fmt.Fprintf(os.Stderr, "cannot open new session: %v", err)
        return 1
    }
    defer session.Close()

    go func() {
        time.Sleep(5 * time.Second)
        conn.Close()
    }()

    session.Stdout = os.Stdout
    session.Stderr = os.Stderr
    session.Stdin = os.Stdin
    err = session.Run(strings.Join(flag.Args()[1:], " "))
    if err != nil {
        fmt.Fprint(os.Stderr, err)
        if ee, ok := err.(*ssh.ExitError); ok {
            return ee.ExitStatus()
        }
        return 1
    }
    return 0
}

func main() {
    os.Exit(run())
}

os/exec.Command と同じ様に os.Stdout や os.Stderr をパイプ出来る様になっていて、終了コードも得られる様になっています。簡単ですね。もう少しコードを足せば公開鍵認証を行う事も出来ます。詳しくはドキュメントを参照して下さい。サーバがパスワード認証をサポートしている場合にはバッチコマンドとして実行出来るので、もしかすると意外と便利かもしれません。ただしパスワードがコマンド引数になるという事は、ps コマンドで他のユーザにパスワードが漏れてしまう危険性がある事を理解しておいて下さい。

みんなのGo言語【現場で使える実践テクニック】 みんなのGo言語【現場で使える実践テクニック】
松木雅幸, mattn, 藤原俊一郎, 中島大一, 牧 大輔, 鈴木健太
技術評論社 / ¥ 2,138 (2016-09-09)
 
発送可能時間:在庫あり。


2017/01/06


Twitter で「言語のしくみ」読みたいなって呟いたら Matz 本人から「献本しましょうか」とメンション頂いて即答でお願いしました。ありがとうございます。

まつもとゆきひろ 言語のしくみ まつもとゆきひろ 言語のしくみ
まつもとゆきひろ
日経BP社 / (2016-12-22)
 
発送可能時間:

ひさびさ紙の本を通勤電車の中で立ちながら読んだので手がだるくなりました。なんだか懐かしい感じがしました。

さてこの本ですが、一言で言うとこんな本です。

Ruby のパパこと Matz が雑誌の連載に追われながら試行錯誤して作ったプログラミング言語「Streem」を解説する本

聞こえが悪かったらすみません。言いたいのはこの「試行錯誤」がとても良いエッセンスになっている点なのです。実際にはその連載記事をまとめた物に対して、この当時はこの様に考えていたが後になってみると実は良く無かったといった振り返り「タイムマシンコラム」で構成されています。

この連載が1つの本に纏められた事でプログラミング言語設計者の葛藤が非常に良く表されているな、そう思ったのです。本書の中では Matz が「以降 Streem をこういう設計にしたい」と考え実装していくのですが、いくら Matz とは言えど設計に迷いは生じます。連載の為に期間も守らないといけません。どっちが良いか迷って実装してしまった後、次月号で別の実装に直してしまうといった内容も出てきます。一エンジニアとしてすごく共感できました。はじめから出来上がった Streem に対して解説して行く内容になっていたら、もしかするとこんなに面白くなっていなかったかもしれません。

内容は Streem を設計(デザイン)し実装していく過程を細かく書いてあり、プログラミング言語を作る過程に必要な知識や歴史、なぜあの言語はそういうデザインになっているか、なぜ Ruby はこうなっているのか、そういった Matz でしか知り得ない内容も盛りだくさんです。プログラミング言語に興味のある方は買いではないでしょうか。

ところで皆さん、プログラミング言語って作った事あるでしょうか。プログラミング言語の実装は、一般的なライブラリやツール類と比べると設計や実装内容が幾らか異なります。正直、技術スキルも要します。ある程度動く様な形に持っていくには何度も心が折れそうにもなります。インターネットのブログ記事で「○○言語を作った」といった内容を読んで

なんとなく理解はできる。僕もやればきっと出来る。でも時間がない。

そう考えている人もいるかもしれません。僕も大昔はそう思っていたかもしれません。ただ幾らかプログラミング言語を作ったり、色んなプログラミング言語にコントリビュートしてきた経験のある僕からひとこと言わせて貰えるならば、こう言いたのです。

プログラミング言語はある程度の自信がないと作れないが、作れるとそれはより大きな、そしてより確かな自信へと変わる

ちょっとカッコ良すぎる事を書いてしまいましたが、実際にそうなのです。人生の中でプログラミング言語を作るなんて事は何十回もやれる経験では無いです。だからこそ自分が手掛けたプログラミング言語が一様に動く様になった際には、なんとも言えない愛着が湧いてくるのです。そして至らない設計を見つけた際にはとにかく憎たらしくもなります。自分で作ったプログラミング言語と葛藤する事になります。「なんでこんな設計にしちゃったんだよ」と自分を戒める事も多々起きます。でもそれを乗り越えた時の満足感は、実装してみた事がある人しか分からない自信へと変わるのです。

Matz も本書で書かれていましたが、プログラミング言語をデザインしている時はよく手が止まります。僕のケースであれば、よくブツブツと喋っているそうです。プログラミング言語を作るにはコンピュータを触っていない時間の方が大事だと僕は思います。あーでもないこーでもないと頭を捻って編み出した最適化がうまくキマった時には誰かに言いたいけど誰にもいえない変な喜びが起きます。プログラミング言語を作った事がある人ならば分かって貰えると思います。一見一人でブツブツ言ってニヤニヤしてとても変態っぽいのですが、そんな僕から見ても Matz の言語オタク度は手の届かない領域だと分かる一冊でした。読みながら「ほんとに言語好きなんだなw」と言いたくなりました。プログラミング言語に係った事がある人ならば、とにかく読みながら「うんうん、分かる分かる」と言いたくなる本です。その中でも特に「わかるー」と言いたくなったのが以下の一言です。

開発者・設計者が使いたい言語そして機能でないとユーザは使ってくれない

手前味噌の話ですが、Vim script には lambda が無くとても不便でした。リストを並べ替える sort に比較関数を渡す為だけに名前付き関数を定義しないといけませんでした。とにかく欲しくて何度か vim-dev に駆け寄りました。メンションは貰えるのですが、結局だれも作り出そうとしないまま月日が流れて諦めかけていたのですが

誰もやってくれないなら自分でやるしかない。だって世界中でこの機能が一番欲しいのは僕なんだ。

と心に決め、思うがままに実装しました。最終的には形はずいぶんと変わってしまいましたが、vim8 に lambda が入った際にはなんとも言えない満足感が得られました。

lambda 関数作ろうぜ! · Issue #632 - vim-jp/issues - GitHub

キャプチャされる関数の引数名がキャプチャする関数の引数名とバッティングすることは通常どの言語でもあり得ますし、一般的にそういう場合は一時変数で別名に預けるか、JavaScript の様に即時関数を作っ...

https://github.com/vim-jp/issues/issues/632

やって良かった、そう思います。

さて話を戻します。冒頭にも書きましたが、本書には「なぜ Ruby はこうなっているのか」が何度も登場します。特に僕が面白いなと思ったのは「Ruby のブロックの設計と、作者が意図していなかった使われ方」の話です。Matz の考えたブロックはイテレーションを実現する為の物でしたが、実際にはイベントハンドラであったり、コールバックであったり、select の様な条件記述であったり、スレッドや fork のインスタンスであったり、時には設定ファイルの DSL だったりもします。これらはユーザが考えた使い方です。作者が意図していなかった設計が違う方向で広がっていったという話はとても面白かったです。僕も libuv の mruby binding である mruby-uv でイベントハンドラやコールバックとして使わせて貰っています。

GitHub - mattn/mruby-uv: interface to libuv for mruby(experimental)

README.md mruby-uv interface to libuv for mruby(experimental) License MIT libuv Current mruby-uv use...

https://github.com/mattn/mruby-uv

もう1点、面白かった内容として上げたいのが「言語設計者のマーケティング論」です。どうやったら人気が出るのかを Ruby の作者である Matz が思いを喋っているのは、とても興味深い物でした。せっかく苦労して作った物なので、誰かの目に止まって欲しいですよね。

ところで本書には僕の名前が何度か登場します。Matz が Streem のリポジトリを公開し、まだコードも無いのに Hacker News で取り上げられ、話題性が落ち着いてきたそんな頃、僕はある pull-request を送りました。

WIP: tiny VM by mattn - Pull Request #101 - matz/streem - GitHub

You signed in with another tab or window. Reload to refresh your session. You signed out in another ...

https://github.com/matz/streem/pull/101

これまで BNF のシンタックスチェッカーでしか無かった Streem に処理系のコードを足しました。当時は Matz にもいろんなカンファレンスでスライドのネタとして扱って頂き見ていてとても楽しかったのを覚えています。ただし本書でも書かれていますが、僕がやったのは継続的なコントリビュートでは無いのです。OSS を運営する上で本当に必要なのは、継続的に手を動かしてくれるコントリビュータ達です。一人の手で出来上がったプロダクトには、作者の考えしか入り込まないので「本当に皆が欲しいと思っている機能」は出て来ない事があります。こういった OSS とコントリビュートに関する話が Ruby の生みの親の言葉として読める点も、本書の楽しみ方の一つだと思います。

この本があれば、「プログラミング言語が作れるかも」そんな気持ちになると思います。ぜひ自分の言語を作ってみて欲しいと思います。

そして迷って躓いて悩んで乗り越えた時に得られる満足感を、ぜひ体験してみて欲しいと思います。