Pat Shaughnessy「rubymotionクリエータに一問一答（前編）」
rubysource 2012.2.13のエントリ
RubySource | Getting To Know RubyMotion With Laurent SansonettiRubySource
- id:naoyaさんのエントリ経由で知った
- 長編で二部構成になってる
- プルリクエストもらえそうなビルドシステム（rubyで書いた）だけオープンソース
- プリリクエスト期待薄だと実体験が教えるコンパイラとランタイムはクローズドにし、プロジェクトの資金にもなってる、とか
- それぞれ違う理由でrubymotionからrequireとevalを削ったこととか、
以下斜め読んだ内容
はじめに
- 2012.4以来rubyコミュニティの心を掴んだrubymotion
- 初めてiosプラットフォームでrubyで書けるようになった
- 古式ゆかしいobjective-cもxcodeも一から勉強しなくてよくなった
- rubyとコマンドラインツールがそれに取って代わった
- インタビュー前編；ベーシック
- インタビュー後編：テクニカル
初のrubymotionカンファレンス
- Q：RubyMotion#INSPECT2013の話から
- A：
- リリース後半年したら閃いた。rubymotion小規模イベント
- 最近bubbleconfにスピーカとして呼ばれたので話をしてきた
- 動画ある
- スタートアップ向けカンファレンス
- rubymotion立ち上げる前に自分が抱いた恐れや不安とかをしゃべってきた
- Nihn Buiがオーガナイザ。周りに助けられた切り盛りしてた。
- 俺もやってみたい、となった
- Q：カンファレンス立ち上げるなんて大変そう
- A：
- Nihnほど大掛かりじゃないし
- 150人くらいの規模でよかった
- はじめはrubymotionユーザの多いアメリカでやろうかと思ってた
- 最初のカンファレンスは自分に特別なものとなるはず、と色々考えた
- ホーム（＝ベルギー）でやることにした
- Q：なんでベルギー開催？
- A：
- 負担がより少ない
- できるだけ小さくやりたかった
- 顔を見ながら話したりハックできる場所にしたかった
- カネ目当てじゃない。今回は赤字になるはず
- 楽しむために、rubymotionの宣伝のためにやる
- 実はミニツアー付きカンファレンス
- チョコレート工場とビール工場見学ツアー。Brusselsらしいもの
- スピーカの数のリストは大きくなった。が、持ち時間は30分。間の時間もゆったり取った
- 会場は１つだけ。全員そこで登壇
- rubymotionコミュで有名なスピーカーもいる
- 37signalsのNick Quaranto
- HerokuのMatt Thompson
- 知名度高くないがrubymotionコミュで凄い仕事してる人たちもスピーカに参加してくれてる
- いいカンファレンスになるはず
rubymotionのはじまり
- Q：Appleで働いてたらしいけど
- A：
- Q：rubymotionのスタッフ
- A：
そもそもrubymotionとは
- Q：rubymotionnとは。。。
- A：
- 要は、rubyでios開発するためのツールチェーン
- objective-cランタイム上のruby実装
- iosコアフレームワークの上に構築
- rubymotionのobject model実装
- objectvie-cランタイムを使ってる
- 例えばrubymotionでエンジニアがクラス、オブジェクト、メソッドを作ったとする
- そのときに実際にはobjective-cのオブジェクト、クラス、メソッドを触ってる
- rubyからのブリッジとかミドルウェアは存在しない
- エンジニアは全てのios apiにダイレクトにアクセスしてる
- Q：objective-cでの開発と全く同じシステムを使ってる？
- A：
- YES
- objective-cランタイムは実際には、小規模なcライブラリ
- ios開発者は自由にこのライブラリを利用できる
- rubymotionで自分がやってることはまさにそれ
- rubymotionアプリは、objective-cアプリと同じ流儀でランタイムAPIを叩く
- rubymotionではiosのcoreframeworksを使ってネイティブのクラスを実装してる
- 例えばrubymotionのStringクラス
- FoundationフレームワークのNSMutableStringのサブクラスとして実装されてる
- Stringクラスは普段rubyを書いてるのと同じ感覚。違いはほぼゼロ
- rubymotionが裏側でobjective-cでstringを操作してるのと同じ状態を作ってる
- どういうことか
- 例えばrubyでstringを作る。
- このstringがobjective-c apiに渡される。変換とか挟まない
- rubymotionのオブジェクトモデルでは、objective-cのランタイムを使う
- rubymotionのクラス実装にはFoundationフレームワークを使う
- Q：
- rubyのString#upcaseに相当するものがobjective-cには無い
- 実装しないといけなかったはず
- A：
- Q：それ以外のrubymotionの構成要素
- A：
- Q：デバイスのobjective-cランタイム上でrubymotionランタイムが走る？
- A：
- YES
- オブジェクトモデルはobjective-cランタイム使う
- rubymotionランタイムがある。1MBくらい。静的にリンクされる
- rubymotionのランタイムではネイティブにあるクラスだけでなく、ネイティブにない機能も実装した
- 例１．objective-cには、mixinという概念がない
- 実装した
- 例２。あるクラスへインスタンス変数を動的にセットすることがobjective-cではできない
- そのためにworkaround入れた
rubymotion v.s. MRI
- Q：rubymotionがベースにしてるrubyのバージョン
- A：
- Q：rubyエンジニアがrubymotion始めるにあたり、気を付けるべき違いは？
- A：まずrequireが無い
- Q：じゃあrubymotionでのライブラリの読み込み方法は？
- A：
- rubymotionでは静的にコンパイルされる
- コンパイル時に必要なファイルをコンパイラに伝える必要がある
- ランタイム時にモジュール読込むとかしない
- Q：cで言うinclude、あるいはMakefileみたいな話し
- A：
- YES
- 最近ビルドシステムはどんどん賢くなってる
- rubymotionでは新規プロジェクト作ると「app.」ディレクトリができる
- 「.app」以下にrbファイル作ってく
- 作法としては、1クラス1ファイルがオススメ
- ビルドシステムは.app以下の全てのrbファイルを読込んで、依存関係を調べる
- 例。クラスFooが定義されたファイル、クラスBarが定義されたファイル、BarはFooを継承してる、とする
- ビルドシステムは継承関係検知して、FooをコンパイルしてからBarをコンパイルする
- ランタイム上ではクラスFooがクラスBarより先に生成される
- こんなわけで通常はrequireがいらない
- Q：依存関係の検知は全自動？
- A：
- やらなかったこと
- コンパイラへのヒント的なものとしてrequireを実装する
- こういう選択肢はあり得たがやらなかった。筋悪いと思う
- そもそもrequireはKernelクラスのメソッド。引数渡して使うもの
- requireはキーワードじゃないし、基本型扱いする必要がない
- requireには定義済みのstringを渡すことができる
- こんなrequireの挙動にrubymotionのコンパイラは対処しないといけない
- この手のエッジケースに対応するのはいい考えだと思わない
- rubymotionのビルドシステムはコードをパースし依存関係を検知しようとする
- rubymotionでrequire使うと例外がスローされる
- requireを別にすれば、rubyとrubymotionの違いはとても小さい
- あとevalも無い
- evalサポートはインタプリタ同梱するのと同じ
- インタプリタ同梱のアプリをリリースすることにつながる
- やらなかったこと
- Q：インタプリタ同梱はapple的にNGでは？
- A：
- Q：evalを外すことでrubymotionは大丈夫ですとappleに伝えてる、と
- A：
- あと、ハードウェア性能は低いので、ランタイム時にコードをevalするのはいい考えだと思わない
- Q：Kernel#eval以外、instance_evalとかclass_evalとかは？
- A：
- サポートしてる。それ以外のeval系メソッドは動く、はず
- メタプログラミングに使われる類のものは全部いける
- Q：requireとevalがないだけであとはMRIと同じ？
- A：
- まとめるとこんな感じ
- require無し。ビルドシステムあるから
- evalは動かない
- Proc#bindingは削除された
- FixnumとFloatでは、演算子オーバーライドできない
- まとめるとこんな感じ
rubymotinはオープンソースでない件
- Q：rubymotionはオープンソース？プロプライエタリ？
- Q：rubymotionがお客に提供できるコア技術はコンパイラ？
- A；
- Q：rubymotionはrailsのようにはいかない。サクっと直したり機能足したりとかできる領域じゃない、と
- A：
- Q：この仕組みでやりたいことを自分のペースでやれてる、と
- A：YES。というか、自分にはこれが唯一のやり方だった
今後
- Q：rubymotionの今後
- A：
- いいにくい部分
- rubymotionは急速に成長してる
- リリースしてから８ヶ月しか経ってない
- 現時点で、色々な選択肢が見えてきた。重要な機能追加、等々
- リソースは有限。決めて行かないといけない
- ツールチェーンの改善。これは多分今後やると言えそうなこと。
- コマンドラインベースしかない。これで大抵のユーザは使えてる
- IDEラブな人たちもいる。いまJetBrainsと一緒に仕事してる
- RubyMineのrubymotionサポートは良い感じになってる
- RubyMIne内部でrubymotionのデバッグができる
- このまま一緒に仕事続けたら、rubymotionユーザのためのIDEが作れるかも、と思ってる
- ios以外のプラットフォームもサポートしてほしいというリクエストは沢山もらってる
後編
