とうとう最終日です。
２日目の良い天気は続かず、
今日は朝から雨が降っていました。
最終日のスケジュールはこちら。
Schedule – RubyKaigi 2015
Rubyコミッタ大集合
３日目の最初のセッションは
Rubyコミッタの方々が壇上に集まり、
Ruby開発の現状と未来について語ってくれました。
少し前に話題になった @kazuhoさんによる最適化の話も本人を交えて盛り上がりを見せていました。
Rubyにcontributeするには？という質問に対し、コミッタは以下の様な回答をしていました。
「Redmineへのバグレポートやパッチを投げまくっている人には、コミッタが面倒くさくなってコミット権をくれたりします。」
Writing web application in Ruby
@youchanさんによるReactライクな仮想DOMをRubyで記述できるHyaliteというgemの紹介でした。
youchan/hyalite
スライド自体もHyaliteで作られているという凝った仕掛け。
当初はそのことは伏せられており、実は…といった形で紹介されました。
紹介後、会場がざわざわ。デモとしてもすごく良いですねー！
Railsのフロントエンド周りの動向は
これからもチェックしていきたいですね。
Upcoming Improvements to JRuby 9000
今年リリースされたJRuby9000についての発表。
1.7.xから9000の変更点、
現在の高速化への取り組みの紹介でした。
年明けにリリース予定のJRuby9.1.0.0ではRuby 2.3もサポートされるそう。
Refinements - the Worst Feature You Ever Loved
モンキーパッチは、DSLやActiveSupportのような便利メソッドの追加、メソッドをラップする際に使いますが、使い方次第で全体に影響が出るようなものになってしまいます。
そこで、Refinementという機能を使って安全にモンキーパッチを当てる方法を教えていただきました。
Refinementを使うと、Lexical Scopeの範囲内でのみ適応されるため、そのモジュールを使っているクラス以外には影響が出ないようにできるそうです。
Discussion on Thread between version 1.8.6 and 2.2.3
1.8.6と2.2.3で、スレッドを使った際に2.2.3の方がよりCPUを使うようになったことと、例外を併用した際に消費するメモリ量がめっちゃ増えて、なんなんだろう、ということを1プロセス100スレッドで100プロセスの計10,000スレッドが動くシステムの実行結果をもとに伝えておられました。
その場にいたコミッタの方が、もしかしたら例外をあげたときにスタックにポインタを積んだりするので、数が多いと一気に膨らむのかも・・・？ということを考察されていました。
Plugin-based software design with Ruby and RubyGems
@frsyukiさんによるFluentdやEmbulkにおける
プラグインベースのアーキテクチャの設計について、どうデザインしたかを話していただきました。
プラグインを実現するのには2種類あって、1つはコアにフックポイントを用意し、コアからプラグインを呼び出す方式です。
プラグインができることを増やすには本体の改修が必要で、他のプラグインにも影響を与えます。昔のソフトウェアに多いそうです。
もう一つは、コアを解放して、プラグイン同士で連携するようなネットワークを形成させる方式です。
プラグインの中から別のプラグインを呼び出せる機構が必要になります。
FluentdやEmbulkでは、プラグインのエコシステムを構築できる環境をデザインするために、後者を選択したそうです。
こういったエコシステムを構築できるようにする方が重要だと考えていたからだそうです。
機能の大部分をプラグインで構成することで、
コアを小さく保ちつつソフトウェアの拡張性を担保することができ、
さらには複雑性も上がらないのでテストもしやすいとのことでした。
Let’s make a functional language!
Hindley-Milner type systemという型システムの考え方と推論の動きを解説していただきました。
その実装として、OreScriptを作ってみたそうです。
yhara/rk2015orescript
言語を作る上で必要になってくる構文木を生成するために、raccというLALRパーサのgemを使ったりと、型推論以外の部分でも参考になりました。
tenderlove/racc
Actor, Tread and me
ActorはThreadの良い版という風潮に待ったを投げかけるセッションでした。
Threadの代わりにActorを使えば全て解決するようなものではなく、ActorでもThreadでも、処理内容がお互いに依存している場合はシステムをうまく設計しないとデッドロックは発生しうるということを話しておられました。
船に乗ったoso_matz, jushi_matzらがエーテルにメッセージボトルを流している概念図がとても可愛いスライドでした。
KeyNote: Ruby3が3倍の速度を手に入れるためには
Rubyが今の3倍のスピードを手に入れるためにはどうすればいいのか？
@evanphxさんによるその解決策の提案でした。
JavascriptのV8エンジンや、Strongtalk, SELFといった、JITの先人の紹介と、Rubyのコアも中間コードにしておくことで、JITを使えばいかにコードが最適化できるのか、サンプルコードを例に語られました。
スポンサーセッション
今回、SpeeeはRubyKaigi 2015にRubyスポンサーとして協賛させていただきました！
なんと、最後のKeyNoteの直前に3分間、Speeeのことを紹介する時間をいただくことができました。
↑ 壇上から見た風景
Splathonの紹介と、Speeeラウンジの紹介、そして、弊社のRubyに対する取り組みを簡単に紹介しました。
Speee.rb thank you! #rubykaigi pic.twitter.com/MxeKyTUrNF
— Nick Hance (@nhance) 2015, 12月 13
「Rubyコミュニティへの貢献」の1つとして、今回のRubyKaigi2015、及び、先日のRubyWorld Conference 2015に協賛させていただきましたが、これから、技術面でもOSS活動など様々な形で貢献できるよう、開発部一同精進していきます！
