ソースコードの品質向上のための効果的で効率的なコードレビューを読んで、循環的複雑度(サイクロマティック数)を手っ取り早く測定してみたくなったので、GradleとPMDで試してみました。 http://wiki.gradle.org/display/GRADLE/Cookbook#Cookbook-usingPMD http://pmd.sourceforge.net/howtomakearuleset.html この辺を読めば割と簡単にできます。プロジェクトとしてきちんと測定していくなら、現在お使いのGradleの設定ファイル*1にpmdタスクを追加してあげればいいんですけど、手元のプロジェクトでちょっと測定してみたい、というときに仕込みがだるいのでやっつけですが*2シェルスクリプトを用意してみました。 スクリプト もう読んだそのままな感じで、pmd.gradleファイルとpmd-rule
2012/3/21追記 id:Hirohiroさんによれば、Gradle 1.0-milestone-9から後述の方法がdeprecatedになってるそうです。最新の方法は↓を参照ください。他にもEclipseでGradleを使うための素敵なTipsが紹介されてます。 http://d.hatena.ne.jp/Hirohiro/20120321/1332287707 以降はオリジナルのエントリ本編(参考として残しておく) Mavenでeclipse:eclipseをやって生成させた.classpathもそうなんですけど、とりあえずデフォルトで生成するとソースディレクトリのパスとして、コマンド実行したユーザ環境のフルパスが入ってしまったりします*1。Mavenの設定でそれを回避しようとしたこともありましたが、結局よくわからなくてあきらめました。頑張ればできるのかな? さて、Gradleでも
ちょっと前に書いた Javaプロジェクトにおけるビルドツール - @ikikko のはてなダイアリー Javaプロジェクトにおけるビルドツール2 - @ikikko のはてなダイアリー に関連して、はてブコメントへの反応とか、その他追加で考えたことについて。 IDE連携 eclipseと統合されてるかは極めて重要:Javaプロジェクトにおけるビルドツール - @ikikko のはてなダイアリー URL 2011-08-02 20:47:25 via BBS (JP) どのIDEを用いるかの議論はあるにせよ、今どきJavaプロジェクトの開発で何もIDEを用いないのはさすがにしんどいかと思われます。ただ、IDEだけ用意すればいいわけでもありません。IDEとは独立してビルドツール・ビルドスクリプトも用意しておかないと、ビルドがIDE依存になってしまったりCIが回せなかったりと、色々不都合な面も出
Androidアプリケーションの開発をすることになりました。 ド素人ですが楽しそうです。 っていうことで開発環境の選定から行うことになりました。 テストのないコードを書けるほどアジリティなプログラミングスキルがないのでテスティングフレームワークの選定とか。 半日ほどざっくりと試したりしてみて今の構想としては次の感じです。 どれも1時間以内に使えそうって意識できたものだけが残った点が「僕のいつも通りな基準だなー」って思いました。 自動テストフレームワーク Robotium -> エミュレーター起動UIテスト Robolectric -> エミュレーター起動なしロジックテスト +(Spock) -> Robolectricを使用して書けるなら使いたい ビルドツール Gradle -> 実質Gradleでしかやる気がない CI Jenkins Android Plugin -> CIサーバー確保
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く