Cubbyのルーティングの問題点
Cubbyのルーティング（URLとActionのマッチング）は非常に柔軟で、下記の様にした場合は /hoge/fuga で HogeAction#fuga が呼び出される。
@Path("hoge")
public class HogeAction extends Action {
@Path("fuga")
public ActionResult fuga() throws Exception {
}
}
じゃあ、Amazonの商品ページのようにURLエンコーディングされたURLはどうなるかな？と思ってやってみたらうまくいかなかった。
調べてみるとCubbyのPathアノテーションはデフォルトで正規表現 [a-zA-Z0-9]+ でマッチングされているらしい。
ということはURLエンコーディングに合わせた正規表現にすればいいのかと思ってパーセントエンコーディングにマッチする正規表現を書いてみたが、これまたうまくいかなかった。
悩んでCubbyのソースを読んでみたら、マッチングはデコードしたURIに対して行われることが判明した。なるほど。
で、ここからが本題。ルーティング関連のソースを読んで気がついた点があった。
CubbyはPathResolverImpl#getInternalForwardInfoで独自のエンコーディングでURIのデコードを行っている。これはコンテナで指定されているURIエンコーディングと一致しなかった場合に問題になりそうな感じ。
これ→http://sastruts.seasar.org/fileReference.html#server
RouterImpl#routingの中のCubbyUtils#getPathで返すパスは、HttpServletRequest#getPathInfoの値とほぼ同じ値（こっちはコンテナでURIデコードされる）だと思うので、この値を使えば独自にデコードする必要もなくなって、いい感じじゃないかと思う。（デコードしないURIを使用していることに意図がなければ）
どうでしょうか中の人？
次世代Webアプリケーション基盤技術
Aerial（エアリアル） - Ajax/Cometの次を行く リアルタイム双方向RPC - Blog by Sadayuki Furuhashi
Comet/Ajaxの上を行く技術 - Blog by Sadayuki Furuhashi
これは本当に非常に素晴らしい。
ただ、Flash・サーバ間の通信がHTTPじゃなく、Socket(独自プロトコル over TCP)なのが最大の欠点になってしまうと思う。
似たことが出来るAdobeのBlazeDSの最大の利点はやっぱりHTTPで通信してるところなんだと思うし。
このエントリの通りFlex3でExternal Interface使ってフレームワークとして整えてあげればHTTP版Aerialが完成なんじゃなかろうか。
もしくはサーバをCometにして、Flash側でそれをうまいことラッピングしてプロトコル意識させないようにするとか。
確かにBlazeDSを使った方がパフォーマンスは良いと思います。ただBlazeDSはサーバー側がJavaなので、インストールとプログラミングで、LLと比べて取っつきにくい感があります。サーバー側の実装コストが高い。
2008-05-04
「取っつきにくさ」はすごく重要だと思っていて、Tomcatだ、コンパイルが必須だと言われると、やる気が削がれてしまうように思います。やる気で駆動しているオープンソース開発者には致命的な問題だと思います。オープンソース開発者はアテにしていないと言われればそれまでですが (^_^;
Javaの敷居が高いのはごもっとも。
ただ、Seasar2って日本発のオープンソースフレームワークがありまして、それを使えばJavaでのプログラミングは非常に楽になりますよ。
これからの知的生産とは
情報の「肝」を書き出す
- グーグルが扱う情報の単位、つまり記事、ウェブサイト、論文といった単位よりも、粒度の高いレベルでの情報整理を、情報処理の時点で行っておく
- 情報全体をそのまま保存するのではなく、元の情報を凝縮したものを書き出す。要約でもいいが、その文章の「肝」だと感じた箇所を抜き書きする
- 凝縮した内容を「書き出す」という点が重要
- 情報の「肝」を書き出すという、より粒度の高い、きめ細かな整理を行うことで、整理の段階から知的生産を始めることができる
- 情報を整理し、それを元に知的生産を行う、と分けて考えがちだが、単純な整理はグーグルが担ってくれる
「肝」を抽出する方法
- 本を読むときに欠かさないのは、読んでいて気になったページの上端を折ること
- 線まで引くと思考が途切れるので、読書中は上端を折るだけ
- 読み終わると、折り目のついたページだけを再読し、「肝」をさらに選別して、特に心に残った箇所だけを書き込む
時間の勝負
- これからの時代、知的活動において、時間がない人こそが圧倒的な敗者になる
- ウェブの力により、誰もが無料で多くのことを勉強できるようになってきたから
- 時間が自由に使える状態にあれば、それはとても大きなアドバンテージになる
- じっくり考える時間が持てずに、本当に知的活動ができているのか、真摯に考える必要がある
グーグルという「知的エンジン」
- 何事についても、考えるときの軸はまず時間。自分の時間をいかにたくさん生み出すか。そればかり考えている。
- そのための核が、情報を選択・抽出するためのミクロな技術で、一方ではなすべきことかを判断する俯瞰的な、マクロな技術
- これらのグーグルが担わない技術を確立している人が、グーグルに淘汰されず、本当に使いこなせるし、その登場に興奮できる
グーグルに淘汰されない知的生産術 - My Life Between Silicon Valley and Japan万人に開かれた時代
- 本を読むだけで終わるなら、それは知的消費であり、感想文を書くなりして初めて知的生産になる
- 次の選択肢は、書いたものをオープンに
- すると今度はあなたと関心や志向性の近い人たちとの結びつきが生まれ、新たな知の創造へと繋がる
僕はグーグル以前から、そういった技を身に付けてきたつもりです。だから、旧来の整理が必要なくなり、知的生産の始まりとしての整理に集中できるようになったことで、自分の力が急激に増幅され、知的生産の効率が飛躍的に高まりました。グーグルが僕にエンジンをつけてくれたような感動があります。その結果、僕は『ウェブ進化論』のような本を書けた。僕は最近寿命が延びたような感じさえするんですよ。効率がよくなって時間がますます凝縮されたから、でしょうね。
グーグルに淘汰されない知的生産術 - My Life Between Silicon Valley and Japan
自分の場合、情報収集にRSSリーダとソーシャルブックマークを使うようになって「力が急激に増幅される」感覚を覚えた。大袈裟じゃなく情報収集能力が１００倍になったと感じるくらい。
で、今までは情報収集っていうインプットばかりだったから今後は、知的生産というアウトプットも少しづつやっていけたらって思ってます。まずは、自分自身の思考の整理（まとめ）から。
重要なのは他人には出来ないことや、他人がやっていない知的生産だよね。
