2014-09-22

#RubyHiroba 2014でLTしてきました

最近プライベートは育児で忙しいので、RubyKaigiには残念ながら参加できなかったものの、RubyHirobaに参加してきた。

<a href="http://rubyhiroba.org/2014/">RubyHiroba 2014</a>

多分Ruby系のイベント参加は去年のRubyKaigiとHiroba以来なので懐かしい感じがした。

今回は生活発表とLTthonを見ようかなーと思っていたのだが、最近ネタが出来たのでLTthonの会場でLT資料を作り始める。資料ができて飛び込み参加が間に合えば発表しようと思ったら、昼休憩の間に資料ができたので飛び入り参加してきた。

5人と5万円で 2人が救えた話 from Mahito

発表時間が5分だと思ったら飛び込みが多かったので、発表時間が3分になったからいろいろ端折って喋ったのでここで解説しておく。

Rubyアソシエーション

http://www.ruby.or.jp/ja/

Rubyアソシエーションは、プログラミング言語 Rubyの普及と発展のための組織、理事長にMatz（ゆきひろが漢字になってる）、理事に笹田さんなどがいる。開発支援や、コミュニティ支援、情報発信、Ruby技術者認定試験、事業者認定などを行っている。

Rubyアソシエーション認定システムインテグレータ

http://www.ruby.or.jp/ja/certification/sier/

Rubyの高い技術を持った企業としてRubyアソシエーションのWebサイトにて紹介される。

認定の条件としてSilverでは5名以上のRuby Association Certified Ruby Programmer Silver又はGold資格保持者が正社員として所属していること。

Goldでは5名以上のRuby Association Certified Ruby Programmer Gold資格保持者が正社員として所属していること。

突然現れたRuby案件のヘルプ

当初サポートは２週間という話だったのだが、いつのまにやら２ヶ月になり更に延期になりそうだったが撤収を命じられる。自分が撤収してしばらくして案件は消滅。

サポート体制について

保守的な組織にありがちな「〜が起きたらどうするんだ！」の典型的なパターン。

社内でRubyの技術サポートは行っていないため、プロジェクトからRubyのサポートを依頼されたら対応できないから、サポート体制を作ってからにしてもらいたいと言われたらしいが、多分サポート体制は向こう３年はできないだろうなーと思ったので、偉い人に相談して別ルートから攻略した次第。

登録手続き

言い出しっぺが異動で逃亡した結果、自分にお鉢が回ってきて、大きな企業にはあると言われている、書類を通すためのスタンプラリーをするはめに。多分自分と他に偉い人３名ほど巻き込んだことから5~6人日ぐらいの稼働は費やされていると思う。

社内周知

「Rubyアソシエーションのサイトに載ってお客さんからRubyの話が来たらどうするの！？」という謎な声（むしろ仕事が来たんだから喜べよ）に答えて社内周知をすることになり、ここでもスタンプラリーがはじまり4~5人日ぐらいの稼働をついやして辛み。

結果として、メールは3件来たけど1件は当初のサポート体制の話で、2件有望な若手Rubyistからのメールだったので後者が得られたのが個人的な救い。

ちなみに、Rubyアソシエーション認定システムインテグレータに登録してから1件も営業はおろか、お客様からの反応を聞いたことがないので、最初の心配は杞憂だったんじゃないかと思ってる。

ちなみに最初に相談した少し偉い人たちとの間では「話が来てから考えよう」ということにしている。

社内にいた若手Rubyist

社内にRuby案件なんてないけど自分で勉強してたというエライ若者たち。（そのうち1名はまさかのRubyHirobaに来ていたｗ）

これは腐る前に保護せねばということで、速攻でランチミーティングをして、社内に生息する数少ない手を動かすエンジニアの勉強会を紹介したり、社外の勉強会、コミュニティを紹介して、Rubyを使った開発案件の話がきたら紹介、推薦することを約束した。

というわけで、Rubyアソシエーション認定システムインテグレータに登録してみた結果、社外よりも社内の方に影響があった。それも若手のRubyistたちが腐る前に保護できたのが思いもよらない成果だったという発表をしたつもり。

しかしながら、社内で腐る前に救うより、社外に逃す道を示しても良いんじゃないかと今でも少し悩む事がある。でも、この後彼らが社内外のコミュニティやエンジニアとの交流を通してそこは自分で判断をすると信じて今はよしとしておく。

もしあの会場や、今回公開しておいた資料を見たSIerに勤務しているRubyistの方は、Rubyアソシエーション認定システムインテグレータに登録してみると、社内外で何らかの変化があるかもしれないので、ちょっとおすすめしてみたい。

久しぶりにRubyのイベントに参加でき、更に発表までできて楽しかった。

開催・運営をしていただいたスタッフの皆様、また、場所を提供していただいたCyberAgentの皆様に心より感謝致します。

2014-09-10

また沖縄へ

5月に石垣島に行ってきたけど、夏休みに入ったのでまた沖縄に行ってきます。

今回は沖縄本島

斎場御嶽とか美ら海水族館とかいってきます。

子連れの旅行は大変だー

2014-08-17

ServerspecでXMLファイルの中身をテストするために少しテストをイジってみた

Serverspec

最近はChefとかAnsibleで構築を自動化する際に Serverspec で試験することも多くなってきたけれど、ServerspecだとXMLのテストがしにくい。

リソースタイプに'file'があるが、 containでは評価が正規表現なので通常のファイルの中身を見る文には便利。

describe file('/etc/httpd/conf/httpd.conf') do

its(:content){ should match /ServerName www.example.jp/ }

end

しかしXML形式だとタグの中の複数の値（nameとvalueとか）を見なければいけないとなると、スペースとかが入ってきてやたら長大な正規表現を書くことになりそうで、いまひとつしっくりこない。

<property>
        <name>dfs.block.access.token.enable</name>
        <value>true</value>
        <description> If "true", access tokens are used as capabilities
        for accessing datanodes. If "false", no access tokens are checked on
        accessing datanodes. </description>
</property>

というわけで、なんとなくしっくり来る方法はないかと試行錯誤をしたところこんな形になった。

Serverspec to xml file

'file'リソースタイプのsubjectがファイルの本体のオブジェクトのようだったので、その中身をnokogiriに喰わせて、タグでまとめられるようにしてみた。

そして、今回はプロパティの中身をチェックしたかったのでプロパティごとに名前でヒットさせてその値をテストするようにしてみた。

content + 正規表現よりは読みやすいかと思うのでひとまずはこういう形にしている。

しかし、なんかもっといい方法はないんもんだろうか。。。

2014-08-12

Herokuでの文字化けを直してみた

Ruby Heroku

FluentdのPluginを書こうかなと思って公式HPのプラグイン作成を解説しているページを見たところ、サンプルコード内の日本語が文字化けしてた。

プラグインを書く | Fluentd（現在はPR出して修正済み）

どうも調べてみると、Herokuの上でCodeRayを使うと文字化けしてしまうらしい。

Herokuにデプロイすると、CodeRayでソースコードの日本語が文字化けする - SKKTM Lab Blog

ぐぐってみても日本語で直し方を書いてる人がいなかったので、調べて直してみたのでそのメモ。

ちなみに先に結論だけ述べておくと

.buildpacksにRubyとlibxml2のbuildpackのURLを記載
Gemfile.lockのnokogiriを1.6以上にする
HerokuのConfigにBUILDPACK_URLにheroku-buildpack-multiを指定
デプロイ

やり方はPRを見ていただければ何となくわかると思う。

update libxml2 and nokogiri to fix japanese comment rendering on heroku by Mahito · Pull Request #119 · fluent/fluentd-docs · GitHub

で、調べてから結論に至るまでは以下のとおり。

CodeRayのソースコードを読む

coderay/lib/coderay at master · rubychan/coderay · GitHub
しかしどうもCodeRayが原因じゃないので別の原因を調べてみる
rack-codehighligherを調べる

wbzyl/rack-codehighlighter · GitHub
fluentd-docの中でCoderayが直接呼ばれてるような形跡がなかったので調べてみたところ、rack-codehighligerが関係していたので、Mac上のローカル環境でデバッグするも再現しないのでHeroku上でデバッグ。
すごい時間がかかったがどうやら中でNokogiriがパースしてるところで文字化けが起きてる模様

https://github.com/wbzyl/rack-codehighlighter/blob/64bf50520cb1d563432832ae30d85bbd94cec5bd/lib/rack/codehighlighter.rb#L40
Nokogiriとlibxml2を調べる
Nokogiriのバグっぽいということで追いかけていったが最終的にlibxml2に渡して帰ってきたらバグってることまでは突き止めたので同じ事例がないか調べてみたところこちらでヒット

ruby on rails - Nokogiri adds characters during parsing on Heroku - Stack Overflow
原因はHerokuのlibxml2がバグのあるバージョンを使っていることらしい。
Nokogiriのバージョンを上げる
Fluentd-docはNokogiriの1.5が使われていたが、1.6にするとNokogiriのインストール時にlibxml2を独自にビルドして使うことができるようになったのでbundle update nokogiriをして解決！
・・・と思ったらHeroku上でlibxml2がビルドされた形跡がなく問題解決に至らず
buildpackでlibxml2をバージョンアップ
buildpackをつかえばlibxml2のバージョンがあげられるということでやってみた。
・・・アプリが動かなくなったのでこれもボツ
heroku-buidpack-multiを利用してRubyとlibxml2を導入してnokogiriをバージョンアップ
PaaSといえば個人的にはこの人ということで@jacopenさんに相談したところ、libxml2を入れただけだとRubyが動かないのでbuildpack-multiでRubyとlibxml2を入れないとダメと教えていただいたのでその通りやってみたらようやくサンプルコードの日本語の文字化けが治った。