その手の平は尻もつかめるさ

ギジュツ的な事をメーンで書く予定です

HikariCP で kamipo TRADITIONAL を有効にする

java

さて2015年も暮れになってきましたので，各位に於かれましては常識の如く kamipo TRADITIONAL を有効にしていることと存じます．
kamipo TRADITIONAL とはなんぞや，という方は以下のエントリが参考になりますからご一読下さい．


さて Java で kamipo TRADITIONAL を有効にするテクについては

上記のエントリで紹介したわけですが，21世紀の我々には文明があるので connection pooling というものを使う (あるいは使えと言われる) ケースが多くなっております．

ということで HikariCP を使うわけですが，この時に kamipo TRADITIONAL をどう設定するのかという話題があります．connection を borrow する度に sql mode を set するというのも渋いので，以下のようにしてやるとよろしい．

final HikariDataSource dataSource = new HikariDataSource();
...
// This is "kamipo TRADITIONAL". More strict, healthy, nice.
// https://github.com/kamipo/etcfiles/blob/b8d7f2dc93567cb3de486197952ac8b048641d31/etc/my.cnf#L28
dataSource.setConnectionInitSql("SET SESSION sql_mode = 'TRADITIONAL,NO_AUTO_VALUE_ON_ZERO,ONLY_FULL_GROUP_BY';");

HikariDataSource#setConnectionInitSql() を使うと，connection を initial state でセットアップする時にだけ発行する sql を指定できるので *1，ここで kamipo TRADITIONAL を設定するようにしてやると connection が作られるタイミングで kamipo TRADITIONAL が有効になり，以降はその kamipo connection *2 を使い回すことが可能となります．


簡単ですね！

*1:This property sets a SQL statement that will be executed after every new connection creation before adding it to the pool. If this SQL is not valid or throws an exception, it will be treated as a connection failure and the standard retry logic will be followed. Default: none https://github.com/brettwooldridge/HikariCP#infrequently-used

*2:kamipo TRADITIONAL が有効になった connection という意味です．流行させたい語です

HikariCP のステータスを JMX 経由で取得する

java

HikariCP を使っていると，connection の状態をモニタリングしておきたくなると思います．例えば active な connection と idle 中の connection の比率を見たかったり，あるいは connection がリーク (アプリケーションが connection を borrow するだけして返却してない状態) していないかをモニタリングしたい，みたいなケースが挙げられるでしょう．
こうしたものはモニタリングしたくなるのが心情というものですし，モニタリングすべきだとも思っています．


開発中の環境だと HikariCP のデバッグログを出すことでそこから connection の情報を取得することが出来ますが，本番の環境だとそんなのは出さないし (HikariCP のデバッグログは結構量が多い) ，出したとしてもいちいちログを見てやっていくのはダルいので，やはり JMX で見たいという事になります．
そのやり方は至って簡単で，

final HikariDataSource dataSource = new HikariDataSource();
...
dataSource.setPoolName("pool-name");
dataSource.setRegisterMbeans(true);

という風に，dataSource.setRegisterMbeans(true); としてやることで HikariCP のメトリクスが JMX で取れるようになります *1．


あとは jolokia なんかを使っている場合だと，

http://server.example.com/jolokia/read/com.zaxxer.hikari:type=Pool%20(pool-name)

という風にアクセスしてやると HikariCP の connection のステータスを取得することができるようになります．


あとは数値を取ってこういうグラフを描画することが可能．

f:id:moznion:20151213013152p:plain

Total の connection の個数を見つつ，その上に active，idle，awaiting な connection の状態を描画することで，connection のステータスが一目瞭然となります (ちなみに18:00 を超えた辺りで total の connection がガクッと落ちているのは再起動したからです)．
便利ですね．


See Also: MBean (JMX) Monitoring and Management · brettwooldridge/HikariCP Wiki · GitHub

*1:registerMbeans: This property controls whether or not JMX Management Beans ("MBeans") are registered or not. Default: false https://github.com/brettwooldridge/HikariCP

ねぎま鍋、ほうれん草とツナのマヨネーズあえ

今日も定時退社することに成功しました．嘘です，実際には45分ほど残業をしましたがこれは定時と言っても遜色はありません．最高の事態です．

というわけで自炊にも成功しています．

マグロの切り落としが300gで340円という破格でしたので調達しました．季節も季節なのでねぎま鍋とします．
醤油大さじ3，酒大さじ3，みりん大さじ1，白だし適量という感じで漬けます．ある程度放置．その間に飯でも炊きましょう．

昨日のほうれん草が残っているので，飯が炊けるのを待つ間に酒の友を作りましょう．幸いなことに良いツナ缶もあります．このツナ缶は id:papix さんからもらったものです．

ほうれん草を茹でたものにツナ缶を1缶，マヨネーズ適量，粗挽き胡椒を想像を遥かに超えるくらいガッツリ，醤油を隠し味程度放り込みます．そして頑張って混ぜる．

成果物．

最高に美味い……奇妙にビールが進む，今日はインドの青鬼です．

各界からの反響．

ねぎまに戻ります．長ねぎに焼き色を付けていきます．これは1本分です．

鰹出汁に醤油，塩，酒，みりん，隠し味に味噌を僅かに加えて味を付けた出汁です．

一煮立ちしたら，漬けていたマグロを漬け汁と共に投入し，長ねぎを追います．とろ火でじっくり煮る．煮る時間は適当で良いと思います．あくが出たら適宜取ります．

味がしみたと確信した時が食べごろなので椀などによそいます．

美味い！！！！ 飯だけでなく日本酒も進むのです．


明日はこうです．


[追記]

間違えて技術的なブログの方に書いていた……

普段はこういった事はこっちに書いています．

http://moznion.hatenablog.com



情報共有システム (Wiki みたいなやつ) に求めること

いま所属している組織で使っている情報共有システムが僕はいまいち好きではなくて，気に食わないところを twitter にガーッと書いたんだけど，さてここで「良い情報共有システムとは」と考えた時にスッと言語化出来なかったので，僕の思う情報共有システムに求めることをここでまとめておくことにする．

エディタが腐ってない

これは本当に重要で，エディタが腐っていると「Wiki を書こう」という気がそもそも起きないし，起きたとしてもエディタがストレスフルだと文章を書き始めてすぐに嫌になってしまうので最低限エディタはまともである必要がある．さもなくば Wiki は廃墟と化す．
WYSIWYG なエディタを利用するのは難しいと思っていて，本当に使いやすい WYSIWYG エディタを作るというのはかなりコストが高い (WYSIWYG エディタはある程度まで完成度が高まっていないと使い物にならない気がする) ので，システム側がマトモなエディタを用意してくれている可能性は高くはない．あと WYSIWYG の場合は見たままが成果物に反映されるから，誰かにとって使いやすいものでも他の誰かにとっては使いにくいという事が起きやすいと思っていて，組織全体にとっての使いやすさを最大化するのが難しい気がする．
そうなってくると，何らかの記法 (Markdown やそうした類のもの) に対応してそれを用いて書くのが良いのかなと思うし，僕はそれで良いんだけど，エンジニア以外の人にとってそれは本当に使いやすいのかな？　という懸念はあって，難しいところだと思う．だからと言って，1つのページについて或る人は WYSIWYG で書いて，また或る人は Markdown で書く，みたいなハイブリッドな方法を採用すると大体カオスな事になって不幸が起きるという印象しかない．しかしこのへんに上手い解決法が提供されると幸せそう．
あとブラウザ内にエディタがあるというのは，エディタがブラウザのキーボードショートカットを奪ったり，或いはブラウザに奪われたりするから難しい気もしていて，そうなると既にある文章を API 経由か何かで送りつけられるのが良いのか，もしくはネイティヴなアプリがあると良いのだろうか？　とか思うけどここらへんは良く分からない．一方でブラウザから編集できないと，資料を見ながら「ここ間違えているからスッと直そう」みたいな感じでカジュアルに編集しようとする意識をサポート出来ないから，ブラウザで編集可能である必要自体はありそう．でも GitHub を使っている時にブラウザから README.md を直接編集したくなる事はあまり無い気がする．文化の違いだろうか？

まあ，ストレス無くブラウザでページを編集できれば問題は無さそう．

ページ内の配置がある程度規約に縛られている

Wiki のページはその人の芸術性とかを反映する必要はあまりないはずなので，ある程度規約で縛られていたほうが良いと思う．
「ページ内のここを見たら必ずこれがある」だとか「時系列はページの上の方が新しくて下に行くほど古い」だとか，そういう基本的なことは全ページで共通していたほうが良くて，それは規約のようなものになっているべきだと思う．そうした規約があることで全てのページで「これが欲しい時はここを見ると良い」という共通の認識ができるので，欲しい情報へのアクセスが高速に行えて良いと思う．

自由に HTML を記述できて，自由な場所に自由に要素を置ける，みたいな機能は Wiki だと地獄を生むと思う．

URL の構造が予想しやすい

これは良い API の設計にも似ているけれど，各ページへの URL があまりに自由だと使いにくいと思う．
例えばプロジェクトのトップページは URL パスの親になっていて，その下にそのプロジェクトの各ページや子プロジェクトのページがぶら下がっていて，子プロジェクトはさらにその構造を持っているみたいな感じが使いやすいと思う．全部がフラットな構造になっていて，ページのタイトルがそのままパーマリンクのパスになっているとかはファンキーだけど使いにくいという感想しか無い．

僕はブラウザの URL 窓にプロジェクト ID を打ち込んで，そこから検索履歴に基いて見たいページを絞り込むという方法で特定のページにアクセスすることが多いので，URL に規則性が無いとそれが出来なくて大変な気持ちになる．

検索可能

説明不要だと思う．21世紀の Wiki は全文検索できないと使いものにならない．
あとは「このプロジェクト内の文書だけ検索」みたいな，検索対象を絞れればあまり不満がないけど，検索オプションが多いと便利そう．

添付ファイルをまとめて管理できる

いま所属している組織では PowerPoint や PDF といった様々なファイルが Wiki にアップロードされ，日夜それらのファイルが更新されていきながら，それを見ながら，というスタイルで仕事が行われているので，添付ファイルを一括で管理できると便利．
例えば「企画.pptx」はプロジェクト内のあのページにあるけれど，「デザインガイド.pdf」はプロジェクト内の別のあっちのページにある，みたいな感じになっていてファイルがガンガン増えてくると，いざ「あのファイルが欲しい」となった時にどこに行けば良いのか分からなくて非常にストレスが溜まる．プロジェクト内の添付ファイルを一覧できる機能があれば，とにかくそこに行ってファイルを GET すれば良いので楽だと思う．

他サービスとの連携がしやすい

ページを更新したりした時に，なぜだかメールを飛ばしたがる Wiki が多いように思うけど，メールで飛ばされてもどうせ見ないし，どうしようもないと思う．それだったらチャットやら他のツールやらに飛ばせる方がどう考えても便利だし，その口があらかじめ用意されていると気持ちが良いと思う．更に自分で拡張も書きやすかったらなお良い．

ここまで書いてから気づいたんだけれど，これはイベントに対応する API がちゃんと提供されていれば良いということになった．

その他

と色々書いたのだけれど，Wiki のようなものはエンジニアだけでなく，あらゆる人が使うし，むしろエンジニアでない人の方が多く使う為，エンジニアが使いやすさを追求してもエンジニアでない人にとっては使いにくくなってしまって，全体的な作業効率は悪くなってしまうかもしれない *1．しかし導入する Wiki システムや BTS システムを選定する人は大体エンジニアが中心になっていて，そうした時にどのようにしてフラットな目線で，かつ明確な判断基準を持って選定すべきなのかというところが気になる．

個人的に，情報共有システムについて特に重視すべき点は「記事の作成・更新にストレスが無いかどうか」と「情報へのアクセスがストレス無くスムーズに行えるかどうか」だと思っている．

とにかく僕はここに列挙したような機能が情報共有ツールに付いていてくれると嬉しい．気づいていないだけで，あるいは忘れているだけで，他にもあった方が良い機能はあるかもしれないので，他の人の意見についても大変興味がある．

あと，最高の情報共有システムがあったら教えて下さい．よろしくお願いします．

追記

マジで重要な奴を忘れていた

*1:エンジニアでもない限り，イベント API を使ってアレやコレやしたい，みたいなことは思わないと思うし……

perl6 の環境を手っ取り早く構築してサクッと Hello world する

perl6

本記事はサクッと perl6 (rakudo) が動く環境を作って，ズバッと Hello world してみるというやつです．
早速行ってみましょう．

1. rakudobrew をインストールする

rakudobrew をインストールします

rakudobrew というのは perl5 で言うところの perlbrew/plenv，ruby で言うところの rvm/rbenv のようなものです．
なぜこうした物を使うかというと，perl6 は開発が非常に活発な言語であるためにデイリーで変更が入っていて，直っていたり壊れていたりするためです．
2015年10月現在，perl6 をやるときは rakudo と MoarVM は HEAD を使うというのが紳士の嗜みとなっています *1．

というわけで入れましょう．

git clone https://github.com/tadzik/rakudobrew ~/.rakudobrew
echo 'export PATH=~/.rakudobrew/bin:~/.rakudobrew/moar-nom/install/share/perl6/site/bin:$PATH' >> ~/.bash_profile
echo 'eval "$(rakudobrew init -)"' >> ~/.bash_profile
exec $SHELL -l
2. MoarVMをビルドする

MoarVM というのは perl6 の VM です．これをビルドするとその VM 上で rakudo を走らせられるようになります．

rakudobrew build moar

そこそこ時間がかかります．待ちましょう．

3. panda をインストールする

panda というのは perl5 で言うところの cpan/cpanm，ruby で言うところの gem のようなものです．
別にこれを入れなくても Hello world 程度なら可能ですが，現実的にライブラリが使えないと話にならないので入れます．

rakudobrew build-panda
4. プログラムを書く

ここまで来るともう perl6 が実行可能となっていますから，あとは Hello world するだけです．
プログラムを書きましょう．

use v6;

say 'Hello world!';

use v6; というのにテンションの上昇を禁じえませんね！
それでは満を持して実行．

perl6 hello.p6

動きましたか？　動きましたね．やりました！　実績解除です．


これであなたも立派な perl6 野郎です．
あとは Perl 6 Documentation を覗いたり，Perl 6 Design Documents を愛でたりして頑張りましょう！
perl6-users-jp/perl6-examples · GitHub を眺めると，perl6 の全体を俯瞰できて良いかもしれませんね．


以上です．

*1:バージョンの切り替えとかも出来るっぽいけど使ったことがない．常に HEAD で生きているから……

Released IO::Blob for perl6

perl6

Released IO::Blob.


This is a perl6 module which provides IO:: interface for reading and writing a Blob.
IO::Blob inherited from IO::Handle, means it supports to handle a Blob like a filehandle (writable, readable and seekable).
For example, in case of you want to buffer string without real file, IO::Blob will help you to do that.

This module is inspired by perl5's IO::Scalar so basic usage is almost the same.

Please see documentation for more details.
https://github.com/moznion/p6-IO-Blob/blob/master/README.md


Enjoy!

perl6 の正規表現の or (|) は longest match

perl6

perl5 での正規表現の or は | のみでした．以下のように使うことができます．

'aaabbb' =~ /(a|a+b)/

これは a にマッチします．左に書いてあるマッチャが優先されますね．


同様に | を用いて perl6 で書いてみましょう．

'aaabbb' ~~ /(a|a+b)/

おおっと，これは aaab にマッチしてしまいます．
何故かと言うと perl6 の | は longest match だからなんですね．すごいぞ，これは便利！！！！

しかし上の perl5 の例と同じような挙動をさせたい場合もあるでしょう．まあ大体はそうですね．
そういう時は | の代わりに || を使うとよろしい．

'aaabbb' ~~ /(a||a+b)/

こうすると a にマッチします．やりましたね．