Groovy on yusuiked's blog

Groovy で寒い冬を乗り越える話 #gadvent

yusuiked@gmail.com (yusuiked) — Sun, 06 Dec 2015 08:00:00 +0900

これは G* Advent Calendar 2015 の 6 日目の記事です。

昨日は @saba1024 さんの [Groovy]RatpackでシンプルなWEBアプリケーションを開発する -JSONとJSONPを扱う- でした。

明日も @saba1024 さんです。

前置き

自宅、寒いんですよ。鉄筋かつ建物自体が古いのもあってか、断熱性が悪くて家に帰ってエアコン付けてから温まるまで、結構時間かかります。みなさんもこういう経験よくあるんじゃないでしょうか。先に帰宅した者負けみたいな。

マーティがホバーボードに乗ってるはずの 2015 年にもなって、出先からエアコンを付けられないなんておかしい！！！１１１

とゆーことで、買いました。IRKit。

IRKit - Open Source WiFi Connected Infrared Remote Controller

割と有名だと思うので、ここで IRKit がどういうものかという説明はしませんが、ざっくり言うと WiFi で繋がる学習機能付き赤外線リモコンです。また、HTTP をおしゃべりできるので、あんなことやそんなことがいろいろできちゃいます。

IRKit は基本的には家の中のネットワークから使うのですが、IRKit にはインターネット越しに信号を送れる Internet HTTP API もあったりして、至れり尽くせりです。ただ、一つだけ面倒な点があって、赤外線データは IRKit 自体ではなく iOS アプリが保持する仕組みになっているため、家族のスマホで共有するのが面倒という事があります。

なので、情報自体は一つにしてしまって、外部から自由に信号を送れたら、冬でも暖かい生活が送れる！と思っていろいろ調べていたら、同じことを考えている人はいるもので、すでにあるんですね。

IRKitの自分専用APIサーバ＆自分専用UIをHerokuに立てて快適生活を目指す - As a Futurist…

あるんですが、Ruby です。まぁ、そのまま Ruby で使っても良かったんですが、なんとなく、Ruby にあるなら Groovy（か Java）にもあるやろ！！と思って、探してみたんですが無いんですねこれが。

そこで、せっかくなので作りました。

Girkit
Girkit-api-server

Girkit

github.com

はい、ruby-irkit のパクりインスパイアです。本当にありが（ry

読み方は「じゃーきっと」で、これは IRKit のクライアントライブラリになっています。できることは本家と同じで、

今こそッ、始めようGrailsブートキャンプ!!!! に行ってきた #jggug

yusuiked@gmail.com (yusuiked) — Sat, 24 Oct 2015 23:39:50 +0900

いつもの NTTソフトウェアさんで。

jggug.doorkeeper.jp

Grails も3系になり、Spring Boot をベースに生まれ変わったということで以前ちょこっとだけ触ってみたことがありましたが、再度自分の理解を確かめる意味で参加してきました。

内容

Grails 3.0.9 を使って簡単な Todo アプリを作るハンズオンでした。@yamkazu さんの資料が素晴らしすぎて、これを読みながら手を動かしていくことでざっと Grails 3 での開発の流れを実体験できる仕上がりになっています。これ Grails 3 の日本語の入門資料として今のところ最適なんじゃないでしょうか。

github.com

成果物

私もこれに沿って Todo アプリを作ってみました。カンタン。

github.com

感想とかメモ

ドメインクラスを指定するだけで基本的な CRUD のメソッド（save, delete, list, get）が勝手に生えてる

class Todo {
    String content
    
    static constraints = {
        content blank: false, maxSize: 20
    }
}

def todo = new Todo(content: 'hogehoge')
todo.save() // Create

def todos = Todo.list() // Multi read
def todo = Todo.get(1) // Read
todo.content = 'updated.'
todo.save() // Update
todo.delete() // Delete

環境ごとに設定を変える仕組みが最初から備わっている

environments に development, test, production と環境ごとに設定ができる

// BootStrap.groovy で起動時の処理を記述できる
class BootStrap {
    def init = { servletContext ->
        environments {
            development {
                // run-app で立ち上げた時のモード
            }
            test {
                // test-app でテスト実行した時のモード
            }
            production {
                // war, jar で動かしている時のモード
            }
        }
    }
}

コントローラについて

Controller と Action メソッドが URL に対応している

渋谷 JVM に行ってきた #渋谷JVM

yusuiked@gmail.com (yusuiked) — Sun, 19 Apr 2015 23:25:02 +0900

d-cube.connpass.com

JVM そのものではなく、JVM の上で動く言語についての会でした。申し込み人数が100人超えしていたけど、最終的には90人くらいに落ち着いてた。

連休に入るとサーバが故障するとか、ヘソ曲げてるとしか思えない

— Yusuke Ikeda (@yukung) 2015, 4月 18

出かける直前にサーバのアラートが来ちゃって*1、なんだかんだバタバタしてしまい10分くらい遅れて到着したけど、セッション自体はまだ始まってなかったのでセーフ。

まとめはこの辺

togetter.com

とか、

とか。shigemk2 さんの記事は素晴らしくまとまっているので、詳細な内容はそちらでどうぞ。 

Scala セッション（@takezoen さん）

竹添さんの言語遍歴と Scala に出会ってからのお話。Java 以外にも Lisp、Haskell、Clojure といろいろ変遷があって、人に歴史ありだなーと勝手に思ってました。会社入って早い段階でポール・グレアムの本を読んでいたとか、当時の自分は存在も知らなかったしすごいなーと思いつつ。2011年〜2012年辺りの Java の停滞感と、当時の Scala の Java にはなかった熱気が、竹添さんを Scala に誘ったといった辺りも、なるほどなぁと思いながら聞いてました。途中、Java の停滞期の話をしている途中で竹添さんの PC から Java アップデートのお知らせが来てスライドが中断するという奇跡が起こって会場が盛り上がってたｗ

たけぞえさんへの Java からの悲痛な叫びｗｗ #渋谷JVM

— Yusuke Ikeda (@yukung) 2015, 4月 18

本が出るまで待てない!? Gradleハンズオン - G*ワークショップZ Oct 2014 に行ってきた #jggug

yusuiked@gmail.com (yusuiked) — Sun, 26 Oct 2014 22:48:31 +0900

最近ずっと使ってます。Gradle。

今仕事でやってるプロジェクトも Gradle を使っているので、なんという俺得なタイミング、ということで行ってきました。

Gradle 本出版記念ということで、参加者だけのありがたい特典もありました。行ってよかったデス。

コンテンツ

@nobusue さんの Gradle イントロダクションと 2.0,2.1 の主な変更点
- Gws 20141024 gradle_intro from Nobuhiro Sue
@literalice さんの Gradle プラグインハンズオン

LT

@kyon_mm さんの Gradle 2.2, 2.3 の変更点おさらい
@nobeans さんの OSS 開発の嗜み話
- すいません、資料見つけられませんでした

以下、学び

plugins ブロックとプラグインポータル

Gradle2.1 で追加された
3rd party のプラグインを使うときにより簡単になった

buildscript {
    repositories {
        jcenter()
    }
    dependencies {
        classpath "com.bmuschko:gradle-tomcat-plugin:2.0"
    }
}
apply plugin: "com.bmuschko.tomcat"

〜2.0までこう書いていたのが、

plugins {
    id "com.bmuschko.tomcat" version "2.0"
}

これで良くなった。ただしプラグインポータルに登録されていることが前提。

インクリメンタルコンパイル

Gradle 2.1 で追加された
変更のあった Java ソースのみ再コンパイルする

Tellurium を試してみた

yusuiked@gmail.com (yusuiked) — Tue, 27 Dec 2011 03:02:21 +0900

もう25日は過ぎてしまいましたが、自重せずに G* Advent Calendar 2011 : ATND 27日目の記事行かせていただきたいと思います。
初めまして、id:yukung/@yukung と申します。Groovistな皆様、お手柔らかにお願いいたします。

最近、ノンブロッキングI/Oな仕事をしているので、当初Grettyについて書こうかなーと思っておりました。そうしたら見事に @toby55kij さんとネタがかぶってしまったので（Grettyで割り勘計算機 #gadvent2011 - Toby55@新潟の日常）、慌ててここを漁って違うネタを探して若干焦りました＞＜
Groovy - Modules の中で、Telluriumがちょっと面白そうだなーと思ったのと、ググッてもあまり日本語の情報がなかったので*1、書いてみようと思います。というわけで、急造な記事なのでちょっと浅いかもしれませんが、ご容赦ください。

Tellurium って？

Tellurium は、GroovyとJavaで実装されたWebアプリケーション向けのテスティングフレームワークです。この分野には、Webブラウザの操作をエミュレートしてWebアプリケーションの自動テストを可能にしてくれるSeleniumという有名なツールがありますが、TelluriumはそのSeleniumを基盤にして構築されています。というか私が触ってみた感想は、平たく言ってSeleniumをDSLで書けるようにしたGroovy/Javaラッパーな感じです。

Selenium との違い

公式サイトによれば、TelluriumはSeleniumとの違いを、テストコンセプトの違いと定義しています。また、Seleniumを「C言語」のようなものであるとすれば、Telluriumは「C++」のようなものだ、とも言っています。なんだかわかったようなわからないような感じですね。

UI要素の扱い

Telluriumでは、UI要素の記述を「UI module」として扱えることをSeleniumに対するアドバンテージとして捉えているようです。
RIAやAjaxなど*2、リッチなWebアプリケーションが一般的になってきた昨今、Webのインテグレーションテストも重量級になってきがちなところに対する一つの答えとなるのがTelluriumのゴールのようです。

主なメリットとしては、

JavaScript Eventをトリガーにした動作
Ajaxアプリケーションのサポート
変更に対する堅牢性と柔軟性
メンテナンスの容易さ
UI module の再利用性
表現力（DSLで書けるなど）

といった所が挙げられています。

私はSeleniumを仕事では使っていませんし、使いたいなーと思って入るものの今のところヘビーユーザーでもないので、相違点について細かいところはあまりわからないのですが、例えばSeleniumでボタンクリックするような挙動を記述したいときは、

   selenium.click("//div[3]/input[@value='Create']");

こんな風に書くと思いますが、TelluriumではGroovyを使って、

    ui.Form(uid: "Form", clocator: [tag: "form"]){
        Div(uid: "User", clocator: [:]){
            Selector(uid: "Sex", clocator: [:])
            InputBox(uid: "Input", clocator: [tag: "input", type: "text", name: "j_username"])
        }
        Container(uid: "Finish", clocator: [tag: "tr"]){
            SubmitButton(uid: "Submit", clocator: [tag: "input", type: "submit", value: "Login", name: "submit"])
        }
    }

こんな風に、UI要素だけを分離して書くことで、テスト箇所のUI要素と、実際のテストコードを分離することができます。また、UI要素を階層構造で記述するので、モジュールとしての再利用性も期待できます。
UI要素など、変更が頻繁にかかる箇所はGroovyのDSLでライトに書いてカプセル化し、テストコードは使い慣れたJUnitやTestNGなどで書くことによって、UIの変更に大きな影響を受けず、かつUI要素をモジュール化して再利用できる、ということが主なメリットのようです。