Rubyの課題と取り組み -...

Rubyの課題と取り組み

前⽥ 修吾

ネットワーク応用通信研究所2008年9⽉11⽇

自⼰紹介

名前

前⽥ 修吾

所属

ネットワーク応用通信研究所(NaCl)

Rubyアソシエーション

01 77

Rubyとの出会い

1997年

JavaHouse ML

02 77

Rubyとの関わり

仕様提案・実装

ライブラリの開発

アプリケーションの開発

サーバ管理

03 77

仕様提案・実装

callcc

protected

トレースAPI (rb̲add̲event̲hook)

untrusted?

Time#strftime04 77

ライブラリの開発curses

readline最近、弊社⾼尾に引き継ぎ

monitor

net/ftp

net/imap05 77

アプリケーションの開発mod̲ruby

Apache用Rubyモジュール

erubyテキストへRubyを埋め込むツール

ximapdRubyで書いたIMAPサーバ

06 77

サーバ管理

carbon.ruby-lang.org公式Webサイト・MLなどのサービス

nitrogen.ruby-lang.org開発用SVNリポジトリを提供

07 77

本⽇のテーマ

Rubyの課題と取り組み

08 77

背景

状況の変化

09 77

10年前

Rubyを仕事で使うといえばちょっとしたスクリプトで…

プロトタイピングに…

無知なお客様に内緒で…

むしろ仕事をさぼって趣味で…

10 77

現在

Rubyを仕事で使うといえばRuby on Rails

開発⾔語として普通に採用

11 77

状況の変化

趣味 → 仕事

要求が過酷にちょっと前のLinuxに似た状況?

12 77

課題と取り組み

性能

互換性

脆弱性

ドキュメント

13 77

性能

Rubyは遅い

14 77

Rubyは遅い

15 77

よくある反論

PCより開発者の時間の⽅が重要

たいていIOがボトルネックだよ

ハードウェアの性能も上がってるし

スケールアウトすればいいじゃん

16 77

結論

Rubyが遅いのは事実

17 77

遅い理由

関数がないすべてメソッド → 動的束縛

静的型がない

既存のクラスを再定義可能オープンクラス

18 77

関数がない

# factは一見関数に見えるが、実はメソッドdef fact(n) if n < 2 1 else n * fact(n-1) endendp fact(100)

19 77

静的型がない

# xにどんなオブジェクトが来るかは、# 実行時までわからないdef foo(x) ...endfoo(123)foo("123")foo([1, 2, 3])

20 77

オープンクラス

p 1 + 1 #=> 2class Fixnum def +(other) return self * other endendp 1 + 1 #=> 1

21 77

オープンクラスの例外

class String def =~(re) return nil endend# 右辺が正規表現リテラルの時は再定義不可p "foo" =~ /foo/ #=> 0re = /foo/# 変数だと再定義可能p "foo" =~ re #=> nil

22 77

⾼速化の取り組み

インタプリタの刷新by ささださん

バイトコードインタプリタ

各種最適化

23 77

バイトコードインタプリタ従来のRuby処理系(Ruby 1.8)

スクリプトを構⽂⽊にコンパイル後、構⽂⽊を再帰的に辿りながらプログラムを実⾏

新Ruby処理系(Ruby 1.9)スクリプトをバイトコードにコンパイルして、実⾏

24 77

各種最適化(1)

ダイレクトスレッデッドコード

覗き⽳最適化

インラインメソッドキャッシュ

インライン定数キャッシュ

特化命令25 77

各種最適化(2)

命令融合

オペランド融合

スタックキャッシング

末尾呼び出しの最適化

26 77

デモ

ベンチマーク

27 77

互換性

バージョン間の互換性

処理系間の互換性

28 77

バージョン間の互換性

アップグレードしたら動かなくなった

とくにRails

29 77

例

クラスコピー時のクラス変数の挙動

cgi.rbのファイル名の処理

30 77

処理系間の互換性

複数の処理系JRuby・IronRuby・Rubinius・MagLev

いずれも基本的にRuby 1.8互換しかし、Ruby 1.8の仕様が不明確

31 77

取り組み

RubySpec

⾊々な環境でのテスト

32 77

RubySpec

実⾏可能な仕様

Rubiniusの⼀部としてスタート

MSpecを使用RSpec風のフレームワーク

リリース時のテストに利用33 77

記述例

describe "The if expression" do it "evaluates body if expression is true" do a = [] if true a << 123 end a.should == [123] end ...end

34 77

⾊々な環境でのテスト

現在はIA32 Linuxが中⼼

⾊々な環境でのテストを検討中SPARCとかPPCとかAlphaとか

SolarisとかHP-UXとか

35 77

脆弱性

脆弱性の対応が今⼀つ

36 77

最近の脆弱性REXMLのDoS脆弱性

2008年8⽉23⽇公開

Rubyに複数の脆弱性2008年8⽉8⽇公開

任意のコードが実⾏される脆弱性?2008年6⽉20⽇公開

37 77

問題

対応が遅い

対応が不完全

リリースにバグ

情報の公開が不⼗分

38 77

検討事項

判断基準

対応⽅針

体制

39 77

判断基準

そもそも脆弱性かどうか

脆弱性の深刻さ

40 77

そもそも脆弱性かどうか

SEGVは脆弱性?

処理が遅いのは脆弱性?

メモリリークは脆弱性?

41 77

脆弱性の深刻さ

アプリケーションによる

判断が難しい

42 77

対応⽅針

リリース

パッチ

何もしない

43 77

リリース

保守ブランチから新しいリリース1.8.x-py

44 77

Rubyのブランチtrunk(1.9)

開発ブランチ(というか幹)・何でもアリ

ruby̲1̲8準開発ブランチ・非互換な修正はNG

ruby̲1̲8̲x保守ブランチ・バグ修正のみ

45 77

リリースのメリット

ユーザが利用しやすい

46 77

リリースのデメリット

リリース作業が大変あまり頻繁だと厳しい

修正箇所が他の修正に埋もれがち

デグレードの危険性

47 77

デグレードの危険性

脆弱性対応の場合は緊急リリース

保守ブランチの修正は意外に多いすべてのバグ修正が適用されるため

⼗分な確認が難しい

48 77

パッチ

前回のリリースへのパッチの提供

49 77

パッチのメリット

修正箇所がわかりやすい

他の修正の影響がない

50 77

パッチのデメリット

ユーザによっては適用が難しい

どのバージョンへのパッチにするか悩ましい

51 77

何もしない

いっそのこと全部普通の修正として扱うという案も…

52 77

体制

現状はボランティアによる対応

本業が忙しいと対応が滞りがち

53 77

取り組み

保守ブランチの安定化

情報公開

モンキーパッチ

54 77

保守ブランチの安定化現状はすべてのバグ修正を適用

たまに壊れることがある

緊急リリースにあたるとまずい

1.8.xに対する修正を限定?判断が難しい

→ 代りに修正候補を事前に公開55 77

情報公開

なるべく早期に

⼗分な情報をまだまだ不⼗分

関連したコミットのリビジョン情報?

56 77

モンキーパッチ

実⾏時にライブラリを変更するパッチ

REXMLの脆弱性の時に提供

57 77

モンキーパッチのメリット

適用が簡単

暫定的な対応を⼊れやすい

58 77

デメリット

アプリケーションごとに適用が必要

Cレベルの修正は適用しにくい

59 77

ドキュメント

質・量とも不⼗分(⽇本語)

「ソースがドキュメントだ。 バグも完全に記述されている」

60 77

リファレンスマニュアル英語リファレンスマニュアル

RDoc

ソースにコメントとして記述・英語

⽇本語リファレンスマニュアルWiki

だれが書いたかわからない61 77

⾔語仕様

⽂書化された仕様がない

62 77

取り組み

るりま

標準化

63 77

るりま

Rubyリファレンスマニュアル刷新計画

⻘⽊さん・okkezさんが中⼼

64 77

改善点

しっかりとしたプロジェクト体制Wiki → Subversion・Redmine

品質の⾼いドキュメント

より厳密でメタデータを取りやすいファイルフォーマット

65 77

進捗状況

組み込みライブラリはほぼ網羅

標準ライブラリ全体でも50%以上ただしtkとsoapを除く

66 77

松江の取り組み

Ruby勉強会 in 松江るりまの読み書き

勉強しながらプロジェクトに貢献

弊社⾼尾主宰

67 77

標準化

IPA公募事業

⾔語仕様の⽂書化

68 77

IPA公募事業

「Rubyの国際標準化に関する調査の請負契約」に係る公募

標準仕様の草案作成が主な内容

弊社も応募現在結果待ち…

69 77

背景

政府調達

安定した仕様へのニーズ

70 77

政府調達

政府調達の基本指針総務省

オープンな標準特定製品の名指しを避ける

71 77

安定した仕様へのニーズ

処理系の開発

⼈材育成テキスト

試験問題

72 77

目標

ISOにおける標準化

開発の妨げとならないような配慮

コミュニティなどへの配慮

将来的な自⽴的維持

73 77

弊社の提案内容

仕様は実装(Ruby 1.8)から抽出Rubyの開発自体は今まで通り

最⼩限の範囲の仕様を⽂書化みんなが合意できる範囲に

オープンなMLでの議論74 77

標準化プロセス

Linuxが参考になるかも実装からの仕様抽出

開発プロセスとの明確な分離

とにかく開発の妨げになることだけは避けたい

75 77

まとめ

まだまだ課題はたくさん

ご協⼒をお願いします

76 77

おわり

ご静聴ありがとうございました

77 77