デブサミ 2014 1日目

デブサミ 2014 1日目に行ってきました。

すでにまとめができてるようで関連資料などはそこで公開されそう。

デブサミ2014、講演関連資料まとめ

自分が聞いたセッション（リンクはTogetter）

• 【13-B-1】サーバプロビジョニングのこれまでとこれから
• 【13-B-2】グリーにおけるChef導入事例～既存の資産を活かし新しい技術を導入する～
• 【13-B-3】社内システムの構造と設計、実装のはなし
• 【13-A-4】新卒エンジニア研修ですべきことできること
• 【13-A-5】成功と失敗の狭間に横たわる2つのマネジメント
• 【13-A-6】Mobageを支えるテストエンジニアリング
• 【13-B-7】何故クックパッドのサービス開発は日々進化しているのか

全体の話

全体の傾向として、インフラ、テスト自動化、開発を通してのプロセスに関わる話が多い印象を受けました。

数年前はフレームワークや最新技術などのセッションが多く、少し前はクラウドの話が多く、これら前の技術・仕組みが当たり前となっている前提で、次のステップへ進んで行く話なのかなと感じました。

クラウドやCIは当たり前で、それをどう組み合わせて自分たちの開発プロセスをスムーズにしていくのかという点が中心な印象。

個々のセッションの話

セッション資料はいまのところすべて公開されているようなので、自分が感じた点を中心に記載しています。

【13-B-1】サーバプロビジョニングのこれまでとこれから

講演資料（speakerdeck）

serverspecなり、Chefなり、dockerなり今インフラレイヤーでトレンド周りを押さえたセッションで一発目としては興味深く聞けました。

会場アンケートで、Puppet、Chefを使用したことがあるかのアンケートだと、

• Puppet -> 数人
• Chef -> 3〜4割手を挙げた

という感じ。

Chefはホントにもう流行ってるようで、まだきちんと取り組めてない自分はちょっと焦る。

ただし、話の中でImmutable（Disposable）なインフラ、作って破棄できる環境というのが出てきてこちらのほうが自分は興味深く聞けた。

既存の動いているサーバに変更を加えるのではなく、全く新しいサーバを構築して、サービスの切替はロードバランサーなどで切り替える。

成功したら元のサーバは破棄（Dispose）、失敗したら元のサーバに向き先を戻す。

-> Blue-Green Deploymentという考え。（AWS EC2などによって容易になってきている）

Chefはかなり気になっているけど、環境を作った後に、差分でどんどんアップデートして行ける（メンテできる）ものかなという懸念があった。

学習コストが高いと聞くし、あまり難しいことまでこだわりすぎるとハマると思っていたので、シンプルに使える構成に持って行くのはたしかになるほどなぁと。

サーバにImmutableであることの制約をいれることによって、同じツールで常に同じ状態を維持するという敷居が下がるのかなという期待が持てる気がした。

後半に出てきた、Dockerは直近で試してみたいものだったので、デブサミという場でも出てきてちゃんと広まってるんだなと思って試してみたい意欲が上がった。

【13-B-2】グリーにおけるChef導入事例～既存の資産を活かし新しい技術を導入する～

講演資料（speakerdeck）

引き続きChefに関連するセッション。

こちらでも会場アンケート

• Chef触ったことある -> 4割くらい
• Chef使ってる -> 1割くらい

という感じ。

こちらでもMutable、Immutableの話が出てきていて、こちらだと、ChefはMutableだと相性がいいとのこと。

複雑で大変そうと思ったら、グリーではChef Soloをベースにラップしたツールを内製して使ってるよう。（Chef ServerはSPOFなり、Erlang人材不足などによりで採用しないことになったとのこと）

セッション聞いてると、Chefでなんでもかんでもやるのは厳しいかなとなんとなく思った。
ある程度、したいこと、やることを限定してやらないと収集つかないような印象を受けた。（それを乗り越えれば幸せになれるのかもしれないが、そこに至るまでが相当ハードル高そう）

前述のImmutable前提のように割り切ることができて、新規からのべき等性を確保するという割り切りができるならよさそう。

【13-B-3】社内システムの構造と設計、実装のはなし

講演資料（slideshare）


社内システムほど、他システム連携を考えようというのがすごくいいなと思った。
連携するのはやっぱりJSONが便利。

社内システムは長期運用が前提になりがち。
欠点や問題点があっても、長い間ほっとかれるものもある。
ドキュメントは、風化していくので、データ自体が人に見やすい形になってるのはとても大事。
たしかによっぽどカリカリなパフォーマンスを求められない限り、わかりやすいもののほうがいい。
触る敷居が低いというのはシステム連携を考えるにあたって無視できない要素だなというのを再認識した。

JSONなどのAPIを提供する際には、view側にも仕組みを持たせすぎるよりも自身のviewからもそのAPIを叩くようにした方が修正が少なくてよい。（クライアントjsでそのAPIを叩く方式等。）

「社内システムほど試しやすい場はない」
まさに。

【13-A-4】新卒エンジニア研修ですべきことできること

講演資料（speakerdeck）

個人的には本日一番、ためになった（ある意味耳が痛い）セッション

「自走できるエンジニア」

これができるエンジニアを育てることはやっぱ難しいと再認識。
出来る人は勝手にできるようになるけど、そうじゃない人を引き上げるというのは、やはりかなり根気や覚悟がいるということ。

理想を先に刷り込むという表現があったけど、いいケースをちゃんと知っておくというのはとても大事だと思った。

実際の現場だと、多くのことがバッドノウハウなどで回避できるけど、それって本来は良くないことなんだという意識をちゃんと持てるか（それが当たり前だと思わないか）というのは成長に必要な要素だなと感じた。

物事に疑問を持てるエンジニアになれるかというのはエンジニアとしてやってくには大事な要素だ。

考えとして、

• 基本的な技術向上、マインド向上
• 問題を問題と感じれるか
• 応用力を身につける

というのは考え自体は自分もなんとなく思ってたけど、それを体現されるまでにもっていったのは素直にすごいと思う。

【13-A-5】成功と失敗の狭間に横たわる2つのマネジメント

講演資料（slideshare）

マネジメント関連のセッション。
マネジメントといっても、よくいうQCDに関わるマネジメントではなくて、マインドのマネジメントのお話だった。

全体的にふむふむと一緒に考えながら聞けた。

期待マネジメント
ここまでやってくれる「はず」が実は自分とチームや、上司が思っていることが違うことが往々にあるので、お互いに表明してすり合わせていかないといけない。

なんとなく周囲に期待されているものはわかるけどはっきりする機会というのはそうそうないのかもしれない。
自分の場合は、これやりたいとか、これやりますと言い切ってから取り組んでるので、そういう意味だと自分の表明はできているかもしれないけど、反対に周りの期待することをちゃんと聞けてないのかなと感じた。

また期待は変わっていくものなので、定期的に確認する必要がある。

モチベーションは何気ない一言で乱高下する。
また人によって鍵穴（きっかけ）は全然違うし、他人がその鍵を持っているわけではないので、周りは手助けはできるが、やるのは自分自身。

良いプレイヤーは不調な時が短い、調子を上げれることも重要。
へこんだときに立ち直れるスイッチを自分で知っておくのは大事。

これは確かにそうだと思う、常にいい状態で入れる人はいないと思うけど、できる人はなんらか自分のリフレッシュ方法やゾーンに入りやすくする方法などを経験的にも持っている気がする。

【13-A-6】Mobageを支えるテストエンジニアリング

講演資料（slideshare）

テストに関する、チーム組織が中心なセッション。

DeNAではSWETと呼ばれる特殊チームがいるようだ。
名前は違えど、Google(SET)やMS(SETD)にも同種のカテゴリはあるらしい。

テストのパターンところで、ブラックボックス、ホワイトボックス、グレーボックスと三種類出てきて、グレーボックスってあまり聞いたことない単語だなと思ってたら、DBやキャッシュなどアプリデータを直接いじってテストするということだった。

条件付きの結合テストに近いのかなと。
前提を置いてデータを積んでテストするということであまり特別な感じは受けなかった。

テストでCalabash(Cucumber)を使ってたみたいで、やっぱりいまいち受けはよくないみたい。
自分はあまりCucumberは肌に合わない（無理矢理感が強くて中途半端になりそう）と思っていて触ったことはないけど、Cucumberを絶賛している資料とかはあまりみたことがない。

Appiumというのがあるそうで、こちらはWebDriverを使っているっぽい。
やっぱりWebDriverベースのツールがいいようだ。
自分もWebDriverはよく使ってます。（よくInternetExploreDriverに泣かされるけど）

【13-B-7】何故クックパッドのサービス開発は日々進化しているのか

講演資料（speakerdeck）

クックパッドの開発フローのセッション。

java-jaの方だったけど、最近はその界隈の人たちはあまりきてないのだろうか。
java-jaのセッションは昔は冷やかしとか爆笑とか結構あったような気がするけど、今回のセッションの雰囲気はそんな感じではなかった。（くすくす笑いはあったけど、昔のような内輪ノリはなかった）

全体を聞いた印象は、クックパッドすごい。
クックパッドは、ほぼすべてでGitHubを活用していて、デザイナーさんだけでなく、サポートデスクの方もGitHubのIssueなどを直接扱っているよう。

GitHubという土台があるからこそだと思うけど、サポートの方までGitHubを活用するというのは目から鱗な感じ。

ここらへんをある程度個人の裁量で決めれる組織風土というのもあるんだろうけど、そういったより良くしていこうというのがいいサイクルで回ってるんだなというのがみてとれた。

少し前は、タスク管理と言えばRedmineやTracなどが活用されていたけど、GitHubベースになると下手に連携とかしないでIssueを活用する流れの方がいいのかな。

2013年の振り返り

2013年の振り返り。

今年は、去年（2012年）に培ったものを別のプロジェクトに適用していくなど、改善にフォーカスした一年でした。
まったくの新規技術といったものには触れてはいませんが、去年本格的に導入しだしたもの（Jenkins、WebDriver、Gradle）を引き続き導入・深く掘り下げてることが多く、裏方寄りのお仕事が中心になってる状態です。

そういった意味では去年の振り返りの後半に書いた方向に、少しは舵取りできてるのかもしれません。（アプリ単体ではなく、運用・保守までトータルしたクオリティを向上させ、疲弊しない開発やプロジェクト運営というレールをしけるようになっていきたい）


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

• Jenkins x WebDriver
• ソース自動生成

・Jenkins x WebDriver

社内的には、自動テストが受けがいいようで、WebDriverの方が受けがいいのですが（苦笑）、個人的にはJenkinsさんにいろいろ頼るのが好きです。
去年は、初めて導入という感じでしたが、だいぶ回し方も慣れてきたようで、新しいプロジェクトではどうJenkinsを活用してビルド＆デプロイ、テストをうまくこなしていくかを考えれるようになりました。（導入するのが当たり前になった）

Jenkinsはある程度テンプレ的に構築できるのですが、WebDriverをうまく活用していくのはアプリの特性やくせもあるので、まだ一概にすっと導入できるかというと、まだ難しい部分もあります。
対して、あらかじめWebDriverなどブラウザ自動テストを行う前提で設計をしておけば、バッドノウハウも少しずつ溜まってきているので、ハマりどころが少なく抑えれるかなと思います。

・ソース自動生成

僕自身も、諸手を挙げて賛成というわけではありませんが、きちんと適用範囲を決めて導入するのはアリだと思っています。

基本スタンスとしては、すべてを自動生成とか、設計書と同期とりますとか、GUIでノンプログラミング、というのはよほど簡単なシステムでないと難しいと思っています。

しかしながら、数百画面レベルの規模だと、さすがに一画面ずつ一からというのは非効率なため、ある程度パターン化して、可能な範囲で雛形を生成していくのは一定規模だと必要かなと思っています。

このあたりをソース自動生成用のフレームワークをベースにして、アプリに特化した対応をすることによってうまく適用していくというのが今のところの現実解かなと考えています。

とはいえ、やりすぎると自動化ハイ（自動化が目的になる）となるので、

• 可能な範囲の見極め（頑張り過ぎない）
• 書き換え可能（その後は各自でエンハンス可能、ツールによっては編集禁止とかもあるので。。）
• テストも合わせて雛形生成（デグレ検知＋テスト自身の作成も負荷になる場合もあるので）

というくらいのカジュアルな方針でいいと思っています。

実際、これくらいの方針でもちゃんと母数が多いと効果はでるので、アリかなと。

また、自動生成されるコードは、キレイなコード（可読性を意識＋あらかじめユーティリティや抽象クラスを活用する設計）を心がけているため、コピペコードの防止という面も合わせてあります。（プロジェクトの都合でどうしても、きちんとしたコードを書ける要員が集めれないという場合は助かります）

・来年（2014年）

ひとつ楽しみとしては、gitを社内で利用できるようにしました。

2013年後半から徐々に準備しており、年明けごろからはgitベースで開発できるようにしたので、来年はそちらの方面で楽しく開発できそうです。

subversionでもいいじゃんという話もありますが、結構リリースが複雑になりそうなプロジェクトがあるので、ブランチ、マージがより柔軟なgitでチャレンジすることにしました。

もう一つは、出遅れ感はややありますが、chefなどのサーバ管理ツールをなんとかねじ込みたいですね。数はそんなにないとは言え、似たようなサーバを構築することはそこそこあるのでこのあたりのフローも省力化していきたいです。

来年も、基本路線としてはやはり、疲弊しない開発やプロジェクト運営を行えるようにしていきたいというのは継続していきたいと思います。

# あとはもう少し、勉強会の参加を増やしていきたいところです。
# 下手すると来年はデブサミが勉強会始めとなるかもしれません。

Web✕Java - HTML5で進化したWeb標準を、Java技術でどう扱うのか？ に行ってきました

・サイト
  http://atnd.org/events/42782

　公開可能資料は後ほど、html5jえんぷら部で公開されるとのこと
　http://www.html5biz.org/

・アジェンダ
  ・今のWeb標準とStruts/Javaの問題(仮)
  　出遅れて受付待ちで拝聴できず。

  ・Java EE の概要と HTML 5 の取り組み
  　# 資料は9/10午前時点で未公開
  　twitterのTLによると近いのは以下らしい。
  　http://www.slideshare.net/mobile/OracleMiddleJP/java-ee-7-detail
  　http://www.slideshare.net/OracleMiddleJP/java-ee7-html5

  ・Strutsから移行する人のためのJSF基礎
  　http://www.slideshare.net/SatoshiKubo1/strutsjsf

  ・JavaプログラマのためのScalaプログラミング
  　# 資料は9/10午前時点で未公開

  ・JavaからScalaへ　~ScalaでWeb開発はこう変わる~
  　http://www.slideshare.net/takezoe/javascala


・全体的な感想
タイトル詐欺（笑）
html5の話がほぼなかったのは残念。

半分くらいは、Scalaだった気がする。

Scalaは業務では使えていないけど、FWとかはウオッチしているので、実体験としてのplay2、Scalatraの話が聞けてよかった。
竹添さんが言っていたけど、「エンジニアとしては新しいものが出てくる環境のほうがよい」というのは同意です。
Javaは、まだまだアクティブだと思うけど、Seasar2のコミュニティがアクティブだったころよりは熱気というのは冷めている気がする。
（とはいえ、Springは継続的にSpring4まで来ていて十分活用していますが）

ただ、熱気という観点だと、ここ数年はJava/Scalaといった言語面というよりも、CI/DepOpsといった開発サイクル全体への取り組みへと分散して行っているという感触がある。
今まではプログラム中心でアクティブだったけど（ある程度成熟してきたのもあって）、CIやリリースサイクルの高速化、運用の向上といった点がフォーカスされてきているのかなと。

また、Oracleの寺田さんのJavaの話でいつももったいないなと思うのが、過去のアーキテクチャ（Struts/Spring/Hibernate）をよくdisること。
それと比較するよりは、EE7ではこう楽なんですよとアピールして行く方が建設的なのかなと思いました。

今、Springをそれなりに使っている人は、部分活用するにしても、わざわざ全面的にJavaEEに戻ったりはしないと思うので、新規参入者に向けて標準技術がいかに楽できるんですよと言って行く方がいいのかなと思う。
EE7でできることは、すでにSpringでできるか、Springと統合しやすいようなライブラリがあったりするので。

# tomcatと比較するのは、サーバ製品を売っているベンダーということで、理解はできます

同じjava内のStruts、Springと張り合うより、nodejs、ruby、.netなど別の言語からのパイを奪うほうがjava全体にとってはいいはず。


・メモ
・Java EE の概要と HTML 5 の取り組み
  ・Struts1.xはEOL、使い続けるなら自分たちで脆弱性の対応をしなければならない
    ・# ベンダー製品もバージョンのサポート期限やバージョンアップによる検証コストもあるのでそんなに変わるかなという気もしなくもない
    ・# strutsに限っては、枯れている、大手SIerがサポートし続けるだろうというのもあって別枠として捉える方がいいと思う

  ・相変わらず（？）のStruts/Spring/Hibernate dis
    ・# そろそろ未来の話を聞きたいところ
  ・EE7
    ・Oracle寺田さんのブログ内アンケートでは、WebSocket/JAX-RSなどが人気上位
    ・従来型(JSF)、次世代型(WebSocket, JSON, JAX-RS)どちらにも対応している
    ・JMSが改善されているらしい。
      ・# が、Springだと特にJMS用のクラスとか作らないでいいので気にしたことない
    ・EE7は、本番にいきなりはおすすめできない。まずはEE6から試してほしい。
　　・GlassFish4.0ではEE7の機能はお披露目的な感じで、本番環境ではまだあやしい部分があるとのこと
    ・http://yoshio3.com/2013/06/11/glassfish-v4-0-released-0611/
    ・# APIや仕様的に気になるのが多いけど、はっきりと本番で使える品質ですって言われてないと、標準を採用基準として考える人は（標準なのに）採用しづらいのでは


・Strutsから移行する人のためのJSF基礎
  ・JSFの拡張ライブラリ、Prime Faces、Rich Facesがある
  　・Prime Faces より Rich Faces のほうが、海外の認知度は高い？
  ・モダンブラウザしか対応されていないケースが多い（業務システムには少し敷居が高い）
  ・JSF1は、メモリを大量に積んで下さい（Struts時代の2倍から10倍ぐらい）
  ・# struts->JSFは需要あるのか。自分はthymeleafに流れてしまった。


・JavaプログラマのためのScalaプログラミング
  ・Java/Scalaでの記述比較中心
    ・# が、文字が小さくてスライドがあまり見えなかったのが残念。。
    ・# 資料公開されたらゆっくり見てみたい
    ・# groovy/gradleで文法が似てる部分もあって、慣れればすんなり読めそう
  ・traitは、mixin（別のオブジェクトの実装を持てる）できる機能。（という理解でいいのかな）
    ・java8ならインターフェースのデフォルトメソッドが近い気もする


・JavaからScalaへ　~ScalaでWeb開発はこう変わる~
  ・play2、Scalatraの話
  ・Javaの（これ以上の生産性向上の）限界を感じた、らしい。
    ・Seasar2 + Click + S2JDBC からScalaにポーティング ->コード量40〜50%減。
    ・play2、ノンブロッキングIOで大量アクセスをさばきやすい
      ・が、IOがノンブロッキングでも、ボトルネックはやはりDB待ちのケースが多い
      ・viewテンプレートもタイプセーフなので、実行前にエラーがわかる
      ・# これはけっこう惹かれる
    ・play2のwarプラグインは茨の道（はまりやすい）
    ・play2 -> BtoC（大量リクエストをさばくもの）
    ・Scalatra -> 業務アプリ向き（Javaからポーティングしやすい）
      ・# javaから行くなら、play2よりScalatraのほうが親和性がありそう

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の顔を模したおにぎり弁当+飲み物（ビール、ノンアルコール）が配布されてうきうき。

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

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

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