JJUG Cross Community Conference

Java

JJUG Cross Community Conference 2008 Spring行ってきました。Webフレームワークのパネルまでの予定だったのですが、時間があったのでというか休みなので、、そのままScalaとひがさんのBOFまで聞いてきてしまいました。

Webフレームワーク関連のセッションとパネルを聞いてのまとめと感想です。

  • Grails
    • Spring,Hibernateなどいろいろなプロダクトを組み合わせてフルスタックを用意している
    • DSL(Domain Specific Languages)という独自のミニ言語を使って設定や各種の記述を行う
    • 拡張性やプラグイン機能が充実している
  • JRuby on Rails
    • Ruby on Railsは実運用のノウハウがあまり蓄積されていないので、開発のフェーズではよいが、運用に入る段で苦労することが多い。
    • JRubyを使うとServletコンテナ上で動かせるので、この点についても既存の資産を活かせる。なるほど。
    • EJBも呼び出せる。
    • やっぱりRailsをちゃんと使ってみた方がよさそうですね。
  • Click Framework
    • フレームワークの中身がシンプルで動作も軽い
    • ドキュメントが充実している（ただし英語）。
    • Googleで情報を探しずらい（確かに。。）。そもそもそんなに情報がないので、ドキュメントとソースを見る方が早い。
    • フォームの自動レイアウト機能があるが細かいデザインには向かない（使えればかなり工数が減らせる）
    • 多くのコンポーネントがあらかじめ用意されている
  • Wicket
    • 手続き型からSwingのようなオブジェクト指向の開発モデルに。
    • 設定もJavaで書く（条件分岐とかも柔軟にできる）
    • 今のWebフレームワークはJavaの機能を使いこなしていない。Wicketでは匿名クラスとかをバリバリ使う（Swingのイベントリスナみたいな）。
    • コンポーネントが状態を持てる。状態とメモリの管理もWicketがやってくれる。
    • メモリの消費もそれほどではない。
    • コードがHTMLを浸食しないのでデザイナとの分業がしやすい
  • パネル
    • clickを使ったことがある人が意外と多い。Grailsは非常に少ない
    • みんながStrutsに足りない機能を独自に付け足しながらStrutsを使い続けている
    • どのフレームワークも決めてにかけていて、今後はいかにユーザーを確保できるかが重要
    • でもStrutsと同じ土俵(MVC?)にのってしまった時点で負けではないか??
    • Strutsを使わない理由を聞かれると、工数や納期の面でのメリットをアピールする

Programming First Developmentの話は、私はSIerで働いていないし受託の案件も数えるほどしかやったことないので、あまり実感持てないのですが、かなりの盛り上がりでした。やっぱり一番楽しいのは動くものを作ることなので（ドキュメントもテストも書くことより）、開発者のモチベーションがすごくアップして好い循環が生まれそうです。