# Ember.js コアチームへのインタビュー（後編）

http://net.tutsplus.com/articles/interviews/ember-js-core-team-interview/

後編ですが例によってかなり意訳してます。

Ember.js を見ていると Rails の影響を感じるんだけど？

Tom Dale

• さっきも言ったように URL が Web の重要な特徴。
  • Cocoa のコンセプトをそのまま Web には持ってこれない。
  • SproutCore も Cappuccino もそれをやろうとして失敗した。
• Rails はフレームワークが URL をどう扱うかを示した。
  • Rails では Model は単に Resource であり, Routes によって公開される。
• Ember も Rails に倣って URL を中心に置いている。
  • Rails のような CoC もある。

Yehuda Katz

• Rails の MVC と Ember の MVC は違う。
  • Rails に似ていると感じるのは CoC と命名規約だと思う。
  • 表面的には似ているかもしれないが, そのまま持ってくるのは駄目。
  • でも Router に関しては Rails にかなり近いものになった。

Ember.js を利用する開発者が知っておくべきことは？

Tom Dale

• Templates は Controller に接続され, Controller は Model（もしくは Collection）に接続される。
  • これらの関係は Router で定義される。
  • アプリを作るときはこれを繰り返す。Template, Controller, Model ...

過去一年間で沢山の API 変更が行われ, Ember を使いたい開発者はメンテが大変だった。これからはどうするつもり？

Tom Dale

• 1.0 RC リリースした。
  • 2.0 になるまでは互換性は維持される。

Yehuda Katz

• OSS 開発で好きなパターンは, 1.0 になるまではアーリーアダプタに API 設計をドライブしてもらうこと。
  • 開発者はユースケースに応じてフィードバック出来る。

Discourse がローンチされたけど, どうだった？

Tom Dale

• 凄いと思った。
  • 開発中のフレームワークを使って 2 人で良く出来たプロダクトを作り上げてるのには唖然とした。
• 彼らは Ember のパフォーマンス問題にも貢献してくれた。

Yehuda Katz

• Discourse はレスポンシブなところが好き。
  • こういうのは生の HTML 使わないと作れないって意見が多かった。
  • Discourse はきちんとした URL を担保して Google に見せられるようになってる。

意図的に（Ember の）プロジェクトチームを小さくしてたよね？

（省略）

他の MVC フレームワークが沢山あるけど, Ember を選ぶ理由は？

Tom Dale

• Ember は強力な規約に基づいてる。
  • 不要な議論を避けることが出来る。

Yehuda Katz

• Web アプリケーションを作るときに必要とされるのは URL。
  • URL を中心に置いて構造化する。
  • 他のフレームワークも URL をサポートしてるけど, Ember は URL から始まるところが違う。

jQuery や MooTools ではなく, Ember のような MVC フレームワークを選ぶ理由は？

（省略）

Ember が jQuery を使ってる理由は？

（省略）

モバイルで Ember 使うときに考慮すべき点は？

Tom Dale

• 沢山の会社がモバイルで Ember を使ってると言われている。
• プロファイラが使えるようにしておくこと。
  • 途中で最適化を考えるよりもホットスポットをプロファイルする方が良い。

Yehuda Katz

• Ember を使うことによるオーバーヘッドもあるけど, Ember が最適化してくれるところもある。
  • 複数の DOM 操作の結合とか。
  • 例えば Ember ListView は DOM を再利用してくれる。
• 制限された環境では, 間違いなくパフォーマンスにフォーカスすることになる。
  • Ember 使ってたら高レベルな API 使うことになる。
  • 誰かがパフォーマンス問題に直面したらそれが Ember にフィードバックされる。
  • Ember をバージョンアップするだけでパフォーマンスが向上することもある。

SPA (Single Page Application) 初心者に有用なリソースは？

Tom Dale

• Ember.js Guide。
  • 少なくとも週に一度は更新してる。

Ember.js コアチームへのインタビュー（前編）

http://net.tutsplus.com/articles/interviews/ember-js-core-team-interview/

Ember.js コアチームへのインタビューが興味深かったので斜め読み。長いので分割します。 インタビュー対象者は Yehuda Katz と Tom Dale です。

ちょこちょこ良く分からないところがあったので, 例によって間違ってたらスミマセン。

バックグラウンド教えて

Yehuda Katz

• 大学で会計を専攻してた。
  • 学ぶのは好きだけど会計を仕事にするのは自分にはつまらないと感じた。
• 最初に就職した会社で Web デザイナーの職を得た。
  • プログラミング勉強しようと思った。当時すでに jQuery と Rails があった。
  • すぐに OSS の世界に入った。まだ未成熟だったし自分の未熟なスキルでも貢献出来るところがあった。
• 最初のアプリをリリースしたら Rails の枠を超えて成長し始めた。
  • 気がつけばアプリよりも Rails をハックしてることの方が多くなってた。
• Merb の開発に参加した。
  • 最終的に Merb の目指すところは Rails と似てきたので合流することになった。
  • Merb の modularity と configurability を Rails 3 に取り入れた。
• Rails 3 をリリースしたあと、Web 上の他の大きな問題がないか探し始めた。
  • 大きな Web アプリを作るときのやり方は何年も変わってなかった。未だに jQuery 使うやり方は変わってなかった。
  • jQuery は素晴らしい DOM ライブラリだけど、どういうわけかその存在が開発者を低レベルな抽象化に閉じ込めていた。
• 最初にデータバインディング出来るテンプレートエンジン作った。
  • これは Handlebars になった。
  • SproutCore にはデータバインディングがあるのを知ってたけど、これはシンプルな HTML を描画するのに大量の JavaScript を要求した。
  • 最高の HTML の DSL は HTML。
  • Knockout も知ってたけど、バインディング情報を HTML 属性として書きこむのはあまり好きじゃなかった。
• このころ Charles Jolley（SproutCore の開発者）に Apple まで呼ばれた。
  • 最初の SproutCore が Merb で作られたものだから, 彼は僕のことを知ってた。
  • 彼は SproutCore に僕のテンプレートエンジンのアイディアを組み込まないかと提案してきた。
  • 彼の作った新しい会社（Strobe）に入社した。
  • このとき Tom はまだ Apple に居たけど、彼のことは素晴らしい API デザイナーだと分かったので Strobe にリクルートした。
• Strobe が Facebook に買収されたあと、Tilde 作ってプロジェクトを継続してる。

Tom Dale

• きちんとした教育を受けたエンジニアではない。
  • カリフォルニア大アーバイン校で犯罪学・社会学・法学の学位を取得。
  • 卒業後, アップルストアの Genius Bar で働き始めた。
  • 仕事で使うソフトウェアが酷いものだったので, Cocoa の本を買ってハックした。
  • 暫くしてこのソフトウェアは周囲の店舗にも拡がっていった。
• フロントエンド SproutCore, バックエンド Rails のアプリつくってる人に呼ばれた。
  • Rails のバックエンドはすぐ出来たけど, フロントエンドはまだまだ仕事が残ってた。
  • JS やったことは無かったけど, リテールに戻りたくなかったので JS の本を大量に買って仕事することにした。
  • これが 2009 年頃の話。
• 暫くしてリリース出来た。
  • SproutCore は ver 1.0 になってなかった。
  • 当時はまだ誰もこのようなクライアントサイドアプリケーションを作ってなかった。SproutCore は進歩的だった。
  • Cocoa と JS を詳しく知ってる人も少なかった。
  • 正しい場所に正しいときに居たと思う。
  • MobileMe に採用された。
• フレームワーク開発するのが好きだと気付いた。
  • SproutCore の API 設計を通じて Yehuda と知り合い、彼らの会社（Strobe）に入社した。
  • SproutCore は素晴らしいアイディアを沢山もってたけど沢山のレガシーな部分も抱えていた。
  • SproutCore 2.0 をスクラッチから作ることにした。
• 2011 年の終わり頃, Strobe は Facebook に買収された。
  • Facebook は働くには良いところかもしれないけど, 僕等は OSS の世界で独立して仕事を達成したかった。
  • Yahuda や他のメンバーと一緒に新しい会社（Tilde）を作った。

何で新しいフレームワーク作ったの？

（省略）

何で SproutCore からリネームしたの？Ember.js の新しい取り組みは何？

Tom Dale

• SproutCore では沢山の間違いを犯した。
  • 一番大きな間違いは多分 Cocoa を Web に持ってこようとしたこと。
  • Web では UI のカスタマイズ性は大事だけど, SproutCore では難しくなってた。
• Backbone の人気に気付かされた。
  • 開発者は HTML と CSS の経験が豊富。
  • 彼らに SproutCore を学んでとは言いづらかった。
  • Backbone は大きなアプリケーションを作る際に必要になる適切な抽象化を欠いている。
  • けど始めるのも簡単だし, 開発者は HTML と CSS のノウハウが利用出来る。
• Web 開発者に Cocoa のようなアーキテクチャを提供出来ると思った。
  • 新しい API を設計して既存の開発者の資産を活かせるようにしたかった。
  • だから新しくスクラッチで作り直した。
  • SproutCore には色んなレッテルがあったし, テンプレートドリブンなアプローチはコミュニティ内でも議論を醸した。
  • 新しいものなんだってことを伝えたくてリネームすることにした。

Yehuda Katz

• SproutCore での最大の仕事は DOM の抽象化だった。
  • HTML と CSS を理解してる開発者よりも, 何らかの抽象化された層の上での開発者の方が多い。
• Web はパワフル。HTML と CSS でコンテンツを表現出来る。
  • じゃあそれで完璧？全然そうじゃない。
  • Ember の目標は, 開発者が使っていたツールを彼らの手に取り戻させること。

Ember はまだ未成熟だけど？

（省略）

MVC って観点だと Ember のとったアプローチは他のフレームワークとは違うよね？

Tom Dale

• Ember の MVC は Cocoa や Smalltalk のそれに似てる。オリジナルの MVC に近い。
  • Model：ドメインロジックとデータ。
  • View（テンプレート）：Controller にバインドされて Model を表現する。
  • Model の変更は補足されて View に反映される。
• 他のフレームワークと比較して一番大きな違いは恐らく Ember は front と center に router を置いていること（※ どういうこと？）。
  • 他のフレームワークと同様に URL にフォーカスしてる。
  • URL をコピーしたら, 他のブラウザで開いても全く同じ画面が見えるべき。
  • Ember 使えば簡単に開発出来る。

Yehuda Katz

• みんなそれぞれ違うけど, やりたいのは HTML とデータモデルを分けたいってこと。
• Backbone はそれだけに留めてる。Model と View を提供してくれるけど, 他のレイヤは自分で好きなように作る。
• 他のフレームワークには Controller がある。これは View Model と呼ばれていて, Knockout とかはコレ。
• Ember は Cocoa にインスパイアされてる。
  • Controller は View レイヤで Model をデコレートして表現する。
  • Router は Cocoa で言うところの coordinating controllers で, コントローラ間の協調を可能にする。
  • Ember の Router は URL を中心の概念に置いているので, ブックマーク／共有可能な URL を提供する。

Eclipse で Gradle を使う (2) マルチプロジェクト構成

前回 に続き、今度はマルチプロジェクト構成を試してみた。Eclipse で管理する場合はフラットレイアウトでないと扱いづらいため、フラットレイアウトで作成する。結果は Gist に纏めてみたけどココにも全部書いてる。

プロジェクト構成

以下のようなプロジェクト構成を想定。

• workspace
  • util
  • model
  • persistence
  • service
  • api
  • web
  • master-build
  • .git

依存関係としては

• model -> util
• persistence -> model
• service -> model + persistence
• web -> service

といった感じ。master-build がフラットレイアウトの親プロジェクト。

親プロジェクトの設定

STS の Gradle プラグインでもマルチプロジェクト構成を作ることは出来るのだが、どうもこの機能を使って作るとプロジェクトのリネームをしてもリソースのフォルダ名が変わらなかったりして使いづらいので、普通に手で build.gradle などを配置した方が良さそう。

まず適当なフォルダに想定しているプロジェクトのフォルダを作る。次に、親プロジェクトは master-build という前提なので、ここに build.gradle を記述する。

apply plugin: 'eclipse'
 
subprojects {
    
    apply plugin: 'java'
    apply plugin: 'eclipse-wtp'
 
    jdkVersion = 1.7
    sourceCompatibility = jdkVersion
    targetCompatibility = jdkVersion
    version = '0.1'
    vendor = 'vendor.com'
 
    repositories {
       mavenCentral()
    }
 
    dependencies {
        compile group: 'com.google.guava', name: 'guava', version: '13.0.1'
        testCompile 'junit:junit:4.8.2'
    }
 
    jar {
        manifest.attributes provider: 'gradle'
        manifest.attributes 'Implementation-Vendor-Id': vendor
        manifest.attributes 'Implementation-Vendor': vendor
        manifest.attributes 'Implementation-Version': version
    }
 
    eclipse {
 
      classpath {
        file {
          whenMerged { classpath ->
            classpath.configure classpath.entries.grep { entry ->
              !(entry instanceof org.gradle.plugins.ide.eclipse.model.Library)
            }
          }
        }
      }
 
    }
 
    task mkdirs << {
      ["src/main/java", "src/main/resources", "src/test/java", "src/test/resources"].each {
        def path = "${projectDir}/${it}"
        ant.mkdir(dir: path)
        ant.touch(file: "${path}/.gitkeep")
      }
    }
 
 
}
 
task wrapper(type: Wrapper) {
    gradleVeresion = '1.4'
}

mkdirs というタスクは下位プロジェクトのソースフォルダを作るのが面倒くさかったのでユーティリティとして作ったもの。eclipse の設定を書き換えているのは、普通に gradle eclipse すると jar のパスが直接書き込まれてしまうので、これを削除するもの。こちら から拝借しました。

settings.gradle は普通に子プロジェクトを定義するだけ。

includeFlat "util", "model", "persistence", "service", "api", "web"

但し include ではなく includeFlat を使うのがポイント。こうするとフラットなプロジェクト構成を認識してくれる。

子プロジェクトの設定

基本的に build.gradle を書くだけなのだけど、web を例にとるとこんな感じ。dependencies - compile project で依存プロジェクトを設定する。

apply plugin: 'war'
 
dependencies {
  providedCompile 'javax.servlet:servlet-api:2.5'
  compile project(':api')
  compile project(':service')
}
 
war {
    manifest.attributes = jar.manifest.attributes
    manifest.attributes 'Implementation-Title': 'web'
}

war を作成するのでこのプロジェクトだけ war プラグインを入れてる。マニフェストの設定も jar から拝借するようにした。

ビルドしてみる

早速ビルドしてみる。

$ ./gradlew build

して問題なくビルド出来れば OK。ちなみに web のみ war プラグインを入れているのだけど、そうすると賢く war もビルドしてくれて至れり尽くせり。

Eclipse プロジェクト化

プロジェクト構成は出来上がったので master-build プロジェクトから以下のコマンドを実行すると Eclipse プロジェクト化してくれる。

$ ./gradlew eclipse

Eclipse を起動し、Import - Gradle Project からインポートするのだけど、注意点としてはここでインポートする際には Gradle の親プロジェクトを選ぶところ。今回だと master-build を選択し、Build Model してからインポートする。

あとは Team - Share から Git を選び、親プロジェクト直下に .git を作って管理すれば良いと思う。

JAX-RS のモデル

JAXB と JPA をひとつのモデルに混ぜるのってアリ？

• JPA と JAXB でモデル分けると変換用のボイルプレートコードが大量発生する。
  • どうすべき？
• エンティティに循環参照があったりするとキツい。
  • 複雑な関連を持ったエンティティを全てシリアライズするのは非現実的。
  • すべてのリクエストに対してエンティティのオブジェクトグラフを深くまで辿っていらない情報まで返す必要ある？
  • JAXB オブジェクトが複数のシリアライゼーション形式をサポートしていれば良いけど JAXB も Jackson もそんな機能はサポートしてない。
• 複数のシリアライゼーション形式をサポートしようとするとアノテーションヘルになりそう。
  • 複数の DTO 使うとより冗長になるけど少なくとも上手くいく。

JAX-RS：モデルとベストプラクティス

• ちょっと教えて。
  • モデルを異なる jar にして共有してる？
  • いつも DTO 使ってる？
• プロジェクトの複雑さによる。
  • シンプルなプロジェクトなら DTO レイヤーは作らない。
  • クライアントとサーバ両方を自分でコントロール出来るなら新しいレイヤは作らずモデルを共有する（jar を分ける）。
  • API を外部に公開するなら DTO 使ってモデルを分離するのは良いアイディア。モデルの変更によって API が壊れない。
• 私見では DTO レイヤは次の理由で必要になる。
  • 関心の分離。
  • 出力サイズの最適化。
  • やっぱり DTO 使う方が良さそうに思う。

Ember.js から AngularJS に移行中

http://beust.com/weblog/2012/12/29/migrating-from-ember-js-to-angularjs/ より斜め読み。

• 中規模の JavaScript アプリケーションを Ember → Angular に移した。
• なぜ？
  • Ember 0.9.x ベースで作ってたけど 1.0 に乗り換えるのツラい。
  • pre-release 版を使ってるんだからしょうがないんだけど、根本的な変更も多いし。
  • 他のを見ても損は無いかなって。
• Angular は Ember より広範なフレームワーク。
• Binding / MVC フレームワークだけじゃない。
  • Module。自分が好きなように出来る。
  • Injection と Testability。
  • Partial のサポート。Ember 使ってて本当に欲しかったものはコレ。HTML テンプレートを小さく分割出来なかった。
  • Documentation。Ember のドキュメントはかなり多いけど整理されてない。Angular は整理されてる。
• Ember と Angular には色々な違いがある。
  • Ember は昔ながらのテンプレート。散らばったディレクティブ。
  • Angular は独自の HTML 属性を使い、プリプロセッサで DOM を処理する。
  • Angular のアプローチの方がデバッグしやすかった。
    • 展開されたあとの HTML を検査出来る。
    • Ember はプリプロセッサが magic identifiers（e.g. "id="metamorph-34-start") を付けるし。
• バインディングもかなり違う。
  • Embre はモデルに含まれるオブジェクトをラップさせるけど問題を孕んでる。
  • object.set('foo', newValue) みたいにセッター呼ばないといけないけど、バインディングが動かないデータもある。
  • 連鎖的な更新がすぐに実行される。
    • データを色々操作してから纏めて更新したい。
    • 仕方なくモデルにフラグを設け、準備が出来るまで更新しないようにするしかなかった。
  • Angular のバインディングの方はもっと簡単で、単純にモデルを更新すれば良い。
  • Ember の computed property はテンプレートにバインディングを書かないといけなくて厄介。
• これだけは言わせてくれ。IDEA の JavaScript サポートは Eclipse の数光年先を行ってるぜ。
• まとめると Ember 使ってた頃より Angular 楽しんでる。
  • 活気ある。
  • ドキュメントは高品質。
  • モダンな概念のサポート（modularity, testability, injection）。
  • JS で SPA (Single Page Application) 作るときのデファクトになると思う。

なぜ Discourse は Ember.js を使うのか？

http://eviltrout.com/2013/02/10/why-discourse-uses-emberjs.html より斜め読み。

• ふたつに分けて答えよう。
  • なぜクライアントサイド MVC フレームワークを使うのか？
  • なぜ（他のフレームワークではなく）Ember なのか？

何故クライアントサイド MVC フレームワークを使うのか？

• 対話性
  • 比較的静的なページならサーバーサイドでレンダリングすれば良い。
  • 対話的になればなるほどクライアントサイド MVC フレームワークの便益が向上する。
• なんで昔ながらの jQuery を使わないの？
  • jQuery はちょっとした対話機能の実装なら上手くいく。
  • でも状態が増えると data-* 属性を使って DOM にデータを埋め込んでいくことになる。
    • イベントと属性の対応を覚えるの大変。
    • それに DOM の構造と jQuery の実装が密接に結びつく。
    • HTML を変えたら jQuery 側の実装も調整しないといけない。
  • すぐスパゲッティコードになっちゃう（※ 例は記事を見て下さい）。
    • データは DOM に分散。
    • ロジックは特定の HTML に依存。
• MVC フレームワーク使うとどうなるか？
  • Ember.js 使えば解決。
    • バインディング機能があるから HTML の再レンダリングコール不要。
    • DOM からデータを見つける必要もない。
    • フロントエンド開発者がテンプレートを弄っても大丈夫。
• クライアントサイド MVC のパフォーマンス
  • こんな心配を良く聞く。
    • 巨大な JS ライブラリのダウンロード。
    • JSON の送信。
    • テンプレートのコンパイル。
    • HTML 文字列の生成。
  • Ember.js は minified gzipped で 47k。
    • そんなに大きくない。
  • Discourse は View が変わったときに JSON だけリクエストする。
  • production ではテンプレートはコンパイルしない。
    • プリコンパイルしておく。
  • 確かにサーバーでレンダリングした方が速い。
    • 特にしょぼいデバイスだとレンダリングするのが普通より遅くなる。
    • でもまぁ良く考えて。JS もデバイスもこれからどんどん速くなるし。
    • 最新の iPad だったらスムーズに動くよ。
    • データ（JSON）だけ送ってスローなレンダリングする方が速かったりする（テーブルとか）。
  • 良い副作用として良くテストされた API が出来上がる。
    • 今後 Android や iOS クライアントを作るのは楽になる。
    • だって既に流暢に JSON を話すようになってるんだもんね。

なぜ（他のフレームワークではなく）Ember なのか？

• ドキュメントがシンプルで分かりやすい。
  • Angular.js のドキュメントは内部（詳細）を語ってない。
  • Ember.js のドキュメントと比べてみたらシンプルさが分かる。
  • 分かりやすいことって大切だと思う。
• 早い段階でちゃんと動いてたし凄い勢いで進化してる。
  • API は途方もなく改善されてる。
• オープンソース界隈で実績があるチーム。
  • Yehuda Katz は Rails3 と Bundler で凄い仕事をした人だし。
  • 彼は Ember.js を放棄するつもりは無いって言ってたし。
  • 僕は彼のことを信頼してるし。
• 文字列テンプレート vs DOM テンプレート
  • Ember.js は DOM ベースのテンプレートを使う代わりに文字列ベースのテンプレートを使う（Angular.js は DOM ベース）。
  • 個人的には DOM に属性追加するより handlebars のシンタックスの方が好き。
  • ついでに言うと僕らは幾らかサーバーサイドでレンダリングもするし。
    • そんなときは文字列ベースのテンプレートの方が楽。
    • PhantomJS 環境を全部動かす必要ないしね。
• ループ処理
  • DOM とバインディングのバッチ処理のパフォーマンス。
  • 他のフレームワークでは 100 個のアイテムがあったら 100 回の DOM アップデート。
  • Ember は 1 回でバッチ更新。
  • ユーザーエクスペリエンス考えたら Ember の方が良いよね。

Eclipse で Gradle を使う

Gradle 凄く便利だということが分かったのでメモしておく。ちなみに以下のメモは STS の Gradle Integration for Eclipse を利用している前提。

依存関係の更新

Eclipse では build.gradle をこんな感じに更新し、

# build.gradle
dependencies {
    compile group: 'com.google.guava', name: 'guava', version: '13.0.1'
    testCompile group: 'junit', name: 'junit', version: '4.+'
}

build.gradle を右クリック → Gradle → Refresh Dependencies で自動的に依存関係が更新される。

Gradle Wrapper を使おう

Gradle には Gradle Wrapper というものがあり、これを使うとインストールレスでビルドが出来る。Eclipse の Gradle プラグインなんかもこれを利用しており、基本的には一切 Gradle をインストールする必要がない。ビルドすると自動的に Gradle がダウンロードされるようになっている。

自分のプロジェクトでビルド環境を統一したければ、プロジェクトに Gradle Wrapper をコミットしておけば良い。まず、こんな感じで build.gradle に wrapper タスクを定義しておく。

# build.gradle
task wrapper(type: Wrapper) {
  gradleVeresion = '1.4'
}

次に最初だけ Gradle のバイナリをどこかにダウンロードし、

$ ./GRADLE_HOME/bin/gradle wrapper

を実行すると、こんな感じのファイルが出来る。

• gradlew
• gradlew.bat
• gradle/wrapper/*

これらをリポジトリにコミットしておくと、以降開発者は

$ ./gradlew build

なんて感じで Gradle をインストールすることなくビルド出来るのだ。これは素晴らしい。

既存の Git プロジェクトをインポートする

まず普通に Git リポジトリを clone したあと、build.gradle で Eclipse プロジェクト化する。

$ ./gradlew eclipse

次が肝心で、Eclipse で普通に Existing Project や Gradle Project として Import すると Git リポジトリの情報が引き継がれない。なので、File → Import → Git → Projects from Git から先ほど eclipsefy したプロジェクトを選択し、Import existing projects として Import する。そうすると上手く Git リポジトリの情報も維持したまま Gradle プロジェクトとして取り込まれる。

〈追記〉

普通に Gradle プロジェクトとしてインポートすれば良かったです。File - Import - Gradle Project から任意の Git リポジトリを選択し、Build Model を実行して Gradle プロジェクトとして取り込みます。次に、Team - Share Project から、当該プロジェクトの Git リポジトリを選択すれば問題なく Git の情報を引き継げます。

なお .gitignore はこんな感じ（訂正しました 2013/02/23）。

.gradle
*.project
*.settings
*.metadata
*.classpath
.DS_Store
bin/
build/