（弊社からの RubyKaigi 2018 速報リンク: 2 日目 / 3 日目）
こんにちは。デジタル・トランスフォーメーション（DX）事業部エンジニアの中嶋（@nyamadorim）です。 Twitter の画像リストを見てもらえるとわかるんですが、私は書道の人です。
最近は、TypeScript + React でフロントエンド 8 割、Rails で JSON API を書くのが 2 割ぐらいで、RubyKaigi の Speee ブースでデモを行った架電ツールの開発を行っています。
RubyKaigi 2018 は 2 年ぶりの参加です。では、少し遅くなりましたが一日目の発表内容のレポートといきましょう。
Keynote
一日目の Keynote は、弊社技術顧問の Matz さんからです。
発表ではことわざを通して、Matz がプログラミングや Ruby という言語コミュニティにおいて大切にするコンセプトについて話しました。
ことわざの「名は体を表す」は、つまり Matz の座右の銘である名前重要です。名前付けには、振る舞いに対する名前と、プロジェクトに対する名前があります。振る舞いに対する名前とは、クラス名やメソッド名のことです。私達プログラマがしばしば直面する「命名の辛さ」は、概念に対する理解の不足から起こります。Matz が挙げた悪い命名の例として Ruby の yield_self があります。yield_self は
def yield_self yield self end
という挙動と名前が完全一致した身も蓋もない名前ですが、このメソッドを使って何をしたいかが、この名前からは伝わりません。そこで Matz は yield_self のエイリアスに then を追加する、というコミットを RubyKaigi の前日に行いました。これが 5 年ぶりの意味のある Matz のコミットでした*1👏
Ruby は振り返れば「塞翁が馬」でした。Ruby on Rails の登場以来、Ruby は多くのユーザに愛される言語になりました。後発の言語もあり「Ruby is Dead」と言われることもありますが、これからも歩みを止めず進化し続ける、と Matz は締めくくりました。
then という命名、私はしっくりきましたが、JSer にとって、ES2015 の Promise.then と意味が違うのが違和感になりそうですね。今年 2 月に開かれた Ruby 25 と重複する内容も多くありましたが、Matz の哲学的なキーノート、私は何故かいつも引き込まれます。残りの RubyKaigi 2018 で発表される「様々な Ruby の未来」が楽しみですね!
Deep Learning Programming on Ruby
弊社から、Ruby コミッター @mrkn とエンジニアの @hatappi が発表しました。この発表は残念ながら見ることができなかったので、レポートは、@hatappi が書いたこちらを見てください!
Python や R の世界がメインだった機械学習が Ruby でできるようになるのは、選択肢が広がっていいですね!
Deep Learning Programming on Ruby by @mrkn and @hatappi
— null (@KatsumaNarisawa) 2018年5月31日
選択の幅が増えるのは素晴らしいし、Rubyでもこの辺色々出来るようになるの本当ありがたいなあ。 pic.twitter.com/AwZ4avlZmW
社内に @mrkn、@gfx、@hatappi、@ktou（月一で社内に来てくれます）など OSS 活動に関わる人がいるのは、本当に恵まれている環境だなと改めて思います。
Hijacking Ruby Syntax in Ruby
www.slideshare.net
@joker1007 さんと @tagomoris さんの発表です。
発表では、発表者が開発した gem を例に、Ruby の Binding や TracePoint など強力なメタプログラミング機構について話しました。
Binding#local_variable_set でよそのコンテキストの既存の変数を上書きでき、TracePoint は、コード実行中に発生する「例外発生」や「クラス定義の開始」や「クラス定義の終了」などあらゆるイベントをイベント発生元の Binding オブジェクトと共に取得できます。この TracePoint、Binding#local_variable_set、メソッドフック（Module#method_added など）のような強力なメタプログラミング機構を利用しつつ、Refinements によって安全にコア API に追加できます。
発表者の方々は、前述の強力なメタプログラミング機構を利用した便利な gem を開発しています。興味深い実装なので、コードを覗いてみてください! 数百行程度のコードでサクッと読めると思います! *2
- joker1007/overrider / TracePoint, Ripper
- Java のような
overrideメソッドを定義するための gem
- Java のような
- joker1007/finalist / メソッドフック
- Java のような
finalメソッドを定義するための gem
- Java のような
- tagomoris/with_resources / TracePoint
- Java の try-with-resources のような複数のリソースを安全に確保・開放するための gem
RubyGems 3 & 4
t.co
@hsbt さんの発表です。
発表では、RubyGems 2.7 の現状と RubyGems 3、4 のリリース計画について話しました。
RubyGems 2.7 には、Ruby 1.8 サポートのためのコードの複雑化によってつらい状況になっているとのことです。この状況を解決するためにまず RubyGems 3 でいくつかの API を Deprecated に指定し、Ruby 2.2 未満のサポートを切ります。RubyGems 4 で Deprecated にした API を削除し、いくつかの新機能を導入します。
RubyGems は、Ruby エコシステムにおけるインフラのため、何を Deplecated にし、削除するかの判断はクリティカルに行う必要があります。この判断のために akr/gem-codesearch と aka/all-ruby を使いました。gem-codesearch は rubygems.org のミラーをローカルに構築してコードの全文検索を行う検索エンジンです。all-ruby は、全 Ruby バージョンでコードを実行できるコマンドです。これらを使い、RubyGems の API が他の gem から使われていないかや、Ruby のバージョン間の挙動の違いを確認することで、API の Deplecated や削除の判断を行いました。
RubyGems のような古くからあってインフラのような OSS は、普段仕事で保守することがないので貴重な話でした!
A parser based syntax highlighter
@p_ck_ さんの発表です。
発表では、Ripper という Ruby パーサーを用いた壊れないシンタックスハイライターについて話しました。
既存のシンタックスハイライターは、正規表現によってハイライトする構文を定義しますが、正規表現による構文定義は非常に読みづらいです（例: Atom Editor の Ruby の構文定義）。また、正規表現による構文定義は、実際の言語の文法とは一致しておらず、正規表現の表現力の低さもあり、誤ったハイライトを行ってしまいます（例）。誤ったハイライトはプログラムの理解を妨げる原因になります。
そこで、発表者は Iro という Ripper を用いたシンタックスハイライターと Iro が返した情報を利用して、シンタックスハイライトする Vim プラグイン を開発しました。Ripper を用いているため、Ruby の構文のとおりローカル変数をちゃんと区別してハイライトできるようです。Iro の今後は、Slim や Markdown 対応、Vim 以外のエディタ対応を考えているようです。
Ruby を書いていると時々ハイライトが壊れるなと思っていたので（特に Slim と Ruby の組み合わせ）、めっちゃ良さそうです! 私は Atom / VSCode ユーザなので、これはコミットチャンスですね 💪
最後に
RubyKaigi 2 日目、3 日目の速報は、__mnc90（佐々木） と selmertsx（森岡）が書きました。 こちらも合わせてご覧ください!
