JavaOne2013 総括 : JavaOne2013 レポート6 #j1jp

まだ何件かセッションのレポートを上げる予定ですが、先に全体の総括を書かせていただきます。各セッションレポートはこちらから。

なぜ今回JavaOneに参加したか

今年の自分のテーマの一つが「技術力」。
昨年はどちらかと言うと、アジャイルやスクラムがおもしろく、かつ広げていくのが自分のテーマでしたので、マネジメントやチームビルディングなどのトピックスに興味がありました。
しかしその中で改めて、「自分はエンジニアである。コンピュータ技術者として改めてプログラミングと向き合いたい」という想いに気づきました。そこで、今年のOSC（OverSeas Conference。エンジニアを海外のカンファレンスに年一回行かせてくれる、弊社の大変すばらしいプログラム）は、JavaOneに行ってみたいと思うようになりました。

もう一つ後押しになったのが、以前にどこかのブログか何かで、新人エンジニア向けのメッセージとして「自分が使っているプログラム言語のカンファレンスに出てみよう」という記事を読んでいたことです。今年で職業エンジニア6年目になり、Javaとの付き合いも5年近くになる一方で、Java系のイベントへの参加経験は一度もなし。
一度Javaの最大のカンファレンスに出てみたいと考え、参加させていただくことにしました。

セッションを選ぶ段階での気付き

セッションがたくさんあるとは聞いていたのですが、いざSchedule Builderが公開されると、本当に本当に多くのセッションの中から選ぶことに驚きました。

単に数が多いだけでなく、「Java」という技術は非常に周辺技術が多く、
プロダクトの種類だけでもJavaSE／JavaEE／JavaFX／JavaME…、それらに含まれるフレームワークであるJAX-RSやJPAなどなどがあります。セッションがフォーカスしている内容も多岐にわたり、新機能の紹介や、現行の機能のパフォーマンスチューニング、さらには少しJavaから離れてクラウド、PaaS／IaaSの話やREST、コミュニティ、などなどなど。ほんとうに様々なセッションがありました。

それらを眺めながら聞くセッションを選んでいった結果、ある程度自分の中で興味の方向性があることに気づきました。具体的には、今の仕事とリンクしている、RESTやクラウド、運用関連のセッションが中心になりました。結局言語仕様から少し離れたところに興味があったようです。
あとは申し訳程度にJava8のラムダ式絡み。（←これが申し訳程度でなく、非常に良かったことに後に気づく）

これまで、「Java」という広大な技術に対して、漠然としたイメージしかなかったのですが、このスケジュール作成を通して、自分の興味の方向性がある程度見えたことは（来年には変わっているでしょうが）、今回の収穫の1つ目です。

何を得たか　何を知ったか　何に気づいたか

実際にJavaOneに参加して得た、もっとも大きなことは、私はアプリケーション開発の際に、様々な構成要素を検討できるチャンスをたくさん持っているということに気付けたことです。
さらに、そういった時に検討できるよう、日々の「素振り」が大切である、ということにも改めて気付きました。

具体例1　アプリケーションサーバの選定

「CON4117:The Adventurous Developer's Guide to Application Servers」はこの点において大きな気づきをくれたセッションの一つです。

記事中にも書いていますが、正直これまで、アプリケーションサーバについては「とりあえずtomcat使っておけばいいんでしょ」というスタンスでした。
しかし、アプリケーションサーバには様々な種類があり、ここ最近でも新しいものがどんどん出ていること、それらにはそれぞれ特徴があることを知ることができ、常に、「本当にtomcatでいいのか？」の考慮は必要であると思い知らされました。

この発想に至ったのは、カンファレンス期間中に、少し時間をとってGrassfishを試してみたのも大きかったと思います。

具体例２　Java８導入について考える

言語にもっと近いところでは、Java８の導入について考えられたことが大きかったです。ラムダ式については５月に参加したJavaDayTokyoでも聞いていましたので、「大体わかってるし、現場で使えるようになるのは１年以上先だし、まだ深くは知らなくていいや」と実は思っていました。
しかし、キーノートや、「Programing with Lambda Expressions in Java」などのセッションを通じ、改めてこの変化が非常にJavaにとって大きなものであること、コードの可読性が非常に向上するため是非導入すべきであること、そして、いざ導入となった時にその素晴らしさを理解し、メンバー全員で使い始めるには、ある程度の事前知識を、自分はもちろん、メンバー皆が持っていることで、導入のハードルを下げることができるだろうということに気づきました。

この気付きは自分の中では大きかったです。

「海外」に意味はあるのか

はたしてこういった気付きは、わざわざ海外のカンファレンスに行かなければ得られないのでしょうか。
今回の参加には、往復飛行機代と宿泊費、さらにクソ高い参加費で、私の一ヶ月分の給料くらいのお金を会社から出してもらっています。一方、上に書いた、私の「気付き」は国内で雑誌でも読んでいればわかるのではないか、というものにも思えます。

それでもあえて、海外の、JavaOneに、参加しなければ得られなかったと思うことがいくつかあります。

自分の英語力のなさに対する気付き、勉強へのモチベーション

事前知識があまりないセッションを聞いたこともおおきかったですが。

クソ多いセッション数から選ぶ中での、自分の興味の気付き

これは上に書いたとおり。

「素振り」に専念できる時間の捻出。合宿。

今回のカンファレンス期間中、実は、セッションを聞いていた時間よりも、電源スペースに居座って、セッションで聴いた内容を調べたり、手を動かして検証してみたり、ブログにまとめてみたりという「復習」に割いた時間のほうが多かったです。
また、こういったことに時間がとれるよう、セッションは実はスカスカにして、空き時間をかなり多くとっていました。

これこそ一見、海外に行かなくても、わざわざカンファレンスに出なくても、できそうなことですし、事実普段から意識的に時間を作られて、こういった情報収集と検証に時間を割かれている方はいらっしゃると思いますし、そうあるべきだと思います。

ですが現実問題、日々の業務の中で、もしくは自由時間の中でまとまった時間を確保するのは難しいですし、国内カンファレンスの場合、時差がないのもあって結局会社のほうが気になってしまったりということもあると思います。

その点、海外のカンファレンスですと、日程が長く、またリアルタイムに日本の人とやりとりする機会が少ないことから、こうした「素振り」に割く時間を取りやすいと感じました。

言ってみれば、スポーツの合宿みたいだな、と感じました。普段の生活から離れて、その専門のことのみに専念する。

非常に高い金を出してもらっての合宿なのですが、日本を離れたことの大きな一つの意味はそこにあるのではないかと思いました。

今回は上記のような気付き、考えを頂きました。本当に非常にいい機会になったと思います。

なお、セッションの聴き方などは前回参加させていただいた海外カンファレンスと同じ方法＋上記のとおり、素振りに時間を割くという態度で参加させていただきました。

Application Server, 仁義なき戦い : JavaOne2013レポート5 #j1jp

Simon Maple氏による、「CON4117:The Adventurous Developer's Guide to Application Servers」のレポートです。

とりあえず中身の前に外見の感想

いきなり映画のオープニング風味のムービーで始まった本セッション。

会場からアンケートをとってその場で棒グラフが書かれる会場参加型（？）で楽しかったです。
演出面では今回聞いたセッションの中で一番かも。

内容は仁義無きApplication Server Buttle！

Application ServerをMaple氏独自に比較していくセッションです。出場は、Tomcat、Jetty、GlassFish、Liberty Profile、JBoss。の5者。（＋WebSphereとWebLogicが最後に一瞬だけdisられに登場）

なお自分の経験は

• Tomcat　⇒　いつもお世話になっています
• Jetty　⇒　Solrについてるあれだよね。Solrちょこっと動かすのに使ったよ
• GlassFish　⇒　ついこのあいだ触った！
• Liberty Profile　⇒　なにそれはじめてきいた
• JBoss　⇒　お名前はかねがね伺っています

というレベル。なので、セッションレポートに入る前に、まったく見ず知らずの後ろ2つを調べるところから始めたいと思います。

 Liberty Profile

http://codezine.jp/article/detail/6604
無料版（開発環境向け）WebSphereらしい。昨年2012年に登場した模様。

JBoss

http://d.hatena.ne.jp/nekop/20110421/1303372984
Tomcatに比べるとかなりハイ機能な子らしい。

会場は殆どTomcat

まず戦いの前に、会場の人がどのサーバを使っているのか調査。その場で棒グラフを描いていきます。

（このスタイルは面白かったので自分もどこかの発表で使おうと思った次第。）

その結果、9割くらいがTomcatユーザ！で、そのうち75％くらいが満足しているとのこと。

もっとも、恥ずかしながら自分も含めて、大して他のサーバを使うことなく、単にデファクトスタンダードだから使ってるって人が多いんじゃないかなぁとは思いました。
なお、それ以外だと、JBossが会場の20％くらい（計算があってませんが、複数下位挙手した人がいるのでしょう）で満足度はなかなか。WebSphereとWebLogicも2割くらいで、満足度は低い（値段以外は最高！と言ってる人もいました）でした。

導入のしやすさ

ここからはMaple氏の独断でスコア付けがされていきます。
初戦はDOWNLOAD&INSTALLATION。ツールを落としてきて、入れて、起動して…というのは、初めての人にとっては結構面倒なもの。
この点、みんな大好きtomcatは、ダウンロード⇒解凍⇒start.shで即効起動ということですばらしい！ということに。

JBossはサイズが大き目らしいのですが、インストールは簡単とのこと。

それと、大して触れられてなかったけどJettyは軽くて高評価。

設定のしやすさ

『お前らみんなXML好きだろ！？』
ってことでtomcatちゃんなんかはXMLで設定がゴリゴリ記述されてるわけですが、どうしてもサーバって設定項目が多いので、XMLが肥大化しがち。
その中から変更したい箇所だけ探して変更すのはなかなか大変です。

その点、WebSphereはXMLが細かく分割されていて、一部だけさっくり編集するのが非常に簡単だそうで、Liberty Propertyにもその特徴が引き継がれているそうです。

ということでこの項目はLPの優勝。GlassFishは、設定がやたら複雑だからか、下位でした。

DOCS AND COMMUNITY

ドキュメントの充実度…　なのですが、
『一番いけてるドキュメント置き場って言ったら…Googleだろ！？』ということで、この項は実質、どのくらいWeb上にネタが転がっているか。

『なんとかExceptionが出たら、ググればたいてい、同じ問題が発生したやつの解決策が乗ってるよね』

ということで、ユーザが圧倒的に多いtomcat圧勝。

パフォーマンス

自分のマシンで、Jenkinsなどいくつかのプロダクトの、デプロイの速さや実行速度を測定したとのこと。

なんとLPが圧勝だと！次点でTomcatだそうで、トムちゃん遅くはないそう。

機能の充実度・OSとの相性

tomcatはいろいろプラグイン入れないと、機能が足りないよねーとの話。
冒頭のJBoss関連のブログにもありましたが、JBossは標準でかなり高機能なそうで、JBoss圧勝でした。
なお、tomcatのプラグインでは、apache common projectで開発されている、tomEEというのがかなりいいとのお勧め。

公式サイトを見る限り、JavaEEで提供されているような機能がもろもろついてくるようですね。（よくわかってない）

 結果

…という感じで、合計8項目について比較したところ、、、

• JBoss : 35
• GlassFish : 34.5
• Tomcat : 34
• LP : 31
• jetty : 29.5

ということでJBossが優勝！

…と見せかけて。

『項目がいろいろあったけど、お前らの中で優先度が違うだろ？』

ということで再び会場アンケート。8項目がそれぞれどのくらい重要か、High/Middle/Lowでランク付けをしました。

その結果…

tomcatが逆転勝利！！

『おまえらおめでとー！！』

ということで本セッションは幕を閉じたのでした。

まとめ

正直今までは自分の中でtomcat以外の選択肢が存在しなく（選んだわけではなく単に他のサーバを知らないので）、周りが使っているからtomcatという状態でした。

ですが今回のセッションがきっかけで、他のサーバについても考えるきっかけが生まれました。

とはいえよっぽど尖ったサービスを作るのでなければ、周囲のサービスに合わせておいたほうがいいのが事実で、この辺がtomcatの全盛につながっているのでしょうね。

Java8 Lamda式 改めて。: JavaOne2013 レポート4 #j1jp

Venkat Subramaniam氏による、「Programing with Lambda Expressions in Java」のレポートです。

本セッションはライブコーディング形式で、従来のコードがどのようにLambda式に置き換わっていくのかを解説していました。
既に知っている人にとっては特に目新しいものではなかったと思うのですが、ステップバイステップで話が進んだので、非常にわかりやすかったです。
また、このレポートではうまく伝えることができないのですが、Subramaniam氏の話術が非常に面白く、引き込まれるプレゼンテーションでした。

最初に総括

JavaOne初日のキーノートでも触れられていましたが、Lambda式のメリットは、マルチコアを効率的に使って速く処理する　ということにのみならず、従来に比べてコレクション関連のコードが非常にシンプルに、わかりやすく書けることが特徴です。

本セッションでも、その点にフォーカスが置かれて説明がなされていました。

なお、本セッション内で紹介されていたサンプルコードはすべて、以下からダウンロード可能です。こちらのレポートでも、公開されているサンプルコードを抜粋して紹介させていただきます。
http://www.agiledeveloper.com/downloads.html

Lambda式基礎の基礎

最初のお題として、1～6までの数値が入ったListの値を順に出力するプログラムを考えてみます。
一番ベタベタな書き方をするとこんな感じ。

import java.util.*;
import java.util.function.*;

public class Sample {
  public static void main(String args) {
    List<Integer> numbers = Arrays.asList(1, 2, 3, 4, 5, 6);
    
    for(int i = 0; i < numbers.size(); i++) {
      System.out.println(i);
    }
}

これで、「123456」（縦に）の出力が得られます。

ただまぁ、『いまどきこんな書き方するやついないけどな！』（氏の発言の意訳）なので、Java5以降であれば、こういう風にループを書くのが普通でしょう。

    for(int e : numbers) {
      System.out.println(e);
    }

で、こういう書き方をExternal Iterator（外部イテレータ）って言うそうなんですが、こいつをInternal Iterator（内部イテレータ）的な書き方にするとこうなります。

    numbers.forEach(new Consumer<Integer>() {
      public void accept(Integer number) {
        System.out.println(number);
      }
    });

ぱっと見わかりにくくなっちゃってますが、繰り返し内部の処理を別クラスに切り出せたことで、繰り返し内部の処理を隠蔽することができました。

さて、ここからがJava8の新機能、Lambda式の登場です。Lambda式は、上記でConsumerクラスとして定義していた処理を、非常に簡潔に記述することができます。

numbers.forEach((Integer number) -> System.out.println(number));

『How Sweet!!』めちゃくちゃシンプルになりました。
一つ前のコードと比較すると、acceptメソッドが一行で記述されたことになります。

一般的に、メソッド（というか手続き型プログラムの関数）は、「引数」「本体」「返り値」の定義からなります。acceptメソッドはvoid型なので返り値は無しですね。
そのうち、引数がLambda式の左辺、本体が右辺に記述されています。
クラス名、メソッド名は不要なのでありません。無名クラス、無名メソッドです。

もう少しシンプルにします。numbersがIntegerのリストですから、要素であるnumberはわざわざ書かなくてもIntegerに決まっています。ということで無駄なので、Integerは取ってしまいます。

numbers.forEach(number -> System.out.println(number));

ずいぶんすっきりしましたが、Lambda式の両辺に"number"が残っていますね。
『Javaプログラマは2回も同じことを書くなんてアホなことはしないんだぜ！　IDEは勝手にしやがるけどな』
ということで、最後に残った重複も取り去ってしまって、これが最終形です。
改めてクラス全体を書くとこうなりました。

import java.util.*;
import java.util.function.*;

public class Sample {
  public static void main(String args) {
    List<Integer> numbers = Arrays.asList(1, 2, 3, 4, 5, 6);
    numbers.forEach(System.out::println);
  }
}

::はメソッドへの参照を表す記号で、本来forEachの引数はLambda式なのですが、単一メソッドのみの場合は、このように書けるとのことでした。

比較を入れてみる

今度はリストの各値をそれぞれ2倍して、その合計値を出してみます。
まずは伝統的な書き方から。

import java.util.*;
import java.util.function.*;

public class Sample {
  public static void main(String args) {
    List<Integer> numbers = Arrays.asList(1, 2, 3, 4, 5, 6);

    int totalOfValuesDoubled = 0;
    for(int number : numbers) {
      totalOfValuesDoubled += number * 2;
    }

    System.out.println(totalOfValuesDoubled);
}

『こいつは汚ぇ！！　子供が見たらエップバリって言うぜぇぇ！！！』
（元の表現は "It's dirty! Kids say "Don't touch me!" みたいな感じ）

で、streamっていうfancy iteratorを使ってこう書くのがJava8式。

import java.util.*;
import java.util.function.*;

public class Sample {
  public static void main(String args) {
    List<Integer> numbers = Arrays.asList(1, 2, 3, 4, 5, 6);
  
    System.out.println(
      numbers.stream()
      .mapToInt(number -> number * 2)
      .sum());
  }
}

map()メソッドはコレクションの各要素に同じ処理を施すメソッドで、ここではmapToIntなので、各要素を2倍する　ということになります。

上から順に読んでいくと、
1. これから処理する結果を表示する
2. numbersコレクションに対して順に処理する
3. 各要素を2倍する
4. 3.の結果を合計する
となります。元の書式に比べるとかなりシンプルになっています。

今度は、filterメソッドを使ってみます。
お題は、「1～6を順に見て行って、3より大きい偶数で最初に出てきたものを2倍して表示」というもの。
（なので、答えは4の2倍の8です）

今度はいきなりLambda式を使いますが、このようになります。

import java.util.*;
import java.util.function.Predicate;

  public static void main(String args) {
    List<Integer> numbers = Arrays.asList(1, 2, 3, 4, 5, 6);
    
    //double the first even number greater than 3 from the list
    
    System.out.println(
      numbers.stream()
      .filter(number -> number > 3)
      .filter(number -> number % 2)
      .mapToInt(number -> number * 2)
      .findFirst()
      .getAsInt()
    );
  }
}

これでも十分読みやすいのですが、各Lambda式を、適切な名前のついたメソッドに置き換えることで、さらに「読める」プログラムにすることができます。

import java.util.*;
import java.util.function.Predicate;

public class Sample {
  public static boolean isGreaterThan3(int number) {
    return number > 3;
  }
 
  public static boolean isEven(int number) {
    return number % 2 == 0;
  }
 
  public static int doubleIt(int number) {
    return number * 2;
  }
 
  public static void main(String args) {
    List<Integer> numbers = Arrays.asList(1, 2, 3, 4, 5, 6);
    
    //double the first even number greater than 3 from the list
    
    System.out.println(
      numbers.stream()
      .filter(Sample::isGreaterThan3)
      .filter(Sample::isEven)
      .mapToInt(Sample::doubleIt)
      .findFirst()
      .getAsInt()
    );
  }
}

※大体この手のメソッドって碌な名前がつかないので（特に日本人がつけると）、個人的にはメソッドかしないほうが読みやすそうに見えますが。

パラレル処理が威力を発揮するとき

最後に、parallelStreamの速さの実験。YahooFinanceが提供している株価APIを連続でコールして、最も株価が高い銘柄を求めるというものでした。
通信が絡むため繰り返しによるオーバーヘッドが大きい処理です。
これをparallelStreamを使って並列化することでめっちゃ速くなる！という例。

以前はこういった処理を記述するためにはマルチスレッドで意図的に書く必要がありましたが、今後は非常にシンプルに書くことができるようになるようです。

Building Modular Cloud Applications in Java : JavaOne2013 レポート3 #j1jp

Bert Ertman氏とPaul Bakker氏による「Building Modular Cloud Applications in Java」のレポートです。
オランダの方の模様。

最近、PaaS上でのJavaアプリ開発に携わっているので、Cloudという単語に反応して聴きに行ったのですが、Modularityという単語や、Apache ACEによるデプロイ管理といった話を聴くことができ、有意義なものでした。

スライドはすでにSlide Shareで共有されていました。

Building Modular Cloud Applications in Java - Lessons Learned from Bert Ertman

モジュール化はアジャイルのための究極のツールである

アジャイルに限らずですが、サービスをインクリメンタルに拡張していくと、必ずぶち当たるのがアーキテクチャを「よしなに」変更すること。
クラスの再設計などを余儀なくされることが出てきます。このときに、アプリケーションの各パーツが蜜結合でごっそりくっついていると大変ですよね。

そこで、"Modularity". アプリケーションの各部分をなるべく小さなモジュールとして独立させ、インタフェースのみを共有してデータのやり取りを行うことで、内部が疎結合なアプリケーションを作ることができます。

Javaでモジュールシステムを作るならOSGi

OSGiは比較的古くからある、Javaモジュールの動的追加や実行を管理するツールです。OSGiが使われているもっとも代表的な例の一つは、IDEのEclipseで、Eclipseに動的にプラグインを追加できるのは、OSGiを基盤にしているからだそうです。

OSGiでは、各モジュールがひとつのプロジェクト

セッションでは、実際にプレゼンターが作成したアプリケーションの内部設計の紹介がありました。

このように、RESTで受け取ったリクエストを処理してMongoDBに読み書きするというアプリケーションなのですが、特徴的なのはこの図の四角がすべて、独立したプロジェクトであることです。

OSGiでは、このそれぞれのプロジェクトが一つ一つのモジュールとなり、Bundleと呼ばれています。そして、ひとつのアプリケーション内で、Bandleごとにバージョン管理ができます。
他Bandleにあるクラスは、プロジェクトが異なるので、たとえPublicなClassであっても実装を見ることができません。唯一、InterfaceのみをOSGi内部の仕組みで共有します。こうすることで、普通のアプリケーションより一段、部品の隠蔽化を進めているようです。

ひとつのアプリケーションを複数のプロジェクトに分割する方法としては他に、それぞれをJarにビルドして取り込む方法もあると思いますが、そういった方法よりも一段、結合の疎化を押し進めたものだと思います。

なお、OSGiに関してはよくわからなかったので、プレゼンの中で「本日発売！」と発表された二人の書籍「Modular Cloud Apps with OSGi」を購入して実際に試してみました。詳細はこちらの記事に書きました。。

Apache ACEによるデプロイ管理

さて、アプリをモジュール化する方法がわかったところで、いよいよ本題のCloud Applicationです。

今回、プレゼンターが紹介してくれたアプリケーションは以下のような要件だそうです。

• 学校で使うシステム（よく聞き取れなかったけど、学校で使う業務システム的なやつ？）
• 「自分たちで構築したPaaS上にデプロイされている」
• ノードクラスタは各学校ごとに用意されている。また、学校ごとに用件が違うため、使用するモジュールが異なるらしい

自分たちでPaaSを構築とは驚きですが、制約が無いことが何よりすばらしいこととか。

そのため、各ノードへのデプロイの仕組みも自分たちで構築しているそうなのですが、ここで使われているのがApach ACEという、デプロイ管理システムだそうです。
Apache ACEは、モジュールに分割した分、構成管理が複雑になりがちなOSGiのデプロイの管理を行うために、Apache Foundationで進められているプロジェクトで、

• 複数のコンポーネントからなるアプリを
• いくつかの環境にデプロイ、かつ環境によって構成を帰る必要がある

ようなときに力を発揮するツールとのこと。

このように、一度ACEにアプリをアップロードしたあと、設定にあわせて、ACEが各サーバへアプリケーションを配布していくことができるそうです。

時間帯に合わせてノード数、スペックを変更

さらに、本システムは学校用という要件上、アクセスは日中に集中し、夜間は殆ど使われないそうです。そこでリソースを効率的に使うため、夜間は小さなノードをひとつだけ上げ、朝になると強力なノードを一気に15台立ち上げるそう。

その際、立ち上がったサーバから順に、Apache ACEからアプリケーションを受け取り、デプロイされることでサービスできる状態にしているそうです。
（ノードは起動直後は、何も無い状態）

まとめ

技術的なこと

本セッションで、OSGiやApache ACEという技術を知りました。OSGiはセッション内で「簡単になった」といわれていたものの正直まだ難しく、メリットもイマイチ腹落ちしていないのが実情です。

ただ、私が今担当しているプロダクトが各種APIの集合体のアプリケーションで、APIごとにバージョン管理をしたいと思っているもので、もしかしたらOSGiと相性がいいのかも、、と思いました。

思想的なこと

なるべく各部品は小さく、疎結合に　というのは、アプリケーション開発における、共通項かと思います。

今回のセッションでは、改めてその方向性を確認しました。

さらに、夜間は1ノード、朝になったら15ノードあげてデプロイ！という一連のライフサイクルが自動で運用されていることに驚きました。
デプロイ改善はここ最近、必要性を感じてずっと取り組んできていることなのですが、いまだ解決できていないのが実情です。

本番反映の自動化、簡素化、見える化は今後も継続して取り組んでいく必要があると改めて感じました。

JAX-RSとJPAとEclipseLink JPA-RSとRESTfulなアプリケーション : JavaOne2013 参加レポート2 #j1jp

Dong Clarke氏による、「Practical RESTful Presistence」のレポート…というよりは、セッションを聞いてわからなかったことを調べなおしたレポートです。

今もっているプロダクトがRESTfulに近い（RESTfulではない）APIということもあり、RESTfulというタイトルが気になって聴講。

知らないことが多すぎて、終わった後にひたすら調べまくって、ようやく概要の説明ができるかな、、、というレベルまできましたので、調べたことも織り交ぜつつ、整理のためにまとめてみます。

そもそもPresistenceという言葉

日本語では「永続性」と訳されるそうなのですが、データ処理の観点での完全性を実現するのに最低限必要な機能である、新規作成／参照／更新／削除を「永続性」と呼ぶことがあるそうです（by Wikipedia)。
本セッションでのPresistenceはこれについて述べていた模様。

JAX-RS

JAX-RSとは、JavaでRESTfulなwebサービスを提供するための「仕様」です。

JAX-RS自体は仕様なので、使う際にはさまざまなベンダーが提供している、実装を利用することになります。Apache CXFや、Jerseyなどがある模様。

JAX-RSを使うと　/リソース/id のようなURLと、各HTTPのメソッドを対応付けたコントローラが簡単に作成できるそうです。

Java Persistence API (JPA)

JPAとはJavaEEの標準O/Rマッピング機能で、最新のJava EE7には、JPA2.1が実装されるそうです。

POJOに@Entityアノテーションを付加することで、テーブルと対応付けることができ、EntitiyManagerクラスが提供する永続化処理のメソッドが使えるようになります。
RDBのリレーションも適切に反映することができるそう。

※こちらの寺田さんのブログを参考にさせていただきました。
http://yoshio3.com/2011/12/19/java-persistence-api-for-begineers/

JAXB + JAX-RS + JPA で

JAXBはXMLを対応するPOJOにバインディングすることのできる仕様です。ということは、この3者をつかえば、RESTfulなAPIでリソースの作成や更新のデータをXMLで受け取り、そのまま対応するDB上のテーブルに突っ込む　ということが可能になるわけです。

で、EclipseLink JPA-RS

…というようなアプリを、”EclipseLink JPA-RS”ってのをつかえばHTML5利用のアプリとして簡単に作れるよ！というのが本セッションのテーマ。

EclipseLinkプロジェクトとは、Eclipseプロジェクトのサブプロジェクトで、Javaの永続性関連のライブラリを提供しているそうです。

そのEclipseLinkの2.4で実装された、JPA-RS（という手法？）を使うことで、RESTfulなアプリケーションを非常に簡単に作ることができるそうです。

セッションの後半では、JPA-RSによって作られたサンプルアプリケーションのデモが行われました。

さらに、ぐぐればデモがあるよ！と紹介されていたので、

http://wiki.eclipse.org/EclipseLink/Examples/JPARS/Simple

こちらを参考に試してみようとしたんですが、、、

• 初めてのGlassFishインストール＆起動
  

  

• GITからプロジェクトをClone(clone用のURLが見つからなくて15分ほど路頭に迷う）
• GlassFishでDB設定（そもそもローカルにDBが無かったのでそこから。mysqlだと重かったのでsqlightを使ってみる）
• Eclipse上でアプリをGlassFishについかして、起動して、、、どや！？

404　←　いまここ。

ということで、結局今のところデモならずでタイムアップです。
なんとも歯切れの悪い。

【まとめ】今日は以下のキーワードを覚えました。Tryが中途半端なところで終わったのが残念。

• Presistence
• Java Persistence API (JPA)
• JAX-RS
• EclipseLink
• EclipseLink JPA-RS

コミュニティ活性化のためにロゴが大事！ : JavaOne2013 参加レポート1 #j1jp

本日より、JavaOne2013に（会社のお金で）参加させてもらっています。

記念すべき1件目の参加レポートは…
Ryan Cuprak氏の「Organizing Your Local Community」。

なんでJavaOneまで行ってコミュニティなの！？というツッコミを受けそうですが、MeetUpの本場であるベイエリアで、現地の人がどんなことを考えてコミュニティを主宰しているのか聞いてみたく、参加しました。

Cuprak氏は2002年より、CTJAVAというJUG(Java User Group)を運営しているそう。
本セッションは、氏が、運営の中で学んだことや苦労したこと、工夫していることの発表でした。「JUGは～」というTOPICSが多かったのですが、十分他のコミュニティ運営にも通ずる話だったので、紹介させていただきます。

全体を聴いた上での感想は、大変なことはどこも変わらないな、ということ。
コミュニティを運営するには、自分の時間を割かなければいけないし、
ある程度運営スキルがないと運営していくのも大変。そして参加者を集めるのには非常に労力が必要とのことでした。

一方で得られるものとしては、その、重要な運営のスキルが身につくことや、
技術の最新動向を知られること、そして、業務外でコネクションを作られることなどを挙げていました。

さて、Cuprak氏がコミュニティを立ち上げるに当たって重要だと語ったことの中で、特になるほどと思ったのが、「ロゴ」。

コミュニティのロゴは、ビジュアルにブランドのイメージを示すことができ、かつ、見た人に印象を残すことができるとのことでした。

これは私にも思うところがあります。
私は、10%ルールというコミュニティというかイベントの運営を部署内で行っていますが、デザインができる後輩にロゴを作ってもらったところ、
スライドに使ったり、ステッカーを作れたり、さらには自分のデスクトップの背景にして、ミーティングのときにさりげなく見せて話題に持っていったりと、何かとアピールする機会が増えました。確かにロゴ大事です。

とはいえ、ロゴ作りって難しいですよね。
私はそんな後輩君がいたので、素敵なロゴを作ってもらうことができたのですが、周囲にそういう知り合いがいない場合はどうしたらいいのでしょうか。
Cuprak氏曰く（そして世の中でよく言われているように）、殆どのCoderは絵を描くのは下手なので、自分でロゴをデザインするのはやめておいたほうがいいそうです。

ではどうするか。

Cuprak氏は有効な手段を二つ挙げていました。

1. プロに依頼する

本当のプロに依頼すると$2000ほどかかってしまうそうなのですが、プロが作ったロゴには値段以上の価値はあるとのこと。

2. オンラインロゴサービスを使う

CTJavaは、こちらの方法を採用したそうで、LogoDesigneTeam.comというサイトで依頼して作ってもらったとのこと。
$150ほどで作ることができるそうです。

1., 2. いずれの方法でも、"Iterative Ideas"を受けられるとのことだったので、デザイナーとのあいだでコミュニケーションをとりながら、よりイメージに近いものを作ってもらえるようです。

ということで、若干のお金をかけてでも、そのコミュニティのイメージをバシッと表すロゴが作れると、他の人に大きく印象を残すことができ、活動の活性化へつなげていくことができるようです。