めそらぼ - mesolabs.com

はてなアカウント作りました。
t_43z

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

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

DatabaseProvider#getInstance()を参照すると以下の記述が。

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

つまり、SupportedDBProviderがちゃんと取れてないんですね。
じゃぁ、そっちを見ましょう、と言うことで見てみます。SupportedDBProviderではEnumを拡張して対応しているDBかどうかをチェックしている模様。
その中にH2が含まれていないのですね。結果、DatabaseProvider様が「んなDB知るか！！！」とのたまっているのですね。お気持ちはわかります。
Wicket + Guice + ActiveObjects + H2ができない - kirikenの日記

このエントリに対し、僕は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
});

こんな感じでね。これって要は、コンストラクタ呼びだしてるだけだよね。んでこのbackを呼びだし元に返してるだけなので、結局はnewしてるのと変わらない。
ま、poolingするときは、このbackを利用可能なpoolProviderに入れて返してるんで、poolingしたい場合にはSupoprtedDBProviderを書き換えるしかないかもだけど。

というわけで、

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

でやってみてくださいな。

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

Rails 2.2でスレッド・セーフになると、JRuby上で動かす利点がさらに増えるよねってことで、JRuby On Railsを試したりしてる。

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
で、上手くいくはずなのに、次のようなエラーが。

C:/jruby/jruby-1.1.4/lib/ruby/gems/1.8/gems/activesupport-2.1.2/lib/active_support/dependencies.rb:513:in `new_constants_in': protected method `log' called for ActiveSupport::Dependencies:Module (NoMethodError)
from C:/jruby/jruby-1.1.4/lib/ruby/gems/1.8/gems/activesupport-2.1.2/lib/active_support/dependencies.rb:510:in `require'
from C:/jruby/jruby-1.1.4/lib/ruby/gems/1.8/gems/jetty-rails-0.6/lib/jetty_rails.rb:13
from C:/jruby/jruby-1.1.4/lib/ruby/gems/1.8/gems/jetty-rails-0.6/lib/jetty_rails.rb:27:in `require'
from C:/jruby/jruby-1.1.4/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `require'
from C:/jruby/jruby-1.1.4/lib/ruby/gems/1.8/gems/jetty-rails-0.6/bin/jetty_rails:36
from C:/jruby/jruby-1.1.4/lib/ruby/gems/1.8/gems/jetty-rails-0.6/bin/jetty_rails:19:in `load'
from C:/jruby/jruby-1.1.4/bin/jetty_rails:19

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

こんな感じで作って、config/environment.rbに
ActionController::AbstractRequest.relative_url_root = "/demo"
を追加しても同じ。

むーん。

===追記(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で動作するのを確認しました。

「外注と同じ仕事しかしないなら辞めろ」
http://d.hatena.ne.jp/yuripop/20081021/p1

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

って思ったけど、

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

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

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

第一回ひがやすを飲み会に参加したつもりが、いつの間にかjava-jaに参加していた。

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

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

ようやく、Wicket in ActionがAmazonから届きましたー。
PDF本も買ってたけど、やっぱり紙の本の方が使いやすいなー。

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

告知遅れたんだけど、DB Magazine9月号に執筆しました。
（もうすでに最新号は10月号です）
僕の本名知ってる人は、翔泳社のDB Magazineのページに僕の名前を見つけられるはず！
本名知らない人は、上のメニューのWHOから、mixiかFacebook見ればわかるかな。

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

先日、近所のカラオケにいきました。
カラオケの鉄人 大井町店

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

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

本日、婚姻届を区役所に提出いたします。

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

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

Wicket-jaとしては初のオフラインイベント。
会場をご提供くださいましたXarts株式会社様、ありがとうございました。

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

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

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

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

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

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

貼ったらどうみえるのかテスト