2003/03/28

春の雪

北海道でも3月下旬となると春うららでして、ここ数日は私もぽわわぽわわしてたんですが(すいません)、昨日起きてみたら雪降ってるんですよ。しかも、雪は丸1日降り続いて今日起きたら積もってるのね(もうほとんど溶けましたけど)。

だーかーら、雪降るとAirH"がつながらなくなるんだってばっ!

雪降るとAirH"が、とかいうと大風が吹けば桶屋が儲かるような回りくどさというか、「単に電波が悪いのを天気のせいにしてるんじゃないのー?」とか思われがちなのではっきりといっておきますと、AirH"って1.9GHzなんで、そんなに電波が乱反射してうんぬんかんぬんなことはないような気がしますが、なにぶんここはエリアぎりぎりなので、ちょっとでも雪が降り始めるともー大変です。ただでさえデータを飛ばしていないと10分に1回は来る圏外の時間が2分に1回ぐらいになったりします。しかも、データ飛ばしていても圏外になってぷっつり切れます。だめだこりゃ。で、降ってる雪も悩みの種ではあるんですが、エリアぎりぎりともなるとたぶん積もった雪でもここに届いた電波が乱反射したりしてただでさえ弱い電波がさらに撹乱(むしろ撹拌?)されるんでしょうか、雪の積もった後の晴れた日でもかなーり調子悪いです。

ってか今気がつきましたが、もしかして基地局のアンテナが雪をかぶってそれが除雪されてないからこうなってるんじゃ?街外れの基地局の宿命ってか…

DLLをリソースに、とか(not リソースをDLLに)

TaskTrapの次の展開を考えてみたりしてるわけですが、TaskTrapは外部DLLを持ってないわけで、他のウィンドウに対するHook関係の芸当ができないわけですよ(タスクバークリックでメニューを出すとか)。いや、サブクラス化するというのも手ではありますが。

で、フック用DLLでもつくってもうちょっと機能拡張路線に走ってみたりしようかとも考えてるわけですが、どーせTaskTrapからしか呼ばれないDLLなのにDLLとして外部においておくのもどーなんでしょうね、とか思ったりしてるわけですよ。やっぱり、こう、ポータブルな感じ(なにそれ)のアプリケーションが作りたいと思うと(DLL無しの)実行ファイル1個でバシッと行きたいわけですよ(私だけですかそうですか)。

ちうわけで、アプリケーション(.exe)のリソースバイナリとしてフック用DLLを持っておいて、exe実行時にリソースからDLLをメモリ上に展開してそれを動的ロードする、なんて芸当ができればなぁ、とかおもってるわけですが、そんなことできるんですかね?

ま、リソースから外部ファイルに書き出してその外部ファイルを読み込めばいい話ですが、実行時に外部にファイルを作るぐらいだったら普通に持てばいい話ですし(謎のポリシーですいません)、とかとか。

で、実現方法を考えてみたんですが、FindResourceしてLoadResourceの戻り値のHGLOBALをHMODULEとして扱うか、LoadResourceの戻り値のHGLOBALでLockResourceして実アドレスをHMODULEとして扱って後はGetProcAddressかなぁ、とか思ってみましたけど、それはLoadLibraryがやってると思われる仕事(DLLのエントリポイント呼び出しなど、あれこれ)を全部肩代わりした上でないと無理ですよね。よねよね。ってか、LoadLibraryって中で何やってるんですかね。

というわけで挫折気味ですが、LoadLibraryExには第2引数にhFileが渡せるという未来の仕様があるわけでして、いつ実装されるのか知りませんけどコレが実装されればそういうこともできるようになるんでしょうかね。CreateMappingFileして、そこにDLLイメージを書き込んで、マッピングしたファイルハンドルをLoadLibraryExに渡す、みたいな。

とまぁ、そんなことを考えてるうちに3月が終わりそうです。

Another HTML-lintでいろいろと知る

ここ数ヶ月(まともにサイトを更新しなかったせいもあって)Another HTML-lintを使ってなかったんですが、サイト内検索の吐き出すXHTMLの妥当性を検証するべく久々に使ってみると、こんなエラーが。

6: line 17: <base> の href 属性の URI は絶対位置で指定しなければなりません。 → 解説 222

で、私はbase hrefになんて書いていたかというと、<base href="/~kawazoe/" />って書いてたんですよ。

何でこんな書き方かというと、t-baseではt-baseを基準にして、localhostではlocalhostを基準にして読んでほしかったからなんですね。たとえばCSSのテストをしてるときにbaseがhref="http://www.t-base.ne.jp/~kawazoe/"だとまだアップロードしてないローカルのCSSを読みに行かないし、そもそもlocalhostにファイルがあるのにt-baseにCSSとかの外部ファイルを読みにいってしまうとトラフィックの無駄、というかAirH"にはそれなりに負担なわけです。

ということで、HTML4.01仕様を久々に読んでみたんですが、確かにbaseのhrefは絶対URIでないとならないと書いてありますね。で、そもそも、URIの指定法は3つあるということを考えてみてください。

• URIのスキーム(httpとかftpとか)から始まる絶対URI (e.g.: http://www.t-base.ne.jp/~kawazoe/)
• サーバの絶対Path (e.g.: /~kawazoe/)
• 普通の相対Path (e.g.: daily/2003/03/28.html)

1つめは絶対URIな絶対Path。2つめは相対URIな絶対Path。3つ目が相対URIな相対Path。で、baseのhrefは仕様書ではこの1番目のケースでしか指定できないことになってます。でも、実際のところ、3番目の相対Pathではどうしようもないですけど2つめのサーバー内の絶対Path指定でも事足りるような気がしませんか? ってか、私はこれで事足りてますし。ということで、私はこの点を次のXHTMLでの改善点として声高に叫びたいっっ、と思ったんですが、HTML4.01仕様からこんなことが。

12.4.1 Resolving relative URIs

User agents must calculate the base URI for resolving relative URIs according to [RFC1808], section 3. The following describes how [RFC1808] applies specifically to HTML.

User agents must calculate the base URI according to the following precedences (highest priority to lowest):

1. The base URI is set by the BASE element.
2. The base URI is given by meta data discovered during a protocol interaction, such as an HTTP header (see [RFC2616]).
3. By default, the base URI is that of the current document. Not all HTML documents have a base URI (e.g., a valid HTML document may appear in an email and may not be designated by a URI). Such HTML documents are considered erroneous if they contain relative URIs and rely on a default base URI.

相対URIの解決方法ということで、3つの手順が示されてます。1つめはbase要素があればそれを使え、と。2つめはHTTP headerからそれが得られるときはそれを使え、と。で、それでも得られないときは3つめとしてその当該文書自身を示す絶対URIからの相対URIとして解釈しなさいと書いてあります。

で、問題はNot all HTML以下です。「しかしながらすべてのHTML文書が自分自身を示す絶対URIを持ってるとは限らないわけですよ。たとえば、HTML文書はemailにだって現れるけど、それは絶対URIをもってないでしょう。そういう(email中のHTML文書にbaseとなるURIが指定されていない)場合、HTML文書中に相対URIが出てきたらそいつはエラーとして判断されちまうぜボビー」と。

つまり、これは裏を返せばbaseにサーバを指定しない相対URIな絶対Pathを指定したときにそれがemailみたいな媒体で使われたときはサーバの解決ができないわけで(そりゃそうだ)、そういった理由からbaseでは絶対URIを示さなければならない、ということを示唆しているわけですな。

で、結局emailに現れるHTML文書って何なのよ、って考えてみたんですが、もしかしてあれですか、HTMLメールのことを言ってますか。あはははー、確かに某社から送られてきたHTMLメールのメールマガジンには確かにソース中にbaseが絶対URIで指定されてるわぁー。まぁ、私の場合はAirH"なんかでHTMLメールなんて読んでられないのでOE6SP1からの新機能であるHTMLオフ機能でHTMLメールを開かないようにしてるんですが。

というわけで、HTML4.01仕様はちゃんとHTMLメールのことまで考えたすばらしい仕様になっているということがよくわかったわけですが、原因がHTMLメールだけに(他にもあるんだろうけど)無性に腹が立つのは私だけでしょうか。結局、うちのサイトでは各ブラウザが解釈するのをいいことに<base href="/~kawazoe/" />で運用しちゃってます、ハイ。

(笑)

基本的にこのサイトでは(笑)とかいうのが出てこないのがミソですが(そのぶん、やけに長い注釈はどんどん出てきます)、それは単にこのサイトが全体を通して謎の説明口調で書かれているからであり、その辺が他のサイトとは一味違うのかどうかは知りませんけど、とりあえず基本的に「ここは笑うところだぞ」or「冗談です」的に(笑)を使わないようにしてるわけです。使わないようにしているというよりは、「というか」「というわけで」「で、」「ということで」みたいな前の文の調子をそのまま引っ張ってくるような文章をだらだらと書きなぐっているだけので特に笑うとこもないし冗談であればその直後に冗談であることが(冗談の通じる人には)明白になるように書いてるんで基本的に(笑)みたいなのは使わなくてすむんですね。というか、そんなに(笑)を連発するような文章って読み手を不快にすると思うんですよ。むしろ最近は（ｗとか、単にｗとかに略されてますが。

しかしながら、逆にまじめっぽいネタとそうでないネタが混在するようなページを読んでいると逆に(笑)というのが含まれているほうが内容の流れにメリハリがついてて読みやすいというのも事実。で、(笑)を効果的に使っているとあるサイトを読んでいたんですが、どう考えても冗談で言ってるようなことなのに(笑)がついてない文章があったんですよ。内容的にたぶんフレンドリーな冗談(ってなんだろう)なのに、(笑)がついてないので非常にそこだけ非常に違和感があったんですが、後日行ってみるとこっそりそこに(笑)が追加されてたんですよね。「あー、やっぱり」と思わずニヤリ

というわけで基本的に私は(笑)を毛嫌いして使っていなかったわけですが、(笑)ひとつで文章の印象がこんなにも変わるんだなぁ、というのをふと感じました。ちなみに、そこのサイトは基本的に軽い冗談をしめるときにだけ(笑)を使っているんで文章の流れが損なわれることがなく、(笑)を使うことで内容のまじめ度(なにそれ)の切り替わりのメリハリがしっかりしてて読みやすいんですよね。

とまぁそういう話だったんですが特にオチがないんですよね(笑)。……なーんてな。