読者です 読者をやめる 読者になる 読者になる

以下斜め読んだ内容

pseudo translation of useful posts, book reviews, remarks,etc. twitter: feeddict

Pat Shaughnessy「rubymotionクリエータに一問一答(前編)」

斜め読み

rubysource 2012.2.13のエントリ

RubySource | Getting To Know RubyMotion With Laurent SansonettiRubySource

以下斜め読んだ内容

はじめに

  • 2012.4以来rubyコミュニティの心を掴んだrubymotion
  • 初めてiosプラットフォームでrubyで書けるようになった
  • 古式ゆかしいobjective-cxcodeも一から勉強しなくてよくなった
    • (補足)コメント欄で「ミスリードiosapiは勉強しないとダメだろ」とツッコミ入って、「apiもそうだしsdkの知識はいるね」と補足いてる
  • rubyとコマンドラインツールがそれに取って代わった
  • インタビュー前編;ベーシック
    • rubymotion:何?何するもの?使い方は?
    • ios甩にruby書くこと、普通のrubyアプリ書くこと。どこが違う?
  • インタビュー後編:テクニカル
    • rubymotionの中身
    • LLVMの使われ方
    • rubyコードをstaticな実行ファイルにコンパイル
    • rubymotionの挙動:macruby,rubiniusとの違い

初のrubymotionカンファレンス

  • Q:RubyMotion#INSPECT2013の話から
  • A:
  • Q:カンファレンス立ち上げるなんて大変そう
  • A:
    • Nihnほど大掛かりじゃないし
    • 150人くらいの規模でよかった
    • はじめはrubymotionユーザの多いアメリカでやろうかと思ってた
    • 最初のカンファレンスは自分に特別なものとなるはず、と色々考えた
    • ホーム(=ベルギー)でやることにした
  • Q:なんでベルギー開催?
  • A:
    • 負担がより少ない
    • できるだけ小さくやりたかった
    • 顔を見ながら話したりハックできる場所にしたかった
    • カネ目当てじゃない。今回は赤字になるはず
    • 楽しむために、rubymotionの宣伝のためにやる
    • 実はミニツアー付きカンファレンス
    • チョコレート工場とビール工場見学ツアー。Brusselsらしいもの
    • スピーカの数のリストは大きくなった。が、持ち時間は30分。間の時間もゆったり取った
    • 会場は1つだけ。全員そこで登壇
    • rubymotionコミュで有名なスピーカーもいる
    • 37signalsのNick Quaranto
    • HerokuのMatt Thompson
    • 知名度高くないがrubymotionコミュで凄い仕事してる人たちもスピーカに参加してくれてる
    • いいカンファレンスになるはず

rubymotionのはじまり

  • Q:Appleで働いてたらしいけど
  • A:
    • 7年働いた
    • macrubyが自分がやった最後のプロジェクト
    • appleには珍しいオープンソースプロジェクト
    • apple上層部は今後macrubyをバックアップするつもりがなかった
    • ってことで、これからどうしよう?、となった
      • apple残留(=別プロジェクト参加)、転職、起業
      • よーく考えて、会社作るいい機会と結論だした
    • 当時子供は4ヶ月、Californiaに住んでたし、ヨーロッパに戻りたかった
  • Q:rubymotionのスタッフ
  • A:

そもそもrubymotionとは

  • Q:rubymotionnとは。。。
  • A:
    • 要は、rubyios開発するためのツールチェーン
    • 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のランタイムではネイティブにあるクラスだけでなく、ネイティブにない機能も実装した
    • 例1.objective-cには、mixinという概念がない
      • 実装した
    • 例2。あるクラスへインスタンス変数を動的にセットすることがobjective-cではできない
      • そのためにworkaround入れた

rubymotion v.s. MRI

  • Q:rubymotionがベースにしてるrubyのバージョン
  • A:
    • ruby1.9準拠
    • rubymotionはmacrubyのフォークとも言える
    • macrubyはrubyspec準拠にエネルギー使ってきた
    • rubyspecはruby使用の実行可能なセット
    • rubyspecはrubiniusから派生したプロジェクト
    • rubymotion始めた時rubyspecは1.9.1だった
    • まずmacrubyをフォークしたけど、その後rubyspecの動向は追ってない
    • rubymotionから削られたrubyの機能
      • ある
      • rubymotionが静的にコンパイルされる点を考慮した
  • 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も無い
    • インタプリタ同梱のアプリをリリースすることにつながる
  • 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;
    • YES。ていうか、コンパイラとランタイム
    • ruby実装はクローズド
    • ここは色々考えた
    • 全部オープンソースにすべきか、部分的にオープンソースにすべきか
    • rubymotionプロジェクトの存続にはお金が必要だった
    • オープンソースにしたらスポンサー探しをしないとダメだった
    • スポンサーしてもらうこと自体好きじゃない
    • スポンサーは或る日突然手を引くことができる
    • スポンサーが去ったらまたスポンサー探しの旅をしないと存続できない
    • スポンサー探ししないなら別の手段をやらないとダメ
    • オープンソースにしたらこんなに速く成長しなかった、と自分は確信してる
    • macrubyの教訓
      • 6年プロジェクト続けた
      • コンパイラとランタイムに貢献してくれた人はたった4人
      • rubymotionをオープンソースにすることから得られることはない、と判断してた
      • rubymotionユーザの大半はrubyエンジニア
      • rubyエンジニアがCコンパイラやVMに精通してるとは思えない
  • Q:rubymotionはrailsのようにはいかない。サクっと直したり機能足したりとかできる領域じゃない、と
  • A:
    • YES
    • なのでrubyで書かれた部分はオープンソースにした
    • 沢山プルリクエストもらってる。中身見る時間が。。
    • 一部だけオープンソースというのは妥協方法として結構いい線言ってると思う
    • オープンにできる部分はオープンにする
    • ユーザに財政的な援助を求めることができる
    • ビジネスとしてrubymotionを続けることができる
    • 出資はいらないと思ってるんのは、投資する側は3~5年でリターン求めてくるから
  • Q:この仕組みでやりたいことを自分のペースでやれてる、と
  • A:YES。というか、自分にはこれが唯一のやり方だった

今後

  • Q:rubymotionの今後
  • A:
    • いいにくい部分
    • rubymotionは急速に成長してる
    • リリースしてから8ヶ月しか経ってない
    • 現時点で、色々な選択肢が見えてきた。重要な機能追加、等々
    • リソースは有限。決めて行かないといけない
    • ツールチェーンの改善。これは多分今後やると言えそうなこと。
    • コマンドラインベースしかない。これで大抵のユーザは使えてる
    • IDEラブな人たちもいる。いまJetBrainsと一緒に仕事してる
    • RubyMineのrubymotionサポートは良い感じになってる
    • RubyMIne内部でrubymotionのデバッグができる
    • このまま一緒に仕事続けたら、rubymotionユーザのためのIDEが作れるかも、と思ってる
    • ios以外のプラットフォームもサポートしてほしいというリクエストは沢山もらってる

後編