こんにちは！ピクスタ開発部です。
ピクスタ開発部は今年もRubyKaigiのスポンサーとなりました。今年で5回目です！
今年も、RubyKaigiに参加することができなかった方でもイベントの内容が楽しめるように、実況ツイートをしています。 この記事は開発部のメンバーが選りすぐりのセッションを紹介します。
Keynote「箴言 Proverbs」
今年もDay1のKeynoteはMatzこと、まつもとゆきひろさんの講演でした。「箴言 Proverbs」というタイトルで、ことわざ（先人たちの知恵）から学びを得るという内容でした。
講演で紹介されたことわざは3つです。
- 名は体を表す
- 時は金なり
- 塞翁が馬
1. 名は体を表す
プログラミングにおいて「概念」は非常に重要です。概念は物体が存在しないため、名前をつけなければ説明することができません。「名前をつけるのが難しい」という状態は、名前をつける概念を十分に理解していないためである、と話されていました。
また、プログラミングだけでなくコミュニティにおいても、良い名前はコミュニティの旗印や求心力になります。Rubyという名前をつけた時はGoogleが無い時代だったが、今だったらRubyという名前にしない、と話されていました。
2. 時は金なり
時間の使い方を考え、優先順位を決めることは、自分がどんな人生か、人かを決めるのと同義です。Rubyはプログラミングにおいて、時間を有効活用するための助けになります。
12月にリリース予定のRuby2.6にはJIT Compilerが組み込まれる予定であることや、パフォーマンスを出すために複数のCPUコアを使用する機能が実装されていると話されていたので、実行速度の面でも今後期待ができると思いました。
3. 塞翁が馬
Ruby1.9は1.8と互換性の無いアップグレードになりました。その結果コミニティが停滞しまいましたが、今後はそんな悲劇は起こしたくない、と話されていました。 また、毎年様々な言語が台頭してきており、その都度、Rubyは死んだと揶揄されています。*1
Matzは、Rubyは「Rubyを使ってもっと生産的になる」ことを目指しており、プログラミングの過程ではコードが複雑になったり規模が大きくなったりするが、ツールや機能を提供してサポートしていきたいと考えているようです。
All About RuboCop
RuboCopのauthorであるBozhidar Batsov氏による、同ライブラリの紹介セッションでした。
ピクスタではRuboCopを全社的に導入しており、日々のプロダクト開発において欠かせないツールのひとつになっています。導入にあたり工夫した点は次のエントリにまとまっているので、よろしければこちらもお読みください。
今回、そのauthorであるBozhidar氏がRubyKaigiで初めて登壇する*2ということで、筆者的には大注目のセッションでした。
セッションは「なぜRuboCopが生まれたのか」という話から始まりました。きっかけとなったのは、2011年に彼がメンテナンスしているruby-style-guideのリポジトリに、「PythonのPEP-8みたいに、ruby-style-guideに則って自動でコードをチェックしてくれるツールはないの？」というissueが上がったことでした。
このissueから約半年後の2012年に、最初のバージョンであるv0.0.0がリリースされます。このときには、一行あたりの文字数をチェックするルールのみが実装されていました。
次に、より多くの機能を提供するためにRipperを使って実装を進めたのですが、Ripperには
- CRubyのみサポートしていること
- ドキュメントがほとんど存在しないこと
- パースできるシンタックスは実行時に使用されるRubyのバージョンによって依存すること
などの問題がありました。そこで、異なるプラットフォームで動作し、実行時のRubyのバージョンに依存しないツールにするために、parser gemを使う形に変更しました。 こうして、私たちが現在使っているRuboCopの基礎が出来上がったわけです。
セッションの最後には、「RuboCop 1.0はいつリリースされるのか？*3」という話も出ました。筆者が聞き取れた範囲では
- Rails用のルールをコアから切り離すこと
- RuboCopのextensionを作るためのAPIを用意すること
- デフォルトで有効になるルールの見直しをすること
などが達成できたら、と話されていました。
筆者としては、2つ目の拡張用APIの動向に注目していきたいなと思いました。というのも、現在、RuboCopのextensionとしてはrubocop-rspecなどがありますが、これらのgemはやや強引な方法でRuboCopを拡張しているからです。
このAPIが整備されることでこうした状況が改善されるだけでなく、ESLintのようにコミュニティから便利なextensionが生まれる土壌ができるかもしれない、そんな期待感を抱くことができたセッションでした。
A parser based syntax highlighter
pockeさんによる、エディタ等で使われているRuby向けのSyntax HighlighterをRubyを使って改善したお話でした。個人的には日々の開発でVimを使っていて、Syntax Highlightが間違った形で表現されることに遭遇したことがあったので、どのように改善したかを聞くのが楽しみでした。
一般的なSyntax Highlighterは 正規表現を使って実装されているようです。それも含めて、2つの問題があったそうです。
- Syntax Highlighter用のコード（正規表現）を読むのが難しい
Vimの例: https://github.com/vim-ruby/vim-ruby/blob/master/syntax/ruby.vim - 間違った形でRubyコードをSyntax Highlightしてしまう
「間違った形でRubyコードをSyntax Highlightしてしまう」が起こってしまうと、以下のようにコードが理解しにくくなったりします。ヒアドキュメントとかも同じ問題が起きたりして、あるある！と見ながら思っていました。
上記の2つの問題を解決するために、iroではRubyのパーサーであるRipperを使ってRubyの構文を解析するアプローチをとっていました。
ちなみに、上記はコードをパースするだけなので、Vimから使用する場合はiro.vimを使う必要があります。
実際にRipperを使ってどのように構文を解析しているかは、資料の後半に詳しく載っているのでこちらを参照してください。
将来的には、Inline Highlighting（ヒアドキュメントの中にあるSQLなど）やSlim, Markdownなどの他の言語を対応（現在はRuby, YAML, Pythonのみ）していきたいとのことでした。
本セッションの紹介の冒頭にも書いたとおり、普段はVimを使って開発しているので近いうちに試してみたいと思います。
Exploring Internal Ruby Through C Extensions
RubyのC拡張を書いてみた、という内容の講演でした。
まず、HelloWorldを出力するコードを表示し、Hash実装を元にベンチマークを取るという流れで発表は進みました。途中で、Rubyにおけるガベージコレクトについての基本的な説明もありました。
HelloWorldのコードを見る限り、C拡張は非常にシンプルに書けるようでした。C拡張を書いたことのない私でも容易に試してみることができそうだと感じワクワクしました。
Hash実装のベンチマークについては、以下の4つを比較していました。
- RubyオリジナルのHash
- RubyのHashをC++で書き直したもの
- RubyのHashをRubyで書き直したもの
- 純粋にC++で書いたもの
このうち、最も速かったのは（当然）4.のC++でした。そして、2番目に速かったのは意外にも1.のRubyオリジナルのHashでした。
このことから、C拡張を書いたからと言って必ずしも速くなるわけではない、ということが伺える結果となりました。
（CRubyでは Mark&Sweep 方式を取っており、2.でも同じように実装しているが、自分で書いたコードではすべてのオブジェクトに対して毎回markする関数を呼び出しているのでそのあたりがオーバーヘッドになっているのでは？という推測をされていました。）
結論として述べられていたのは、以下のような内容でした。
- デメリット
- C拡張で書いた部分はmarkや解放をrubyに任せることができないので、自力でC拡張コード内で行わなければならない
- C拡張で書いた部分については、Rubyの進化から取り残される
- メリット
- 既存のCライブラリを取り込む際に用いることができる
基本的に使わずに済むのであれば使わない方が良さそうですが、試しに書いてみるのは楽しそうだな、という印象を受けました。
おわりに
2日目、3日目も実況ツイートしていきます！よければフォローもお願いします！
＊ ＊ ＊ ＊ ＊
ピクスタではエンジニアを募集しています！
