えてにつき

ジュリエット...

Thu, 31 May 2007 19:38:10 +0900

とある製品の HP-UX 版の CD-ROM を入手した。この CD-ROM が必要だという同僚に送った。同僚いわく、「ファイル名が 8.3 形式になってる...」。まさか、Joliet 形式？と思い、CD-ROM をもらって確認してみると UDF。そして HP-UX は 11i v3 になるまで UDF には対応していないらしい。あぼーん。

民生用DVDプレーヤーで再生できるDVDをつくる

Thu, 10 May 2007 15:35:34 +0900

我が家のiMac G5 (iSight)にはスーパードライブが搭載されている。システムプロファイルで確認すると、このドライブは松下製で、DVD+R DL※1の書き込みに対応している。ローカルディスクに放り込んであるVIDEO_TSフォルダを民生用のDVDプレーヤーで再生するためにDVD+R DLのメディアに焼こうと試みて、ドツボにはまった。Toastなどの特別なソフトを購入せずにやろうとすると、素人にはなかなか難しい。

DVD+R DLはDVD-ROM化する。

まず結論から言って、ドライブはLacie D2を新調した。内蔵の松下製ドライブでDVD+R DLへの書き込みができるにもかかわらず、わざわざ二重投資してまでドライブを購入したのにはいくつか理由がある。我が家のiMac G5はただでさえ稼働時の放熱に心配を抱えているので、CPUとドライブに同時に負荷のかかりそうなDVDの書き込み処理は、できれば外部のドライブに押し出したかったからだ。また、外部ドライブを導入すれば、Combo Drive(DVD書き込み機能なし)のiBook G4からでもDVDへの書き込みができるようになる、という利点もある。

もう一つ、外部ドライブにした理由は、ネットを漁ってもiMac G5(iSight)に搭載されている松下製のドライブがDVD+R DLをROM化してくれるかどうかわからなかったからだ。我が家のテレビにつながっているDVDプレ−ヤーはパイオニアのDVR-515H-Sというハードディスクレコーダーで、DVD-R系にしか対応していない。DVD+R DLに焼いただけでは、おそらく再生できない。未検証だけれど...

Lacie D2はDVD+R DLの焼き込み完了時にbook typeをDVD-ROMにする機能がある※2ので、パイオニアのDVDプレーヤーとの互換性が期待できる。

hdiutilでUDFフォーマットに変換。

最初、VIDEO_TSフォルダの上位フォルダからCD/DVDマスター形式のディスクイメージを作成し、それをDVDに焼けばいいだろう、と考えていた。どちらの作業もディスクユーティリティからおこなえる。

... が、そうではない。ネットの情報を漁っていると、とある掲示板にディスクユーティリティでISO9660形式のボリュームの作成が可能、と書かれていた。だがいろいろディスクユーティリティを試してみたが、ディスクユーティリティでは望む結果は得られないようだ。拡張子が.cdrのCD/DVDマスター形式のディスクイメージは作成できる。これをDVD+R DLやDVD-Rといったメディアにそのまま焼く。最後に焼き上がったメディアをいったん排出して再度DVDドライブに射し込むと... 期待する動作はDVDプレーヤーが起動して再生がはじまることだが... 結果はデスクトップにマウントされるだけ。DVDプレーヤーを手動で起動してマウントされたボリュームを読み込ませようとしても拒絶される。どうやら、このディスクはMac OS拡張フォーマットとして認識されてしまっているのが問題のようだ。ちなみにVLCでも再生できない。素人の知識では、VLCで認識できないのであれば、何をどのようにしてもこのディスクからビデオを再生する術はない。

ディスクユーティリティに見切りを付けてさらにネットを徘徊していると、mkisofsというコマンドをMac OS Xに入れると、Mac OS拡張フォーマットではなくDVD-Videoフォーマットのディスクイメージを作成できるらしい、ということがわかった。使い方は、


mkisofs -f -dvd-video -udf -V <volume_name> \
    -o <image_name>.img <folder>/

である。

ここで、それぞれのオプションは次の通り。

-f: シンボリックリンクを追跡する
-dvd-video: DVD-Videoフォーマット互換のUDFフォーマットにする
-udf: 生成されるイメージにUDFサポートを含める
-V: ボリューム名
-o: 出力ファイル名

最後の<folder>はVIDEO_TSを含むフォルダの名前。

mkisofsで作成されたディスクイメージをファインダからダブルクリックすると、デスクトップにマウントされる。ダブルクリックするだけではDVDプレーヤーは起動しない。が、DVDプレーヤーを手動で起動すると、マウントされているボリュームにDVD-Video形式のものがあると認識するらしく、再生が始まる。このディスクイメージをディスクユーティリティでDVD-RやDVD+R DLに焼くと、すくなくとも我が家のパイオニアDVR-515H Sでは問題なく再生できた。

ところで、ネットを徘徊していると、わざわざmkisofsを拾ってこなくても、Mac OS Xに標準でついているhdiutilというツールでUDFフォーマットのディスクイメージをつくれるらしい。

hdiutilでmkisofsと同じことができるか実際に試してみたら... できた。使い方は下記の通り。


hdiutil makehybrid -o <output_name> \
    <folder> -iso -udf \
    -udf-volume-name <volume_name>

-o オプションには、生成されるディスクイメージの名前を指定する。つづく<folder>はVIDEO_TSフォルダを含むフォルダの名前。<volume_name>にはディスクのボリューム名を指定する。

hdiutilが生成するディスクイメージをファインダからダブルクリックすると、デスクトップにマウントされる。この状態でDVDプレーヤーを立ち上げると、自動的に再生が始まる。mkisofsと同じことができるようだ。

よくは知らないが、ディスクユーティリティーも下回りでhdiutilを呼んでるのだと思う。なぜにディスクユーティリティでDVD-Video(あるいはUDF)形式のディスクイメージを作成できないようになってるのかわからない。ハリウッドと仲良くするためにわざとそうなっているのかもしれない。

2層書き込みはディスクユーティリティで。

片面2層の書き込みに関しては、Mac OS X 10.4.9以降はディスクユーティリティが対応しているようで、問題なく行える。Lacie D2にはToast 6 Liteがついてきたが、これでToast 6 Liteは出番なし。

まとめ

結局、手順としては次の通り。

VIDEO_TSフォルダを準備する。
4.7Gを超えるデータを扱う場合には、DVD+R DLのメディアと対応しているドライブを用意する。Mac OS Xのシステムプロファイラのハードウェアセクションで、「ディスク作成」の「書き込み方法」にDVD+R DLがリストされていれば、そのドライブは DVD+R DLを扱える。
hdiutilでISO9660かつDVD-Video(UDF)形式のディスクイメージを作成する。VIDEO_TSフォルダのひとつ上のフォルダから作成する。
ディスクユーティリティでメディアに焼く。

※1: DVD+R DL
DVD+Rで、片面2層に焼くための企画。DLはDouble Layerの頭文字。ちなみにDVD-Rのほうの片面2層の規格はDVD-R DLだが、こちらのDLはDual Layerだそうな。DVD+R DLは、DVD+R9 と書かれていることもある。

※2: DVD-ROMにする機能がある
最近の大抵のドライブでは民生用のDVDプレーヤーとの互換性を重視して、ROM化機能を搭載している -- と、秋葉原ソフマップの店員さんが教えてくれた。

iMac G5 熱対策

Fri, 04 May 2007 22:04:59 +0900

我が家のメインマシンはiMac G5 (iSight)だが，長らくメモリを512メガバイトのままでなんとかやりくりしてきた。さすがに夫婦二人がファスト・ユーザー・スイッチをしながら使うには512メガだと辛く，ユーザーを切り替えるたびに一分から酷いときには二分も待たされることがしばしば。ページアウトどころか完全にスワップ落ちしているようである。まぁ，OLYMPUS Studio※1とiPhotoとiTunesとMailとSafariが同時に起動していて，さらに嫁がSafariのタブを十以上も開くので無理もない。

どうせ飲み会に誘われればCPU課金で一万円搾り取られるなら※2，家族のために後に残る出費も悪くはないと思い立ち，先週秋葉原で1ギガバイトの追加メモリを購入した。併せて1.5ギガバイトの環境にしたらメモリを使いきることなく，サクサク動くようになった。もう，快適の一言に尽きる。こんなに速かったのか，iMac G5。メモリが潤沢にあれば，の話だが。昔のOSは数百キロバイトの制限の中で動いていたもんだけれどねぇ...

ところが最近，頻繁にCPUの温度が高くなり，iMacが自動的にスリープするようになってしまった。CPUに負荷のかかる処理をするとすぐにスリープに入ってしまう。OLYMPUS StudioでRAWデータからJPEGへの変換をバッチ処理で九十枚ほどやらせるとダメ。MediaFork※3でDVDをH.264のmain profileに変換させてもダメ。とにかくCPUに仕事をさせると，五分と持たない。システム環境設定でプロセッサのパフォーマンスを『自動』から『低』に落としても，スリープに入るまでの時間が稼げるだけで，結局はスリープしてしまう。

CPUの温度がどんなになっているのかと思い，iStat Nano※4でチェックすると，定常状態でCPUの温度は七十度を超えている。CPUにちょっと仕事をさせるとすぐに温度が八十度ちかくまで急上昇し，そしてスリープ。iMac G5の初期型で放熱処理に問題を抱えていて，基盤の設計からやり直したはずのiMac G5(iSight)でこれでは，いかんともしがたいのである。

とにかく熱対策をせねば，とネットでいろいろ情報を探っていたら，今まで気がついていなかったところに吸気口があることを発見 - いや，発見と言っても，ちゃんとみてれば普通に気がつくだろ，というところにあったのだが - 本体を支える支柱の陰に，大きめの吸気口があるではないか。試しにここを指で拭ってみると，案の定ほこりまみれ。ということで，ウェットティッシュとブラシで掃除してやると，掃除している最中から急にファンの音が大きくなり - つまりそれまではファンの音さえ消してしまうほど吸気口が詰まっていたわけだが - CPUの温度が一気に下がった。

以来，CPUは定常で六十度前後，重い処理をさせても六十度台で推移するようになった。当然，ファンの回転数も3600rpmから1100rpmまで落ち，静かに稼働するようになった。

今回の教訓。吸気口の掃除は大切である。吸気口がどこにあるのかを知っておくことは，もっと大切である。

※1: OLYMPUS Studio
オリンパスのカメラが記録するRAWファイルをJPEGに変換するために使用している。使い勝手はもちろんPhoto Shopなどのほうが良いが，OLYMPUS Studioで現像しないといわゆる『オリンパス・ブルー』が再現できないという神話があり，いまもこれを使っている。神話の真偽については定かではない。
オリンパスの製品ページ

※2: CPU課金
マネージャー以上の人間であれば，本人の可処分所得に関係なく，一律高い飲み代を幹事が要求する習慣が僕の勤める会社にはある。CPU課金と呼ばれているが，人頭税と言ったほうが正確だろう。

※3: MediaFork
ちょっと前まではHandBrakeという名前のソフトだった。一昔前，MacでDVDをリッピングするには，ffmpegやらなにやら面倒くさいツールを使わなければならないことが多く，また映像と音声は別々に処理をしなければならず，そしてその面倒な作業をやったのに映像と音声がずれるということもしばしばで，とても僕のような素人に手を出せるものではなかった。そこにOpenShiivaという『お手軽一発変換ソフト』が出てきて随分ありがたい思いをした。やがてHandBrakeが出てきて，H.264などに対応していることもあってこれに飛びついたのだが，先日最新版をダウンロードしてみれば，MediaForkという名前に変わっていた。ただ，まだサイトのURLもタイトルもHandBrakeのままだ。
HandBrake

※4: iStat Nano
Mac OS X 10.4の便利な機能のDashboard。そのDashboardのウィジェット(アプリケーション)として動作する，CPUやメモリやその他もろもろのハードウェアの稼働状況を報告してくれるツール。ちなみにDashboardが便利だからといって，ウィジェットをあれこれ貼付けておくと結構なメモリを喰う。
iStat Nano

Outlook 2007、いまだ成熟せず

Tue, 24 Apr 2007 14:26:49 +0900

ここのところ、会社でずっと Outlook のヘルプデスクのようなことをしている。「あの Outlook 嫌いが?」と思う人もいるかもしれないが、サラリーマンなんてのはそんなもので... まぁ、現実には、チームのメンバーが精力的にヘルプデスク作業をこなしてくれるおかげで、僕のところに回ってくるのは文字化け系の解析作業ぐらいだけれど。

ところで、ヘルプデスクの中でみかけた「いまだにそんなっ？」なできごとをひとつ。

X-Mailer: Microsoft Office Outlook 12.0 を名乗るクライアント - おそらくは Outlook 2007 - から送られてくるメールの件名が文字化けする、と報告を受けた。調べてみると Outlook 12.0 とやらは、Subject 行に ISO-2022-JP の文字列をそのまま使っている。B-Encode していない。つまり、一昔前によくみた「Subject の生JIS問題」がふたたび起こっている。

いまだにそんなことするのか。

RFC2822 形式のメールでは、Subject 行は unstructured filed と定義されており、unstructured field に使えるのは US-ASCII (の CR/LF を除く部分)だと明記してある。

2.2. Header Fields

Header fields are lines composed of a field name, followed by a colon (":"), followed by a field body, and terminated by CRLF. A field name MUST be composed of printable US-ASCII characters (i.e., characters that have values between 33 and 126, inclusive), except colon. A field body may be composed of any US-ASCII characters, except for CR and LF. However, a field body may contain CRLF when used in header "folding" and "unfolding" as described in section 2.2.3. All field bodies MUST conform to the syntax described in sections 3 and 4 of this standard.

2.2.1. Unstructured Header Field Bodies

Some field bodies in this standard are defined simply as "unstructured" (which is specified below as any US-ASCII characters, except for CR and LF) with no further restrictions. These are referred to as unstructured field bodies. Semantically, unstructured field bodies are simply to be treated as a single line of characters with no further processing (except for header "folding" and "unfolding" as described in section 2.2.3).

で、US-ASCII との互換性を意識して設計された(※1) ISO-2022-JP には、RFC2822と衝突するようなシークエンスはない。昔はRFC2822 の Unftructured Field の body に許されるのは US-ASCII の printable部分で、そうなると ISO-2022-JP で使われる ESC (0x1B)が実は衝突する、だとか、そもそも US-ASCII の printable とはなにか、そこに ESC は含まれるのか含まれないのか、という論議がずっとあった。これに決着が付いた、という話は聞いたことがない。たんに勉強不足なんだろうけれど、あれはなんだったんだろう。いまRFC2822を斜め読みするぶんには、ヘッダーの名前は US-ASCII の、コロン(:)を除く printable 部分しか許されない、ヘッダーのボディは US-ASCII の CR / LF を除く部分を使っていいよ、CR / LF はヘッダーを折り返す(header folding)ときに使ってね、と書いてあるだけのように読める。

つまるところ、Subject に許されるシンタックスだけに注目するなら、実は ISO-2022-JP をそのまま使うのは是か否かというと、これはどうも「是」であるような気がする。

いずれにせよ、よしんば Subject 行のシンタックスとしてISO-2022-JP が許されるとしても、「これは ISO-2022-JP のシークエンスとして扱ってほしい」というセマンティクスはそこにはない。US-ASCII の文字が羅列されているだけで、その文字列をどの文字符号化方式として解釈してやらなければならないのか、その情報はどこからも与えられない。ISO-2022-JP のようにも解釈できるシークエンスを書いた人が、それを ISO-2022-JP として解釈してほしいのか、それとも US-ASCII として解釈してほしいのか、それは Subject 行そのものからはうかがい知ることはできない。そして、上に挙げたRFC2822の引用部分には重要な記述がある。もう一度みてみよう。重要なのは太字で下線がついている一文だ。

2.2.1. Unstructured Header Field Bodies

セマンティクスとしては、unstructured field のボディ部分は、単純なキャラクターの連続として扱い、それ以上の処理を施すべきではない、と書かれている。つまり、それが ISO-2022-JP のシークエンスのように見えても、それは US-ASCII として扱うべきだ、(RFC2047 の形式で無い限り)、プロアクティブに「何か別のコード体系」として処理してはならない。

いい加減、Microsoft も実践的な解法に従うべきではないのか。つまり、Subject にRFC2047で定義されたセマンティクスを与えてやればよい。たんに ISO-2022-JP を B-Encoding するだけで達成できる。そして、日本語対応を謳うメールクライアントなら、Subject 行の B-Encoding された ISO-2022-JP なら間違いなくデコードできる(※2)。

僕の手元に Outlook 12 (Outlook 2007?)があるわけではないので、送信者がどのような設定をしているのかはわからない。だが、どのような設定であれ、ISO-2022-JP をベアで(つまり生 JISで) Subject に突っ込むべきではないと思う。そのぐらい、もう Outlook を日本市場に投入して長いのだから、いい加減改めろよな、と思う。

※1
まわりくどい言いかたをしているけれど、つまりは 7bit ということ。

※2
もちろん、B-Encoding がまっとうに行われていれば、の話。外国産のメールクライアントには、いまだに B-Encoding を RFC に書かれたとおりに行わないものがある。行のフォールディングに CR + LF を使わずどちらかだけになっているとか、一行が 75文字を越えているとか、US-ASCII 部分と encoded-word 部分が一文字以上の空白文字で区切られていない、とか...

そもそも、B-Encoding などという「しちめんどうくさいこと」をしなければ日本語の情報が交換できないということ自体、現行の規格には無理がある。そろそろ、7bit ではないと通信路上でのデータの安全が確保できないなどという前世紀のくびきから解き放たれて良いころだろう。8bit 転送を前提に、よりシンプルなマルチバイト文字の交換が本当の意味で可能になるのはいつの日のことか...

POP3をいつまで使うのか

Fri, 20 Apr 2007 01:20:15 +0900

IPAが APOP（エーポップ）方式におけるセキュリティ上の弱点（脆弱性）の注意喚起について勧告を出している。APOPのチャレンジ・レスポンスに利用されるMD5ハッシュに脆弱性があり，サーバーに成り済ました悪意ある第三者にパスワードを盗まれる可能性がある，というものだ。IPAではPOP over SSLやウェブメールなどへの移行を勧めている。

いうまでもないが，POP3は古いプロトコルである。もともとのPOP3の規格では，パスワードは平文でネットワーク上を流れていた。そんなことをしても問題にならないほど平和な時代に作られたプロトコルであるとも言える(※1)。のちにパスワードを平文で流すなんてことが許されなくなるとRPOPやAPOPが考案され，結局APOPが主流になったのだけれど，そもそもいつまでPOP3を使うのか。

Solaris 2.6のころだと思うが，SunがIMAPサーバー機能をOSに同梱したことがある(※2)。あのころ，「なぜにIMAP?」というのが僕の疑問だった。せっかくのIMAPサーバー機能だが，まだクライアントがIMAPを十分に実装できていなかった。なにせWinbiffやAlmailが圧倒的なシェアを持っていた頃である。サーバーだけがIMAPを実装していても，まったく使えなかった。結局，qpopperを導入してお客さんに納めていた。

今思えば，Sunの選択はあながち悪いものではなかったと思う。当時，すでに複数のクライアントからメールを読みたいという要求が強くなりつつあり，そのためにはIMAPのほうが適していた。IMAPは最初からメールをサーバー側で保管するように設計されていたからだ。IMAPではクライアントはローカルにメールのコピーを持つ必要はなく，複数のクライアントからメールにアクセスするという用途にはうってつけだった。POP3もUIDLという苦し紛れの - それでも特定の用途には十分に機能した - 解決策を見いだしたが，いかんせん，サーバー側でメールをフォルダに振り分けて管理することができないのが致命的だった。POP3のUIDLは，単にサーバー側に保存されているメールの，一度も読まれたことのないコピーがどこからかを示す機能しかなかった。またPOP3は，サーバー側に保存されているメールを条件検索する機能も備えていなかった。メールを使い始めて数ヶ月もすればサーバーに相当数のメールが溜まる。効率よくメールを検索するための方法がなければ，ユーザーは結局はローカルドライブにメールを保存するしかない(※3)。

IMAPは完全ではない。それでもPOP3よりは使い勝手が良い。自宅のPCがVPNで会社のLANに乗り入れることができるなら，あるいは，会社のIMAPサーバーがDMZ上でサービスを提供しているなら，わざわざ会社のPCを自宅まで持ち運ばなくても自宅でも職場と同様にメールにアクセスできる。サーバー側にフォルダ・ツリーがあるから，POP3のときのように職場と自宅ではメールを振り分けたフォルダが違っていて困るなんてことはない。サーバーに保存されているメールを効率よく探し出すための条件検索も，IMAPではプロトコルに組み込まれている(※4)。

いずれにせよ，IMAPがこれほど広く受け入れられている状況で，POP3を使う必要があるのか？インターネット・プロバイダーのように巨大なユーザー・ベースを持つところは，IMAPにするとユーザーのクォータという問題に突き当たるのでPOP3がいまだにありがたいのかもしれない。が，しかし，Apple は .MacではPOP3ではなくIMAPでサービスを提供しているし，クォータの話をするならば，Google mailやYahoo! Mailはすでにギガバイト単位の容量をユーザーに与えている。

APOPに脆弱性が見つかったからどうというのではないが，そろそろPOP3を「終わらせ」てもいいんじゃないだろうか。

註:

※1
パスワードの保護とは観点が違うけれど，同じくらい古いSMTP/ESMTPのほうはいまだに認証なしで接続を受け付けるのが多い。企業内だとまずSMTP-AUTHにしていないのではないか。

※2
僕はSolaris 2.6までしか触っていないので，今のSolarisでもIMAPサーバー機能が同梱されているのかは知らない。

※3
現実には，IMAPのユーザーも検索や表示のパフォーマンスの問題から，ローカルコピーを多用している。

※4
もっとも，検索のパフォーマンスについては，サーバーのアルゴリズムと処理能力に大きく依存する。メールボディへの全文検索を行わないように設定できるサーバーがあるのも，条件検索がIMAPサーバーにとっては決して軽くはない操作であることを物語っている。結局，ユーザーは利便性を損ねているのかもしれない。

IdM for SMBs

Thu, 19 Apr 2007 13:36:32 +0900

Oracle は社員によるオフィシャルなブログサイトを持っているが、(英語のみ)、IdM 関連で面白いエントリがあった。 IdM is different for SMBs と題されたエントリ。Nishant Kaushik が書いている。

以下、勝手な意訳。許可を取っているわけではないので、怒られたら消します...

中小企業マーケットでは IdM が違う

カスタマー・アドバイザリ・ボード(CAB)(※1)では興味深い論議をいくつかしたが、そのひとつに「アイデンティティ管理に関してどれほど大企業と中小企業で意識に差があるか」というのがあった。Thor Technology は起業に際して、大多数の企業のニーズを満たすのではなく、特定のマーケットに集中しなければならなかった。そして、私たち(Thor)は金融業界で力を蓄え、今日に至っている。金融業界では、Thor の強みを活かせる顧客をもっぱら相手にした。とても洗練された要件を持ち、柔軟に拡張できる製品を必要とし、(とくに創業期のThor にとっては重要な要素である) 巨額の予算をもつ顧客たちである。やがて時が経ち、私たちは他のマーケットへの扉を開けつつあることに気がつき、そして同業者がすでに知っていたことを悟るにいたった。つまり、中小企業マーケットは、とても難しい「猛獣」なのである。

中小企業マーケットでは、キーワードは「箱から出してすぐ」(※2)である。システムは、追加の作業なんかほとんどせずに、すぐに使えなければならない。
以前の顧客たちとは正反対である。私たちがそれまでにアイデンティティ管理として理解していたもの - 業務処理と承認ワークフローは企業ごとに独自で、企業のインフラストラクチャは高度に作りこまれており、そしてユーザー・コミュニティは多種多様 - と「箱から出してすぐ」の概念はまったく相容れなかった。中小企業マーケットに踏み込むために私たちが取り組まなければならないふたつのこと - 「標準で提供されるもの」と「使い勝手」に気が付くまで、すこしばかり時間がかかった。

「標準で提供されるもの」が本質的に意味することは、私たちが製品として提供するものは何であれ、(それがコネクタだろうとワークフローだろうとポリシーだろうと)、一般的な使用用途に対応していなければならない、ということだ。
もし作りこみが必要なのであれば、その作業を無理なく簡単にするための使いやすいツールが必須となる。製品として何が提供されるべきかについてのカスタマー・アドバイザリ・ボードでの論議は、激しい討論となった。大企業の顧客はもっとたくさんの機能と柔軟性を製品に求めている。私たちが何を製品に含めるにせよ、彼らの独自の環境に適合するためには多くの作りこみを必要とするのだから、彼らは製品に標準で添付されてくるものに注意を払わない。一方で中小規模の顧客は製品として何が提供されるのかについて注意を払い、そして製品を拡張し操作するツールについても気にしている。私たちはどのようにしたら、ユーザビリティを損なわずに高い柔軟性を維持できるだろうか？このバランスをとることは、とても興味深い活動ではある。

その答えは、機能を多層的に抽象化するモデル - 低次の抽象化レイヤーの上に高次の抽象化レイヤーを持つモデル - を構築することにある。最大限の柔軟性が必要な顧客は、低次の機能抽象化レイヤーに取り組めばよい。設定・構成作業を最低限に抑えたい顧客は、高次の機能抽象化レイヤーだけを気にすればよい。これは OIM が最近実装したエレガントなソリューションだ。今後、私たちはこの機能を単に拡張するのではなく、この考え方を IdM 製品ラインの全体へ押し広げていく。中小企業マーケットは現在オラクルが本気で取り組んでいるビジネスであるから、これは、オラクルにとってきわめて重要なことである。
事実、Oracle Identity Management は中小企業マーケット向けの専用ページを開設している。そこには価値のある情報があるので、チェックしてほしい。

中小企業マーケットで IdM に対して何が本当に必要とされているのかを、コミュニティから聞くことは役に立つであろう。これまで述べてきたように、IdM 製品は、伝統的に中小企業マーケットの要件をぜんぜん満たしていなかった。しかし現在、この状況は変わりつつある。Oracle も、Novell や Sun などの他のベンダーも、中小企業マーケットに対応するために製品ロードマップに重要な変更をおこなっている。しかし、まだまだ取り組まなければならないことは多い。なぜなら、実装費用に対するライセンス費用の比率は、いまだに実装費用のほうがはるかに大きいからだ - ライセンス費用が安いからというのが理由ではなく、実装費用が嵩むというのが理由だが -。

P.S.

これを書くために Oracle IdM for SMBs のページを参照したら、中小企業顧客向けに特別価格キャンペーンを実施していることに気がついた。このキャンペーンは期間限定のようだが、ぜひ見てほしい。そのページで中小企業での実装事例として、Silicon Image の成功事例を読むことができる。

註:

※1
CAB... Customer Advisory Board。顧客から製品のフィードバックを得るために定期的に開催される Oracle と顧客グループとの会合。

※2
原文は Out-Of-The-Box。インストールすれば面倒な設定やチューニングやカスタマイズなしに業務用に動作することを言う。

[英語] Sucking Wind

Wed, 18 Apr 2007 10:14:24 +0900

英語で書かれたとあるブログを会社の人間に紹介するのに、要旨の部分を翻訳していたら... またでた。知らない表現。


sucking wind

これを最近よくお世話になっているエキサイトの翻訳に流すと、


風をしゃぶります。

そうじゃないだろう...

手元の現代英英辞典(LONGMAN Dictionary of Contenporary English)を引いても、suck の項にも wind の項にも sucking wind の用例はない。

一瞬、これはサーファー用語か? と思ったけれど、Google で用例をいくつか見た結果、suck(ing) windは「価値が下落傾向にある」という表現であると結論。

わかんないって。ネイティブじゃなんだから。もうちょっと口語よりの、あるいは経済よりの辞書を買うかなぁ...

Ethereal

Mon, 12 Mar 2007 13:47:12 +0900

Ethereal が Wiresharkに名前が変更されている。EtherealからWiresharkへの名称変更の経緯に事情はある程度詳しく書かれているが...

会社で使うマシンを Dell D600 から Lenovo Thinkpad Z61t へ変更したので、環境再構築の真っ最中なのだが、せっかくなので Wireshark のほうを使うことにした。インストーラが進化してる。そのほかは... あんまり変わってないかな。

NTEmacs: Mew on SSL

Mon, 12 Mar 2007 13:30:35 +0900

会社の imap サーバーがいつのまにやら IMAP on SSL が有効になっていたようなので、mew にも対応させる。

mew は SSL 通信のためにstunnel を使うようなので、stunnel-4.20-installer.exe を落とす。インストールは基本的にクリックするだけ。らくちん。

mew はどうも version 3 の stunnel を使うらしく、上記のサイトから stunnel-3.26.exe を落としてきて、上の手順で導入した stunnel.exe と置き換える。そんな面倒をしなくても、最初から stunnel-3.26 のインストーラを落としてくればいいじゃん、と思ったが、stunnel の 3 系はインストーラを提供しておらず、実行ファイルのバイナリが置いてあるのみ。やはり ver. 4 を導入して ver. 3 へ実行ファイルのみを置き換えるという手順が手っ取り早いようだ。ちなみに、ver. 4 のまま mew から使おうとすると、「サーバーがみつからん」趣旨の英語のメッセージがダイアログボックスに表示されておしまい。NTEmacs がフリーズする。

mew 用の設定は下記のとおり。


; SSL

(setq mew-ssl-verify-level 0); Do not verify
(setq mew-prog-ssl "C:\\Program Files\\stunnel\\stunnel.exe")
(setq mew-ssl-ver 3) 
(setq mew-imap-ssl t)
(setq mew-imap-ssl-port "993")

ひとつの Terminal セッションを共有する

Fri, 09 Mar 2007 17:37:36 +0900

昔はこういう「技」は師匠から弟子へ伝えられたものだが...

書いときます。

Terminal でやっている作業をみんなで見守る方法。

Terminal A から。


$ telnet localhost | tee /tmp/akio

Terminal B から。もちろん、別マシンからの SSH/Telnet でよし。


$ tail -f /tmp/akio

Terminal A (作業する人)があえてローカルマシンへ telnet し、標準出力を tee で分岐するところがミソ。

昔は Web Conferencing なんて要らなかった。テキストが世界のすべてだったころはよかったなぁ...

NTEmacs: ispell その 3

Fri, 02 Mar 2007 17:09:47 +0900

ispell に関してもうひとつ。 cygwin は egrep が grep へのシンボリックリンクになっている。ispell のほうで egrep ではなく grep を使うように指定してやらないと、うまくいかない。


; Cygwin では egrep が grep へのシンボリックリンク
(setq ispell-grep-command "grep")

あと、ispell-complete-word を使うなら、/usr/dict というディレクトリを掘って、wordsファイルのアーカイブを置いてくれている人の親切にすがりながら、ダウンロードした words ファイルを /usr/dict/words に配置すること。

NTEmacs: ispell その 2

Fri, 02 Mar 2007 14:45:00 +0900

NTEmacs は情報が少ない。ためしに "NTEmacs ispell" でググってみると... さて。ispell を NTEmacs に使うには、(ひとつ前に設定はいらないと書いたけれど...) .emacs に次の設定をする。


;;
;; ispell
;;
(autoload 'ispell-word "ispell" "Check the spelling of word in buffer." t)
(autoload 'ispell-region "ispell" "Check the spelling of region." t)
(autoload 'ispell-buffer "ispell" "Check the spelling of buffer." t)
(autoload 'ispell-complete-word
    "ispell" "Look up current word in dictionary and try to complete it." t)
(autoload 'ispell-change-dictionary "ispell" "Change ispell dictionary." t)
(autoload 'ispell-message "ispell" "Check spelling of mail message or newsx post.")
(defun ispell-tex-buffer-p ()
  (memq major-mode '(plain-tex-mode latex-mode slitex-mode yatex-mode)))
(setq ispell-enable-tex-parser t)

;; 日本語部分をスキップする
(eval-after-load "ispell"
  '(add-to-list 'ispell-skip-region-alist '("[^\000-\377]+")))

最近の cygwin は ispell ではなく aspell が入っているようなので、次のようにしておく。


(setq-default ispell-program-name "aspell")

NTEmacs: ispell

Tue, 27 Feb 2007 11:25:12 +0900

Mew でメールを書くとき、英語のスペルチェックには ispell を利用している。NTEmacs の環境から ispell を使うには、cygwin で aspell.exe を導入する。

cygwin では、Text カテゴリに aspell が収録されている。aspell.exe をインストールしたら、Emacs / Mew 側での~~余分な作業は必要なく、そのまま ispell が使える。~~ NTEmacs 側での作業は必要。以後の記事に説明を書く。

NTEmacs: w3m

Tue, 27 Feb 2007 09:54:07 +0900

NTEmacs と Mew の導入まではすんなりいく。

Mew で HTML のメールを読むためには、w3m と emacs-w3m が必要。

w3m を Windows 環境に導入する最も簡単な方法は、cygwin。cygwin のインストール時に(インストール後でもいいけど) w3m を選択してインストールし、%cygwin_path%\bin を PATH 環境変数にいれておけば、それでいっちょあがり。

emacs-w3m はソースを落としてきてコンパイルする。cygwin で gcc や make を入れておく必要がある。コンパイル自身は ./configure -> make -> make install で Emacs の share\sitelisp へ放り込んでくれるので、簡単。らくちん。

NTEmacs: fiber.exe

Tue, 27 Feb 2007 09:49:28 +0900

Mac OS X には open という便利なコマンドがあって、ターミナル(Terminal.app)にいるときに open コマンドに適当なファイル名を与えると、そのファイルに関連付けられているアプリケーションを起動してファイルを開いてくれる。

とくに Emacs でメールを読んでいるときにはこの open コマンドがすごく役に立つんだけれど、Windows には open に相当するコマンドがない。

で、Meadow には open と同じことをしてくれる fiber.exe という実行ファイルが添付されている。

NTEMacs には添付されていない。ということで、NTEmacs を使う場合には、fiber.exe でググって、適当なパスに入れてやる。まぁ、コマンドの性格上、cygwin\bin あたりが適当かな...