ラベル Eclipse の投稿を表示しています。 すべての投稿を表示
ラベル Eclipse の投稿を表示しています。 すべての投稿を表示

2014年4月10日木曜日

Vim使いにもお勧めするEclipseの併用方法

もともと昔から開発はEclipseで行っていましたが、今はRubyを書いていくのがVimの方がやりやすいため、コードはVimで書いています。さらに、gitのコミットなどの操作もEclipseからではなく、ターミナル上のgitコマンドで行うようにしています(こちらは、Eclipseはシンボリックリンクを含むgitリポジトリの扱いにバグがあるため)。

逆に、Eclipseを使っていない人もいると思うんですよね。僕の周囲にはそういう人も居ます。確かに、Vimとターミナル上の各種コマンドで全てのことはできるっちゃできるんですが、Eclipseを併用すると色々な場面で効率を上げることができます。

僕がEclipseで活用している機能のうち、特に役立つと思うものをいくつか紹介します。

・ファイル検索

grepコマンドやfindコマンドでも同様のことができますが、Eclipseは結果表示の一覧性が良く、結果からエディターのヒット箇所へジャンプしつつ、結果を次々と見ていけたりできます。検索範囲をファイルツリーから選ぶのも直感的にできますし、使える正規表現もgrepより多いです。
操作方法:プロジェクト・エクスプローラ上で、検索したい範囲を選択した上でメニューから「検索>検索...」を選びます。

・gitヒストリー(コミットグラフ)の閲覧

これがあるからEclipseを併用していると言っても過言ではないです。gitのコミットグラフを可視化するツールはいくつも試しましたが、Eclipse(の標準プラグインEGit)が一番綺麗で見やすいと思います。
操作方法:プロジェクト・エクスプローラ上でプロジェクトのトップディレクトリを右クリックして「チーム>ヒストリーに表示」を選びます。

・gitコミット直前の確認ダイアログ

コミットする際に変更のあったファイル一覧は、ターミナル上でgitコマンドによるコミットを行う場合も出てきますけれども、Eclipseの場合ダイアログが表示されて変更のあったファイルと変更の種類を一覧で出すとともに、その一覧のファイルをダブルクリックすると、コミットしようとしている差分を表示してくれます。僕はここで差分だけ確認したらキャンセルして、実際のコミット操作はターミナル上のgitコマンドで行っています。
操作方法:プロジェクト・エクスプローラ上でプロジェクトのトップディレクトリを右クリックして「チーム>コミット...」を選びます。

・ディレクトリ単位での比較

比較結果がディレクトリ構造にのっとってツリー状に表示されるため、変更箇所が分かりやすいです。
操作方法:プロジェクト・エクスプローラ上で比較したい2つのディレクトリを選択した状態で右クリックして「比較>相互」を選びます。

他にも色々機能はありますが、上で述べた機能が最もよく使いますし、これらだけでも使いこなせば、Vimとターミナルだけで開発を進めるよりも一段高い生産性を発揮できることでしょう。

※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうぞ。

2014年4月2日水曜日

Eclipse EGitでサブモジュールを含むリポジトリが常に変更ありになる件

Eclipse の EGit プラグインでは、サブモジュールを含むリポジトリをチェックアウトすると、まだ何も変更していないはずなのに、変更ありのマークが付くという不可思議な状況になります。

最初はいきなり変更ありのマークが付いて何かミスったのかと思いましたが、やり直しても変わらないのでEGitがおかしいってことですね。

ちなみにシンボリックリンクも同じように変更していないはずなのに変更ありのマークが就いてしまいます。

調べてみたら、どうやらEgitが使うgitのJava上の実装であるJGitのバグのようです。シンボリックリンクの扱いが原因みたいですね。

https://bugs.eclipse.org/bugs/show_bug.cgi?id=391280

Eclipseはクロスプラットフォームである以上、シンボリックリンクの扱いをどうするのかは難しい問題なのかもしれません。上記リンク先を見ると、まだバグの対処は手付かずのようです。

仕方ないのでとりあえず、僕は端末上から git コマンドを併用することにしています。ステータスを見る時やgit コマンドによる各種操作はEclipseでなく端末上の git から行うようにしています。Eclipseはヒストリー(コミットグラフ)が見やすいのと、コミット時に出る、変更一覧を選択して差分を見るダイアログが見やすいので、実際のコミットは行わずコミット時のダイアログだけ見るといった使い方をしています。

※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうぞ。

2014年3月20日木曜日

[Ruby]開発環境をEclipse(Aptana)からVimに変更した件

開発環境にはEclipseを愛用してきた僕ですけれども、Rubyでの開発プロジェクトを本格的に進めるにあたり、色々試行錯誤の結果Vimに乗り換えることにしました。いえ、乗り換えるというと語弊がありますね。正確に言えば、コーディングすなわちソースコードをガリガリ書く部分にはVimを使いますが、EclipseはGitリポジトリの状態を見るのに使ったりするので併用していく方式にした、ということです。適材適所。

PHPの時にはEclipseのPDTプラグインが大変良く働いて、例えば文脈に応じての補完機能などは非常に便利でした。これは動的にコードから補完ができる優れ物で、自分で書いたクラス定義を参照してインスタンスのメソッド名を補完できたりしたんですね。さらに、フレームワークのソースコードをライブラリを読み込ませることで、フレームワークに用意されたクラスやクラス内のメソッドまで補完が効きました。あとクラスやメソッドにカーソルを合わせてショートカットで定義元にジャンプできたりとか。

一方、EclipseでRuby開発に使えるプラグインとしてはAptana Studio3がありますが、動的にコードから補完するところまではできないようでした。また、フレームワークのクラス名やメソッド名も補完が働きませんでした。もしかしたら僕の設定が間違っていた可能性もありますが、ある程度時間を掛けたところで諦めました。

そもそも、純粋なテキストエディタとしての使い勝手としてはVimが好きで、EclipseにVim風のキーバインドを実現するプラグインのvrapperを入れて愛用していたくらいです。PHPで開発していた時には、文脈を理解した動的な補完とライブラリからの補完がよく出来ていたので書きやすさを少し犠牲にしてEclipseを使っていましたが、それがイマイチならEclipseを使う優位性は薄れてしまいます。

調べてみると、Vimで一定レベルの補完や自動文法チェックもプラグインでできるので、それならRubyを書くのにはVimの方がいいかと思ったんですね。ということでコーディングはVimで行うことにしました。

ちなみに、Gitリポジトリの状態を見るためにEclipseは併用します。コミットグラフが見やすいので。ヒストリービューはほぼリアルタイム(長くても5秒くらいの遅延)でコミットグラフを更新してくれるので、状態を把握しつつブランチ間を移動したりコミットしたりできます。Eclipseは検索なんかも結果が見やすいですし。タスク・タグの一覧とかも便利です。普段はVimでコードを書きつつ、裏でEclipseを起動させておいて必要な時だけ見る、という使い方になると思います。

※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうそ。

2014年2月11日火曜日

Eclipseのエラー抑制:DLTK問題・ビルドパス・バリデータ

EclipseでGitなどのソースコードリポジトリから新たにプロジェクトをチェックアウトした時など、ビルド時や検証時に出現するエラーの対応に苦労するのは僕だけではないはず。必要なところだけにエラーをだして欲しいのだが、外部のライブラリや自分の担当ではない部分のエラーまで出てしまったりする。

中にはエラーを放置していて、数百ものエラーをそのままにしている人も見たことがあるけれど、必要なエラーだけを出すようにすれば、バグを未然に防いだり、非推奨のコードをうっかり使うのを防止してくれたりと、Eclipseのメリットを享受できるのだ。

まあでも、この設定意外とわかりにくい。僕も全部は分かっていないが、とりあえず現時点で自分が分かっている範囲で概要をまとめてみたい。まず、Eclipseでの出るエラーは

  1. DLTK問題
  2. <言語名>問題

の2つに大きく分けられると思う。後者は例えばXML問題とかHTML問題とかPHP問題とかいうやつだ。

で、対処法としては、

  1. DLTK問題 → ビルドパスの設定
  2. <言語名>問題 → バリデータの範囲設定とレベル設定(可能なもの)

という感じ。

まず、「DLTK問題」の場合は、ビルドパスから検証不要なコードを除外すればいい。プロジェクトのプロパティから「ビルドパス」(or相当するもの)を選択する。なお下の画像はPDTを適用しているため「PHP ビルド・パス」となっているが、適当に読み替えて欲しい。


「除外:〜」をクリックして「編集」ボタンをクリックし、除外パターンを追加すればいい。


次に「<言語名>問題 」の場合には、バリデータの範囲設定で不要なソースを除外する。プロジェクトのプロパティから「検証」を選択する。


各バリデータの右側にある設定ボタンをクリックすると、バリデータの対象範囲を設定できる。まず、特定の範囲だけにバリデータを適用したい場合はまず内包グループを追加し、そのグループにさらにルールを追加して適用範囲を指定する。特定の範囲を除外したい場合は同様にまず除外グループを追加し、そのグループにさらにルールを追加して除外範囲を指定する。


ここまでの設定で不要なソースに対してのエラーは抑制できると思う。ただ、必要なソースに対しても、無視して欲しいエラーが出ているケースもあるだろう。例えばWeb系言語のフレームワークではHTMLタグを出力する命令があったりして、その場合はテンプレートをHTMLとしてバリデートすると開始タグがないというエラーが出てしまったりする。

こういう場合には、バリデータのレベル設定を変更してやればいい。例えば、HTMLバリデータの場合は、プロジェクトのプロパティから「検証>HTML構文」を選び、「プロジェクト固有の設定を可能にする」にチェックを入れれば色々いじることができる。


だいたいこんなところ。他にも言語やプラグインによって設定できる箇所は増えると思うけれど、だいたい上記の設定は共通して行うことになるんじゃないかな。

※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうそ。