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

2014年11月19日水曜日

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、セッションの発表者、スポンサー、参加者の皆様、ありがとうございました。

2014年8月24日日曜日

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を快適にしましょう。



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

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

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

2014年4月21日月曜日

Agile Samurai Base Camp 2014 Re:TDD に参加してきました #agilesamurai

Agile Samurai Base Camp 2014 Re:TDD
http://agilesamurai-basecamp.doorkeeper.jp/events/9333

Agile Samurai Base Camp 2014 Re:TDD #agilesamurai
http://togetter.com/li/657283

はじめに

前回は、インセプションデッキ、TDDの同時開催でしたが、今回は、TDDのセッションだけの再公演でした。
今回新しい試みとして、Groovyのセッションをする機会をいただけることになりました。

今回、Javaを使っている人を対象としていたので、JUnitだけでもいいけど「Groovyを使うという選択肢もありますよ。」という提案が出来ればといった内容にしました。
また、アジャイルサムライを読んだ後にJUnit実践入門を読んでいただければ、実際に現場に戻っても助けになると思います。
JUnit実践入門ではGroovyの紹介がありましたが、今回はもう少し先を見せることが出来たのではないかと思います。

JavaScriptのライブコーディングは、前回の反省を踏まえた内容にしました。
Jasmineで既にあるプロダクトに対してとっかかりを見つけながら、テストコード書いていくのを見せることが出来たと思います。

Groovyセッションの補足

grimrose/asbc-2014-04-groovy

今回のデモで使用したコードです。
現在の最新コミットの状態では、デモが終わった状態のままでテストが失敗するようになっています。
デモでは動かしただけだったGebも番外編として併せてコミットいたしました。

Gradle Wrapperも併せてコミットしているので、Gradleがインストールされていなくても動かすことが出来ると思います。

おわりに

Groovyを現場で使うには色々とクリアしなければならないハードルがありますが、まずご自身でGroovyがどういったものか試せるようになれる道筋を見せることが出来たのではないかと思います。
拙い説明だったかもしれませんが、Groovyのセッションに来て下さった皆様、ありがとうございました。

ホワイトボードの付箋に気づきや目標が見つかった内容がたくさんあったので、お手伝い出来てよかったと思いました。
BaseCampなので、また現場での気づきや疑問を共有出来ればいいなと思います。

参加者の皆様、スタッフの皆様、会場を提供して下さったサイバーエージェント様、ありがとうございました。

2013年1月20日日曜日

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さん、参加者の皆様、横浜タネマキさん、ありがとうございました。

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

2013年1月14日月曜日

『JUnit実践入門』写経・実践会 in 横浜 #2 に参加してきました #junitbook

『JUnit実践入門』写経・実践会 in 横浜 #2
http://connpass.com/event/1557/

2013/01/12 『JUnit実践入門』写経・実践会 in 横浜 #2 #junitbook
http://togetter.com/li/437795

はじめに

前回の写経・実践会のレポートはこちら→『JUnit実践入門』写経・実践会 in 横浜 #1 に参加してきました。 #junitbook

前回に引き続き参加して来ました。
今回は、「Part.2 JUnitの機能と拡張」が対象でした。
初めの方の参加条件として写経のレポジトリを登録するというのがあったので、
年末にやってみましたが第8章までしか出来ませんでした。
出来れば全てこなしたかったので、残念です。

写経のレポジトリはこちら→https://github.com/grimrose/junit-boost-camp

JUnit Boost Camp

第6章のディスカッションの時にうまく説明出来なかったので、この場を借りて言いたかった事を説明してみます。

対象のクラスのメソッドに対するテストと対象のクラスの状態をテストするためのテストが混ざっているような場合があると思います。
そんな場合@Enclosedを使うことで、テストを構造化出来るようになりました。
static classにすることで、明示的にお互いに依存しないように記述出来るようになります。
例えば、JUnit4.xの形式で書かれていたテストを構造化するのであれば、以下のような手順で出来ます。
  • 「@RunWith(Enclosed.class)」を追加する。(import句も)
  • 「public static class コンテキストの名称など {}」を追加する。
  • 内容をそのままstatic classに移動する。
このように新しいstatic classを作ってテストを追加することで、今までのテストも構造化することが出来ます。
新しいフィクスチャが必要になった場合も、新しいメソッドに対してテストを追加する場合も、必要に応じて追加することが出来ます。

JUnit3.xの場合は、TestCaseを継承しただけのテストであれば、setUpとtearDownなどをそれぞれ修正することで対応出来ますが、TestCaseを継承したテスト用の基底クラスを使っている場合は、いろいろと対応しなければならないことが多いので、優先順位とコストなどで判断してください。

もくもくと

後半はGroovyで書かれたテストにJUnitとSpockが同居することが出来るのか試してみました。
参考にさせて頂いたのは、@irofさんのこちらの記事です。→GroovyでJUnitなテストを書くときの注意点……なんて無かった #gadvent2012
同居させるために、Spockのversionを0.6から1.0へ上げました。
0.6では出来ないということに気づいたのは終盤だったので、ちょっと勿体無かったです。

おわりに

今回は、対象範囲が広かった為か終盤はスタミナ切れしてました。
次回は、適度につまめるような何かしらスイーツを用意して見たいと思います。

一番の収穫としては現場でも使えそうな@Ruleや@RunWith(Categories.class)を知ることが出来たので、活かして行きたいと思います。

主催の@shinyaa31さん、参加者の皆様、横浜タネマキさんありがとうございました。
次回もよろしくお願いします。

2012年9月3日月曜日

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

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

ペアプロ中の気づき

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


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

参加者の方から、言語の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さん、参加して下さった皆様、スタッフの皆様、会場を提供して下さった株式会社アットウェア様、ありがとうございました。

2012年7月19日木曜日

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ソフトウェア様ありがとうございました。

2012年7月10日火曜日

G*ワークショップ「非同期並列なG*」+JGGUG総会 に参加してきました #jggug

G*ワークショップ「非同期並列なG*」+JGGUG総会
http://kokucheese.com/event/index/41799/

2012/07/06_G*ワークショップ「非同期並列なG*」+JGGUG総会 #jggug
http://togetter.com/li/333348

きっかけ

Startup Groovyから、IntelliJ IDEAでGroovyを使うようになりました。Community Editionのキーマップを慣れているeclipseに変更して使っています。
JGGUGの勉強会は、まだ行ったことがなかったのでステッカーに釣られて申し込みました。

GroovyCSPによる並行処理

Communicating Sequential ProcessesをJavaで実装したJCSPをGroovyでwrapしたのがGroovy CSPです。
GParsで利用できます。

プロセスとチャネルの話と、Ray Tracingのデモがありました。100%使い切ってるのに割り込み制御が即座に実行される様をみると並列処理の凄さを見ることが出来ました。
あと低消費電力のWebServerとしては、スリープ状態からアクションが起きたら実行してまたスリープに戻るといったことが出来るようになるそうです。

CSPモデル自体全く知らなかったので、調べてみたいと思います。

Grails/Groovyの開発活用術~Java EE資産を活かして開発を加速する~

Grailsの導入事例とGrails2.1のお話でした。
Grailsはまだ触っていなかったのですが、面白そうだと感じました。
開発補佐としてGrailsやGebなどのテストフレームワークも含めて徐々に使っていければいいなと思っています。

Grails2.1の詳細は、こちらから。
Grails 2.1.0 GA リリース!
http://d.hatena.ne.jp/mottsnite/20120705/1341495778

G*Magazine Vol.5のepub版はこちらのサービスを利用して作られたそうです。
Mybetabook
http://mybetabook.com/index_ja.html
jggug - 日本Grails/Groovyユーザーグループ
http://beta.mybetabook.com/u/jggug/

最後に

懇親会でgroovyでexcelからxmlに変換する仕事で使うツールを書いていますという話をしたところ、@nobeansさんにGExcelAPIを教えていただきました。ありがたく使わせて頂きます。

JGGUGの皆様、参加された皆様、会場を提供して下さったNTTソフトウェア様ありがとうございました。

2012年2月19日日曜日

StartupGroovyに参加してきました #StartupGroovy

StartupGroovy
http://kokucheese.com/event/index/26942/

以前のTDDBC横浜でSpockのテストコードが綺麗だったのが、印象に残っていました。
SpockはGroovyで実装されているので、Groovyを勉強したいと思ってました。
このイベントを知ったきっかけは、twitterのTLで告知が流れてきたことでした。


プログラミングGROOVY

とりあえずイベントが始まる前までに青い本を読んでおこうと思い購入。
読んでいると何かワクワクするようなそんな印象を受けました。

印象に残ったのは、ハンズオンの形式がテストから実装をしていくだったことです。
GroovyはJavaの文法でも書けるので、自分の場合以下の手法を取りました。
  1. テストを失敗させる。
  2. Javaで書いてGreenにする。
  3. 青い本やネットで調べて、Greenの状態を維持しながら、Groovyで書く。
推奨されたIDEがIntelliJ IDEAだったため、普段使っているEclipseと違い、
なかなか思ったとおりには進みませんでした。
ただ、コード補完とJavaを拡張したAPIのおかげで助けれられました。

StackTraceだけだと、
  • 行のどこが間違ってるのかわかりにくい
  • パラメータの値はログに出力するか、デバッグしないと見えない

ということがあるで、Power Assertによって視覚的になるのはありがたかった。

ハンズオンが終わった時に全部Greenで終わっていて達成感があるのは、いいですね。
あと、ぷりんどらめっさ美味かった。これを知れただけでも行った甲斐があった。
次のステップへ進むために、利用したソースをSpockでテストするのをやってみようかなと思います。
その次はGradle。
まずこの2つを使えるようになって、Javaの単体テストを効率良くできるようにしたいです。

主催してくださった@kyon_mmさん、スタッフの皆さんお疲れ様でした。

とても楽しい一日をありがとうございました。