Kishima's Hateda log

はてなダイアリー記事の保管庫

mrubyとMobiRuby

Ruby 技術

MobiRuby支援ってことで、Matt AimonettiさんのmrubyとMobiRubyについての記事を翻訳してみました。
英語力不足で文意が汲めてない部分があるかもしれませんが、何かあればご指摘頂ければ嬉しいです。*1
Apr 20th, 2012 "Mruby and MobiRuby"
http://matt.aimonetti.net/posts/2012/04/20/mruby-and-mobiruby/

2012/4/20
今日、二つの大きなRubyのニュースが日本でありました。

私がMacRubyプロジェクトに参加してるためか、このニュースについてどう思うかと聞かれることがありました。

mruby

mrubyは新しいプロジェクトではなくて、RiteVMに基づいたものです。これは経産省の援助*2と、Rubyの作者であるまつもとゆきひろ(Matz)氏によって主導されたもので、詳しくはMatzのRubyConf2010の基調講演で説明されたものです。
2011年11月にもmrubyについてMatzは述べています。そのときの話は記録されています。そこで彼は、現在のRubyのエコシステムについて、そしてなぜmrubyなのか、ということについて詳しく述べています。

mrubyの主な目的は、組み込み適用可能で、そのためにより小さなフットプリントを持ち、別のアプリケーションの中に入るようにコンパイル、リンクできるRubyを作ることであると、述べられています。

なかむらひろし氏はmrubyについてとても良い１行の定義を与えてます。

mrubyは、ゲーム開発者(Luaを使うのではなくて)、組み込みアプリケーション開発者(デバイス、TV、携帯)、少ないメモリフットプリントのサーバアプリケーション（インスタンスとしてJSを使うのではなくて）、をターゲットとしています。
私が個人的にmrubyについてとてもワクワクしています。それはまだここにはなく、そしてプロジェクトの価値を達成するためにやるべきことがまだたくさんありますが、これはまさしく正しい方向への大きな一歩です。このプロジェクトのもうひとつ本当に良い点は、我々皆が貢献でき、企業もそれぞれの必要性に基づいて実装を発展させることを許すOSSライセンスでリリースされていることです。

まとめ

mrubyはまだ発展途上ですが、前途有望なプロジェクトです。もう一つのRuby実装であることに加えて、ターゲットの利用者とプロジェクトのスコープはしっかり定められており、Rubyの制作者の先導と日本政府の援助があるという事実は、プロジェクトが成功することを信じるに足るものにしてくれます。Luaはシンプルな言語であり、その対象とするマーケットですでによく実装されていると述べていることから、Matzと彼のチームと日本政府は、この新しい技術を推奨し擁護していく計画をきっと持っています。彼らの幸運を祈ります。そして私も継続して注意深くこのプロジェクト見守っていくつもりです。

追記：mrubyの導入ガイドを書きました。
http://matt.aimonetti.net/posts/2012/04/25/getting-started-with-mruby/

MobiRuby

MobiRubyはJSでネイティブのiOSとAndroidアプリを書くことができるTitaniumプラットフォームで有名なAppceleratorで働く増井雄一郎氏によって開発されています。
MobiRubyは、Matz新実装に触発された開発者が行うmrubyの上に築かれた最初のデモンストレーションとなるものです。mrubyとよく似て、MobiRubyはOSSライセンスでリリースされますが、ライセンスとしてはApacheライセンスが選択されています。
これまでのところ、アナウンスされたのはコードサンプルとスクリーンショットです。これはHackersNewsのトップページを飾るに十分でした。作者はここ数ヶ月にうちに最初のバージョンをリリースすることを予定してるそうです。

いくらかの驚きがあったかもしれません。MacRubyといくつかの部分で競合するものですが、それでも私はこのような類のプロジェクトとまみえることを喜ばしく思ってます。

これは二つのことを示しています。

  • モバイル機器でRubyを内部に持つことについて強い興味があること
  • 技術的にこのようなことが可能であること

これはどちらも新しいことではありません。しばらく前からLua言語でiOSアプリを書くことは可能ですが、依然としてObjetice-Cを使っているのがiOS開発者の多数派です。Objective-Cを置き換えるため、実装に際した課題は何でしょうか？

置き換えた言語がCocoaのデザインと合わないかもしれない

iOS/OS Xアプリを開発するということは、あなたが提供されたライブラリ(Apple用語ではframeworksと呼ぶ)を使うのに時間を費やすということです。これらのframeworksは特有のパターン、しっかり定義された文法を持ち、通常とても一貫性がある/制約された方法で動作します。または、あなたの言語はかなり似ていて(Rubyのように)、そして移行は簡単です。そうでなければ、あなたはメンテナンスするためのラッパーを書き始める必要があるでしょう(titanium)。

ブリッジランタイム

２つのラインタイムを同時に持つのは、野心的ですが、効果的ではありません。これは、MacRubyについて、ブリッジであるRubyCocoaからの移行とObjective-Cランタイムで動作するRuby実装を持つことを、なぜAppleが後押ししたのかの理由のひとつです。これは他のことも認めることになります。MacRubyにおいて全てのオブジェクトは実際にObjective-Cオブジェクトであり、これはRubyコードから展開されたCocoaAPIなどを変換する必要がないことを意味しています。

サポート

これは多くの人にとって重要なことです。よい支援、サポートがない技術に基づく大きな次のプロジェクトを受け持つことを望まないことはしばしばあることです。もし異なる代替の実装を用いてあなたのアプリをビルドすることになり、突然開発者がうんざりして、異動または転職してしまうならば、何が起きるでしょう？　Apple/Googleが行うプラットフォームのアップデートに求められているようなアップデートについてはどうでしょうか？　これは代替を選ばない最も良い理由ではないと思われますが、"安全" を求める会社にとっては理解できる理由です。

Cocoa

iOS/OX Xアプリケーションを書くときに、Cocoa APIはその課題のおよそ90%を占めてます。強力で効果的なAPIですが、学習して使えるようになるのは、しばしば大変なことです。
誰かが参考書を書き、かつまたは大量の文章を変換し、メンテナンスすることが求められているおり、あなたはObjective-Cのみの事例たちとドキュメントテーションの課題を抱えています。
また、Appleから提供されている全てのツールを持っていても、それらのツールチェインを使っていないことがあるため、ツールのすべてを使うことができません。
率直に言って、MacRubyを使って何年も過ぎた後、このようなプロジェクトの実際の価値は簡単な文法ではなく、むしろ、繰り返し作業周りのラッパーと上位レベルのインタフェースの生成を簡単に行えることなのではないかと考えています。上手くデザインされたDSLのMIXを持ちつつも、なおかつネイティブオブジェクトへのアクセスはとても強力なものです。

Objective-C は発展している

Objective-Cは発展しており、ARCの導入でメモリ管理はとても簡単になりました。clangの最新版はObjective-Cでは、新しいリテラルとオブジェクトによる添字記法によって、文法がより便利になっています(詳しくはこちら)。実は、Objective-C の文法はますますRubyのものに近づいてきているのです。代替案を使うという選択肢を選ぶことはますます難しいものとなっています。

// character literals.
NSNumber *theLetterZ = @'Z';          // equivalent to [NSNumber numberWithChar:'Z']

// integral literals.
NSNumber *fortyTwo = @42;             // equivalent to [NSNumber numberWithInt:42]

// floating point literals.
NSNumber *piDouble = @3.1415926535;   // equivalent to [NSNumber numberWithDouble:3.1415926535]

// BOOL literals.
NSNumber *yesNumber = @YES;           // equivalent to [NSNumber numberWithBool:YES]

// Container literals
NSArray *array = @[ @"Hello", NSApp, [NSNumber numberWithInt:42] ];
id value = array[idx];

NSDictionary *dictionary = @{
  @"name" : NSUserName(),
  @"date" : [NSDate date],
  @"processInfo" : [NSProcessInfo processInfo]
};
id oldObject = dictionary[key];
dictionary[key] = newObject; // replace oldObject with newObject
性能

デバイスがどんどん強力になっているとはいえ、性能はしばしば重要な問題となります。Appleは彼らの言語のためのソリューションの性能を最適化しました。もしTitaniumアプリを開発してきたならば、性能は問題とすべき事柄の一つであり、優れた性能を得るためには回避策を探す必要がある場合があることを知っていると思います。

まとめ

MobiRubyがリリースされると、これらのことに基づいてよりよい判断をすることができると思います。しかしこれまでの経験から、封を開けたばかりの状態でのMobiRubyの文法と性能については非常に心配しています。ですが結果は時間が教えてくれるものですし、問題は常に改善されていくでしょう。Ruby on iOS/Android はエキサイティングです。ファーストベータを試すことを楽しみにしています。

*1:id:naohaq さんコメントありがとうございます

*2:経済産業省の地域イノベーション創出研究開発事業 http://www.meti.go.jp/policy/local_economy/tiikiinnovation/22fy_inoberd.html