2009/01/18

フォルダ管理

超「超整理法」を読んで、「分類するな検索せよ」というフレーズには感銘を受けたのだけど、一つだけフォルダによる整理の利点があると思う。

それは、関連性を保存できるということ。

その作業をしていたときに使った資料や、作業途中の経過、メモ、その他もろもろ、1つのフォルダに保存できる。

今、個人的に使っている方法なのだけど、プロジェクトのフォルダを作って、その中に作業日と作業内容を書いたフォルダを作り、その日に使った必要なファイルを全てその中にいれる

C:. ├─20090116_試験パターン1 └─20090117_Rel1.2リリース

こうすることによって、その日に何の作業をしていたか、何を参照して、何を保存したかが時系列にならぶ。超整理術の押し出しファイルとまったく同じことを紙のファイルではなく、PC上でフォルダ化しているのだ。

この利点は、上にも書いたとおり、その日に何をしていたかという状態に関連付けられた資料一式を保存できること。Web検索、グーグルデスクトップ検索だけだと、個々のファイルは見つかるが、状態を保存できないのが不便だと思う。

状態はその情報を利用する人それぞれで異なるのだから、ファイルにもつべきものではなく外で管理するべきものだから当然なのだけど。プロジェクトでは、みんなで共有すべき状態もある。VersionControlシステムではタグやブランチでやっているようなものだ。それらの状態の共有も必要で、それにはフォルダという構成がわかりやすいと思う。

欠点もある。原本を何度もコピーすることでファイルが分散してしまい、版管理で誤りやすいこと。ローカルディスクだとディスクサイズを食いすぎること。シンボリックリンク的なものがあるといいんだけど、Windowsのショートカットは使いにくい。また、日付をまたいだりプロジェクトを横断するような状態では、やはり「こうもり問題」が発生する。

ということで、個人的に今後のファイルシステムに期待することは、以下のポイントだ。

  • 情報の検索性:グーグルデスクトップのような、アプリケーションをまたいだ全文検索
    特にメールとWebと普通のファイルの統合。メールはMUAで、Webの文書はお気に入りで、普通のファイルはローカルでというのは面倒だ。全てを一元管理したい。どれも保存してローカルのフォルダにおくことはできるけど、もっと楽に関連する情報を一覧したい。
    デスクトップも、アプリ志向ではなくデータ志向で。
  • 状態の保存:全ての情報を統合できるスマートフォルダのようならラベリングの仕組み
    上で書いた、その日に何をやっていたかを保存し、それによってデータをまとめ、検索できる仕組み。
    あらかじめ複数のファイル(しかもある時点の版)を串刺しにしておき取り出せるようにしておく必要がある。この串刺しの単位が重要な場合がある。
  • バージョン管理:原本は一元管理され、バージョニングする仕組み。
    スマートフォルダに必要なファイルをかき集めて、変更すると自動でバージョニングして欲しい。
    変更したファイルはTortoiseみたいに変更履歴の表示や、変更のログをとって欲しい。
  • 組織をまたいだ共有とセキュリティ:せっかくこれらのことができても、他の組織(協力会社や発注先)とのファイルの共有が面倒だ。いまだにメールを分割して、暗号化して送信とかナンセンスだ。

タグ付け(ラベル付け)は、フォルダ名とかファイル名で暗黙でやっていることだ。コンピュータがセマンティクスを解釈できなくても、タグとしてコンテキストをつけてやって、それを人間が検索できるようにするだけでも、大分楽になるはず。そのための仕組みが欲しい。そうすればそのうちセマンティックWebで必要なタグはそろってくるんじゃないかなぁ。

どうもこういうのはOSに組み込んでくれないと、追加のソフトは入れられないとか、信用ならないとか、使ってくれないんだよねぇ。そしてみんなで使わないとこういうのは意味がない。

まさしく、超整理法でみんなPDFで送ってくれればいいのに状態だ。

企業用にそういう機能の方面を強化してくれないかなぁ。Windowsも個別で強化ではなくインフラとしてやってもらいたいものだ。MacもGoogleは使わせてもらえないのに、Windowsだけはよくわからないけど信じる会社は多いのだから。

そのブランド力?ごめんなさい力?Windowsじゃあしょうがない力?を振るえる絶好の場所だと思うんだけど。

2009/01/06

Anchor

ここ2,3日ほどGWTを使ってみたが、やっぱりレイアウトがめんどくさい。

なにがめんどくさいってパネルが生成するTableレイアウトとか、思うようにレイアウトできない。

昔のSwingのいやなレイアウトのメンドクサさから抜け出せていない。

SwingでGUIを手で組むメンドクサさ、LayoutManagerの組み合わせでうわーとかから変わってない。

ところで、Google Calendarのコンテンツ描画領域はどうやってるかFirebugsで追ってみたら、どうも動的にHeightの値を設定していたりしている。Windowのリサイズにあわせて描画してるっぽい。

うーん、Anchorが欲しい。

Borlandは偉大だなぁ。C#のGUIビルダのようにさくっと作る方法はないものか。

2009/01/03

なぜJavaScriptなのか

GWTのデモを作ってみて、ドキュメントをさらっと読んで、さて、作ってみるかと始めてみたものの。。。Gregorian Calendarがない。

java.utilはそろってるかと思ったら、うーん意外と基本的なクラスがないんだなぁ。MIDPで書いているような感じだ。

というか何でJavaで書いて、JavaScriptコンパイラなんだ!

ブラウザにのっける言語を間違ってるんだ。ブラウザに載ってるのがJavaScriptじゃなくて、CLRとかJVM的なバイトコードを解釈できれば、Rubyとかマルチ言語でかけるようになるじゃないか。

ECMAとかScript言語の仕様決めてる場合じゃなくて、統合バイトコードを決めてサンプル実装作って全ブラウザに載せればみんな幸せだよ!

それなんてJavaApplet

あぁ、ほんとなんでHTMLで書いてるんだろうなぁ。つかなんでWebなんだろうなぁ

ClickOnce、WebStart、AIR、SilverlightとかとかRIA環境は出揃ってきた。

Webの利点であった、クライアントソフトの一括管理、バージョニングはもうC/Sでできるよね?

Stateless通信はめんどくさいのに、なぜ普通のSocketじゃなくてHTTPでCommetなんてやってるんだっけ?

セキュリティ?リバースプロキシとか変わらないんじゃない?

なんかエコみたいなマッチポンプで首絞めながら進歩(?)しているような気がしてきた。

今思うとNCとか、リソースの都合上、時期尚早すぎた技術が多すぎたのだろうか。なんか昔ダメだったから嫌われた技術が多い気もする。

それとも単にプロプライエタリが嫌いが理由なんだろうか?

みたいなことを考えてしまった。

さて、コードに戻ろうか。

#でも、GWTはJavaでGUIのパラダイムでかけるので楽しいね。

2009/01/02

GWTのメモ

Google Web Toolkitを勉強中

Javaとの違いの部分をちょっとメモ。いつの間にかMacOSXもサポートしてた。でもSafari3が必須らしい。

メールアプリのデモがかっこいい。

言語

Java5以降の文法をサポート。GWT1.5ではGenericsが使えます。

  • 型:プリミティブ(boolean, byte, char, short, int, long, float, double)、Object, String, 配列、ユーザ定義クラスが全て使えます。
    • JavaScriptにおいてnumber型は64bit浮動小数点のみです。
    • そのため、long以外の数値プリミティブは、Webモードにおいてdoubleとして扱われます。
    • longについて
      • JavaScriptは64bit整数をもっていません。そのため、32bit整数のペアでエミュレートしています。
      • longの多用はパフォーマンスに影響があります。
      • longはJSNIで使用できません。
  • 例外:try, catch, finalyが通常どおり使えます。
    • ただし、Throwable.getStackTraceはWebモードでサポートされません。
    • NullPointerException、StackOverflowError、OutOfMemoryErrorなどいくつかの例外はWebモードでは発生しません。
      • その代わり、JavaScriptExceptionが生成されます。
      • これはJavaScriptの例外が正しくJavaの例外へマッピングできないためです。
  • アサーション
    • assert文はHostモードで常に有効です。
    • GWTコンパイラはすべてのアサーションを取り除きます。
  • マルチスレッドと同期
    • JavaScriptはシングルスレッドであり、マルチスレッドをサポートしていないので、以下のものは使えません
      • synchronizedキーワード
      • Object.wait()
      • Object.notify()
      • Object.notifyAll()
  • リフレクション
    • 効率化のため、GWTはJavaソースを単一のスクリプトにコンパイルし、クラスの動的ロードをサポートしません。
    • 最適化のためリフレクションはサポートしません。
    • ただし、オブジェクトのクラス名を取得するため、Object.getClass().getName()は使えます。
  • ファイナライズ
    • JavaScriptではガベージコレクション時のFinalizeをサポートしていません。
    • そのため、JavaのFinalizerはWebモードで使えません。
  • 厳密浮動小数
    • Java言語仕様ではstrictfpキーワードで厳密浮動小数が使えますが、GWTではサポートしません。

ライブラリ

Java2SEとEEの小さなサブセットクラスを提供します。

  • いくつかのパッケージとクラスのみ使えます。
    • java.lang
    • java.lang.annotation
    • java.util
    • java.io
    • java.sql
  • Listとかも使えます。
  • 加えて、GWTのAPIがあります。
    • 直接提供すると高価すぎる機能を似た機能として提供しています
    • java.util.DataTimeFormat → com.google.gwt.i18n.client.DateTimeFormat
    • java.util.NumberFormat → com.google.gwt.i18n.client.NumberFormat
    • java.io.Serializable → com.google.gwt.user.client.rpc
    • java.util.Timer → com.google.gwt.user.client.Timer
    • その他もろもろ。
  • 一部のライブラリの挙動の違い
    • 正規表現:JavaとJavaScriptの正規表現はにていますが一致していません。
      そのため、正規表現の意味がJavaScriptと同じか注意してください。
    • シリアライズ:Java標準をサポートしません。
      • JavaのシリアライズはJavaScriptにコンパイルされたときにいくつか使えない機能を使用しています。
      • 動的クラスロード
      • リフレクション
      • その代わり別のシリアライズの方法が用意されています。

2009/01/01

WebとGUI

最近Google Calendar的なWebアプリケーションを書いているが、Ajaxというのは開発が面倒だ。

なぜ、こんなに面倒なのかを考えていたのだけど、GUIアプリケーションを書くパラダイムになっていないからだと思い至った。

GoogleCalendarのようなWebアプリケーションは、Webではなく、GUIアプリケーションなのだ。

設計はどちらも同じMVCを用いるのだが、Webアプリケーションの場合、難点が2つある。

  • 1つはプレゼンテーション層が貧弱であること。
  • 2つ目はController層がサーバサイドにあること。

まず1つ目の問題点はプレゼンテーション層の貧弱さである。

そもそもHTMLというのは文章を表現するためのものであって、アプリケーション向きではない。そこにJavaScriptという言語で動的にしたもののあくまで文書なのだ。

貧弱とはいえ、タブを作ったり、カレンダーを作ったり、CSSとJSでがりがり書くことはできる。これによってだいぶリッチなものになってきた。

しかし、Webを意識しすぎたつくりになってしまうことが多い。Webということを忘れて、GUIアプリケーションのコンポーネントを作るという感じで書くべきだと思う。

コンポーネントとして用意しプロパティやイベントをハンドルできるObserverを登録メソッドを提供する。GUIビルダが提供するようなイメージだ。

標準化されたコンポーネントの形がないのが問題だと思う。

2つ目の問題はコントローラ層がサーバサイドにあることだ。

GUIプログラミングの場合、一般的にはイベントドリブンを用いる。 例えば、ボタンが押されたというイベントに応じてデータ処理など何らかの動作を行う。

イベントハンドリングは本来Controllerで行うが、Controller層がサーバサイドにあることにより、非常に扱いにくいものになっている。

JSFやASP等イベントドリブンを提供するWebフレームワークもあるが、あくまでControllerはサーバ側にある。

サーバ側にあることで、次のような問題点がある。

  • いちいちサーバへイベントを送らなければならないため、レスポンスが遅い。
    →AJAXで一部解消
  • クライアントだけで処理する変更をハンドリングできないため、処理が分散する。
    AJAXでサーバへのイベント送信を非同期にできるようになったが、Viewの更新が面倒すぎる。
    ページ上の複数コンポーネントを処理するのが煩雑である。

プレゼンテーションの貧弱さの原因の一つが、このクライアント側コントローラがないこと、そしてコントローラを作りにくいことにあると考えられる。

Railsやその他のフレームワークで大分Webアプリケーションが作りやすくなったとはいえ、プレゼンテーションがいまだにJSPライクなHTML埋め込みスクリプトなので、いまだに古典Webを抜けられていない。

我々が書いているのはもはや単なるHTMLベースのWebではない。我々が書いているのはGUIアプリケーションなんだ、という意識で書いてみたらどうだろう。

ということで、HTML版AIR見たいな形で統合されたプレゼンテーションとコントローラを提供してくれるWebのフレームワークが欲しいなと思いました。

もうコントローラはクライアント側でよくね?Webの先はストレージだけでよくね?と思うんだけど。

どうも古きよきWebをいじるためのフレームワークはあるけど、GUIのためのフレームワークってないんだよね。(いいのがあったら教えてください。)

いや、みんな気付いててRIAなんだろうけど。 何でHTML大好きなんだろう。

GWTとかEclipseとか、使ってみようかなぁ。