既に大渕さん、寺田さん、増月さん、Jimさんによってレポートされていますが、JavaOneの決まり文句「Don't Be Shy」でおなじみのJohn Gageのお話を聞くチャンスに恵まれました。先週のSimon Phippsとのミーティングといい、Sunの主要なビジョナリーに直接話を聞ける機会とあってうきうきしていました・・。が、起きたらややぎりぎりの時間で、しかもPASMOのチャージ不足とかでぐずぐずしていたら少し遅刻・・・orz。

大渕さんのブログにある

デスクトップ PC とサーバについて、重さと原材料消費量の比を考えると、デスクトップ PC は 100 倍だけど、サーバだと 2 倍におさえられるんですよ、とかの小ネタもおもしろかったです。

を説明するスライド。

ワンセグ携帯に驚いたことをうれしそうに説明するJohn Gage。単なるガジェット好き、という感じではなくて、テクノロジーに対する尊敬と愛情が満ちあふれていました。

最後は予想通りというか、撮影大会です。ストロボ(SB-600)が鞄に入らなくて持っていけなかったのが個人的には悔やまれるところです。

この前の記事の続きです。ようやく写真が全部アップロードできました。なお、すでに知ってるよ〜という方も多いかと思いますが当日の資料はOpenSolarisの日本語ポータルよりダウンロードできますのでご興味のある方はそちらから資料をゲットしてみてください。

Solaris on Eee PCからSecondLifeを起動するというデモンストレーション。どうさ速度はけっこうキビシい感じ・・・。

SecondLifeで会話を試みるあかぴん先生。

続いて佐藤さんによるSolaris 10かNevadaかどっちを使うか！？というお話。

最後はQ&Aタイム。なんと、沖縄など遠くからこのためにお越しいただいた方も！

片付けも終わり、打ち上げ会場へ。

打ち上げ会場。

カンパーイ！カメラ談義で盛り上がったり、パッケージ管理についての熱い議論があったり、傍観しているだけでもそうとう楽しい打ち上げでした。

前々から自宅のインターネット環境をemobileに移行しようかと考えていましたが、ExpressCard/34タイプの7.2Mbps対応モデルD03HWというのが出たので、このタイミングで買ってしまうことにしました。元々はもう少し先でもいいかな〜、と思っていましたが今日たまたまビックカメラに行ったら先行発売の在庫があるとのことで早速買ってきました。通信速度はうちの部屋だとめちゃくちゃ早い、という感じはありませんが、まあだいたい予想の範囲内なのでそれはいいでしょう。唯一の不満はMac OS X用のユーティリティソフトがださ過ぎることです。

このアイコンはさすがにないでしょう・・・。これはアイコンが設定されていないアプリに対してMac OS Xがデフォルトのアイコンとして設定するアイコンです。これはひどい。/Applicationsフォルダの見栄えにこだわる自分としては許せません。

早速アイコンを作って、

設定完了〜。ところで最初はこのユーティリティソフトをいちいち起動しないとインターネットにつながらないのかとだまされた気分になりましたが「インターネット接続」を使って、メニューバー上にモデムの設定を出せばちゃんとメニューバーからアクセス可能になります。

左端の電話アイコン。

どうでもいいですが、うちのflickrアカウントの写真に対するビューが30,000を超えました。惜しくも写真枚数はまだ30,000枚を超えられていません・・。すこしビューにリードされています。でも、遅くとも来月中には写真も30,000枚を超えそうな勢いです。

愛用のGPSロガーSony GPS-CS1K。以前書いたMac OS XをLeopard(10.5.2)からTiger(10.4.11)へダウングレードした理由の一つにこのデバイスがLeopardでは使えないことがあります。GPS-CS1は通常のUSB Massストレージデバイスなのですが、どうもMac OS Xのドライバとの相性が悪いらしく、利用できるOSのバージョンがMac OS X 10.4.9〜10.4.10のIntel Mac (および10.4.8のMac Pro)でしか利用可能な実績がありません。これに困っている人は多いようで、ググルと山ほど似たような症状を抱えた人のブログが引っかかります。

これは海外でも同様で、いろんなフォーラムやブログで日本と同様に困った困ったとの記事がヒットします。その中でも最もメジャーなワークアラウンドがSony GPS-CS1 for Mac (macgpscs1.blogspot.com)というサイトのワークアラウンドです。結構強引な方法なので当然サポート外な方法なんですが、サポート外でも何でもとりあえず使えるならと祈る気持ちで・・。今回の問題はGPS-CS1をハンドルすべきIOUSBMassStorageClass.kextというドライバのバージョンにあります。いろいろ情報をまとめてみると次のような感じです。IOUSBMassStorageClass.kextはMac OS Xのオープンソース部分Darwinに含まれているのでそれぞれソースコードを参照することができます。

• Mac OS X 10.4.8 ... IOUSBMassStorageClass.kext v145.0.4 → NG
• Mac OS X 10.4.9 ... IOUSBMassStorageClass.kext v147.0.7 → OK
• Mac OS X 10.4.10 ... IOUSBMassStorageClass.kext v149.0.6 → OK
• Mac OS X 10.4.11 ... IOUSBMassStorageClass.kext v150.1.3 → NG
• Mac OS X 10.5.0〜2 ... IOUSBMassStorageClass.kext v200.0.3 → NG

ソースコードのdiffをとったりしてみましたが、どうも設定で回避できるような感じでもなく、どこかの分岐ブロックで機嫌が悪くなってしまっているようです。USBドライバどころかカーネルエクステンション自体、デバッグどころかビルドしたことさえないので、ちょっとこの先は手が出せそうにありません。仕方なく、先ほどのmacgpscs1.blogspot.comに紹介されていた手法でワークアラウンドを試しました。

1. Mac OS X 10.4.10のコンボアップデートのdmgをとってくる
2. USBデバイスを念のためとりあえず全部はずす、よけいなアプリは終了しておく
3. IOUSBMassStorageClassをkextunloadする・・、つもりが、できないのでそのまま強行。
4. 既存の /System/Library/Extensions/IOUSBMassStorageClass.kextを名前を変えたり、移動したりする。
5. Pacifistというツールで10.4.10のコンボアップデートdmgからIOUSBMassStorageClass.kextを取り出して /System/Library/Extensionsにおく
6. sudo touch /System/Library/Extensions
7. リブート

これで無事、Sony GPS-CS1Kにつながりました。ひょっとしたらLeopardでも同様にIOUSBMassStorageClass.kextをv149.0.6とかに変えてやれば動作するかもしれませんが、v1xxからv2xxへとメジャーバージョンアップしていることなどを考慮すれば、かなり危険なチャレンジになりそうなのでやめておいた方がいいでしょう。

先週の金曜日はOpenSolaris 2008.05 リリース記念セミナーに参加してきました。写真がまだflickrにあがりきっていないようですが、どうやら家でアップロードのバッチ処理がこけているようです・・。うむ・・。

さて、今回は神宮前のオフィスでの開催でした。実は神宮前オフィスへ行くのは今回がはじめて。それほど道は複雑ではないとはいえ、やや歩くのですごく迷子になりやすい自分としては行くだけでまずドキドキです (^^ゞ

実はセミナーの前に今回このセミナーだけのために来日されたSunのチーフオープンソースオフィサーSimon Phippsさんと社内メンバーと意見交換をしたりしました。

せっせと会場の準備。三つ部屋がつながるので結構広いですね。

たくさんの方にご来場いただきました。

大曽根さんの格好がぱっと見遠くからでは誰だかわかりませんでした・・・。

OpenSolarisのセミナーではビールが出て、乾杯から始まり、なごやかなムードで進められます。いつものOpenSolarisセミナーでは一人のスピーカーが2時間程度はなす、という流れですが今回はSunからは特別ゲストのSimonさんをはじめ、大曽根さん、長谷川さん、OpenNSUG/OpenSolaris User Groupからは太田さん、佐藤さんと豪華スピーカー陣でした。

最初はSimonさんから。オープンソースについて一番良く聞かれること。「オープンソースでどうやって儲けているのか？」についてお話をいただきました。

ホワイトボードを使って従来のビジネスモデルと、オープンソースを使った場合のビジネスモデルの違いを説明していただきました。おそらくこの辺りはSDC等で詳しくレポートが出てくると思いますので、省略しておきます。

次は大曽根さん。帽子の横かぶりがまたいい感じです。

続いて長谷川さん。

OpenSolarisをEee PCで使う！に続きます。写真のアップロード・プログラムがこけているので続きはまた後ほど・・。

自分のブログでどういった話題が人気なのかを調べてみたところ、今月はダントツでMac OS X版のOpenOffice.org 3.0ベータを試すという3月に書いた記事でした。この頃のビルドがいくつだったかは覚えていませんが、5月7日にはベータテストが開始されたこともあって一気に注目が高まったのかもしれません。さて、個人的にはこの辺りのネタも気になるところですが、個人的には5月8日のブログOUT NOW!! - The first public version of ODFDOM.. (GullFOSS)が断然気になっていました。このODFDOMはOpenDocument Formatの文書を扱うためのJava APIです。OpenOffice.orgがなくとも単体で動作するのが魅力的です。早速ダウンロードして試そうと思ったら、Java 5 implementationと書いてあるのに、中身を見たら思いっきりJava SE 6でコンパイルされていて読み込めないし、ソースをダウンロードしてJDK 5.0でコンパイルしようとおもったらJava SE 6のAPI使っててコンパイルできないし・・・。おいおい・・・。ということで、Java SE 6が使えない自宅PCではあきらめて、別の環境で。

まずはテストデータを作っておきます。一番いじりたそうなスプレッドシートのドキュメントを作って、適当にいくつかデータを入れておきます。

次にこの手のドキュメントもRubyから扱えたら素敵なので、jirbからインタラクティブに試します。CLASSPATHにはこのodfdom-v0_6_1.jarと、xercesImpl.jarを別途ダウンロードして入れておきましょう。

include Java
import org.openoffice.odf.doc.OdfDocument
d = OdfDocument.load('./test.odf')
c = d.get_content

という感じでインタラクティブにうちこむとその結果が取得できます。はい、結果は見るからにDOMですね。このOdfDocumentで読み込んで、getContentで得られるDOMをXPath等で取り出したりして、いじっていけばコンテンツをいろいろいじることができます。OdfDocumentクラスを通してDOMをファイルに保存することもできますし、画像ファイルの追加なんかもできます。まだバージョンもv0.6.1と早熟な感じなのでしょうがないところですが、ドキュメント自体をもう少しODFに特化した形のJavaクラスを用意しておいてほしいところですね。
まだほとんどDOMをそのまま生で触っているのと感覚が同じです。とはいえ、ようやくODFを扱うためのまともなAPIが出てき始めているのはとても楽しみです。今後の発展に期待しましょう。

この間水没してしまったLomo Fisheye2ですが、無事復活したので再度Lomo fisheye submarineとともに水中写真を撮ってきました。しかも今回は、Lomo fisheye submarineのスペック上の限界深度 20mを大幅に上回りそうな予感たっぷりの、Enriched Air Nitrox (以下EAN)を使ったダイビングです。EANとはおおざっぱに言えば、普通の空気に比べて酸素がたくさん入っているボンベを使ってダイビングをすることです。普通の空気はだいたい酸素が21%、窒素が78%ぐらいですが、ダイビングをしているときの一つの問題として窒素が体にとけ込んでしまうことがあげられます。別にとけ込むだけならいいのですが、深度をあげていくととけ込んだ窒素が体内で気泡化してしまい、減圧症を発症してしまうことがあります。

大まかには、ダイバーが水中にいられる時間は残りの空気の量と、体にとけ込んだ窒素の量によって決まります。ダイビングの上級者であれば、消費する空気量はおおむね初心者と比べ少ないので、より水中に長く滞在できるのですが、平等に訪れるのが窒素による滞在時間限界です。高圧下ではより多くの空気を取り込むことになり、結果、窒素がより多く体にとけ込むため、一般に深い場所に行けば行くほど水中で滞在可能な時間は短くなります。めずらしい魚に限って深い場所にいるのに！

さて、そんな問題を和らげることができるのがEANです。EANは酸素がたくさん入っていて、今回つかったボンベだと31.6%の酸素が入っていました。つまり、その分だけ窒素が少なく、深場での滞在時間を長くとることができます。少し前置きが長くなってしまいましたが、EANを使うときは、たいていの場合、深場を目的としているので、耐圧20mなLomo fisheye submarineが耐えられるかは、一度30mまで耐えられることを確認しているとはいえ若干心配でした。

でも今回は、20mぐらいのところでゆったり過ごすというプランだったため、深度の面ではセーフ。あとは、Lomo Fisheye2の怪しげな露出計算を水中でどうするかを検討しながらパチパチ写真を撮ってみました。これはホンソメワケベラ。ちょこまか動くのでコンデジでとるとたいていぶれますが、Lomo Fisheye2はシャッタースピード1/100秒固定なのでそれほどぶれません。すごく近づいてストロボを炊いたので露出もまあまあです。

キビナゴのすごい群れ。だいたい自分から5m以上はなれたところをキビナゴが真鯛に追いかけられてすごいスピードで通り去っていきました。5m以上離れているので、ストロボを炊いてもほとんど意味はなく、かえってマリンスノーだらけになってしまうのでISO 400の明るさを信じてそのまま撮影。なんとか、見える範囲ですが、この手の写真はやっぱりToycameraの限界を感じてしまうところで、コンデジ＋ワイコンか、一眼＋広角レンズが欲しくなってしまうところです・・。

ありきたりなアオウミウシです。マクロ撮影には全くて適しませんね・・・このカメラ。

みんなでムラサキウミコチョウを撮っているところ。まったくわかりませんね・・・。このムラサキウミコチョウ、泳いだんです。初めて生で泳いでいるところみました。ちょっと感動。

クマノミとか。

イバラカンザシとか。マクロレンズで撮るとおもしろんですけどね〜。フィッシュアイだと、フィッシュアイなりの被写体を選びますね。もうちょっと勉強しないと・・・。

起動できなくなっていた写真管理ソフトApertureが起動できるようになりました。Macのトラブルシュートはあんまりしたことがなかったのであたふたしましたが、原因不明なエラーで、ぐーぐる先生にお伺いするよりはコンソールのログをみた方がより有意であることに、お風呂に入っているときにひらめいて、早速実行。

関係ないログは無駄にモザイクしてありますが、どうやらApertureはCFNetServiceRegisterWithOptionsの呼び出しでこけているようです。error = 9と出ているので原因不明のエラー 9、というのもこのエラー番号なのでしょう。このエラーの意味はなんだろうな〜、なんて思いながらAPIをみているとどうやらBonjour関係のものであることに気づきました。ん？Bonjourといえば、Mac OS X 10.5(Leopard)からOS X 10.4(Tiger)へで書いた通り、mDNSResponderを止めています。どうやらこれっぽい・・・。ことに気づいて、

$ sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist

とやってmDNSResponderを有効化。Apertureは・・・、無事起動。これか・・・。Bonjourに依存して起動できないアプリを初めてみました。mDNSResponderって何となくセキュリティ上(アメリカ国家安全保障局の公開しているMac OS X Security Configuration For Version 10.4 or Later, Second Edition [p126]でも心配ならdisableにしろ、と書いてあるので)オフにしておいた方が安心だろうと思っていました。Bonjourはファイル共有やプリンタの検出のためにとても便利ですが、個人的にはそういったことは手動設定でよいと思っているのでBonjour機能は特に必要なく、オフにしておくことがセキュリティ上も、(微々たるものですが)リソース消費の観点からも好ましいだろうと思っていました。それがまさか必須のアプリがあるとは・・・。
まあ、これを有効化したことによってたちどころにセキュリティ上の問題が出ることはなく、ちゃんとネットワークの設定で共有したいサービスを選んでおけばいいのですがなんとなく釈然としないですね・・。

この間から原因不明のエラー9というのが出たまま、Aperture 2.1が起動できなくなってしまいました。これは困った・・・。ライブラリの中のPreferencesやApplication SupportのAperture関連のものを消してもだめ。ほかのアプリを全部止めてからやってもだめ。再起動してもだめ。困った・・・。

この間Macアプリ化してみた継続インテグレーションツールのHudsonですが、ようやく実行中の三角マークが出るようにできました。やり方はとっても簡単でした。

HudsonにはJava Web Start版のHudsonがあるのですが、Java Web Start版ではグラフィカルなコンソールが立ち上がってそこにログが出力されます。このコンソールのメインクラスを読んであげるようにすればいいだけです。コマンドライン版のメインクラスがパッケージなしのMainだったのに対し、こちらはJNLPMainという名前のクラスです。

あとせっかくなので、最新の1.218をベースにdmg形式のパッケージも作ってみました。

欲しい方はこちらからダウンロードしてみてください。

• Hudson.dmg

Differences between Java CAPS 6 and OpenESB (Jason Baragry's Blog)より。アクエリアムでも既に取り上げられていますが、良くご質問をいただく内容が含まれていますので改めて、こちらのエントリの内容をベースにOpen ESBやJava CAPSの位置づけを確認しておきます。

One of the most common questions I get asked is, "Will Sun support OpenESB?" or "Is Java CAPS a supported version of OpenESB?" Developers want to get started now with functionality in Open ESB and feel confident that it will be supported by Sun with a Java CAPS license.

ここにもあるように、頻繁にいただく質問に「SunはOpen ESBをサポートするの?」とか「Java CAPSはOpen ESBのサポートがつく版なの?」あるいは「SunはOpen ESBに本気で取り組んでいるの?」といった質問があります。

We do already have some JavaCAPS customers who are entering the development phase of their projects with Open ESB in the knowledge that the infrastructure will be a supported part of Java CAPS by the time they go to production. Unfortunately, the answer to the original questions is a little more detailed than simply "yes" or "no". Let me explain...

伝え聞くところでは日本でもいくつかのプロジェクトでOpen ESBの評価をしていただいているとのことですが、ここで取り上げられているようによりSunが密接にサポートさせていただいている海外のお客様では既にOpen ESBをベースとしたプロジェクトが開発フェーズにあるとのことです。もちろん、ESBを導入するようなケースで、サポートが不要であるということはまれで、Open ESBがJava CAPSによってサポートされるはずだろうということで、本番環境のサポートを得ようとお考えです。この考えはほとんどの場合正しいのですが、残念ながらシンプルにYesともNoとも言えません。

Java CAPS 6 is, to grossly oversimplify it, Java CAPS 5 + some OpenESB technology. However the first release of Java CAPS 6 will not include all OpenESB components. This is for a couple of reasons:

• Not all openesb components have been through the necessary QA to make them ready for production yet.
• Not all openesb components are developed by Sun, so it is impossible for Sun to support them.

Java CAPS 6はとても大雑把に言えば、Java CAPS 5.1.x + Open ESBのいくつかのテクノロジを取り入れたものと言えます。ところが残念ながら最初のJava CAPS 6リリースではすべてのOpen ESBコンポーネントはJava CAPS 6に含まれません。それには次のような理由があります。

• まだOpen ESBのすべてのコンポーネントが本番環境で利用するのに耐える品質保証作業が行われていないこと。
• すべてのOpen ESBのコンポーネントがSunによって開発されたわけではないこと。このため、Sun以外の方々によってOpen ESBに寄贈されたり開発されたコンポーネントをSunがサポートすることができないこと。

When Java CAPS 6 is released, it will consist of some openesb components. For instance:

• JBI runtime.
• BPEL SE
• HTTP BC
• JavaEE SE

Java CAPS 6が最初にリリースされる段階で含まれるOpen ESBのコンポーネントには上記の通り、JBIランタイム、BPEL 2.0準拠のBPELサービスエンジン、HTTPバインディングコンポーネント、それにEJB等Java EEコンポーネントをサービスエンジンとして利用可能にするJava EEサービスエンジンがあります。

During the rest of 2008, Sun will continue to make other openesb components production ready and make them supported parts of Java CAPS. The exact content and timeline of these "Component Packs" or is still to be released, but you can probably expect them to include:

• IEP SE
• JBI BC & SQL SE
• JMS BC
• XSLT SE
• File BC
• others.

(note: I'm not in product management so this isn't an official list, just an indication)

製品担当マネージャではないので、との前置きがありますので上記リストは、参考程度にご覧ください。公式にサポートされるコンポーネントのリストは正式リリース時にリリースノート等で参照できるようになるはずです。Sunは2008年の残りの時間を使って、最初に挙げた基本的な4つのコンポーネント以外のコンポーネントについても本番環境に耐えうる品質で、Sunからサポートされるコンポーネントを"コンポーネントパック"としてリリースするつもりです。まだそれらがいつ頃でて、どのコンポーネントがパックに入るのかはわかりませんが、有力な候補は次のようなコンポーネントです。

• IEP SE ... インテリジェント・イベント・プロセッサ SE。
• JBI BC ... JBIに対するバインディングコンポーネント
• SQL SE ... SQLのサービスエンジン
• JMS BC ... JMSに対するバインディングコンポーネント。いわゆるMQとつなぐためのコンポーネントですね。
• XSLT SE ... XSLTをサポートするサービスエンジン。XMLの書式を変更する場合等に使うエンジン。
• ファイル BC ... ファイルアクセスのためのバインディングコンポーネント
• その他

Additionally, Sun may enter agreements with the companies who are developing other openesb components and make them "supported" parts of Java CAPS. So it is possible that OpenESB components that are not developed by Sun will also be supported by a Java CAPS license.

また、Sunが開発した以外のコンポーネントについても、それらを開発されている企業にたいして、Java CAPSのサポートされるコンポーネントの一部として取り入れられるように合意をいただいている最中です。このあたりがうまく整理がつけば、多くのOpen ESBに貢献されているコンポーネントがJava CAPSライセンスをご購入いただくことでSunからサポートを得ることができるようになります。

To give you an example. I currently have two Java CAPS 6 "customers", even though it has not yet been released.. They have looked at their requirements and see that they need only components which will be available in the initial release of Java CAPS 6 or will most likely be available in Component Packs in 2008. They have started development work now and plan to be in production in 2009. By 2009, all OpenESB components they need will be supported parts of Java CAPS.

元記事のJasonさんはすでにJava CAPS 6 を(ベータ段階より) 2社のお客様にご利用いただいているそうです。それらのお客様の場合には、Java CAPS 6が最初にリリースされる段階で含まれるコンポーネントと、2008年中にリリースされるであろうコンポーネントパックに含まれる予定だとのことです。それらのお客様では2009年より本格稼働を開始されるとのことです。

さて、最初の質問に戻りましょう。

• SunはOpen ESBをサポートするの?
• Java CAPSはOpen ESBのサポートがつく版なの?
• SunはOpen ESBに本気で取り組んでいるの?

最後の質問はシンプルにYesと答えられますね。あと残りの二つですが、以上すこし長くなりましたが、Java CAPS 6はOpen ESBの主要な部分をサポートし、残りの部分については準備が整い次第サポートするといった回答になります。すこし歯切れの悪い答えになってしまいましたが、シンプルにYes！と答えられるような方向に努力している最中だとお考えください。

CAPS6 code freeze is today (Fred Aabedi)より。SunのSOA基盤ソフトウエアであるSun Java CAPSの次期バージョン Release 6が今日、コードフリーズ段階に到達したそうです。これでいよいよ後はリリースに向けた最終調整を残すのみとなります。

To name a few: support for Netbean 6.1 for CAPS tooling with the ability to create/build and deploy repository based (5.1.x) applications in addition to the new JBI and Java EE5 based applications with Interoperability features for a mixture of these.

Java CAPS 6ではJava CAPS 5.1.xで作成されたプロジェクト(これをレポジトリベースアプリケーションと言います)と加えて、JBI (JSR 208)に準拠したOpen ESBエンジンも搭載しています。開発環境は最新のNetBeans 6.1をベースとしています。実はJava CAPS 5.1.x以前もSeeBeyond ICAN Suiteの時代からNetBeansが開発環境のベースとして使われていましたが、今回はよりNetBeans自体の持っているSOA機能をフル活用するように仕上がっています。

Many eWay adapters are available as standard JCA adapters for use in JavaEE/ejb applications. Upgraded features for many adapters like V3 support for HL7, Security (SNC) support for SAP, EJB 3 support for Weblogic and SunOne,... Runtime, uses the standard GlassFish 9.1 Application Server.

対外システムとの接続をサポートするeWayアダプタも、Java EE標準のJCAを通してEJB等から利用することができるようになりました。ESBのような基盤を導入しようと考えた場合、外部システムに対してEJB等から直接やりとりをするのはやや例外的なことで、通常はバスを通して外部システムにアクセスするようにします。とはいえ、すべてのケースに対してバス経由のアクセスが必須とされると、パフォーマンス上の問題を解決できなかったり、特殊なごく一部の要件を満たすために大きな労力が必要となってしまいます。Java CAPS 6では、EJBからも直接eWayアダプタを利用できるようにしたことで、要件に応じた柔軟な設計を選択できるようにしています。 そして、Java CAPS 6の実行環境はGlassFish v2です。

Application Configuration, allows for building the application once and deploy to multiple runtime environments without change by externalizing the connectivity configurations. The installer is much friendlier and faster and support additional platforms. Lot's of cool features in Management and Monitoring framework including API callable from all JSR-223 Scripting languages.

通常、ミッションクリティカルシステムを開発、運用するためには、開発環境／テスト環境／本番環境のように複数の環境が存在します。Java CAPS 6ではこれらの環境固有の設定が分離して管理されるため、環境を変えるごとにアプリケーションを改変する必要はありません。また、インストーラがずいぶんわかりやすく、使いやすくなりました。これは評価のためにちょっと試してみようという時に、ずいぶん役に立ちます。あと、管理・監視機能がJMXによってアクセス可能になったので、たとえばJSR 223準拠のスクリプティング言語、たとえばJRubyやJythonからこれらの監視・管理機能を呼び出すことができます。JRubyでやりたい！なんてお考えの方は、以前書いたJRubyでJMXが参考になるかもしれません。
JBI/Open ESBをベースとした本格的なSOA製品の登場ということもあって、今後の動向がとても楽しみです。

Nozawaさんのブログを見て思い出しました。前から買おうと思っていたのに忘れていた本、「 Rails of Ruby on Rails ~Case of LOCUSANDWONDERS.COM~」をさっき買ってきました。ぱっと見ではRubyの本だ！とは気づかないようなカッコイイデザイン。これがプログラマー向けの本の場合、Railsの使い方に終始して、サンプルアプリが幾つかある。というパターンが典型的ですが、この本ではブログの作り方とか、ショッピングカートの作り方のようにサイトをデザインする際に必要なユースケースごとに説明があることです。
Rubyは今までもコマンドラインでテキスト整形などに使っていましたが、実はRailsってほとんど触ったことがありません。ほとんど、というか、Scaffoldさえ触っていません・・。NetBeansのRuby/Rails機能を使っているのでそんなRails初心者の僕にうってつけの本です。

久しぶりにみたらずいぶん犯罪と交通網がひどいことになっていました。町の規模としては、昔の実家付近を思い出すようなぐらいの発展ぶりです。