デブサミ2013の「【14-A-3】Ruby2.0（http://event.shoeisha.jp/detail/1/session/5/／増井雄一郎さんのセッション）」のメモ。

当日の資料はこちら→
mruby & MobiRuby // Speaker Deck

またtogetterまとめはこちら→デブサミ2013 【14-A-5】RubyでiOS/Androidアプリを作るMobiRuby Twitterまとめ

増井さんの自己紹介

ruby自体は98年ぐらいからずっと使っているが、コントリビュートはしていなかった。
過去に携わったプロダクトはPukiWiki等。

現在の所属はFrogApps。アプリを開発しているが、これはネイティブ。
その前はTitaniumに所属していた。

mruby（≠MobiRuby）について

mrubyは、mobirubyの基礎にあたる。

mrubyはrubyとは別系統で、メモリやCPUパワーが少ない環境向けの実装。
まつもとさんのrubyは、mrubyとの対比で「CRuby」と呼ばれる。

mrubyはCRubyのサブセット。
rubyが標準化された仕様（ISO/JIS）に準拠しているが、パイプの入出力やソケットやスレッドといった機能は搭載されていない。

mrubyはコンパクトな実装であり、その分自由度が高く、OSやCPUへ依存しない。
POSIX対応は不要で、C99（C仕様のコンパイラ）があればビルドできる。

ビルド時にConfigureがいろいろと可能。
例えば組み込み用途でそもそも使用しない機能は、Configureで切り離してしまうことで、より少ないメモリで動作させられるmrubyをビルドすることができる。
他には、テーブルのアルゴリズムをhashとlistから選択できたりとか。
　
mrubyのターゲットは組み込み。
また、アプリケーションへの組み込みも簡単にできるようになっている。アプリケーションへのバンドル。
　
mrubyのApacheモジュールによって、「Apacheのモジュールをmrubyで記述できる」ようになっている。
これによって、従来Cなどで作成しなければならなかったApacheモジュールをmrubyで手軽に実装できるようになっている。

mrubyが他のruby環境と大きく違うのは、複数のVMを起動できること。

逆にスレッド周りは問題があって、マルチスレッドになっていない。ただこの点は複数のVMに多少はカバーできる。
　
mrubyとCRubyの違いの一つに、拡張用のモジュールの互換性がない。つまりCRuby用に多数提供されているモジュールをmrubyで使うことはできない。

rubyでプログラムを書く時は大抵rubygemsを使う。
これまでmrubyにはそうした仕組みがなかったが、Daniel(@bovi）が拡張パッケージ（mrbgems）を作った。

mrubyはCRubyに比べて機能が少ないので、OAuthを実装しようとするとDigest（MD5）が生成できなくて困ったりするが、そうした機能を公開されたライブラリから取り込めるようになった。mrubyのライブラリは5人ぐらいしか手掛けていない。

CRubyは非常に多くの人が携わってきたので、今から新たに入って貢献するのは難しい。mrubyは敷居がまだ低いので、mrubyの開発を手伝ってもらえると嬉しい。

MobiRuby

mrubyを使ってiPhoneやAndroidのアプリを作れるようにしたいというのがmobiruby。

mrubyのソースを昨年まつもとさんから頂戴することができて、それはiPhoneでも使えそうだということがわかって、開発を始めた。

MobiRubyのおさらい

ライセンスはmrubyと同じくMITライセンスで、ほぼなんでも自由。
現在はiPhoneの開発環境のみ。
Android版も到達可能性は確認しているので、確認でき次第公開したいと思っている。

「Objective-Cで使える機能はほぼすべてmobirubyから使える」ことを目標に作っている。
ツールキットを使うと制約が発生して、例えばある程度作った時点で「実は使えない機能がある」とか「パフォーマンスが出ない」ということがあるのがイヤだったので、そうならないことを目指している。

Vision

Rubyの力をモバイルデバイスに届けたい。
メタプログラミングがrubyの力。自由に言語内言語を作れたりするのが、気持ちよく開発する上で重要。

似たようなツールキットはある。Luaとか。
ただ、あまり流行っていない。

Luaが流行っていない一つの理由は、DSL（言語内言語）を書きにくいこと。
Objective-C・Cocoaの文化と別の言語の間には差があって、それをフレームワークが吸収しないとできない。
mobirubyではそこをうまくラッピングしたい。
SQLをラッピングしているRailsのように、Cocoaをラッピングするのがmobiruby。

今の版ではObjective-Cが全面に出たコードだが、これを土台にして次の版ではよりrubyらしいコードに持っていこうとしている。

MobiRubyのスタック

mruby-cfunc

rubyからCのファンクションを叩くためのライブラリ。
例えばCのputsを叩くとか。

今まではＣ言語でブリッジとなるライブラリを作らないと呼べなかったが、この機能によって原理上は（スレッド以外は）mobirubyのレイヤだけでCを使った機能を実装できる。

そしてObjective-CはCからも呼び出せる作りになっている。
従って、mruby-cfuncを使うことでCocoaの機能のほぼすべてを叩けるようになる。

ただ、すべてをこの呼び出しで実装すると実行速度に難が出るので、必要なところは一部Cで書いてそれをコールするのが実際のところか。

メモリ管理

Objective-Cはリファレンスカウント、mrubyはMark&Sweepによってメモリ管理をしていて、両者は等価ではないのでうまく解決しないと行けない。
今、ここがネックになって速度が遅いという問題はわかっている。

mobiruby-common

mruby（mobirubyでなく）で最初に驚くのは、外部のスクリプトを読み込めないこと。
これはそもそもmrubyがI/Oの機能をサポートしていないからで、I/Oがないから必然的に外部ライブラリが読み込めない。
これでは使いにくいので、mobirubyではrequireできる実装を追加している。

mobiruby-ios

githubに置いてある。（たぶんここ→https://github.com/mobiruby/mobiruby-ios）
最新版のXCodeを使えばすぐ動く。
　
現在のバージョンはObjective-Cをそのまま持ってきた形に近いコードになっているが、これはあくまで土台。
次のバージョンでは、少なくともコード補完がなくてもコードが書ける程度のAPIを整備したいと考えている。

まとめ

mobirubyのRoad map

・Cocoa bridge→終わった
　　・Fix bugs, improvement
・パッケージング
・ドキュメント

ここまでを2013/Q1に実現しようと思っていて、時間もかけているのだが、いかんせんプライベートの中で開発しているので遅れていて、上記の「Cocoa bridge」のFix bugsまでをQ1までに完了するスケジュールで考えている。

AppleがMobiRubyでの実装を許すか

一時期揉めていたが、現在のAppleは許可する方針になっている。
但し「実行時に外部コードをダウンロードしないこと」「private APIを使用しないこと」という条件が課せられている。

ここでprivate APIの定義が不明で、ヘッダに存在するがドキュメントに記載されていないAPIがあって、それがprivateかどうかの区別が客観的につかない。
（単にAppleのドキュメント整備遅れのような気がしている）

判断が付かないのでAppStoreに実際にmobirubyで作ったアプリをリリースして確認しているが、今のところ弾かれたことはないので問題なさそうとは思っている。

Objective-C側に問題があって、オブジェクトのプロパティを書けるが読めないという問題が見つかっているが、それ以外は動作している。
C側については1000ぐらいのテストが終わっていて相応の品質になっている、順次Objective-Cのほうも進める。
　
あと、mrubyは正規表現がサポートされていないが、これができるようになれば。

メリット

Mac版Ruby実装のRubyMotion？とよく比較される。
mrubyの利点は、本家であるmatz（まつもとさん）が関わっていること。
　・mrbgems。
　・MIT license。
　・非常にコンパクト。今は4000Lines未満、v1の時点でもせいぜい5〜6KL。

デメリット

不安定。
クラスが少ない／Gemsを探さないといけない。
バックトレースの機能がなくて、Exceptionが起こったことはわかるがどこで起こったかがわからない。mruby版で改善しているのもあるし、どうやって（バックトレース用の）口を作るかまつもとさんと話したりもしている。

Action!

mobirubyを作った経緯。

増井さんは元々Titanium mobileにいた。ちょうど本社へ出張したとき（その直前にまつもとさんからmrubyのソースコードを入手して飛行機の中で確認していた）、CEOに会ってmobiruby（となるもの）をOSSで作りたいと言ったら意外にあっさりOKが出た。
普通、自社（Titanium）の競合になるプロダクトをOSSで作りたいと言ったら首を切られても仕方がないと思うが、CEOは元々OSSに携わられていたこともあって理解があった。

帰ってきて作業に入った。リリースの前日、不安になって本当にリリースして首になったりしないかCEOに確認したが、OKという話だった。

JavaScriptも好きだが、まあまあ好き程度だったので本当に好きなrubyをやりたかった。
世界に向けて自分のポートフォリオになるようなプロダクトを作りたかった。

---

ここまで。