同じ日付の項目が複数並んでいる場合がありますが、必ずしも間違いではありません。
6 月 24 日に新サーバーに移行して、ウェブサーバーのアクセスログを見ることができるようになりました。そのため、以前導入していた Google Analytics などのアクセスログ収集スクリプトを使うのをやめました。また復活するかもしれませんが。
24 日から 29 日までの 6 日間のページビュー (HTML ファイルに対するアクセス回数) は、僕自身とロボットによると思われるアクセスを除くと 245 回で、 1 日平均約 40 回でした。手作業で集計しているので不正確ですが、目安ということで。最もアクセスが多いのはトップページで
49 回、 2 番目は「C 言語の strtoul 関数の不思議」で 47 回でした。
Yahoo! のロボットである Slurp がほぼすべてのページを 10 回ほどアクセスしてきているのが不思議です。ページを更新していないことはページにアクセスしなくてもサイトマップファイルによってわかるようにしてあるつもりなのですが……。
一つ前の項目で、 Google ウェブマスターツールで Google のクロール頻度「多い」を選ぶことができないのは Google がウェブサイトを重要だとみなしていない場合だと書きましたが、この記述は僕の推測であり、 Google のヘルプにはここまではっきりとは書かれていません。
「多い」を選べるのはどういう場合かについて、 Google のウェブマスター向けヘルプセンターに記述があります。
(英語版)
If we determine that we are limiting how much we crawl your site (in other words, we would crawl your site more if we felt your server could handle the additional bandwidth), we will let you know this and offer the option for a faster crawl.
if 節の中に括弧で挿入句があって、その中に if 節が入っていて、僕には意味を理解するのも大変でした。多少言葉を補って日本語に訳してみると次のようになります。
(仮訳)
Google がサイトのクロールの速さを抑えていると判断した場合 (言い換えれば、今はウェブサーバーがこれ以上の帯域を処理できるかどうか自信がないから今の速さでクロールしているのであって、もし今以上の帯域を処理できそうならもっと速くサイトをクロールすることになる場合)、このことを表示してクロールを速くする選択肢を提供します。
逆に言えば、「多い」という選択肢が表示されないのは、ウェブサーバーの帯域に余裕があってサイトの側がもっと速くクロールしてくれてもかまわないと思っていたとしても Google はこれ以上速くクロールする気がない場合です。結局、尋ねても関係ないときには尋ねないという当たり前の動作をしていることになります。
ちなみに、ヘルプセンターの日本語版の記述は
Google がより多くの帯域幅を処理できると判断した場合、サイトをより頻繁にクロールします。また、より高速なクロールを実行するオプションをご提案いたします。
ですが、「Google がより多くの帯域幅を処理できる」と読めてしまったり、「サイトをより頻繁にクロールします」と英語版にないことを言っていたりして、英語版の和訳としてはあまり良くありません。
もう一つ、 Google ウェブマスターツールで気になったこと。ウェブサイトの URL がルートディレクトリーになっている場合、 Google のクロールの頻度を「多い」「標準」「少ない」の 3 段階から選ぶことができます。ただし、 Google がそのウェブサイトを重要だとみなしていない場合は「多い」を選ぶことができず、代わりに次のメッセージが表示されます。
Googlebot のクロール頻度は様々な要素で決定されます。 現在のところ、クロール頻度は要素に含まれておりません。 クロール頻度が要素になると、下記の [高速] オプションがご利用いただけます。
「高速」ではなくて「多い」だろう、というのは措いて、「クロール頻度は要素に含まれておりません」とか「クロール頻度が要素になる」とかいう謎の日本語が気になります。
英語版では
The rate at which Googlebot crawls is based on many factors. At this time, crawl rate is not a factor in your site's crawl. If it becomes a factor, the Faster option below will become available.
となっており、日本語版のメッセージの中の「要素」は factor の訳語のようですが、この英文も僕にはよくわかりません。もしかして「factor」には「自由に設定できる項目」のような意味があるのでしょうか。
Google ウェブマスターツールでは、ウェブサイトの URL がルートディレクトリーである場合とそうでない場合で機能に差があります。 http://homepage2.nifty.com/polytope/ から http://www.unsanitized.net/ に移ったので、ルートディレクトリーの場合しか使えない機能が使えるようになりました。
この URL に移った後しばらくすると、ウェブマスターツールのページに「お客様のホームページに正常にアクセスしました」と表示されるようになりました。正常にアクセスしてくれたのはよいですが、何でしょう、このエラーメッセージのような表示は。
何かの誤訳かと思いましたが、英語版でも同じように「We accessed your home page successfully.」と表示されるので、訳の間違いではないようです。
中学の頃友人に見せてもらった本に載っていた、「0 で足し算をしました」というエラーメッセージのジョーク画像を思い出しました。服部宗弘『まみむめマッキントッシュ』 (技術評論社、 1993 年) という本だったと思います。
「最近の fcp」のフィードを追加しました。
電子メールの返信の題名にはよく「Re:」と付けます。この re は「〜に関して」という意味の英単語ですが、電子メールの題名では返信を表す記号として使われています (re の語源については Michael T. Kye さんの「Re:」に詳しく書かれています)。でも、日本語のメールのときには「返:」などと日本語で書く習慣だったらわかりやすかったのになあ、と思います。今さら習慣が変わることはないでしょうが。
当サイトのアドレスが http://www.unsanitized.net/ に変わりました。しばらくは旧アドレス http://homepage2.nifty.com/polytope/ からも転送されます。
http://www.unsanitized.net/ は ロリポップ! レンタルサーバーサービスを利用して運営しています。
HTTP の Referer リクエストヘッダーフィールドと同様の情報をクライアントサイドの JavaScript で取得するときに見るべきメンバーは、 document.referer だと思っていましたが、正しくは document.referrer です。ショック。英単語の綴りとしては referrer が正しいので、 HTTP は今さら変えられないけれど後から決めた DOM では正しくしたということでしょう。
おとといの「話し」に関する話に関係します。 MS-IME 2002 で「倫理感」と入力しようとしたら、候補に「倫理観」しか表示されませんでした。「話」と違って、「倫理感」の場合は漢字に自信があまりありません。「倫理感」という言葉があるような気がするのは錯覚か? でも、「倫理観」というのは、人としての正しさに関する考え方のことだよね? 人として正しいことをしようと思う気持ちは「倫理感」って言うよね? あれ、言わない?
不安になりながらも、かな漢字変換の辞書なんてものは何の権威でもないんだと自分に言い聞かせ、デジタル大辞泉を調べたら、「倫理」の用例の中に「倫理感」という言葉が出ていました。勝った。 MS-IME の言いなりになどなるものか。ふふん。
こうして MS-IME という権威から解き放たれた僕はデジタル大辞泉という権威に尻尾を振るのでした。
名詞の「話」の表記が「話」か「話し」かについて。はてな匿名ダイアリー「『話』を『話し』って書くな」で参照されているように、内閣告示「送り仮名の付け方」では送りがなを付けずに「話」とすることになっています。僕も小学校の頃「話」と習いました。
記憶が正しければ、 Windows 95 に付いてくる MS-IME 95 の標準辞書には「はなし」→「話し」という変換候補はあっても「はなし」→「話」という変換候補はありませんでした。自分が当然正しいと思っている表記が候補に出なくて驚いた記憶があります。わたなべごうさんの電波…とどいた? 1998 年 6 月 6 日でも、「話し」という表記の原因として Wnn と並んで MS-IME が挙げられています。
当然ながら、現在の MS-IME では「はなし」→「話」も標準で登録されています。僕が主に使っている MS-IME 2002 でも登録されています。 MS-IME 95 と MS-IME 2002 の間には、 MS-IME 97、 MS-IME 98、 MS-IME 2000 というバージョンがあり、どこから「話」が標準で登録されるようになったのかはわかりません。
6 月 13 日、サイドフィードが「あわせて読みたい」というサービスを開始しました。ブログに画像を貼り付けるだけで、そのブログの読者がほかに読んでいるブログをリストアップしてくれるのだそうです。面白いですね。
Google Analytics もそうなのですが、このようなサービスはプライバシーをある程度犠牲にして初めて成り立ちます。以前はもっと機能よりプライバシーが重視されていたような気がするのですが、どうでしょうか。どの辺りでバランスを取るのが望ましいのか、僕にはまだわかりません。
StatCounter を導入してからまだ 1 週間もたっていませんが、 StatCounter を使うのをやめました。二つを同時に管理するのは案外大変でした。
StatCounter ではページをローカルに保存したときにローカルファイルのフルパスが表示されてしまうことがわかりました。僕が閲覧者から集めたい情報の範囲を超えているのですが、うまい回避方法が見つからなかったので、この際やめてしまえと。
Google Analytics は引き続き使っていく予定です。
Visual C++ でプログラムをコンパイルして実行ファイルを配布する場合、プログラムの動作に必要なランタイム DLL を一緒に配布することができます。ただし、ランタイム DLL を付けてプログラムを配布するには、次の条件を守る必要があります (Visual Studio 2005 Professional Edition 使用許諾契約書 3 条 b 項 ii より抜粋)。
- お客様のアプリケーションのエンド ユーザーとの間において、本契約書と同等以上に再頒布可能コードを保護する条項を含む使用許諾契約を締結すること。
- お客様のアプリケーションにお客様名義の有効な著作権表示を行うこと。
このため、再頒布可能コード付きで公開するプログラムについては、「自由に使ってください。著作権を放棄します」と言うことはできません。パブリックドメイン好きの人は注意が必要です (「著作権を放棄します」と言ったからって使用許諾契約違反でマイクロソフトから何かされるとは思いませんけど、まあ一応)。
コンパイルしてできた実行ファイルを自由に配布できるとは Visual C++ の使用許諾契約書のどこにも書かれていないようですが、できないわけがないので、これは許諾されるまでもなく当然できるということでしょう。ランタイムライブラリーを静的リンクした実行ファイルの配布についても何も書かれていませんが、これもできないわけがないので、許諾は不要ということだと思います。この解釈が正しければ、ランタイムライブラリーを静的リンクすれば上述の条件には縛られません。ただし、マイクロソフトは動的リンクを推奨しています。
ランタイムライブラリーに動的リンクしているけれど DLL を一緒に配布したくない場合、ユーザーに再頒布可能パッケージを別途ダウンロードしてインストールするよう指示するという方法も一応あります。
Google Analytics の導入に続き、アクセス解析ツール StatCounter を導入しました。二つ入れてどうするんだという話もありますが、どちらがより遊べるか比べてみることにします。
はてながロゴをクリエイティブ・コモンズ・パブリック・ライセンス (CC ライセンス) で提供したと聞いて驚きました。企業のロゴなどの商標 (登録商標に限らず) というのは、他者に真似されないようにする必要があるというのが僕の理解です。他者が自由に使える CC ライセンスにすると、商標として使いにくいのでは……でも、そんな考え方はもう古いのかなあ……と思いながら、アナウンスを読み進めていたら、
但し、そのロゴマークを用いてはてな社やはてなサービス以外のものを指し示したり、商用行為に利用するといった利用方法はおこなえません。
と書いてあって、僕にはさっぱり理解できませんでした。
CC ライセンスの中でも「表示 - 非営利 - 継承」だそうなので、営利目的で利用できないのはその通りだと思うのですが、なぜロゴマークではてな社やそのサービス以外を指し示してはいけないのでしょう。 CC ライセンスは、そんなライセンスではないと思うので、「CC ライセンスで提供している」というのと矛盾するように思いますが……。
はてなは「はてなのロゴの入った T シャツを作ってもいい」と書いていますが、僕の考える CC ライセンスというのは、そんな風に原著作者が狭い枠を定めて、その中で自由に使っていいですよ、なんて生易しいものではありません。 CC ライセンスというのは、今回のライセンスなら、原著作者を表示し、非営利で、派生物も同じライセンスに従う限り、どんな目的で利用されても著作権を武器に文句を言うことはない、という宣言のはずです。だからこそ、ロゴを CC ライセンスで公開したと聞いて「思い切ったことをするなあ」と思ったのですが、どうもただの間違いだったようです。
いわいまさはるさんは「はてなロゴマークのライセンス表示がひどい」という記事の中で、「このようなものは Creative Commons ライセンスだと名乗るべきではない」と書いています。この点は僕も賛成です。
はてなにはたぶんクリエイティブ・コモンズのことを知っている社員がほとんどいないのでしょう。今回のはてなの動きがクリエイティブ・コモンズの活動にとって吉か凶かなんて、僕にはわかりません。ひょっとしたら、これでクリエイティブ・コモンズの活動の知名度が上がって良い結果を生むかもしれませんし。でも、「はてなって、情報技術系の先進的な企業だと思っていたのに、その程度なのか」と多少がっかりしました。
アクセス解析ツール Google Analytics を導入しました。いつまで飽きずに見続けるかわかりませんが。
磯崎哲也さんの「『年金を受け取れる権利』なんて、もともと存在しない」、 bewaad さんの「『年金を受け取れる権利』は当然存在します」、磯崎さんの「『年金を受け取れる権利』なんて、もともと存在しない (補足編)」を読みました。
磯崎さんの最初の記事を、僕を含め一部の人にとってわかりやすいように少し書き換ると、次のようになります。
「年金の掛金を払った人には、将来、年金をもらう権利があるはずだ。それなのに、社会保険庁からは、受託者として『人のカネを預かっている』責任感といったものが感じられない。どうしてだろう」
「俺たちはとんでもない思い違いをしていたようだ。確かに、年金をもらう権利があると考えると社会保険庁の無責任さは説明が付かない。だが、債務者である国側の都合で金額が勝手に変えられてしまうものが『債権』であるはずがない。つまり! 『年金を受け取る権利』なんて、もともと存在しなかったんだよ!!」
Ω ΩΩ < な……なんだってー!
file:///dir%2Ffile.html という URL は何を表すでしょうか。 RFC 3986 の 2.2 節によれば、 %2F のようにパーセント符号化された文字は予約文字としての特別な意味を持たないことになっているので、 %2F はパスの区切りではなくただのスラッシュという文字を表すことになります。なので、僕は、 dir というディレクトリーの下の file.html というファイルではなく、「dir/file.html」という名前のファイルを表すと解釈するべき (よってスラッシュがファイル名に使えない環境ではエラーにするべき) だと思っていますが、 Firefox 2.0.0.4 ではこの URL はエラーにならず file:///dir/file.html と同じように解釈されるようです (Windows 上の Firefox 2.0.0.4 で類似の例 file:///C:%5Cdir%5Cfile.html の動作を確認しただけなので、違っていたらごめんなさい)。
これをエラーにしていれば、 Firefox のバグ 380994 「Fix for bug 367428 lets through escaped slashes on Linux」は発生しなかっただろうになあ、というだけですけど。
ちなみに、 file: スキームの URL は 1994 年の標準仕様 Uniform Resource Locators (URL) (RFC 1738) で定義されています。 URL の一般的な構文に関する RFC は何度も改訂されているのに、こんな古い仕様が生き残っていて驚きました。
「すぐに役立つとは言っていない」とか「インストールするべきとは言っていない」とか「Google が悪いとは言っていない」とか、予防線を張りまくっていることに気付いて、僕はこんなにも読者を信頼していなかったのかと反省しています。
このサイトの中でページを移動してから約 1 ヶ月がたちました。 Google と Yahoo! は旧ページから新ページに Meta Refresh で飛ばしているのを認識してくれているようです (Live Search では当サイトのページがほとんど検索できないのでここでは考察しません)。
Google の少なくとも Meta Refresh でのリダイレクトの取り扱いについて、細かいところで不思議な挙動を見つけたので書いてみます (べつに何か不都合があると主張しているわけではありません)。
Yahoo! の場合は旧ページのアドレスを検索したときと新ページのアドレスを検索したときで表示されるキャッシュが同じもので、動作は単純明快、二つのアドレスは同じページを表すものと解釈されているようです。
一方、 Google の場合、旧ページと新ページで異なる保存日時が表示されます (旧ページは 5 月 18 日、新ページは 5 月 27 日。なお、この「保存日時」は最後に更新の有無を確認した日時のことです)。しかも、旧ページのキャッシュとして表示されているのは 5 月 18 日時点の旧ページの内容でも新ページの内容でもなく、旧ページに Meta Refresh を設定した 5 月 6 日時点の新ページの内容です (5 月 6 日の次に新ページを変更したのは 5 月 13 日なので、それまでに取得された内容ということです)。 Google では、少なくとも Meta Refresh の取り扱いにおいて、内部で少し変な処理が行われているように見えます。このまま旧ページに置いた Meta Refresh ページを更新しないと、旧ページの「保存日時」は新しくなるのに、キャッシュとしては古い内容が表示されるということが起きそうです。
Firefox 2.0.0.4 がリリースされました (スラッシュドットの記事で知りました)。僕が今使っているのは 2.0.0.3 なので、 Administrator でログオンし直して Firefox を起動してみます。無事に自動的に更新されるでしょうか。
嫌な予感が……。
Firefox を再起動すると、無事に Firefox 2.0.0.2 がインストールされました。めでたしめでたし。いや、めでたくないぞ。うがー。
Firefox 2.0.0.2 になったところで改めて更新を確認したら、 Firefox 2.0.0.4 が表示され、今度こそ無事に更新できました。 2.0.0.4 にした後で再び 2.0.0.2 への「更新」を要求されたらどうしようと思いましたが、そんなことは起きませんでした。
何があったのかよくわかりませんが、ともあれ 2.0.0.4 に更新できて良かったです。
最近 Mozilla アプリケーション (主に拡張機能) のプログラミングに興味を持っています。『Creating Applications with Mozilla』の内容が古いので、新しい情報はないかと思って探していたら、 Mozilla Developer Center (MDC) の内容は少し読みにくいけれど割と正確そうだということがわかってきました。
ところで、 MDC の Introduction to XUL の中に次の文がありました。
“XPFE” is the term Mozilla-the-organization is using to describe Mozilla-the-browser's Cross Platform Front End, because X and C look similar if you beat them long and hard with a hammer.
(私訳)
「XPFE」は Mozilla (組織の方) が Mozilla (ブラウザーの方) の Cross Platform Front End のことを表すのに使っている用語である。 X と C はハンマーでがんがん叩いてのばすと似ているので、このような略称になっている。
うそー。
RSS 2.0 では XML 名前空間を使いません。そのため、 RSS 2.0 フィードと他の XML 文書を内容で区別する必要がある場合、「rss」という名前の要素をルートに持つ XML 文書を RSS 2.0 フィードと解釈するか、それよりもう少し条件を厳しくする程度のことしかできなくて、美しくありません。何とも乱暴な仕様です。
社会保険庁の年金記録の不備で年金が本来より少ない額しか支給されない人を救済するため、年金を請求する権利の時効を (条件付きで?) 撤廃する法案 (年金時効撤廃特例法案) が、今日未明に衆議院を通過しました。でも、もちろん時効が定められていることにも理由があります (時効がなかったらいつまでたっても過去のミスの分が請求される可能性が排除できず、支出額が確定しなくて困るなど)。こんな簡単に変えてしまって大丈夫なのでしょうか。
一つ前の項目で Google Gears を紹介しましたが、 Google Gears はベータ版です。今すぐ使えるものというつもりでは紹介していません。最近「ベータ版」と名の付くサービスが多くて狼少年になっているような気がするので、念のため、 Google Gears にバグが合った場合セキュリティーやブラウザーの安定性に問題が生じる可能性があることを指摘しておきます。インストールするならリスクを理解した上でどうぞ。
もちろん、ベータ版とはいえ Google の開発者は公開する前にいろいろと確認しているとは思いますが、それでもベータ版は製品版ではありません。