watermint.org

先週はJava Hot Topicセミナーに行ってきました。今月からSun Microsystemsの法人が完全にオラクルと統合されたとのことで、Sun Microsystems K.K.として行われたおそらく最後のイベントです。Java Hot Topicセミナーは2006年11月に始まって、合計28回もやってたんですね。Sunにいた頃はほぼ毎月、喋るネタか、Javaパズラーの問題を考えるのが習慣になっていたように懐かしく思い出します。

2006年11月当時、マスコットといえばDukeだけでした。いまやご存知NetBeansの「ねこび〜ん」にMySQLの「Sakila」が加わりにぎやかになりました。

いままで運営していただいたエバンジェリストの皆さん。おつかれさまでした。

ノベルティーの大放出もありましたよ。Java Hot Topicセミナー、最初に始めたときの名前はたしか「2時間で学ぶJavaホットトピックセミナー」という長い名前でした。他候補として3つぐらい考えた覚えがありますが、なんとなくしっくりきたのがこれだったと思います。今後、少なくとも形式はかわるでしょうけれど継続的にこのようなセミナーが開催されることを願ってやみません。

先月のJJUG CCC 2010 Springでは、GlassFishで即習！Java EEパフォーマンスチューニングとトラブルシューティングというセッションでお話をさせていただきました。今回、資料を準備するにあたって、話の主軸をどこにおくか最後まで迷いましたが、本業で謀殺されていたためあるいみ消去法で決めざるを得ませんでした。話そうと思っていた主軸の一つはかなりテクニカルかつ、具体的な例を挙げてGlassFishでパフォーマンスチューニングやトラブルシューティングを行う方法の紹介です。残念ながら今回はこのネタでの発表は準備が間に合いませんでした。経験上、ある問題があったときにそれを解決に導く方法や、GlassFish特有の便利な機能を見つけることは出来ると思っていますが、発表に耐えるほどわかりやすく、GlassFishの特色を出したサンプルアプリケーションの作成が間に合いませんでした。こういった話を期待されていた方には大変申し訳ないです。

もう一方の、今回お話をした話はもう少し大局的で、概念的なお話です。実際のところ、ここ数年でこういった話を聞く機会は少しずつ増えたものの、現場を見て回ればあまりそれらの知識が生かしきれていないようにも感じていました。今回の発表の趣旨はおおざっぱに言えば「便利なものをもっと使おう、そのために使える環境を準備しよう。あるいは使えるように交渉しよう」という内容でした。

前提として、よくあるトラブルシューティング／パフォーマンスチューニングの現場を説明しておきましょう。プロジェクトメンバーは多くの場合すでに多方面から時間的／政治的プレッシャーを与えられており時間的／精神的な余裕はあまりありません。新たなツールを導入するような時間もコストも許されず、対処方法は似たような事例をGoogleで検索する程度です。Googleで検索した情報がぴったりその状況を引き起こしている原因に当てはまれば良いのですが、それは一攫千金を夢見て宝くじを買いに走るのと同様、確率に身を委ねているにすぎません。Googleで検索した情報は既に現在のバージョンのプラットホームには意味の無い情報だったり、現在扱おうとしているトランザクションの性質と、検索で見つかったブログエントリーが問題としているトランザクションの性質が多くの場合違うからです。

では本質的に、問題を解決するためにはどうしたらいいでしょうか。問題を解決したり、あるいは本当に解決されたことを確認するためには問題の原因を探る必要があります。原因が分からなければ再現手順もわからず、解決したことを示してみせるにも説得力がありません。経験上、トラブルシューティングを行うときのほとんどの時間は問題の原因を探すこと、とくに問題を再現することに充てられていると言っても過言ではありません。問題の再現は、比較的簡単な場合もありますが、プロジェクトメンバーが時間的／精神的に追いつめられるほど深刻な問題の場合、問題の再現すら難しいというケースがほとんどです。

本番環境で発生している問題は、なかなかテスト環境では再現しません。データに起因する問題、ハードウエアやプラットホームの違いによる再現性の違いによって、問題の再現は困難を極めます。また、仮に似たような問題を再現できたとしても、それが本当に本番環境でおこっているトラブルやパフォーマンス劣化と同一なのか、確認することはきわめて難しいことです。こうした問題は、本番環境と切り離された環境、少ない情報で作業せざるを得ない環境特有の問題です。本番環境で直接プロファイリングをしたり、ログやダンプの設定を動的に変更したり、プローブを加えて仮説を検証することができれば問題の原因特定は飛躍的に効率的になります。

ツールを使うことを勧めると「はい、それはわかっています。しかし、xxxx」というような返答は常にあります。SOX、J-SOXなどをきっかけとした職務分掌／権限分掌の確立もより問題を複雑にします。?本番環境にデバッガやプロファイラが接続できればどんなにいいことでしょうか。そのシステムの設計や開発に携わったエンジニアであれば、いくつかの仮説を持って問題に取り組むことが出来ます。しかしながら、仮説を検証するためには情報を試行錯誤しながら集めなければならず、1ヶ月に1度しか変更の加えられないシステムに対しては仮説の検証も困難を極めます。

さて、だからといってこのまま闇雲に問題解決に取り組んだり、じれったい思いをしながら雲をつかむような思いでログをなめ回すことを続けるべきでしょうか？日本のエンジニアは勤勉で、優秀です。しかしながら、ツールが自由に使えないがために諸外国の経験の浅いエンジニアと同等の生産性しかだせないとしたらどうでしょうか。ツールが自由に使えるならば3日で問題が解決するにもかかわらず、ツールが自由に使えないがために最低2週間は問題の解決に時間を要するとしたらどうでしょうか。より安く、より速く問題を解決してくれる海外に頼りたくなるのが自然な思考です。多くの場合、スポンサーが有用性を理解していないがために非科学的に禁止されたツールの利用禁止は、そろそろ日本のエンジニアが主体となって、利用を認めるよう主張を始めるべきだと思っています。とてもおとなしい、主張しないエンジニアの言い分はいままでも、これからも認められていかないでしょう。経営や運営の立場をもつ人々の視点からみれば、そもそもなぜ問題の解決に時間がかかるのか理由もわからないまま、（多くの場合精神的なセキュリティーを根拠として）ツールなんて無くてもよいと思われているにすぎず、エンジニア側の主張がそもそも足りないのだと思っています。

もの言うエンジニアを増やそうという、主張ではありませんが、科学的に有益なものはもっと主張して、自由に使えるような環境を獲得する。これが、この先10年〜20年先に日本のエンジニアが職を失わず、また国際競争力をもちつづけられるための必須条件ではないかと考えています。以上が、発表でのおおまかな主張でした。小手先のテクニックと比べれば、こうしたもっと土台となる問題が、少なくとも前職Sunにおいて見えてきた、エンジニアにとって一番の問題解決の障壁になっていることだと思っています。

JJUG CCC 2010 Springに来ています。先ほど発表しました資料を公開します。

来月12月11日(金)にJapan JavaFX User Groupの第二回勉強会が開催されます。

勉強会の後には忘年会もありますので、両方あるいはどちらか片方だけでも参加される方はぜひ参加登録サイトよりお申し込みください。僕はProject MaiTaiの紹介をする予定です。Ustreamによる中継も予定していますので、遠方あるいはご都合のあわない方はぜひそちらをご覧ください。URL等は後ほどご案内いたします。

Project MaiTaiのHudsonスナップショットからはダウンロードできませんでしたが、Kenaiのプロジェクトからソースをダウンロードしてビルドしてみました。なかなか面白いかもしれません。

まだ不安定なところもありますが、ムービーとして書き出しができるなど今後の展開に期待が持てます。

JavaFXで面白そうなプロジェクトがスタートしています。Josh MarinacciのProject MaiTai。櫻庭さんが紹介されているのでご存知のかたも多いかも。ただこのMai Tai。知ってる方はお分かりの通り、それなんてQuartz Composer？っていうぐらい見事にパクリ似ています。

こちらはProject MaiTaiの画面。ダウンロードできなかったのでプロジェクトページに載っているスクリーンショットから。

こちらがQuartz Composer。

先週の土曜日は日本Javaユーザグループ(JJUG)のJavaOne 2009報告会でした。今回は、ライトニングトークでしゃべらせていただきましたが、事前になかなか時間がとれず資料は当日つくることに・・。隣にaqubiさんがいらっしゃったのですが、資料作成にいっぱいいっぱいでaqubiさんを含め他の方ともあまりお話できませんでした・・。

丸山先生よりJavaOne全体の報告。SunはOracleに買収されてしまうこともあり、JavaOneは今年で最後ではないか(少なくともSunとしてのJavaOneは最後)という哀愁が語られました。

下道さん。JavaOneというよりは、同時に開催されたCommunityOneの報告。

クラウドのデモ。正直GUIはしょぼい気がしますが、本当に使えるようになったらおもしろそうです。それにしても、Sun神宮前オフィスの地下会議室はどうも電波の状況が良くないですね・・。Emobileもつながりません。

櫻庭さんより、JavaFXおよびJava SE 7について。いつも通り時間をかけて作られたことがよく分かるプレゼン。プレゼンソフトもJavaFXでかかれています。

木村さんよりJavaのエンタープライズ周りについて。

ライトニングトークです。去年に引き続きJavaOneに行かないままJavaOne報告をすることになったのですが、今年はAIR JavaOneと題してネット越しにJavaOneを楽しむ方法をご紹介しました。下記に参考URLをリストしておきます。

• 2009 JavaOne Conference Homepage – JavaOne公式サイト
• General Session Details and Video Plays – Generalセッションの録画
• JavaOne Online Technical Sessions – PDF化されたセッション資料。Hands On Labsの資料もあります。LTでも話しましたが、まとめてZIPでダウンロードするリンクがありますのでそちらをご活用ください。
• JavaPosse – 有名なPodcast

マイコミジャーナルに執筆されている杉山さん。プレスの立場での参加についてと、メディアのあり方について話されました。

技術評論社の馮(ふおん)さん。杉山さんと同様、プレスとしての参加について、メディアのあり方について。

続いて櫻庭さんより。今回のLTは固い内容が多かった、との話でした。櫻庭さんからはサンフランシスコ(というか海外に行くときの)での食事情改善方法について。ミシュランガイド、ぜんぜん使ったことありません。櫻庭さんが今回べた褒めされていたOpenTable。その日の予約を、Web上のみで完結できるというのがいいですね。ちなみに、OpenTableは日本版(東京)もあります。東京カレンダーとのコラボもしてるようです。

最後は太田さんよりCommunityOneスピーカーとして話された時のお話。

今年から日本Javaユーザグループ(JJUG)のスタッフになりました。あと、関わっているJava系のコミュニティー Glassfishユーザ・グループ・ジャパンと日本JavaFXユーザグループもCommunity of Communitiesに入れていただきました。

年末にドメインを取得してから放置したままだったjavafx.jpですが、ようやく始動しました。最初、Google Appsでコミュニケーションツールをそろえようかと思いましたが、結局メーリングリストの管理がさほど楽ではないので少なくともメーリングリストに関してはGoogle Groupsを使うことにしました。若干登録作業など一般利用者の敷居が高いような気がしますが、手動での作業が増えてしまうGoogle AppsはやめてGroupsでの運用にしました。その辺の準備もやや時間がかかりましたがそれよりも、今回はCMSを入れた上にデザインを一から作るというのに一番時間を費やしてしまいました。CMSにはWordPressを使っています。WordPressはブログエンジンですが、近代的なブログエンジンは簡単なCMSとしても使えますし、下手に高機能なCMSを使うより結果的にうまく運用できる印象があります。

午前中である程度形にしようと思っていたのに、結局10時間ぐらいかかりました。Illustrator CS4のクラッシュ2回、Fireworks CS3のクラッシュ1回も泣き所でした。今週のjavafx.jpに関する作業はこのあたりにしておきますが、次は内容の整備ですね。

円高だということもあって思い切ってFlickrExport for Apertureを買ったのはいいものの、品質が低すぎて正直返品したい。良くても100枚一度にアップロードできない。ネットワークが途中で切断されたりすると必ずクラッシュする。ひどいときにはたった5枚すらアップロードする前にクラッシュ。しかも、単にpluginがクラッシュするだけではなくてApertureを巻き込んでクラッシュするのでたちが悪い。Nikon D90を買ってから急激に写真の枚数が増えてきたので、安定したアップローダがやっぱりほしい。jUploadrが一番安定しているから1000枚単位の大量アップロードをするときにはまだこれを使っているけど、いくつか不満な点が。

その1。サムネイルを作る時間が長すぎるし、CPUを使いすぎる。jUploadrに写真をDrag & Dropすると写真のサムネイルを作って、その後、Photosetに入れたりするための操作ができるんですが、まずこのサムネイルを作るのにとても時間がかかる。1000枚単位の追加をするとCPUは20分ぐらい100%フル稼働でほかのことができない。そもそも、Apertureで整理した後なので、サムネイルを確認して一枚ずつ設定を変えることもないからサムネイル作成処理は僕にとって不要。ディレクトリ単位でアップロードの設定ができれば十分。個別にいじりたいときでもファイル名だけわかればとりあえずApertureで確認できるし、そのときに個別にサムネイルを作ってほしい。

その2。Photosetsへの写真追加に失敗することがある。今まで試した、FlickrExport for Aperture、1001、jUploadr、Flickr Uploadr 2.x/3.xのいずれでも、あらかじめ設定しておいたとおりに写真がPhotosetsに追加されずに全部の処理が完了されましたと表示されてしまうことがあって、結局あとからもう一度手動でOrganizerを使って整理するのが必須でした。1000枚単位の写真をWeb画面で整理し出すと大変なので、このあたりの処理が確実に実行されるか、再試行について詳しく設定できるようにしてほしい。

その3。未現像のRAW画像について設定ができない。これは仕組み上しょうがないんだけど、Apertureなどのような現像ソフトを使っている場合、RAW画像はAperture上で管理されていて、JPEGに書き出したファイルについてようやくjUploadrがファイルとして認識して、アップロードのタスクとして追加される。RAW現像にかかる時間もなかなか侮れなくて1000枚単位だと20分ぐらいはかかるし、いちいちRAW現像処理が終わったことを目視確認してからjUploadrにかけるなんてやってると、面倒くさい。なので、できればApertureなどであらかじめ指定したディレクトリにRAW現像するようにして、現像が終わったJPEGファイルからディレクトリに対して設定されたメタデータを元に随時アップロードするようにしてほしい。またアップロードができたJPEGファイルが完了後に自動削除されるオプションがあるとよりうれしい。

そんなこんなで前々から作ろうと思っていたFlickrへのバッチアップローダを作り始めました。Flickr APIは認証周りの実装が面倒くさいので敬遠していました。どうせ作るなら安定して使えるJavaで実装したいのだけど、JavaのFlickr APIライブラリは古かったりアップロードAPIが実装されていなかったりするのも今まで着手していなかった理由の一つ。でも今回は、今実家にいてすることがないので、がっつりと時間を使って実装に集中することができ、とりあえず認証まわりとアップロードまでのライブラリが作りあがりました。次は、UIとアップロード順序の管理をするあたりを作ります。アプリケーションの名前はj20000という名前にしました。