Sapporo RubyKaigi 2012 スペシャルレポート

札幌Ruby会議2012,2日目レポート[更新終了]

この記事を読むのに必要な時間:およそ 18.5 分

笹田耕一さん「Towards Ruby 2.0: Progress of VM Internals」

初日にHeroku弁当の配布も行なっていた,HerokuのささださんによるRuby2.0の中身についての発表です(スライド等はこちら)⁠ささださんはHerokuのmatzチームに所属しており,そこでRuby処理系の開発を行なっています。

セッション冒頭からRuby2.0の機能についての話ではなく,その機能をどのように実現しているのか,ということについての話だということや,RHG(Ruby Hacking Guide)くらいは読んでる人が対象,ということでハードルを上げながら話を始めました。

Ruby2.0

Rubyは1993年2月24日に誕生しました。20周年を迎える2013年2月24日にRuby2.0を出す予定です。大きな機能追加の凍結を今年8月に,機能の凍結を10月,コードの凍結を12月など,リリースに向けて間に合わない機能追加はやめるという思い切りの良いリリースプランで進めています。

リリースポリシーとして"Rubyらしからぬ"ことに互換性を重視して開発を行なっていて,matzが"100% compatible"と言っているとのことです。もし以前のコードが動かないということがあれば,連絡をすると2.0に修正を入れてもらえるかもしれません。

これまでにやったこと

そのなかでこれまでに作ったものとして以下の紹介を行いました。

  • Object単位ではなく,Class単位でのextendを実現するModule#prepend
  • immediate valueを実現し,GC発生を抑えて性能を向上させるFlonum
  • CallStackを便利に素早く扱える新しいバックトレースAPIであるcaller_locations
  • invokeするイベントを指定できる,バインディングされるまで生成を遅延させるTracePoint API
  • 非同期例外の発生有無を制御できるControllable asynchronous interrupts
  • 他,VMのソースコードを読んだことある人向けの細かい仕様の変更

特にFlonumについては詳しく説明しました。Flonumでは既存のFloatの仕様からexponentの範囲にある2bitを貰って実現したことや,上3bitでFlonumかどうかの判断ができること,bit patternが増えてどのように変わったのか,32bitでは既存通りの動きをすることなどを取り上げていました。

これからやること

次に2.0のリリースまでにこれからやることとして,VM(仮想マシン)の変更,プロファイラ/デバッガのサポート,今回入らなかった機能のC APIを実装することを挙げました。

VMの変更について,笹田さんがはじめにYARVをつくったときには,多くの最適化コンパイルオプションをつくったのですが,現在はすべて無効にしており,それを有効にしたいとのことでした。なぜ現在無効になっているかというと,効果が大きくでていないのと,どのような用途の時にどのオプションを指定すべきかをきちんと調査をして出さなければならないからと言います。

メソッド呼び出しの速度向上についても取り上げ,現在たらいまわし関数などで実行時間を測定したところ,VM実行時間の1/3近くがメソッド呼び出しにかかっているとし,ここの速度を向上したいとのことでした。

将来やりたいこと

最後に話す予定だったのは,将来的に実現したい,夢の話とのことでした。残念ながら今回は時間が足らずお話は聞けませんでしたが,スライドには書いてあるのでそちらをごらんくださいとのことでした。最後に「来年Ruby2.0がでますので,よろしくお願いします」とセッションを締めくくりました。

画像

画像

浦嶌啓太さん「Ruby on Rails: The Bad Parts」

永和システムマネジメントの浦嶌啓太さんによるRails開発におけるよくある問題と,その解決方法に関する発表です(スライド等はこちら

Railsアプリケーションの死因

Ruby on Railsは「Ride on Rails」⁠すなわちレールに乗った開発を行うことで気持ちよくWebアプリケーションを作ることができるフレームワークです。レールに乗ることで,理想としては動作する綺麗なコードが手に入るはずです。しかしながら,現実としては数ヶ月後には触れたくないようなコードとなってしまいます。テストコードがあったとしても,それはよいコードを書くためには十分ではありません。

浦嶌さんは,QA@ITの開発でRailsを採用する時,これまで死亡してきたRailsのアプリケーションの分析を行いました。すると,大きく3種類の死因があることが解りました。

ヘルパーは私たちを助けてくれない

ヘルパーはRailsのビューで必要になる共通的な処理を記述する場所です。しかし大きなアプリケーションではヘルパーに多くのメソッドが追加されていき,気がつくと巨大で管理できないコードができあがります。

この問題は,これまでRailsがビューと呼んでいるものはテンプレートでしかないというのが原因でした。ビューであればプレゼンテーションのロジックも含むべきですが,その部分がヘルパーとして分離しており,それを多くのテンプレートから利用しているためヘルパーが巨大になってしまうのです。また,プレゼンテーションとモデルを分離するためには仕方ない面もありますが,メソッドの引数にモデルを渡さなければならないインターフェイスはダサいです。

これらの問題を解決するために,active_decoratorプラグインを使います。active_decoratorを使うことで,モデルオブジェクトに動的にプレゼンテーションロジックを追加することができます。これまで,ビュー(テンプレート+ヘルパー)で次のように書かざるを得なかった記述を改善できます。

  • helperを利用:<%= link user %>
  • active_decoratorを利用:<%= user.link %>

もちろん,モデルに直接記述するわけではありません。デコレータを独立したクラスとして定義し,実行時に拡張されるしくみです。このしくみを導入することで,巨大化しがちなヘルパーを使わずに,スマートなプレゼンテーションロジックを記述できます。

ちなみに,似たプロダクトとしてDraperというのもあるそうです。細かい違いはあるようですが,基本的には同じ設計思想であり,モデルにプレゼンテーションロジックを差し込むプラグインです。これらのプラグインを使うことで,ヘルパーを使わずにきれいなビューに整理することができます。

パーシャルはパーシャルであってパーツではない

2つ目の死因はパーシャルです。例えば,質問の一覧を表示する機能のコントローラで,タグの一覧を取得するのは美しくありません。それはページデザインの都合であり,仕様変更により影響を受けやすいでしょう。このような場合,Railsではパーシャルとfilterを使うことが推奨されています。しかしながら,パーシャルは根本的な解決にはなっていません。もし,タグの一覧が他のページに移動するならば,パーシャルのコードも移動させる必要があります。パーシャルは「部分的なもの」でしかなく,部品(コンポーネント)ではないのです。

この問題を解決するために,Cellsというプラグインを使います。Cellsは,Railsにコンポーネントを提供します。簡単に言えば,テンプレート(ビュー)から直接モデルを取得してレンダリングできる「部品」です。

Cellsはコントローラと同じように実装します。コントローラからは完全に分離されてビューから呼び出されるため,独立したきれいな部品とすることができるとしました。

モデルになるには太りすぎている

最後の死因は,モデルです。⁠Skinny Controller, Fat Model」はよく知られた設計思想ですが,実践してみると500行を超えるようなモデルができあがります。もちろん,モデルにHTMLを生成するコードやSQLのコードがあるわけではありません。モデルに関連する処理を集約していった結果であり,本来あるべき姿ともいえます。しかしながら,太りすぎたモデルは,きれいなコードではありません。

この問題を解決する手段は,ライブラリの活用です。非常に手間のかかる処理であっても,ライブラリを活用すれば数行ですむため,モデルが太りすぎることを防止できます。しかしながら,いつでも利用できるライブラリがあるわけではありません。そこで,そのシステムに必要な,小さなライブラリを作ることを提案していました。汎用的にする必要はなく,タグ付けするといった小さな機能を抽象化し,ライブラリにまとめるだけです。このようにライブラリを活用することで,モデルをシンプルできれいなコードにできます。

また,ユーザの行動や振る舞いを抽象化したフレームワークとして「アクティビティレイヤー」という考え方を提案していました。アクティビティレイヤーとは,DCIのエッセンスを含んだ考え方で,複数のモデルが協調する必要がある処理をユーザのアクティビティとして抽象化したものです。例えば,ユーザが質問に答えた時には,幾つかのモデルに影響を与えますが,そのような場合質問のモデルではなく,⁠回答する」というアクティビティに着目し,コードをきれいに整理します。

最後に

まとめとして,Railsはよいフレームワークですが,乗るべき「レール」がないこともあります。そのような部分は,先人の作ったライブラリを使ったり,作ったりして対応しましょうと述べ,本セッションを結びました。

画像

画像

中村成洋さん「Rubyによる本気のGC」

CRubyのコミッタであり,もっぱらGCをメンテナンスしたり壊したりしているnariさんの発表です(スライド等はこちら)⁠nariさんは徹底改造G1GC実装編という本を無料配布しています。ぜひご覧ください。

Google TrendでGCという言葉を検索してみたところ,平日にくらべて休日の検索数が大きく減っていました。nariさんはこれを「休日に趣味でGCをいじる人が少ない」と解釈し,GCはまだまだ愛されていないと残念がっていました。

RubyでGC

今回のセッションをやろうと思った理由については,今までのRuby会議での発表がすべてC言語での話だったこと,卜部さんのブログ「ちゃんと調査すればCで書かなくてもいい実装はたくさんある」と書かれており,自分がC以外でGCを書けるか試されていると感じたことを挙げていました。

Ruby上でGCを実装した場合,Ruby上のGC自身がCでのGCの影響を受けるため性能評価しにくく,あまり意味がないため,違うアプローチを模索したそうです。

Meta-circular evaluator

そこで目をつけたのがpypy,rubiniusなどのMeta-circular evaluatorです。Meta-circular evaluatorとは自身のコードを用いて自身を評価する評価機で,今回はJavaでJavaが書けるJikesRVMに着目したと話します。

JikesRVMはGC部分がMMTkという別ライブラリに分けられているため,その部分を切り替えることでGCの振舞いを変えられます。これでJava言語ではGCを作り放題になったのですが,残念ながらRubyではありませんでした。

Regicide

そこでJRubyを使い,Regicide(国王殺し)というライブラリをつくりました。ちなみに,名前は「RとGとCで辞書をgrepしてそれらしいのを選んだ」と述べていました。

まとめ

Regicideを作ってみた結果,本当に欲しかったものはこういったものではなく,⁠GC実装に特化したミニ言語」であるかもしれないと気づいたため,今後はそちらを攻めていきたいとのことでした。

画像

画像

著者プロフィール

KaigiFreaks レポート班

KaigiFreaksとは,会場に来れなかった人にも雰囲気や内容を楽しんでもらえることをミッションとする特別編成チーム。配信班とレポート班の2班で構成される。レポート班の作業はエクストリームスポーツとして知られていたが,今回はその評判を覆すべく史上最大規模の編成で臨む。


前鼻毅(まえはなつよし)

Ruby札幌,アジャイル札幌,CLR/Hなど札幌のコミュニティで活動中。RICOH IT SOLUTIONSにてRubyやObjective-Cのコードを書いている。

twitter:http://twitter.com/sandinist


にく

北海道出身で沖縄や東京に住んだ後,今は札幌在住のプログラマ。コンサドーレ札幌が好き。Ruby,Emacsが心のメインツール。最近はHaskellを試している。

twitter:https://twitter.com/niku_name
blog:http://niku.name/


小野寺大地(おのでらだいち)

北海道大学大学院,一般社団法人LOCAL,Ruby札幌あたりで活動中。普段は複雑ネットワークの研究をしていて,肉チャーと二郎系ラーメンをこよなく愛している。

twitter:http://twitter.com/onodes
facebook:https://facebook.com/onodes


H.Hiro

北海道大学大学院在籍。Ruby札幌,札幌C++勉強会などで活動中。コレクションの要素数を数えるのに便利なライブラリ「multiset」などを作っている。Rubyで好きなものは「ブロック付きメソッド呼び出し」「Domain-Specific Languageの文化」。

twitter:http://twitter.com/h_hiro_


小玉直樹(こだまなおき)

生まれも育ちも札幌のプログラマ。RubyにハマってからはWebアプリを作るのが楽しくて日課になっている。1年ほど前からコミュニティ活動にも参加を開始し,素敵な技術者と出会える日々に感謝。

twitter:https://twitter.com/volpe_hd28v
blog:http://d.hatena.ne.jp/koda_hd28v/


うさみけんた

いまをときめく自宅警備員…だったのですが,Ruby会議の半月前に退職して東京に移住しました。Python札幌などでも活動。セキュリティ&プログラミングキャンプ2011言語クラスチューター。函数型言語の浅瀬で溺れる。

twitter:http://twitter.com/zonu_exe
blog:http://d.hatena.ne.jp/zonu_exe


すずきゆうすけ

札幌市に隣接する風の街・江別市で働く自営業。Ruby札幌にときどき顔を出す。Garage Labsにもときどき出没。プリキュアと朝ドラをこよなく愛し,日々変動する体重に怯えるごくごく普通のアラフォー。

twitter:https://twitter.com/yuskesuzki


みぃお

一般社団法人LOCALで主に活動中。お家でRubyをちょくちょく書いている。男の娘。お仕事はPHPでソーシャルゲームを作っている。

twitter:https://twitter.com/ayako119
homepage:http://miio.info/


永沼智比呂(ながぬまちひろ)

首の長いプログラマー。達人プログラマー読書会を主催したりしていた。Ruby札幌やSapporo.js,アジャイル札幌に参加。Ruby界隈の文化って面白い!

twitter:https://twitter.com/onjiro_mohyahya
blog:http://onjiro.blogspot.jp/


わたなべしゅうじ

札幌在住のプログラマ。札幌Javaコミュニティ代表。Java,Ruby,Python,JavaScriptなどを扱い,ユニットテストが好物。

twitter:https://twitter.com/shuji_w6e/
blog:http://d.hatena.ne.jp/shuji_w6e/


菅井祐太朗(すがいゆうたろう)

北海道から上京して一年。ようやく仕事でRubyを使えそう。Ruby札幌,Asakusa.rb,Yokohama.rbなどに顔を出している。

twitter:https://twitter.com/hokkai7go
blog:http://d.hatena.ne.jp/lncr_ct9a