以下斜め読んだ内容

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-cã‚‚xcodeも一から勉強しなくてよくなった
    • （補足）コメント欄で「ミスリード。iosのapiは勉強しないとダメだろ」とツッコミ入って、「apiもそうだしsdkの知識はいるね」と補足いてる
  • rubyとコマンドラインツールがそれに取って代わった
  • インタビュー前編；ベーシック
    • rubymotion：何？何するもの？使い方は？
    • ios甩にruby書くこと、普通のrubyアプリ書くこと。どこが違う？
  • インタビュー後編：テクニカル
    • rubymotionの中身
    • LLVMの使われ方
    • rubyコードをstaticな実行ファイルにコンパイル
    • rubymotionの挙動：macruby,rubiniusとの違い

初の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：
    • 7年働いた
    • macrubyが自分がやった最後のプロジェクト
    • appleには珍しいオープンソースプロジェクト
    • apple上層部は今後macrubyをバックアップするつもりがなかった
    • ってことで、これからどうしよう？、となった
      • apple残留（＝別プロジェクト参加）、転職、起業
      • よーく考えて、会社作るいい機会と結論だした
    • 当時子供は4ヶ月、Californiaに住んでたし、ヨーロッパに戻りたかった
  • Q：rubymotionのスタッフ
  • A：
    • しばらく１人スタートアップ
    • 4ヶ月前に１人雇った
    • Watson（shizuo fujita)
    • 彼はmacrubyの有名人
    • 自分はrubymotion始めたらmacrubyから完全に離れた
    • watsonはあらゆることをmacrubyプロジェクトでやってた
    • macruby界最大のコミッタ
    • 今年中に雇いたい人があと２人いる

そもそも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：
    • それはmacrubyから持ってきた
    • なのでmacruby風味に
  • 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：
    • 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も無い
    • インタプリタ同梱のアプリをリリースすることにつながる
      • アプリ内インタプリタはappleのガイドライン的にOKなのかNGなのかはっきりしない所
  • 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~５年でリターン求めてくるから
  • Q：この仕組みでやりたいことを自分のペースでやれてる、と
  • A：YES。というか、自分にはこれが唯一のやり方だった

今後

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

後編