ぱと隊長日誌

ブログ運用もエンジニアとしての生き方も模索中

JJUG CCC 2013 Spring レポート

はじめに

JJUG CCC 2013 Springに参加させていただきました。
JJUG CCC 2013 Spring – セッション | 日本Javaユーザーグループ

参加したセッションのメモを公開いたします。
登壇者の方が資料には記載せず口頭でお話しされたことを中心にメモしています。そのため、資料無しでは意味の伝わらない個所もあるかと思います。どうかご了承ください。
また、一部はセッション後に直接質問させていただいた内容も含めています。

もし内容に間違いや問題などありましたら、Twitter(@pato_taityo)、コメント、MessageLeaf等でご指摘いただければ幸いです。

基調講演-1 Javaのこれからを考える(鈴木雄介

技術的な変化

バイス

今回の講演会場を見てもノートPC以外にタブレットや大きめのスマホが目立つようになった。
サイネージはWindows OSで動いているものが多い。特殊な仕組みを利用しているわけではない。
レスポンシブWebがこれからの主流になると言われている。
これからのデザイナーにはどういうデバイスにどう見せるかという力量が求められている。

仮想化

クラウドの種類が以下の4種類に分化されつつある。

この4種類がこれ以上集約されることはなく、それぞれで発展していくだろう。
対して、XaaS(PaaSなど)はさらに細分化されていくだろう。
クラウドOSのメリットは物理に制約されないこと。載せ替えが楽。
今は各社が仮想化でしのぎを競っており、まだこれを選べば将来も安心と言えるものはない。ただ仮想化自体は主流になっていくだろう。
これからはインフラ(ネットワーク構成も含め)がソフトウェア化し、抽象化していく。

ハードウェア

GPUはCPUに比べまだまだ特殊で、一般に採用されるのはまだ先かも。それでも金融の分野などでは採用が始まっている。
データセンターでのSSDの採用が進んでいる。ハードディスクとメモリのアクセススピードのギャップをこれまではキャッシュメモリで埋めていたが、SSDが埋めてくれる。
インメモリの世界は今のところ商用製品がメイン。これからはOSSが出てくるだろう。

アーキテクチャ

スケールアウトが正義とは限らない。スケールアップも正義となりうる。
どこのサーバーにシステムがあるかというのは気にならなくなる。本当のSOAが始まる。

ユーザとIT

クライアントtoサーバからデバイスtoサービスへ。サービスがどのサーバにあるかは重要ではない。
小売業会ではオムニチャネルが主流となる。チャネルという概念自体がなくなる。実店舗とネット店舗の境目が無くなる。実店舗とネット店舗の情報を完全に共有し、活用する。
⇒例えば、購買履歴からのリコメンド。
オムニになると変化要素が増える。その変化による相互作用を考慮し続けなけばいけない(大変!)。
変化に適応するため、アーキテクチャから考えていかないといけない。イベント駆動の難しさはイベントが積み上がった時の振る舞いの規定が難しいこと。

これからのシステム開発

作りたいシステムに対しどういう技術を適用するか、という選択が重要になっていく。

これから求められるシステム

これからは日常生活にWebが入り込んで行く。それは目に見えないかもしれない。
⇒例えば、センサー技術とビッグデータの組み合わせ。

新しいシステム開発のカタチ

ユーザーのフィードバックの積極的な活用と反映。ユーザーの反応が悪ければ即改修を求められる。
⇒その結果として起こるのが細切れなリリースと並行開発。
これはWebの世界では当たり前だったが、エンタープライズの分野でもその流れがくる。

サステイナブルSI

変化に対応というより変化を感知する。

直近のトピックス

UXはまだまだ発展途上。
リーン・スタートアップの勉強にリーン・キャンバスから始めるといいかも。

Javaのこれから

Java 9は2015年頃?
補足:最近の記事によるとJava 8リリース延期によりJava 9は2016年初めになる見込みとのこと。
Java 8のリリースが延期,いまだ続くセキュリティ問題のために2014年まで
Oracleはユーザの声を聞くことに真剣。驚きは少なくなったかもしれないが、反面としてJavaOneで発表したことがいつの間にか無くなった、ということは減りそう。

H-1 Java EE 6 から Java EE 7 に向かって(寺田 佳央)

Java EE 7に対する寺田さんの感想

(補足:始まる前にちょっと時間があり、そこで寺田さんが話された内容です)
Java EE 7は新機能+既存機能の改良。既存機能は利用が簡単になっている。Java EE 5/6を使っている方はJava EE 7との差分さえ押さえれば簡単に移行できる。

Java EEの歴史

Java EE 1.4は使いづらいという意見が多かった。そこで、OSS開発者の意見を取り入れてJava EE 5ができた。Java EE 5の荒削りな部分を仕上げたのがJava EE 6。
OracleによるSunの買収が決まって買収完了まで時間が出来たことをきっかけに、寺田さんのブログなどでJava EE 6の情報を積極的に発信するようになった。でもその頃はほとんど注目されていなかった(Strutsで十分との意見も)。

拡張性

Java EE 6はWeb Fragmentで外部フレームワークの設定が容易になった。
参考:
Servlet 3.0 web-fragment.xml による設定 | 寺田 佳央 - Yoshio Terada

プロファイル

Java EEのサブセットを提供。
今はWeb Profileだけ提供しているが、仕組みとしては他のプロファイルを提供することも可能。
プロファイルの概念はJava SEにも取り込まれた。

Pruning(仕様の削減)

2段階プロセスで行う。
Java EE 6でこの先に廃止する仕様をアナウンスし、Java EE 7で仕様から削除する。
Java EE 7以降も実装を残すかもしれないが保証はされない。

EJBコンテナ

Java SEにEJBコンテナを組み込むことができる。
これによりJUnitでの単体テストがやりやすくなった。

プロファイル

Web Profileを使えば目茶苦茶早く起動する。
Java EE 6のフル・スペック版を使って遅いと感じている方がいて、もったいない!

Java EE 5以降の設定

デフォルト設定値があるので、必要なとこだけアノテーションで上書きすれば良い。

Java EE 7

Java EE 7はJava EE 6がベース。なので差分だけおさえれば移行が楽。

Java API for Processing JSON

昨年夏からいくつか仕様の変更があった。

Streaming API

パーサーからイベントを取得する。そのイベント毎の振る舞いを実装する。
資料では説明が抜けているが、途中の波括弧もSTART_OBJECT, END_OBJECTになる。

Object Model API

見た目面倒だし実際面倒だけど、IDEの補完を使えばまあまあ使える。

Expression Langage 3.0

ELの書式が大幅に変更される。
LINQ式はコレクションに対して使える。.NETとは異なり、データベースに対しては使えない。
LINQ式の使用例:
データベースから取得したデータをコレクションに格納しておく。そのデータに対してLINQで操作すれば、データベースに再度クエリを投げる必要がない。
EL式の中でセミコロンが書けるようになった。
⇒やりすぎるとviewの可読性が落ちかねないのでそこは注意。

H-2 Project Lambda Essential(櫻庭 祐一)

Lambdaの目的はクロージャの導入では無い。
パラレルコンピューティングを簡単にするため。
Lambda式よりパラレルコンピューティングのAPIの方が重要!

処理効率をあげるためにタスクの粒度をより細かくしたい。

Iteratorを並列化するのは昔からの定番。
JavaIteratorはExternal Iterators。
⇒ループ外のインスタンス変数などを介して、他の並列処理に影響しないことを保証しにくい。
スクリプト言語によくあるforeachはInternal Iterators。
⇒これなら並列化しやすい。

JavaでもInternal Iteratorsで記述できるようにLambda式を導入した。

実装しないといけないメソッドが1つのインタフェースをfunctional interfaceと呼ぶ。
Comparatorはfunctional interface。equalsはObjectクラスで実装されており、実装の必要なメソッドは1つなため。

Iterable#forEach
ローカル変数は参照できない。final宣言したローカル変数のみ参照できる。この制限は無名クラス由来のもの。

Stream
終端が定義されていないコレクション。
対してListは終端が定義されているのでサイズが取得できる。

Lambda式が表す無名クラスは動的に生成される。よってclassファイルが生成されない。メモリ上で生成され、Dynamic Invocationで実行される。

Lambda式はFunctional Interfaceのシンタックスシュガー。無名クラスを実装する手間を省くために導入された。

補足:
資料無しだとメモのつながりが見えないと思います。。すいません。
櫻庭さんの以前のエントリに今回の講演内容と重なるものがありましたので、そちらのリンクをご紹介します。
Java in the Box Annex: Project Lambda

H-3 ニコニコAndroid開発 – アプリ・サーバサイド両面から見た開発事情(松本 明浩/間島 大智)

アプリサイド

複数端末でデバッグを行うことにより、1機種だけ動かない問題を見つけるだけでなく、1機種だけ動いてしまう問題を見つけることにもつながる。
⇒後者のバグを残したままリリースした日には最悪なことに。。

コードレビューで全員がOKしないとマージされない。

アプリのアップデートはなるべく間を空ける。
⇒頻繁にアップデートを行うとユーザーにダウンロードの負担を強いることになり、クレームにつながるため。

サーバーサイド

(資料でほぼ網羅されていたので省略しました)

H-4 失敗から学ぶAPI設計(山本 裕介)

補足:ここでのユーザーとはTwitter4Jのユーザーという意味です。

ユーザーが少なくてもコミュニティが活発なら不安感を払拭できる。

バージョン2.0からDOMオブジェクトを保持しないことでメモリ使用量を削減した。

インタフェースを知らないユーザーもいる。そうしたユーザーも使えるようにインタフェースはなるべく導入しないようにしている。

原則としてユーザーにクラス継承をさせない。メソッドをオーバーライドすることで他のメソッドに影響してしまうことを防ぐ。
ユーザーがモックテストで必要となるクラスのみ継承を許している。その場合でもモックテスト目的以外での継承を意図していない旨をコメントに記述している。

デザインパターンを知らないユーザのため、積極的にはデザインパターンを導入していない。

補完が効かないように非推奨のクラスはzで始めている。補完リストの最後に出ることを狙っている。

Twitter APIの挙動が急に変わったり元に戻ったり。なるべくTwitter4Jでカバーするが、無理な時はそのままレスポンスすることもある。ユーザーから問い合わせがあった時はその旨説明する。

直列化形式の互換性の確認はユーザー任せ。真面目にやるとテストケースが爆発するため。

互換性を損なう改修はメジャーバージョンアップのタイミングで行う。
この対象となるAPIにはマイナーバージョンアップで@deprecatedをつけておく。Webサイトでも気をつけるべき点として明記する。

パッケージ再編は直列化の互換性維持のため見送っている。でもいつかやるかも。

テストコードはドキュメントの補足となることも意図している。

ログの出し方を工夫しており、ログの内容を検索するだけで問題が見当つくようにしている。
例えば、以下のような情報を出している。

質問:ソースコード全体を把握している?
全部は無理。必要に応じて見返す。自身が見返すためにも可読性に気をつけている。

質問:レスポンススキーマの変更をどう検知しているのか?
テストケースに含めている。要素が増えたり減ったりしていないかをチェック。値までは見ていない。

R5-6 [BOF] Facebook4Jで近づくJavaFacebook Graph API(山下 竜司)

RestFBはOAuthに対応していない。インターフェースもしっくりこない。
⇒Twitter4Jに慣れすぎたからかも。。

この@yusukeさんにFacebook4Jをリクエストするtweetが出た頃、Facebook4Jは8割方できてた。


先のtweetを受けて着々と準備を進める(?)@yusukeさん。
⇒このままだと@yusukeさんが作りかねない!ということで、慌ててドメインとって数週間後に公開。
Facebook4J - A Java library for the Facebook Graph API

Facebook4JのインターフェースはTwitter4Jに影響を受けており、それに合わせて設計することにした。

RestFBだとメソッドのパラメータ指定が文字列だったりして、タイプミスで動かなかったりする。Facebook4Jはメソッド毎に切り分けている。

Facebook4Jの公式ページにはエンドポイントとメソッドの対応表を用意している。
サポートAPI | Facebook4J - A most easily usable Facebook API wrapper in Java

シングルサインオン(公式クライアントでログイン済みならFacebook4Jでもログイン済みとする)をAndroidSDK無しで実現してみたい。

xx4Jを作るのは(Javaプログラマーな)男のロマンだ!

Facebook4Jは10ヶ月ぐらいでファーストリリースした。

公式サイトはjekyllで作っている。
ソースコードを公開しています。
GitHub - facebook4j/facebook4j.github.io: Facebook4J Web Site

Breaking Changesには随時バージョンアップして対応。まだユーザー数が少ないのでBreaking Changes移行期間中の互換性維持はあまり考慮していないが、これからユーザーが増えたら考えないといけない。

Facebook APIは急にレスポンスを変更されることがあって大変。

更新情報

2013/12/01:
・『H-2 Project Lambda Essential(櫻庭 祐一)』の資料を追加
・『H-3 ニコニコAndroid開発 – アプリ・サーバサイド両面から見た開発事情(松本 明浩/間島 大智)』の資料を追加