JJUGクロスコミュニティカンファレンス2008Springに参加した

各セッションの内容をメモしておく。

参加したセッション

• Click Framework
• Grails
• JRuby on Rails
• Wicket
• パネルディスカッション（Webアプリケーションフレームワーク）

• 教科書に載っていないアジャイルプロセス開発
• ポストJavaは何か？JVMで動く関数型言語Scalaの可能性

Click Framework

※発表資料 http://amateras.sourceforge.jp/resources/ClickFramework.pdf

• コンポーネント指向
• イベント駆動
• シンプルでコンパクトなフレームワーク
• ゆえに開発者にとって理解しやすく、拡張しやすい
• 薄いフレームワークなので高性能（Strutsと同等）
• 理想と現実の妥協点
  • Servlet APIを無理に隠蔽していない
• Click＋S2DaoでのアジャイルWeb開発プロジェクト
  • 期間は3ヶ月
  • 外部設計からテストまで
  • 顧客の仕様が固まっておらず作りながら確定したいというありえない要求
  • 60画面
  • アプリ自体はわりと単純なもの
  • HTMLモックは作らない。Clickでいきなり画面作成
  • 自動レイアウト機能はあまり使えなかった。まずは自動レイアウト機能で作っておいて、顧客の要望に対応できなければHTMLテンプレートを作成
• Clickのビミョーなところ
  • ビューがコントローラを侵食している。Pageクラスがビューを構築するためのコードで埋め尽くされる
  • HTMLモックをつくるようなケースでは向いていない
  • 既存のコンポーネントが微妙に拡張しづらい。（特にJavaScript）
  • 割と保守的（Java1.4ベースで動作するように設計されている）
  • ググラビリティが低い（Clickで検索してもまず引っかからない）

Grails

• Web開発用フルスタック・フレームワーク
  • Spring、Hibernate、…
• メタフレームワーク
  • 様々なJavaフレームワークを組み合わせることが可能
• MVC2
• Grailsによる開発
  • 仕様（モデル）をGroovyのDSLを使って書く
  • 共通部分（アーキテクチャ・アスペクト）を括りだしてプラグインを作る
• Grailsの価値
  • 顧客にとって　…早い段階で動くものを提供すること
  • 開発者にとって…問題領域と技術領域を分離することができる
  • 会社にとって　…プラグインの形で実装技術の資産化
• 技術的な３つのポイント
  • モデル駆動（動く仕様）
  • ドメイン駆動（railsはテーブル駆動）
  • アーキテクチャ上のアスペクト
• メタオブジェクトプロトコル
• 動的な型付け＋静的な型付け

JRuby on Rails

※発表資料　http://www.eisbahn.jp/yoichiro/2008/05/jruby_on_rails.html

• JVM上で動作するRails
• Railsでは運用面での安定稼動がわりと難しいが（負荷分散とか）
• JRuby on RailsではJavaEE上で動作するのでJavaEEの技術をそのまま流用可能。
• でもほとんど実績がないため、本当に運用面でメリットがあるかどうかは不明
• JRuby on Railsならではのメリット
  • EJBとの連携（分散トランザクション構成が可能）
  • CGIではなくServletとして動作するのでスケールしやすい
• JRuby on Railsのデメリット
  • 起動が遅い

Wicket

※発表資料　http://homepage.mac.com/benbrand/files/jjug-spring2008-wicket.pdf

• Webページを生成するためのフレームワーク（Strutsと同じポジション）
• JavaとHTMLだけでアプリを作成する
• Webデザイナとプログラマとの協同
  • デザイナがツールを使って作成したHTMLにWicket用のおまじないを挿入
  • しかしHTMLは壊さないため、同じHTMLファイルをデザイナがツールを使って再編集できる
• 今後Webアプリ開発はステートフルなフレームワークが活用される傾向（JBoss Seamもステートフル）
• ステートフルなオブジェクト指向を実現
  • Sessionはバンバン使う。
• Session管理＝メモリ管理
  • Sessionは悪ではない。むしろ便利
  • Sessionを開放し忘れることが悪
  • Wicketのページコンポーネントは必要がなくなれば自動開放される
• Javaであることを大切にする
  • オブジェクト指向をフル活用
  • 匿名クラスをよく使う。Swingのような感じ。
• 実績は意外と多い
• Wicket in Actionが出る。

パネルセッション（Webアプリケーションフレームワークについて）

• Struts vs Struts以外
• ほとんどのJava開発者はStrutsでの開発を経験
• なんだかんだで結局はStrutsになることが多い
  • 技術的に枯れているから
  • 圧倒的な開発経験者数。技術者を集めやすいから
  • 経営層から見れば、Strutsで確実にできるんならStrutsでいいじゃん
• Strutsが登場したころのWebアプリの世界は、Strutsで十分だった
• Webの進化と共にWebアプリやWebアプリ開発に求められる要素も多くなった
  • EoD
  • テストの容易性
  • Ajax
• もはやStrutsで開発するには時代が遅れすぎているのではないか
• 様々なWebアプリケーションフレームワークの登場、乱立
  • Strutsと同じくビューだけを担当するフレームワーク（JSF、Tapestry、Wicket、Click、など）
  • フルスタックフレームワーク（Rails、Grails、JRails、その他Railsにインスパイヤされたものが多数）
• でもStrutsはStrutsで悪くはない。Webアプリ開発に対する貢献度は非常に大きい
• Webアプリ開発の２つのアプローチ
  1. 成熟したStrutsを用いて今までのように開発する。（Strutsをより使いやすく、SAStruts）
  2. より今のWebの流れに沿ったフレームワークを用いて開発する
• Struts以外を利用する場合には、経営層にとって明らかなメリットが必要
  • 納期、コスト、品質などの面でのメリットが必要
  • エンジニアが幸せになる、ではダメ
• 第2のStrutsとなるWebアプリケーションフレームワークを作るためには開発者数の確保が必須

教科書に載っていないアジャイルプロセス開発

• 特に目新しい内容がなくてちょっと残念
• KPT分析するときは、開発の流れを可視化したタイムラインがあるといろんな意見が出やすい
• 計画ゲームをするときにはトリアージを常に意識する必要がる。
• お客様へは「アジャイル」というキーワードを使わずにアジャイルできるように説明することも必要なことがある。
• 伝えたいメッセージ　「今の開発方法を完璧と思わないこと」

ポストJavaは何か？JVMで動く関数型言語Scalaの可能性

• スクリプト言語というより汎用型プログラミング言語
• 非純粋な関数型言語
• Java⇔Scalaの相互利用が可能

• どうやらかなりマニアックなセッションらしい
• でも、会場は立ち見する人がいるほど盛況（あとのひがやすを氏のセッションに参加する人が多い？）
• 時間都合により、途中退席