Fight the Future

Java言語とJVM、そしてJavaエコシステム全般にまつわること

JJUGクロスコミュニティカンファレンスに行ってきた

基調講演『A Component Model for SOA, Web Services and Web2.0

WebSphereの開発者であるドン・ファーガソンの基調講演。
とりあえず英語。
概要はわかったけど細かい意味は理解できませんでした。


SOAはサービスバス、インターネットは一種のESBという発想になるほど、と。


特に印象に残ったのがこの表。

Web ServiceとWeb2.0はアプローチが逆だということ。
Web Serviceはまずサービスが先にあり、それを利用する画面はあとになる。
一方Web2.0はまず画面が先にあり、サービスはあとから追加する(Atomのフィードとか)。


そしてAtomフィードもWeb Serviceであり、もっともシンプルなものと言える。


RESTやAtomフィードがあるからと言ってWeb Serviceが不要であるわけではなく、
スケールが大きくなるとともに必要になる。
たとえばWSセキュリティなど。
個人的にはトランザクションもかなあとか思ったり。


マッシュアップはコンポジションという考えもなるほどだった。


印象に残った言葉は「Enterprise cannot ignore innovative technology.」。
最高。
エンタープライズシステムは革新的な技術を無視することはできない。
僕らがなぜ学び続けなければならないかという決定的な部分をついてるなーと。


「Programming is moving higher abstraction(e.g. BPEL, XQuery, content management).」
まあそうだよね。でもBPELははやるか疑問。


Java is Enterprise backplane.」
たしかに。このままJavaが主流になり続けるわけでもなければ、まったく消えてなくなるわけでもない。
根幹みたいな感じ?JEEのAPサーバが培ったものは生き続けるってイメージ。

Grails

GrailsRails。まったく別物です。フルスタックってとこが共通。
Railsの表駆動に対してこっちはドメインモデル。
でもDAOとかおかしいよね、ってことでアーキテクチャ上のアスペクトとでもいうような考えになっている。
たとえば永続化は情報構造の定義とは別のアスペクトであるので、動的にその操作を注入するみたいな(注入といってもDIではなくメソッド注入)。


禿同。ドメインモデル自体が永続化機能を持っているのはヘンだと個人的に感じていたし、かといってDAOもどうかと思ってたので。


Grails自体はメタフレームワークであり、SpringやHibernateをつなぎ合わせるグルーである。
ヨーロッパのG2oneという会社のメンバーが中心になって開発している。

JRuby on Rails

天使やカイザーのよういちろうさんだった。
RoRは開発はサクサクだが運用が難しいと(Twitterの不安定さもこれが原因)。
対してJava EEは開発はめんどうだけど運用は豊富なAPサーバの実績あり。
なのでJRuby on Railsって発想。


さらにEJBとも連携できるから分散Txやリモート呼び出しもできる。


デプロイはwarにするらしく、goldspikeってツールを使う。
# JRoRについてはJava Expert#02にめっちゃ詳しく載ってるよ。
サーブレットになるから安心。

Click

これまた、たけぞう(瀕死)さんだった。
とにかく薄いってとこがウリ。
コンポーネント指向だけど、JSFみたいな複雑なモデルではない。イベント駆動。
とにかくドキュメント(英語)が充実している。


結局プロジェクトごとにフレームワークは改変するものだから、
理解しやすく変えやすいフレームワーク(=Click)がイイ!ってこと。


あとClickはServlet APIを隠蔽していない。

Wicket

世界のt_yanoさん。Airだった。


挙手で確認したらWicketを会場のかなりの人がすでに触っていた。
デスクトップアプリケーションの考え方がWebアプリケーションには通用しない今までが変であって、やっぱりオブジェクトは状態を持つものじゃんってこと。
Swingみたいに。


なのでWicketではWebページはすべてオブジェクト。
コンポーネントはデータモデル(Bean)と直接結びついている。なのでモデルの値が変われば表示も変わる。自然だね。


状態を保持するためにセッション(=メモリ)を使うけど、ページやコンポーネントWicketが自動的に解放する。
GCみたいに。
それほどメモリヘビーではないらしい。

エンタープライズアプリケーションに使える言語ScalaとフレームワークLiftのお得なところと使い道

オブ脳の牛尾さん。テンション高い。関西弁。


LiftはScalaのフレームワーク。なんとダウンロードして手順通り実行してもそのままでは動かないらしい。
しかもSubversionからチェックアウトしてMavenする手順しかないらしい。


Scala = 階段でLift = エレベーターね。


View Firstが特徴。
今まではController Firstなフレームワークが主流。
LiftはServletとして動作する。
warにアーカイブする。
フルスタック。


ちなみにScalaは他のJVMで動作するLLより1桁早いのがパフォーマンス上のウリ。
でもHaskellには負ける。

JVMで動く関数型言語(Scala)の可能性

羽生田さん。
相当Scala推してます。


ってか会場に100人くらいいたのに6割くらいの人がScala触ってた。


Scala = OO + 関数型
で静的。


なのでScalaはRubyPerlやなんやに対抗するものではなくて、Javaの後継と目される。
エンタープライズではタイプセーフ最高ってこと。


さらにScalaにはActorっていうライブラリがあって、これはErlangを参考に作った並列処理。
デモもありました。
難しくて全部は理解できませんでした。


さらにSpecというBDDのライブラリを作っているEricさんが登場して英語で講演。
SpecはRSpecなどと同様のBDDライブラリ。
# JavaならJDaveもあるよね。


個人的には、仕事に必要な学習という意味ではJavaの次にScalaをやるのは本当にお勧めだと思う。
今ならまだ言語仕様だけ学べばいい段階だし、関数型を学ぶのもメリットが大きいし。

ITゼネコンをぶっつぶせ

ひがさん。


今回はSeasarの話ではなくて、業界の裏話?
会場とのインタラクションが多かった。


要は上流だけとかプロジェクトマネジメントだけとかのSIerの体質を変えよう!ってこと。
これは無条件に大賛成。


そこでProgramming First Developmet。
この辺の話はひがさんのblogにあったことと同じなので、そっちを見てもらった方がいいと思います。


こんな感じでした。
こういったイベントは刺激を受けるのでいいですね。
でもいつまでも参加するだけの受け身ではなくて、ほんと大阪でも立ち上げていかないとと強く思います。
でも手が回らないとか言い訳しつつ。。。
絶対的に時間が足りない気もします。