ここ最近はblogs.sun.comのネタはJavaOneで持ち切りですね。blogs.sun.comのフィードをGoogle Readerに登録して、全部チェックしているので、まだ始まっていないのにいろいろ楽しそうな雰囲気が感じられてきます。さて、岡崎はことしのJavaOneに参加できることになりましたので、今週はいろいろと準備をしています。

準備といっても、パスポート・飛行機のチケット・お金・クレジットカードがあれば何とかなるだろうという風ないい加減さなので、毎度の事ながらあんまり準備できていません。 とは言うものの、せっかくの機会なのでキチンとブログ等でJavaOneの雰囲気をお伝えしたいのでデジカメとパソコンは必須アイテムですね。

昨年のJavaOneにはNikon D50を持って行っていましたが、やはりデジタル一眼となると重くて持ち運ぶのも、取り出すのも大変・・・。なので、ことしはいろいろとガジェット(gadget; [目新しめの] 道具)をそろえて、そういう意味で準備万端にしようと密かな構想を練っています。(そんなことをしていると、だいたい他の大事なものを忘れてしまいそうですが・・・)

そんなことを考えているときに、リコーから良さげなコンパクトデジカメ「Caplio GX100」が出ると知って、先日買ってしまいました(RICOH Caplio GX100; Watermint〜捨てるには惜しいボツネタ集)。昨日、今日と買ったばかりの新ガジェットに大喜びしてどうでも良いような写真をばしばし撮ってきました。今日は多摩川沿いをチャリンコでうろうろしながらバシバシ撮ってきました。

まだ咲いていた八重桜

このカメラは撮影時に1x1とか、3x2のようなアスペクト比が選べるのがおもしろいところです。特に、1x1の正方形は使いだすとおもしろいですね。

手元のNikon D50にはマクロレンズを持っていないので、マクロモードがちゃんと使える(というか、かなり強力)というのはまた新しい発見がたくさんあります。

背景をぼかした写真も思いのまま。

夕焼けのグラデーションもきれいに写りました。カメラ好きというよりはガジェット好きなだけなので、詳しい撮影テクニックはまだまだありませんが、それでもなんか良さげな写真が出来上がってくると楽しくなってきます。この他にももう少しガジェットを携えてサンフランシスコに乗り込むつもりですがその辺りはまた別途ご紹介しようと思います。

Sunのブログサイトblogs.sun.comが今日で3周年を迎えたそうです。ブログ: 岡崎を開設したのは2005年3月からなので、2年ちょっとということになりますね。この2年ちょっとで184エントリになりましたが、おかげさまで検索エンジンでokazakiと検索するとかなり上位の方に出していただけるようになってきました。

なかなか忙しいと書きづらいときもありますが、継続は力なりと信じてまたいろいろとネタ集めをして行こうと思います。

今週はイベント／セミナーがめじろ押しでした。日本Javaユーザグループ結成総会に始まり、火曜日はNSUG/IAJapanのJavaナイトセミナー、水曜日はSun Javaエバンジェリストグループによる2時間で学ぶ今月のJavaホットトピックセミナー、木曜日はSun SolarisエバンジェリストグループによるSolarisナイトセミナー。このうち、月〜水のイベントには参加してきました。
月曜日のJJUG結成総会はご紹介済みですので、順番に今回はNSUG/IAJapanのJavaナイトセミナーをご紹介します。今回で5回目のJavaナイトセミナーですが、今回は「世界の佐藤」こと佐藤 治氏による「オブジェクト指向(再?)入門」でした。

佐藤氏の講義はホワイトボードを使って進めて行く方式でしたが、テンポもよく、うまく比喩された例を使って説明されていてすんなりと情報が頭に入ってきました。プレゼン資料を使ったプレゼンになれきってしまっている自分としてはかなり新鮮でしたし、改めてプレゼン、というより、人に情報を伝える事の奥深さを実感しました。

しかも、ホワイトボードは今回向かって左半分はアジェンダが書かれたままで、ほとんどは右側のスペースだけを使って紹介されました。ただし、内容はこの写真にあるようにとてもシンプルでわかりやすく噛み砕かれたものです。

「a.method()」を「aのmethodを呼ぶ」ではなく、「aにmethodをたのむ」 と言い換えましょう。

とか。 「aのmethod」と言った時点で、methodはaによって実装されているような感覚がしますが、「aにmethodを頼む」であれば、aは単にmethod相当の処理を別の bに丸投げするような場合も含めてうまく表現できる訳です。

今回もナイトセミナー終了後は「世界の佐藤」さんを囲んでの二次会です。

相変わらずナイトセミナー終了後の呑み会はマニアックな感じの話題で持ち切りでした(個人的なヒットはnekopさんと同い年だったことですね)。

昨日4月23日、秋葉原ダイビルにて日本Javaユーザグループ(JJUG; じぇいじゃぐ)の結成総会が開かれました。

個人的に驚いた事は、この規模のセミナーで参加者がほぼ遅刻無くほぼ満席の状態で会が始まった事です。Wakhok 丸山学長より会の主旨などが説明され、その後はいくつかの講演のあと、パネルディスカッションとして本音トークでコミュニティのあり方や、地方と中央におけるコミュニティーのあり方がディスカッションされました。

特にこのディスカッションで印象的だったのは「飲み会ドリブン」というキーワード。必ずしもお酒が必要な訳ではないにせよ、直接会って話すということの重要性は少なからず必要性があるということでしょう。

まあ、この飲み会ドリブンという話とマッチしたのか、その後の懇親会、二次会へとの流れが続いて行った訳ですが、「○○みたいなセミナーを大阪でもやってほしい」とか、「○○のようなことをやろうと思っている」とか、前向きな声がたくさん聞こえてきたのが印象的でした。

おかげさまで先日ご紹介したNSUG/IAJapan主催のJavaナイトセミナーの資料は好評のようで、カウンタを見るとすでに3,000ダウンロード以上となっていました。せっかくなので資料に載せられなかったボツネタも紹介しておこうと思います。このボツネタはトラブルシューティングの現場(だけではないですが)でよくあるパターンを、自分の心の中だけで使っている造語として定義したものを紹介しようとしていたものです。

WoTR (Waste of Time Ratio; 時間の無駄遣い比率)

WoTRはWaste of Tiime Ratioの頭文字語で、次の式で求める事ができる比率です。

WoTR = (全体の時間 - 有意義な時間) / 全体の時間

これはコーディング時間やデバッグ時間に対して計測してもかまいませんが、最もよく気になるところはミーティングについてのWoTRです。ミーティングは直感的に、普通の効率か、きわめて悪い効率かに二極化しています。普通の効率だなあ、と思うときにはあまりWoTRを意識しないのでキチンと計測した事はありませんが、直感的にだいたい10%〜20%程度です。

この程度の無駄な時間であれば、逆にミーティングをなごませたり、活気づけていると考えても良いかもしれません。一方、非効率だなあと思うミーティングのWoTRは個人的な調査結果を平均すると 81.93%です。1時間のミーティングのうち10分程度しか有意義な時間が存在しないというものです。ちなみに、有意義な時間かどうかの定義はかなり主観的ですが、後述の原因に該当するような場合には有意義ではないとしています。

なぜこのような事態が引き起こされるのかというと、一般的には次のような原因が考えられています。

• 資料を棒読み
  
• ミーティングのゴールが無い (何を確認したいのか、何を合意したいのか等)
• ゴールとは違う方向に話題が進んでしまっている
• ステークホルダーが不在 (結論に両者がその場で合意できない、あるいは合意したと思っていても後から覆る)

トラブルが発生している現場ではこのような原因が複合的に見られる事が多く、WoTRは常に高い状態をキープすることになります。トラブルシューティングとして現場に向かう際には、しょせんは１エンジニアであり、なかなかこのような状況を解決するのは難しい傾向があります。有効な手段としては、ファシリテーションの導入や、(なければ)議事録の作成ですが、まずはそういった改善策を受け入れてもらえるような土壌を作るために周囲からの信頼を得るという作業を忘れてはなりません。

 用例 

• あ〜、このプロジェクトもWoTRが高いな〜
  
• WoTRを下げる手段何か無いかな〜
  

無能化 (むのう-か)

この造語は有能な人が無理難題を押し付けられたり、キャパシティを超えた量の仕事をやらされていたり、(十分な権限が無いにも関わらず) 本来あるべき業務以外の作業を押し付けられている状態を示します。この無能化の背景には次のような原因が潜んでいます。

• プロジェクトに十分な予算が確保できていないか、予算の配分が決まっていない
• プロジェクトに十分な人員が確保できていないか、人員の配分が適切ではない
• プロジェクトを見切り発車してしまい、初期の中心人物に作業が集中する
• Role & Responsibility (役割と責任)が過度に明確化される文化が存在し、たらい回しにされる
• (作業の内容が)ランダムかつ頻繁に指示が出される
  

この無能化は、不幸な事に無能化されてしまった人だけが影響を受けるのではなく、プロジェクト全体が影響を受けます。また、当然ながら無能化されてしまった人は健康を害したり、自信をなくしてしまったりする傾向があります。

そしてこの問題の最も深刻なところは対外的には無能化されている人は「有能だ」と判断されている事です。このため、人員を増員するように話を持って行ったとしても、「有能な人を配置しているので」という理由で断られてしまうケースがある訳です。このような事から、「無能化」を現場で発見した場合にはかなり大掛かりかつ戦略的な解決の糸口を見つける必要があります (また、多くの場合、現場ならびにその周辺は精神論によって支配されているので論理的な説明だけでは不十分です)。

解決方法はケースバイケースですが、ごくまれに自然解消されるケースとしてはインフルエンザの流行等があります (つまり、その無能化された人がしばらく休むので、ようやく周囲に事態が理解される)。 

用例

• このプロジェクト、Aさんが無能化されてるからよくケアをしてあげないとね
• いっそのことAさんが風邪でもひいたら無能かの実態がよくわかるのにね
  

趣味のプログラミング 〜ダウンロードを自動化したい〜でご紹介したdocs.sun.comからのマニュアルダウンロードアプリですが、Solarisのマニュアルには歯が立たない事がいきなり判明しました (^^;;

というのも、タイトルが Solaris 10 11/06 ・・・のように、スラッシュを含んだりしていてファイルが作れないのですね。そりゃそうです。という訳で、早速アップデート版を作成しました。 

あと今回はたくさんマニュアルをダウンロードするとコレクションごとにディレクトリ分けをしたくなってくるので、コレクションのタイトルでディレクトリを勝手に作るようにしてあります (面倒臭かったのでこの設定をオフにするプロパティは作りませんでした・・)。アップデート版は次の場所から取得できるようになっています。使い方は同じです。

• DocsGetter update 1 for Java SE 6
• DocsGetter update 1 for Mac OS X 10.4 with Java SE 6

ここのところずっと忙しく、趣味のプログラミングができていませんでした。まあ、忙しいのは忙しいで仕方の無い事ですがしばらくプログラムをしないといろいろとカンが鈍るので久しぶりにプログラムを作ってみる事にしました。

今回は最近気になっているリッチクライアント系のアプリを作ってみる事にしました。とはいっても、作りはじめのきっかけはどちらかというと必要にかられて、というか、面倒臭い事を自動化したい！というところからでした。今回のプログラムはSunの製品マニュアルが置いてあるdocs.sun.comからマニュアルを一括ダウンロードしたい！という思いから2時間ちょっとで手抜きアプリとして完成しました。

docs.sun.comでは上図のSun Java System Web Server 7.0のマニュアルのように一つの製品に対して結構たくさんのパートにわけられたドキュメントの構成になっています。普段はオンラインで見たり、ダウンロードすれば良いのですが、お客様先へ出かける際などでネットワーク接続できない場合には手元のPCあるいはCD-ROMに入れて持っていきたいというケースが結構あります。

また、最近はGoogle DesktopやMac OS XのSpotlightのように手元のPDF等のドキュメントを検索するためのツールや機能も手軽になった事もあり、より快適なドキュメント検索をするためには製品マニュアルのようなドキュメントを手元に置いておきたくなってきます。

このような時にマニュアルを一つ一つダウンロードするのは面倒だし、また、Sunのマニュアルはダウンロードすると「819-2629.pdf」のように管理用の番号で保存されてしまうのでマニュアルを探すときにいちいち開けなければならず面倒でした。

今まではダウンロードしてはファイル名を変えていたのですが、こんな非効率な事をするのはどうかということで製品のマニュアルを一括ダウンロードした上で、ファイル名もちゃんとわかりやすいものにするようなアプリを作る事にしました。そして出来上がったのがこちらです。

2時間ちょいで作ったアプリケーションにしてはわりと見栄えが良くなったように思えます。製品マニュアルのURLをベースURLの欄に入れて実行を押すと自動的にマニュアルを全部ダウンロードしてくれるという寸法です。もしかしたら利用されたい方がいらっしゃるかもしれないので一応バイナリは公開しておきます。

• DocsGetter (Java SE 6用)
• DocsGetter (Mac OS X 10.4以降 + Java SE 6用, dmg形式)
  

両方とも内容は同じですが、Mac用しかテストしていません :-P

このアプリケーションではJava SE 6が必要で、Mac OS Xの場合はApple Developer ConnectionからJava SE 6を事前に入手＆インストールしていただく必要があります。起動方法はMac版の場合はdmgを展開してDocsGetterアプリを起動、Java SE 6用はZIPを展開して、その展開したディレクトリで

java -jar DocsGetter.jar

というようにコマンドを入力して起動します。使い方はそれほど機能がないので難しくはないと思いますが、「http://docs.sun.com/app/docs/coll/1308.3」のようなdocs.sun.com上の製品マニュアル一覧のページURLを「ベースURL」の欄に入力して実行を押すだけです。HTTP接続にプロクシが必要な場合はその設定をし、保存先を設定したい場合にはその設定を事前に行ってください。なお、例外処理などはほとんど皆無なので、うごかなかったらあきらめてください・・・。

ダウンロードが完了すると次のような感じでファイル名がタイトルになっていて、ずいぶんとマニュアルが探しやすくなりました。

今回このアプリケーションを作るのにはNetBeans 6.0マイルストーン8で開発し、SwingLabsによるSwingXのコンポーネント、およびビーンとSwingコンポーネントを結びつけるためのライブラリでJava SE 7に入りそうなBeansBinding (JSR-295) 0.5が丁度ダウンロードできるようになったので使ってみました。

他にもライブラリはいろいろ使っているのですが、旬の技術という事で今回はBeansBindingについてちょっと紹介しておきます。BeansBindingはPOJOとSwingのコンポーネントを結びつけるためのライブラリで、Swingのテキストフィールドなどがユーザによって値が変更された結果を自動的にPOJOに同期してくれるというものです。

従来のSwingアプリケーションではテキストフィールド等の情報はgetterメソッドを使ってそれぞれの項目ごとに取得していたのですが、その作業は結構大変で、面倒なものでした。このBeansBindingはその面倒さから解放してくれるすばらしいライブラリなのです。使い方もそれほど難しくはありません。基本的な機能を利用するときの書き方は次のような感じです。

   new javax.beans.binding.Binding(settings, "${proxyHost}", proxyHost, "text").bind();

これはsettingsというproxyHostというプロパティを持つPOJOのインスタンスを、proxyHostというJTextFieldの値(text)とひもづけるという操作です。おもしろいのはPOJOのプロパティを指定するところにELが使えるというところです。

なのでたとえば、${proxy.host} というようにドット区切りでネストしたプロパティにもアクセスする事ができます。今回のアプリでも画面から設定できる値についてはこのBeansBindingを使って同期しています。

今回のアプリ程度の規模であればこのBeansBindingを使ううまみはあまり無いのですが、項目がもっとたくさんあるようなアプリの場合には効率はずいぶん違います。また、今回は利用しませんでしたが値のバリデーションやコンバート等をバインディングに記述すると今までgetter/setterを使ってがんばって値をやり取りしていたコードからはおそらく見違えるようなすっきり感が得られるのではないかと思います。

ご興味があればこの辺りぜひ使ってみてください (バージョンはまだ0.5なのでまだいろいろ変わるかもしれませんし、バグもいろいろあるかもしれませんが)

3月27日に行いましたNSUG/IAJapan主催のJavaナイトセミナーで使いました資料を遅ればせながら公開させていただきます。

• 2時間集中Javaトラブル解決ドリル