JJUG Cross Community Conference 2008 Springにいってきたよ

JJUG

あんまりまとめる元気もないから、とりあえずメモ書きをそのまま貼付けるよ。

Grails - 山田 正樹 (メタボリックス)

Jruby on Rails - 田中 洋一郎 (ATL システムズ)

  • RoRのはやりの要因の一つはTestフレームワークの仕組みの充実
  • RoRは開発さくさくだが運用するとなると突然敷居が高くなる
    • twitterが安定してないのはこのせい
    • 情報、前例が少ない
  • 一方Javaでは運用面が充実している
    • だがJavaの生産性は頭打ち!!!
    • ここでJruby!!!!
  • ActiveRecord-JDBC
    • Railsで書いているんだけど、JDBC経由でアクセスできる
  • JRubyは運用が簡単。だかがJavaAPのノウハウが生かされるということであってJ2EEコンテナの知識は凄い要求される。

Click Framework - 竹添 直樹 (NTT データ先端技術)

  • フレームワークを作る人はドキュメントを作るのが嫌いな人が多いが、Malcolm Edger氏は逆で、異常に書く
  • clickは理想と妥協がいいバランス。servletを使おうと思えばがんがん使えるし,struts的に書こうと思えば書くことも出来る
  • 日本語対応はほぼOK。ただし新しい機能はあやしい。が正式リリースのときは問題ない
  • コンポーネントは結構豊富。Ajaxはあとからとってつけたようなもん(?)
  • IDEもあるよ。本家で開発しているので結構ちゃんとしている
  • 仕様変更が多発する為に、なるべくコード量をへらす。
    • publicフィールド全開!!。IDEが自動生成してくるとはいえ、JavaDocの記述とか、フィールド名の変更時などそれなりのコストがかかる。
    • コード保管がめんどいという意見もあり。getと書けばプロパティ一覧がでるし。
  • 微妙なところ
    • フォームの構築するコードがページクラス側に出現
    • HTMLでモックを作るようなケースには向いていない
    • Java5対応は来年以降(開発者が保守的らしい)
    • ググラビリティが低い
      • ググるよりドキュメントとソースを読んだ方が早いかも...

Wicket - 矢野 勉 (Wicket-ja)

パネル - 山田 正樹 (メタボリックス) 田中 洋一郎 (ATL システムズ) 竹添 直樹 (NTT データ先端技術) 矢野 勉 (Wicket-ja)

  • Grailsのほれこんだところ
    • オブジェクト指向を取り戻せる
    • オブジェクと指向の先にあるアスペクトという部分。
    • 産業構造を変えられるんじゃないか。ソリューション、開発、がわけられるんじゃないのか？と思えた。
  • Ruby on Railsに惚れ込んだのは
    • Javaはフレームワークが乱立して、案件ごとに選ぶのがめんどくさくなってきた(エンジニアとして腐った意見ですが(ry
    • Ruby on Railsは最適解の集合なのでは。あとさくさく開発。Seaser2も一緒。
  • Click Freamworkに惚れ込んだのは
    • JSF、タペストリーも試したけど複雑だった。ClickFreamworkはシンプル。Freamworkの中身も。
  • Wicketのフレームワークにほれこんだのは
    • JavaとHTMLで全部かけること。HTMLが生だということが最初んところ。
    • インナークラスとかStrutsのときには使われなくなってきた。でもWicketは本来のJavaのオブジェクト指向を取り戻すというところで魅力的。
  • Strutsアンチいけん
    • Strutsはそこまで悪くはないと思ってない。否定されるものではない。ただ、Strutsをそのまま使って使えない。手を入れながら。育てていく為のフレームワークとしては機能がなさ過ぎたのではないか
    • Strutsの登場時にはそれで十分な機能だった
  • Strutsに現在足りない機能は
    • たりないからWebフレームワークが乱立してしまった。O/Rマッパの部分はわりとしぼられている。そのStrutsに足りない部分をうすーくラップしたのがSAStrutsです。
  • サポートからの比較
    • フルスタックは重要。Sturtsは足りないものが多くて、他のフレームワークと組み合わせ、その組み合わせのベストプラクティスを探す歴史でもあった。そのベストプラクティスとまとめたのがフルスタックであり。GrailsでありRailsです。
  • プロジェクトでフレームワークを選ぶとき
    • 現実解として、イレギュラーなもんに対応できるごりごり書ける仕組みが必要。その点Strutsはできる。逃げ道のあるフレームワーク。
    • 世の中にWebアプリケーションの製造モデルが確立されてしまっていて、じゃあStrutsでいいじゃんという話になる。
    • プログラミングモデルでSturtsと比較すると対抗できない。
    • 安く出来ます。短く出来ますがというくらいしかお客さんへのうりでしかでてこない。
  • 言語が違えばフレームワークの作り方も変わってくる。なので言語が違うフレームワークを追いかけても意味がない。例えばJavaでRailsを追いかけても意味はなくて、RailsはRubyだから出来たもの。
  • 運用/実績
    • jrubyは実績なし。rubyをjavaでラップすることになるので、RoRを生で動かすよりは遅いというか超えられない。
    • Grailsは実績はあるがあるが、ノウハウとして外に出てきてない。基本はJEEと一緒。足りないのは事実。
    • Wicketは覆っているよりヘビーじゃないよ。Memoryを吐き出す仕組みもあるし。

lift - 牛尾 剛 (豆蔵)

  • 実行速度はjavaとほぼ同じか。気持ち遅いぐらい。
  • Ruby on Railsを実運用で安心する為にはたくさんテストを書かなければいけない。その結果、結局Javaで書くのと大してコード量がかわらなくなった。んでliftを作った
  • Scalaはエンタープライズ向けにもいける。型チェックとかも良い例。
  • liftはRoRに似たものといううわさがあるが、全然別もの。アーキテクチャもかなり異なる。
  • まだまだアーリーアルファなので、svnから落としてきてすぐ動くって感じじゃない。いまさわればTopLifterになれるよ!!

てことでおれもTopLifterになったよ!!

ITゼネコンをぶっ壊せ - ひがやすお

わたしがとやかくいうよりひがさんのblogを見ていただいた方が良いかな。
http://d.hatena.ne.jp/higayasuo/20080501/1209636051
http://d.hatena.ne.jp/higayasuo/20080418/1208485137
内容は、正直自分の心がいたくなる感じでした。なんでかって？まぁ、そいうことです。やっぱり内製回帰しなきゃいけないんだろうな。
あとオフショアの話が結構もりあがってました。面白かったのは、会場の7割ぐらいがオフショア経験をしているのに、オフショアで成功していると言う人は1%ぐらい。話を聞くと、やっぱり教育をしっかりやっているとのこと。でも50人ぐらい雇う規模じゃないと元は取れないとか。でも、それを超えれば、教育コストを含めても俄然安いとのこと。

そんなこんなで凄い勉強になりました。

懇親会は別エントリーにて

追記

みなさまの、資料をまとめておきます。(見つかったものだけ)