とりあえずは、ブックマークとスターぐらいしか使ってないけど、そのうちダイアリーとかも使おうかなー。

ってか、livedoorクリップとはてブのクロスポスト用にTombloo使い出したんだけど、めっちゃ便利だね、これ。
もっと早くから使っとけばよかったー。

SupportedDBProvider provider = SupportedDBProvider.getProviderForURI(uri);
if (provider == null) {
	throw new RuntimeException("Unable to locate a valid database provider for URI: " + uri);
}

このエントリに対し、僕はLDCで「SupoprtedDBProvider自体も書き換えたような記憶が」って書きました。

気になったので、もっかい見なおしてみたら、そんなこともする必要なくて、

new EntityManager(H2DatabaseProvider.getInstance("jdbc:h2:file:hogehoge", "sa", ""))

new EntityManager(new H2DatabaseProvider("jdbc:h2:file:hogehoge", "sa", ""))

どういうことかというと、DatabaseProvider#getInstanceは、上で引用してる部分で、サポートしてるDBかどうかチェックしたあとにSupportedDBProvider#createInstanceを呼んでるんだけど、こいつが実際に使用しようとしてるDatabaseProviderをインスタンス化してる。

 
Constructor constructor = type.getDeclaredConstructor(new Class[] {
    java/lang/String, java/lang/String, java/lang/String
});
constructor.setAccessible(true);
back = (DatabaseProvider)constructor.newInstance(new Object[] {
    uri, username, password
});

というわけで、

new EntityManager(new H2DatabaseProvider("jdbc:h2:file:hogehoge", "sa", ""))

ってか、H2使うなら、ActiveObjectsよりもJaQu(H2に付属のORM)使うほうが楽しいと思うけどねー。

GlassFish Gemを使って、GlassFish v3にdeployするのは超簡単。
JRubyをinstallして、パスとか通したりしたら、 jruby -S gem install rails で、JRuby用のRailsをinstall。ちなみにRubyGemsは最初から入ってる。 jruby -S rails demo で、Railsアプリの雛形作成。 jruby -S gem install glassfish で、GlassFish Gemのinstall。 jruby -S glassfish_rails demo で、GlassFishを起動できる。んだけど、注意点が一つ。
WEBRickなりMongrelなりを起動するときは、作成したRailsアプリのディレクトリ(この場合demo)の中で、 ruby script/server ってやってたけど、glassfish_railsコマンドはdemoの一個上のディレクトリで実行する。
そうすれば、http://localhost:3000/で、例のRailsのスタートページ(動作環境とかがAjaxで見えるやつ)が見える。
demoの中で実行した場合は、Railsアプリはdeployされず、GlassFishの動作確認ページっぽいのしかでてこない。

んで、その辺の情報を調査してるときに、rackに基づいて作られてるアプリをJavaのアプリケーションサーバ上で動かせるJRuby-Rackを発見。
これならRailsだけじゃなくてMerbで作ったアプリケーションなんかもGlassFishとかで動かせちゃう。

さらに、そのJRuby-Rackを使ってJetty上でRailsや、MerbなどのRackベースのframeworkで作られたアプリケーションを動かせるようにする、jetty-railsを発見。
こいつは、RailsやMerb以外にも、GlassFish GemではできないJava Servletアプリケーションも動かせるらしい。
GlassFish Gemの手軽さで、RailsとServletの共存ができるなんて素晴しいってことで、さっそく試してみた。

jruby -S gem install jetty-rails で、install。
GlassFish Gemとは違って、Railsアプリのディレクトリ(今回はdemo)に入って、
jruby -S jetty_rails で、上手くいくはずなのに、次のようなエラーが。

config/jetty_rails.ymlを

---
:servers:
- :context_path: /demo
  :adapter: :rails
  :base: jetty_rails_proj
  :environment: development
  :port: 3000
:environment: production
:jruby_min_runtimes: 1
:jruby_max_runtimes: 2
:thread_pool_max: 40
:thread_pool_min: 1
:acceptor_size: 20

むーん。

===追記(10/30)===
どうやらJRuby1.1.4のバグのようです。
http://blogs.sun.com/cinnabar/entry/jetty_rails_with_jruby1_1

===追記(11/7)===
http://blogs.sun.com/cinnabar/entry/jruby1_1_5_releaseにある通り、JRuby1.1.5で動作するのを確認しました。

を受けて、id:yuripopと「協力会社さん」という立場で一緒の現場で働いていた身として、色々書いておきたいことがある。

って思ったけど、

前は、だれのブログを見ても必ずJavaのソースがあるとか、いかにコードを書くかという話だった感じだけど、いまはいかに仕事をするかとか、いかに生きるかとか。技術話から業界話にシフトしたのか。 http://d.hatena.ne.jp/nowokay/20081021#1224616671

を見て、あーやっぱ僕はコード書こうって思ったのでやめとく。

ただ、ひとつだけ。
色々あった現場だけど、僕はid:yuripopと一緒の現場にいれてよかったなぁって思うよ、うん。

吉岡さんがWassrの「今夜は飲みに行けるよ！」ボタンをずっと褒めてた。その後、酔っ払ってからはずっと眼鏡っ子を口説いてた、気がする。
あと、池面が眼鏡っ子くどいてる姿も写メ撮った。
その後、早めにyuripopと一緒に帰った。品川駅まで。

翌日、傘置き忘れたことに気がついた。

とりあえず最新のWicket1.4系を使って写経していく予定。

リッチクライアント特集の中の主にjQueryについての部分を書かせていただきました。
DB Magazineっていう名前にとらわれず、いろんな技術の特集してるんだねー。

部屋に入るとテーブルの上に、「リクエストランキング」的なものが置いてあったので、見てみました。
それはどうやら、ちょっと前のもの（行ったのは8月だがランキングは2月のもの）だったのでちょっと残念だったのですが、ランキングの中身を見てもっと残念な気持ちになりました。

このランキングを見て残念だと思う奴のほうがもっと残念だという意見は大正解

別に、オリンピックの開会式がある日だからとかじゃなく、
8が多い末広がりで縁起がいいからってわけでもなく、
08年08月08日なので覚えやすく、数年後結婚記念日を忘れたことによってdisられるのを避けるためです。

なお、史上初(?)の婚姻届を提出する場面をUstで生中継！とかやろうかと思ったけど、
絶対ぶち切れられるので止めときます。すみません。

詳しい内容は、ほかのひとのエントリを参照してもらうとして、反省から。

まず、全部矢野さん任せになっちゃってたこと。発案から募集と人数調整や会場確保、懇親会の店予約や当日の準備・進行と全部矢野さんがやられてました。
これじゃだめだ、せめて何か手伝わないとって思ってUst係をやりましたが、Ust結構難しいなぁ。ちゃんとやるにはちゃんと機材がほしいね。cojiさんに教わるべきか。
まあ、第2回以降も開催されるはずなので、そのときはもうちょっとみんなで（僕も含めて）役割分担して矢野さんの負荷を分散させないと、Wicket本がいつまでたっても上梓されないことになりそうなので、みんなで手伝いましょう。

あとは、LTはもっとちゃんとLTっぽくするべきかなぁって思った。タイムキーパーちゃんとつけて時間着たら終了！続きは懇親会でって感じのほうがLTっぽい。
そういう意味で@yamashiroの「続きは懇親会で！」の声掛けはGJだったと思う。

内容に関しての感想としては、発表内容が割とバラけてたのがよかったなーって思った。
Wicketよく知ってる人もいれば、当日処理系インストールした人もいるぐらいだったので、参加者それぞれが勉強会に求めるものが違っていた。
Wicketって名前は知ってるけど実際に使うとどういう感じなんだろ？って知りたい人もいれば、Wicketの仕組みの深い部分を知りたい人もいれば、Wicketの採用/運用実績ってどうなの？って人もいた。
そういう多様な参加者に応えうるだけの発表がそろっていたんじゃないでしょうか。

僕の個人的な感想では、ComponentResolver関連の話をもっと深めてみたかったかな。
あんな仕組みあるって知らなかったし、あそこに拡張ポイントが用意されてるってことは、オレオレフレームワークを作るための土台として使うことも想定されてるんだろうなぁ、僕ならどういじるかなぁとか色々妄想が膨らんだ。
あと、運用実績の話も、意外と知らないところで使われてるもんだなーって思った。

第2回も2ヶ月以内を目標ぐらいに開催する予定なので、今回参加した方もできなかった方も、是非ご参加ください。