JJUG CCC 2013 Spring

・サイト
  http://www.java-users.jp/?page_id=330

・まとめサイト
  http://togetter.com/li/500961

・参加したもの
  ・H-1JavaEE6からJavaEE7に向かって
    http://www.slideshare.net/OracleMiddleJP/java-ee-6-to-java-ee-7

  ・H-2ProjectLambdaEssential

  ・H-4失敗から学ぶAPI設計
    http://www.slideshare.net/yusukey/api-ccch4-jjug-jjugccc-jjug-ccc-2013-spring

  ・R2-5[BOF]Groovy2.Xの新機能
    http://www.slideshare.net/uehaj/jjug-ccc-groovy2x20130511

・全体的な感想
Lambdaの話と、Twitter4jのAPI設計の話が特にためになった。
Lambdaは、遅れてもいいからJava8に入って欲しい。

Lambda、Groovy（というか主にGradle）でクロージャ周りを使えるようになってきたけど、やっぱり書きやすさが全然違う。
全容を把握できてる訳ではないけど、うまくJavaのタイプセーフさとも組み合わさればJava8は広まりそう。
ネタでコーディングルールで、Lambda禁止とかあるけど、導入されるなら積極的に使って行きたい。

インターフェイスのdefaultmethod、implmentsした順で実装が優先されるとかいう理解をしてしまっていたけど、Twitterで指摘をいただいて試したところ理解が間違っていた。
別のdefaultmethod同士だと、やっぱりどちらの実装を選択するかを明示しないといけないよう。

https://gist.github.com/hiroisojp/5560120

Twitter4jのAPI設計の話、ライブラリとフレームワークという側面でAPI設計は結構変わると思うけど、
主にライブラリとして作って行く場合の設計意図の話が直接聞けてためになった。

  ・拡張ポイントはなるべく少なく
  ・クラス継承はさせない
  ・デザインパターンを活用しすぎない（初心者は詳しくない）

というところから、ライブラリとしてのスコープ（どの部分までを扱うか、どう提供するか）をブレないように設計するという観点が必要と感じた。

その他、細やかな点として、
  ・IDEの補完を活かせるようにする
    ・同一パッケージにして、検索性を上げる

  ・IDEの補完が効きすぎないようにする
    ・利用して欲しくないクラスを意図的に検索性を下げる
ex)z_T4JInternal***として、z（補完候補の最後の方にでる）、Internal（内部で利用しているクラス）というように意図を示す

といったのも参考になった。

・メモ
・H-1JavaEE6からJavaEE7に向かって
  ・JavaEE6の振り返り
  ・JAX-RPC、EJBEntityBeanは、EE6で廃止予定で、EE7からは「仕様上なくなる」。実際になくすか（下位互換を保つか）はベンダーに次第

  ・EJBコンテナをJUnitであげれる->サンプルコードはルックアップしてるがDI形式にできないのかな？（その方がスマートだと思う）

  ・JavaEE7のテーマは、「シンプル化」、「HTML5対応」
  ・EL3.0で実はLambda式がもう使える（SE7環境下で動作する）
  ・EL3.0でやり過ぎると、昔のJSPのロジック埋め込みに逆戻りな気がするので、ビューとロジックを分離して欲しい気がする

・H-2ProjectLambdaEssential
  ・Lambdaは、クロージャ周りが注目されがちだけど、（出自としては）クロージャのためではなくパラレルコンピューティングを導入するため。
  ・Lambda<<API（のほうが重要）
  ・functionalinterfaceでインターフェイスを定義すれば、Lambdaで書ける。
  ・@FunctionalInterfaceは、実装が問題ないかコンパイル時にチェックするためのもの（後で確認した）
  ・StreamAPIは、Groovyのコレクション処理に似てる気がした
  ・map、filter（戻り値がStreamになってるようなもの）は遅延される。->最適化されて速い

・H-4失敗から学ぶAPI設計
  ・「NoGGRKS」（親切に対応）

  ・シンプルにYAGNI。将来必要になるかもとか拡張性とかを考えすぎない。
  ・クラス数は極力増やさない。インターフェースは（なるべく）使わない。
  ・拡張ポイントはなるべく少なく。何でもかんでもやると逆に初心者に難しくなる。
  ・クラス継承はさせない。finalじゃないと意図しない挙動になることがある。
  ・一部finalでないものはモック用が主で、コメントで理由をつけている。

  ・ライブラリ自体を簡単に書くよりは、ユーザが簡単に利用できるようにしている。
  ・普通のユーザが戸惑うような作りにはしない。
  ・デザインパターンを適用しない。（やりすぎない）->知らない人が多い。

  ・IDEの補完を活かせるようにする。
  ・一般的すぎるクラス名にしない。
  ・IDEの補完がいきすぎないようにする。使うべきでないクラス名を異様にする。（z_T4JInternal*****）

  ・至上命題
    ・互換性の維持
      ・クラス名を変えない。
      ・挙動を変えない。
      ・Twitter側の挙動が変わった場合は判断が迷う、Twitter4jが吸収すべきかどうか。
      ・直列化形式（シリアライズ）の互換性の維持
        ・復元ができないケースがたまにある。対応する情報がなくなったとか
        ・フィールドは残してgetterなど省くなどで対応。
      ・難しい。が、気をつけるだけでテストはしてない。（ホントはしないといけないけど、コストがかかる）
    ・互換性情報は、ドキュメントで通知
    ・非互換はコンパイラに検出させる。どうしても保てない場合など。

・失敗例
  ・パッケージ構成
  ・やりすぎるとクラスが見つけられない。blogのコード例をコピペしても見つからない。
  ・（ただし、通常のプロダクトでは機能別にパッケージわけしたほうがいい）
  ・ソースディレクトリをわけるのがいいかもしれない。

・R2-5[BOF]Groovy2.Xの新機能
  ・スピーカー、プログラミングGroovyという書籍の中の人だった。
  ・Groovyは、動的が中心だったが、動的かつ、静的言語になってきてる
  ・Gradleは、Androidの公式ビルドシステム

  ・2.0から、@TypeChecked、@CompileStaticなどの静的チェックを行えるアノテーションが導入されている
  ・静的Groovyでどう変わる？
  ・引数は省略できなくなる、動的機能は対応不可。（そのかわり性能向上、IDE補完、型安全、ランタイムではなくコンパイル時に検知。Javaっぽい）
  ・静的Groovy、大規模なものをあとから書き直すというのはちょっとつらいように感じられる。

  ・indy対応(invokedynamic)、Groovyのindyはあまり性能がよくないようにみえるよう。

  ・Groovy2.0
    ・静的への回帰
    ・BettarJava
    ・今使えるJava8(Lambda,TypeAnnotation)

2012年の振り返り

2012年の振り返り。

今年は、いくつか新しいことに取り組む機会があり、特に技術的にはいろいろ得られた年でした。
自分が中心となって開発したものが、一気に採用されてかなり忙しい一年でしたが、よい一年だったと思います。


技術的なものは、以下のウェイトが多かったと思います。

• Jenkins
• WebDriver
• Spring + Thymeleaf

・Jenkins

個人的にはちょこちょこ触ってみてはいましたが、今年、2012年に初めて実プロジェクトの運営で使いましたが、自分の関連プロジェクトはだいたい使うようになりました。

リーダポジションの人で、ある程度アプリケーションの全体像や品質を考えなくてはならない立場の人には結構、受けがいいですが、まだ経験が浅いような若手だとまだあまりメリットを感じれていない人もいます。
（まぁ、Jenkinsがあった開発となかった開発を両方経験しないと、ないときの不便さがわからないというのもありますが。）

具体的に何がいいの？とたまに言われるのですが、自分としては以下の点が気に入っています。

・変更に対するしきいが飛躍的に下がった

Jenkinsで、コミット時に自動的にテストが実行されることにより、気軽に変更したり試したりできることを実感しました。

これには当然、ユニットテストを書く必要があるのですが、Jenkinsではいままでの履歴も保持しており、テスト自体の成長の記録もわかるので、テストを書こうという気にさせてくれます。

過去のプロジェクトの多くでは、ユニットテストを書いてるけどだんだんメンテナンスされていかなくなる、というのを幾度か経験しましたが、Jenkinsでは、自動実行される事により、プロダクションコードと、テストコードが乖離すると、すぐにテストがエラーになるので、修正しなければ先に進めなくなる点も（強制な面はありつつも）気に入っています。

体感的な効果はテストをないがしろにしがちな人も多少、意識が変わってきているという認識です。
いままではテストの話など全然しなかった人が、これはどういう風にテストするといいと思いますか？など言ってくれたりしてくれるようになりました。


・メトリクス関連のツールと組み合わせての品質の予防
checkstyle、findbugsのような静的解析、cobetruaのようなカバレッジツールと組み合わせてある一点で品質を観測するのではなく、連続的にいつでも最新のコードの品質を確認できるようになりました。

自動でメトリクスを取得するので、ある程度システムが出来上がってくると、checkstyleなどをさぼっていると警告数がどんどん増えて行きます。

自分で取得するのではなく、Jenkinsが取得するので手間ではなく、かつ見たときに、あ、細かい部分をさぼってるな、対応しなきゃ、という気にさせてくれます。

もちろん、メトリクスが取る事が目的ではないので、場当たり的な対応やテストコードにならないように注意する必要があり、その部分はまだ浸透はしきれていない部分はあるというのはまだまだ実感しています。


Jenkinsは（というかCIツールになりますが）、自分の中では、なくてはならないものというか、すでにあって当然というスタンスでいます。

・WebDriver

Webアプリの場合、ブラウザ操作を自動化したり、画面の処理結果などを検証したいという場合が数多くあります。

WebDriverはコードでブラウザ操作を行うライブラリで、ブラウザ操作の自動化や、検証についてこれをかなり使っています。

他の候補として、firefoxプラグインとして自分で操作したものを記録し、テストコードを出力してくれるSelenium IDEなども検討してみましたが、なんだかTDDじゃないなぁと思ったり、生成されるコード中にURLや入力値がハードコードされてしまうので、見送りました。

ただし、WebDriverはそのまま使うのではなく、多少ラップして、Excelに手続き的に書いたシナリオをJUnitから自動実行するようにしています。

その他、テスト前のデータ初期化やREST APIの呼び出しなどもテストシナリオに記載できるようにしています。

Excelはプログラマには結構嫌われてしまう面が強いのですが、それなりの規模のプロジェクトではJUnitテストコードをまともにかける人ばかりではないので、Excelで、テストシナリオを書くとWebDriverのテストがかけるというのは結構便利なんじゃないかなと思っています。Excelなら「なんとなく」なら使える人も多いですし。

またJenkins + maven cargo + coberturaと組み合わせて自動テスト時に、ブラウザ操作をしつつ、カバレッジも取るという事もしています。（もちろんこのテストはスローテストになるので、コミット単位ではなく、定期的に実行しています）

webアプリでテストコードだけでカバレッジを取るというのは難しいので、これも助かっています。

・Spring + Thymeleaf

Springは今年ではなく、ここ数年は継続的に扱っています。

Spring関連は組み合わせや自由度が高く、どれを使っていいのか迷う面もありますが、いろんな逃げ道があったり、後発のフレームワークと組み合わせたりできるってのはアーキテクチャを決める側としてはうれしいものがあります。

また、後方互換性にもかなり気を使っているので、バージョンアップの際にも安心感があります。（反面、内部のコードはキレイと言いがたい部分も結構あったりするのですが。）

後方互換性に気をつかいつつ、新しい仕様への対応も継続的に続けているプロダクトはそうそうなないんじゃないかなと思います。

Springは一部、拡張してSeasarやSlim3のように開発モードとしてhotRelaodingライクなことをできるようにしており、Spring MVCでもサクサク開発ができて便利です。（Spring3.1 -> 3.2 のServlet3.0対応周りでちょっとハマりましたが）
　
最近は、spring-loadedというプロジェクトというもの出てきてるようで、Grailsでフォーカスされているようですが、もしかしたら本家側でもhotReloadingのようなものも対応してくれたりするとうれしいですね。（有償？でJRebelというのもあるようですが、これもどんな感じか気になります）

  https://github.com/SpringSource/spring-loaded

ビューは、Spring MVCと組み合わせで、ThymeleafというHTMLベースのテンプレートエンジンと組み合わせて使っています。

  http://www.thymeleaf.org/

TeedaやFaceletesのような同じHTMLベースのビューフレームワークを探していたのですが、印象はよいです。
HTMLベースがよかったのは、お客様向けのモックを見せる段階で作成したHTMLをなるべく活かしたいなと思っていたのが大きな理由です。

TeedaはS2前提なのと、Faceletesは、内部的にはJSFだったので見送ったのですが、ThymeleafはSpringと組み合わせることも考慮されており、使いやすいと思っています。

Thymeleaf1.xのころから使い始めていたので、そのころはマイナーだったようですが、最近は日本のブログでもみかけたり、Springのカンファレンスでもセッションがあったようで、今後、広まってくれるとうれしいなぁという気持ちです。




その他、プロジェクト運営の観点からも、今年はわりと自分の中でもいいターニングポイントになったかと思います。

世の中は、キレイなアーキテクチャや運営などできているところもあると思いますが、
今年は多くのプロジェクトを見る機会があったせいか、まだまだ整備されていない形の開発や運営があるのを実感しました。

社内外をみていて強く感じたのは、プロジェクト初期の判断ミスによって運用、保守フェーズへのしわ寄せがいったり、残される人への負担を増やす対応とか、自分が最後まで面倒見ないからといって、後続に負債をもたせるようPM、PLとか、。。。ですねぇ。
（そしてその運用が当たり前と思うような保守も）

理想と現実と、組織の制約のバランスをとって現実解を探していくのもおもしろいかと思います。

アプリ単体ではなく、運用・保守までトータルしたクオリティを向上させ、疲弊しない開発やプロジェクト運営というレールをしけるようになっていきたいです。
今後はそこのニーズが合うかどうかもどう仕事して行くかの基準になるかと思います。

JavaOne Tokyo 2012 2日目

JavaOne Tokyo 2012 2日目の話。

2日目に参加したものは以下の通りです。

• [JK2-01] Technology Keynote
• [JS2-01] #jt12_s201 The Java EE 6 Programming Model Explained
• [JS2-13] #jt12_s213 Java EE 6時代のJ2EEパターン再考
• [JS2-21] #jt12_s221 How to Write Low Latency Java Applications
• [JS2-31] #jt12_s231 ForgeとArquillianを利用したJava EEアプリケーションの迅速な開発
• [JS2-41] #jt12_s241 Java Persistence API on the Grid
• [JS2-51] #jt12_s251 The Future of JavaScript in the JDK
• [JK2-01] Technology Keynote

[JK2-01] Technology Keynote

2日目のキーノートは、Coin, Lambda, Jigsaw, JDK7,8,9の方針、JavaFX, Java EE7(Cloud周り) 、いろんなデバイスにJava載るよ、 Java ME、M2M、という話の概要レベルがキレイにまとまっててキーノートとして非常にわかりやすかったです。

CoinやLambdaは、1日目のセッションで重複しているものが多かったので、さらっと聞けました。

Lambdaは1日目に見たものを早速書き方が異なっていて、どっちが最新だよ、というツッコミが。

キーノートでは、「Math#max」という表記で、1日目のセッションだと、「Math::max」のように「::」を用いて示しているところが微妙に違ってました。

JavaFXは、初日のStrategy Keynoteでキネクトっぽく、スピーカーの方の動きと、JavaFX上のDukeの動きがシンクロするという面白いデモ + GUIエディタを見せてもらってから急に興味がわいて来ました。

今回のJavaOneではJavaFXのセッションもかなり多かったので、Oracleとしても力は入ってるのでしょう。

どれか一つくらい、JavaFXのセッション聞いておけばよかったかなとちょっと後悔。

Java EE7では、再度、クラウドの話がありましたが、このあたりはやはりクラウドベンダーとの協調がどうなされていくかが重要かなと思っています。

組み込みJava関連はあまりお仕事では関わったこともなく、詳しい話はスルーしました。

[JS2-01] #jt12_s201 The Java EE 6 Programming Model Explained

Java EE6でのプログラミングモデルの話。

1日目のセッションのいくつかで聞いた情報が重複していました。

web-fragment.xmlはここでも出てきていたので、意外と有名なんだなと。

EE6は、なぜかweb.xmlが嫌いみたいでweb.xmlなしでも起動できるようにアノテーションやら、ServletContainerInitializerで初期化処理がコードベースでできるようになっています。

が、個人的にはweb.xmlはあってもいいんじゃないかなと思います。

定型的なものは、web-fragment.xmlで流用できるようにしておけばいいし、web.xmlがあるほうがエントリポイントが見つけやすくていいと思っています。

strutsや2.5系以前のspringのように、画面や機能が増えるごとにXMLも増えていくのはもちろん避けるべきだと思いますが、数が増えない（であろう）コアの部分やアプリケーション全体のコンフィグレーションを示す外部ファイルはあってもいいと思う。

CDI周りは、Qualifierアノテーションを使えば、独自のDIの目印用のアノテーションを作れるのは知りませんでした。

Qualifierの仕組みは、Springでも使えるようで、試してみたところ、Spring3.1でもQualifierアノテーションを活用したDIができるので、これは便利で早速取り入れています。

http://togetter.com/li/283774

[JS2-13] #jt12_s213 Java EE 6時代のJ2EEパターン再考

ちょっと選択を失敗したセッション（笑）

いや、内容は悪くはなかったのですが、EJB2からやってきてる人向けのセッション内容でした。

EJB2は概要レベルは知っていますが、基本的にEJB3以降の世代なので、あまりバッドノウハウを知らない状態で聞いても、いまさら感が結構ありました。

EJB2はやっぱりいろいろ苦労されてるのですね。。。

[JS2-21] #jt12_s221 How to Write Low Latency Java Applications

JVMのメモリ管理の話。

最初は、基本的なメモリ管理の話かーと思って、油断してたら後半はちょっと難しかった。

このときは、結構疲労してたので話しとTLをウォッチ中心にしてしまいました。

http://togetter.com/li/283786

[JS2-31] #jt12_s231 ForgeとArquillianを利用したJava EEアプリケーションの迅速な開発

レッドハットさんによる、CDI周りとForgeの話。

Arquillianという方の話は時間の関係か、結局詳細は聞けず。

（別のセッションで詳しくされてたみたい）

CDIでは、CDIのExtension部分の汎用的な部分を提供するDeltaSpikeというプロジェクトがあるようです。

JBossではなくて、Apacheとしてプロジェクトが立ち上がってるみたい。

Forgeは、Spring Rooのようなコマンドラインベースでコードを自動生成するツールです。

最初みたとき、めっちゃ似てると思いました（笑）

ただし、Forgeのほうは、Spring Rooとは違って純粋なjavaコードを出力していたように見えました。

Rooのようにajファイルを出力して黒魔術的にやるよりは明示的にjavaコードを出力してくれるほうがわかりやすい気もしなくもないですが、変更が入ったりラウンドトリップな感じで進めて生きたい場合はどうするんでしょうか？

Rooは、javaコード部分のほうは、変更されること前提で設計されているので、変更を検知してくれるけど、Forgeも変更に強かったりするのかな？であればかなり便利そうな印象。

出力されたものをスケルトンとして継承して利用するようにするのが基本なのかな。

また、Rooでscaffoldすると、View部分がJSPの独自タグ満載(tagx)で作られるので違和感があるのですが、Forgeのほうは、JavaEEということでJSF（facelets）で出力するようです。

こちらの方がすんなり入れそうという印象。

http://togetter.com/li/284158

[JS2-41] #jt12_s241 Java Persistence API on the Grid

タイトルにはないけど、ほぼCoherenceの話。

JPAのキャッシュ機構は微妙だけど、それを補うのにCoherence使ってねみたいな印象を受けました。

（いいすぎ？）

TLみる限りでは、JPAのキャッシュはあまり使ってる人いないみたい。

memcachedと組み合わせたりするほうがいいですかね。

[JS2-51] #jt12_s251 The Future of JavaScript in the JDK

Node.jsでJavaのクラスが使える！

このセッションで一番盛り上がった瞬間。

Java6ではRhinoだったけど、Nashornという名前で後継プロジェクトができてるよう。

JavaとJavascript間をよりシームレスに利用できるようになるみたい、JavaBeansやCollectionのやりとりが簡単になったり、デバッグもできるようになる。

Nashornでは、Javascript上から、java, javaxパッケージのクラスが使えるようになる。

デモでは、Node.jsがNashorn上で再現され、さらにNode.js（Javascript）コードからJavaのSimpleDateFormatを使って日付をフォーマットしてコンソールやブラウザに出力するデモ。

前半は、まったりとした説明で会場の空気もまったりしていたのですが、Node.jsのデモから体感的に一気にまわりの食いつきが変わってた。

javaxパッケージが使えるということで、Node.jsからJDBCが使えることになればまた面白そう。

今のところ使う場所は想像できないけど、プロジェクト的にはかなり面白い取り組みだなと思います。

まとめ・感想

JavaOneは初参加でしたが、非常に有意義でした。

今後のJavaの進み方、現在の取り組みがかなり整理された状態で聞くことができたのが、やはり大きい。

どういった方向性に進んでいるかをちゃんと提示してもらえると開発者としてもどういう風に進んでいこうかということが考えていけるので非常によいと思います。

（方向性が合わない場合はJavaから離れてもよいわけですし）

Oracleさんの会場運営もよかったです。

全セッション（？）に通訳レシーバがちゃんとありましたし、たまたま前方の席のほうに座って気づいたのですが、手話用の通訳もあり、こういった細部にも配慮されているんだなぁと感心しました。

ただ、セッション間の移動は、会場が同じであっても総入れ替え制でそこの混雑が段取りがいまいちだったなぁと思います。

同じ会場でセッションが続く場合は、デブサミのように、会場前方で受け付けれるようにしてあれば、分散されてもう少し混雑が緩和されていたのではないかと思います。

とはいえ、非常に有意義な時間を過ごさせていただいたのは間違いありません。

スタッフの皆様、お疲れ様でした＆ありがとうございました。

JavaOne Tokyo 2012 1日目

JavaOne Tokyo 2012に参加してきました。
7年ぶりとのことらしいですが、自分は7年前は社会人なりたてくらいだったので存在をあまり知りませんでした。

大きめのカンファレンスはいくつか参加したことありますが、ここまでJava + 技術ネタのセッションばかりのものは初めてで非常に楽しめました。

参加人数の1000人オーバーということで、普段回りに少ない（あれ？）Javaのエンジニアの方々がたくさんいたり、Twitterでつぶやいてると、同じ会場で聴講している方がコメントくれたりして楽しんで聞けました。

自分が1日目に参加したものは以下の通りです。

• [JS1-02] #jt12_s102 Java EE Web Container in the Cloud -What's New in Servlet 3.1
• [JS1-11] #jt12_s111 The Heads and Tails of Project Coin
• [JS1-21] #jt12_s121 Pragmatic Cloud and PaaS with Java EE 7 (and GlassFish)
• [JS1-31] #jt12_s131 Project Lambda: To Multicore and Beyond
• [JS1-42] #jt12_s142 JAX-RS 2.0: What's in JSR 339?
• [JS1-51] #jt12_s151 HotRockit: What to Expect from Oracle's Converged JVM

[JS1-02] #jt12_s102 Java EE Web Container in the Cloud -What's New in Servlet 3.1

Servlet3.1まわりの話。

一通り知ってるつもりでしたが、web-fragment.xmlは知りませんでした。

web-fragment.xmlを使えば、web.xmlの一部を定義しておいて、jarに同梱できるようです。

フレームワークなどを作っている場合は、servletやfilterが必要になることが多いので、フレームワークで利用するfilterを定義しておいて、jarに同梱しておけばすぐに使えるという感じ、これは便利そう。

後で調べてみたところ、複数のweb-fragment.xmlがあり、かつfilterが適用される順番などを気にする必要がある場合は、web.xmlに、<absolute-ordering>タグを記載すれば明示的に順番を指定できるよう。


少しだけ、WebSocket対応というキーワードがありましたが、詳細なし。

Java EE7の話。

EE7ではクラウド対応というキーワードしか知らなかったのですが、かなりいろいろなものが入りそう。

アプリケーションレイヤーとしては、multi-tenancy対応が気になりました。
アプリケーションで複数の顧客をサポートするような場合の対応です。（Salesforceのように）

JPAレベルでもいろいろサポートするようで、@Multitenantのようなアノテーションでマルチテナントを明示化したりするようです。

テナントIDといった顧客を識別するIDをwhereに自動的に組み込み、データをうまいこと扱うような感じです。

テナントIDの引き渡し方といったことなどはまだまだ仕様策定中らしく詳細はまだ不明。

とはいえ、最近は案件としても、リソースの有効活用という観点からもマルチテナントなアプリケーションを求めれられることがあるので、こういった機能があると確かに便利だなと思います。

また、バーチャルサーバというテナントごとに独立したイメージのサーバを立てることができるようになるみたいでこちらもおもしろそう。

[JS1-11] #jt12_s111 The Heads and Tails of Project Coin

Coinの話。

CoinはJava7から入っている小さい変更です。

小さいといっても、Javaの世界において影響度は小さくなく、そういった変更に対する影響の話やコンパイラでどう解釈されるかなどの話があって、Coinの仕様自体の話よりもそちらの話がおもしろかった。

Coinは6つのフィーチャーだけど、その小さなことが他の機能に影響しており、全体の1/3程度に影響がしているらしく、樹形図のようなものを見せてもらいました。それらに対してどう影響を考慮していくかといった、開発プロセスの考え方の話がおもしろい、これはスライドあげてほしいなぁ。

Coin自体については一度サンプルコードを書いてみたことがあったのでおおむね知ってる話でした。

ちなみにサンプルコードはgithub上に上げています。

https://github.com/hiroisojp/java7-dolphin-example

[JS1-21] #jt12_s121 Pragmatic Cloud and PaaS with Java EE 7 (and GlassFish)

1つめのセッションに続いて、Cloud関連の話。

このセッションでは特にPaaS関連が中心でした。

PaaSではMulti-Services, Elasticity, Isolationを意識する必要があるよう。

Multi-Serviceは、

Elasticityは、リソースの増減を柔軟にすること、

Isolationは、独立性を確保すること、マルチテナントになった場合でも他のテナント（顧客）のものは見えないようにしないといけない。

IMS(IaaS Management Service)と呼ばれるアーキテクチャで、PaaSのリソースの上げ下げをコマンドラインインタフェースやAPIでできるようにするという感じのスライドがあったけど、あまりよくわからなかったです。

IMSは、ユーザには、あくまでレイヤーしか見せないようにラップして、実際のサーバをelasticに増減するのはPluginで頑張る感じなのかなという印象を受けましたが、理解があってるかはいまいち不明。

AWS Pluginとか、Azure PluginとかIaaSにサービスに応じたPluginが出てきたりするのでしょうか。

なんにせよ、クラウドのポータビリティを意識しているんだなところはいい印象です。

ただ、SpringSourceのクラウド間のポータビリティへの取り組みである、Cloud Foundryとかも少なくとも日本ではあまり聞かないのでここらへん、うまく仕組みを作っただけでは普及しないのではないかと思っています。

たぶん、クラウドベンダーと如何に連携ととって推し進めれれるかがキーポイントとなりそう。

デモでは、Glassfish4によるelasticなサーバの上げ下げのデモがありました。

サーバにメモリ負荷をかけると自動的に別のサーバが起動してAutoScaleするデモでした。

AutoScaleするトリガーはいくつか選べるようで、今回はメモリが一定値以上なら自動的にスケールする設定のよう。

デモでは、全部同じマシン上で別ポートとしてサーバをあげていましたが、実際には別の仮想サーバであげたりすると思うので、そのあたりの連携とかどうなんだろう。

ノードマネージャ的な機能が入るんでしょうけど、どうAWSとかと連携していくのかまだイメージがわかない。

[JS1-31] #jt12_s131 Project Lambda: To Multicore and Beyond

Lambdaの話。

セッション名を読み上げる司会の方がランバダとかいってちょっと吹いた。（まぁそう読めちゃうやんね。。）

Lambdaは、構文がかなり大幅に書き換わるからか、まだまだ変わる可能性があることが強調されていました。

例えばソートするときには、以下のようにかけるみたい。

「people.sort(comparing(Person::getLastName));」

今までだと、無名クラスでComparatorを自前で書いてたりしたけど、かなりすっきりする印象。

セッション後の周りで、「これウチの人間はたぶん使えない」とかいう声も聞こえてきましたが、個人的にはすっきりするのでうれしい。

新しくJavaやる人にとっても最初からこういう構文だということで入ってくればよりすっきりわかりやすいのではないかなと。

これは早く欲しいフィーチャーです。

Interfaceのdefault methodの話。

インターフェースに直接、デフォルトの実装を定義できるようになるらしい。

スライドの例では、デフォルトでUnsupportedOperationExceptionをスローするとか。

2つのインタフェースに同名のデフォルトメソッドが実装されていたりしても、どちらを利用するか明示できるみたい。

implements Hoge, Fooとして、両方ともに、getValue()みたいなデフォルトメソッドがあってどちらを使うかというようなときなど。

この機能はインタフェースデザインをうまくできないとハマる原因となりそうなので、ちょっと注意したいところ。

[JS1-42] #jt12_s142 JAX-RS 2.0: What's in JSR 339?

JAX-RS2.0の話。

JAX-RSは全然使ったことないけど、アノテーションスタイルでかなりすっきりかけるようで好印象。

が、Spring MVC使ってるとちょっとしたJSONやXMLは普通に@ResponseBodyで返せるので、Spring使ってるとあまり出番はないかなと思った。

ただし、JAX-RS2.0ではいろいろ機能を拡充していくみたいで、Bean Validation対応や、独自Interceptor、PreMatchRequestFilter、RequestFilter、ResponseFilterといった拡張ポイントがいろいろ用意されているようなので、このあたりの仕様をもうちょっとウォッチしてみたいところ。

なんかSpring使ってると、だいたいそれあるよ的な感じになってしまうのですが、RESTスタイルのJava標準としてキレイに整備されていくと、Spring側にもフィードバックされそうでいいなぁという感じです。

[JS1-51] #jt12_s151 HotRockit: What to Expect from Oracle's Converged JVM

JVMの話。

会場アンケートで、どのJVM使ってる？という質問で

IBM J9 ->1人

JRocket->そこそこ

HotSpot->多い

という結果に。

自分もIBM Java6は使ったことがあるのですが、J9=Java7のことかと思って手をあげませんでした。（ゴメンなさい、唯一あげた一人の方。。。）

セッションの中心は、JRockit Flight Recorder（今後は、Java Flight Recorderに名前が変わるみたい）でした。

ボトルネックや、メモリリークの検知デモがあったりいくつかのデモがあって非常にわかりやすかったです。

WebLogicな案件でもあまり使ったことなかったけど、かなり興味わきました。

あまりクリティカルなメモリリークにぶち当たったことがないので使いこなせていませんが、WebLogic案件で試してみよう。

スペシャルセッション

LTラッシュ。

Dukeの顔を模したおにぎり弁当+飲み物（ビール、ノンアルコール）が配布されてうきうき。

大体爆笑していたので、全然メモってません（笑

ドラ娘さんのやりとりや、ろくろやバルスなど楽しませていただきました。

という感じで１日目終わりです。

STS(eclipse)でSeversからサーバ起動時、maven管理のjarファイルをクラスパスに通す方法

今まではMaven2 Additionalプラグインを使って、WEB-INF/lib以下にjarをコピーしていたのですが、自身で開発をしているjarでsnapshot版に変更が頻繁にあると、コピーが少し手間に思っていました。


ということで少し、eclipseの設定を見てみたところ、プロジェクト直下の.classpathファイルにある、mavenのclasspathentryを直接編集すればうまく動きそうです。
mavenのclasspathentryに対して、org.eclipse.jst.component.dependencyに関連づけることにより、サーバ起動時にクラスパスが自動的に通っているよう。

これで、mavenでjarなどを変更しても、いちいちWEB-INF/lib以下にコピーしなくてもよくなった。

JAWS Summit 2日目

JAWS Summit 2日目に行ってきました。（1日目は参加せず）


＜資料＞
サイト
まとめリンク
発表資料(slideshare)

・サイト
JAWS Summit 2012

・facebook
JAWS Summit 2012ファンページ
クラウドデザインパターン (cdp)

・slideshare
クラウドデザインパターン デザインパターン概要編
クラウドデザインパターン コンテンツ配信編(Movable Type on AWS)
クラウドデザインパターン Eコマース編(EC-CUBE on AWS)
クラウドデザインパターン キャンペーンサイト編(WordPress on AWS)

# ベストプラクティス Force.comとAWS連携は、3/4時点では公開されておらず

・Toggetter
2012/03/03 JAWS Summit 2012 PROGRAM Day2 クラウドデザインパターン


＜感想＞
それぞれのセッションの内容は、詳しく記載されているのでそちらを参照。（最近はホント、資料もアップされる勉強会が多くて親切ですね、感謝。）

注）以下でのクラウドは、基本的にPaaS、IaaSを想定しています。

AWSも認知度が上がってきてるかと思えば、まだまだそうではないみたい。
知ってる人は増えてきてるけど、使いこなしてる人はまだまだ少ない。

AWSクラウドをより伝わりやすくしたい。
ということで考え出されたのが、クラウドデザインパターン（CDP）。
クラウドをつかうときの典型的な問題の解決するパターンとのこと。

デブサミでもチラッと聞いたけど、物事を認知させるのには、名前が重要。
アジャイルのように名前と意味が別解釈されたり一人歩きする危険性はあるものの、名前がないと認知しようがない、確かにそうだ。

facebookのクラウドデザインパターンのファンページをいいねすれば、CDPのパターンを記載したwikiが見れる。
（が、一説によるとgoogle検索してもクロールされてるかも、facebookのアカウントを持ってない人はググればでてくるかも）

最近は、こういう勉強会などのfacebookのファンページも多くなってきてるのかな。

CDPは、3/3時点で45パターンあるらしくて、もうすこしで48とか。
ちらっと見てみると、図でイメージがちゃんと示されてるのが多くて、パターン適用時の注意点も書いたりしているものもあって、育っていくとすごく便利だと感じた。
（AWS忍者や、JAWSUGの方々が書いてると思うので、実体験によるものも多く載ってると思います。）


ただし、パターンだけあっても、じゃあそれを自分たちのシステムを作る際にどう適用さればいいの？ということになるが、それをシナリオとして一緒に伝えていくためのものが、今回のセッションの中心だった。
コンテンツ配信、Eコマース、キャンペーンサイトなど。
こういったシステムでどういうスモールスタートをして、どうスケールしていくかが順々に説明されてわかりやすい。


世界を見ると、世界ではクラウドを使いこなしている企業が多く成功している。
日本ではまだまだ弱いという印象（らしい）。
AWSとしてはクラウドを使いこなせるデベロッパーを増やしたい、とのこと。


デザインパターンのプレゼンを見ていて、やっぱりクローズドな環境と、パブリッククラウドはスケールのしやすさが桁違いだなぁと。
QAでもあったけど、スモールスタートから、順々に規模を大きくしていくこともできるし、逆に規模を縮小していくこともできる。
ホント、柔軟(elastic）だなぁと。

コストとしても、個人的にはどんどん（AWSだけでなく）パブリッククラウド自体が流行って、クローズドな環境とのコスト差をどんどん広げていってほしいと思う。

今でも相当あると思うけど、より差がついていくことによって、クローズドオンリーな環境でも検討の機会が出てくると思うので。

もちろん、セキュリティリスクや、既存運用の取り回しなどいろいろな乗り越えるべきハードルがあると思うけど、トップダウンで判断されやすいコストで大きく水を空けられると検討せざるを得なくなる。
（まぁ、世の中にはどうしても外に繋げないシステムもあると思うけど、それはそれで寡占ビジネスなんだろうなぁ）

官公庁や金融機関などの事例はまだ少ないという認識だけど、時間の問題で先に着手できたところがアドバンテージを得れるんじゃないかなと思う。
官公庁や金融機関を扱ってるSIerもアドバンテージを得るためにも提案してほしいなぁ。（SIerとしての旨みは少ないのかもしれないが）

たぶん、いずれはクラウドが来るな、しなきゃなと思っているところはいかに早く手を出していけるかが大事。
クラウドの流れはもう規定路線になってる。
AWSでないにしろ、検討をしてノウハウを溜めていかないとどんどんコスト差がついていく。

後はベンダー（クラウド）ロックインを避けるためにももう少し、クラウドポータビリティが充実してくるといいなぁ。
SQLみたいな共通言語としてAPIが共通化されればいいのに。
（SpringSourceがクラウドポータビリティを目指していたと思うけど、どうなったんでしょう。。）
仮想サーバなどのインフラはある程度共通化できたとしても、運用ノウハウはクラウド固有だから難しいかな。

個人ユースでは去年はEC2、RDS、S3などを利用していたけど、APIももう少し深堀して行きたい。
全部のサービスを使うには手広くなりすぎてると思うので、自分に必要なサービスから入っていて、必要になったら徐々に見ていく感じがいいと思う。

デブサミ 2012 2日目

デブサミ 2012 2日目に行ってきました。

1日目に続き、自分用のメモとして。

＜自分が聞いたセッション＞
・若手～中堅まで幅広く
　・【17-B-5】アジャイルマニフェスト ディケイド

・チームリーダ以上向け
　・【17-C-2】仕事のバトン、渡っていますか？ - プロジェクト管理におけるコミュニケーション基盤作り
　・【17-A-4】Scrumで組織改革

・その他
　・【17-B-7】ソーシャルコーディングの世界
　・【17-B-6】Building scalable web apps
　・【17-A-3】スマートフォンにおけるHTML5実装の最先端


＜セッションについて＞
2日目は、GREEさんではなく、DeNAさんが多かった。
そのほかは、1日目よりは雑多（ノンジャンル）な感じが多かった気がする。


＜感想＞
・【17-C-2】仕事のバトン、渡っていますか？ - プロジェクト管理におけるコミュニケーション基盤作り
少し遅刻して聴講。
プロジェクト管理というより、JIRAの話と絡めて、課題管理ツールの話だった気がする。
　
顧客と一緒にJIRAなどのツールを使えるのはいいなぁ。
もちろん顧客からの要望とかQAとかは社内でも管理しているところが多いと思うけど、消しこみとか管理とか正直二度手間なときもあるし。
プロジェクトを開始するときにそういう風土をもてるならより顧客と一体になってできそう。

セッションの中で、時間管理重要というのがあった。
課題管理ツールで、時間管理をするというのではなくて、別のツール（WBSやExcel）などで時間管理をして、その枠内（タイムボックス）で課題管理ツールを使うことのがよいらしい。
このあたりはその通りだと思う。

僕はTracを良く使うんだけれども、基本的にはWBSとは関連させてない。
スケジュール管理はMS-ProjectとかExcelで割り切って使っている。というか1:1になることが少ない、粒度が合わない。
スケジュール管理というか、バグや修正など、決まった１つの事象についてのトラッキングにやっぱり向いてるんだと思う。
リリースのときのタギングとか関連付けにも使えるので、課題管理ツールはやっぱりそういうものに使うのがいい。


起票ルールについて、「気遣い（言葉遣いを丁寧に）」が重要というのはすごくすっと入った。
バグにぶちあたってイライラすることもあるときに、（個人を）非難するような書き方になったり、気分を害す書き方になっていることもあって、
そういうときは（仕事とはいえ）コミュニケーションがうまくいかず、非協力的な態度をとったり、とられたりするということもあったなぁと。
そういうのに時間をとられるのはやっぱりもったいない。


浸透をいかにさせるか、というのはすごく共感できて、Tracを使うようにしたときも最初はなかなか使ってくれなかった。
使い方に手間取ったりすると嫌がられる。
なので、一緒に操作したり説明したり、という地味な対応が待っている。

導入する自分と、導入しなければいけないその人にとって、メリットや知識や思いに乖離があって、そうなる。
課題管理ツールって、ともすれば別の運用で何とかなる場合というものも多いので、そうなる。
そこで以下に一緒に動いて障壁を取り除けるかってのは大事。

昨日のデブサミの自分戦略の部分で、アウトプットを広げるというフレーズがあったけど、
自分のいいと思っているものを相手に浸透させていくというのもアウトプットを広げるという一つなのかも。
浸透させられないというのは、そこへの取り組みが足りてないってことか。


・【17-B-5】アジャイルマニフェスト ディケイド
角谷さんのプレゼンは初めて拝聴させてもらったけど、なにこれおもしろい。
ご自身でも言ってるとおり直接は役に立たないんだろうけど、一緒に考えさせられる講演だった。

アジャイル（本来は形容詞）やパターンなどの呼び方が先行していて、手法や名前に囚われてはいけないとのこと。
プランニングポーカーやってる、朝会やってる＝アジャイルではない。

広めたりするときは名前がついてるほうがいいけど、それが実際に自分たちの状況において適用するときにあうかどうかはわからない。

クラウドとか、ビッグデータとかアジャイルとか、確かに世の中に認知させるためには名前が必要だけど、それが自分のコンテキストの中で有効かどうかは自分自身にしかわからない。
あるところでは有効であった手法でも自分にとっては、前提や制約条件が違ってそのままハマるわけではない。

世の中の色々なプロジェクトから類似の問題は抽出できて、パターン化することはできる。
自分が解決したいものがそのパターンに当てはまったとしても、同じ手法が通じるとは限らない。

たぶん、自分（たち）自身の問題として真剣に解決するためにどうすればいいか、価値を提供できるにはどうすればいいか、というのを考え続けていかなければいけないんだと思う。


プレゼン資料みただけではわけわからないので、話と一緒になって聞くというライブ感は大事だなぁ。
頭の中で組み立てられているストーリーとスライドが一体になって展開されたときの爆発感は見ててわくわくする。

あと、講演終わってから、たまたま生matzを近くで見かけて、こっそり、おー！ってなってた。（笑）


・【17-B-6】Building scalable web apps
herokuの中の人が来日してのお話。

全編英語でお送りされました。
（自分のリスニング力の低さに）泣きそう。

スライドにちらっとある図と部分部分で聞き取れる単語でフル推測の時間。

herokuが、自分たちのアプリ開発以外の部分（インフラ、デプロイなど）を全部面倒見てくれるってのだけなんとなくわかった。
デモは、gitでherokuのリポジトリにpushするだけでheroku上でアプリが動くデモだった。
gitのpush時にhookして、ごにょごにょしてる感じ。

configがAPIでできるようなことがちらっと聞こえた気がするけど、AWSみたいな感じなのかな。

正直、herokuうんぬんよりも自分のリスニング力の低さに絶望した。
世界に通じるエンジニアになるためにも英語は避けれないなと実感。


・【17-B-7】ソーシャルコーディングの世界
まとまりのないようなスライドだったけど、それでもどこかまとまってるような良くわからない感じ。
でも、githubでのソーシャルコーディングの楽しさやすごさはすごく伝わってきて楽しく聞けた。

ソーシャルコーディングを活用できるとすごく世界が広がるんだろうなぁ。
でもコードを書くのもソーシャルだと、コミュニケーション力が低い人がますます淘汰されるのか。

企業が求めるコミュニケーション力というものとは別だと思うけど、仕事をするのにコミュニケーション力ってのはやっぱり必要なんだなと実感。


2日間参加して、自分の進んできた道や足りないところなどを見つめなおす機会になりました。
こういったところで刺激をもらったり考えたりするのってやっぱ大事。

デブサミ10周年おめでとうございます、そしてありがとうございました。