2013年11月10日日曜日

JJUG CCC 2013 Fall メモ

JJUG CCC 2013 Fall に参加しました。どのセッションも非常におもしろく、あっという間に1日が過ぎてしまいました。

WebSocket のハンズオンは社内システムに応用できそうなアーキテクチャ(WebSocket + JMS)なので、ぜひ WildFLy 上で動作するようにしてみたいと思います。

JVM コードリーディング入門は、大規模ソースコードのリーディングに普遍的に通用するテクニックを教えていただきました。めげずにいろいろと読んで行こうと思います。

Virt.x も気になるプロダクトです。まずは Acroquest さんのブログで入門したいと思います。

以下、メモをはりつけ(手抜きですみません)。発表スライドは公表されたら順次リンクしていきます。

参加セッションリスト



K-2 2013 エンタープライズ Java 最前線

GlassFish のロードマップ


  • 商用ライセンスサポートはバージョン 3.1.2.2 までで終了
  • バージョン 4 以降は OSS 版のみ提供
  • 今後 Oracle が提供する Java アプリケーションサーバは WLS のみ
  • 今後も Java EE の RI であるという GlassFIsh の位置づけは変わらない

Java EE 7 2013.6 リリース


  • EE 7 は EE 6 を拡張したもの。Web のトレンド(HTML5, WebSocket など)に対応したもの。
    • EE 6 は EoD の集大成と言えるリリースであった。
  • WebSocket の注目が高い(寺田さん調べ)
  • CDI + JTA で EJB をかなり置き換えられるようになった。
  • Bean Validation がいろいろなところで使えるようになった。
  • Concurancy Utility で、ユーザアプリケーション側でスレッドを起こすことが可能になった。
  • JAX-RS が Full Profile から Web Profile へ移った。

Project Avatar


  • JDK8_b103 以降で利用できる。 
  • 今年の Java One で OSS 化された旨が発表された。
  • Avatar を試してみたい場合、自力でセットアップするよりも、Avatar 公式サイトからダウンロードできる Avatar が同梱された GlassFish を使うのがおすすめ(どこにあるかわからない...)。 
  • Avatar は JS のエンジン(Nashorn)上で動作する。
    • Nashorn は JVM 上で動作する JS エンジンで、JDK8 の 1 プロジェクト。旧来の JS エンジンである Rhino より性能がよいらしい。 
      • 性能が良いのは、JDK8 における Invoke Dynamic 命令の恩恵らしい。 
  • Avatar で TSA を実現する場合。// TODO 寺田さんの絵がほしい。 
  • Avatar はデータバインディングに EL 式を使える。 
    • Avatar コンパイラでコンパイルする。 
  • Avatar でビルドしたアプリケーションは、GlassFish にそのままデプロイできる。 
  • 同じ AP サーバ上にほかの Java EE アプリケーションもデプロイされるので、Java <-> JS の相互呼び出しが可能。 
  • Avatar のサンプルアプリケーションは寺田さんのブログを参照。

Java EE 8 とその将来


  • まだまだ決まっていないことがたくさんあって、これからの状態
    • JSON バインディング、JCache は確実に入ってきそう。

R5-1 Java EE 7 WebSocket ハンズオン

// TODO WIldFLy で動かせるようにしたい！

  • 作成するアプリケーションは WebSocket による大規模リアルタイム情報配信
    • チャットとかだとバックエンドのサーバがあまり企業システムらしくないので、それらしいものを作る。
    • 利用テクノロジは WebSocket + JSF + JMS WebSocket
    • サーバはクラスタ構成にする。
    • JMS アプリケーションと WS アプリケーションは別のアプリケーションとして提供する。
  • 寺田さんは public フィールドはお好みでないようだ。
  • JSF のエッセンスは ManagedBean と EL 式。
  • Java EE 7 の WebSocket API は簡単に使えるように設計されている。
    • POJO
    • ポイントになるアノテーションは以下
      • @ServerEndpoint
      • @OnMessage
      • @OnOpen
      • @OnClose
      • etc.
    • Session#getOpenSessions で接続してきているすべてのクライアント情報を取得できる。 
  • GlassFish の JMS 実装は OpenMQ
  • JMS2.0 かんたん！
  • 途中で出てきた 4001 ってなに？


H-3 ユニットテスト改善ガイド


  • ユニットテストを組織に広めるためのヒントを紹介
  • (参考)渡辺さんのクラスメソッドのブログ記事
    • JUnit はあくまでテストするためのツールであり、「JUnit を使うこと」が目的ではない
    • ユニットテストを作るにはそれ相応のスキルが必要である
    • etc.
  • ユニットテストは適材適所であるべき
    • 全てやる派 vs 薄くやる派
  • テストは誰でもできる簡単なものではなく、トレーンングが必要
    • テスティングフレームワークの使い方やテスト手法を学ぶ
    • プロジェクトのコストとして扱わず、業務時間にトレーニングを実施する。
    • コーチができる人を探す。
  • テストが難しいコード、簡単なコードがある。いきなりすべてをやろうとせず、できるところからやる。
  • テストがしにくいAPI=使いにくいAPI。
    • テスト対象を直してはならないという勘違い。
    • 一度書いたものは変えたくないという抵抗感を減らす1つの方法は、テストファーストを行うこと。
  • CI を導入する前に、テスト文化を根付かせるのが先。
    • CI 導入にもノウハウが必要。一緒にテストも学ぶのは大変。
  • CI の効果
    • リグレッションをすぐに検知できる
    • 自動化が「見える」
      • モチベーションが上がる
    • 見える化のおかげで、管理者にも説明しやすい。
  • テストコード自体のメンテナンス・リファクタリングが必要。
    • テストは使い捨てでない
    • DRY をサボると確実にコピペ地獄になる。
    • 動かないテストは思い切って捨てるべき
    • テストは常にきれいにしておくこと。
      • ただし、整理しすぎるとかえって可読性が落ちることがあるので、あくまでテストとして読みやすいバランスを保つこと。
  • ユニットテストの効果を伝えずに押し付けても反発されるだけ。
    • メンバの手間を増やさない
    • 導入する目的を説明する
    • デバッガの代わりに紹介してみる
  • 上司の説得方法

R2-4 Javaアプリケーションサーバ構築・運用の勘所

ログ管理


  • トラブルシューティングの基本
    • GC ログ
      • 取っていないケースも多い。
      • 標準出力に出すのもあり
        • 普通の出力と混じってしまうのでは？
    • スレッドダンプ
      • ThreadLogic
        • WLS に特化した機能も含むものの、ほかの製品でも使える。
        • 侍のほうが直感的な UI だが、ThreadLogic は診断結果などが出
        • 大きなスレッドダンプも読み込み可能。
    • アクセスログ
      • JBoss/Tomcat はデフォルトで出るようになってほしい。
      • 性能劣化している時の切り分けとして、前段の Apache のレスポンスタイムと比べる。
    • CPU
      • ps auxwww -L プロセス単位でなく、スレッドごとのCPU使用率を知りたい。
      • コネクションプール不要論に対する反論
        • プールするのは性能だけでなく、リソースを制限することにも意味がある。

R5-5 JVMコードリーディング入門 ～JVMのOS抽象化レイヤーについて

対象のソースコード


  • jdk7u

読む前の準備


  • ビルドするかしないか
    • デバッグ実行しながら動作を調べるなら必要
    • 動かす前の調査としてコードを読むなら不要

JVM を読む基本的な方法


  • わからなくても全部をざっくり何週も読む
  • メモ・図解をする
    • わかったこともわからないこともメモしないと忘れてしまう。
  • 名言「理解とは真実との相対的な距離を縮める行為である。」
    • 仮設と懸賞を繰り返す。
  • 鳥の目と虫の目を交互に繰り返すことでわかることもある
  • ファイルサイズの大きい物を把握する
    • 重要 or ゴミの可能性大
  • 抽象度の高い名前を付けられたファイルを把握する
    • より重要度が高いファイルである可能性大
  • クラスの関係性を把握する
  • いろいろなクラスから継承されていたり、フレンド関数としてアクセスされてたり
  • C, C++ のレイヤを切り分ける
    • システムコールを行う層とそれを使う層
    • OS との境界
  • ざっくり読む
    • 読む部分と読み飛ばしても良い部分
      • assert -> 読む。なんらかの重要なチェックが行われている
      • non-PRODUCT -> 読み飛ばして OK。デバッグ情報など。
  • ソースコードのコメントをどう読むか
    • コード中のものはメンテされていない可能性もあるため、完全に信頼は置けない。
    • ヘッダファイルは基本的に読む。設計指針や専門用語の解説あり
    • ソース中でも以下のコメントは読む
      • 署名がついているもの
      • バグトラックの番号がついているもの。セキュリティホール対応だったりする。
      • 日付が書いてあるもの
    • JVM の抽象クラスの特性
    • メモリ周りのコードに億出てくる略語を押さえる
      • oop, RO, TLAB, BOT...
    • os <- 猫に見える

JVM の OS 抽象化レイヤ


  • memory <- 寝てる猫に見える
  • os.hpp
  • os.cpp
  • os:: を呼び出しているクラスは share/vm/memory にある
  • memory ディレクトリに含まれるクラスの継承関係を図示する。
  • allocation.hpp|cpp 中のクラスが大事そう。

R5-6 [BOF] Over the Node.js. An Introduction to Vert.x

Vert.x の概要


  • Vert.x は JVM 上で動くアプリケーションプラットフォーム。
  • ドキュメントが充実している(vertx.io)
  • Virt.x の作者 timfox は Red Hat で HornetQ とか関わっている。
  • 特徴
    • High Perf.
    • Distributed Event Bus
    • Polyglot
    • Module System
  • High Perf.
    • C10K問題。一般的に1つのスレッドあたり、256kb - 1mb 必要
    • EventLoop でノンブロッキング+非同期処理
      • EventLoop を止めてはいけない。
        • どうしてもブロックしたいときは、WorkerThread を利用する。
    • Java のスレッドを利用するので、デフォルトで CPU 数に応じたスケーリングが可能
      • node.js では、クラスタ機能を使わないとだめ。単体だと 1 CPU での動作になる。
  • Distributed Event Bus
    • JMS みたいな通信(P2P, Pub/Sub)
    • クラスタリングも可能
  • Polyglot
    • JVM 上で扱える様々な言語をサポート
    • Java JS Groovy JRuby Jython が公式でサポート
    • Scala Clojure PHP も開発中
  • Module System
    • node.js でいう npm のような機構
    • モジュールは Maven や Bintray に公開し、共有できる
    • モジュール間は Event Bus を介した疎結合
    • モジュールはいろいろな言語で実装されているが、Event Bus を介しているため、言語の差を意識しないで済む。

Vert.x による開発


  • JDK7 or later(must)
  • Project Template は、gradle を使うのがおすすめ。
  • Auto Reload
  • Remote Debug も可能
  • Node.js and the new web front-end
    • Backend は Virt.x

Vert.x の最新情報


  • Fat Jar(executable jar)
    • Virt.x Core を同梱しているので、実行に Virt.x のインストールが不要。
  • HA
    • HA Group を作る。HornetQ っぽい。
    • QUORUM スプリットブレイン対策
  • DNS / UDP Core API

Netty, Virt.x, Java EE アプリケーションサーバ

  • Netty, Virt.x, Java EE アプリケーションサーバの住み分けは？
    • Netty は低レイヤ向きのアプリケーション向け(ゲートウェイとか)
    • Virt.x は Netty より高レイヤかつ、M2M などのサービスに向いているのでは
      • あくまで LightWight を目指し、Java EE アプリケーションサーバの範囲を全て網羅するような作りにはならないように思える。

参考


R1-7 [BOF] Spring Frameworkの今(2013年版)


  • Spring は生きている。
    • ホストしている会が移り(Pivotal社)、どう扱われるかという意味で未来にはちょっと不安な部分もある。
  • spring.io にメインサイトが変更された。
    • 40 種類のサンプルを用意されている。
  • Spring Boot
    • 複雑化した Spring モジュールを簡単に扱えるようにする。
  • CDI(JSR-330)対応
  • SockJS 対応
    • レガシーブラウザでも利用できる WebSocket
  • STOMP に対応
  • Spring vs Java EE
    • Spring もどんどん JSR に対応していき、Java EE と差がなくなってきた。
    • JTA が使えるのでグローバルトランザクションもできる。
    • 外部 JMS との連携も可能。

その他


  • Tomcat 7.0.47 では JSR 標準の WebSocket API を制限付きで同梱している。
  • JSR356は低レイヤ過ぎる。なんらかのフレームワークが必要。
投稿者 時刻:
ラベル: ,

0 件のコメント:

コメントを投稿

登録: コメントの投稿 (Atom)