« April 2004 | Main | June 2004 »

2004.05.21

IPv6 と XQuery の本

不勉強がばれて XQuery の話 にコメントを付けられてしまいました。のでとりあえずもうちょっとちゃんと勉強することに。
XQuery 本はいくつか出ているようだけど、評判が一番よさそうな Xquery: The Xml Query Language (洋書) を注文。読んだらまた感想書きます。
前に書いた「数冊読んだ IPv6」ですが、IPv6―次世代インターネット・プロトコル はちょっと発刊も古く、読み物としては面白いけど、という話。
ちゃんと勉強するなら IPv6エッセンシャルズ の方が良いです。いわゆるネットワーク本なので気合は必要ですが、幅広く網羅していて、かなり新しい話にも付いていっている。関連技術を一通り網羅して概説が付いているので、例えばトンネリング技術っていっぱいあるけどどこから調べ始めよう、みたいな時に便利。IPv6 の参考書みたいな感じ。

| | Comments (7) | TrackBack (0)

2004.05.19

XML, XPath, XSLT, XQuery...

Microsoft の WebData チーム XML Lead Program Manager の Mark Fussell.NET Framework 2.0 の XML において XPath 2.0/XSLT 2.0 のサポートを行わないことを表明した ことがちょっとした波紋を呼んでいる。
XSLT 2.0XQuery 1.0 は、8割方同じことをするために2つの流派がそれぞれの仕様を定めたようなものだ。そしてそのどちらがより優れているかは、人によって意見を異にするかもしれないが私は XQuery だと思っている。
XSLT は今日現在ほかによい代替技術がなく、ほとんどの PC に入っていることから実際に私も使っている。どちらかというとかなりヘビーに使っている。しかし XSLT にあまり将来は見えない。Mark と同じチームの Arpan Desai述べている が、XSLT には 2 つの大きな問題がある。


  1. パラダイムとして LISP 系などに見られる関数型言語を基にしている点

  2. 型がない点

特に 1 はその本質にかかわる問題で、正直なぜ W3C が普及を目指す言語パラダイムとして関数型言語を採用したのかは大いなる疑問だ。世の 99.99% の人に使ってもらわなくてもいい、と最初から宣言しているようなものだ。
型についてはいろいろな意見もあるが、プロとしてある程度の規模のシステムを作る時、型のない言語はなるべく避けようと思っている。ほかに選択肢がない時には XSLT や JavaScript を使うが、効率や品質が落ちるのを覚悟の上で使うことになる。関数型言語をまじめに目指していればいらないのかもしれないが、その辺ですでにメインストリームやビジネス系での利用を念頭においていないとしか思えない。
XSLT 2.0 はその本質をそのままに、まっすぐの方向で強化している。競合がいなかった時代ならいざ知らず、若干とはいえ関数型言語にバイアスし、強い型を持つ XQuery が登場した後となっては、いささか厳しいものを感じる。
その点ではマイクロソフトの判断は正しいように思えるが、いかんせん予測を裏切り、良いと思ったものが普及しない世の中で、大胆な決断をしたなぁ、とは思う。XQuery 1.0 では XSLT 2.0 の完全な置き換えはまだ難しく、また XQuery にも政治的な問題点は多く残っている。外れれば、進歩の速い XML 分野で追いつくのにしばらくかかるだろう。
判断が付きにくい時、決断者が決断できず、コストをかけてしまうことで解決することが多いことを考えれば、マイクロソフトほどの大きな会社でこの決断は小気味良く思える。
今日現在では XSLT 2.0 も XQuery 1.0 も実装がない。来年にはいろいろ出てくるだろう。それまでは使いづらい XSLT 1.0 で我慢しながら、楽しみに見ていることとしよう。

| | Comments (302) | TrackBack (1)

2004.05.16

「頑張りすぎる人」が会社をダメにする―部下を無責任にしてしまう上司の法則―

トップダウン型、ヒーロー型のリーダーシップの限界が指摘され始めてからコーチングが注目されているが、どうにも「笑顔を絶やさず」といったレベルの細かい手法の話に陥りがちであまり琴線に触れてこなかった。が、久しぶりのヒットに出会ったのでちょっとオフトピック。
ロジャー・マーティンの 「頑張りすぎる人」が会社をダメにする―部下を無責任にしてしまう上司の法則―。私はわりとそういう上司だったりするので、恥ずかしい話だが、マネージメントには少し苦手感を持っている。この本は、そういう人にも、またそういう上司に出会ってしまった人にも勧めたい。
「責任量保存の法則」というのが出てくる。いわゆる熱力学の法則のように、片方が責任範囲を増やすと、もう片方は減らす方向に働き、合計の責任量が同じになる、という主張。危機に際して自分で取ってしまうと、相手は引いてしまう。これは関係の問題で、放置しておくとお互いに不幸になるが、適正量に戻すにはお互いの努力が必要で、どちらからでも切り出すことができる、という理論を展開し、そのために有効となるツールや手法を紹介している。
ちょっとボリュームがあるかもしれないが、例を多く引き、共感を覚えられる形にして、仕事上の関係を中心にしながら、この問題はリーダーシップとフォロワーシップが存在するところには必ず起きうるので、個人関係にもありうる、という話まで触れている。
仕事を数年していれば、「ああ、この人はコントロールしたがっているな」と思って手を引くケースがあると思う。その相手は上司だったり、取引先だったりする。その時に少し工夫することで、自分がもっと貢献できることがある。身につまされる話も多いが、同時に次はもっとうまくやれそうだと感じさせてくれる本だ。

| | Comments (0) | TrackBack (1)

2004.05.15

IPv6 続き

IPv6 本を続けて読んでいる。最初のは IPv6―次世代インターネット・プロトコル。出版が 1996 年と古く、内容も古い部分があるが、軽く読める。技術的内容も多いが、著者クリスチャン・ウイテマの熱意的な部分を感じるためだろうか。
結論がまた感慨深い。「負け惜しみ組は、IPv6 には飴が足りないというだけでなく、鞭も足りないという」と言いつつ反論するわけだが、やっぱり現実はそうなんだと思う。IPv6 にネガティブな感情をあまり持っていないつもりだが、学ぶほどに移行する理由が見えない。もうちょっと勉強すれば見えてくるのかと思いつつ勉強を続けているわけだが、まだ見えない。
IPv6 のメリットの 1 つに Plug-n-Play がある。冷蔵庫に IP アドレスを割り振る時、誰も DHCP を使いたくないだろう、という問題。で、ホームゲートウェイとかって議論が一時期あったわけだが、ADSL 普及がここまで進んだ現在、すべての ADSL ルータは DHCP を持っている。IPv6 組は、当初は必要だったかもしれないけど、今の時勢で考えれば要らないくなったものを整理するべき時期なのかもしれない。
NAT の善悪もよくわからない。1996 年には、NAT は厄介者だったのだと思う。グローバル IP アドレスという概念から考えると、IPv4 のアドレス空間は枯渇する。しかしグローバル IP アドレスは国民総背番号制のようなもので、すべてにユニークな ID を振りさえすれば解決する、という、IPv4 の延長線上の考え方に見える。対して NAT は、それぞれの空間内で独立管理している、村ごとの番号体系じゃないだろうか。村ごとの番号体系に問題があった時、世界番号体系に移行すればいいのか、村ごとの番号体系の連携方法を定めればいいのかは、出発点が大きく違う。セキュリティをほとんど気にしなかった 1996 年には、世界番号体系が魅力的に映ったかもしれない。管理する側には、管理しやすいモデルが魅力的に見えるものだ。
NAT は、出て行く通信に関して村の連携を定めて動作している。外から入ってくる通信に関しては動作しない。しかし世界番号体系を使っても、ファイアウォールがある限りやっぱり動作しない。ファイアウォールが大企業にしかなかった 1996 年と、すべての Windows XP SP2 に装備され、PC 単位でもファイアウォールがデフォルトでオンになる世界では、必要な技術が違うように思える。必要な技術は、2 つのネットワークを安全に分離しつつ、必要な通信を行える技術ではないだろうか。そしてそれができて、国や ISP がそれぞれ分散管理する、DNS のようなシステムの方が、セキュリティやプライバシーの重要度が高い現在の時流には合っている気がする。
IPv4 と IPv6 はいわゆるよくある「改良対作り直し」議論なのだと思う。既存のシステムに問題が出た時、作り直したいという感情は必ず起こる。しかし作り直しにコストや時間がかかる場合、作り直しが終わる前に改良で済んでしまう。それを長い間繰り返し、どこかで緩やかに作り直し側に遷移する場合もあるし、改良組が結局残る場合もある。
作り直し組の IPv6 がどうなるかはわからない。しかし、その結論はまだでない気がする。こういう議論には、結論が出る時期というのがある。その時期は後から見れば分かるが、前もってはなかなか分からない。近づいてくると予感のようなものがあることもある。しかし IPv6 に関してはまだ予感を感じない。まだ時期じゃないんだなぁ、という気がする。
Windows "Cairo" は作り直そうとして消えてしまったが、Windows XP は Windows 95/98/Me を後継した。IPv6 は、Cairo なんだろうか、XP なんだろうか。今はまだ分からない。そういう面白い時期にこの業界にいることを幸運に思って、行く末を見て行きたい気がする。

| | Comments (0) | TrackBack (1)

2004.05.09

Lognhorn DWM

MSDN からダウンロードできる Longhorn M7.2 には DWM が入っているという話。
DWM (Desktop Window Manager) というのは PDC では DCE (Desktop Composition Engine) と呼ばれていた、画面上のウィンドウやコントロールを管理するモジュール。Avalon が GDI の置き換えなら、DWM は USER の置き換えと言える。
が、これはデフォルトでオフになっている。まだ buggy だし、パフォーマンスも悪い。オンにする方法は英語のサイトにはいくつかリークされている。

cd \windows\i386
sbctl start

見た目は大きく変わらないが、これで DWM を使った画面になる。ALT-TAB したりするとその効果が良く分かる・・・らしい。DWM の環境では、すべてのウィンドウがオフスクリーンバッファに描かれ、合成されて表示される。が、上のコマンドを入力した Virtual PC は 20 分間ディスクアクセスをしていてまだ戻ってこない。のでその間にこれを書いている、というわけだ。

| | Comments (12) | TrackBack (0)

Longhorn M7.2

WinHEC で公開された Longhorn M7.2 が MSDN でダウンロードを開始した。PDC 版よりいろいろ入っている模様で、ダウンロード中。
合わせて Reflector が 4.0 になり、Framework のバージョンを選ばなくなったので、より簡単に Longhorn や Whidbey で使えるようになった。Reflector はさらに Add-in をサポートしている。
先日書いた PINVOKE.NETVisual Studio.NET から使うための Add-In もリリース。Wiki & コミュニティパワーで、いつの間にかボリュームがすごくなっている。
今日の Blog はなんだか後で試してみたいモノを書き留めておくようなものになってしまった。

| | Comments (438) | TrackBack (1)

2004.05.08

Outlook, Exchange, & RPC over HTTP

うちのメールサーバーは Exchange 2003 で、メールクライアントは Outlook 2003 だが、この組み合わせで使える「RPC over HTTP」はずっと使っていなかった。
ニーズがなかったので、というのが一番の理由だったが、最近外出が増え、またパートナーと連携するためにインターネット上に公開された SharePoint なども使っている。こうなると、メールを読むために VPN に入り、インターネットにアクセスするために VPN を切断し、というのが面倒になってくる。で、RPC over HTTP をセットアップしてみた。
いくつかつまずいたが、セットアップが完了してみるとこれがなかなか便利。P-in Free でインターネットにつなげれば Outlook は勝手に RPC over HTTP で社内のメールサーバーにつなぎに行ってくれる。今 VPN だっけ、とか考える必要がない。
仕事のパートナーの間では、Exchange も Outlook も使っている人が少ない。管理者が嫌がって、禁止されている、という人も少なくない。一度使ってみると、離れられないと思うんだけどなぁ。

| | Comments (35) | TrackBack (0)

« April 2004 | Main | June 2004 »