plenv で stableperl を利用するの術 & stableperl の話

[追記]
(旧タイトル) Perl::Build (plenv) で stableperl が利用できるようになりました & stableperl の話

色々あって方法が変わったので内容を修正します

Perl::Build (plenv) で stableperl が利用できるようになりました & stableperl の話

Perl::Build 及び plenv で stableperl を取り扱うことが可能になりました．
Perl::Build 1.11 以降で stableperl 対応が有効になっています．

Perl::Build 側に Perl::Build->install_from_stableperl() というメソッドが追加されているので，
それを利用すると stableperl の tar玉をダウンロードして展開してビルドしてインストール，という事ができます．

また，最新の Perl::Build を plenv の build plugin として使用すると stableperl を plenv から
取り扱うことが可能となります．
こんな感じ;

$plenv install -l
Available versions:
 5.6.0
 5.6.1-TRIAL1
 5.6.1-TRIAL2
 5.6.1-TRIAL3
 5.6.1
 5.6.2
 ...
 stableperl-5.22.0-1.001

ご利用される方はご利用下さい．

そんなことをしなくても

$ plenv install --as=stableperl-5.22.0 http://stableperl.schmorp.de/dist/stableperl-5.22.0-1.001.tar.gz

このようにすれば入ります！！！！！！
(Thank you @miyagawa)

[追記ここまで]

stableperl について

stableperl の日本語の資料があんまり無いので併記しておきます．

stableperl についての情報は以下のウェブページを見るのが手っ取り早いと思います．

• http://blog.schmorp.de/2015-06-06-a-stable-perl.html
• http://blog.schmorp.de/2015-06-06-stableperl-faq.html

最初の一文を借用して stableperl を説明するならば
「perlの安定性と互換性をオフィシャルのPerlポリシーに記載されたレベルにまで引き上げる (取り戻す)」
ことを目的とした distribution と言うことが出来るでしょう．
stableperl は standard perl の fork であり，AnyEvent や Coro, JSON::XS の作者で知られるところの
Marc Lehmann さんがメンテナを務めています．

特徴としては

• 通常のメンテナンス期限を超えてもサポートされる *1
• 後方互換性を *大変* 重視している
• standard perl が修正を放棄したいくつかのバグを修正する (つもり)
• 新機能の導入に対する意欲は低い．重要な修正については行う

というものが挙げられるでしょう．

こうした fork 版が出るに至った経緯ですが，これは上掲の記事中で再三示されているように
perl の互換性が (standard) perl 5.22 で損なわれたためです．
perl 5.22 は PP のレベルでは互換性が保たれていますが，内部実装に大きく手が加わったため，
内部 API を利用しているような凝った XS モジュールの中には正常に動作しなくなったものが出てきました．
例としては，Lehmann 氏の Coro や gfx 氏の Mouse (ただし ithread 環境下での話)，
またそうした Mouse の問題に伴い Text::Xslate などが挙げられます．恐らく他にもあることでしょう．

そうした状況に Lehmann 氏が業を煮やした為に *2 *3
この度 stableperl という互換性維持を旗印にした fork 版が出たというのが経緯と見ることができます．

さて，そうした状況になってきたので我々はどうするべきかを考える必要があります．

stableperl は互換性が維持され，重要な修正 (fatal なバグ修正などでしょう) が入ることもアナウンスされ，
なおかつ通常の EOL 期日を超えてもサポートされることがポリシーとして掲げられていますから，
これを使っていくというのはひとつの手かもしれません．

しかしながら，「新機能を導入するモチベーションが低い」と書かれていることからも，
今後の standard perl との乖離が進んでいくことは必至でしょう．
なおかつ現状は stableperl は Lehmann 氏が1人でメンテナンスしているようなので *4，
Lehmann 氏にがこの活動に飽きたり，あるいは何らかの事情でメンテナンスを続行できない状況になってしまったらゲームセットとなってしまいます．
そうなってしまった時に，じゃあ stableperl から standard perl に戻すぞ！　となっても
その時の移行コストやリスクは決して低いものではないことが予想されます．

ので，

• どうしても Coro (とかその他の動かないモジュール) を動かしたい時は stableperl を使う (あるいは standard perl の 5.20 以前を使う)
• 動かないモジュールを別の代替モジュールに切り替えていく (standard perl に寄せていく)
• Coro (とかその他の動かないモジュール) を動くように直す，あるいはそれらが直る事を祈る (standard perl に寄せていく)
• あきらめる

あたりが落とし所なのかな〜という見方をしています (しかし Coro が直る未来が見えない)．
個人的には動かないモジュールを別のモジュールに切り替えていくのが現実的な線なのかなあ，という気がしています (なお Text::Xslate は次の Major バージョンアップで Moo 化される見込みで，Mouse 由来の問題は解消される予定とのこと)．

しかしながら今後 stableperl がどうなっていくかは分からないので，動静を見守る必要があるでしょう．
以上です．

*1:予定だと思います

*2:業を煮やした様子については上掲記事のこのパラグラフが分かりやすいでしょう; "Simply because the new set of perl 5 porters (the people maintaining the standard version of perl 5) have an abysmal track record of providing stable releases. They ignore the long-standing policy of keeping compatibility to existing code, and regularly break dozens or even hundreds of modules in new releases, often at a whim, stating they break things as they wish."

*3:とはいえ内部 API を触っているんだから……という意見もある

*4:映画 300 <スリーハンドレッド> を彷彿とさせますね

YAPC::Asia Tokyo 2015にて"Yet Another Perl Cooking"というタイトルで発表します

発表する運びとなりました．
主に上に書いてあるような事を話しますから，興味のある方は是非いらして下さい！！！

ところで，個人スポンサーのチケットが1枚余った風味なので誰か欲しい人いたら「YAPC行きたい！！！」というキーワードを添えてご連絡下さい．参加券だけ差し上げます（ノベルティは欲しいので……）．

fluent-logger-mock-sender 書いた

fluentd (td-agent) をプロジェクトで使う際に，開発途中で「fluentd に対して正しい内容のログを飛ばせてるのかどうか」みたいな事をテストしたくなる瞬間というのがあると思います．

td-agent のモックサーバ的なものを立てて，そこに実際に payload を投げつけて内容を確認するというのでも良いとは思うんですが，もっとお手軽な感じで「送信自体しないで，インターナルなデータ構造に対してログをスタックしておく」という風にすることでテストやデバッグを簡単に出来るのではないか，ということでそういう動きをするSenderを書きました．Maven Central にも上げています．

使い方は synopsis に書いてある通りです．MockSender 経由で put したログについては fluentd に対して送信されず，代わりに MockSender 自体がメンバーとして保持している List に対してログが積まれていくという動作をします．そして然る後，MockSender#getFluentLogs() でそのリストを取ってきたり MockSender#clearFluentLogs() で全消去出来たり，ということができます．

Perl 時代は実行時に動的にFluent::Loggerのメソッドを書き換えることでこのような処理を実現していたのですが，Java ではそうした行いが困難なので書いた次第．

ところで fluent-logger-java の新しいバージョンでは logger が利用している Sender が簡単に取れるようになって便利ですね！　ありがとうございます．

YAPC::Asia Tokyo 2015にトークを応募した

トークを応募しました．

Perl，というかプログラミング全般のテクニックを用いた料理の自動化を試みる話について議論をします．

最近料理に興味があり，併せてソフトウェアエンジニアリングには依然として興味があったので，それをうまく組み合わせた形になりました．

そのタイトルからネタだと思われるかもしれませんが，至って真面目な話をします．応用的な内容としては crontab や CI と組み合わせて料理を自動化することについても検討及び議論します．残念ながら，会場の都合からその場で調理を実演して皆さんに振舞う事は不可能だと思われますから，写真や動画をふんだんに使うことで臨場感を出していきたいと考えています．

みなさんどんどん投票等お願いします．

ところでこのトークをするにあたってかなり金がかかる事が分かってきました．nomikuを購入する事はもちろん，その他のデバイスやら食材やらをガンガン購入していく必要が出てきています．昨日は鴨を購入しました．これはコンフィになります．コンフィについては色々と検討する必要があり，その性能評価の結果についてもYAPCのトークで披露する予定です．というか実際に何度も調理を行って実験をしていく必要があるわけですが，とてもではありませんが僕1人で食べきれる量ではありませんし，下手を打つと破算する恐れも出てきました．我々はどうすれば良いのでしょうか，協力してくれる人を募集しています．
以上です．

gimei-java 作った

世は空前の gimei ブームです．この前 go 版が出ましたね．
というわけで，というわけではなく，業務で必要だったので gimei-java を作ってしかるべきところ (つまりmaven central) にあげました．

Ruby には gimei という gem があり，

gimei は、日本人の名前や、日本の住所をランダムに返すライブラリです。テストの時などに使います。似たようなライブラリにfakerがあります。fakerはとても優れたライブラリで、多言語対応もしていますが、ふりがな(フリガナ)は流石に対応していません。gimei ふりがな(及びフリガナ)に対応しています。

というやつで，強いんですが，Java には存在しておりませんでした (もちろん Faker はある)．

そんな折，大量にテストデータを作る必要が出てきて，僕は「テスト太郎」や「テスト花子」などという架空人物の名前を心をこめて考えてやっていたのですがそんな生活にももちろん限界が来てしまいます．

というわけでこの度 Java 版の gimei を作成・リリース致しました．
快くオリジナルの人名・住所のデータを使わせてくださった @netwillnet さんありがとうございます．

gem の gimei と同等な機能はほぼ揃えています．
使い方は README 等を読んでもらうとして，gimei-java にはオリジナルにはない taro と hanako，加えて noun という機能が追加されています．
それぞれ何かと言うと「○○太郎」「○○花子」 (○○にはそれぞれランダムな名詞が入る)，そしてランダムな名詞を出力するという機能になっています．

こんな感じ:

Taro taro = Gimei.generateTaro();

taro.kanji();    // => "ハム 太郎"
taro.hiragana(); // => "はむ たろう"
taro.katakana(); // => "ハム タロウ"

Hanako hanako = Gimei.generateHanako();

hanako.kanji();    // => "パソコン 花子"
hanako.hiragana(); // => "ぱそこん はなこ"
hanako.katakana(); // => "パソコン ハナコ"

Noun noun = Gimei.generateNoun();

noun.kanji();    // => "関東電化工業"
noun.hiragana(); // => "かんとうでんかこうぎょう"
noun.katakana(); // => "カントウデンカコウギョウ"

これらの機能は実は便利で，「○○太郎」や「○○花子」がテストデータに入っていると，それだけで役所感が出てくるのでカタい仕事をしているという気分に浸ることが可能です．あと男女の見分けが一瞬でできる．

名詞をランダムに出す機能は，個人的に架空の店舗名などを生成する必要があったため「<名詞> + 店」みたいな風に使えると便利かな〜と思って付け足しました．便利．

これらの機能で使っている名詞データのオリジナルはnaist-jdicで，そこから名詞・一般と名詞・固有名詞のみを抽出し，更にそこから1万件に絞り込んだというスタイルになっています．

もしも欲しい太郎や花子がございましたら，名詞のyamlにその名詞データを突っ込むだけなのでパッチを送って来てもらえればと思います．

以上です．ご利用下さい．

STDIN経由で入力を受け取って1秒あたりのスループットを取れるpersecというのを書いた

表題のやつです．便利っぽかったのと書きたかったという理由からgoで書いています．

例えばアクセスログのようなものがあった時，「1秒間に何行ログに書き込まれているか」が分かれば秒間のアクセス数を求めることが可能となります．これはそういうことをする為のツールとなります．
persecを一言で言うと，「1秒間に何行やってくるか」をカウントするコマンドです．

$ tail -F nankano.log | persec

という風に使ってやると，persecはteeの様にtail -Fの内容をそのまま出力しつつ，行数をカウントして一定周期ごとにそのスループットを出力します．末尾に雑に噛ませておくとスループットが取れる．

デフォルトだと，persecは60秒ごとのインターバルでスループットをSTDOUTに吐き出します．この場合は60秒間分の行数をカウントしておいて，それを60で割ったものを1秒間あたりのスループットとして扱います．
インターバルは--delta，スループットの出力先は--outというオプションでそれぞれ指定することが可能です．また，--noteeオプションを指定すると，受け取った内容をteeの様にフォワードしなくなります．

加えて--patternというオプションによって，カウントの対象とする行を絞り込むことが出来ます．ここにはgoで利用可能な正規表現を突っ込むことが出来ます．例えば，yyyy-mm-ddから始まる行だけをカウント対象にしたい場合は--pattern="^[0-9]{4}-[0-9]{2}-[0-9]{2}"というふうに指定してやるとそのような感じになります．

--helpで詳細が見れますから，そちらもご確認ください．

シェルスクリプトでも頑張ればこういうことが出来るような気もしたんですが僕にはその力が足りなかった！
というわけでどうぞ御利用ください．

余談ですがテストをどう書けば良いかわからなくて，結局シェルスクリプトによるE2Eテストになってしまった……

java-db-transaction-managerが出ていた

大昔の話ですが，java-db-transaction-managerというのを書いて，リリースしていました．

PerlのTransaction ManagerであるDBIx::TransactionManagerのJava移植版です．シンプルなやつが欲しかったので．

機能としてはDBのtransactionに必要な機能であるbegin，commit，rollbackを提供しています．
入れ子になったtransaction内で既にrollbackされているのにも関わらずcommitが発行された時は例外が上がります．普通な感じですね．
try-with-resourcesを利用することも可能で，もし明示的にcommitもしくはrollbackが発行されないままそのスコープ外に出ると自動的にrollbackを発行するというような挙動になっています．

加えて，アクティブなtransactionのトレース (現在のtransactionのみ，あるいは全てのtransactionについて) を取るということも出来ます．便利！
ところでJavaでLLの様にカジュアルにスタックトレースの情報を取ろうとするとまあまあハイコストで困ってしまう，というかパフォーマンスに支障が出るわけですけれども，それを何とかすべくこのライブラリではJDKのprivateなAPIをリフレクションで呼び出すという力技で解決しています．そうすると速い．ここらへんは
tokuhirom/caller · GitHub
を参考にしました．

御利用ください．
あ，念のため言うとスレッドセーフではないです．