各位お疲れ様です．
さて表題の通り，YAPC::Asia Hachioji 2016 の2日目16時から，
「突如見知らぬ言語に出会ってしまった俺達は」というタイトルで発表します．
どんな話をするかというと，まあプロポーザルに書いてあるとおりなんですが，新しい言語とかを学ぶ為にどうすれば良いのか，そして実際にどうやっているのか，みたいな話をする予定です．プログラミング初学者の人をターゲットとしています．
今回本当に魂を売ってエモい話にしようと頑張っていたんですが，蓋を開けてみればいつもの様に漫談になってしまった……なので漫談に興味のある人もターゲットとなっています．エモ漫談みたいな新境地を開拓していきたい．
皆さん2日目の会場でお会いしましょう．1日目は友人の結婚式で喋るのでいません．
sprint という Java 向けの String formatter を書いた．
Maven Central にも置いてある．
http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22net.moznion%22%20AND%20a%3A%22sprint%22
sprint は Sprint#ff() というメソッドを提供している．使い方としては以下の様な感じ．
final Sprint sprint = new Sprint(); System.out.Println(sprint.ff("Hello: {}!", "John")); // => Hello: John!
処理としては，template を parse して placeholder とそれ以外とを検出して，その検出した placeholder に変数を埋めつつ文字列を生成している．
そしてコードを読むと分かる通り，sprint は実際には StringBuilder の wrapper のようになっていて，適宜 StringBuilder#append() を呼びながら文字列を組み立てている．
工夫などとしては以下の通り．
sprint では簡単な template を利用する．例えば "{}: {}" という感じ．この template 中の {} は placeholder であり，sprint はこの placeholder に対して与えられたパラメータを埋めていく．メソッドの受け取る第一引数はこの template であり，以降の引数は placeholder に埋めるためのパラメータとして扱われる．この時，このパラメータは StringBuilder#append() に渡されるので，結果的に String.valueOf() を適用した結果が文字列中に埋められる．
これは Logback の文字列 template もこんな感じだったと思う．楽で良い．
文字列を format する度に template を parse していては効率的ではない．template に対する parse の結果は一意のはずで，記憶しておいて以降の処理で使いまわしたとしても矛盾は起きないはず．なので sprint では template の parse 結果を template 文字列と紐付けてインスタンス内に保持し，同じ template を使った二回目以降の format の際にはその保持しておいた結果を用いる．つまり，sprint では template の parse は一度だけ実行されるということになる．
なお，sprint ではこの parse した結果の構造を走査することで文字列を生成している．
こうした処理の削減によりパフォーマンスが向上している．ベンチマークの結果としては以下の様な感じ(jdk1.8.0_92 で実行．コードはここ)．
code review の reviewer 選出をする時，pull request の内容をざっと眺めてから「この部分だから XX さんかな」とか「あそこのコードは YY さんが詳しいだろう」とか，そういう感じで選ぶことが多くて，つまりは勘と経験で選びがちになってしまう．これについては常々いくばくかの危うさを感じていた．
そもそも，「reviewer として誰が最適か」という知識はプロジェクトに長く関わっている人でなければ知りにくいものであり，いわば属人的な知識のひとつだと思っている．プロジェクトからそういった長老的な人がいなくなってしまったら，最適な code review を実施できなくなってしまう可能性がある．
従って，やはり技術で解決ということになる．
Facebook が作っている mention-bot という GitHub の bot として動作するやつがあって，これは pull request が送られてくるとその pull request について blame を実行して code reviewer の候補を出してくれるという気の利いた処理を自動で行ってくれる．
mention-bot は便利で，我々も使っているのだけれど若干の不満もある (おおよそ良いのだけれど……)
後者は身も蓋もない話だけれど，前者については若干問題があるなーと思っていた．
任意の時点での reviewer 選出をもっと気軽にできれば良いのに，と．
というわけで，git-reviewer というスクリプトを書いた．手元で git のサブコマンドを実行することで reviewer 候補の選出が出来る．
使い方は至って簡単で，
$ git reviewer <into branch> <from branch>
としてやると，その brnach 間の diff について最適と思われる reviewer を選出してくれる (into branch を省略すると，current branch が into branch として扱われる)．
仕組みとしては極めてシンプルで，
1. branch 間の diff を取る
2. diff が出た各ファイルについて，削除された行をかき集める (すなわち，diff の先頭に - が付いている行)
3. 削除された行 (つまり変更を入れられた行) のもともとの author を git blame により特定する
4. その author をかき集める
という処理を行い，頻出する author が reviewer 候補として選出される．
もしも diff に削除行が1つもない場合は，変更があったファイルの全行についてその author を集計し，その数が多い人を reviewer 候補として扱うようにしている．
このコマンドを手元で実行することで，手軽に reviewer 候補を知ることが出来て便利になった．めでたしめでたし．
何か「こうした方が良いのではないか」「おかしいのではないか」などがあったら教えて下さい．
[追記]
実行してみればお分かり頂けると思うのだけれど，git-reviewer の出力はとてもシンプルなものになっている．以下のような感じ．
moznion: 123 nozniom: 42 foobar: 2
これらは影響行数の降順として出力されるので，上に表示されればされるほど reviewer 力が高いという事になる．
もしも除外したい committer がいるならば，パイプで grep -v とかで除外すれば良いのかな〜とか思っていたのだけれど，確かに reviewer 側のオプションで食わせられるようにしても良いかもしれない．これが UNIX 哲学だ！！ と頭ごなしに殴りつけても良いことはないのです．参考になりました．
以下はコミュニケーションの様子
コードレビュアーの選定は多くの場合経験と勘によって行われていて、これは言語化されていない知識によるものなので、レビュアーの選定というのは皆さんの嫌う属人的な作業になっている場合が多い。当たり前のように行っているあまり、それに気付かないことも多いのだけど
— 病弱 (@moznion) 2016年5月25日
一方でコードレビューによる属人性の排除という視点もあり，そういったばあいはおみくじが有効ということになっていたはず
— 浸食_〜lose_control〜 (@side_tana) 2016年5月25日
コードレビューで属人性が排除できるの夢では，といった指摘については別のところでやったほうがよさそう
— 浸食_〜lose_control〜 (@side_tana) 2016年5月25日
とはいえ、いきなりなにも分からない人にレビュアー依頼が飛んでもお互い不幸なので、現実的な落とし所としてこれかな〜って感じ！！
— 病弱 (@moznion) 2016年5月25日
実装俺、レビュアー俺なのでどうにも。
— Atom（アトム） (@FromAtom) 2016年5月25日
@FromAtom 選手兼監督っぽい
— 病弱 (@moznion) 2016年5月25日
@moznion ヤクルト古田の苦労が忍ばれる。
— Atom（アトム） (@FromAtom) 2016年5月25日
@FromAtom ガッハッハ (ガッハッハではない
— 病弱 (@moznion) 2016年5月25日
まず以下の様なシェルスクリプトを用意する．
#!/bin/bash # ここで依存しているパッケージを go get する # 例えば以下の様な感じ # go get -v gopkg.in/yaml.v2 # go get -v gopkg.in/redis.v3 for GOOS in darwin linux; do for GOARCH in 386 amd64; do export GOOS export GOARCH go build -v -o bin/tool-$GOOS-$GOARCH main.go done done
darwin と linux について，それぞれ i386 と amd64 アーキテクチャ向けのバイナリを作るようなスクリプト．main.go はビルド対象のファイル．成果物はカレントディレクトリの bin 以下に生成されるので，あらかじめ mkdir しておく必要がある (後述)．
なお，GOOS と GOARCH を export しておかないとうまく動かない．ドキュメントではこれが省略されていて少しハマった．
そんでもってこのスクリプトを呼び出す．以下は Makefile の例．
build: docker run --rm -v "$(PWD)":/go/src/github.com/moznion/tool -w /go/src/github.com/moznion/tool golang:1.6 bash build.sh
ここでは docker hub で公開されている golang のイメージを利用している．
https://hub.docker.com/_/golang/
-v オプションを使ってカレントディレクトリに docker image 内の go path が通っている然るべきディレクトリをマウントする．
でもって，-w オプションでマウントしたディレクトリをワーキングディレクトリに設定し，上記のシェルスクリプトを image 内で実行する．
と，ワーキングディレクトリ以下の bin に成果物が吐き出され，ワーキングディレクトリはカレントディレクトリにマウントされているので，つまり成果物はカレントディレクトリ以下の bin に出力されてハッピーという寸法！
なお，--rm オプションを付けておかないと実行する度にゴミ container がどんどん溜まっていくのでつけたほうが良い．
実際のコードはここに書いてある感じのやつ
cgo 使わない，なおかつ go 1.5 以上であれば make だけで完結するとのこと！
Docker 使って golang で書いたツールの cross platform build をする - その手の平は尻もつかめるさb.hatena.ne.jp別にdockerもシェルスクリプトもいらなくて makeだけで完結しそうな予感／アンサーソングしといた http://lestrrat.ldblog.jp/archives/48673706.html
2016/05/24 06:27
なお，gox 及び goxc については go 1.4 以下の便利ツールという立ち位置とのこと．
最近 Prometheus を使って各種メトリクスを取っていて，ふと resque の queue のステータス，つまり各 queue に 積まれている job の数を集計・可視化したくなったので，そのための exporter を書きました *1．
実装としては，resque は <namespace>:queues という SET に全ての queue の名前を持っているので，SMEMBER を使って全 queue 名を取得してきて，
更にその各 queue 名に対応する <namespace>:queue:<queue_name> という LIST が queue そのものを表しているので，その LIST の長さを LLEN により取得することで各 queue の job 数を集計するという仕組みになっています (ここらへんがその実装)．
なお，この exporter は resque 互換の job queue であれば問題なく動作するようになっていると思います (実際に我々は resque の java 実装である jesque でこれを使っています)．
ところで golang で Prometheus の exporter を書くのは至って簡単で，
prometheus.MustRegister(exporter) と言う感じで Collector interface の実装を登録するhttp.Handle("/metrics", prometheus.Handler()) という感じで http 経由で export する口を作って serveという感じでめいめい exporter を提供することが出来ます．シンプル！
なお補足ですが，色々な exporter の実装を見ていると scrapeFailures という counter を用意してあげて，そこに metrics 取得に失敗した回数を突っ込んでやるのがマナーっぽい感じでしたので，当 exporter でもそのようにしております．
*1:今までは fluentd + kibana という構成で似たようなことをやっていた
p5-Redis-Script の Java 移植になります．
Redis を使ってて困った時にインターネットを徘徊してると @shogo82148 さんのブログにたどり着く事が多く，日頃お世話になってるわけですが，今回は Redisのトランザクション・スクリプト・ランキングを扱うPerlモジュールを公開しました - Shogo's Blog からの知見です．
上記の記事中には
EVALコマンドのドキュメントによると、 「EVALSHAで実行してみて NOSCRIPT No matching script で失敗したらEVALでやり直す」というのがおすすめらしいです。 EVALコマンドはSHA1ハッシュの登録も行ってくれるので、初回 NOSCRIPT になっても次回からはEVALSHAが成功します。
そんなに複雑なことではないのですが、毎回書くのも大変なのでモジュールとして切り出したのが Redis::Script です。 以下のようにスクリプトオブジェクトを作っておいて、パラメータを渡して実行します。
とあり，まさにこの度そういった utility 的なものを毎度毎度書くのもだるくなったので，ここは一丁 library 化しようということで今回 Java に移植した次第．
Java でやるなら，特定の script について SCRIPT LOAD を一度だけ行なうような singleton class を用意してごにょごにょやるという方法も考えましたが，基本的な実装は p5-Redis-Script を踏襲しています *1．
redis-script-manager としては Jedis と lettuce の2つの Redis Client に対応しています．
ひとまずこれだけ対応しておけば自分で使う分は大丈夫だろう，という判断からこの2つに対応しました．
もしも他の Redis Client のサポートが必要になったら，redis-script-manager-core の抽象クラスである ScriptManager を継承して実装すれば同様の挙動を実現できるので，その時が来たら考えるぞ！ という感じです．
ところでこういう細かい library を書いて使っていくのはあまり Java の文化っぽくない感じがあり，その背景には依存する jar が増えれば増える程地獄と化してきて厳しい，などといった状況があることと思います．確かにそうだ．
しかしだからといってコードをいちいちコピペして使い回すとかはあまりしたくないし，やっぱりかゆい所に手が届くパーツがあれば便利やん？ みたいな感覚があるので，とりあえず外に出して使ってみるのが良いのではないかと思っているところです．
*1:むしろ ScriptManager ごと singleton にするという戦略はありかもしれない
割とニッチな話題ではありますが……
Server::Starter を使ってプロセスを立ち上げると graceful restart を簡単に実現できるなど便利な点が多く，LL 時代はこれでやっていっていたわけですが，残念なことに Java からその Server::Starter テクノロジを利用するのは長らく不可能なものと思われてきました．しかし昨年2015年の中頃に Java からでも Server::Starter の利用が可能であることが 
id:tokuhirom 氏により発見された (+ Server::Starter にパッチが送られた) ため，Java からでもお手軽に Server::Starter を用いた graceful restart が出来るようになりました．
Server::Starter については参考になる記事がインターネット上にたくさんありますから適宜検索してもらうとして，Java から Server::Starter を利用する術については以下を参照してください．
さて本題ですが，タイトルが長いのでわかりやすく分割して書きますと，
に，JMX が port を食い合ってしまうために上手く restart できないという問題についての話です．
例えば，以下のようにして Server::Starter + Java + jmx を起動してから，
$ java \
...
-Dcom.sun.management.jmxremote \
-Dcom.sun.management.jmxremote.port=5555 \
-Dcom.sun.management.jmxremote.rmi.port=5555 \
Mainrestart を行うと，瞬間的に2つの Java のプロセスが立ち上がるため，JMX の connector server が port を食い合って (新プロセスの方が "Address already in use" を吐く) 新しいプロセスを上手く立ち上げることがきなくなります．こうした場合，connector server は立ち上がりませんし，手法によっては古いプロセス・新しいプロセスの両方とも終了せずに無限に起動し続けるといった，言うなればデッドロックのような状況に陥るかもしれません．
というわけでどうするかというと，コマンドラインオプションを指定する代わりに手で connector server を立ち上げるコードを書いて，daemon の起動時に立ち上げてやります．
public void startJMXConnectorServer() throws IOException { final int port = 5555; LocateRegistry.createRegistry(port); final JMXServiceURL url = new JMXServiceURL("service:jmx:rmi:///jndi/rmi://localhost:" + port + "/jmxrmi"); final MBeanServer mBeanServer = ManagementFactory.getPlatformMBeanServer(); JMXConnectorServerFactory.newJMXConnectorServer(url, null, mBeanServer).start(); }
こんな感じのものを書いて，立ち上げのタイミングで startJMXConnectorServer() を呼び出してやると，コマンドラインオプションで指定した時と同様の効果が得られます．
が，しかしこれで上手くいくかと思いきや，このままだとコマンドラインオプションを使った手法と同様で上手く resstart することが出来ません (依然 "Address already in use" が出る)．
ので，苦肉の策でこうしてやる．
public void startJMXConnectorServer() { final int port = 5555; boolean isJMXLaunched = false; for (int i = 0; i < 100; i++) { try { LocateRegistry.createRegistry(port); final JMXServiceURL url = new JMXServiceURL("service:jmx:rmi:///jndi/rmi://localhost:" + port + "/jmxrmi"); final MBeanServer mBeanServer = ManagementFactory.getPlatformMBeanServer(); JMXConnectorServerFactory.newJMXConnectorServer(url, null, mBeanServer).start(); } catch (IOException e) { // Might be "address already in use" error, retry try { Thread.sleep(300); } catch (InterruptedException ie) { log.warn("Interrupted"); } continue; } isJMXLaunched = true; break; } if (!isJMXLaunched) { throw new RuntimeException("Failed to start JMX connector server"); } log.info("JMX connector server started"); }
スピンロックのような感じで port が空くまで待って，port が空いた，すなわち古いプロセスが終了したら connector server を立ち上げるという感じ．これでひとまず動くっちゃ動く．良かった良かった．
しかしこの方法だと起動のタイミングによっては「古いプロセスの破棄」と「新しいプロセスの完全な立ち上がり」との狭間に落ちて，リクエストを取りこぼしてしまう可能性があるので，実装に (つまり startJMXConnectorServer() を呼び出すタイミングに) 気を使う必要がありそうです．
あるいは Web Application のようなものであればこんな方法を使わずに，起動してから最初にリクエストが来た瞬間に connector server を立ち上げてやる，というような方法でも良いかもしれませんね．
こちらからは以上です．
