てくすた

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

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との互換性が保れていました

RubyKaigi 2017 1日目まとめ

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

f:id:Yasaichi:20170918183459j:plain

ピクスタ開発部は今年もRubyKaigiのスポンサーとなりました。
今年は、RubyKaigiに参加することができなかった方でもイベントの内容が楽しめるように、実況ツイートをしています。 この記事は開発部のメンバーが選りすぐりのセッションを紹介します。

Development of Data Science Ecosystem for Ruby


Development of Data Science Ecosystem for Ruby

データサイエンスで使用できる言語として、Rubyを紹介する発表でした。主な発表はPyCallを使用したRubyからPythonのライブラリを呼ぶことについての紹介がありました。PyCallを使用することでpandasmatplotlibを使用して、データの整形、可視化、機械学習などを利用することができます。*1
データ分析などをしたくてもPythonが扱えるエンジニアがいなくて苦労する局面も、Railsでデータ分析基盤を作ることで、運用もしやすくなるのではないかと思います。

また、Apache Arrow*2にRubyコミッターが参画されたので、Rubyへの展開が期待できるとのことでした。

API Development in 2017

APIとそれを使う側の両方に携わるものとして、API Development in 2017がとてもよいプレゼンだったので紹介させてください。

フロントエンドが高機能化する昨今、APIを常に良いものに変更したいという要望と、変更への追従が辛い状況とのがんじがらめで、思ったようにスピード感を持った開発ができない、という状況は多いと思います。 APIを作る人は、スマホだったり、別のサービスだったり、他のサービスや他人との関わりが深く、気軽に変更できず、ドキュメントも必要で、テストも用意したい、という厳しい状況にあります。 このプレゼンはそんな僕達の悩みに一石を投じるものでした。

Schema First Development、というAPI設計、開発手法があります。 Schemaによる型定義とドキュメント自動生成により、API設計者、使用者共に並行開発が進められないか、というプレゼンでした。

これまでのREST APIとは異なり、クライアントからクエリを発行するGraphQLの紹介など、API開発の未来を考えさせられるプレゼンでした。

Handling mails on a text editor

RubyコミッターのShugo MaedaさんのRubyで作られたテキストエディタTextbringer、Textbringerのプラグインとして実装されたメッセージユーザエージェントであるMournmailについて、テキストエディタやメール処理の楽しさが伝わる内容でした。

Textbringerという名前は、Elric Sagaという小説の中に出てくるStormbringerという剣の名前から、MournmailはるStormbringerの双子の剣Mournbladeからインスパイアされたものだそうです。
Stormbringerは、秩序と規律を司る法と、多様性と変化とで破壊に向かう混沌との宇宙のバランスが重要なものであり、 Textbringerは、プログラミングと宇宙バランスが重要ということで、スパゲティコードでテストのない破壊的なこともダメだし、ルールの厳しい非情なRubocopの使用によって縛るようなコードでも停滞してしまうので、バランスが重要という設定?も大切なことで納得感もあるけど、それよりも小説を元にした背景設定を持つテキストエディタの開発そのものが楽しそう。

バッファの取り方や、文字の内部エンコーディング、再描画などの話もありましたが、 テキストエディタ、プラグインを作るのは楽しい、なんでもできるのがRubyの良いところ、と話されていたことが印象的な内容でした。

Hanami - New Ruby Web Framework


Hanami - New Ruby Web Framework - RubyKaigi 2017

Hanamiのcore developerであるAnton Davydov氏による、同フレームワークの紹介セッションでした。

今年の4月にバージョン1.0.0がリリースされたばかりの、Ruby製の新しいWebアプリケーションフレームワークであるHanami。筆者は旧名のLotus時代からその存在(とその特徴的なディレクトリ構造)は知っていたのですが、コードをちゃんと見たのはこの日が初めてでした。

発表の中で特に印象に残ったのが、1つのActionに対して1クラスを使って実装する点と、ModelをEntityとRepositoryの2層で表現している(=Repositoryパターン)点です。前者は、リクエストパラメータを引数に取り、Rack Application形式の配列を返す#callメソッドのみを持っているため、コードの見通しがよく、テストが書きやすいという利点があります(参考: 公式ドキュメント)。

全体的にRailsと比較して「これどうやって動いてるんだろ」感が少なく(Anton Davydov氏は発表の中でこれを“No magic”と表現していました)、とても良い印象を受けました。

おわりに

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

*1:画像中の物体認識もライブでデモを行なっていました

*2:性能と相互運用性を向上させるために、インメモリでビッグデータをどう扱うかという共通の問題を解決する取り組み