RubyKaigi2016に参加してきました

f:id:tech-kazuhisa:20160909131955j:plain 2016年9月8日から10日にかけて国立京都国際会館にてRubyKaigi2016が開催されました。地域Ruby会議ではなくThe Ruby Kaigiが関西圏で開催されるのは初めてだと思います。RubyKaigi2015はスケジュールの関係で参加することができませんでしたが、今回は岡山から近いこともあり3日間参加してきました。 印象に残ったセッションについて感想を書いておこうと思います。

1日目

Ruby3 Typing(Yukihiro "Matz" Matsumoto)

基調講演はRubyのパパであるまつもとゆきひろさんから、主にRubyの型についてのお話でした。Javaのようにきっちりと型を指定せずとも型推論等を用いて、ストレス無く静的型付けの恩恵をうけることができる言語が最近増えてきています。それを受けて完全な動的型付けであるRubyが今後どのように進化を遂げようとしているのか、その方向性を示す内容でした。

静的型付けのように何度も型を書くのはDRYではないので、絶対にやりたくない。しかし、動的型付けは実行してみるまでエラーが発生しない。静的型付けのような型チェックもできるけど、動的型付けのような柔軟性もほしい。そのために、実行結果を記録し型データベースのようなものを作ってはどうかとのこと。 確かにこの方法であれば完璧ではないにしろ、静的型付けの恩恵は受けることができそうです。私の想像ですがGemで提供されるライブラリにも型データベースが添付される時代が来るのかもしれません。

「前に進むことについてはなんでもやる」と力強く言われていたのがとても印象的なキーノートでした。

dRuby in the last century.(Masatoshi SEKI)

Rubyの分散オブジェクト技術であるdRubyの歴史についてのお話でした。個人的にはRails開発でかつて利用していたSporkで使われていた技術という認識でしかありませんでしたが、分かりやすいデモを交えた発表内容でよく理解できました。前職では.NET リモーティングを使ったプログラム開発を行っていたのですが、dRubyはそのRuby版という印象を受けました。10年ほど前は「ネットワーク経由で遠隔地のオブジェクトをオブジェクトのまま扱いたい」っていう需要もしくはブームがあったのかな？ 遠隔でRubyを操作というとAPIサーバー立てて、httpで操作させるかな...という発想になりがちですが、改めてdRubyの利便性を感じることができました。

Unifying Fixnum and Bignum into Integer(Tanaka Akira)

Ruby2.4系からFixnumとBignumがIntegerに統合されることについての説明でした。

（手元のRuby2.3.1と2.4.0devで検証した結果）

# v2.3.1
p 1.class
=> Fixnum
p 4611686018427387904.class
=> Bignum

# v2.4.x
p 1.class
=> Integer
p 4611686018427387904.class
=> Integer

変更の理由としては

  • 32bit/64bitのCRuby/JRuby実装によってFixnumの範囲が異なる
  • ISO/JISの規格では明確に範囲が決まっていない

といったことが挙げられます。現実的にはBignumとFixnumはプログラマはあまり区別すること無く利用していたわけです。また次のように互換性も保持されているようです。 （手元の2.4.0devで検証した結果）

1.class == Fixnum
=> true

このためコードの変換は基本的には不要だと思われますが、自作のGem等は早めの対策を行って欲しいとのこと。その際にメジャーバージョン(1.2.3の1の部分)ではなくマイナーバージョン(1.2.3の2の部分）をバージョンアップするように要望がありました。

メジャーバージョンだとGemfileで~>で指定している場合にバージョンアップされないし、仕様変更を嫌ってなかなか導入されないためだそうです。仕様変更を行った際に、こういった細かな気遣いを同時に行うことで変更を世に広める事ができるんだなと妙に納得してしまいました。

2日目

Fearlessly Refactoring Legacy Ruby(Justin Searls)

sutureというgemのお話でした。 メソッドの実行状況を一度DBに保存し、下位互換性をチェックしながら新しいコードに差し替えていくという手法でレガシーコードをリファクタリングしていくことができるようです。実況状況を保存するという手法は、外部へのhttpアクセスを保存して、それをテストで利用するvcr.gemに似てると思ったのですが、対象が外部アクセスではなくRubyのメソッドで、かつテストだけではなく開発環境や本番環境で利用できるのが面白いと感じました。

How DSL works on Ruby(SHIBATA Hiroshi)

Rakeを取り上げ、RubyでDSLがどのように実装されているかの解説でした。DSLとは特定のドメイン領域の問題解決に特化した言語だそうです。Rakeは当初Ruby版Makeを作る思想で作られたそうです。普段RailsでRakeタスクを定義している時にタスクごとの依存関係を簡単に解決できるので、なるほどこれが「特定のドメイン領域か」と理解できました。メタプログラミングを利用してDSLをどのように定義することができるのか初心者にもわかりやすく解説されていたのが印象的でした。

Ruby Reference Manual 2016 Autumn(okkez)

Rubyのリファレンスマニュアルであるるりまのお話でした。Ruby2.4.0では次の点が大きく変更となるようです。

  • Tk関連の組み込みライブラリのGem化
  • FixnumとBignumの統合

特にFixnumとBignumの統合はドキュメントのメンテが大変に感じました。

Modern Black Mages Fighting in the Real World(Satoshi "moris" Tagomori)

「現代の黒魔術師が現実世界で戦う」というタイトルです。ここでいう「黒魔術」とはダックタイピングの事。Fluentdの0.12から0.14へのバージョンアップでいかにして下位互換性を保持したままNameSpaceを整理していったかという話でした。この黒魔術のおかげでv0.12用に作成されたプラグインはv0.14で問題なく利用できるそうです。 Twitterで「バージョンを1に変更して下位互換性を切り捨てれば？」という意見もありましたが、Fluentdほど無停止が要求され多くの環境で利用されている仕組みにとって、互換性はとても重要なのだと思います。

ただ、個人的にはv0.14でv0.12のプラグインを利用している時には何らかのWARNINGを出さないといつまでもv0.12のプラグインが利用されてしまうような気がしました。私のプロジェクトでも言えますが、メンテが難解な黒魔術を今後どうやって取り除いていくかが課題となる気がしました。

3日目

Ruby Committers vs the World

Rubyコミッターによる座談会でした。様々な話題が飛び出したのですが私が気になったのは次の3点です。

  • Stringリテラルのデフォルトをfreezeにしないのか？

    Ruby2.3から次のようなマジックコメントをファイルの先頭に書けばデフォルトでStringオブジェクトがfreezeされた状態となります。

# frozen_string_literal: true

会場からこの動きをデフォルト動作にしないのかという質問がされましたが、会場に「このコメントを普段書いている人」と手を上げてもらったところ、大多数の人が書いていないという状態でした。 おそらく大多数の人が書くようになればfreezeがデフォルトとなるのでしょう。

  • Githubで開発はしないのか？

    たとえソースの管理がGithubに移ったとしてもisssueは使わないとのことでした。すでにredmineとsvnの間でいくつもの連携スクリプトが動作しており、そこを自分たちで変更してまで移行するメリットが見いだせないとのお話でした。

  • Ruby3では並行性・並列性のサポートをしてほしい

    Rubyコミッターの笹田さんからの要望でした。同RubyKaigiで新しい並列実行モデルであるGuildの発表をされています。まつもとゆきひろさん曰く「何らかのサポートは取り入れていきたいが、それがGuildになるかどうかは分からない」とのことでした。

Web Clients for Ruby and What they should be in the future(Toru Kawamura)

同氏が2014年のRubyKaigiで発表されていたHypermedia: the Missing Element to Building Adaptable Web APIs in Rails はサーバー側のアーキテクチャに関係するものでしたが、今回はAPIにアクセスするクライアントに関係するお話でした。現在FacebookやTwitterなどWebサービスごとに様々なクライアントGemが存在しています。使い方はGem毎に異なり、それぞれのドキュメントを読む必要があります。その理由としてはWeb APIごとのJSON構造の違いや4xxより細かいWebAPI固有のエラーがあります。またAPIを1回呼び出すことと、機能を実行することにはギャップがあり、機能が使いたいわけであってAPIを呼び出したいわけじゃないとの事です。

これを打破するためには状態管理が必要なWebクライアントが必要とのこと。この発表ではFaradayを用いてミドルウェアを作成し、サービス固有のGemを作成せず汎用的な設計にするテクニックが紹介されました。

It's More Fun to Compute(Julian Cheal)

Rubyを用いてコードで音を奏でる発表を行われていました。まず、様々な波形による音の違いが説明されFM音源世代のおじさんたちは大喜びでした。バブルソートとクイックソートのアルゴリズムの違いを音で表現したのは素晴らしかったです。

まとめ

今回は会場の素晴らしさが印象に残るRubyKaigi2016でした。毎年ですがスタッフのホスピタリティあふれる活躍のおかげで3日間楽しく過ごすことができました。

さて昨今、言語仕様としては多言語に押され気味なRubyですが新しい並列実行モデルや、動的型付けのカジュアルさを引き継いだ型推論の考えなどまだまだネタに尽きないなぁと思い安心しました。今後どのようにRubyが進化していくのか楽しみです。