てくすた

ピクスタ株式会社のエンジニア・デザイナーがつづるよもやまテクニカルブログです

RubyKaigi 2017 2日目まとめ

こんにちは!ピクスタ開発部です。

f:id:Yasaichi:20170919094640j:plain

RubyKaigi 1日目に引き続き、2日目も実況ツイートをしました! それでは、2日目の開発部のメンバーが選りすぐりのセッションを紹介します。

The Ruby Module Builder Pattern


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


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

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用のゲームプログラミングフレームワークのDXRubyDXだそうで、RubyからJavaScriptに変換するOpalにさらにDXRubyの機能を入れたものということだそうです。

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

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

おわりに

RubyKaigi後にランチ会を企画しています!サービス開発の話はもちろん、ピクスタの開発環境や、開発部の組織体制/チームづくり、キャリアの話、今注目の技術に関する話題など何でも話しましょう!

*1:既存APIとの互換性が保れていました