Java Day Tokyo2016に行ってきたよ
都合のため、キーノートとナイトセッションは参加できず。
午後の5セッションの感想です。
スライドがアップされたら更新するかも
Introduction to MVC 1.0
Java EE 8に含まれるMVC1.0の概要の説明。
深く突っ込んだ内容はなし。
「MVCとは?」の説明からなので、基本的なところから学べた。
そうは言いつつも、さりげなくViewでFreeMaker使ってるサンプルがスライドに入ってたり。
実装はOzark。
仕様はそれほど難しくなく、JAX-RSを使いこなせてる人ならそのまま使えそうな感じ。
SpringMVC慣れてる人も大丈夫そう。
感想としては、Viewの指定方法が沢山あるのは使う時に迷いそうなのが微妙。
まとめにもあったけど、Java EEにMVCという選択肢が増えるのは良いことであるのは間違いない。
ただ・・・遅すぎない?
EE7に入っていればよかったのに・・・。
Java EE 7 アプリケーションとWebセキュリティ
スーツ姿の裏紙さんセッション。
IPAが公開している、安全なWebサイトの作り方をJava EEでどう実現するかの話。
重要なこと
- 最初からセキュアなコードを書くこと。セキュアじゃないコードをセキュアにするのはコストが高い
- 対策も必要だけど、脆弱なコードをチェックする仕組みも必要
- それぞれの対策は簡単だけど、攻撃がどういう仕組みでどういう理由で対策できるのかを知らないと対策しても不安が残る
- セキュリティに関する資料は一般的に多く出回っているので、普段から勉強しておくのが大事
- ビジネスロジック(モデル)で対応するのは、可読性や保守性に悪影響。なるべくViewやControllerで対応する
各攻撃に対する対策
JSPや低レベルな処理の話もあったけど、面倒なので割愛。JSFを使おう。
XSS
Faceletならデフォルトで対策済。
CSRF
JSFなら対策不要。
ただしViewをステートレスにすると対策が必要になる。
ステートレスとステートフルを使い分けるといい。
SQLインジェクション
JPAの@NamedQueryアノテーションを使う。
em.createQueryはクエリ文字列を受け取るため、SQLインジェクションの脆弱性があるクエリを指定される可能性がある。
CriteriaAPIを使う手もあるが、学習コストが高いのでオススメはしない。
パスのパラメーターチェック
JavaのFileAPIをそのまま使うのではなく、パラメータチェックを行うラップAPIを作成して利用する。
こうすることで、FileAPIで検索して脆弱なところを検出できる。
クリックジャッキング
レスポンスヘッダーに、X-Frame-Optionsをつけることでiframe、frameを禁止できる。
ただし、Ajaxで行うファイルアップロードも潰してしまう可能性があるので、すべて禁止するのではなくSameOrigin指定を推奨する。
OSコマンドインジェクション、バッファーオーバーフロー
割愛。
どちらも普通に作っていれば起こらない。
その他
レスポンスヘッダーに以下の二つをつけるといい。
X-Content-Type-Options:nosniff
IEはコンテントタイプが指定されていないものを自動で判断する。
そのため、悪意のあるコンテンツを解析した際にスクリプトを実行される可能性がある。
このヘッダーをつければ自動解析を無効にできる。Content-Sequrity-Policy 最強のCSRF対策だけど、CSSやイメージを妨げる可能性あり。
すべて禁止ではなく、許容するリソースを指定する。
Java Concurrency A(nother) Peek the Hood
Javaの並行処理に関する話。
わかりやすかったけど、技術的にはかなり深い所。
概要
- Webアプリケーション、GUIはマルチスレッドが普通
- ライブラリを公開する場合も、マルチスレッドで使われることを考慮しよう
というより、シングルスレッドが許されるのは学校の宿題まで
ConcurrentAPIとか使い方を暗記していても仕組みを理解してないのは危険
メモリモデルを正しく理解しよう
マルチスレッドの場合、各スレッドによって実行順の基準が異なる
Javaの場合はHappened-before
Java SE 5まではfinalがイミュータブルではなかった
並列処理ライブラリを利用するときは、なるべく抽象化されているものを使う。具体的な処理を利用すると実行効率が良さそうに思えるが、とても難しく問題も出やすい。
本番と同じ環境でテストすることが大事
本を読むならJava Concurrency in Practiceがおすすめ
実践してわかったJavaマイクロサービス開発
モノリシックなWebアプリケーションをマイクロサービスに変えていった経験の話。
マイクロサービスは技術的な話は多いけど、実践例は少なかったので参考になった。
スライドが丁寧だったので、内容の詳細は省略。
参考になった点
- サービスディスカバリーは必須
- クライアントとサービスを共通のインターフェースにすることで、IF仕様書を作らなくて良くなる
- 多言語化はEurekaとの関係もあり難しい
- サーキットブレーカーは障害が起きたらどうすればいいかまだわからない
- HTTPは同期処理。AMQPは戻り値なしの非同期
- 画面を中心にAPIを考えると、巨大なものになりやすい
- ドメイン分割は大事。ドメインごとにサービスを作るくらいがちょうどいい
Javaエンジニアのためのクラウド時代の過ごし方
これもスライドがとてもいい感じなのでポイントだけ。
決してお酒が回って面倒なわけではない。
考えさせられた点
- 今までは作ることが大変だった。しかし今は作るところは簡単になり、運用面の問題に向かい合えるようになった。
- 良いコードを書くことは大事だけどそれだけじゃダメ
- アジャイル、クラウド、DevOPS、マイクロサービスは、それぞれの組織が取り組んできた結果
- クラウドによって、ハードウェアがソフトウェアとして定義できる
- 自動化、コピーができる
- 非機能要件のテストが書ける
- PaaSは稼働しているミドルウェアを借りるイメージ
- インフラのテストは本番環境でしかできない。そのテストをするのがNetflixのカオスモンキー
- カオスモンキーはランダムにサービスをダウンさせる
- カオスゴリラはAZを丸ごとダウンさせる
- カオスキングコングはリージョン丸ごとダウン
- ダウンの目的は自動で復旧するかの確認。手順書ではなくコード。運用を不要にする。
これからのエンジニア
2つのどちらかにならないといけない
JSUG勉強会 2016年その3.5に行ってきました
イベントページはこちら
JSUG勉強会 2016年その3.5 - Kenny Bastani来日特別講演 - 日本Springユーザ会 | Doorkeeper
SpringBootを中心とした、マイクロサービスについてのセッション。
テーマ自体が難しいことに加えて、QAを含めて通訳なし100%英語というハードコアなセッションでしたが、ためになるお話でした。
最大の敵は開始前のピザとビール・・
セッション概要
開始前の会場アンケート。 SpringBoot使ってる人はたくさん挙手があった。
逆にSpringCloudを使ってる人はほぼいなかった。Apache、Tomcat、MySQLで構成されるモノリシックなアプリケーションから、SOAを経てマイクロサービスになる。
マイクロサービスは、各サービスで共有するShered Cacheとそれぞれのサービスの特性に応じたDBMS等のリソース。
サービスごとにリソースを分けることで、1つのサービスがダウンしても全体はダウンしない。インフラストラクチャもスケールアウトが難しいモノリスな構成から、スケールアウトが容易なコンテナへ。
マイクロサービスはコンテナ単位で依存関係を持つ。 依存関係の解決はServiceDiscoveryがおこなう。SpringBootのMavenダウンロード数は、2015年12月に225万を突破
SpringBootは「フレームワークのためのフレームワーク」
SpringFrameworkがケーキの材料だとしたら、SpringBootは完成したケーキ。 ケーキを作成するキッチンがSpringInitializr。 SpringBootがケーキだとしたら、SpringCloudはケーキが並んだショーケース。
デモ
マイクロサービスで構築したショッピングサイト。
ソースは↓。
何がすごいって、モノリシックな普通のWebアプリケーションにしか見えないくらいサクサク動く
しかも動いているだけじゃなく、メトリクスもキチンと取っている。
「WebAPIを使いまくると遅い」と決めつけるのは間違いだった。ソースはまだあまり見てないけど、サービスの単位は思っていたよりも小さい
ただ、メモリは全体で8.5GBくらい使っているっぽい
モノリシックに比べれば、大きくなりそう
Q&A
QAもほとんど英語。
あまり聞き取れなかった。。。
質問の傾向としては、マイクロサービス構築時のベストプラクティスやガイドラインについて聞いているのが印象に残った。
回答としては、ケース・バイ・ケースと言った感じ?
反省点
やっぱり終わる前にお酒を飲んではいけない。
後半はマッタリしてしまった・・・。英語で質問出来るようにならないとまずいなぁ・・・。
他の人の質問を聞いてて思ったことは、最初に質問内容をバーンと言ってから、細かい事情や背景を説明したほうが良さそう。
詳細を先に話し始めると、説明が難しくてそこで詰まってしまう。
聞いてる方もどこから質問なのか判別が難しくなりそう。今年度(not 今年)は勉強会に行ったらブログを書く。
いじょ!
データのマスキングが気になったので調べてみた
セキュリティの要件を検討中、データのマスキングについて気になったので調べてみた。
具体的なシチュエーションとしてはこんな感じ。
- システム導入先のユーザーと、そのシステムを構築・保守するSIer
- SIerはテストや障害調査等でユーザーの個人情報含むデータ(顧客テーブルとか)が必要
- 従来通りの氏名とか住所をマスキングすることは、個人情報保護法的にOKなのか
法律の解釈についてはあまり詳しくないので、間違っている箇所もあるかもしれないのでご容赦を。
匿名加工情報
個人情報保護法には「匿名加工情報」という言葉の定義があり、以下のように説明されていた。
・特定の個人を識別することができないように個人情報を加工して得られる個人に関する情報であって、当該個人情報を復元することができないようにしたものをいう。
・当該個人情報に含まれる記述等の一部を削除すること(当該一部の記述等を復元することのできる規則性を有しない方法により他の記述等に置き換えることを含む。)。
・当該個人情報に含まれる個人識別符号の全部を削除すること(当該個人識別符号を復元することのできる規則性を有しない方法により他の記述等に置き換えることを含む。)。
「個人識別符号」も定義されている。
・特定の個人の身体の一部の特徴を電子計算機の用に供するために変換した文字、番号、記号その他の符号であって、当該特定の個人を識別することができるもの
・個人に提供される役務の利用若しくは個人に販売される商品の購入に関し割り当てられ、又は個人に発行されるカードその他の書類に記載され、若しくは電磁的方式により記録された文字、番号、記号その他の符号であって、その利用者若しくは購入者又は発行を受ける者ごとに異なるものとなるように割り当てられ、又は記載され、若しくは記録されることにより、特定の利用者若しくは購入者又は発行を受ける者を識別することができるもの
特定の個人の身体の一部の特徴の例としては、顔写真とかが考えられる。
病院のカルテとかなら、病状や治療歴も含まれそう。
2つ目はクレジットカードや銀行口座の番号が該当する。
伝票番号とかは、他のデータと突き合わせれば購入した人がわかる可能性があるけど、この文には「他の情報と照合」という言葉が入っていないので許されるかもしれない。
ここまでのまとめ
- マスキングして個人を特定できなくなったデータは個人情報保護法における「匿名加工情報」になる
- 氏名や顔写真等は当然として、IDも削除しないといけない対象になる可能性がある
ID系についてはこんな感じ。
匿名加工情報の作成
これも法律に書いてあった。
・個人情報取扱事業者は、匿名加工情報(匿名加工情報データベース等を構成するものに限る。以下同じ。)を作成するときは、特定の個人を識別すること及びその作成に用いる個人情報を復元することができないようにするために必要なものとして個人情報保護委員会規則で定める基準に従い、当該個人情報を加工しなければならない。
・個人情報取扱事業者は、匿名加工情報を作成したときは、その作成に用いた個人情報から削除した記述等及び個人識別符号並びに前項の規定により行った加工の方法に関する情報の漏えいを防止するために必要なものとして個人情報保護委員会規則で定める基準に従い、これらの情報の安全管理のための措置を講じなければならない。
・個人情報取扱事業者は、匿名加工情報を作成して当該匿名加工情報を第三者に提供するときは、個人情報保護委員会規則で定めるところにより、あらかじめ、第三者に提供される匿名加工情報に含まれる個人に関する情報の項目及びその提供の方法について公表するとともに、当該第三者に対して、当該提供に係る情報が匿名加工情報である旨を明示しなければならない。
・個人情報取扱事業者は、匿名加工情報を作成したときは、個人情報保護委員会規則で定めるところにより、当該匿名加工情報に含まれる個人に関する情報の項目を公表しなければならない。 ・個人情報取扱事業者は、匿名加工情報を作成して自ら当該匿名加工情報を取り扱うに当たっては、当該匿名加工情報の作成に用いられた個人情報に係る本人を識別するために、当該匿名加工情報を他の情報と照合してはならない。
・個人情報取扱事業者は、匿名加工情報を作成したときは、当該匿名加工情報の安全管理のために必要かつ適切な措置、当該匿名加工情報の作成その他の取扱いに関する苦情の処理その他の当該匿名加工情報の適正な取扱いを確保するために必要な措置を自ら講じ、かつ、当該措置の内容を公表するよう努めなければならない。
公表・・・?
えー、まとめると・・・
- データをマスキングする時は、個人情報保護委員会規則で定める基準も考慮しないといけない
- 加工の方法はバラしちゃだめ
- 第三者に提供するときは公表しないといけない(!?)
『みなさんこんにちわ、○○商社です。今回、わが社の顧客情報管理システムでトラブルが発生しました。つきましてはお客様のデータのうち氏名、住所を秘密にした顧客情報を、委託している××システムに提供します』とかプレスリリースとかに乗せろということ・・・なのか? - そもそも匿名加工情報を作った自体、公表しないといけない(!?)
なんかすごく面倒・・・。
少なくともシステムを開発・運用するSIerとの関係だと、法律通りの運用はされないのでは・・・。
JJUG CCC 2014 Fallに行ってきました
予定があって夕方に切り上げましたけど、今回は非常に内容が濃かったと思います。
とりあえず、参加したセッションの概要のまとめ。
K-1 基調講演1 : これからのJavaエンジニアの生きる道
技術の変化のための技術
クラウド
- コンテナ型の仮想化ソフトDockerにより、クラウドプラットフォーム間の移動が簡単にできるようになると思われる。 ** より安く、サービスが充実した環境へ簡単に変えられる
- Dockerで移動出来るようになったらクラウド事業者はどうなるか データロックインの方向に進むのではないか * データロックイン=データ活用のためのツール、ミドルウェア、ライブラリを充実。利用者が簡単に移動しないようにする。
- 蓄積したデータを人工知能に利用する
時代はDockerっぽい。
データロックインという考え方は面白いかも。
人工知能
- 人工知能に必要なものは認識、意思決定、行動
IBMのWatson。想定するユースケースはコールセンターで想定問答集や回答をサポートなど ** 「ロボットは東大に入れるか」という本が面白そう
今、何故人工知能の話題が多いのか?
** データ、マシンパワーの増大により、認識やデータ解析の制度が向上。意思決定に使えるようになった。人工知能はデータが貯まるほど補正される関数
** 統計で問題をとくことは、理詰めでは説明できない。でも、なんとなくよく当たる。Watsonは、音声認識→質問解析→検索→回答評価のプロセスで回答を導き出す。
質問解析
** 問題からキーワードを抽出する。- 検索 ** キーワードをWebで検索し、回答の候補となる単語を抽出
- 回答評価 ** 回答の候補を更に検索し、質問とマッチしているかを検索
Javaの今後
社会の変化
- 価値にお金を払わない 例えばKickStarter。まだ製品化されていないのにお金を払う。 クオリティーじゃなく心に響く何かにお金を払っている
まとめ
- 企業が人の成長を見られない状況。だからこそコミュニティは重要。
本当に人のつながりは大事だと思う。。。 というより、企業が人のつながりを軽視し過ぎで、コミュニティが特別じゃないというのが正直な思いかも。
私がTDDできないのはどう考えてもお前らが悪い!~エンタープライズJava開発でのTDD適用の勘所~
どうTDDするかについて?
チームの概要
- BackBone.js+Spring MVC+Spring Batch+JPA
テストケース3800ケース クライアント開発部隊とインテグレーター2社で1チーム *** 初めて顔を合わせるメンバーが多い。手探り。 - ペア組んでユニットテストのコーチング。
進め方
- インテグレーションの中で実装とテストが完結していればOK。
** テストがあることのメリットを感じてもらう - フェイルファストしてないユニットテストは、フェイルファストしているテストと比べて信頼性を欠く。
- 自動でないテストを重視する
** ユニットテストから漏れるバグが有ることを知っておく コントローラーとサービスを優先的にテスト テストで100%を目指さない。
再現性がある、独立しているが重要。
*** それがないとCIに乗せられない技術的負債は改善サイクルに含める ** Tryをちゃんとタスク化する
- 今のチームは問題を指摘したら次のスプリントに乗せてくれる。
** チームの信頼感重要
スローテスト
- スローテストによる開発リズムの悪化はプロジェクトの死因
- データベースを使うテストは遅い問題 データベースを使うことが遅いなら、データベースはプロダクトに使えない テスト実行時間より、テストデータのメンテナンスがスローテストの原因 *** エクセルでデータ管理の限界
- データベースのアサートはテーブル全体に行う ** 差分をとってアサート出来るようにDBユニットをカスタマイズ
- データベースマイグレーションはTDDを実施するのに必須
コントローラー層のテスト
- End to Endに近い条件で。
- DIしたオブジェクトをモックにすると、コンテナ内のオブジェクトが汚染される。
** @Afterでモックオブジェクトを取り除く
リグレッションテスト
デプロイの自動化
- ServerSpecでデプロイスプリクトのコードを検証
なぜTDDするのか
- 「もううんざりです。何も改善できません。」問題
- TDDを導入するために必要なのはチームを作ること
スキルの有無、キャリアの長短を人を測る尺度にしない
「新人だから知らないと思うけど」という考え方は間違い ** IT技術者各人の背景を尊重すること重要
Spring Boot + Doma + AngularJSで作るERP(統合基幹業務システム)
プロダクトの歴史
2007年 seasar2、IE6と7をサポート。
- IE8で動かない問題
- 時代遅れ感の出てきたUI
- リッチなWebサイトが増えて顧客の目が肥えてきた
- 他のRESTAPIとの連携
- 改修より作りなおすことを選択
Java EE 6 作成
SpringMVC
Doma2 S2DAOを利用していたので、移行が楽だった SQLをごりごり書きたい派にはおすすめ。
** 依存ライブラリがない点もいいAngular.js bootstrapのみを使用。ライブラリは自分で作成。
JSFより軽快(当社比) ** バージョンアップで後方互換性が保たれない。Spring開発にTerasolnaのガイドラインが役にたった
Angularは業務で使っても大丈夫 動かなくなったらフロントだけ作りなおせばいいという割り切り 当然コストがかかる
一般的なシステムの償却期間は5年 フロントFrameworkの追従の予算が取れるかどうか。
** とれないならJSFのように一度作れば動き続けるものがよいのでは標準だから、流行ってるからじゃなく、きちんと検証して自分たちに合うものを選ぶ
QA
- 3つのアーキテクチャの連携は? ** 認証はそれぞれ独立。連携する部分は少ない。
Java EE の新たな旅立ち : Java EE 8 へ向かって
Java EE8の具体的な内容について
現時点でのSnapshotのため、コードは変わる可能性あり
Java EE 8について
JSONB
- JAXBとおなじ感覚で使える
JSONP
- JSONPointer、JSONPatch、クエリに対するラムダ式を追加予定
JSONPointerは特定の値を参照するための標準(RFC)の構文
JSONPatchもRFCに定義されている
JSONで記述したパッチを利用して更新 ラムダ式用にJSONCollectorクラスを提供
** toJsonArrayのような終端処理が出来る
SSE(サーバセンドイベント)
- HTTP標準。実装をどこでやるかはまだ未定。 ** JAX-RSで対応するのが今のところ有望
ActionベースMVC
http2.0対応
- Request/Responseの多重化、Streamの優先順位付け、ServerPush ** 今のServletAPIでは、Request/Responseの多重化に対応できない
CDIの適用範囲拡大
- JSRは365
- JavaEE以外でも使用できるようになる
これはちょっと嬉しい。
CDIのモジュール化
- 多くの機能が追加されることによる肥大化の回避。
** DIのみ、CDIイベントのみ、フルセットから選択
EJBの教訓かな。
他機能との連携強化
- JMSとの連携 ** MDBの実装が不要に
セキュリティインターセプタ
サンプルコード見た限り、ごちゃごちゃしすぎて使いづらそう。
仕様削減(pruning)
- EJB2.Xのクライアント
まぁ、これはなくなっていいと思う。
JMX
- JSR77にRESTインターフェースを追加
** JMXがサーバ実装に非依存
RESTでアクセスできるのはいいと思うけど、各サーバは独自実装捨てないといけなくなるから対応が大変そう。
セキュリティ
- パスワードエイリアス、ユーザ管理、ユーザマッピング
- パスワードエイリアスの標準化
- ユーザ管理の標準化。アプリケーションサーバ間の互換性 ユーザソース:データの元ネタ。DBとかLDAPとか。 ユーザサービス:追加・変更・削除 ** ユーザInfo:ユーザの情報Bean
Javaエンジニアのためのアーキテクト講座
システム開発の現状
- 「アプリケーションをいかによく作るか」から、「ITサービスをいかに良く運営するか 」への変化
- 静的な仕様から作る→開発
- 動的なフィードバックに基づく活動→運営 ** Web業界が先駆者
- デジタル化 ** テクノロジーが社会に関わる
- 仕様書に従って安全なコードを書けばいい時代は終わる
アーキテクチャの役割
- 価値は利用者の体験によって定義される
** 一度リリースされたら終わりではない - フィードバックに対する持続的な成長
これら全体をデザインするアーキテクチャが必要 ** 家を建てる例
家族がそれぞれ家のパーツを考える。それを形にしてもきちんと整合性が取れたものにならない。
整合性をとり、かつ地震が来ても大丈夫なシステム。
フィードバックを受け続け、継続的に保証する。利用者の動線、時期と作業、それに対応するだけの並行処理、トランザクション増加、負荷を分散させるためのclass分割、作るための要因と手法、KPIとしての評価
必要とされるスキル
- TOGAFの全部が必要
** だけど、全部をやる必要ない。 - 品質モデルとかは知ってないとダメ。
- フレームワークの構成とかを考えるだけなのはアーキテクトじゃない。
設計の進め方
- マイクロサービスアーキテクチャ ** 個々のサービス→データ、ガバナンス、手法も独立
個々のサービスは個々のチームによって開発、運用 ** 責任も各チーム
異なるドメインとして定義
- ユーザによって役割が異なる
ユーザによって利用されるサイクルが違う
* 変化の境界線 - それぞれのサービスごとに利用者とサイクルが異なる。
- ドメインを分割しつつも非機能も考えないといけない。
** ECサイトの例。決済のASPダウンしてるから買わせないはダメ
QA
JJUG ナイトセミナー「WildFly 8 ローンチ記念」行ってきました
久しぶりのJavaEEということで行ってきました。
やっぱりEEはいいですねー。
リンク
DoorKeeper
【東京】JJUG ナイトセミナー 「WildFly 8 ローンチ記念」Red Hat共同開催 - 日本Javaユーザーグループ | Doorkeeper
発表資料はこちら。
What’s new in WildFly 8 ?
wildfly-deck/deck/slides.html at master · arun-gupta/wildfly-deck · GitHub
Undertow
WildFlyについて
What’s new in WildFly 8 ?はJavaEEの有名人、Arun Guptaさんが世界中でやったセッション。
日本でもやる予定だったけど、「日本人がやればいいんじゃね?」ということで今回のセッションが開催されることになったようです。
WildFlyって何?
Java EE 7準拠のアプリケーションサーバです。
昔はJBossASという名前だったけど、JBossから始まるプロダクトが非常に多く、ぐぐらビリティが悪いから名前を変えたそうです。
なお、RedHatが出してる有償サポート版であるJBossEAPは、専門の検索サイトが有るらしいので問題はないそうです。
WildFlyEAPにはならないっぽい。
特徴は早いこと。
デモだと1.5秒で起動しています。
載せてるアプリにもよるけど、TomcatとゴテゴテSpringより起動は早そうです。
また、非常に開発者フレンドリーらしいです。
どこが変わったの?
- サーブレットの部分をTomcatベースのものから高速なWebサーバーのUndertowに変更
- WebSocketを使用することで、使用するポートを5から2に減らした
- ロールを使用したアクセス管理・・・
- 自動パッチ機能
Zipファイルをダウンロードしてアップデートすることが出来ます。
更に元のバージョンに戻すことも可能。
他にもこんな機能が
- JDK8に対応
ただし、まだ対応版はJavaEEのコンパチビリティテストを通っていない
コンパチビリティテストの方がJava8に対応するのを待つらしい - RESTEasy3はJerseyよりも優秀らしい
- Hibernate searchで全文検索出来るようになった
使いどころとしては、不動産の検索とか。デフォルトで入っているのがスモイ。 - デプロイメントごとにセキュリティの設定が変えられる
クラウド環境で使うことを想定しているらしい。 - 元からクラスタリングテクノロジーが強い
- EJB2.1のEntityBean、JAX-RPC、JSR88をバッサリとカット
- クラウド対応
OpenShiftやCloudBeeなど。 - 有償サポートであるEAPのJavaEE7対応版はWildFly9がベースになる。
WildFlyは来年の頭に出る予定なので、EAPは来年の中頃くらい。
楽しみに待ちましょう。
(そのころはJavaEE8の話題で持ちきりな予感もする・・・)
Undertowのお話
Undertowとは?
- Webサーブレットコンテナ。2012/7に初コミットの若いコンテナ。
- パフォーマンスが凄くいい。
- XNIOというライブラリを使用。
- とにかく軽い。ヒープに展開しても10MBくらい。
- JBoss7まではTomcatの強化版。
強化版はパフォーマンス向上、クラスタリングの独自実装。
Struts祭りで被害なし。 - そんな強化猫から乗り換えた理由は、Webの発展についていくのが難しくなったから。
特徴
- ワーカー、リスナー、ハンドラーから構成。
- Requestを受け付けるとハンドラを呼ぶ。
ハンドラを小さい処理を記述し、それをチェーンしていく方式。
サーブレットフィルターみたいなイメージかも - Wildflyで動くときはハンドラーを自動で登録してくれる。
その他
まとめ
GlassFishと比べて勢いがある印象。
やっぱり有償サポートが控えてるっていうのが強みな気がする。
Undertowは単体で使うのはちょっと難しそうですけど、WildFlyに組み込まれている分には問題なさそう。
Tomcat以外の選択肢が増えるのはとてもいいことだと思います。
JSFさんの空気っぷり・・・。
JavaDayTokyo2014に行ってきた
去る5月22日に行われたJavaDayTokyoに行ってきました。
去年の秋葉原に引き続き、2年連続の参加です。
参加して思ったことを書き連ねてみます。
日本Oracleの本気度アップ
秋葉原UDXから品川プリンスに変更になり、会場に余裕が出来ました。
去年はすし詰め状態だった基調講演もゆったり聞くことが出来ました。
椅子も柔らかく座り心地もよいものが用意され、腰痛持ちの自分でも安心して参加出来ました。
さらに待望のJavaSE8日本語ドキュメントのリリースも発表。
SE7の日本語ドキュメントが去年のJavaDayTokyoだった気がするので、それに比べれば非常に早いリリースだと思います。
これがきっかけで、日本でもJava8が一気に浸透していくのではないでしょうか。(願望)
IoT重点の基調講演
基調講演の50%以上はIoT関連のものでした。
驚いたことに、本家JavaOneの基調講演で登場したDukePadやチェスロボットが登場したこと。
Oracleが日本の市場を重視していることが伺えます。
わざわざアメリカに行かなくても日本でOK、ではなくいつかは本家でお披露目の瞬間でみたいです。
マインドストームのDukeも登場し、会場はとても盛り上がっていました。
日本からもNECのパペロが参戦し、流暢なお喋りを披露してくれました。
MindstormやRaspberry Piのような小さなデバイスでほぼJavaSEのコードが動くことは、開発者が今まで持っているスキルでできることを広げてくれる夢のある話です。
だってこちらが何もしなくても出来ることが広がっていくんんですよ?
Lambdaをマスターしているうちに、ロボットも動かせるようになるなんてすごい時代になったものだと思います。
端末の性能も向上していけば、できることはさらに増えていくのではないでしょうか。
その反面EEは・・・
『C-1 Java SE 8時代のJava EE 7アプリケーション開発』では、MindstormとJava EE7を組み合わせたデモが披露されました。
ブラウザとGlassfishはWebSocketで接続、GlassfishとMindstormの間もWebsocketで接続し、JavaSEとJavaEEだけでもブラウザからリモートコントロールするアプリを作れることを示してくれました。
今後、エンタープライズなWebアプリしか作ったことがない人でも、IoTを使いこなせる様になるというのは開発者にとって嬉しい事です。
ここまで出来るようになっているにも関わらず、JavaEE7準拠のアプリケーションサーバーが遅れていることが非常にもったいない。
Glassfishは有償サポートがなくなった上、4.0.1が今年のJavaOneにようやくリリース(できればいいなぁ)という状況。
WebLogicは今年中は厳しい。
WASが辛うじて今年間に合いそう?
日本のベンダーはどうなってる?
こんな状況だと、せっかくのいいものが個人で楽しんだり教育での使用にとどまってしまいます。
Javaユーザーが多いエンタープライズな方面でも使えるようになってほしいです。
IoTの端末部分がいろいろ進化しても、肝心のクラウドで使うものが遅れてちゃあ・・・。 Oracleさんもそこんとこわかっているとは思いますので、今年のJavaOneでの巻き返しに期待です。
とにかくLambdaだ!
あとはJavaSE8と言うよりLambda祭り。
Lambdaは難しそうに見えても文法の仕組みを知ってしまえば書くのは簡単。
でも奥が深くて使いこなすのは難しい。
そして、使いこなせれば強力な武器になる魅力的な機能です。
Lambdaについては使いこんで慣れることが肝心だと思います。
Lambda100%セッションとしてはA-4を聞きましたが、イキナリ聞いただけではほとんど理解できないんじゃないかなと思います。
A-2の続きだったようですが、Lambda知識0でA-2→A-4と聞いてついてこれた人はなかなか少ないのではないかと。
初めてのLambdaとか入門Lambdaというイベントは、今年一杯で終わりそうな気もするので、なるべく早いうちにJava8に慣れておくことが重要です。
あとは、日本語APIリファレンスが出たので、StreamAPIはちゃんと読んでおこうと思います。
注釈に重要な情報が大量に書いてありました。
特にparallel使って見るときは読む必要があります。
その他もろもろ
コミュニティ寄りの人もスーツな人もどちらも楽しめるバランスになっている良いイベントだったと思います。
IoT関連の展示も面白く、Raspberry Pi、Mindstormのいずれも完売する人気っぷり。
Mindstormは欲しかったけど、10万ドル、ぽんっと出してくれるほどお財布さんが優しくなかったので泣く泣く諦めました。
ゴールデンウィークの月に行うのが悪いと思います。
それでも重箱の隅をつつくように注文をつけるのであれば、遠路はるばるお越しいただいた人向けに荷物の預かり所(もしくはその案内)があったほうがいいとは思います。
荷物が多いとかさばりますし、セッション聞くのも大変です。
あの人混みでキャリーバックを引いてる人がいて、案の定轢かれました。。。
forループ殺すべし。慈悲はない。
うん。言ってみたかっただけなんだ。
JJUG CCC 2014春に行ってきました。
基調講演の『foreach書いたら負け!for禁止!』という言葉のインパクトが強すぎです。
その後のセッションのデモでforが出てくるとツッコミが入っていたくらいです。
とりあえず、マケグミ・サラリマンにならないようにforを潰す練習をしてみました。
一時変数を使ったループの置き換え
一時変数を使ったループはこんな感じで置き換えればよさそうです。
for (int i = 0; i < 100; i++) {
// 何か処理をする!
}
これをLambdaにしてみるとこんな感じ。
IntStream.range(0, 100).forEach(i -> ここに処理を書く!);
1行で書けるのが素晴らし。
条件に適合したらループを抜けるケース
いきなり自信なくなります。
動いているのは確認してますけど、もっと良いやり方があるとかもしれないので・・・。
例としてはListを先頭から検索していき、条件に該当するものが見つかったらループを抜けるケースです。
for (int i = 0; i < 100; i++) {
if (condition) {
// 何か処理をする!
break;
}
}
forの方はだんだんウザくなってきました。
これをLambdaで書いてみると、こんな感じになります。
IntStream.range(1, 100).filter(i -> condition).findFirst().ifPresent(i -> 処理を書こう);
filterメソッドで条件を指定し、findFirstメソッドで条件に一致する最初の値に対して処理をおこないます。
条件に該当する数値がない場合は、処理が呼び出されません。
例外じゃないです。
Lambdaにすると読みやすくなったといえます。
それに加え、先頭から要素を探す残念処理を簡単にパラレルで実行できたりもシマス。
IntStream.range(1, 100000).parallel().filter(i -> condition).以下略
途中にparallelメソッドを挟むことで処理が並列で行われるので、条件に一致するものを見つけるまでの時間が早くなります。
決められた件数だけを処理するパターン
リストの最後に到達するか一定の件数を超えたら処理を終了するパターンです。
for文で書くとこんな感じ。
int count = 0;
for (int i = 0; i < 100; i++) {
if (condition) {
// 何か処理をする!
count++;
if (count == 10) {
// 10件処理したら終わる
break;
}
}
}
うんざりするようなソースですが、Lambdaならこんなに簡単に書けます。
IntStream.range(1, 100).filter(i -> condition).limit(10).forEach(処理をする!);
limitは上限を設定するメソッドで、条件に該当する要素に対して10件処理をしたら終了になります。
forでやっている時のような一時変数でカウントする必要がないのでスッキリします。
こちらも処理がスレッドセーフなら、parallelにして処理時間を短縮することが出来ると思います。
今日やったことまとめ
一時変数forループもLambdaにすると可読性も上がっていい感じ。
IntStreamには今回使ったfindFirstやlimitだけじゃなく、distinctとかmaxといったフィルタリングするのに便利なメソッドが多いので複雑なループでも大丈夫。
Lambdaこわいにならないように準備しておくのが肝心だと思います。
あとは、Java8を仕事で使う政治的根回しをすることも重要です・・・。
なんで、来月から始まるJava開発がJava6なんですかね、某大手ベンダー=サン・・・