2014-11-21

『Java最強リファレンス』をいただきました

Java

java最強リファレンスも読みたいなー |дﾟ)ﾁﾗｯ
— Takafumi Ikeda (@ikeike443) 2014, 11月 11

先日~~わざとらしく~~何気なく上記のようにTweetしたら、著者の @yuichielectric さんにご献本いただきました。ありがとうございます！

Java最強リファレンスいただきました！ @yuichielectric さん、ありがとうございます！ pic.twitter.com/IueGU11rtL
— Takafumi Ikeda (@ikeike443) 2014, 11月 13

読ませていただきましたのでご紹介をば。

Java 最強リファレンス

作者: 田中裕一
出版社/メーカー: SBクリエイティブ
発売日: 2014/10/27
メディア: 大型本
この商品を含むブログ (1件) を見る

この本は名前の通りJavaのリファレンスです。通読するというよりは、用途に応じて参照するのが正しいでしょう。
この本が素晴らしいのは、基本的にすべての項をJava7, 8といった最近のバージョンをベースにして解説されているところです。*1
大変な労作です。

ラムダ式やメソッド参照、Optionalについても "Javaの基礎" という章で解説していますし、Streamについても一章割いてきちんと解説しています。
Fileの読み書きもJava8のStream APIを使った書き方を中心に紹介しているところが大変好印象で、新しいJavaの効率的な書き方がよくわかります。*2

Stream API の後ろで使われている Fork/Joinフレームワークの解説や、Fork/Join 自体の使い方にも触れているところもよいです。ScriptEngine(nashornですね)にもきちんと言及していて、いいリファレンスだと思います。

全体的に標準パッケージのみを解説の対象としているのも潔く、読みやすくなっていると思います。

惜しいのは Servlet にも触れているところかなあと思います。Servlet は JavaEEですし標準パッケージとは言いがたく、若干蛇足かなと思いました。Web 開発編みたいなものを別途出したほうがいいんじゃないかと思ったけど、Servletを入れないと売れない、っていう判断があったんだろうなあと邪推しました。。

Jettyのようなサードパーティのライブラリ説明をするのに、Mavenのようなビルドシステムの説明がないのは片手落ちな気がしましたし、セッションの説明についても http はステートレスだって書いてるそばからサンプルコードの中でsession.sethogeしており、セッションの永続化をどうするかについて特に説明がないのがちょっと気になりはしました。*3

ですが、気になったのはそこくらいで、Javaの包括的なリファレンスで、最新のJavaをベースに丁寧な解説があるのはとてもとてもポイントが高く、Java開発者であれば必携の書であると思います！

僕も現場の若手に薦めようと思っています。

Java 最強リファレンス

作者: 田中裕一
出版社/メーカー: SBクリエイティブ
発売日: 2014/10/27
メディア: 大型本
この商品を含むブログ (1件) を見る

@yuichielectric さん、執筆お疲れ様でした。そして出版おめでとうございます！

*1:この本自体はJava5〜8を対象にしています

*2:もちろん5,6,7の書き方も併記されています

*3:そのままだとステートフルになってしまうと思うのでセッションレプリケーションの解説をするか、外部ストレージ（RDBやmemcached）に永続化することを説明したほうがいいんじゃないかと思いました

2014-10-13

Jenkins + Maven3.2.1 で IllegalAccessError on AbstractMapBasedMultimap

CI Jenkins Java maven

メモ。時間があるときに調べる。
Maven3.2.1とJenkins1.581のCoreとで依存しているGuavaのバージョンが違っていることが遠因になっていくつかのプラグインが動かなくなっている。（下記参照）
[#JENKINS-22252] Maven 3.2.1: IllegalAccessError on AbstractMapBasedMultimap - Jenkins JIRA

JenkinsでMavenプロジェクトを作って静的解析をしていて下記のようなエラーが出ていたらこの問題に該当すると思って良さそう。PMD, CheckStyle, FindBugs全て同じ。静的解析以外でも問題が起きそうだけど、今のところ聞いてない。

java.io.IOException: Remote call on channel failed
	at hudson.remoting.Channel.call(Channel.java:748)
	at hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:168)
	at com.sun.proxy.$Proxy7.execute(Unknown Source)
	at hudson.maven.MavenBuildProxy$Filter.execute(MavenBuildProxy.java:206)
	at hudson.plugins.analysis.core.HealthAwareReporter.registerResultsOnMaster(HealthAwareReporter.java:325)
	at hudson.plugins.analysis.core.HealthAwareReporter.postExecute(HealthAwareReporter.java:316)
	at hudson.maven.Maven3Builder$MavenExecutionListener.recordMojoEnded(Maven3Builder.java:628)
	at hudson.maven.Maven3Builder$MavenExecutionListener.mojoSucceeded(Maven3Builder.java:610)
	at hudson.maven.Maven3Builder$JenkinsEventSpy.onEvent(Maven3Builder.java:306)
	...
Caused by: java.lang.LinkageError: Failed to load com.google.common.collect.AbstractMapBasedMultimap
	at hudson.remoting.RemoteClassLoader.loadClassFile(RemoteClassLoader.java:326)
	at hudson.remoting.RemoteClassLoader.findClass(RemoteClassLoader.java:236)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
	at java.lang.Class.forName0(Native Method)
	at java.lang.Class.forName(Class.java:270)
	at hudson.remoting.MultiClassLoaderSerializer$Input.resolveClass(MultiClassLoaderSerializer.java:113)
	... 
Caused by: java.lang.IllegalAccessError: class com.google.common.collect.AbstractMapBasedMultimap cannot access its superclass com.google.common.collect.AbstractMultimap
	at java.lang.ClassLoader.defineClass1(Native Method)
	at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
	at java.lang.ClassLoader.defineClass(ClassLoader.java:643)
	at hudson.remoting.RemoteClassLoader.loadClassFile(RemoteClassLoader.java:322)
	... 39 more

Workaroundとしては、Mavenプロジェクトをやめてフリースタイルプロジェクトで作るか、Mavenのバージョンを3.0.5くらいまで落とせば一応動く。細かいバージョンの組み合わせは試してないが、まあ3.0.5まで落とせば大丈夫っぽい、という程度の理解をしている。

これ結構直すのは面倒そうだなあ。JenkinsのGuavaバージョンをあげるのか、各プラグイン側でWorkaroundな修正を入れるのか。。

2014-02-09

maven-archetype-quickstartが未だにJUnit3.8.1使ってる件

Java maven

どうにかならないんでしたっけ。。

mvn archetype:generateすると、下記のように344（maven-archetype-quickstart）を勧められて、

$ mvn archetype:generate
略
913: remote -> tk.skuro:clojure-maven-archetype (A simple Maven archetype for Clojure)
914: remote -> uk.ac.rdg.resc:edal-ncwms-based-webapp (-)
Choose a number or apply filter (format: [groupId:]artifactId, case sensitive contains): 344:

言われるがままにプロジェクトを作って、出来上がったpomを見ると、JUnit3.8.1。。

<dependencies>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>3.8.1</version>
      <scope>test</scope>
    </dependency>
</dependencies>

この問題は既に下記チケットで報告され、既に修正されているっぽく*1、次回リリースの1.2に含まれそうだが。。
http://jira.codehaus.org/browse/MARCHETYPES-41

セントラルリポジトリを見てみるとまだ1.2はリリースされてない。。
http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.apache.maven.archetypes%22%20AND%20a%3A%22maven-archetype-quickstart%22

ちょ、困るんですけど。。maven-archetype-quickstartのMLどこなん。。とりあえずチケットAssigneeのOlivierってのにメールしてみたけど。。。

*1:Diffくらい貼れよと思った

2012-07-18

第3回Playframework勉強会 #play_ja をやりました

Java Scala Play!

去る7月14日、勉強会をやりました。

下記がその要項です。
http://playframeworkja.doorkeeper.jp/events/1231-%E7%AC%AC3%E5%9B%9Eplayframework%E5%8B%89%E5%BC%B7%E4%BC%9A-play_ja

70人で募集をかけたところ、3時間で満席になってしまいました。本当にありがとうございます。
最終的にはキャンセル待ちの方が75人にまでふくれあがりましたが、実際のところ現場に来場されたのは54人でした。

場所は@i2keyさんのご好意で、リクルートメディアテクノロジーラボさんの超シャレオツな会場を借りることが出来ました。
本当に本当にありがとうございました！

Ust録画

下記の通りバッチリあります。
リクルートメディアテクノロジーラボさんの開場は、いろいろ設備が充実していて驚愕です。
とてもクリアにスライドが録画されている上、音声もマイクでバッチリ拾えているので、この上ない臨場感です！

Video streaming by Ustream

当日のタイムテーブルと資料一覧

発表者	タイトル
@ikeike443	Playアップデート
@i2key さん	MediaTechnologyLabsの紹介 Play2.0+JavaでAPIサーバを開発しているiPhoneアプリの紹介
@tototoshi さん	Play20 + Scala について
@kara_d さん	2.0Javaのオススメと、1.2からのアップグレード
@daiksy さん	Play2.0 + Scala での開発事例

LT分

発表者	タイトル
@garbegetown さん	ドキュメント翻訳について
@masahito さん	Play2.Xドキュメント翻訳について
@seratch さん	plugin 開発の導入
@たけぞうさん	;Play1.2.X系＋Scalaの話
@gakuzzzzさん	Play20-auth の話か DDD on Play20 みたいな話
@puriketu99 さん	おしべめしべシステムからplayをはじめよう

というわけで、またやりましょー。次は4ヶ月以内くらいにこれくらいの規模でまたやりたいです。

2012-01-07

なぜ Play は Servlet を使っていないのか（Why there is no servlets in Play 翻訳）

Java Play!

まだ正月休みなのです。暇なので訳してみました。

この記事は 1年半以上前に Play の生みの親である Guillaume Bort がブログに書いたものです。
(2012/8/19追記: リンク切れしていたためリンクを貼り直しました)

なぜ Playframework では Servlet が一切使われていないのかについて、簡潔に書いています。

丸山先生が Play に注目し始めた今、Play2.0 のリリースが間近に迫った今、あらためて読むと面白いかも知れません。

なぜ Play は Servlet を使っていないのか

Servlet API に準拠せずに Java web フレームワークを作ることはかなり変に思えるかも知れない。大抵の人はなぜこんな普通じゃない選択をしたのかを聞いてくる。気に入ってくれる人も何人かいるが、大半は毛嫌いする。正直に言うと、 Play フレームワークの一番最初のバージョンは Servlet を使い、Servlet コンテナの上で稼働するようになっていた。しかし、この要件を外すに至ったのには幾つもの理由がある。説明してみよう。

Play フレームワークの重要な特徴は2つある（他にも多くの特徴がある中でも）：完全なステートレスアーキテクチャモデルの上に構築されていること、魔法のように自動的にコードの変更を反映すること。実際、この2つの特徴は密接に重なり合っている。

コードのホットスワップを可能にするには、アプリケーションをステートレスに作ることが欠かせない。あなたは疑問に思ったことはないだろうか。なぜ PHP ではホットスワップ出来るのに、JEE だと出来ないのか、と（ここで言っているのは、バックグラウンドで war をデプロイし直すのではなく、本当にアプリケーションコードをホットスワップするという意味だ）。PHP に出来るのは PHP は徹頭徹尾ステートレスだからだ。PHP の場合、2つの連続したリクエストの間で、都度まっさらな新しいプロセスが起動する（確かに今は FastCGI を使っていくらかの最適化を図ることがあるが、根本的なモデルを変更するわけではない）。アプリケーションがステートレスでなかった場合、コードスワップの後にメモリ上の状態を再構築することなんてできない。きちんと動くケースもあるだろうが、重要な変更があった場合はまず動かないだろう。

Play をステートレスな web フレームワークとして作ることにした理由は、コードのホットスワップを実現したかったからだけではない。この話はこのポストの論点ではないが、基本的に、WEB 自身がステートレスアーキテクチャを採用しているのがその理由だ。そして WEB がステートレスアーキテクチャを採用していることにも幾つものとてもいい理由がある。

Servlet API を使ってステートレスなアプリケーションを作ることは可能だ。しかし、HttpSession や servlet の forward の仕組みなどを使わないようにしなければならない。Play フレームワークの一番最初のバージョンではそんな風にやっていた。

しかし正味の話、皆 servlet API が好きだから使っているわけではない。Servlet API がこれまで考案された HTTP API の中でもダメな部類であるという事実には皆同意している。だが、servlet filter とかその他色々な servlet に依存したコンポーネントを再利用したいがためにこの API を使っているのだ。

これらのコンポーネントは、大抵の場合設計がまずいという問題を抱えていることが多い。開発者の知らないところで、HTTP リクエストのオブジェクトとレスポンスのオブジェクトをごっちゃにしてセッションに格納したりする。だからこのようなコンポーネントをインストールすると、Play の初期処理で行っているステートレスな取り決めを破壊したり、クラスのリロードやキャストに多くの問題を引き起こしたりする結果になり得る。これは Play で書かれたアプリケーションコードをリロード出来るようにするために、コードを Play のカスタムクラスローダーの中で動かしている理由でもある。そして Servlet コンポーネントは Servlet コンテナのクラスローダーの中で動いている必要がある。これらのコンポーネントを協調して動かす必要があるのだろうか？もちろんあなたにはあるだろう。そしてそれは悪夢となる。

実際のところ、Servlet ベースのコンポーネントには2種類ある。私がこの問題に直面したのは、Play 用の captcha ライブラリを探していた時だった。2種類あるうちの一方に属するライブラリ群の作りは、2つの層に綺麗に分かれていた。1つは captcha を生成するロジックで、もう1つは Servlet API との結合だった。もう一方に属するライブラリ群はぐちゃぐちゃにコードが折り重なっていて、Servlet API なしには利用することが出来ない作りだった。よく出来ている方のライブラリを Play にインストールした場合、Play のユーザーはそれを使って本来の面白い部分を作ることに集中することが出来るが、ダメな方のライブラリをインストール出来てしまった場合、ユーザーのアプリケーションは壊れてしまう可能性が高いだろう。

最後に、我々が Servlet API を金輪際使わないことにしたのにはもう一つ理由がある。Servlet コンテナはオールドファッションな ”1リクエストにつき1スレッド” モデルを採用している。幾つかのアプリケーションにとってはそれでも問題ないだろう。だが、Ajax とロングポーリング呼出しが必須となった今日において、これでは不十分だ。

根本的な問題は、 JEE サーバと HTTP 層を結ぶには Servlet APIを使う以外に選択肢がないことだと思う。おそらく、 java のエコシステムには Rack の様なものが必要なのではないだろうか。つまり、HTTP を扱う本当に低レベルでポータブルな API が必要だと思う。少々欠陥のあるアーキテクチャ原則に基づいて構築された、半ばでたらめな HTTP API ではなく。

2011-12-01

Play! framework 概要 Tipsもあるよ！

Scala Java Play! node.js

Play! Advent Calendar 2011 一日目ということで、軽めの話をします。

おさらい：Play!とは

Play!はJavaで軽量に素早く開発できるフレームワークです。

Play!についてよく知らない人が圧倒的多数だと思いますので、ものすごく簡単に説明しますね。

Play!はJavaEEの仕様を捨ててWebとフォーリンラブすることに決めたフレームワークなので、Servlet特有の変なセッション仕様なんてないですし、えっと、セッションレプリケーションってなんですか？　ってなノリのフレームワークです。
もちろん、warにパッケージングする必要もないです。

EclipseのECJを使って動的コンパイルを行うことで、ほんとうの意味でのホットデプロイを実現しています。というか、デプロイしないんですけど。。まあ、ほとんどスクリプト言語のようにJavaを使えるわけです。再起動無しで変更が反映されるって素敵。

モデル周りは、JPA、っていうかこれJPAなのかなー。。って思うくらい手を入れてますが、そのおかげでPlayではDBスキーマの変更もJavaのコードを書き換えるだけで自動でやれちゃいます。DBスキーマの変更も再起動無しでやっちゃうわけですね。
もちろん、この機能はプロダクション環境で動作すると危険ですので、環境によって動作を変えるなんてのも容易です。

今時のプラグインが揃ってる

プラグインシステムも用意されています。
ここを見ると分かるんですが、Javaとは思えないイケてるラインナップっぷり。
MongoDB、Redis、CoffeeScriptやSASSなんて当たり前のようにサポートされています。

Play!を好んで使う開発者っていうのが、どんな人達なのか、よくわかると思います。
HerokuがネイティブにPlayをサポートしたのも当然だなあなんて思いますね。

ノンブロッキングもあるよ！

また、最近Node.jsで注目度を高めたノンブロッキングI/Oもサポートしています。興味のある人はこのへんのコード *1や、このへんのコード *2を読んでみるといいと思います。また、多分誰かがこの辺詳しく突っ込んでくれるでしょう！

これでノンブロッキングI/Oといえば、JavascriptならNode.js、PythonならTwisted、RubyならEventMachine、JavaならPlay!と言えるわけです。よかったですね！

Node.jsとPlay!を比較した記事なんかもありました。レンダリングを除いたI/O部分だけ見れば、Play!はNode.jsに比肩する部分もある（2011年3月時点の話）んですよね。レンダリングを含むとNode.jsには全然勝てないんですが。。
詳しく知りたい方は、翻訳しておいたので下記を見てください。まあこの記事は半年も前なのであまり参考にはならんかもですが。。
https://www.evernote.com/shard/s18/sh/d356225c-93ab-4fb2-9a7c-178eb23045e9/d82052027a5bb481579eaa4691d53dfb

そしてScalaへ、そしてPlay2.0へ

っていうここまでが、Playの1.x系のお話。
このへんの話はこのスライドにもまとめてあるので、ぜひ読んでください。

で、こんなイケてるフレームワークを作ったPlayの連中は、やっぱりJavaの世界では異端児なのか、それほど広く受け入れられてるとは言いがたいと思います。特に日本国内では知名度含めて結構絶望的ですし、JavaEEを完全無視しているせいで、キワモノ扱いを受けてますね。

彼らはScalaをサポートし始めました。1.1からScalaプラグインを作ってサポートを始めます。
日本国内では、このへんのエントリをきっかけに、ScalaのフレームワークとしてPlay!がプチブレイクし始めた感ありますよね。

そして、Play2.0です。

彼らはついに、Play!をScala フレームワークとして一から書きなおし始めてしまいました。*3

この判断が正しかったかどうかはまだわかりません。大きな賭けだと思います。ただ、このままJavaのちょっと変わったフレームワークとしての地位に甘んじるよりも、Scalaの未来に賭けよう、という姿勢を僕は支持します。

2012年はPlay!とScalaの年になるでしょう。
"Play2 with Scala in Action"という書籍も出ますし、なによりScalaの総本山であるTypesafeがPlay2.0をテクノロジースタックとしてサポートすると表明しましたから。

という訳で、一日目はPlayの概要についておさらいして見ました。
これだけで終わると寂しいので、1.x系のTipsを幾つか紹介します。

Play! 1.xのTips

CookieにSecureフラグを付与する

httpsでCookieをやり取りする際は、secureフラグを立てたいのが普通だと思います。
Play!はデフォルトのままだとsecureフラグを自動でたてたりはしてくれませんので、明示的にapplication.confに下記を設定してやる必要があります。

application.session.secure=true

この辺は、私が1年半前にバグ報告した結果付いた機能です。昔はこれも出来なかったんですよね。。
http://d.hatena.ne.jp/ikeike443/20100505/1273040748

Memcachedハマリ道（というかapplication.confの癖に注意）

Play!でmemcachedを使うのは簡単で、application.confに下記のように書いてやるだけで動きます。

memcached=enabled
memcached.host=xxxx:11211

memcachedを複数台立てて分散させたい場合は下記のように書くだけです。これだけでPlay!のCache API（の中で使われてるspymemcached）がよしなにしてくれます。

memcached.1.host=xxxx:11211
memcached.2.host=xxxx:11211
memcached.3.host=xxxx:11211
...

ところがちょっと罠があって、例えば開発環境においてはmemcachedサーバは一台しか立ててないけど、ステージング環境では複数台立ててますよ、みたいな状況で例えば下記のように設定してしまうと。。

#開発用
memcached.host=hogedomain:11211
#ステージング用
%QA.memcached.1.host=fugadomain:11211
%QA.memcached.1.host=bazdomain:11211

実はこうしてしまうと、Play!はIDなしの設定（memcached.host=hogedomain:11211）をIDありの設定よりも優先して有効化してしまうという癖がありまして、ステージング環境でもhogedomianのmemcachedを見に行ってしまい、想定外の挙動をしてしまってパニック、ってな感じのハマリ方をします。はい。昔ハマリました。。

なので、解決策としてはIDなしの設定をやめてしまって、開発環境にも明示的にIDを振ってやる、というのが解決策かなーと思います。

つまりこんな感じ。

#開発用
%DEV.memcached.host=hogedomain:11211
#ステージング用
%QA.memcached.1.host=fugadomain:11211
%QA.memcached.1.host=bazdomain:11211

この話、memcachedに限らず、log4jもそうですし、その他の割とあらゆる設定について言えることですので、覚えておくといいと思います。

Jobを環境によってOn/Offする

Play!には非同期Jobフレームワークが存在します。
play.jobs.Jobを継承して、@Everyか@Onといったアノテーションを書いておくと、それにしたがってスケジュール実行してくれる便利な機能です。詳しくは以前書いたのでこちらを見てください。

例えばこの機能を使って、あるサービスのAPIを定期的に叩いてデータを収集する、みたいなコードを書いたりするわけです。
プロダクションはそれでいいのですが、自動テストを組んだ時に困るわけです。
実はPlay!のauto-testコマンドの実行時に、Jobも動いてしまうんですよね。

というわけで、環境によってJobをOn/Offできるようにパッチを書いたのです。
http://d.hatena.ne.jp/ikeike443/20100824/1282656188

この機能を使えば、例えばapplication.confに下記のように書いておくだけで、環境によってJobのOn/Offを制御できるわけです。

%DEV.cron.JobA=5min
%DEV.cron.JobB=*    0    *    *    *    ?
%PROD.cron.JobA=5min
%PROD.cron.JobB=*    0    *    *    *    ?
%test.cron.JobA=never
%test.cron.JobB=never

ぜひご活用ください。

Dependencies

最後にDependenciesのTipsです。
Dependenciesコマンドを使うと、内部でivyが実行されて、依存関係の解決をやってくれます。
Maven リポジトリにあるものや、Playのプラグインリポジトリにあるものは暗黙的に解決してくれますし、それ以外のライブラリを解決したい場合は、dependencies.ymlに下記のように書けばいいです。

require:
    - play
    - Some -> SomeLib 1.4
    - Some -> SomeUtil 0.5
repositories:
    - SomeExternalLib:
        type:       http
        artifact:   "http://somedomain/repo/Some/[artifact]/[revision]/[artifact]-[revision].[ext]"
        contains:
            - Some -> SomeLib 1.4
            - Some -> SomeUtil 0.5

ただここで問題なのは、repositoriesのtypeです。
typeをiBiblioにすれば、Maven的に解釈してくれるので（バージョン番号じゃなくてmd5見て変更検知してくれる）、本来はそれでいいんですが、事情によりhttpにしたい場合ありますよね。

httpにしてしまうと、ライブラリに変更が入っても検知してくれないんですね。
というわけでちょっと（かなり？）強引ですが、ivyのキャッシュを強制クリアするオプションを作って取り込んでもらいました。
https://github.com/playframework/play/pull/322

これは次の1.2.4でリリースされると思うので、dependenciesで困ってるひとは活用してもらえると嬉しいです。キャッシュのクリアがかなり強引ですがね。。

以上です。次は@kara_dさんです。僕よりもさらに輪をかけたPlayラバーなので、期待できると思います！！

*1:Promiseが出てきます

*2:Continuationの実装があります

*3:ちなみにJavaも動きます。1.xはJavaで書かれたScalaも動くJava フレームワーク、だったのが、2.0は逆にScalaで書かれたJavaも動くScala フレームワーク、になったわけです

2011-10-09

第二回 Playframework 勉強会 in Tokyo やりました #play_ja

Play! Scala Java

10月8日にPlayframework勉強会をやりました。
http://atnd.org/events/19107

当初は30人規模の会場でやろうとしていたんですが、あっという間に定員を倍以上オーバーしてしまったため、急遽100人規模の会議室を借りて開催しました。
ニフティさんにも打診したのですが、既に同日は埋まってたので、お金を出して借りることになりました。。

そんな感じで困っていたところに、気前よく資金提供いただいた株式会社イージフ様と株式会社シャノン様には心から感謝します。
イージフ様は来週の木曜、ビックサイトで行われる「eドキュメントJAPAN2011」に、AlfrescoのCTOを招聘して、「オープンソースの視点から見るＥＣＭのグローバル市場」という題名で出展されるそうです。
ご興味のある方はぜひ足をお運びください。

勉強会を主催するのって、会場押さえたり設営したり懇親会の場所押さえたり、結構大変でしたが、やってよかったなと感じることが出来ました。
こうやって勉強会をやってみると、意外にPlayframeworkが好きな人、使ってる人が多いことに気づけて、とても心強い感覚を得られたのが収穫でした。

運営を手伝ってくれたシャノンのゆかいな仲間たち（@fujya, @yosu, @twintaro）、それから早めに来て手伝ってくれた@tan_go238さん、ありがとうございました！

さて、勉強会の発表内容について、下記に報告します。

Play! の紹介

一発目は私の発表でした。
内容的には、Playframeworkについてよく知らない人を対象に、特徴を30分で紹介するというものです。
Play! についてよく知ってもらうには実際にコードを書いて動かしてみせるのが一番いいだろう、ということでライブコーディングをやりました。
詳しくはスライドとUstreamの録画をご覧ください。
...と言いたかったのですが、ミスでこの部分は録画できていません。。さーせん。。

大体下記のようなことを紹介しました。

Play! はJavaEEの規約ではなく、Webのアーキテクチャに従う
シェアードナッシング、非同期I/Oといった特徴を持つ
Kloutや英ガーディアンなどが使っている
SASSやCoffieScript、MongoDBなどのプラグインがあり、新しいトピックへの反応が速い
HerokuやCloudbees、GAEなど、あらゆるPaaSにデプロイ出来る
Play2.0でさらに進化する

ライブコーディングの内容は下記内容のものを解説しながら10分で作る、というものでした。

DBアプリ
管理画面付き
JSONを返すREST API付き

ちょっと失敗したんですがｗ　
現場での雰囲気から推し量るに、このライブコーディングで伝えたかったPlay! の生産性の高さと分かりやすさについては、伝わったっぽいです。

と、いろいろ喋ったんですが、一番伝えたかったことを要約すると、下記の1行に尽きます。
JavaでWeb開発するのって、本来こんなに楽しいものなんだよ！！！

ぜひ資料をご覧ください。

What is play

View more presentations from Takafumi Ikeda

playdocja のこれまでとこれから

ここからはUstの録画つきです。（途中からですが。。）

@garbagetown さんは、Play!が出始めた初期の頃に日本語翻訳サイト(playdocja)を立ち上げて翻訳をしてくださっている方です。
私もすこーしだけ協力していますが、翻訳の90%以上は@garbagetownさんによるものと言っても過言ではないです。
いつもお世話になっております。

~~発表資料がアップされていないのでここに貼れていませんが~~（10月13日追記：アップされました）、内容としては下記でした。

playdocjaを立ち上げたきっかけは、Play!内部に組み込まれているDocViewerプラグインに気づいたこと
今回は翻訳の仕方をご紹介して、みんなを翻訳者として勧誘したいということｗ
playdocjaのホスト先であるGAEが値上げしたのでHerokuあたりに引っ越そうと考えていること

これを読んでいるみなさんはもちろん、翻訳協力してくれますよね？
興味のある方は@garbagetownさんに直接Twitterで話しかけるか、play_jaのMLに投稿頂けるといいかなーと思います。

play_jaで独自ドメイン取る？　って話もありましたが、ちょっと本当に検討したいですねー。

20111008

View more presentations from garbagetown

Play!で作る業務アプリケーション構成例

@genki_ さんによる、Play!で業務アプリを作っていますよ、っていうおはなし。

資料は下記です。
「業務で使うPlay!」

私も業務でPlay!を使っていますが、それは私が所属しているのが自社サービスをやっている会社だからできるのであって、SI案件でPlay!を提案して通したって言うのはすごいなーと思います。

Play!を使うとAOPも結構簡単に書けるし、業務アプリ開発にも全く問題ないよー、っていう発表でした。
これは参考になった方多かったのではないでしょうか？

また、@genki_さんは発表をiPadのkeynoteでされていて、iPadの画面を指でグリグリ触ってポインタを動かしていたんですね。
それもとても注目されていました。
iPadのkeynoteにあんな機能があるなんて知らなかった。。
そのへんも注目して御覧ください。

Play! + GAEで作ったアプリをPlay! + Heroku で動かすとどうなるか

@hagikuratakeshiさんによる発表。

Play!+GAEで作ったサービスを、Herokuに移行してみたよーっていうタイムリーでおもろい話でした。

みんなGAEの値上げには困っているみたいですね。。
Googleさんも商売なので値上げ自体はしょうがないと思うのですが、ベンダーロックインでこの価格帯だと、正直割りに合わないよねー、っていうのが会場とTLの雰囲気でしたね。。

@hagikuratakeshiさんの発表が面白いのは、ただHerokuに移行したよーだけで話が終わらず（これだけで充分興味深いんだけど）、MongoDBも使ってみたよ、Sienaで上手く動かなかったからSienaのMongoDB用PersistenceManagerを書いて動くようにしたよ、っていうところですよね。

Siena-MongoDBが本家にマージされることを期待して待ってます！

2011/10/08_Playframework_GAE_to_Heroku

View more presentations from hagikuratakeshi

LT

LTもやりました。5分×6人で30分を予定していたのですが、一人分枠が余ったので、最後に私もLTしましたｗ

大阪勉強会の続きのはなし

Play勉強会 in tokyo

View more presentations from Daisuke Kasuya

大阪勉強会でPlay! on GAEについて発表してくれた@daiksyさんが、なんと上京してくれました！！

また大阪でもやりましょう！

Play FrameworkでWebSocketを使ってSVGのビジュアルチャットを作ってGDD open call html5に応募してみたけど落ちました

Play FrameworkとWeb Socketの話

View more presentations from Kazuhiro Hara

@kara_dさんによるPlay!+WebSocketの話。
電車のなかで設計してラウンジオフィスで開発して帰りの電車でデプロイした、みたいな話をさらっとするあたりかっこいいすね！

WebSocketの仕様の変わりっぷりとか、Chromeのバージョンアップの勝手っぷりとかを軽くDisってましたが、私も共感しましたｗ

残念ながら5分で終わりませんでしたが、とても面白いLTでした。

Play!+WebSocketハッカソンを近々やる予定みたいです。
参加してみたいなー。

HerokuのPlay! 対応について

Herokuの多言語対応とPlay!

View more presentations from Mitsuhiro Okamoto

セールスフォース社のエバンジェリストである、@mitsuhiro 岡本充洋さんもいらしてくれました。
LT枠で、Heorkuについてかっこ良くプレゼンしてくれました。

資料の洗練されっぷりにみな圧倒されていました。

Herokuはとても開発しやすくて、いいPaaSだよなーと思いましたね。

5分で説明するPlay-Scala

5分で説明する Play! scala

View more presentations from masahitojp

@masahitoさんによる、Play! Scalaの紹介。
今回の勉強会ではScalaに関する言及が少なかったのですが、@masahitoさんがやってくれました。
開発の仕方から、Anormなどのモジュールの説明まで、分かりやすく紹介してくれました。

NettyはPlay!でどう使われてるのか的な話

Play Netty LT

View more presentations from Go Tanaka

@tan_go238さんによる、Play!内部でのNettyの使われ方に関するLT。
@tan_go238さんも大阪の勉強会の続きでLTしてくれました！
Play!の内部では、NettyというJBoss由来の非同期I/Oライブラリを使っているのですが、そいつがPlay!内部でどう使われているかについて、さらっと分かりやすく説明してくれました。

この辺のコードを読むとすごく面白いので、ソースコードリーディングもやりたいですね！て話を懇親会でしましたｗ
やりたいなあ。

Jenkins+Play!で気軽にCI

Jenkins+Play!で気軽にCI

View more presentations from Takafumi Ikeda

最後に、枠が余ってたので私がしゃべりました。
今年2月ごろにJenkins勉強会でLTした内容をもう一回しゃべりました。
Jenkins勉強会でやったときは5分で終わらなかったので、リベンジですｗ

ちなみに、見事5分以内にしゃべり終わりました！
やったね！！

懇親会

私は腸を痛めていたので飲めませんでしたが、私以外の皆さんはとても楽しく飲んでいましたｗ
いや、私もウーロン茶で楽しく語り合えてとてもよかったです。

Play!に興味を持っている人、既にぞっこんLOVEな人、いろんな方がいらっしゃいました。

とっても楽しかったです。

次回は？

次回はいつやりましょうかね。
2,3ヶ月後にはやりたいなーとは思ってるんですが。
発表形式でやるか、ソースコードリーディングやるか、または他のことやるか。

続きはMLで話しましょう！

また一緒にPlay!しましょう！！

Togetter、ブログなど

Togetterやブログなどのリンク集を下記にまとめておきます。
他にもありましたらTwitterか、このブログのコメント欄で教えてください。
追記させていただきます。
http://togetter.com/li/198173
http://d.hatena.ne.jp/moccos_info/20111008/p1
http://ponta027.blogspot.com/2011/10/playframework.html
http://d.hatena.ne.jp/dreamscrapround/20111008/1318112117
http://daiksy.blogspot.com/2011/10/2-playframeworklt.html
http://d.hatena.ne.jp/yosuke_furukawa/20111008/1318091648
http://blog.restartr.com/2011/10/10/play-framework-study-in-tokyo/
http://aws.lefthandz.org/wordpress/2011/10/play-framework-study/
http://d.hatena.ne.jp/Ehren/20111011/1318293303
http://d.hatena.ne.jp/garbagetown/20111012/1318449282

というわけで、enjoy play!

ikeike443のブログ

ソフトウェアビジネスに関心がある系のブログ