type Foo interface { ... }
type Bar struct {...} // implements Foo
type Quux struct {
    A int
    B string
    C Foo
}

続きを読む

ちょうど本業のほうでDBへのアクセスが遅い？んだかなんだかでREST APIがタイムアウトしている事象に出会っていたのでよっしゃとgo-sql-proxyを使おうと思ったのだけど、まずこのままだと実行時間とかが計測できない… ということに気づいて色々考えた結果PRを送る事にした。送ったら光速でマージされた。

今度から NewTraceProxyでプロキシを作れば Open/Exec/Queryに関しては所要時間が出力されるようになります。mysqlなら以下のような感じ：

driverName := "mysql"
if traceEnabled {
    driverName = "mysql-trace"
    sql.Register(driverName, proxy.NewTraceProxy(&mysql.MySQLDriver{}, logger))
}
db, err := sql.Open(driverName, dsn)
...

出力はこんな感じ：

tracer_test.go:27: Open (54.116µs)
tracer_test.go:27: Exec: CREATE TABLE t1 (id INTEGER PRIMARY KEY); args = [] (44.535µs)
tracer_test.go:41: Query: SELECT id FROM t1 WHERE id = ?; args = [1] (1.828µs)

わーい、これでボトルネック探すの捗るぞー！… と思っていたら、元々のNewTraceProxyのシグネチャが

func NewTraceProxy(d driver.Driver, o Outputter) *Proxy

で、これだと自前のloggerを受け付けてくれない！

type MyLogger struct { *log.Logger }

とかでも駄目だ！ということでインターフェースを定義してOutputメソッドを実装してればなんでもいいようにしておいたPRを送って取り込んでもらった。これで使えるようになった。YATTA!（けど、デプロイはこれからなのでまだなにか後で追加するかも…）

どちらのPRも光速でマージしてもらって大分たすかった。ありがとうございます。

タグ ：

#golang

#mysql

#db

godepというツールをpecoやmigemogrepに便利に使わせてもらってたんだけど、このたびカスタムなgoスクリプト（goだとスクリプトじゃないと言われそうだけど、スクリプトとしか言い様が無い）を書いてgodepを卒業しました。

 なんでこうしたかというとgodepの-copy=falseというオプションが使えなくなり、基本的に依存関係のライブラリもこちらのレポジトリに入れないといけない形になったから。いや、入れても良いけどさ… う〜ん。毎日ビルドして出荷してるわけじゃないし、それなのにレポジトリをcloneした時に依存関係も全部落とすのはなああああ、ということで、もう全部自前で書きました。

別にシェルスクリプトでもよかったんだけど、goのプロジェクトだし…ってことで全部goで書いて、wercker.ymlからこんな感じで呼び出すようにした。

それだけ。あとで「なんであんなことしてるの？」って聞かれた時用に書いておく。

タグ ：

#golang

先週 @k0kubunさんがpecoで複数キーの入力シーケンスに対してアクションを起こす（例：C-x, C-cで終了する、みたいなの）PRをしてくれたのでそれをマージした。pecoには楽しいお兄さんが色々コントリビュートしてくれているので、そのPRを見た瞬間にこんなコメントが

mattn@mattn_jp

こりゃあ、コナミコマンド作るしかねぇべ / “Accept key sequence by k0kubun Pull Request #124 peco/peco GitHub” http://t.co/YwjJo9Ao1A

2014/07/03 01:06:44

おお、いいですね、ということで実装してみようとしたところ… うっ… 設定ファイルから読み込んで動的に作る無名関数からレキシカルな変数へのスイッチングしてて、これをプログラム内部から他に作る方法がねぇ！w 設定ファイルからはできるのに！w むきー！

ということでその後、基本的な設計構造を変えないでその辺りを奇麗にできる方法は ないかと一日くらい費やした。が、やはりうまくいかない。薄々気づいていたけどこれFSMとかの出番だよな… 一から実装面倒くせぇなーと、つぶやいたらすぐ返信が：

MURAOKA Taro@kaoriya

@lestrrat トライ木 & aho-corasick 使うと綺麗に決まると思いますよ。これは文字列マッチ用ですが参考にはなるかもしれません。 https://t.co/C4HadJAWx3

2014/07/04 20:16:59

うほ！goでahocorasickの実装があるwwww ありがとうございます！全部ぱくります！

コードを眺めているとトップレベルではstringに対しての実装で、 中身はruneに対してノードを返すみたいな事になってるので、これまぁ用はstring = []rune として考えられるので、キーシーケンス= []キー で代用できるね、って分かったのでガツガツ変更。といっても検索キーとか、ちょっと再起的に使うためにinterfaceを足した程度で、基本は何も変えていない。

そんなこんなで最初にpecoを書き始めてから一番大きいPRをマージして、キー入力周りがそれまでのコードと一変した。コードを提示してもらったおかげで任意の長さのキーシーケンスを特定のコマンドを高速かつ分かりやすい形で検索＋ディスパッチできるようになった。

これも含めて先ほどpeco v0.2.0としてリリースした。このリリースはかなりの数の変更が入っているので、pecoヘビーユーザーには嬉しい機能が結構あると思う。是非お試し有れ！

本日の教訓：この一つ前の記事もパクリの話だったけど、こういう汎用的な方法論についての助言はどんどん受け入れるべきだし、コードもがんがん再利用してやればいいと思う。

プログラムを書く作業は孤独だけど、わからない事は「分からない！どこから始めるか教えて！」って聞けば誰でもヒントをくれるので人に頼る事を恐れないほうが良い（ただし、そこから先は自己責任でちゃんと勉強しましょうね）。そういえばgo-xslate書いた時もgfxに「これ、どこのサイト読むとxslateで使ってるVMのモデルの概要わかるの？」って聞いたな。

年を取れば取るほど経験値はたまっていくけど、それと同時に自分の知らない事が世界にはまだまだあるのがわかる。もちろんそれらを全部吸収できればベストなんだけど、脳にも限界があるので他人に聞く事によって自分の知らない事を素早く正しく補完できるのであればそれを活用できるようにつながりを作ったり、素直に質問できるようにしていくのが老いてゆくエンジニアの進む正しい道な気がする。おすすめです。

タグ ：

#golang

#peco

pecoでは何個か前のリリースからバイナリビルドをリリースの成果物として登録するようにしている。これのおかげでpecoはそもそもの存在理由である「2014年だしこういうツールはバイナリ一個置いておくだけで動いてほしい！」というをより簡単に実現できている。


で、その実装方法。基本motemenさんのスクリプトにmattnさんがツッコミを入れたりしてるのを見ながら「よし！パクろう！」と思ってパクったんだけど、一つだけpecoでは意図的に変えたところがあって、それはboxの選定のところ。

motemenさんのgolang-goxc box自体に基本何も問題がないのだけど、pecoで色々やっているうちにgo1.3がリリースされたのにこのボックスを使っているといつまでもgo1.2.1だった（今はもう違うかもしれない）。まぁ当たり前ですよね。そこは他人の褌で相撲を取ろうとしている俺が文句言うところではない。

ただやっぱりバイナリのサイズが小さくなったり、多少パフォーマンス改善も見られている1.3系を使いたいと思いが募ったのと「これから先もきっとこういう事があるだろうし、そういうことがあるごとに文句を言わないといけないのか？」という思いがあり、pecoにはpeco専用のビルドボックスを作る事にした。それがこちら。もちろんgo1.3とgoxcを入れているところ以外はたいした事してない。

たいしたことはしてないんだけど、よくよく考えればライブラリとかではなくpecoのようにエンドユーザーに直接届くプログラムに関してはあまり自分が制御できていない環境に依存するのもどうかなーと思ったのでもうボックスから作る事にしてしまった。これなら自分がやりたいタイミングでgo1.4が出たらgo1.4にすることもできるし、goxcの特定のバージョンが欲しい、とかにも対応できる。

あとはmotemenさんの元記事と一緒。タグ打ってgit pushすれば勝手にファイルがあがってくる。おっさんは何もする必要がありません。大変すばらしい。また時間のある時にはhomebrewのレシピも自動的に作成しようとは思ってるけどそこまで至っていない。ともあれ、自動化はすばらしい。





ちなみに、drone.ioも一応登録はしてあって、こっちでもリリースとかできるかやってみたんだけど失敗して、ただただコンパイルして成果物を残しているだけ（基本前のやつは上書き）。あんまり必要じゃないけど、別の環境でコンパイルするとたまにバグが見つかったりもするので悪くはないと思ってる。まぁそのうち消すかも。

タグ ：

#golang

#peco

tl;dr;

• githubで長い事使われてないアカウントはリリースしてもらえることがある
• pecoのURLが変わりました
• pecoの有効な使い方があったら、ぜひWikiでシェアしてください

続きを読む

タグ ：

#golang

#peco

これは笑ってしまった。The Open Source Report Cardという、githubのデータを持ってきて色々統計情報を見せてくれるサイトがあるんだけど、ここで今日とうとう「Exceptional Regexer」とか、そういうPerl Monger系の名称から「High Caliber Gopher」みたいな名称になって、さらによくみると「one of the 5% most active Go users」（6/18現在）だったのでツイートしたら、

Daisuke Maki@lestrrat

Hey, I'm apparently &vquot;one of the 5% most active Go users&vquot; according to http://t.co/vZVvOSKNaZ lol #golang

2014/06/18 18:47:37

GoプロジェクトにとてもゆかりのあるDave Cheneyさんからこんなツイートが…

Dave Cheney ♆@davecheney

@lestrrat what, how can you be beating me?!? I'm going to have to step up my game.

2014/06/18 20:37:36

よくみると彼は上位9%という位置だったｗ まぁGithubに対するコミット数とかだからそれ以外のところはカウントされないのでしょうがないｗ 彼がgithubにもっとコミットするようになったら一瞬で抜かされるだろうなー こういうのを"15 minutes of fame"とかいいますねｗ

タグ ：

#golang

（pecoそのものについてはここで読むよりREADMEを見た方が早いです）

今月の初めくらいにpercolという便利なものがあるという話を聞き、「ほう、使おうかな」と思ったら普段あまり使い慣れていないpython製ツールでまるでcpanmを使うのがいやなPerlに慣れていない人のような反応で「まぁ必須アイテムじゃないし…」と思って諦めかけたところ

lestratt さんはやく！

— mattn (@mattn_jp) June 6, 2014

とか言われ「そこまでいいツールなのかなー」と思ったけど、使ったことないし、まずはツールがどういうものなのかをわかるためにGoで実装する事にした（はい、本当にこういう順番です）。
続きを読む

タグ ：

#golang

（以下はgo 1.2.x時点での話です。将来的に仕様がかわるかどうかはわかりません）

これを読んでいて、こういうの気にしてない人多いんだろうなーと思って、書いてみます。元のポストはdeferの挙動について語っているように見受けられるけれども、これは要は複数スレッドで実行されるコードについて、プログラム終了時に同期とか取りたくない、という話だと思ったので、このポストのdeferを正しく動かすには…というところからどういう形でgoroutine同士で同期を取る方法があるのか、一例を書き出していきます。

TL;DR;

goでいくらgoroutineが気軽にかけるからと言って、複数スレッドで処理が行われているので同期はキチンとやらないとダメですよ。

続きを読む

タグ ：

#golang

なんかごく一部に補足されているので、念のため軽く説明しておきます。

masahiro nagano@kazeburo

某所のlestrratさんのgolangなアプリはhot-deployが可能になってる。サーバはserver_starter経由で起動されていて、バイナリ消してHUPを送ると自動でビルドしなおしてプロセスを入れ替えてくれる。便利

2014/04/30 12:18:31

これ、ベストな方法だとは思っていないんだけど、最初にこれを書いた当時の考え方は以下の通り：

1. これは自分の部署で初めて 本番に設置するgoアプリである
2. 一次対応をする人は自分とは限らない
3. 細かいコード内容の修正はともかく、明らかなバグっぽいものの修正（例：SQL文の変更）などを自分以外の人間が施した後にサーバーを簡単に再コンパイル＋再起動するする方法がないと椅子が降ってくる事が容易に予想される

続きを読む

タグ ：

#golang

tl;dr: 別にPerl捨ててないです。Perl大好き。俺はLLはPerlでいい。でも別ドメインの事もやってもいいよね！

Rebuild.fmに限らず、公の場でYAPC/Perl以外の話をする事があるとは正直思っていなかったが、このたびRebuild.fm ep 42に置いて１時間Goについてしゃべりまくってきた。1時間ぶっつけ本番でしゃべりたい事はだいたいしゃべってきたのだけど、その後のフィードバック等もふまえてまとめておきたいと思ったのでこのエントリでまとめてみます

続きを読む

タグ ：

#golang

このところ情熱を燃やしていた go-xslate プロジェクトですが、大分使えるようになってきたし、かなりの処理速度も出るようになったし、go-nutsで宣伝もしたし、小さいプロジェクトで使い始めたし・・・ってことで 手軽に遊べる用に Go PlaygroundをぱくってGo-Xslate Playgroundってのを書いた。

外部テンプレートを使うWRAPPERやINCLUDEは使えないけど、それ以外の機能は一通り使えるはず。是非遊んでみて、問題がありそうだったら "Share"ボタンを押してpermalinkを作成の上、permalinkをissueにはりつけて教えてください。よろしくお願いいたします。

ちなみに書いたそばから mattnさんにぱくられたけど、自分もぱくってるし、ぱくられたのは良い物を書いたからなのでつまり全体的に大変よい。なおGo-Xslate Playground自体のソースはこちらにあります。なにか問題等ありましたら教えてくださいませ。

タグ ：

#golang

golangでNgram処理をするためにgo-ngramを書きました。ngramによる類似文字列検索に関してはコードを読みながら逆算してこういうことか、という書き方をしたのでちょっと実装に自信はないのですが、まぁだいたい動くな、というところまでは確認しました。問題がありそうでしたら是非ご連絡ください。

使い方は以下の通り。まずただngramでトークナイズするならngram.NewTokenize()を使います。以下はいわゆるTrigramを使った例：

import (
    "fmt"
    "github.com/lestrrat/go-ngram"
)

func main() {
    tok := ngram.NewTokenize(3, "ハローハローハロー")
    for _, token := range tok.Tokens() {
        fmt.Printf("token = %s\n", token)
    }
} 

ちゃんと日本語も対応してます。

ユニークなトークンだけがほしい場合はTokenSet()を使ってください。

import (
    "fmt"
    "github.com/lestrrat/go-ngram"
)

func main () {
    tok := ngram.NewTokenize(3, "ハローハローハロー")
    set := tok.TokenSet() // see http://github.com/dackarep/golang-set
    for x := range set.Iter() {
        fmt.Printf("token = %s\n", x)
    }
}

一応簡単なインメモリインデックスも作りました

import (
    "fmt"
    "github.com/lestrrat/go-ngram"
)

func main() {
    index := ngram.NewIndex(3)
    index.AddString(`....`) // 検索対象の文字列を登録しておく
    ....
    matches := index.FindSimilarStrings(`ハロー`) // AddString()された物の中から`ハロー`に似ている文字列を持ってくる
    for _, str := range matches {
        fmt.Printf("matched %s\n", str)
    }
}

これで登録されている文字列の中から似た単語を抽出できます。 デフォルト設定だと一個でもngramがマッチするとあたってしまいますが、SetMinScore()で閾値を設定することによって検索結果を絞り込めます。

さらに、一番良いマッチだけを持ってくる場合にはFindBestMatch()を使ってください。

あと自分で検索結果をフィルターする場合はIterateSimilar()を見てください。

ツッコミ、コメントお待ちしております。

タグ ：

#golang

GrowthForecast のgolang用クライアントライブラリgo-growthforecast-clientを書きました。以上！

タグ ：

#golang

goで書いたwebappでもApache形式のログを出したい！ということでgo-apache-logformatを書きました。

最初はこのツールを使って毎回ServeHTTP()関数の中でログを出力する関数を呼び出すようにしようと思ったんだけど簡単なラッパーを用意したので多分かなり簡単にApacheログを出力できるようになるはず

まず最初にやらないといけないのがApacheLog構造体を作るところ。出力先のio.Writerと出力フォーマットを指定して作成するんだけど、いわゆるcombined logフォーマットだったらもうすでに作ってあるので、それをClone()しちゃえば簡単：

import (
     "github.com/lestrrat/go-apache-logformat"
)

....
logger := apachelog.CombinedLog.Clone()
logger.SetOutput(...)  // io.Writer. os.FileとかでもOK. デフォルトはos.Stderr

で、あとはそれをhttp.HandlerFuncで使用されるようにすればいい。もしServeHTTP()関数を実装した構造体があればそれをラップするだけでもOK:

http.ListenAndServe(":8080", apachelog.WrapLoggingWriter(handler.ServeHTTP, logger)

もし色々自分でやりたいなら、ServeHTTP関数の中で自分で以下のようにフックしてもいい：

func ServeHTTP(w http.ResponseWriter, r *http.Request) {
    ...
    lw := apachelog.NewLoggingWriter(w, r, logger)
    defer lw.EmitLog()
    ...
}

ここでひとつ気をつけないといけないのが、上記のServeHTTPの中ではw ではなく lw (LoggingWriter)のほうを使う事。そうしないと諸々必要な値が取れない。

最後にもしこれをログファイルにはき出しつつローテーションも行いたいならgo-file-rotatelogsを最初のloggerにかませばそれでおしまい：

import (
     "github.com/lestrrat/go-file-rotatelogs"
     "github.com/lestrrat/go-apache-logformat"
)

...
logfile := rotatelogs.NewRotateLogs("/path/to/accesslog.%Y%m%d")
logfile.LinkName = "/path/to/accesslog"
logger := apachelog.CombinedLog.Clone()
logger.SetOutput(logfile)

というわけで是非お試しください。ツッコミ、PR、お待ちしております

タグ ：

#golang

Yet another Yak-shaving... 

というわけで、Perl5のFile::RotateLogsをgoにさくっとポートしました。使い方はREADMEのままです！

これでちょちょっと書けばgoアプリでも勝手にログファイルがローテートされるようになります！

本日のYak Shavingでgo-test-mysqldを書いた。

import (
    "database/sql"
    "log"
    "mysqltest"
)

mysqld, err := mysqltest.NewMysqld(nil)
if err != nil {
   log.Fatalf("Failed to start mysqld: %s", err)
}
defer mysqld.Stop()

db, err := sql.Open("mysql", mysqld.Datasource("test", "", "", 0))
// Now use db, which is connected to a mysql db

go-stf-serverのテストを書き始めるにあたってmysqldをどうしても立ち上げないといけないんだけど、これがまた自動的にやるのは面倒くさくて面倒くさくて・・・

というわけでTest::mysqldからまるまるまるっとぱくってgolangにポートしました。これでmysqldを立ち上げるのも簡単だね！

それほど障壁は高くないと思いますので、是非気軽にお使いください。問題があった場合はissueをお気軽にどうぞ！ 

タグ ：

#golang

Perl版のSTFは自分が参加し始める前から、ひとつのスクリプトから複数の種類のワーカープロセスを立ち上げるように作られていたのでそれを踏襲し続けている。ひとつにはワーカーの種類が複数あるのでそれらをひとつひとつ立ち上げるのは結構面倒くさいのと、Perl版のバージョン2.00からはメインプロセスがシステム全体のワーカー数を関しつつ自分がどのワーカーを何個ずつ立ち上げるべきなのかを自律的に計算するようにしたのでこれはこれでよい。

さて、それでgo版だが、goでは言語設計的にfork()は使えないようになっている。なので通常はgoroutineをガツガツ立ち上げる事になるわけだが、この間やったgo版dispatcherのベンチマークなどから見ても、goroutineベースだとシステムリソースをよりガツガツ最後の1%まで使ってやろう感が見えるので、本能的に「これをSTFワーカーでやると問題が起こった時にやばい」と感じた。

正直ここは勘なので これが正解かどうかわかってない。間違ってるかもしれないけど全部goroutineでやるより、fork + exec とgoroutineの組み合わせで実装するほうがよいような気がしたので、それでやってみた。

スーパーデーモンにあたるものが"drone"と呼ばれる。こいつは必要なワーカー種類の分のコマンドをexec.Command経由で立ち上げる。しかしこの子プロセスがなんらかの理由で停止したら、即座に新しいプロセスを立ち上げ直す必要がある。ところがgolangにはノンブロッキングwaitpid()に相当するようなものはない。いや、厳密にはあるんだけど、syscall.Wait4()というポータブルではないところにあるのであった。

まぁそもそもfork+waitというのがUNIXなイディオムだからそりゃそうだ。ということでポータブルにするにはどうするか。ここはなんとなく無駄にも思えるのだけど、goroutineで豪勢にブロックするとよい：

func SpawnWorker(exitChan chan string, executable string) {
    fullpath, err := exec.LookPath(executable)
    ...
    cmd := exec.Command(fullpath, ...)
    err := cmd.Start()
    ...
    go func() {
       cmd.Wait()
       exitChan <- executable
    }()
}

exitChanは別のところでselect{}経由でノンブロッキングで監視しておいて、もらった実行ファイル名で再度子プロセスをスタートさせる関数にフックしておく

func MainLoop() {
    for {
        select {
        case executable := <-exitChan:
            SpawnWorker(exitChan, executable)
        ...
        }
    }
}

これで永久機関のできあがりだ！あとはSTDOUT/STDERRをコピーしつつシグナルを受け取ったら良い感じにループを抜けたり、後にゾンビを残さないためにプロセスを止めたりすれば停止もキレイになる。

で、この子プロセスの中では特定のワーカー種別について必要な分だけのgoroutineをばかばか作って、必要な処理をする。方式はだいたいdroneと一緒でこちらではQ4Mにアタッチするgoroutineと、さらにそこからchannel経由でジョブをもらって実際の処理を行う複数のgoroutineを作成する。これがようやくいわゆるワーカーの部分。ここもそうする意味があるのかちゃんとわかってないけど、勘でそうするべきだと思ってmax-reqs-per-workerを設定して、定期的にgoroutineが終了するようにしてる。


このマルチプロセス＋マルチスレッド方式のほうがいいな、と思った理由はこれだと例えば特定のワーカーのgoroutineが詰まったりした時にそのプロセスだけ殺して再起動できるから。goroutineってthread idに対応するものが外部に出てないからkillしたくても簡単にできねぇんだよね！

で、ここまでできたので、次は残りのワーカー機能の作成と、自律的にワーカー数の調整を行う部分。自律調整の部分は上記のdrone部分でtime.Tickを使って定期的に行う予定。
 

と、ここまで書いたけど、この実装って本当に正しいのかわからんので相変わらずツッコミをお待ちしております。