09

Java Day Tokyo 2015

行ってきました。

f:id:carrotsword:20150408094326j:plain

Keynote

前半はJava20周年です、ということで、どれだけJavaが使われているか、どれだけJavaプログラマがいるか、どれだけJavaの世界が広がっているか・・・といった内容の話を中心に、今後のロードマップとまさにIoTみたいなところのデモを幾つかやってた。だいたいすでにどこかで聞いたような話だったり、まあここで突っ込んだ技術的な話も期待してなかったりだったんだけど、ただデモにALDEBARANのPepperが来ていて「Pepperをコントロールするライブラリがあって、Java向けのSDKもあるよ!」というような話をしてたあたりがなかなか面白そうだった。IoTってことでなんかMinimalな感じのデバイスにJava乗っけてやってますよっていうのは正直デモを見た感じでは「まあなんとでもしようはあるだろうなあ」と思ってしまったのでそれほど印象的でもなかったかな。実際どんなコードが動いているのか見れたら違ったかもしれないけど。

後半はコミュニティ活動重要ですよね、というような話でした。Javaの仕様はJCP(Java Community Process) に従ってコミュニティの手によって策定されてきていて、例えば楽天なんかがそれに参加しようとしているという話とかJJUGの代表の方がJJUGっていう大きなコミュニティがあるので参加しましょうねとか、関西Javaエンジニアの会の代表の方はもっと各地でユーザグループと作る活動をして盛り上げていきましょうというような話をそれぞれ話されてたかな。 個人的にはコミュニティカンファレンスに参加してみるようになったのも最近のことで経緯的にコミュニティで修行を積んできたわけではないわけなので、その辺はあまり実感のない感じではあったかな。

#jdt21 JAVA EE 8 - directions and new features

Java EE 8 の仕様として以下を中心とした解説。

  • JSON-B / JSON-P
  • MVC
  • Server-Sent Events
  • HTTP/2
  • Web Sockets
  • あとなんだっけ

JSON-Pの中にJSON-Patchという話があって、JSONオブジェクトに対して部分的に変更したり付け足したりする(まさにpatchのような)操作をJSONでかけるようにするみたい。多分この辺JSON-Pathとか先行の仕様ある気がするけど、どの程度整合しているんだろう。

とはいえ、最近のインフラ周りとかクライアントサイドのReactの動きなんか見ていると、冪等性を保証できない方法論はそれができる方法論にだいたい取って代わられるのではないかと思っているので、なんかもう一回ブレイクスルーあんのかなあという気がしている。

それ以外の話はあまり印象に残っていない。居眠りしてたわけではなかったと思うのだけど、食後でだいぶ集中力が削がれたかな・・・。

#jdt42 Oracle Developer Cloud Service , what can you do ?

Oracle Develoepr Cloud の紹介といった内容でした。 まさにどんなものか聞きたくて参加したのだけど、会場のハッシュタグのツイートでもいまいちな感じのコメントが多かったのと同様、自分としてもただ流行りのツールを組み合わせたというだけで新しいユースケースが生まれたりブレイクスルーがあるわけでも無いように思われた。

まあこれからブラッシュアップしていけば良いとはおもうけど、他のベンダと比べるとちょっと動きが遅いかもなあというのが心配なところ。実際使ってみるとまた違う発見があるかもしれない。

[書籍] Java パフォーマンス

確かこのタイミングで、オライリーのJava パフォーマンス買って監訳者の方にサイン頂きました。

f:id:carrotsword:20150409070444j:plain

最近仕事でパフォーマンスの問題に見舞われて相談を受けることが増えてきた気がするので、職場に神棚を作って祀ろうと思います。

#jdt23 Applied Domain Driven Design Brue prints for Java EE 7

少し前に日本語版のDDDの本が出て若干話題になってたからか、結構聴衆がおおかったですね。

けどタイトルの割に、内容はあまり実践的ではなかったのではないか・・・と思うのだけど、実は最後の方、うとうとしていたきがしてよく分からない。なんかあれ、もう終わりかとおもって若干びっくりした気がするんですけど、分かる人にはわかったのですかね。

#jdt44 脆弱性事例に学ぶセキュアコーディング「SSL/TLS証明書検証」編

SSLの基本的な仕組みの説明から「こーいうコーディングをしてたせいでサーバ証明書の検証が甘くて危険にさらされたよ」という事例をつぶさに紹介してくれてました。

まあ事例集ということで仕方ないかもしれないんだけど、あまり関わりたくないなという印象が強くなってしまった。「仕様的にもともと複雑なために微妙な落とし穴にはまることがが多くて全ての分岐を綿密にテストしないとどこかを踏み外すだけで致命的な脆弱性になるんだなあ」というような感想。

そういえばこのセッションを聞いている間に以下のようなツイートをしたんだけど

証明書検証をしている部分をオーバライドして固定的に許容してしまう(検証をスキップする)ロジックにしてしまってる例が結構あるらしい。

なんか過去にやった気がしてなんだったっけなと思い返していたんだけど、以前SOAP Web Service で作ったアプリの試験をしていた時に、HTTPとHTTPSの両方で試験する必要があって、その時にサーバにオレオレ証明証を使用したためにクライアント(これはテスト用にWSDLからざっくり生成したもの)でサーバ証明書の検証とかやってられっかーということでこれをスキップしようとして、この例ような回避策を取った事があったのだった。

ただなんかこの回避法ってどこかのBlogか何かで読んでやった気がするのだよね(自分が最初からそんなオーバライドしてやれば良いということまで知っていたと思えない)。なので変な拡散の仕方してるのではというのがちょっと気になった。

#jdt25 Reactive Java EE 7 Let Me Count the Ways!

Java EE における Reactive な部分、ということでイベントハンドラとか非同期処理が書けるポイントを順に説明していた(のだと思う)このへん、なんとなくこんな仕様があるということを知っているだけで実際使ったこともないので、ほ〜、と聞いているだけだったんだけど。

個人的にEE における非同期ってどの程度有用なのかちょっとよくわかっていなくて、というのは、夜間にバッチ処理というのはともかく、リクエストにたいして非同期にサーブレットが動くであるとか、コンテキストにたいしてイベントをフックして処理するなどして、サーバサイドの負荷が上がる割にクライアントへの応答は良くなるという方向なんだけど、クライアントの応答が良くなってしまうとクライアントサイドからのアクショントリガーも多くなるであろうと思われるわけで、利用実態としてサーバの負荷がうなぎのぼりになるのでは?という疑念がある。個人的にはクライアントがレスポンシブであることよりもサーバの性能が足りない事案の方が多いので、あまり使いどころがない気がする。まあ実際やったことないからよくわからんしスケールアップなりアウトなりすればいいと言われればまあそう。だし、まあアドホック的にこういう対応が必要になるケースがあって、こういうやり方が用意されているということが重要なのかな。でもだとするとReactive Java EE 7とか言ってしまうのは行き過ぎている気がするけれど。

どういうところでどのくらい使われているものなのか事例聞いてみたい気がする。

そういえば、なんかいい加減アノテーションの記述量多すぎだろというのが気になってきたんだけど、どうなんだろう。手続き的な記述から宣言的な記述に移行しているのだからいいということになのかなあ。

#java20th Java 20周年記念セッション

クイズとLTのハイブリッド進行ということで、クイズもあんなに多いと飽きそうだと思いましたが、以外といけましたね。なんだかあまり聴衆受けを取りに行く人のセッションを取らなかったせいか?(失礼)1日で一番空気があったまってた気がします。 全体がゆるい雰囲気で楽しかったです。

運営・関係者の方々、お疲れ様でした。今後20年も、さらに発展したコミュニティになると良いですね。