ごきげんうるわしゅう。NY 滞在が、6月半ばまで延長が決まって、げんなりの sabro です。

さて、いつのまにか、Pebble2.1 が、リリースされていたようです。こちらでは、試す環境がないので、開発者ブログを読んで調べたもののうち、気になる変更点をいくつかあげておきます。

• 複数ファイル同時アップロード対応
• Ajax への対応強化
• about プロパティ（多分、自己紹介ページのようなもの？）追加
• サイドバーにフィードリーダー機能を追加

主に見栄えに関わる変更点を挙げましたが、他にも、管理者向けの小さな機能向上が多い印象を受けました。

私は、デザインも変えたばかりであるし、今回は移行を見送ろうかと考えていますが、試した人がいたら、感想を教えてくださると助かります (^^)

今、担当している Java Swing 案件のフレームワークは、ある意味すごい。○○Frame や、○○Button （○○は会社名略称）のように、Swing の全てのコンポーネントを、ラップしている。また、Swing にとどまらず、○○List や ○○Map 等の、コレクションフレームワークラッパーまである。ありとあらゆる標準 API をラップしているのだ。

ただ、自分は、以下の理由で、このフレームワークはダメだと感じる。

1. 学習のコスト
2. 費用対効果

ラッパーの作成は、継承または委譲で実装されているが、委譲に関しては面倒だったのか、全てのメソッド、フィールドが委譲されてないケースがあった。これでは、Java 標準 API に精通した熟練者であろうと、このフレームワークを使用する場合には、新たな学習をする必要がある。さらに、学習をしても、企業や部署が変わると、使用できないので、モチベーションが上がりにくい。

また、このフレームワークは、かなり多くのクラスをラップしているので、フレームワーク自体の開発コストは、そうとうなものだったと思われる。しかし、それだけの苦労に相当する効果が出ているかというと、とても、そうは感じられない。膨大なクラスのフレームワークは、学習するだけで膨大なコストがかかり、初めて使用した際は、工数が膨れ上がる。では、2回目以降の開発では、楽が出来るのかというと、JDKのバージョンも、そろそろ上げないといけないし、これからの案件では、このフレームワークは使われないという。

Effective Java 等の書籍を読めば分かるように、標準 APIというのは、非常に洗練されている。Jakarta Commons のように、大規模な開発を行い、さらにオープンにして、あらゆる企業で使用可能とするならともかく、一介の技術者が、その全てを改良してやろうと考えるのは、傲慢ではないだろうか。

一般開発者にとって優しいフレームワークとは、独自の作りこみを減らし、標準 API を積極的に利用して作成されたものなのだろう。フレームワーク開発者は、フレームワークを作って、一般開発者をそれに従わせるより、標準 API を利用してもらうための、Java レクチャードキュメントを用意するべきだ。

フレームワークという言葉には、ある種、華があるが、フレームワーク開発者という立場から一歩視点を広げ、ソフトウェア基盤技術者として、一般開発者の作業を楽にする方法を真摯に考えていくことが重要なのではないだろうか。

NY から、こんにちは。

観光気分でやってきた NY の現場は、超修羅場でしたとさ orz
（なぜ、NY にいるのかは、こちらを参照。）

話は、変わりますが、Java One で、JavaFX が発表されましたね。

Silverlight、WPF、Flex、Apollo の台頭にみる今後のソフトウェア開発の方向性のエントリを書いていたとき、この波に乗れなかったら、Java は生き残っていけるのかと考えていました。しかし、このタイミングで、このようなRIAプラットフォームを発表するのは、流石です。

これらの技術のうち、どれを選択していくのか・・・。アーキテクト冥利に尽きる命題ですね。

タイトルにある、4製品は、どれも最近台頭してきた、ソフトウェア開発環境であるが、これらには、共通点がある。

これらは、すべて、デザインに重きがおかれているのだ。

Silverlight、WPF は、マイクロソフトの製品、Flex、Apollo は、Adobe の製品であるが、これら2社は、これからのソフトウェア開発では、デザインが重視されていくと予測しているのであろう。

では、なぜ、これら2社は、デザインの波が来ると考えているのか。

それは、ある程度、ソフトウェア業界というものが成熟したからではないだろうか。これは、持論だが、「成熟した業界は、デザインでの差別化が重要となるの法則」というのがあるように思う。

例えば、自動車の開発なども、最初は、とりあえず走る車の製造から始まり、クーラーやCDプレーヤ等、機能の追加で差別化が計られてきた。しかし、自動車という製品が、ある程度成熟し、機能差が付けにくくなった時、デザインやブランドによる差別化に重きが置かれるようになった。

Web 業界は、Yahoo による、Web1.0 から始まり、最近になって、ユーザ参加、集合知などを駆使した、Web2.0 による機能的革新が起こった。しかし、Web2.0 企業の躍進のスピードは、一時期に比べて停滞しているように思える。今が、デザイン重視への転換期にあるのではないか。Web2.0 的デザインが流行ったのも、この大きな転換の合図だったに違いない。

Web2.0 的デザインといっても、これまでは、画像等を綺麗に作って、CSSでレイアウトしてというレベルのものだった。だが、これからは、Silverlight でムービーを流したり、Flex で、エフェクトをかけたりといったサイトが当たり前のように出て来るだろう。もちろん、デスクトップアプリケーションも、WPF や Apollo によって、同じように生まれ変わるはずだ。

今、プログラマやアーキテクトをしている人は、デザインの技術を高めておくと、大きな武器になるだろう。これから、デザインが流行るというのは、2つの大企業の、お墨付きであるのだから。

Pebble には、せっかくタグがあるのに、いまいちカテゴリとの使い分けが、うまくいってなかったので、いろいろ弄ってみました。

具体的に行った作業は以下。

• カテゴリの分類で、細かすぎるものは削除して、汎用的なカテゴリのみにする
• その他カテゴリの件数が、多かったので、Tips、Tool カテゴリを新たに作って移動させた

後者は、サイトを訪れた人が、記事を見つけやすくするための修正です。「その他」なんていうカテゴリでは、せっかくいい Tips があっても、見てもらえないですから。

前者ですが、カテゴリには、なるべく汎用的なものを、少量作成し、ある程度まとめて、記事を読みたい人に使ってもらえるようにしました。逆にタグは、とにかく、細かく付けて、ピンポイントで検索したい人に使ってもらうといった感じです。

ブログは、時間をもてあましている人、目当ての記事を即読みたい人等、いろいろな人が、見に来るわけで、目的によって、カテゴリとタグを、使い分けられるようにしておくのがいいんじゃないかと考えました。

ホントは、NetBeans、JSF、tomcat あたりも、Java カテゴリに入れようかと思ったのですが、今後、増えそうな気もするので、保留しておきます。

ブログに画像をアップロードする際、参照ダイアログから選択するのが、メンドイなと、思っていたのですが、dragdropupload という、FireFox の拡張を使えば、ドラッグ＆ドロップで、パスを入力できるそうです。

さらに、複数ファイルをドロップすれば、まとめてアップロードできるようなのですが、そのためには、ファイル選択コントロールが、元々ページ内に複数設置してある必要があるとのこと。実に惜しいです。