[書評] Gradle徹底入門

はじめに

このエントリーは Java Advent Calendar 2014 の 15日目として書かれたものです。

14日目は、@bitter_foxさんの「Load to an Author -Contributing OpenJDK-」です。

16日目は、@zephiransasさんの「Lambda-behaveでテストを書こう」です。

Gradle徹底入門とは

Gradle徹底入門
http://www.shoeisha.co.jp/book/detail/9784798136431

まずはじめに、献本して下さった@nobusueさん、ありがとうございました。

この本を読んでまず思ったのは、これまで手厚くサポートされたビルドツールの本を見たことがありませんでした。
過去に日本語で発売されたantやmavenの本でここまで詳しく、且つプロジェクトのプロセスにまで踏み込んだ本は、無いと思います。

個人的にこの本を読んで欲しいのは、未だにEclipseでビルドして、手作業でdeployしてるような残念なプロジェクトに配属されている人です。
読んで世の中には便利なツールがあることを知ってほしいと思います。

JJUG CCC 2014 FallでGradleで始めるGroovy expandというセッションを行う機会にも恵まれまして、この本の紹介をさせて頂きました。
そのセッションでは、Groovy, Gradleの入門編ということで導入に関する箇所を紹介いたしました。

今回は、どういった場面でこの本を使っていくと良いかを紹介したいと思います。

パターン

まず、そもそもGradleの名前だけ知っていて、ちょっと興味がある人の場合は、まず「導入編」だけを読んでどういったものかを知ってほしいと思います。

AndoridStudioを使い始めて、Gradleの世界に連れて来られた人は、「導入編」、「第9章 Androidプロジェクトでの運用」を読んでひとまず記号や文字列が何を意味しているのか知って、次にAndroid Pluginの更新に追従できるように頑張ってください。

今までAntしか使ってこなかった人は、「導入編」、「基礎編」、「実践編」、「第11章 Jenkinsとの連携」、「第12章 アーカイブの作成とファイルの公開」「第14章 ほかのビルドツールからの移行」を実際に書きながらやっていくといいと思います。

Mavenを使っていてGradleに興味がある人は、おそらく2種類だと思います。

まずは、今のプロジェクトがMavenのレールから外れてしまってどうにかしたい場合ですが、利用してるMavenプラグインが少なく、Antや他のスクリプト言語と併用しているような場合は、この本を全部読むことで何とか出来る可能性があります。

次に、どうしても特殊なMavenプラグインに依存していて、Gradleのサードパーティプラグインにも無いような場合は、全部読んだ後に「第13章 エキスパートへの道」を実践してみてプラグインを自作する価値があるかを決めてください。

Javaのライブラリのソースを見たらGradleのプロジェクトだった場合は、「基礎編」を重点的に読んで、タスクがどういった手続きを表しているのか、どういったプラグインに依存していて設定されているのかを知る武器を手に入れてください。

特にGradleはGroovyのDSLを作りやすい機能を活用して省略や簡略化されているのおり、同じ内容でも表現が違う場合があるので、「基礎編」や付録に付いているGroovyリファレンスを読んでください。
それでも足りない場合は、Groovyを知らない人のためのbuild.gradle読み方書き方入門を見てください。

おわりに

この本では、Gradle 2.0を基にしています。
今後のバージョンアップについて不安になっていらっしゃる方もいると思いますが、2.x系であればこの本に書かれている内容のAPIが変わることは無いでしょう。
また、APIにも実験的要素であれば、しっかりドキュメントにも載っているので、使う際には確認しておくといいと思います。

おそらくページ数の多さで迷っている人がいるのであれば、今後もJavaのプロジェクトでMavenのレールから外れる可能性が高かったり、AndroidStudioの様にGradleでしかビルドが出来ないプロジェクトに関わるような可能性があるのであれば、是非購入して役立てて頂ければと思います。

また、まだ公開されているプラグインの数が少ないので、自分の困っていることを解消したいと思ったら、プラグインを作って見て公開するまでの手順も載っていますので、挑戦してみてはいかがでしょうか。

JJUG CCC 2014 Fallに参加してきました #jjug_ccc

JJUG CCC 2014 Fall

きっかけ

これまで使ってきたGradleについてJJUG CCCで発表してみようかなと思って春に応募してみましたが、あえなく落選してしまいました。
秋にはリベンジしたいと思って、どんなネタがいいかなと考えていましたが、JJUG ナイト・セミナー 「ビール片手にLT&納涼会」で話した内容から、Groovyに繋がるような内容にしてみようと思い、応募してみたところ何故か当たってしまいました。

今までLTや長くても15分くらいしか人前で話すことが無かったので、50分をどう扱ったら良いのかいろいろ悩みました。

スライド

セッションは、Gradleで始めるGroovy expandです。
発表した資料はこちらです。

補足

Gradle徹底入門が出版されたということで、本の内容の紹介を含め、Gradleで使うにはGroovyでどんなことを知っておくと良いか等を話すことにしました。

初めはAndroid Studio使ってGradle Tutorial : Part 5 : Gradle App Engine PluginからGradle Tutorial : Part 7 : Android Studio + App Engine + GradleをGroovy, Groovy on Androidでやってみたいなとか考えてましたが、当日までの準備してると間に合わない状況になったのと、トラブルを避けようと思い、全編スライドでの説明にしました。
いずれ何かの機会でチャレンジしてみたいと思います。

スライドや発表では紹介しきれていない箇所がGradleにはあるので、まずは徹底入門を購入していただいてもらうといいと思います。
ちょっとしたスクリプトを書く場合にも使えますし、Javaのライブラリを駆使してタスクを組み上げたりすることも出来ます。

現場ではAntやMavenでレールを外れることもあると思います。
そういった場合にXMLではなく、ビルドスクリプトとしてGroovyを使うことが出来るので、無理をせずにやりたいことが出来るのがGradleの良い所だと思います。
自分がまとめで言いたかった事は、Javaを知っているとGradleやGroovyを使うハードルは低いので、まず試してみて日頃の業務を改善してみてはいかがでしょうか。ということです。

最後に

セッションに参加して下さった皆様ありがとうございました。
初めての発表で、ご期待に添えない、説明が至らない箇所、お聞き苦しい点などあったと思います。
それでも最後の拍手はとても暖かく、嬉しい気持ちでいっぱいでした。

発表の途中でいろいろGroovyやGradleについて質問をしてみましたが、使っている人が増えてきているのを実感しました。
主催しているYokohama.groovyを、今回の発表で興味を持って下さった方々にとってより良いコミュニティにしていきたいと思いました。

今回のJJUG CCCはどのセッションも魅力的で楽しい内容でした。
昼食や懇親会では、普段はtwitterでしかやりとりをしてない人とお会い出来て楽しかったです。

あと、Java養成読本の著者の方がいらっしゃっていたのでサインをしてもらうことも出来て良かったです。

JJUG、セッションの発表者、スポンサー、参加者の皆様、ありがとうございました。

JJUG ナイト・セミナー 「ビール片手にLT&納涼会」に参加してきました #jjug

【東京】【傍聴者募集】JJUG ナイト・セミナー 「ビール片手にLT&納涼会」 8/22(金)開催
http://jjug.doorkeeper.jp/events/13764

JJUG ナイト・セミナー 「ビール片手にLT&納涼会」 #jjug
http://togetter.com/li/709772

JJUGでLTして来ました。
お題は何でもいいというお墨付きを頂いたので、Groovyのお話にしようと思ってました。



JavaのプロジェクトでもAndroidでも使われるようになったGradleですが、Groovyで書くことが要求されます。
Javaのように書かれてもたいていはそのまま動作するので、学習コストは低いのですが、
GradleのようなDSLを書く場合は、ある程度知っておいた方がよい書き方があります。

その場合、試しながらやるとするとREPLがあった方が便利です。
しかし、Groovyをインストールする際にいろいろとお伺いしなければならないような環境だったりすると、いろいろと面倒です。
ですが、Gradle Wrapperを導入してあるプロジェクトであれば、REPL(Groovy Shell)はGradle Pluginを利用すると呼び出すことが出来ます。

2.1から簡単にPluginを導入できる書き方が出来るようになるので、Search Gradle Pluginsから探してGradle Lifeを快適にしましょう。

納涼LT大会の動画を一通りアップしました(まだYouTubeサイドでレンダリング完了してないのもありますが) - 2014/8/22 #JJUG ナイト・セミナー 「ビール片手にLT&納涼会」 - YouTube - https://t.co/a07Xy93I9v

— 山本裕介 (@yusuke) 2014, 8月 22

動画を見返してみましたが、予想以上にろれつが回って無いですね…

会場の方にGradleを使ってるか聞いたみたところ1/3位の方が手を挙げてらっしゃったので、嬉しい限りです。

実際にGradleを業務で使っている方はAndroidで使ってらっしゃる方がほとんどだと思われますが、既存のJavaプロジェクトでもAntを使ってるようなプロジェクトは、Gradleに移行する価値が必ずあると思いますので、試してみてはいかがでしょうか。

『JUnit実践入門』写経・実践会 in 横浜 #6 (特別編) に参加してきました #junitbook

『JUnit実践入門』写経・実践会 in 横浜 #6 (特別編)
http://connpass.com/event/2270/

2013/05/12 『JUnit実践入門』写経・実践会 in 横浜 #6 (特別編) #junitbook
http://togetter.com/li/490112

はじめに

前回の写経・実践会のレポートはこちら→『JUnit実践入門』写経・実践会 in 横浜 #5 に参加してきました #junitbook
今回は、@irofさんの「テスト駆動開発を継続する」と、著者の@shuji_w6eさんのJUnit実践入門には含まれなかった幻の章についての講演とハンズオンでした。

テスト駆動開発を継続する

テスト駆動開発を継続する from irof N

テストの価値は失敗することにあるというのは、現在の状況と目的が一致している状態から変化があったことを分かりやすくしたものだと思いました。
アサーションを分かりやすく一つづつ実施することで、どの状態が意図している目的で、どうして目的に合致しなかったのか見つけやすくなるのかなと思います。
大きなオブジェクトの状態を確認しようとするとアサーションの行が増えますし、本当に確認したいことが埋もれてしまっては、元も子もないと思います。
設計を見なおしたり、リファクタリングをする際に、目的の状態になっていることを確認するためのテストを書き、その状態を維持しつつ小さく分かりやすいテストにしていくことが重要なことだと感じました。
そういった小さいテストを継続的に積み上げることで、ひとつの変更が影響する範囲を視覚的に捉えることが可能になるのではないかなと、思います。
小さいテストであれば、わざと目的通りのRedにした場合でも、意図している動作であるか確認しやすいのではと思いました。

ハンズオン

後半は、@shuji_w6eさんの「受け入れテストの自動化とユースケース駆動開発 -Pre Cucumber Boot Camp-」と「cucumber + selenium」による受け入れテストのハンズオンでした。

元々はmavenとeclipseを対象にしたプロジェクトでしたが、IntelliJ IDEAとGradleでやってみようと思い、前日にGradle 1.6のBuild Setup Pluginを利用してbuild.gradleを作っておきました。



無事、IntelliJ IDEAでもcucumberを使えるようになりました。
また、h2databaseやjettyについてもtaskを追加しておいたお陰で、コマンドを実行するだけで起動や初期化が出来るようになりました。

途中でフィーチャファイルの補完が効いてないのかなと思いました。

#junitbook 日本語だとあまり補完が効かないのかな… Cucumber jetbrains.com/idea/webhelp/c…
— とーますさん (@grimrose) 2013年5月12日

が、IntelliJ IDEAを12.1.2から12.1.3に上げて見たところ、シンタックスハイライトとコードジャンプも出来るようになりました。
さすがJetBrains様です。

なんとか、ハンズオンの進行に付いていくことが出来ましたし、seleniumの残念な箇所も体験することが出来ました。
前回のBDDにてイマイチ使い所が分からなかったcucumberも、seleniumと組み合わせることでどうやって使ったら良いのか体験することが出来たのは良かったと思いました。

おわりに

懇親会では、@enumさんも参加して下さり、とても楽しい充実した時間でした。

今回のハンズオンは、プレと冠していましたがとても実践的でスタートラインまで連れて行ってもらえる内容でした。
今後は、どうやってシナリオを書いて行ったら良いのかなど、教えていただいた書籍を参考にやってみようと思います。

また、GroovyではGebがあるので、これとSpockを組み合わせることで、seleniumの残念な箇所をカバーしてくれて、なおかつシナリオもコードで書けるようになるので、同じ課題を挑戦してみたいと思います。

講師の@irofさん、著者の@shuji_w6eさん、主催の@shinyaa31さん、参加者の皆さん、会場の横浜タネマキさん、ありがとうございました。

残りの章も少なくなって来ましたが、次回もよろしくお願いします。

Yokohama.groovy #11 に参加して来ました #yokohamagroovy

Yokohama.groovy #11
http://connpass.com/event/1604/

2013/01/20 Yokohama.groovy #11 #yokohamagroovy
http://togetter.com/li/442240

はじめに

今回から、もくもく会形式になったYokohama.groovyに行って来ました。
去年までは、「プログラミングGROOVY」の青い本の読書・写経会だったのですが、ひと通り終えてしまったので、これまで学んできた事を自分で課題を見つけてやっていこうということになりました。

もくもくと

Gradle、JPA、JAX-RS、Gebを採用してRESTの勉強をしてみようと思ったので、課題としてみました。
途中まではJavaで書いていたものがあったので、すべてGroovyで書きなおしてそれから始めました。
レポジトリはこちら→https://github.com/grimrose/gradle-jetty-jndi-sample

次の目標は、jettyの設定ファイルをgroovyで生成できるようなのを作ってみたいと思います。
その後は、CDIの参照実装であるweldを試してみようと思います。

おわりに

これまでで参加者が一番多かったYokohama.groovyでした。
今後もいろいろな人が参加してもらえるような場所にしていきたいなと思っているので、今年もYokohama.groovyをよろしくお願いします。

主催の@shinyaa31さん、参加者の皆様、横浜タネマキさん、ありがとうございました。

次回も、よろしくお願いします。

TDD Boot Camp (#TDDBC) 横浜 Second Season に参加してきました

TDD Boot Camp (#TDDBC) 横浜 Second Season
http://kokucheese.com/event/index/46603/

2012/09/01 TDD Boot Camp 横浜 Second Season #tddbc
http://togetter.com/li/360406

TDDBC横浜 Second Season
http://devtesting.jp/tddbc/?TDDBC%E6%A8%AA%E6%B5%9C2nd

はじめに

今回は、スタッフとして初めてTDDBCに参加しました。
前回は、運良く抽選で参加者として参加しました。
前回のレポートはこちら -> レポート置き場: TDDBC横浜に参加しました。
それから、現在までいろいろな勉強会やイベントに参加することで、そろそろスタッフとして参加してみたいと思っていました。
また、TDD in Actionでも感じていたのですが、他のペアがどんな感じでやっているのを見てみたいと思っていました。
言語はJavaで参加しても良かったのですが、あえてGroovyで参加してみてることで自分のGroovy力がどの程度なのかを知ってみたかったので、Groovyにしました。

基調講演

@tosikawaさんによる「テスト駆動開発入門」の入門でした。

写経については、@t_wadaさんの連載にもありました。

［動画で解説］和田卓人の“テスト駆動開発”講座 » 第6回　「写経」でTDDの手順や書き方を学ぶ
http://gihyo.jp/dev/serial/01/tdd/0006

誰が言ったのか忘れてしまいましたが、新しい言語を始める際にテスト駆動開発入門を写経することで覚えるといいと聞きました。
それにならって、私自身まだ、テスト駆動開発入門の写経をしていないので、これを機にやってみたいと思います。

ペアプロ中の気づき

一番印象に残ったのはこれでした。

第三者の視点でペアプロに参加するというのは、大変勉強になった。閉じた世界を外から見ることで気づくこともあった。 #tddbc
— とーますさん (@grimrose) 9月 1, 2012

ペアプロをしていると、基本的に閉じた世界になってしまいがちですが、誰かに相談したり一息ついて一旦閉じた世界から離れてみる必要があるなと実感しました。

参加者の方から、言語のTAと言語以外に抽象的な部分に対応できるTAがいてとても良かったという感想をいただきました。
今回は、@t_wadaさんを始め複数の言語が出来たり、実戦経験豊富な方がTAだったので、上手くサポート出来ていたのではないでしょうか(私はあまり役に立っていたとは言えないのですが)。

前日にStep2まで素振りをしていたことで気づいたのは、事前に同じ課題をこなすことで自分の過去をオーバーラップしながらアドバイス出来たことでした。
自分がつまづいた箇所やGroovyでならどう書くのかといったことを出来るだけ伝えたつもりです。

また、その他の言語のテーブルを見て回れたのは、とても勉強になりました。
個人的にはJavaScriptのテーブルが、ドライバー1とナビゲーター2で10分毎に交代しながら行なっていたので印象に残りました。
jasmine + node.jsを利用していたそうです。
http://pivotal.github.com/jasmine/

探してみたところgradleにもjasmineのpluginがあったので、触ってみたいと思いました。
https://github.com/dzhaughnroth/jasmine-gradle-plugin

コードレビュー

コードレビューでは、C++のペアに学ぶことが多かったとおもいます。
テストに対する取り組み方として、慎重に周りを見渡してこのまま前に進んで大丈夫か確認していく大切さを教えていただきました。

Spockの素晴らしさを披露するのが、TDDBCでのコードレビューにおけるGroovyの定番となっているのですね。
あと、gradleでプロジェクトを作った意図を汲んでいただけたのか、参加者の方がgradleのレポートを披露してくださいました。
これも結構好印象だったので良かったです。
ありがとうございました。

最後に

今回、スタッフとして参加して、TDDの知らなかったことや新しいことを学ぶことができました。
特に質問コーナーでスタッフの皆さんが自身の体験から学んだことを話していたことがとても印象に残りました。
まだまだ練度が低いので、もっといろんな「気づき」を出来るまで日々鍛錬したいと改めて思いました。

主催してくださった@setoazusaさん、参加して下さった皆様、スタッフの皆様、会場を提供して下さった株式会社アットウェア様、ありがとうございました。

Gradleトーキョー に参加してきました #jggug #gradle_ja #gradle_tokyo

Gradleトーキョー
http://atnd.org/events/30137

2012/07/18 Gradleトーキョー #jggug #gradle_ja #gradle_tokyo
http://togetter.com/li/340726

きっかけ

ここ数ヶ月今までant + ivyでビルドしていたプロダクトを徐々にgradleへ切り替える検証を行なっていました。
eclipseのtomcat pluginを前提としたプロダクトだったのですが、柔軟に設定が出来るおかげでなんとか上手くやれそうです。
また、gradleのおかげでgroovyを勉強する勢いがつきました。
gradleは、taskの中でgroovyスクリプトをGroovyShellを利用して呼ぶ出来るので、制約がいろいろあったりする特殊なプロダクトにうってつけです。
そんなgradleの勉強会が開かれると言う事で参加してきました。

gradle入門

gradleの良い点は、IDEのプラグインが優秀なのでeclipse、IDEAであれば簡単にそれぞれのプロジェクトが作れます。
gradleのイマイチな点は、mavenのようなテンプレートプラグインがまだ標準でついていないところです(テンプレートのプラグインは探すと見つかります)。
ただ、propertiesに標準のディレクトリパスを持っているので、それを利用してディレクトリを作るタスクを作ってしまうと言う事も出来ます。
gradleは、antのタスクも利用できますし、build.xmlも利用できます。なので、既存のbuild.xmlをそのまま利用するといったことも出来ます。
そのため、antからmavenへ移行するよりgradleへ移行する方がスムーズに出来ます。

gradle wrapper

gradle wrapperの良い所は、JDK1.6以上さえ入っていれば、環境設定をいじることなく実行できるので、デモ環境を作りやすいとこだと思います。
もちろんgradle wrapperからでも「--gui」のオプションをつけることでGUIで利用することが出来ます。
gradleのデーモン化も出来る等、gradleをインストールしている環境と同じことが出来るので、おすすめです。
wrapperの配置も簡単なので、配布するようなプロダクトでは使いましょう。

最後に

カスタムプラグインの作り方を学ぶことが出来たので、実際に作ってみたいと思いました。
講師の@mike_neckさん、gradle wrapperを解説してくださった@toru_inoueさん、会場を提供してくださったNTTソフトウェア様ありがとうございました。