The Ruby Module Builder Pattern

Moduleをincludeしたとき、includeした側にメソッドが生えたような動きをしますよね。 includeする側でModuleのメソッドと同名のメソッドを定義すると上書きできますが、なんとprivateのメソッドも上書きできてしまいます。 Moduleをincludeする時はModuleのメソッドを衝突しないように注意して実装しなければならない…!? カプセル化とは…!?

この問題を解決するために Module Builder Pattern が考えられました。このパターンでは include、configureを行い、メソッドの定義をinclude側からすることでこの問題を解決できます。内部の処理はメタプログラミングでなかなか読みづらいコードでしたが、使う側は生えるメソッドが明示的になり、スッキリしました。

Static Typo Checker in Ruby

現在はRubyに組み込まれている did_you_mean gemの話でした。みなさん、以下のようなエラーメッセージ、見たことはありますよね。

"PIXTA".starts_with?("P")
NoMethodError: undefined method `starts_with?' for "PIXTA":String
Did you mean?  start_with?

typoを見つけてくれて、正しいメソッドを教えてくれています。これがdid_you_meanの機能で、助けられた経験がきっとあるはずです。

VSCodeやRubyMineから使用する方法も紹介されました。依存が多く速度面の問題があるとのことでしたが、did_you_meanの恩恵がIDEなどで得られたらすごく便利ですね。

An introduction and future of Ruby coverage library

フルタイムRubyコミッターとしてクックパッド株式会社にjoinすることが発表されたばかりの遠藤侑介氏による、テストカバレッジおよびcoverage.soの新機能に関するセッションでした。

coverage.soはRuby本体のテストカバレッジ計測のために遠藤氏によって開発されたライブラリで、SimpleCov（カバレッジの可視化等行うgemで、coverage.soのラッパー）を経由して広く使われています。しかし、遠藤氏はcoverage.soがRuby本体のテストカバレッジ計測以外の目的に使用されることを想定していなかったようで、そのAPIはline coverageの計測だけに特化した形になっていました。このAPIは長らくそのままになっていたのですが、先日、遠藤氏はRubyの堅牢性向上を目的として、coverage.soにbranch coverageとfunction coverageの計測機能を追加するコミットを行いました。

発表では、各種テストカバレッジの紹介と長所・短所、およびその向き合い方について丁寧な説明があった後、Ruby 2.5で導入予定の新しいAPI*1の紹介がありました。また、新しいcoverage.soを使ってRuby本体のテストカバレッジを計測したデモが披露されました。個人的に印象的だったのがこの計測結果で、line coverageは80%を超えていましたが、branch coverageは70%を切るという結果となっていました。

質疑応答の際には司会の松田さんから「SimpleCovのコミッターとして、時間ができたら新しいcoverage.soへの対応をしたい」といった旨の発言もあり、よりよいテストカバレッジ計測に向けてRubyが前進している現状がわかる、個人的に大満足のセッションでした。

Ruby, Opal and WebAssembly

「Rubyで作る奇妙なプログラミング言語」の著者のYutaka HARA(@yhara)さんのRubyを使ってブラウザゲームを書くためのOpal(RubyからJavaScriptにコンパイルしてれるAltJSです。)のゲームプログラミングフレームワークDXOpalとWebAssemblyのお話でした。

なぜOpalなのか？JavaScriptも書けないわけではないけれど、「脳のキャッシュに乗っている」ってことで、そういうことを重要視しているそうです。 DXOpalのDXは、Windows用のゲームプログラミングフレームワークのDXRubyのDXだそうで、RubyからJavaScriptに変換するOpalにさらにDXRubyの機能を入れたものということだそうです。

DXOpalのセールスポイントは、Firefox限定ではあるものの、Rubyをインストールしていなくてもゲームを作れるということ！

DXOpalのSpriteクラスでは、当たり判定の処理は計算が多くてボトルネックになりがち拡大、回転という処理があって、回転すると当たり判定を増やさないといけなくて、 Opalだけだとボトルネックになってしまい、JavaScriptより遅くなってしまう。原因は、Rubyの+演算子は、文字列も配列も加算ができてしまうことで、Opalで書かれたものがJavaScriptにコンパイルされると、複雑なものになってしまうためということで、残念な状態に・・・と思ったところで、タイトルにもある「WebAssembly」の登場でした！

「WebAssembly」の導入を検討した理由は、アセンブリって付いてるしなんか速そうだなということで、名前から期待してとのこと。名前重要ですね！

DXOpalの当たり判定を行う部分だけWebAssemblyを組み込み、 Opal版よりもパフォーマンスがよくなったデモというでしたが、まとめに入る前にyharaさんから重要なお知らせがありました。 WebAssemblyは、実は速くはなくJavaScriptと同じくらいと衝撃の事実が !！ WebAssemblyはロードが速くはなるけれど、実行速度はJavaScriptと同じくらいだそうです。

使いどころとしては、Opalでアプリを書いて一部だけWebAssemblyを使うというDXOpalのようなケースが適していそうです。将来的には、RubyもWebAssemblyで動かせるようになるのか？ということでしたが、 RubyをWebAssemblyにコンパイルするにはいくつもの問題があって、そもそもやりたいのは、Rubyをブラウザで動かす、ということだったはず。そうであるならOpalを使えばいい！ということに。

まとめとしては、 DXOpalをきっかけに、WebAssemblyとRubyの関わりをみてきたところ、 WebAssemblyは銀の弾丸ではなく、単にブラウザでRubyが動けば良いという状態であればOpalを使いましょう！ということでした。 OpalもDXOpalも知りませんでしたが、ブラウザで動くものをRubyで書いてみたくなったお話でした。