発展課題の案を示します。これ以外にも、興味のあるテーマを自分で見つけてくれる分には大歓迎です。
Redmine https://bugs.ruby-lang.org/projects/ruby-trunk/issues で未解決のバグチケットを見つけ、調査してみましょう。自分が興味のある、もしくは自分が困っているチケットですと、やる気が出ると思います。
再現手順が曖昧なチケットでは、再現手順を見つけるだけでも十分に助かります(再現手順が見つかれば、もう半分以上、解けたようなものです)。ぜひ挑戦してみて下さい。
Ruby に足りないと思っている機能を、これを機会に追加してみましょう。
好きな文法を加えてみても、面白いと思います。
MRI にはドキュメントが不足しています。自分が知りたいと思い、そしてその資料がないもの(例えば拡張ライブラリのための API ドキュメント)などがあれば、 ソースコードなどを解読し、ドキュメントを追加してみましょう。
例えば 【緩募】Rubyリファレンス・マニュアル=るりまで不足中のサンプルコード8,000件を一緒に作りませんか? などが参考になります。
6章を参考に、C レベル、Ruby レベルでカバレッジを計測してみましょう。 そして、カバレッジが足りないところにテストを追加してみましょう。
ruby -w
で実行すると、普段は出ない警告が出るようになります。例えば、
def foo
end
のように、インデントがずれていると警告が出ます。おそらく、あまり好ましくない自体が起こっているのでは無いかと思います。
そこで、-w
で make test-all
を実行してみて、警告が出るかどうか試してみましょう。そして、警告が出たら、でなくなるようにテストを改善してみましょう。
前項の続きです。自分が「こんな場面では警告を出して欲しいな」という例を考え(例えば、Refinements は使うべきでは無いので、利用時に警告を出すとか)、警告を出すように Ruby を改造してみましょう。
激しい警告は Rubocop などのツールの役目かもしれません。
現在、ビルドした Ruby で Gem など、外部ライブラリを、ビルドした Ruby で、他の影響を与えないで適切にテストする方法がありません。 というのも、Gem の場合、Gem のテストのために他の Gem を利用したりする必要があるためです。 区切られた環境(サンドボックス)を用いることで
<rubyci.org> や <ci.rvm.jp> のテスト環境の現状を調べ、足りない機能を検討してみましょう。また、できれば整備を手伝ってください。
VM をいじることで、外部から実行状況を知る方法を検討してみましょう。
例えば、Ruby の VM はスタックマシンなので、そのスタックの状況を図で表示するとか、特定のタイミングで音を出すようにするとか。
(5) で紹介したりしなかったりしたツールを使って、自分がよく使う Ruby アプリケーションの性能測定をしてみましょう。 可能なら、性能改善のための方法を実装してみましょう。
実行時に GC パラメータを変更するパッチが提案されているのですが https://bugs.ruby-lang.org/issues/13388 実際にこれを使うと良いことがあるかどうかがわかりません。 まずは Ruby の GC パラメータにどのようなものがあるかを確認し、実際にお持ちのアプリケーションで、実行時の GC パラメータチューニングが役に立つことがあるか、調べてコメントしてみてください。
5章を参考に、ベンチマークを追加してみましょう。 そして、他のメソッドに比べて遅いな? という場所を探して、改善するコードを書いてみましょう。
ruby/debug_counter.[ch]
に、デバッグカウンタという仕組みが入っています。これは、ある処理が何回実行されたか、調べるための仕組みです(DTrace のしょぼい版です)。
カウンタは、実行時では無く、コンパイル時に埋め込まれます。デフォルトではオフになっています。
好きなカウンタを作って、MRI の挙動を調べてみましょう。