2014/04/25


よし、卓球をしよう。
pingpong
ちょっとしたクラサバで何かを動かす時、クライアントが死んだらサーバも死んで欲しい時がある。自分で作ったプログラムならいいけれど、そうじゃないならいちいちサーバで CTRL-C タイプしなきゃならなかったりする。

「そこ自動でしょ!」

と思ったのでツールを作ってみました。
mattn/pingpong - GitHub
https://github.com/mattn/pingpong
2つのツールで構成されます。pping は引数で与えられたタスク名で ppong に一定周期で生存通知を行います。ppong は指定されたタスクが起動していなければ起動し、一定期間 ping が来なければそのプロセスを終了します。
pping は引数を取る事ができ、例えばサーバのあるタスクを起動させてからクライアントを起動したい場合には以下の様に実行します。

$ pping -n game-server game-client
こうすると ppong は game-server.json を読み
    "name""game-server",
    "args": ["-f""game.conf"],
    "timeout"30
予め指定されたコマンドと引数でサーバプロセスを起動します。ppong は30秒間 ping が来なければ強制的に pping を終了します。複数クライアントいる場合、1台でも起動していればサーバは起動し続けます。

本当は ffmpeg/ffserver でストリーミングをやっていて、ffmpeg が終了したら ffserver を落としたいという理由で作りましたが、色んな用途に使えるかもしれないので汎用ツールにしてみました。
何に使えるかは分かりませんが、よろしければどうぞ。

2014/04/16


FAQ に書いてあります。
Why does Go not have exceptions? - Frequently Asked Questions (FAQ) - The Go Programming Language

We believe that coupling exceptions to a control structure, as in the try-catch-finally idiom, results in convoluted code. It also tends to encourage programmers to label too many ordinary errors, such as failing to open a file, as exceptional.

Go takes a different approach. For plain error handling, Go's multi-value returns make it easy to report an error without overloading the return value. A canonical error type, coupled with Go's other features, makes error handling pleasant but quite different from that in other languages.

Go also has a couple of built-in functions to signal and recover from truly exceptional conditions. The recovery mechanism is executed only as part of a function's state being torn down after an error, which is sufficient to handle catastrophe but requires no extra control structures and, when used well, can result in clean error-handling code.

http://golang.org/doc/faq#exceptions
try-catch-finally イディオムはコードを複雑にするし、たかがファイルのオープンに失敗しただけのエラーに過剰なラベル付を強要する。 golang では複数の値を返す事が出来るので、一般的には戻り値の最後にエラーを付けて返す。

と書いてあります。
何度読んでも「例外が使いこなせません」とは読めません。すいません。複雑になるのは良くないという話はそもそもレイヤの違う話だと思いますよ。まぁ FUD なツィートで人気のある方なので、ディスカッションするつもりもないですが。
バグが発生する多くの問題は、エラーハンドリングが正しくされていない事が原因だったりします。golang の場合は戻り値が複数あった場合、戻り値を得るには必ず全ての戻り値を変数にバインドしないといけない仕様になっています。つまりは戻り値が欲しければ、error も取れという事になりますね。
package main

import (
    "fmt"
)

func doSomething(input int) (result string, err error) {
    switch {
    case input < 0:
        return "", fmt.Errorf("%d is negative value", input)
    case input < 50:
        return "less than 50"nil
    default:
        return "greater than 50"nil
    }
}

func main() {
    if r, err := doSomething(20); err != nil {
        fmt.Println(err)
    } else {
        fmt.Println(r)
    }
}
golang では if の else ブロック内でも if 句内で宣言した変数が参照出来ます。Java の try-catch-finally だと try 内で宣言した変数は catch ブロックでは参照出来ません。それを回避する為に try よりも上部に持っていって... などというのは良くある話ですし、ネストだらけの try-catch-finally も良く見ますね。
golang でも細かいエラーハンドリングは出来ます。この辺はドキュメントを読むと書いてあります。例えば os.Open ならば
func Open - The Go Programming Language

Open opens the named file for reading. If successful, methods on the returned file can be used for reading; the associated file descriptor has mode O_RDONLY. If there is an error, it will be of type *PathError.

http://golang.org/pkg/os/#Open
エラーがあった場合には PathError が返ります。
package main

import (
    "log"
    "os"
    "syscall"
)

func main() {
    f, err := os.Open("not-found-file.txt")
    if err != nil {
        pathErr := err.(*os.PathError)
        errno := pathErr.Err.(syscall.Errno)
        if errno == syscall.ENOENT {
            log.Fatalf("ファイルが見つからなかったんだと思います: %v", pathErr)
        }
        log.Fatalf("良く分からないエラーが発生しました: %v", pathErr)
    }
    f.Close()
}
ラベル付けしないからこそ、エラーは詳細に取れる様に設計されています。別のドキュメントにエラーハンドリングについて詳細に書かれています。
Error handling and Go - The Go Blog

If you have written any Go code you have probably encountered the built-in error type...

http://blog.golang.org/error-handling-and-go

2014/03/24


良く分からないけどニーズがある様なので書いた。
1~2時間程度で書けると思ったのに予想以上に ruby 戦闘能力が無くて泣いた。
mattn/mruby-pjson - GitHub
https://github.com/mattn/mruby-pjson
今の所 parse しかないので dump も付けたい。
あとまだまだ色んな所で甘いので直さないといけない。