Thunderbird から Gmail に IMAP で接続して、メールを Inbox フォルダーから All Mail フォルダーに移動しようとしたところ、エラーが出ました。
音符付きで failure などと言われても困ってしまいます♫。
舌が回らず言葉の発音を間違えることを「噛む」 (「言葉を噛む」「台詞を噛む」とも) と表現する場合があります。僕の勝手な印象ではテレビのバラエティー番組で台詞を言い間違えた人に対して別の出演者が「おいおい、台詞噛むなよ!」と言って笑う、というのが典型的な用法です。この意味の「噛む」は基本的にはお笑いの社会だかテレビの社会だか、一部の社会でだけ通じる業界用語だと思っていたのですが、最近は少なくともウェブでよく見かけます。僕が知らないだけで、じつは普通の表現なのかもしれませんが、よくわからないので僕は一般の文章で使うのを躊躇してしまいます。
関連: 人力検索はてなでは、「噛む」のこの用法は舞台用語に由来すると書かれています。
1 月 16 日、 Google が iGoogle の外観をカスタマイズする機能「iGoogle Themes API」を発表しました。名前の「API」という部分が気になりました。 API とは application programming interface の略であって、下位層である基本ソフトやライブラリーなどを上位層であるアプリケーションから操作する方法の取り決めのことです。 iGoogle Themes API はテーマを記述した XML ファイルの仕様を定めているだけであって、主にアプリケーションから利用されるわけではありません。テーマを記述した XML ファイルをアプリケーションと捉えれば、 API と呼ぶことは妥当かもしれませんが、現時点では色や画像を現在時刻に基づいて変えることができるというだけの機能しかないわけで、これをアプリケーションと呼ぶのは背伸びだと思います。ただ、今後 Google は iGoogle Themes API を拡張していって、アプリケーションと呼ぶに値するものをテーマという形で作れるようにするつもりなのかもしれません。 (なお、今後誰かがテーマを作るためのアプリケーションを書くとして、そのアプリケーションから iGoogle を操作するための API なのだという説明は成り立たないと思います。 iGoogle はそのアプリケーションに部品を提供するわけではなく、下位層と上位層という関係にならないので。)
ただ、 Google には技術的に妥当でない名前を使った「前科」があることを思い出さずにはいられません。検索エンジンの中で「キャッシュ」機能を最初に提供したのは、僕が知る限りでは Google が最初で、後から他の検索エンジンも追随しました。しかし、高木浩光さんは「技術用語『cache』が政治的な言葉として拡大利用される」 (高木浩光@自宅の日記) において、 Google 等の検索エンジンがこの機能を「キャッシュ」と呼ぶのは不誠実ではないかと指摘しました。この機能は一時的なミラーであって、「キャッシュ」と呼ぶのは技術的には正しくなく、正しくない呼び方をしている理由はこの機能が著作権侵害であるとの批判を避けるためではないか、という議論です。僕は高木さんの指摘を読むまで検索エンジンの「キャッシュ」という名称に疑問を持っていませんでしたが、言われてみれば、極端な話、「無断ミラー」と書いてあったら Google を使うのすら躊躇してしまいそうです。呼び方が違うだけで同じサービスが良いことに見えたり悪いことに見えたりするなんて、言葉は怖いものです。
べつに Google が iGoogle Themes API に API という名前を使うことに何か裏があると思うわけではありません。ただ、 Google に限らない一般論として、言葉の正しさを気にしないのが当然という世の中にはしたくないと思います。少なくとも僕は言葉を誠実に使うようにしたいです。
「はてなブックマーク等で勝手に批判するのは良くない」とか「IPv4 なんて見切りを付けて IPv6 に移行するべきだ」とかという意見は、現状ではその意見が通っていないので、否定したくなることがあります。でも、現状と違うことを提案する意見だからというだけの理由で安易に考えを否定するのは慎みたいと思っています。現状維持を主張する人と変化を主張する人の言い争いは、現状維持を主張する人の立場の方が強くて公平でないように感じることが多いです。
先日「発言のリスト」の各項目に鉛筆アイコンを付けた際に、発言本文の中のリストまで一緒に鉛筆アイコンが付いてしまっていたのを修正しました。適切な li 要素にだけ CSS の list-style-image プロパティーを指定して鉛筆アイコンを付けたつもりだったのですが、 list-style-image プロパティーが継承されることを考慮に入れていませんでした。修正済みです。
なお、この鉛筆アイコンは IE 7 と Firefox 2 では表示されますが、 IE 6 では表示されないと思います。これは、スタイルシート中で IE 6 が対応していない子セレクターを使っているためです。
僕はスラッシュドットで「Windows は基本的に OpenType もサポートしている」と書いたことがありますが、これはちょっと語弊があったようです。 Michael Kaplan さんのブログ Sorting it All Out の記事「Looking for the Big O, not just some TT's」と「Microsoft *does* support OpenType!」によれば、 Windows Presentation Foundation を使わず GDI/GDI+ だけを使う場合、 Windows は OpenType フォントの機能の一部をサポートしないので、アラビア語等を正しく表示することができず、このことをもって「Windows の GDI/GDI+ は OpenType に対応していない」と言う場合があるそうです。
と、このように以前の発言に少し追加したい情報が出てきたときに、気軽に追記できたら嬉しいと思います。スラッシュドットでは技術的には今でもコメントを書けますが (ストーリーが公開されてから半年間くらいはコメントが書けるようになっていたと思います)、基本的には古いストーリーにはコメントを付けないのが普通なので、普通でないことをするのは少し勇気が要ります。
なので、とりあえずここに書くことで過去の誤りを修正した気分になっておきます。うーん。
発言のリストにアイコンを付けました。今のところ、全項目が同じアイコンなので情報量が少ないかもしれませんが。 YO さんがウェブサイト「アイコン王のフリー素材」で配布しているアイコンを改変したものです。
酒類の広告にはよく「飲酒は 20 歳になってから」とか「飲酒は 20 歳を過ぎてから」といった表示がありますが、「20 歳を過ぎる」は 21 歳になることを指すと思います。
年齢を整数ではなく実数と考えて「ぴったり 20.00 歳になった瞬間を過ぎる」と解釈すれば、「20 歳を過ぎる」で 20 歳になることを指すことも可能かもしれませんが、普通は年齢は整数です。言葉を補って「20 歳の誕生日を過ぎる」とすれば、 20 歳になることとほぼ同じことになります (1 日違いますが)。
なお、「お酒は二十歳になってから」あるいはそれと同趣旨の言葉を広告に入れることは、業界団体である「飲酒に関する連絡協議会」の「酒類の広告・宣伝及び酒類容器の表示に関する自主基準」 (2006 年 12 月 15 日改正) で決まっており、「お酒は二十歳になってから」も「飲酒は 20 歳を過ぎてから」も表示の例として示されています。以下抜粋。
II 広告・宣伝関連
1 未成年者の飲酒防止に関する事項
(1) 表示内容
国税庁告示「未成年者の飲酒防止に関する表示基準」に基づく場合に準拠するものとし、文言については、例えば「未成年者の飲酒は法律で禁じられています」、「飲酒は 20 歳を過ぎてから」、「お酒は二十歳になってから」などとする。
20 歳未満の人のの飲酒は未成年者飲酒禁止法という法律で禁じられています。
当サイトのアクセスログを見ていたら、こんな行がありました (IP アドレスは伏字)。
xxx.xxx.xxx.xxx - - [11/Dec/2007:21:40:55 +0900] "GET /#kosoku HTTP/1.1" 200 28729 "-" "Mozilla/5.0 (compatible; LiteFinder/1.0; +http://www.litefinder.net/about.html)" xxx.xxx.xxx.xxx - - [27/Dec/2007:09:01:22 +0900] "GET /#kosoku HTTP/1.1" 200 28703 "-" "Mozilla/5.0 (compatible; Gigamega.bot/1.0; +http://www.gigamega.net/bot.html)"
2 点おかしな点があります。 (1) 「kosoku」という fragment identifier が存在するのはトップページではなく「僕が間違って使った日本語表現」なので、おそらく http://www.unsanitized.net/incorrect-japanese/#kosoku への参照を誤って http://www.unsanitized.net/#kosoku への参照と解釈しているのではないかと思います。 (2) GET の後のパスに fragment identifier を付けるのは HTTP/1.1 の仕様に反します。 Apache では fragment identifier を取り除くようで、単に / と指定したのと同じ動作をしています。
(2) についての補足です。 HTTP/1.1 の仕様は RFC 2616 で定められていますが、 RFC 2616 では GET の後に書くパスの文法の定義が間違っており、 RFC 2616 の通りだと URI の query 部を含むことができません (例えば www.google.com に GET /search?q=test HTTP/1.1 と送るのが間違いということになってしまいます)。そのため、現在検討されている HTTP/1.1 仕様書の改訂案では定義が修正されています (RFC2616bis issue i11: URI includes query)。修正前でも修正後でも fragment identifier を付けるのは間違いです。
なお、 LiteFinder のページと gigamega.net のページ (www.gigamega.net は現在落ちていて見られないので Google キャッシュへのリンク) を見ると、文章がほとんど同じです。
LiteFinder Network Crawler is a research project started by a group of Indian candidates from the cities of Bangalore, Patna and Jaipur.
gigamega.net is a research project started by a group of Russian candidates from the cities of Saint-Petersburg, Nizhnii Novgorod and Novosibirsk.
どちらも研究プロジェクトを名乗っていますが、まともなサイトかどうかは疑わしいです。
Gmail でメールを送信するとき、ユーザーが送信の操作をした後実際の送信の処理に入る前に 30 秒から 1 分程度待って、その間は送信を取り消せるようになると嬉しいです。送信するつもりがないのに (例えば隣の保存ボタンと間違えて) 送信ボタンを押してしまった場合に、 30 秒もあれば気付いて取り消しの操作ができると思うので。
こういう機能は以前からほしいと思っていたのですが、 Gmail を使い始めて 1 年、ついに実際に間違ってメールを送信してしまって、思いを強くしました (なお、今回間違って送信してしまったのは、間違えて送信ボタンを押したためではありません。いまだに何が起きたのかよくわかっていないのですが、メールの下書きの最中に気付いたら送信されてしまっていたのです。詳細はわかったら書きます)。
なお、送信ボタンを押したら「送信してもいいですか?」という確認メッセージを出す、というのは同じ問題に対する下手な解決方法ですので、念のため。
メールの送信以外にも、迷惑メールフォルダーやごみ箱の中のメールの削除など、本質的に取り消せない他の操作についても同様の方式が提供されると良いと思います (ごみ箱は今のところ僕は使っていないので、個人的にはどうでも良いですが、一貫性のためごみ箱も同様の方が良いのは確実です)。
著作物の私的利用の範囲を制限する方針に反対する、インターネット先進ユーザーの会 (MIAU) は、今年 10 月から 11 月にかけての文化庁文化審議会著作権分科会私的録音録画小委員会の中間報告に関するパブリックコメント募集に対し、文例集や「パブコメジェネレータ」を提供し、 MIAU の主張に賛同する人が大同小異のパブリックコメントを量産するのを助長しました。 MIAU はパブリックコメントに数の勝負という要素を持ち込んだわけです。
パブリックコメントにおいて数で勝負する意図は、文例集や「ジェネレータ」の公開によって明らかだと思いますが、 MIAU が 12 月 19 日に発表した私的録音録画小委員会の第 15 回会合に関する緊急メッセージの中の次の部分にも表れています。
私たち MIAU は、「違法サイトのダウンロード違法化」の問題について、パブリックコメントにおいて反対意見を表明いたしました。さらに、報道によれば、他にも当団体以外にも相当多数の反対意見が寄せられているとのことです。相当多数が反対を表明しているにもかかわらず、パブリックコメントにおいて少数にあたる意見を多数意見への具体的な配慮措置なくして採用することは合理的根拠に乏しいものと MIAU では考えています。
パブリックコメントでの数の勝負という方針が良いと考えるかどうかはあなた次第ですが、 MIAU の手法に賛成する前に、 MIAU の方針がそういうものだということは知っておくべきだと思います。僕は今のところ、 MIAU の方針に疑問を禁じえません。
なお、パブリックコメントで数の勝負を繰り広げることで著作権制限側 (MIAU の主張に賛成する側) が損をする可能性については、 bewaad さんの 10 月 28 日の記事「パブコメは数じゃないんだよ、兄貴!」が参考になると思います。
それにしても、弁護士の懲戒請求にしてもパブリックコメントにしても、署名活動と勘違いしている人がたくさんいるようで不思議です。
発言のリストが長くなったので、発言本文をいったん読み込んだ後非表示にするのでは、ページの読み込みの後しばらく本文が表示されていて、もっさり感がありました。そこで、発言本文をページ読み込みの完了後に取得するように変えました。
XMLHttpRequest を使って非同期通信を行うプログラムは書きにくいです。そこで、これを機に Concurrent.Thread ツールキットを試してみました。このツールキットを使うと、普通に書いた JavaScript プログラムがマルチスレッドで動くようになります。同期的な読み込みをしてもブロックしないので、プログラムがとても書きやすくなります。「発言のリスト」で必要な JavaScript プログラムは短いので、 Concurrent.Thread を使うことによる書きやすさのメリットよりも速度低下のデメリットの方が大きく、結局「発言のリスト」では Concurrent.Thread を使わないことにしましたが、大規模なプログラムを書くならこれは非常に役立つだろうと思いました。
非同期通信を使ったプログラムを手で書くときは、まず同期通信の場合のプログラムを考えて、それを継続渡し形式 (CPS) に変換することになります。 Concurrent.Thread ツールキットの内部では、プログラマーが指定した関数の文字列表現を自力で構文解析して、 CPS 変換を施して、自前のスケジューラーで少しずつ実行しているのだそうです。よくこんなの作れますよね!
Concurrent.Thread ツールキットは時分割によってプリエンプティブなマルチスレッドを提供します。ところが、今のところ Concurrent.Thread ツールキットには JavaScript スレッドどうしの間や JavaScript スレッドとそれ以外の動作 (ユーザー操作など) の間の同期をとる方法が用意されていないようです。 Concurrent.Thread.TIME_SLICE の値を変化させることで、プリエンプティブなマルチスレッドを擬似的にノンプリエンプティブのように使うことはできますが、これは場当たり的なので、もっと綺麗な同期プリミティブがあると良いのではないかと思います。
バージョン管理システム git の開発者として有名 (!?) な Linus Torvalds さんが、同じくバージョン管理システムである Subversion を無意味と批判したそうです。リーナス・トーバルズ「Subversion ほど無意味なプロジェクトはない」 (satolog; Satoshi Tanabe さん) がはてなブックマークの注目エントリーになっていて知りました (動画自体はまだ見ていません)。僕は Subversion が好きですし無意味だとは思いませんが、この話に影響されて、僕も Subversion に対する不満を書いてみます。
その前に、 Subversion の短い説明をします。 Subversion は、それまでフリーのバージョン管理システムの事実上標準であった Concurrent Versioning System (CVS) の欠点を改善することを目指して設計・開発されました (Subversion Book より、 Subversion's History)。実際、 Apache httpd や GCC など多くの有名なオープンソースソフトウェアがレポジトリーを CVS から Subversion へと移行しています。
Subversion は CVS よりレポジトリーに多くの情報を格納します。追加したファイルが新規かコピーかの区別や、どの変更とどの変更が一つの変更か、など。これによって、うまく使えば更新記録を追いやすくなったり変更途中の互換性のない組合せをチェックアウトしてしまうことを防げたりします。でも、細かい情報をうまく使うのは非常に難しいです。難しさの原因は、僕の経験不足もあるのでしょうが、ソフトウェアの設計にもあると思います。
CVS でも Subversion でも、原則としてコミットの操作ミスは許されません。 CVS でも Subversion でも、コミットするつもりのない変更を間違ってコミットしてしまうというミスが起こりえますが、 Subversion の場合はほかにも、同時にコミットするべき変更を一部だけコミットしてしまうとか、その逆で別々にコミットするべき変更を一緒にコミットしてしまうとか、本来コピーとして追加するべきファイルを新規として追加してしまうとか、そういう「誤り」が起こります。 Subversion の使用法に習熟すれば間違えないのかもしれませんが、少なくとも CVS よりもコミットの情報量が増えた分、気を遣うことが増えたのは確実です。利用者の注意力に頼るのではなく、利用者に間違わせない、あるいは間違っても後で簡単に直せるようにするというのが、使いやすいユーザーインターフェースの鉄則です。
とはいっても、じゃあどうすれば良くなるかと問われると、今のところ僕にはわかっていません。レポジトリーの形式が今のままでは、後から一つのコミットを複数に分割するなどの変更は非効率にならざるを得ないでしょうから、少なくともレポジトリーの形式は変えないと解決しないでしょうが。
この前、数式フォントである STIX フォントにひらがなの「の」が含まれると書きました。その理由は今もよくわからないのですが、 Unicode Technical Report #25: Unicode Support for Mathematics でも数式の中に現れる文字の例として「の」が出てくることに気付きました。他の例としてキリル文字の「Ш」 (U+0428 CYRILLIC CAPITAL LETTER SHA) や漢字の「中」 (U+4E2D) が挙がっています。
僕は、「の」も「Ш」も「中」も数式中で見たことがありません。でも、何となく「Ш」ならあっても良いかもしれず、「の」や「中」だととてもおかしいように感じます。この差にはべつに深い理由があるわけではなくて、見慣れていない字が見慣れない文脈で出てきてもおかしいと思わないけれど、普段見慣れている字が見慣れない文脈で出てくると違和感を覚えるというだけのことでしょう。
Thunderbird から Gmail に IMAP で接続して、メールを Inbox フォルダーから All Mail フォルダーに移動しようとしたところ、エラーが出ました。
音符付きで failure などと言われても困ってしまいます♫。
10 月 31 日、 STIX フォントというフリーの数式フォントのベータ版が公開されました。 STIX フォントプロジェクトの発足が 1996 年なので、ベータ版の公開までに 11 年かかったことになります。
これまでも TeX 用にフリーの数式フォントが存在しましたが、 TeX 特有あるいは独自の文字コードを使っているためウェブブラウザーなど他のソフトウェアで使うのは困難でした。 STIX フォントは文字を Unicode で表現しており、ソフトウェアを選ばないようになっています。 Unicode に数式用文字が多数追加されたのも、 STIX フォントプロジェクトの成果のようです。
STIX フォントにはラテン文字、ギリシャ文字、キリル文字が含まれていますが、日本語の文字は含まれていません。それは当然、と思ったら、なんと日本語文字のうち平仮名の「の」 (U+306E HIRAGANA LETTER NO) だけ含まれています (フォント名「STIXGeneral」)。もしかして、集合論で無限の濃度を表すときにヘブライ語のアレフ (א) を使うように、「の」という平仮名が数式で記号として使われることがあるのでしょうか。
参考: 数式用のフリーなフォント STIX Fonts がベータテストを開始 (スラッシュドット)、 In Celebration of the STIX Fonts: Was the Product Worth the Wait?: Yes, Most Definitely! (Council of Science Editors 第 50 回定例会発表資料; Barbara Beeton さん、 Tim Ingoldsby さん)。
JavaScript 改め ECMAScript の次期バージョンである第 4 版の概要を読んでみました。アプリケーション開発に使いやすいように、静的型検査ができるようになっています。
ECMAScript 3 では、 obj.func(...) の形ではなく単に func(...) の形で関数を呼ぶと、呼ばれた関数 func の中では必ず this がグローバルオブジェクトになりました。これは func が現在実行中の関数の中で定義されていても同様でしたが、 ECMAScript 4 ではよくある使い方に配慮して、 func が現在実行中の関数の中で定義されている場合、 func(...) の形で関数を呼ぶと this の値が変化しないようになりました。この仕様を知っていればプログラムを書きやすくはなるでしょうが、ますます仕様を知らないと訳のわからない言語になっているように思います。こういう変化って、良いのか悪いのかよくわかりません。
発言のリストのページを Google のキャッシュ等で見ると、「本文」というリンクが文字化けしていたのを修正しました。原因は、そのページから呼び出している JavaScript ファイルの Content-Type に charset 指定が付いていないことでした。また、 Content-Type に charset 指定を付けるだけでは IE 6 では不十分という記述を「IE6 で異なる charset の JavaScript の読み込み方法」 (World Wide Walker; yoosee さん) で読んだので、ついでに HTML 文書中の script 要素に charset 属性を付けておきました。
また、以前僕は JavaScript の MIME type として text/javascript を使っていると書いていたのですが、今見たら、ロリポップレンタルサーバーでは .js ファイルの MIME type は application/x-javascript になるようです。騙された (誰も騙していません)。気分の問題ですが、 text/javascript に変えてみました。何か悪影響に気付いたら戻します。
7 月に「最近の fcp」過去ログのページを月単位で分割して以来、ずっと過去ログへのリンクが切れていましたが、ようやく修正しました。
Gmail アカウントに POP だけでなく IMAP でもアクセスできるようになるようで、既に一部のアカウントでは IMAP を有効にできます。スラッシュドットの記事「Gmail が IMAP サポートを開始」で知りました。僕のところでも使えています。 Official Gmail Blog にも記事が出ています。
Gmail のウェブインターフェースでのラベルが IMAP でのフォルダーに対応します。複数のラベルが付いたメールは IMAP では複数のフォルダーに表れます。
ウェブインターフェースでのラベルはスレッド単位でしか付けられませんが、 IMAP では一つのスレッドの中の複数のメールを別々のフォルダーに入れることができます。 Gmail アカウントに IMAP でアクセスして、スレッドの中の一部のメールを A というフォルダーに入れ、一部のメールを B というフォルダーに入れた場合、ウェブで見るとこのスレッドに A と B という両方のラベルが付いているように表示されます。ただし、内部ではラベルをスレッド単位ではなくメール単位で管理しているようで、ウェブから「label:A 検索語」のように入力してメールを検索した場合は実際に A というラベルが付いているメール (IMAP で見たときに A というフォルダーに表示されるメール) だけが検索対象になります。
2 月 11 日に公開した某サイト風ウィキペディアのタイトル画像を作り直して、少し某サイトに近付けました。 SVG ファイルを手で書いて、昨日取り上げた Batik のラスタライザーを使って PNG 画像に変換しています。 SVG 形式でも公開しますが、 Firefox 2.0.0.7 ではフィルターや文字の回転が正しく描画されないようです。
ところで、以前の画像は GIMP で作ってあったのですが、いつの間にか元の GIMP 画像ファイルを消してしまっていました。大した画像でもないのですが、間違って消したとわかると少しがっかりします。
LaTeX の jsclasses で 10pt 以外のサイズを指定すると、 geometry パッケージが正しく動作しません。これを簡単に解決するには、 geometry パッケージを呼ぶときに truedimen オプションを指定します。
Batik は SVG 形式の画像を扱うための Java ライブラリーです。 Batik に付属の SVG ラスタライザーというプログラムを使うと、 SVG 画像を PNG, JPEG, TIFF 画像にラスタライズ (ビットマップ化) することができます。
Batik の SVG ラスタライザーでは、 SVG 形式の画像ファイルを PDF 文書に変換することもできることを知りました。最初、 PDF ではベクター形式画像が扱えるのにラスタライズされてしまうのはもったいないと思ったのですが、この「ラスタライザー」は、 SVG のフィルターや半透明などを使わない単純な SVG 画像を PDF 文書に変換する場合、名前に反して画像をラスタライズしないのだそうです。
なお、このプログラムで SVG 画像を PDF 文書に変換するには、 Batik 以外に FOP ライブラリーが必要ですが、 Batik のバイナリー配布を取ってくる場合は FOP のコンパイル済みバイナリーも同梱されているのでそれだけで動きます。実際の PDF 文書の生成は FOP ライブラリーが行っています。
昨日から突然、家からインターネットにつながらなくなりました。普段は ADSL 接続を使っていて、 ADSL モデムが DHCP サーバーになっているはずなのに、 PC が IP アドレスを取得できないと文句を言います。 ADSL モデムを目で見ても普通に光っています。 ADSL モデムの状態を詳しく知るために ADSL モデムの管理コンソールを開こうとしても、 IP アドレスが取れない状態で ADSL モデムに HTTP 接続できるはずもありません。 PC を再起動したり、ウイルス対策ソフトのファイアウォール機能を一時停止してみたりしましたが、変わりません。結局、昨日は諦めてインターネット接続なしで過ごしました。
今日になっても相変わらずです。さて、どうしましょう……。駄目でもともと、とりあえず ADSL モデムの電源を切って入れ直してみたところ、何事もなく動くようになりました。何これ。
まあ、無事に直って良かったのですが、単に電源を入れ直すだけのことを思いつくのに 1 日かかったのは少し悔しいです。
PowerPoint 2003 では、文字を選択して Ctrl+[;] (日本語キーボードの場合。ヘルプには Ctrl+[=] と書いてあるので、英語キーボードだとそうなのでしょう) を押すと選択範囲の文字が下付きになり、もう一度 Ctrl+[;] を押すと下付きが解除されました。上付きは Ctrl+Shift+[;] になるだけで同様でした。ところが、 PowerPoint 2007 ではキーボードショートカットで上付き・下付きを解除することができないようです。僕は上付き・下付きをよく使うので、これは非常に困ります。
Word 2007 で文章に脚注を入れるには、リボンの「参考資料」タブを選び、「脚注の挿入」コマンドを選びます。この「参考資料」というタブの名前は意味がわかりません。このタブには目次・脚注・引用文献・図表番号・索引・引用文など、よそから番号や文章を取得して挿入する操作が並んでいます。こういうのは、日本語では「参照」、英語では「reference」と言います。実際、英語版の Word 2007 ではタブの名前は「References」になっています (英語版のヘルプ)。さらに、「reference」という英単語には「参考資料」という意味もあります。……つまり、「参考資料」は「References」の誤訳で、正しくは「参照」とするべきです。
Word は大きなソフトウェアなので、細かいところに誤訳があっても仕方がないと思いますが、こんな目立つ場所に誤訳があっては、少しでも日本語訳の確認をしたのかどうか疑いたくなります。 Word 2007 を含む Office 2007 のメニュー構造の大変更は、基本的には悪くないと思っていますが、それは変更後が良くできている場合の話です。僕はこの誤訳のせいで脚注の挿入の仕方がヘルプを見るまでわかりませんでした。誤訳のせいで機能のありかがわからないのでは、新しいユーザーインターフェースが良いか悪いか以前の問題です。
僕は一人で使う Windows PC であっても、普段は制限ユーザーで使っていて、特権が必要なときだけ「別のユーザーとして実行」を使うか管理者でログオンし直しています。こうすることで、システム全体に影響が及ぶような操作を意図せず実行してしまう危険が減ります。ただし、逆に特権が必要になるたびに管理者ユーザーのパスワードを入力する必要があります。
これまでそういうものだと思って使っていたので、特に不満はないのですが、 Windows Vista ではそんな面倒なことをしなくても、普段から管理者ユーザーでログオンして使っていればよいのではないかと思い当たりました。
Windows Vista のユーザーアカウント制御 (UAC) の動作について、 Windows Vista User Account Control step by step guide (Microsoft TechNet) と The Windows Vista and Windows Server 2008 developer story: Windows Vista application development requirements for User Account Control (UAC) (MSDN Library) を斜め読みしました。 UAC が有効の場合、管理者ユーザーがログオンすると、 Admin Approval Mode という状態になります。 Admin Approval Mode では、プロセスは標準ユーザー (Windows XP 以前では「制限ユーザー」と呼ばれていた) と同じ権限でしか動きません。 Admin Approval Mode で管理者権限を要求する実行ファイルを実行しようとすると、「実行ファイルが管理者権限を要求しているが、認めて大丈夫か」と問う consent prompt ダイアログボックスが表示されます。ユーザーが consent prompt を承認して初めてプロセスに管理者権限が与えられます。
ということは、管理者でログオンしたとしても、管理者権限を必要とする操作を意図せず実行してしまうのは防げているように思います。試してみないで、調べたことを書いているだけですが、これで合っているなら、個人で使う Windows システムにおけるセキュリティー上望ましいユーザーアカウントの管理方法は Vista で大きく変わることになるのではないかと思います。でも、「XP 以前では制限ユーザーを常用するべきだが、 Vista では管理者ユーザーを常用しても大丈夫」なんて解説は読んだことがないので、何か僕が勘違いしているのかもしれません。
7 年前の 2000 年 9 月にテレビのニュース番組の中でキャスターが言った言葉がいまだに忘れられません (言い回しは違うかもしれません)。
介護保険制度が始まって 5 ヶ月がたち、 6 ヶ月目に入りました。半年目ですね。
趣味が悪くてすみませんが、僕が今までに観たニュース番組の間違いの中で最も面白かったものです。
Yahoo! カテゴリでは、 Yahoo! が特に優れていると認めるウェブサイト (クールサイト) にサングラスのアイコンを付けて表示しています。参考: Yahoo! カテゴリのアイコンの説明。
Yahoo! はクールサイトだそうですが、 Google はクールサイトではないそうです。 Yahoo! は良いサイトだと思いますが、自画自賛……?
ちなみに、 日本以外の各国の Yahoo! もクールサイトでないらしいです。同胞を貶めて自分だけのし上がろうとしている……わけではなくて、これはたぶん日本語話者にとって有用かどうかでクールサイトの認定を決めているからでしょう。
google.co.jp の英語版と google.com の英語版とは少し見かけが違います。 google.co.jp 英語版ではロゴが「Google Japan」になるのは知っていたのですが、「Web Image Video News Maps Gmail more」というメニューの位置も違うことに気付きました。
また、メニューの中の「more」のリンクの動きも違います。 google.co.jp では「more」は More Google products へのリンクになっているので、検索結果の画面から「more」を選ぶと検索語が消えてしまいます。一方、 google.com では「more」はスクリプトで動くようになっていて、検索結果の画面から more の中の Blog Search 等のリンクを選ぶと同じ検索語で自動的に検索してくれるようになっています。 more の中の検索を使う場合には google.com の方が少し便利です。
google.com の方が新しいということでしょうか。そうだとすると、そのうち google.co.jp 英語版や日本語版でも google.com 英語版のようなメニューが使われるようになるのでしょう。
google.co.jp 英語版:
google.com 英語版:
発言のリストとして僕が当サイト以外で行った発言へのリンクを載せていますが、一部の発言について本文も載せてみました。
下の二つは最初 9 月 8 日と書いていましたが、 9 月 9 日の間違いでした。日付を間違えるのはしょっちゅうです。
「さっきの話はネタだから本気にするなよ」のように「ネタ」を「冗談」の意味で使う用法は、どうも好きではありません。この用法はここ数年のうちに生まれたのではないかと思っていますが、真偽を簡単に確かめる方法が思いつかないので、本当のところはよくわかりません。「年金問題をネタにした漫才」のような用法から転じて冗談そのものを指すようになったのではないかと予想しています。
ところで、僕自身、 2 月 11 日には「一発ネタ」という言葉を使っています。これは「ネタ」を「冗談」の意味で使う用法に非常に近そうです。好きでないとか言っておいて、別の場所では自分でまったく気にせずに使っているのだから、矛盾していますね……。まあ、僕の言葉の好き嫌いなんてその程度のものだということでしょう。
Perl では原則として文字列を UTF-8 で符号化して記憶します。このため、 Perl で文字列を扱う場合の原則的な手順は、読み込みの時に UTF-8 に変換し、処理はすべて UTF-8 で行い、出力の時に所望の符号化方式に変換するというものになります。ただし、あくまでもこれが原則というだけで、最初から最後まで US-ASCII の文字列だけで済む場合などには変換の処理を省略する場合もあります。
さて、 Perl の encoding プラグマを使えば、スクリプトをシフト JIS コードなど好きな文字コードで書くことができます。しかし、文字コードの変換のための Encode モジュールを同じスクリプト内で使う場合、 encoding プラグマを使うのは避けた方が無難のようです (少なくとも僕の理解度では)。スクリプト中に US-ASCII 以外の文字を書きたい場合、 UTF-8 で書いて utf8 プラグマを使う方が簡単です。
例えば、
use Encode ();
my $s = Encode::decode('SHIFT_JIS', "\x93\xFA\x96\x7B\x8C\xEA");
printf "%vX\n", $s;
というコードを実行すると、シフト JIS コードで「93 FA 96 7B 8C EA」は「日本語」という文字列であって、この 3 個の漢字の Unicode でのコードポイントは U+65E5、 U+672C、 U+8A9E なので、
65E5.672C.8A9E
と出力されます。このプログラムの先頭に use utf8; という行を加えても動作は変わりません。しかし、 use utf8; の代わりに use encoding 'SHIFT_JIS'; や use encoding 'UTF-8'; と書くと、
Wide character in subroutine entry at C:/Perl/lib/Encode.pm line 166.
といって怒られます。
エラーになる理由は、 encoding プラグマを使うと "\x93\xFA\x96\x7B\x8C\xEA" という文字列がバイト列から Unicode 文字列に自動的に変換されてしまうからです。後日、もう少し詳しく調べて書こうと思います。
外国語として日本語を勉強している人が、「日本語には平仮名と片仮名という 2 種類の表音文字があるのが、ややこしくて嫌だ。こんなの冗長じゃないか」と言っていたので、「英語には大文字と小文字があるけど、それも嫌なの?」と尋ねたら、一つの言語に 2 種類の表音文字があるのはおかしなことではないという点を納得してくれました。わーい。
でも、本当には平仮名・片仮名と大文字・小文字というのはだいぶ違うかもしれません。その人は、「今まで大文字と小文字というのは一つの文字で、大文字と小文字の違いというのはただの装飾だと思っていた」と教えてくれました。英語の場合、語を大文字で書くか小文字で書くかはある程度自由ですが、日本語の平仮名と片仮名の場合は原則としてどの語にどちらの文字を使うかが決まっているので、平仮名と片仮名の違いを一つの文字の装飾の違いだと考える人はあまりいないでしょう。世界の文字を集めたウェブサイト Omniglot でも、ラテン文字は大文字と小文字を合わせて一つの文字体系 (writing system) として扱っていますが、平仮名と片仮名は別々の文字体系として扱っています。
こんなことを言うと、その人にはまた「ややこしくて嫌だ」と言われてしまうかもしれませんが。
昨日通りを歩いていたら、「サマージャンボ宝くじー、発売中でーす」と宝くじ売り場の前で声をかけている人がいました。「本日ー」と言うので、発売期間の最終日なのかと思ったら、「期間中最後の大安となっておりまーす」と続いて、何か騙された気分になりました。ちなみに、今日がサマージャンボ宝くじの発売最終日です。
ネットワーク上のいろいろなサービスにおいて、ユーザー認証をパスワードだけに頼るのはどうも不安です。例えばクレジットカードなら、今まで日本で使われていたカードが突然外国で使われると、カード会社から確認の電話がかかってくる場合があるそうです。カードを使うたびに電話で確認されたら不便ですが、かといってカード番号 (と暗証番号) だけ合っていれば全部成功としてしまうと危険、というジレンマを解消するために、「認証成功」と「認証失敗」の間に「不審な点があるのでもう一つテストする」という選択肢を設けているわけです。こんな感じで、明らかにおかしい場合以外であっても、何か不審な点がないかどうか調べてくれると、今より安心できるように思います。
昨日の続き。 Thunderbird の withAttach 拡張を一日使ってみると、いくつか不満が出てきました。
自動保存のときの問題については、 withAttach の中にもこの問題に対処しようとしている跡が見つかるのですが、コメントアウトされています。拡張機能を自分で書けるようになると面白そうだと思うのですが、なかなか勉強できません。
メールを書いていて、「○○を添付します」とだけ書いて添付し忘れることがあります。後で添付の操作をするつもりで本文を先に書いていて、本文を書き終わったらいつもの癖でそのまま送信してしまうのです。「添付します」と書いてあるのに何もファイルが添付されていないのだから、メーラーが気付いて止めてくれればいいのに。
……とずっと思っていたのですが、探してみるものです。 Sogame さんの withAttach (バージョン 2.1.2) という拡張機能が既にありました。検索対象のキーワードに「.*添付します.*」を加えておくと、日本語のメールで本文に「添付します」が入っていて添付ファイルがない場合に確認してくれます。引用の中に「添付します」が現れる場合でも確認されるのと、送信ではなく保存するだけでも確認されるのが残念ですが、とりあえずこれでしばらく使ってみようと思います。
昨日は「もちろん」と書いてしまったのですが、
高校が一人の生徒を本人の志望と無関係に何十という多数の大学に合格させることが良いことだとはもちろん思いませんし、
なぜ僕はそれを良いことだと思わないのか、考えてみるとよくわかりません。
この高校あるいは受験者は何か不正をはたらいたわけではないように思います。入学するつもりのない生徒は受験してはいけないなんてルールはありません (僕は入学する気のない生徒が入試を受験することをあまり好ましく思いませんが、それは別のレベルの話)。大学の側でも入学するつもりのない生徒が受験することは織り込み済みなので、被害はほとんどありません。
受験料を高校が払ったか生徒 (あるいはその家族) が払ったかの差は、僕は重要でないと思っていますが、それを重要視するとしても、受験料を高校が払ってはいけないなんてルールはありません。同じ高校の他の生徒にとっては、本来別のことに使われるはずだったお金が、合格実績の水増しのために使われたというのは被害かもしれませんが、高校が一年間に使うお金に比べれば微々たるものだろうと思います。
合格実績の「水増し」というのは、真の実績よりも良く見せかけることだから、水増しされた実績を見て騙された人こそが直接的な被害者かもしれません。それに該当しそうなのは、 (1) 水増しされた合格実績を判断材料にしてこの高校に入学した生徒と、 (2) 水増しされた合格実績を判断材料にしてこの高校に本来以上の指定校推薦枠を与えてしまった大学でしょう。でも、 (1) については合格者数の宣伝だけを見て高校を選ぶわけではないでしょうし、 (2) についてはそもそも僕が指定校推薦の意義をよく理解しておらず、なぜ大学が合格者数の多い高校を優遇するのかわからないので、どちらも僕にはどうも具体的なイメージが湧きません。
つまり、僕は本件によって具体的に誰かが被害を被ったというような気はしないのです。でも、生徒が高校と協力して、高校からの合格者数を増やすために実体のない出願をしてしまう状況は、なぜか悲しいです。
僕は、「本来学校というものは教育に全力を注ぐべきだ」などといった固定観念に囚われた「べき論」が嫌いです。でも、今僕が感じるこの水増しへの嫌悪感は、本来的でないことへの嫌悪感のように思います。商業主義とは無縁であってほしい学校という存在が、宣伝のために小細工をするのが気に入らない、というのが今のところもっとも説得力のある説明です。固定観念が嫌いとかいくら言ってみても、結局僕は固定観念に囚われているということなのかもしれません。
恥ずかしいことに今日になってようやく知ったのですが、一部の高校で、大学に合格した延べ人数を増やすなどの目的で、生徒にセンター試験のみで合否を決定する多数の私立大学への受験を勧め、受験料を生徒に代わって払っていたことが問題になっているようですね。
高校が一人の生徒を本人の志望と無関係に何十という多数の大学に合格させることが良いことだとはもちろん思いませんし、それをした高校は当然批判されるべきです。でも他方、高校だけを責めても状況はなかなか改善しないでしょう。高校は何の理由もなく合格者の水増しをしたわけではないのだから、合格者の水増しをするインセンティブが生じるような状況を改善するべきです。どうすればいいのかは難しいのですが。
日刊スポーツ (ウェブ版) の 7 月 26 日付記事「静岡の私立高校でも有名大受験料負担」に気になる記述がありました (強調は引用者による)。
静岡県藤枝市の私立藤枝明誠高校 (塙博校長) が受験料を負担し、 2003 年から毎年、成績優秀な 10〜40 人の生徒に志望とは関係ない多数の有名私立大学の学部・学科を受験させていたことが 26 日、分かった。
同様のケースは関西の私立高校で発覚。塙校長は「合格者の水増し目的ではない」と強調する一方で「合格実績が上がると指定校推薦の枠が広がり、生徒募集に大きな力を発揮すると思った」と話している。来春からはやめるとしている。
生徒に志望とは無関係な大学を受験させて高校の合格実績を上げることをまさに合格者の水増しと呼ぶのではないかと思うのですが、それはさておき、カネさえ払えば水増し可能な「合格実績」によって大学の指定校推薦入試の枠が決まり、それによって高校の人気が左右されるのなら、高校に合格者の水増しをさせている一因は大学にあるということになると思います。
最初に書いたように、水増しを行った高校が悪くないなんて思いません。水増しをすると得そうだと思った高校が、そこでぐっとこらえなかったのは、悪いことだと思います。でも、全体を見渡す努力もせず、高校が水増しを行ったことだけを叩いていても、状況は改善しないと思います。一方で、もちろん大学が合格者数によって高校を優遇することを叩いているだけでも駄目で、今度は大学がそういうことをする理由に目を向ける必要があります。どういう理由か僕にはよくわかりませんが。優秀な生徒を学生として取りたいということなら、合格者数ではなく入学者数によって判断するべきでしょうし、受験料による収入が目的なら、受験者数によって判断するべきところでしょうから、高校別の合格者数というのが大学にとってどういう意味があるのか、僕にはよくわかりません。でも、現に大学が合格者数の多い高校を優遇しているのであれば、何の理由もないということはないでしょう。
ボーイング社が 12 年ぶりに新型の旅客機を発表し、シアトルの同社工場で現地時間の 8 日、最初の機体が公開されました。旅客機の名前は「787 ドリームライナー」で、現地の 07/08/07 (2007 年 7 月 8 日) に公開という演出がなされています。
787 は、同じ大きさの従来機種より「燃料効率が 2 割良い」 (20 percent more fuel efficient) のだそうです。同じ燃料の量で 2 割長く飛べるのと、同じ距離を飛ぶのに必要な燃料が 2 割少ないのとでは違いますよね、などというのは細かい話なのでしょう。
今朝の NHK のニュースでは、従来機種より「低燃費」「燃費が 2 割良くなった」と言っていました。「燃費」というのは字面では燃料消費量 (あるいは燃料にかかる費用) のように見えますが、少なくとも車の場合は燃料消費量あたりに走れる距離の数値のことを指します。この用法と「低燃費」という言葉は矛盾していますが、そういうもののようです。
適当にニュースサイトをまわって、「燃費」という言葉の用法を見てみました。燃費が「良くなる」「改善」と表現する例が多い中、 AFPBB News の 7 月 8 日付記事「ボーイング新型機の使用素材、航空機業界に革命か」では、
同素材の採用によって787ドリームライナーは燃費の抑制を実現。ボーイングによると、同機の燃費は同サイズの旅客機に比べ、約 20% 抑えられたという。
と、「燃費」を「距離あたりの燃料消費量」の意味で使っています。
先週、 Google ウェブマスターツールの「クロール率」について書きましたが ((1)、 (2))、今日見たら「多い」が選べるようになって、注意書きの内容が変わっていました。「要素」と「factor」の意味が解明できるかと思って日本語版と英語版を見比べたのですが……。
(日本語版)
Googlebot が、サーバーのリソースを過度に使用しないようクロールする頻度を制限しました。 より多くの Googlebot トラフィックを処理できる場合、[高速] オプションを選択することをお勧めします。
(英語版)
We've detected that Googlebot is limiting the rate at which it crawls pages on your site to ensure it doesn't use too much of your server's resources. If your server can handle additional Googlebot traffic, we recommend that you choose Faster below.
「要素」も「factor」もなくなっていました。これでは解明できません。残念。
「最近の fcp」過去ログが長過ぎるので、分割しないといけないなとは思っていたのですが、リンクを張り直すのが面倒でずっと放ってありました。とりあえず、リンク切れには目をつぶって分割しました。
「最近の fcp」のフィードは長いままです。 Feed paging and archiving について学んだら、最近の項目とそれ以外の項目に分割するつもりです。
1 月にも書きましたが、 Google ウェブマスターツールを使うと、誰かが Google で検索をして当サイトのページが表示された場合の検索語のリストを見ることができます。前回から約半年たったので、今日の時点での旧サイトの統計を載せておきます。サイトの内容がプログラミングに偏ってきたのを反映して、検索語もほとんどプログラミングに関係するものばかりになってきました。なお、新サイトはまだ Google のインデックスにほとんど入っていません。
別の携帯電話会社 (キャリアー) に乗り換えても今の電話番号をそのまま使うことができる「携帯電話番号ポータビリティー」という制度が導入されたのは 2006 年 10 月ですが、僕は最近までこの制度のことを「MNP」と略すことを知りませんでした。 mobile number portability の略だそうです。
この制度を使って携帯電話会社を換えることを、「MNP する」と表現する場合があるようです。 Google での検索結果は「"MNPする"」が 522 件、「"MNPした"」が 1,530 件です。この表現がどの程度の割合の人に受け入れられているのかわかりませんが、「MNP する」という表現を使う人にとっては、「MNP」は「携帯電話番号ポータビリティー」の略という以外にも意味を持っていることになります (「携帯電話番号ポータビリティーする」とは言わないでしょうから)。
「Windows 上の Apache でも動くパスワード変更 CGI の書き方」の中のサンプル CGI スクリプトが、サーバーの移行に伴い読めなくなっていました。ありがちなミスです。お恥ずかしい。
Apache で
AddHandler cgi-script .cgi
のように設定されている場合、ファイルの拡張子の一つとして .cgi が指定されていれば、 .cgi で終わっていなくても CGI スクリプトとして扱われます。 AddHandler ディレクティブによる設定を取り消すには RemoveHandler ディレクティブを使います。
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 というバージョンがあり、どこから「話」が標準で登録されるようになったのかはわかりません。
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 の開発者は公開する前にいろいろと確認しているとは思いますが、それでもベータ版は製品版ではありません。
ウェブアプリケーションをオフラインで使えるようにするためのプログラム「Google Gears」が発表され、ベータ版が公開されました。 Lifehacking.jp の記事「Google Reader がオフラインでも利用可能になる Google Gears 公開」等で知りました。
HTML 5 (Web Applications 1.0) や Firefox 3 等で議論しているのと同じ目的を達成するものをアドオンの形でさっさと実装してしまったということでしょうか。だとしたら、さすが Google というところです。参考: ウェブベースのアプリケーションをオフラインでも (Open Tech Press、 2007 年 3 月 16 日)、 Firefox 3 のオフライン機能って何だ？ (えむもじら、 2007 年 3 月 17 日)、 Firefox3 で、オフラインでも Google サービスを使える時代が到来?! (Buzzy Dizzy Biz、 2007 年 2 月 12 日)。
JIS X 0201 片仮名のことを「いわゆる『いわゆる半角カナ』」と呼んでライバルに差を付けよう!
当サイトのページは XHTML でない HTML で書かれています。たまに図や数式を入れたいと思うことがあって、 XHTML+SVG+MathML が使えたら便利かもしれないと感じますが、 Internet Explorer は XHTML に対応してくれないし、 SVG は仕様もまだ十分整備されていないし、 MathML はフォントが普及していないので、当面は XHTML の利点がなさそうです。
などと書くと、 XHTML の利点は利用者の側にこそある、という反論があるかもしれません。参考: html に戻りそう (JamGraffiti; 壱茉さん)。
でも、文法的に正しい HTML 文書を等価な XHTML 文書に変換するくらい、機械的にできます (例えば徳保隆夫さんの「文法違反文書の氾濫する中で」を参照)。もし HTML 文書ではなく XHTML 文書として提供されていることが利用者にとって価値があるのなら、ウェブページの翻訳ゲートウェイのように、 URL を指定して HTML から XHTML に変換するゲートウェイがあってもよさそうなものなのに、見たことがありません。ひょっとしたらあるかもしれないけれど、少なくとも広く知られてはいないでしょう。これは、文法的に正しい HTML 文書と文法的に正しい XHTML 文書の比較において、 XHTML であることが利用者にとって大して価値がないことを表していると思います。
ですが、当サイトのページが XHTML で書かれていたら嬉しいという人がいたら教えてください。たぶん僕はメールをもらっただけで舞い上がって、尻尾を振って XHTML に変えると思います。
アプリケーションプログラムを書くための言語として C/C++ は適さないと思います。言語の設計が古くて、コンパイラーの最適化との相性が悪いからです。
昔の C 言語では、プログラマーは何でも書いてよくて、コンパイラーは書いてある通りのコードを機械語に翻訳するだけでした。これではコンパイラーによる最適化の余地などありません。コンパイラーの最適化というのは、運が良ければ同じ動作をする速い機械語を生成してくれるけれど、運が悪ければ動作が変わってしまうものであって、しかも動作が変わらないか変わるかは長年の経験によって学ぶものでした。
それではあまりに不安定なので、今では C 言語の標準仕様でコンパイラーがどのような最適化を行ってよいかが規定されています。正確には、プログラムの動作はどういうときに未定義になるかが規定されています。けれど、この規定は非常に複雑なので、普通のプログラマーは理解できません。一見正しそうに見えるコードが、じつは言語仕様で定義されていない処理系の動作に依存していることもしばしばあり、結局普通のプログラマーにとってコンパイラーの最適化の結果が運次第であることに変わりはありません。
なぜこういうことが起きるかというと、一見何でも書けそうな言語になっているからです。この見かけの柔軟性と最適化の可能性は矛盾します。言語仕様を整えて、実際には「何でも書ける言語」でなくしたとしても、直感的な理解と現実の間にギャップを作っているだけで、直感的な理解と最適化の可能性が矛盾していることに変わりはありません。 C++ も C 言語の「何でも書ける」という幻想をそのまま維持しているので、同じ問題を抱えることになります。 C/C++ の言語設計が古いと僕が感じるのはこの点です。
これは C/C++ を作った人が馬鹿ということではなく、昔と今とでは必要なものが違っているということです。昔は正しく動けばよくて、最適化はおまけでもかまわなかった。今のコンパイラーには賢い機械語を生成する義務がある。アプリケーション開発のための現代的なプログラミング言語はこの要件を考慮して作られているので、 Java でも Caml でも C/C++ よりずっと直感的になっています。
とはいえ、アプリケーション開発が C/C++ を中心に回ってしまっているのは残念ながら止められません。多くのライブラリーやサンプルコードが C/C++ で書かれているので、 GCC が開発中止にでもならない限り、今後も C/C++ が使われていくことでしょう。それに、今ある他の言語だって例えば 20 年後には時代に合わなくなっているでしょうから、 C/C++ だけ避けても仕方がありません。理想的にはプログラマーがプログラミング言語に依存しないことが必要なのでしょうが、それはそれで学ぶのが大変です。結局すべてを解決する魔法は今のところありません。
5 月 15 日に GCC 4.2.0 がリリースされました。主な変更点のリストにも載っていますが、人によっては注意する必要がありそうなのが、新たに加えられた最適化オプション -fstrict-overflow です。符号付き整数型で、オーバーフロー (マイナス側も含む) を意図的に使うのは、 C/C++ 言語仕様から見ると間違いです。これをしている場合、 -fstrict-overflow を無効にする必要があります。具体的には、 -O2 を指定すると自動的に -fstrict-overflow が有効になるので、 -O2 を指定していてしかも符号付き整数型でのオーバーフローを意図的に使っている場合は、コードを修正するか、 -fno-strict-overflow オプションを付ける必要があります。符号なし整数型の演算の動作には影響ありません。
なぜ符号付きと符号なしで動作が違うのかというと、直接には C/C++ 言語仕様の定義がそうなっているからです。 C/C++ の標準言語仕様では、符号なし整数型での演算は型の最大値より 1 大きい整数を法とする演算とすることを定めていますが、符号付き整数型ではオーバーフロー時の動作を定義していません。 GCC 4.0.x までは符号付きでも符号なしでも同じ値を法とする演算をしていましたが、この演算を意図している場合は符号なし整数型を使うのが処理系非依存な方法です。符号なし整数型の動作についての参照を挙げておきます。標準仕様そのものは持っていないので、例によって ISO のウェブサイトから取れる作業草稿で。 C 言語は ISO C 言語標準化委員会の作業草稿 N1124 (2005 年 5 月 6 日付) 6.2.5 節 Types の第 9 項、 C++ は ISO C++ 標準委員会の作業草稿 N2135 (2006 年 11 月 6 日付) の 3.9.1 節 Fundamental types 第 4 項とそこにある脚注 46 です。符号付きの場合の動作についても対応する箇所を挙げるのが親切だと思いますが、僕自身がよく理解しておらず正しい箇所を特定できません。
最近のニュースはランダムであるように感じます。テレビのニュース番組を観る理由をあえて挙げるなら、世の中を理解したいからのような気がするのに、観ていると、こんなの理解しようとするだけ無駄という気がしてきます。以前はそうは思わなかったのに、最近よくそう思うのは、ニュースの内容が変化しているからではなく受け手である僕が変化しているからだと思いますが、嬉しくない変化です。
何でもいいから文章を書きたいとすれば、人の書いたくだらない文章に関して「その文章はくだらない」と主張する文章を書くのが簡単です。少なくとも、面白い文章に関して「面白い」と主張する文章よりは簡単です。だからついつい書きそうになります。でも、簡単にけなせるものをけなしても楽しいのは一瞬だけで (一瞬楽しいと感じてしまう僕は損な性格かもしれません)、後にはたいてい自分と他人に不快感を残すだけです。人を楽しませるような文章は書けなくても、せめて自分が後で読んで楽しめる文章を書きたいです。
例えば、あるブログを読んでいたところ、そのブログの作者を馬鹿にする失礼なコメントがありました。しかも、記事の主張に反対しているつもりらしいのですが、記事の主張を誤解している。それきた! 良いところなしの、くだらないコメントです (本当に良いところがないかどうかは別として、その瞬間にはそう感じたということです)。このコメントに対して、「なんだか必死になっているみたいですが、記事に○○と書いてありますよ。記事を読まずにコメントしてるでしょ?」という内容のコメントを書こうとしました。たぶん書いたら一瞬だけ優越感があることでしょう。でも、そんな文章を書いても面白いことは起きないと思い直して、何も書きませんでした。
これと似たことは数え切れないくらいしています。それなのに、くだらない文章を見かけるとまた手が動くわけです。面白いものよりくだらないものに惹き付けられたりしない人がうらやましい。せめて何か書いてストレスを発散するために、この文章を書きました。
ということで、昨日の続き。偽善とも面倒くさがりとも違う場合もあるみたいです。
二つ前の続き。僕の場合、悪口を抑えるのは偽善ではなく、打算と面倒くさがりの併せ技のような気がしてきました。
定食屋さんで「ご注文はお決まりですか」と聞かれて「○○○定食を」と答えたら、「以上でよろしいですか」と聞かれて戸惑いました。
この言葉は過去に何度か聞いていたので、もう慣れてきて、戸惑いはしても意味は取れるようになりましたが、最初は本当に「以上」が何を指しているのかわかりませんでした。何か別の言葉を聞き間違えているのかと思いましたが、しばらく考えて、「○○○定食ですね。以上でよろしいですか」の最初の文が省略されていると考えると一応意味が通ることに気付きました。であれば、僕が伝えた注文を指して、それで終わりで良いのかどうかを確認しているのでしょう。その可能性が高いと考えて「はい」と答えたら注文を処理してくれて、ちゃんと頼んだものが出てきたので、僕の理解は間違っていなかったようです。
……と言葉以前の思考を文章に起こしてみると、多少誇張されているように思いますが、少なくとも僕が店員の言葉の意味を理解するのに時間がかかったのは事実です。
僕の感覚では、「以上です」「以上でよろしいですか」のように話し言葉で「以上」と言う場合、直前に自分が読み上げたものを指して、「これで終わり」という意味になります。今の場合、店員は直前に「ご注文はお決まりですか」としか言っていないので、「以上」が指す対象が見つかりません。そのため、最初は理解できなかったし、今でも戸惑います。
以前気になって「この言葉って変だよね?」と知人に聞いたら「違和感を覚えない」とばっさり切り捨てられた苦い経験があるのですが (大袈裟)、僕の感覚がずれているのでしょうか。まあ、ずれていたとしても、じゃあ直します、とはたぶんいきませんが。
Google の検索履歴を見ました。たぶん自分で見るより人が見た方が面白いと思うので、載せておきます。
「最近の fcp」過去ログの URL を http://homepage2.nifty.com/polytope/diary.html から変えました。「正しい」とか「標準」とかいったことに完全に反する行為です。でも、プロバイダーのウェブスペースサービス程度の自由度では正しくするのは難しいです (当然ですが、そういうサービスを選んだ僕の責任です)。
まず、ウェブページのアドレスを変えるべきではありません。この時点でアウト。
しかも旧ページから新ページには 0 秒 Meta Refresh で飛ばしています。 Refresh ヘッダーフィールドなんて HTTP/1.1 の標準仕様にも HTTP/1.0 の informational RFC にもありません。やーい非標準。さらに、 HTML の仕様書にも Web Content Accessibility Guidelines 1.0 にも、 meta 要素を使ってリダイレクトするのを避けるよう書かれています (でも理由は納得できません)。
1 月 26 日に書いた内容を今更フォローアップ。同じお店でアナウンスをよく聞いたら、「運転の有無や年齢確認をさせていただく場合がございます」と言っていました (末尾は「あります」だったかも)。前のは聞き間違いだったと思われます。失礼しました。
ところで、「運転の有無や年齢確認を」の部分は、「や」が形の上では「運転の有無」 (あるいは「有無」) と「年齢確認」をつないでいるように見えるのに、実際には「運転の有無」と「年齢」をつないでいるという違いがあり、若干不自然です。「を」を確認の前に動かして「運転の有無や年齢を確認させていただく場合がございます」にすればこの問題は解決します。
ただし、ひょっとすると「年齢確認」から「年齢」単独になると表現の丁寧さが足りないかもしれず、「ご年齢」とした方が良いかもしれません。
『趣味の Web デザイン』の徳保隆夫さんに「最近よく読んでます」と書いてもらえて嬉しいです (3 月 1 日にも書いた通り、僕はミーハーです)。
「IT 系テキストサイト」と一言でまとめられているのを見て考えた結果、トップページ先頭の当サイトの紹介文を少しだけ変えました。最近プログラミング関係のことばかり書いていますが、それ以外もまた書く気が起きるときが来ると思います。
このサイトの中でサイト内の文章にリンクを張るときは、わずかな例外を除き URL にディレクトリ名だけを指定しています。末尾のスラッシュを除いたり、逆に「index.html」を付けたりしても参照できると思いますが、一つの文章に意味なく複数の URL を付けると、訪問済みの文章なのにリンクが未訪問の色で表示されたりして気持ちが悪いので、今のようになっています。
Perl では多くのスクリプト言語と同様、 "My name is $name." のように文字列中で変数を参照すること (interpolation) ができますが、式を参照するうまい方法がないので不便なことがあります。 @{[ ... ]} とか ${ \... } とかいう方法はありますが、どうもなじめません。そこで、 htpasswd.cgi の中では tie を使ってうわべだけ綺麗にしました。これと同じ方法を再利用しやすい形でパッケージ化した Interpolation パッケージというのがあるのを最近知りました。やっぱり同じことを考える人はいるもので、しかも汎用性のある部分だけ取り出してパッケージにしてしまうのだからすごいです。
Ruby には #{...} という構文があります (いいなあ)。なお、現在仕様を議論中の Perl 6 では Qc 'My name is { format_name($name) }.' のように書けるみたいです (Synopsis 2)。
今まで当サイトのトップページには HTML の文法違反があったのですが、面倒くさがって直していませんでした。トップページをフィードから編集するために自作のツールを使っていて、恥ずかしながらそのせいで直すのが少し面倒だったのです。文法違反文書の氾濫する中で (備忘録; 徳保隆夫さん) と HTML は何がいいのか (NULL::something; cho45 さん) を読んで、直す気が起きました。 3 か月ぶりにトップページから文法違反がなくなりました。
ずっと JavaScript ソースファイルの MIME media type は text/javascript だと思っていたのですが、 Scripting Media Types (RFC 4329) では text/javascript は obsolete とされていて、 application/javascript か application/ecmascript が推奨されています。
ただし、 Internet Explorer 7 は text/javascript しか認識しないので、僕は当面 text/javascript を使うことになりそうです。 Firefox 2 はどれも認識します。
「最近の fcp」はもともと、ちょっと面白いと思った小さな発見をほとんど説明抜きで書くというスタイルのつもりだったのですが、最近文章が長くなってしまっているので、今日は思い切って短。
メーラーがメールサーバーからメールを取得するための POP や IMAP といった仕様では、サーバーにメールが届いてもサーバーからクライアントに教えてくれるわけではないので、クライアントが定期的に新着メールがないかどうか確認しなければいけません。これでは効率が悪いので、クライアントからサーバーに、「メールが届いたら教えてください」と要求するための IMAP IDLE 拡張というものが提案されインターネット標準になり、多くの IMAP サーバーやメーラーで実装されています。しかし、メールサーバーに複数のフォルダーがあるとき、 IDLE 拡張では 1 個のフォルダーについてしか新着メールの通知を要求できないので、すべてのフォルダーの新着メールを知りたい場合にはフォルダーの個数だけ接続を張る必要があり、スケーラブルでありません。
これを改善するために、複数のフォルダーの新着メールをすべて知らせてくれるようサーバーに要求するための仕様も、次のように提案されているのですが。
こんなにたくさん提案されているなら、どれか 1 個くらい標準にならないものでしょうか……。
ちなみに、これらの草稿はどれも他の草稿を参照していません。素人考えでは、過去あるいは同時期に、部分的に同じ目的を達成するために書かれた草稿がある場合、相手を参照して共通点・相違点を明らかにした方が役立つ草稿になるような気がするのですが、そういうわけにはいかないのでしょうか。
昨日の続き。もう一つ誤解があるようなので。 network.http.pipelining を true にしても false にしても、 network.http.pipelining.maxrequests をいくつにしても、 Firefox がウェブサーバーから必要なデータを取り終わるまで接続を張ったままであることに変わりはありません。これはパイプライン機能の前提となる HTTP/1.1 の persistent connection という機能です (正確には、 Firefox が必要なデータを取り終わっていないのに自分から接続を切ることはありません。サーバーが接続を切る可能性はあります。また、 HTTP/1.0 でも不完全ながら persistent connection もどきを使うことはできます)。
ところで、 WinDump を使ってパケットキャプチャーを見ると、 Firefox 2.0.0.3 で network.http.pipelining が true で network.http.pipelining.maxrequests が 2 のとき、サーバーからの応答がある前に 3 個の要求を投げているように見えるのですが……。僕が WinDump の使い方を間違えているだけかもしれません。
重くなった Firefox 2.0 を劇的にスピードアップする 13 の方法 (オンライン快適仕事術; husigi さん) で、 Firefox の設定を変えて通信を速くする方法として、 about:config の中の network.http.pipelining を false から true に変え、 network.http.pipelining.maxrequests を 4 から 32 に増やすという方法が紹介され (今は文章は 32 ではなく 8 に修正されています)、「他のクライアントに迷惑をかける設定だ」として叩かれているという話を、同時リクエスト数って今でもクリティカルな問題なのだろうか (備忘録; 徳保隆夫さん) で知りました。
どうも誤解に基づいて非難している人が目立っているようなので、技術的なことを少しだけ書いておきます。
上の Firefox の設定をしてもサーバーの側の同時接続数は変わりません (「同時リクエスト数」というのは普通、同時接続数と同じ意味で使います)。実験して確かめたわけではありませんが、意味を考えればそうなるはずという理屈の上での話です。
一つのクライアントが一つのサーバーに同時に何本も接続を張るのは、行儀が悪いこととされています (少なくとも伝統的にはそう扱われてきました。今の実態に合うか合わないかは知りません)。ウェブサーバーの設定で一つの IP アドレスからの同時接続数を制限するのはよく聞く話です。参考: 最大接続数を増やして速くなったと喜ぶ人々、再び (狐の王国; 狐志庵さん)。
でも、これと HTTP/1.1 パイプラインのリクエストを増やすのとは完全に別個のことです。パイプラインに溜めておるリクエストをある程度以上増やしても、サーバーの側で処理待ちのリクエストが増えるだけです。処理待ちのリクエストというのは、文字通り、まだ処理されていないリクエストなのであって、それを増やしても速くなりません。そして、処理待ちのリクエストが増えたからといって、サーバーにも他のクライアントにもほとんど迷惑はかからないはずです。
HTTP/1.1 に対応していると名乗るのにもかかわらずパイプライン機能を使うと誤った動作をするウェブサーバーがあるらしいです (具体的な名前は知りません)。 Firefox のデフォルトの設定で、 network.http.pipelining が false、すなわち HTTP/1.1 パイプライン機能を使わないようになっている理由は、たぶんそれだと思います (が、クライアントが Server ヘッダーを見て自動的にパイプラインを有効にしたり無効にしたりするというのは無理なのでしょうか)。
Windows にはファイルシステムの操作をする fsutil というコマンドがあります。このコマンドは引数によっていろいろな操作ができ、その中で
fsutil file createnew myfile.dat 1000000
のようにすると myfile.dat という名前の 1,000,000 バイトのファイルが作られ、中身のバイトがすべて 0 に初期化されます。これは、 coLinux のディスクイメージを作るときなどに便利です。
普通の PC で 1 ギガバイト以上のファイルを作ると目に見える時間がかかります。これはファイルのサイズの分だけディスクにデータを書き込むからです。しかし、 fsutil file createnew ではファイルの使用領域を予約するだけで実際にディスクにデータを書き込むわけではないので、一瞬で終わります。参考: SetEndOfFile (MSDN Library)、 ultra fast binary writes (MSDN Forums)。
fsutil を管理者でないユーザーの権限で実行するとエラーになります (少なくとも Windows XP では)。でも、ファイルを作るのに管理者の特権は不要なので、 fsutil file createnew が管理者以外でエラーになるのはつまらない手抜きだと思います。
補足 1: MSDN Forums では情報が混乱していますが、 fsutil file createnew で作られるファイルはスパースファイルではありません。スパースファイルは飛ばしている部分についてディスクの容量を予約しませんが、 fsutil file createnew で作られるファイルはディスクの容量を予約します。 fsutil file createnew が速いのは valid data length が 0 のファイルを作るからです。
補足 2: SetEndOfFile のドキュメントには、 SetEndOfFile でファイルサイズを大きくすると差分の内容は不定になると書かれていますが、 fsutil file のヘルプ (Windows 2003 Server TechCenter) によれば、 NTFS では valid data length を超えた部分は 0 のバイトになるそうです。なお、 fsutil file のヘルプの該当部分の中に「C2 オブジェクト再利用の要件を維持するために」という謎の言葉がありますが、 C2 というのは米国の政府機関 National Computer Security Center が定めるコンピューターシステムのセキュリティーの評価基準の名前です。初期化されていないディスク領域が読めてしまうと、他のユーザーのデータの残骸が読めてしまうことになり、セキュリティーの欠陥になるので、そういう動作をしないよう 0 のバイトを返すという意味です。
昨日の続き。 Windows 機から NBT で Unix 機を参照するには、 Unix 機の側で Samba に含まれる nmbd サーバーを動かしておけばよいです。 NBT で使われるコンピュータ名はデフォルトでは Unix のホスト名になります。
ワークグループ名は smb.conf の [global] セクションの workgroup パラメータで指定します。 smb.conf のデフォルトの場所は Samba の configure のときに決まっており、 Fedora Core 6 で標準の RPM からインストールした場合は /etc/samba/smb.conf になりました。
NBT のコンピュータ名をホスト名と違うものにしたい場合は smb.conf の [global] セクションの netbios name パラメータで指定します。
Unix と Windows が一つのネットワークの中にあるとき、 Unix から Windows 機を NetBIOS コンピュータ名を指定して参照するための機能が Samba に含まれています。 Samba の libnss_wins.so をインストールし、 /etc/nsswitch.conf の hosts の設定に wins を加えると、 Unix での名前解決に NetBIOS over TCP/IP (NBT) を使ってくれるようになるので Unix から Windows 機を参照することができるようになります。参考: The Official Samba-3 HOWTO and Reference Guide > Integrating MS Windows Networks with Samba。
これは Windows 機に coLinux をインストールしてその上で Unix を動かす場合でも同じです (少なくとも tuntap デバイスでつなぐ場合は)。 VMware 等で Unix を動かす場合でも大差ないと思います。
逆に Windows から NBT で Unix を参照するには、 Unix で Samba サーバーを動かす必要があるのだと思いますが、調べていません。
Windows Vista ではハードディスクにある NTFS パーティションの大きさを変更することができます。「Windows Vista ヘルプ: ハード ディスクを再パーティションできますか」にあるように、 [コントロールパネル]-[システムとメンテナンス]-[管理ツール]-[コンピュータの管理]-[ディスクの管理] で変更したいパーティションを右クリックして、「ボリュームの拡張」または「ボリュームの圧縮」を選びます (名前は「ボリュームの圧縮」ですがデータ圧縮を行うわけではありません)。
でも、 Windows で自身の NTFS パーティションを縮小する場合、どれだけファイルが少なくても最初に作った大きさの半分より小さくすることはできないようです (ちゃんと調べていないので条件が怪しいですが)。パーティションの中央には MFT のミラー ($MFTMirr ファイル) と変更ジャーナル ($LogFile ファイル) があるので、その関係でしょう。未確認ですが、 ntfsresize か、内部で ntfsresize を呼び出す Gnome Partition Editor (GParted) などのソフトを使えば、最初の大きさの半分より小さくすることもできるみたいです。
スラッシュドットの「フレームワークを使っての開発は、オレってばスゲー感が少ない？」に、
慣れてくると手応えがないような気がしてくるような気はする。こう思うのは年寄りの証拠なのか、フレームワークはスゲー感を妨げるのかどっちなのだろう?
手法に慣れてくると簡単になって手ごたえがなくなるのは当然です。歳は関係ないし、フレームワークが達成感を妨げるわけでもないでしょう。慣れてきて達成感が薄れていくのが嫌な人は、慣れてきたらその上で新しいことに挑戦したり、慣れたものをあえて捨てて新しいことに挑戦したりするんだと思います。もちろん、達成感よりも優先するべきものがあるなら、達成感のない開発をしなければならないこともあるでしょう。でもそれはフレームワークのせいではないと思います。
というコメントを書こうとしてとしてコメントのプレビューを表示したら、「このアカウントもしくは IP またはネットワークは一時的に投稿禁止になっています。ちょっと落ち着いてから投稿してください。この措置はこの IP もしくはネットワークおよびアカウントから投稿されたコメントが多数回マイナスモデレーションされたことから、システムがあなたを自動的に荒しと疑っているためにとられていいます」と言われました。
たぶん 4 月 3 日頃に書いたコメント 4 個 (このコメント以下) が立て続けに「フレームのもと」「余計なもの」とモデレートされたからでしょう。投稿禁止はかまいませんが、書く前に教えてほしかった……。それとも、掲示板荒らしだと疑われているのにプレビューの段階で教えてもらえただけでも感謝するべきでしょうか。
「OS 開発の愉しみ」 (Prex - 組み込みリアルタイム OS 開発日記; Kohsuke Ohtani さん) は、対象は違っても、学習院大学の田崎晴明教授の logW 日々の雑感的なもの 2003 年 3 月 30 日の、「申し訳ないのだけれど、物理は特権的に面白いのですよ」前後の文章と似ています。
この二つの文章の著者には失礼かもしれませんが、森博嗣『夏のレプリカ』の次の部分を思い出しました (講談社文庫 (2000 年) 450 ページから引用)。
西之園萌絵は、杜萌と二人だけになると、ずっと犀川のことをしゃべり続けた。どんなに彼が魅力的な人物であるかを萌絵は力説したが、根拠は実に曖昧で、しかも、まったく論理性に欠けていた。それは、彼女が理屈を強調すればするほど鮮明になった。こんなことは、従来の西之園萌絵にはありえなかったことだ。
(確かに、萌絵は変わった)
杜萌は黙って彼女の話を聞いていたが、心の中では半分呆れていたし、ますますこの友人が好きになった。
今更ですが、久しぶりに行った秋葉原の LAOX ザ・コンピュータ館の書籍フロアー (6 階) で高林哲、鵜飼文敏、佐藤祐介、浜地慎一郎、首藤一幸『Binary Hacks ― ハッカー秘伝のテクニック 100 選』 (オライリー・ジャパン、 2006 年) がセキュリティーのコーナーに置かれていて驚きました。近くにケビン・ミトニック、ウィリアム・サイモン著、峯村利哉訳『ハッカーズ: その侵入の手口 ― 奴らは常識の斜め上を行く』 (インプレス、 2006 年) が置かれているのも手伝って、「ハッカー秘伝のテクニック」を実行したら法に触れそうな雰囲気です。
昨日 NHK のニュースでキャスターがこう言っていました (正確には憶えていません)。
ページを開くと物が立体的に現れる、「飛び出す絵本」の人気が高まっています。
「飛び出す絵本」という言葉を聞くまでの数秒間、ウェブページの話だと思っていました。
以前「たまご」というソフトウェアの情報を知りたくて、検索エンジンで「たまご」と入力したら、関係ない話ばかり出てきたときと同じ気分です。
そういえば、「定規とコンパスを使った作図」で使っている図は Inkscape で描いたのでした。 3 月 23 日にバージョン 0.45.1 が出たばかりです。
「定規とコンパスを使った作図」の中で「藤﨑源二郎」という数学者の名前が出てきますが、この名前の「﨑」の字は右上の部分が「大」ではなく「立」になっています。この字は Unicode に U+FA11 として含まれます。
ところが、 U+FA11 について調べると、すぐにこの文字が「CJK 互換漢字」のブロックにあることがわかります。互換文字とは、過去使われていた文字コードとの互換性のために Unicode の中に残されている文字のことで、新しく書く文書では特に理由がない限り使うべきではありません。「べきでない」と言われても僕は使いまくっていますが、全角空白 (U+3000 IDEOGRAPHIC SPACE) なんかは互換文字です。
じつは、 U+FA11 は CJK 互換漢字ブロックにあるけれど、互換文字ではなく通常の CJK 統合漢字なのです。ほかにもいくつか、 CJK 互換漢字ブロックの中に互換文字でない CJK 統合漢字があります。ああ、ややこしい。もっと知りたい人は Known Anomalies in Unicode Character Names (Unicode Technical Note #27) を参照してください。
スラッシュドットの「スラッシュドットに聞け!」セクションで、「文字エンコーディングは UTF8 で本当に十分なのか?」という記事がありました。それに対して、僕は「UTF-8 で十分なわけないじゃん」と答えながら、答えの中で、
僕は 1 文字 2 バイト以内であることが重要になるようなギリギリの世界でプログラムを書く予定はないので、日本語以外も扱える UTF-8 や UTF-16 で十分です (UTF-16 は Windows のネイティブの符号化方式なので使います。それがなければ UTF-8 だけで十分)。
と書きました。でも、このサイトのページ (のほとんど) はシフト JIS コードで書かれています! 「嘘つき」と言われる前に言い訳をしておきます。
僕がページをシフト JIS で書くのは、 UTF-8 で書くと日本語の文書でも Internet Explorer (6 でも 7 でも) が日本語用に設定したフォントを使ってくれなくて、それが少しだけ気に入らないからです。つまり、ブラウザーの実装の都合です。まあ些細な話です。この点を無視できるくらい UTF-8 にする利点が発生すれば、 UTF-8 にするでしょう。
さすがに UTF-16 とか、 US-ASCII にして日本語は全部 フ みたいに文字参照とか、 EBCDIK+KEIS とか BOCU-1 とかにする可能性はないと思います。
ウィキペディア日本語版のメインページ (トップページ) の新デザインの予選投票が締め切られました。僕のいい加減な集計では、投票資格を持つ人のうち実際に投票をした人は全部で 212 人で、案外多くて驚きました。投票資格を持つ 2,774 人と比較すると投票率は 7.6 パーセントと言えそうです。
また、有効投票の数は 576 票でした。この投票では好きな個数の候補に投票できるため、投票した人数とは一致しません。投票した人は一人当たり平均 2.7 個の候補に投票していることになります。
味にコクがあることを意味する「まったり」という表現は 1980 年代にできた言葉であって、国語辞典に注釈なく載るような語ではない、と思っていたのですが、デジタル大辞泉 (小学館) にも大辞林第二版 (三省堂) にも何食わぬ顔をして載っていて、自信がなくなってきました。それでもこれが昔からの日本語だとは信じられないので、時間ができたら図書館で昔の辞典を見てみます。
ところで、たぶん「まったり」と関係があるであろう語に「まったく」があります。「まったく」 (全く) は現代語では副詞ですが、もともとは「まったし」 (全し; 意味は「完全である」) というク活用の形容詞の連用形でした。「まったく」の音便形は「まっとう」で、現代語では「職務を全うする」などの「まっとうする」 (全うする) や「まっとうな論理」などの「まっとう」 (全う、あるいは当て字で「真っ当」) の形で使われます。
一つ前のエントリーを書いていたら、「コンテンツを死蔵するな」 (趣味の Web デザイン - 備忘録 2007 年 3 月 4 日; 徳保隆夫さん) が載っていました。フォローが早いですね (僕が遅いだけとも思いますが)。
金にならないものはみんなまとめてパブリックドメインにすればいいんだ。そうすれば、オリジナルは作れないけど改作だけは異様にうまい人とか、文章の手直しが神がかり的な人とか、記事を構成して雑誌を作るだけが取り得の人とか、今まで活躍の場がなかった才能が勇躍し、新たなコンテンツ市場が立ち上がるはずだ。
何がパクリだ。くだらない道徳だね。そんな制限はこの世に必要ない!
あー、すっきりした。
でも僕はまだ迷っているので、転載には出典の明記を求めていますし、改変して利用することについては、改変の定義も含めわざと何も書いていません。曖昧にしておいていざとなったらケチをつける余地を残しておくのはズルいかもしれないけれど、今はそうしています。
「Yahoo!ブログ陥落……我が夢、破れたり」 (趣味の Web デザイン - 備忘録 2007 年 3 月 2 日; 徳保隆夫さん) より引用。
プロの定義
私は著作権税の創設を主張します。年間10万円納税すると、その人物に著作権を主張する権利が与えられます。納税以前の著作物は保護対象外。また翌年の支払いが滞ると、それ以降の著作物はやはり保護されない。保護期間は最後の納税から10年間。遺族が著作権税を払い続けることも可能。ただしいったん著作権が切れたものが再び保護されることはない。
というわけで、年間10万円払えるのがプロ、他はアマチュアという線引きです。
そう書くと「世の中すべてカネで解決すると思っているのか」という反論がくるのは間違いないと思います。徳保さんもわかって書いているのは明らかですが。
価値観はカネですべて表現できるわけではないけれど、じゃあほかに外から見てわかる表現方法に何があるのかと言われると、「いくらまでなら払えるか」というのは比較的うまい指標だと思います。なので、僕は基本的に徳保さんのスタンスに賛成です。一人年間 10 万円という額とか、そもそも一人あたりで課金するのかとか、そのあたりは他の選択肢も検討したいところですが。
タイムリーなことに、僕は全然違う場所で価値観をカネで表現することについて書いています。
ちなみにこのサイト「フルーツチョコレートパフェ」はもともと転載不可としていましたが、 2006 年 12 月 5 日以降、出典を明記してもらえば転載可としています (転載の詳しい条件は「このサイトと管理人について」を参照)。「閉鎖する前に考えてほしいこと」 (趣味の Web デザイン; 徳保隆夫さん) を読んだのがきっかけだったと思います。変えた理由は変更のログに書いてありました。
いろいろ考えた結果、転載許可。条件を読んで考えてくれる人なら転載してもらっていいし、読んでくれない人は何書いても仕方がない。僕の文章が僕のサイトに載っている必要はないし、うまくいけばそのうち移転するつもりで、移転したらリンクは全部駄目になってしまうので。
「ウィキペディア新デザイン選定投票の有資格者のリスト」では、ウィキペディア日本語版のページの編集の記録のうち本文以外をすべて含むダンプファイル jawiki-20070224-stub-meta-history.xml.gz を使いましたが、怖いもの見たさで本文も全部含むダンプファイル jawiki-20070224-pages-meta-history.xml.7z を見てみました。このファイルは 7-Zip で使われている 7z 形式で圧縮されており、圧縮後で 1.1 ギガバイトです。展開すると、すべてのページのすべての版が (差分形式とかではなく) そのまま含まれたファイルが出てきます。その大きさなんと 110.8 ギガバイト。僕の使っている PC ではディスクの容量不足で展開すらできません。本当に怖いものを見てしまいました。敗北。
今日の豆知識: GNU sort はソートするデータ全体がメモリに入りきらないほど大きいと自動的に外部ソートを使います。外部ソートはアルゴリズム自体は簡単ですが、何よりそんな配慮をしてあることに驚きました。単純にメモリ不足で落ちるものと思っていたので。
僕は、ウィキペディア日本語版のメインページ (トップページ) のデザイン・内容のリニューアルについて、予選投票のお手伝いをしています。
2 月 26 日に書いた「投票資格」で、「2006 年 12 月 11 日 (木)」という誤った日付が出てくるのは元が誤っていたからですが、気付かずに写した僕にも責任はあります。すみません。とりあえずウィキペディアでこの誤りについて報告しました。年月日が正しく曜日は誤記ということで、投票資格の文面を修正し、投票自体は続行する可能性が高いと思います。
こっそり直してしまえば誰も気付かないんじゃないかなー、とも一瞬思ったのですが、それは後でバレたときに揉めそうというだけでなく、なにか「フリーの百科事典」に反する行為のような気がして (はっきりと理屈があるわけではないのですが)、むしろ誤りがあることを明確にするべきだと思ったので、こっそり直さず報告したことに今のところ悔いはありません。とはいえ、これで「投票資格に誤りがあったのならこの投票は無効だ!」と揉め始めてしまう恐れもあって、そうなったときに本当に後悔しないかどうかはわかりませんが。
一つ言えるのは、僕はこの投票にひとごととして軽々しく参加しているということです。そもそも僕は現段階のメインページのデザイン変更に賛成か反対かと問われれば反対でした (投票権がないし、あっても投票期間の間はそれどころではなくて投票できなかったと思いますが)。でも、デザイン変更の投票は実施されることになったので、面白そうなので関わっているだけです。責任ある立場にないので、嫌になったらいつでも関わるのをやめられるし、メインページの投票の結果どんなメインページが採用されようと僕自身は大きな被害を被りません (どうしても採択されたメインページが耐えられなかったら、プロキシーを咬ませてメインページの中身だけ差し替えることだってできるので……)。関わりはしているけれどコミットはしていないという、遊び半分の参加です。これを無責任だと非難する人がいるかもしれませんが、僕は悪いことだとは思っていません。今後も僕のウィキペディアへの関わり方は、恩恵は受けられるだけ受けるとしても、貢献なんてものは本当の意味では何もしないと思います。「ウィキペディアをありがたく使っているフリーライダー」と自分で書いている通りです。
「僕が Acid テストを嫌う理由」の中で「IE7 のズーム機能は CSS 使い泣かせ」 (備忘録 2006 年 2 月 1 日; 徳保隆夫さん) の一部を引用して、 Acid2 テストの結果など一般ユーザーが気にするものではないという持論を補強しようとしたら、引用部はブラウザーが仕様に準拠しても生じるブラウザー間の差を肯定しているだけで、ブラウザーが仕様に準拠しないことを是とする趣旨ではないという批判をいただきました。「Web ブラウザは仕様の範囲内で個性ある画作りをしてほしい」 (備忘録 2007 年 2 月 28 日; 徳保隆夫さん)。僕としては素晴らしいウェブサイトをお作りになる徳保さんに拙文を取り上げていただいただけで光栄なのですが (←ミーハー)、ちゃんとしたフォローアップはもう少し頭の働いているときにしたいと思うので、気長にお待ちいただければと思います。
「ブラウザーが画作りをする」というのも、少なくとも以前の僕には絶対に受け入れられなかった表現です、という感想から、たぶんどういうフォローアップを書くかは予想が立つかと思います。
ウィキペディア日本語版のメインページ (トップページ) のデザイン (内容も含む) が 3 月末か 4 月初めから新しくなる予定で、現在新デザインについて議論が行われています。どういう投票方式が提案されているかについては先のページをご覧いただくとして、新デザインを選ぶ投票の投票資格は現時点での提案では次の三つの条件をすべて満たす登録利用者となっています (時刻はすべて UTC)。
いや、わからなくもないのですが、ややこしい! ちなみに僕はどれにも該当しないので投票資格はありません (そのこと自体に不満はありません)。
いったいこの定義で投票資格を持つ利用者は何人いるのか気になりました。誰がいつどんな編集をしたかというデータは download.wikimedia.org から入手することができます (ただし非常に古いデータと「特定の版の復帰機能」で抹消されたものを除きます)。今回の計算に必要なデータファイルは stub-meta-history.xml.gz です。 Gzip で圧縮されて 349.1 メガバイト、展開すると 2.6 ギガバイトという大きなファイルですが、負けてはいられません。
僕の資格の解釈やデータの使い方やスクリプトが間違っていなければ、上述の条件に該当する登録利用者は 2,774 人いることがわかりました。ただし、条件 1・2 については非常に古いデータが含まれていないので正確には判定できません。また、「特定の版の復帰機能」で後から抹消された編集を数えるのかどうか僕はよく知りません。なので、この数値はあくまでも参考です。
「ウィキペディア新デザイン選定投票の有資格者のリスト」もどうぞ。
僕はリンクを張るときに原則として「同じウィンドウで開くか新しいウィンドウで開くか」を指定したくありません。閲覧者の好みやリンクの性質に応じてブラウザーがよしなに判断してくれれば良いのにと思うのですが、残念ながら HTML 4.01 の a 要素には target="_yoshinani" という指定はありません。閲覧者の好みもリンクの性質も数種類しかないと思うので、ブラウザーのメーカーがその気になったら実現は可能だと思うのですが (ただ、閲覧者によっては「本文中のリンクは新しいウィンドウで開きたいが本文以外の (ナビゲーション用の) リンクは同じウィンドウで開きたい」と考えるかもしれず、これは target="_yoshinani" と言われてもなかなか実現が困難かもしれないとは思います)。
target 属性には「今のページと同じフレーム」を表す _self という値もあるので、 target 属性を指定しなければどのウィンドウで開くかを指定していないことになるのかと思ったのですが、 HTML 4 仕様書 16.3.2 項 Target semantics の記述によれば、 target 属性が指定されていない場合は事実上 _self と同じように振る舞うことになっています。
世の中の出版物で run-in heading がよく使われていても、スタイルシートの display: run-in へのブラウザーの対応状況がちっとも良くないのはなぜでしょう。 Firefox では Bug 2056 として登録されています。
今日の占い。「受け」の反対語といえば?
「投げ」と答えた人: キャッチボールか柔道を思い浮かべているのでしょう。スポーツは健全な趣味とされているので問題ありません。
「攻め」と答えた人: 剣術等を思い浮かべているのでしょうが、そのつもりがなくても「やおい」 (男性同性愛を題材にした成人女性向け創作) 好きとみなされる可能性があるので注意が必要です (参照: 読冊日記 2003 年 4 月 25 日 (風野春樹さん) の最後の段落)。
「引き」と答えた人: さすがにそれは反対語ではない気がしますが、「つまらない話をしたら客の引きが良かった」と言うとなんだかポジティブで良い感じです。
「係り」と答えた人: 手遅れです。僕とは話が合いそうな気がします。
何かを理解して答えを知ることは楽しい経験です。
でも、問題を知り、答えを得ようとしていろいろ考えることは、それ自体楽しいものです。これは人から答えを教えてもらうだけではできません。考えるべき問題が必要なのです。
答えは問題から生まれます。ある意味で、答えを知ることは、問題を消費することと言えるかもしれません。だから、考えるに値する問題を生み出すことができる人は、答えを導くことができる人よりすごいと思います。
さらに、問題を生み出す「考え方の枠組み」を作ることができる人は、一つ一つの問題を生み出すことができる人よりもっとすごいと思います。
矮小なたとえですが、ボールをこうやって投げたら何メートル飛ぶか、という問題を与えられて答えを求めることができるのは良いことだけれど、そういう問題を思いつく人はすごいし、そんな問題を生み出す力学・物理学という枠組みを考えた人はもっとすごい。
下位の貢献をおろそかにする人には上位の貢献はできないと思うので、決して一つ一つのことを馬鹿にするつもりはありませんが、下位の概念だけに囚われて上位の概念を見失うとやっぱり上位の貢献はできない。そんなことを最近思います。
何が言いたいのかというと、いろいろあるのですが、一つには、答えを得ようとしていろいろ考えることを放棄して結論に飛びつくのは自分もやってしまいがちなのですが、それって面白いところを放棄しているのでもったいないよなあ、ということです。あと、答えが問題から生み出されるように、問題も枠組みから生み出されて、上には上があるのが興味深いなと。
2 月 11 日に公開した某サイト風ウィキペディアで使っているフォントは相変わらず Windows に付いてくる Georgia (Georgia 2.12) です。このページの画像を作るとき、 Georgia フォントで普通に「Wikipedia」と書いたら下のようになってしまいました。
普段別にこのフォントがおかしいと思ったことはなかったのですが、この程度大きな字で書いてじっと見ていると、 k と i の間だけくっついているのが耐えられなかったので、少し手で調整しました。実際に上記ページで行った調整の内容とは違いますが、 k の次の i を少し右に動かした図が下です。
僕はただの素人でフォントの理屈はよくわかりませんが、両者を見比べると明らかに字間を調整した後の方が読みやすくなっていると思います。できればこういう調整を自動的にしてくれると嬉しいのですが、 OS にくっついてくるフォントにきちんとしたカーニングの情報を要求するのは無理があるのでしょうか。
遊びをせんとや生まれけん。戯れせんとや生まれけん。
遊ぶ子供の声聞けば、我が身さえこそゆるがるれ。
『梁塵秘抄』巻第二 四句神歌 雑 (山口美佐さんのサイト「つれづれの文車」に紹介あり)
「フルーツチョコレートパフェ」の内容には一貫性がありませんが、一貫したテーマは「遊び」です。
僕が気にしないよう心がけているものの例: 周囲の人の話し声、嫌いな音楽、声が大きいだけでやる気も説得力もない演説、他人の常識外れな行為、迷惑メールの内容、サイトへのアクセス数、スラッシュドットで書いたコメントに対するモデレーション、人力検索はてなで回答したときに質問者から送信されるポイントの多寡。
もちろん、これら以外にも最初から気にしていないものはたくさんあるのですが。 A(6, 6) の値など (ただし A(・, ・) は Ackermann 関数)。
僕の好きな色はとくにありません。でも強いて挙げるなら、青でしょうか。 Google の今のデザインの色だから、ではたぶんないと思います。でも無彩色も使い方によっては好きですね。どちらもこのサイトでうまく使えていない色であることに気付きました。テキストの色としては青も黒も出てきますが。
うまくこのサイトが夏まで続けば、きっと涼しげな演出のために青や緑など寒色を多く使った配色に変えることでしょう。使い方にもよるのでしょうが、今の季節に青はちょっと寒すぎます。僕は暑いのは我慢できても寒いのは大嫌いです。
ちなみに、好きな音は B♭ です。
角丸長方形なら現在策定中の CSS Level 3 (CSS3) の border-radius プロパティーでできるよ、とか、 Firefox は対応していないけれど代わりに -moz-border-radius プロパティーというのがあるよ、とか、二つは似て非なる動作をするよ、とかいう情報を消息筋 (Google) から入手したので、やってみました。 fcp の発言のリスト。 Internet Explorer 7 では無視されますが、 Firefox 2 だとちゃんと効きます。 Opera でも効くみたいです。どうせスタイルシートはおまけなので、無視されても気にしないことにします。
それと、昨日あれだけぶーぶー書いた「SVG 1.1 画像を背景に指定しても角丸長方形が作れない問題」も、 CSS3 の border-image プロパティーを使えば解決できるはず、ということも知りました。
CSS3 は以前ちらっと見ただけで、まだ流動的ということで読んでいなかったのですが、そろそろ一度読んでみる頃かもしれません。しかし、多いなあ……全部読むなんて無理です。
この人の苗字が気になります。「エソドウ」とか「カソザキ」なんて苗字、ありませんよね……。
条件に合いそうな姓を一つは思いついたので、ほかにないかと思って日本の姓の全国データベースの上位 200 の姓を見たら、それと似た姓で、もっとずっと珍しくて、「ン」に変えたときの人数はあまり変わらないものもありました。
HTML と CSS で要素の角を面取りして角丸の四角を作ろうとすると、方法はいろいろあるのですがどれも面倒です。 Scalable Vector Graphics (SVG) で角丸長方形を描いて、それを要素の背景に指定させてくれればいいのに、 Internet Explorer 7 も Firefox 2 も対応していません。きいい。
と思ったら、じつはこれは実装者だけが頑張れば済む問題ではないようです。 SVG 1.1 仕様書の 7.2 節と 7.7 節を合わせて読むと、 SVG 1.1 では画像を適切な大きさに変えて表示する際、全体を拡大縮小することしかできないので、面取り半径を変えないで長方形の大きさを変えることはできないということになるような気がします。僕の SVG 1.1/1.2/2.0 Requirements (2002 年 4 月 22 日版、ってとても古いですね……) の理解が正しければ、画像の一部の大きさを保ったまま全体の大きさを変える機能は SVG 1.2 で盛り込むべきということになっています (4.2.6 節 の第 1 項)。
SVG 1.2 仕様の策定は遅れまくっていますが、 SVG には期待しているので、作業部会の皆さんは頑張ってください。
1 から 9 までの整数をある規則に従って並べると、 1、 9、 5、 3、 4、 7、 2、 8、 6 になります。その規則とは。ただし、場合によっては 1、 9、 5、 3、 7、 2、 8、 4、 6 です。
答えがわかっても誰もほめてくれないと思うので、一人でほくそえんでください。
現在、移植用臓器の売買は国際法上禁止されていますが、現実には臓器の売買は闇で行われています。この現状が変わるかもしれません。フィリピンで一定の条件の下、外国人に対する腎臓の販売を認める動きが出てきています。 Shikoku News (四国新聞社) の 2 月 10 日付け記事「腎臓提供「謝礼」に賛否 / フィリピン保健省がシンポ」やスラッシュドットの記事「フィリピンで臓器売買合法化の動き」など。
臓器売買は禁止されていて当然、合法化するなんてもってのほかという人に読んでもらいたい文章が、 47th さんの「Becker が語る臓器移植論」 (1)、 (2)、 (3) です。シカゴ大学教授の Gary Becker 氏がブログ The Becker-Posner Blog で書いた記事「Should the Purchase and Sale of Organs for Transplant Surgery be Permitted?」を日本語で紹介してくれています。
Becker 氏の記事では、経済学の立場から、臓器市場を解禁すれば、臓器移植待ちの患者が今より多く臓器移植を受けることができるようになり、しかも今より適正な価格で取引されることによって提供者に支払われる金銭も増すという論が展開されています。読み返してみると、まっとうすぎて、どうして現状で禁止されているのかがだんだんわからなくなってきて不安になりますが、「だったら臓器市場を解禁するべきだ」という結論に直結できない理由は、「臓器を売買するのは悪いことだから」という倫理観があるからです。
結局、経済学ってのは倫理と相反するものであって、倫理を重んじるなら経済学者の言うことは無視するに限る? ……ええ、数年前の僕ならそう考えたでしょう。でも、違うのです。上記 (3) より、 47th さんの言葉を引用します。僕が「経済学というのはカネのことしか見ていない悪い学問なんかではない」と気付きかけた頃に、ちょうどそのことをはっきりと書いた言葉を読んだので、強く記憶に残っています。
この点 (引用註: 「臓器に関して効率的な資源配分を理想とするならば」という万人が同意するわけではない仮定が付いてしまう点) において、 Becker のような経済学的発想に限界があることは否めないように思えます。
しかし、なお、経済学的には、ある選択肢を制限してしまうことの目に見えないコストが明らかになっていくというメリットがあります。
「倫理観」の下に臓器売買を禁ずることは一つの見識ですが、そこには臓器売買がなされれば得られたであろう利益を失うというコストの側面があります。
少なくとも、この「倫理のコスト」…この場合は、臓器市場が成立すれば救われたであろう命については正面から受け止めるべきだろうと思います。
一つページを作ろうとしましたが、時間がないのでやめました。何を作ろうとしたかは、下の画像から好きに想像してください。
某サイト風ウィキペディア。一発ネタのつもりで作り始めたのに、いろいろ考えてしまって中途半端な出来上がりになりましたが、まあそんなもんです。
厚生労働大臣の柳沢伯夫氏が出産可能な年齢の女性を「産む機械」とたとえたことが話題になっていますが、その「たとえ」が問題なのかというと、僕は違うと思います (ショッキングな発言ではあるので、ショックを与えないよう配慮してほしいと望むのは理に適っていると思いますが、それは問題の本質ではありません)。問題の本質は、「少子化は女性の責任だ」という柳沢氏の考え方です。問題の本質を見過ごして、本質がショッキングな言葉として顕在化した部分だけを責めるのは、おかしな話です。
絶対に誰か書いていると思いますが、僕も書きます。
―少子化が続いている。厚生労働大臣の責任をどう考えるのか。
柳沢氏 くだらない質問だ。女性が子供を産まないからいけない。
(これは一部方面で有名な 2001 年の富士通社長 (当時) の秋草直之氏のインタビューのパロディーであり、実際の発言とは全然違います!)
Yahoo! Site Explorer を使うと、指定したページにリンクしているページの一覧を表示することができます (当サイトトップページの場合)。 Google にもリンク検索という機能がありましたが (当サイトトップページの場合)、こちらは指定したページにリンクしているページのうちごく一部しか表示されませんでした。 2002 年頃までは Google のリンク検索も完全な結果を返していたような記憶があるのですが、ともかく「今では Google のリンク検索は不完全」というのが僕の認識です。
その Google がやってくれました。 Google ウェブマスターツールに、自分の持つサイトにリンクしているページの一覧を表示する機能が付きました。詳しくは Google provides backlink tool for site owners (Matt Cutts: Gadgets, Google, and SEO; Matt Cutts さん) を参照。後発なだけあって、 Yahoo! Site Explorer のより見やすくなっています。 Yahoo! とは異なり、自分の持っているサイトへのリンクしか表示されません。
あとはリンクしてもらえるような文章を書くだけです! (何が。)
……と思ったら、 Google の意図に反して自分のサイト以外へのリンクも表示できてしまうという問題が見つかって、この機能は現在使えなくなっています。なんだかつまらない不注意によるミスのような気がしなくもないですが、頑張れ Google。
……などと書いている間に復活?
28 日の話の続きで気が付いたこと。テレビのチャンネル切り替えで上向き矢印のボタンと下向き矢印のボタンが付いているのも、今のチャンネルから番号を大きくするのはどちらかと聞かれると迷います。普段はこれらのボタンを使わないので、わからなくても困らないのですが。
Outlook Express と Thunderbird では、メールを日付の順にソートして表示している場合にそのことを示すアイコンが表示されますが、 Outlook Express では古いものから順のとき上向きの三角、 Thunderbird では逆に古いものから順のとき下向きの三角が表示されます。スラッシュドットのコメントで知りました。
どちらも理屈はわかるのです。 Outlook Express では日付の「昇順」 (英語でも ascending order) だから上向きの三角で表示しており、一方 Thunderbird では上から下に時間が進んでいくから下向きの三角で表示しているのでしょう。どちらでも論理は通っているので、結局三角形だけ見ても古い順か新しい順かはわからないということになります。細かい話ですけど、言われてみると気になるかもしれません。
なお、上向きと下向きの三角が昇順と降順のどちらを表しているかが理屈では決まらないというのは、日時のデータに限った話ではありません。普通の数値でも同じことが起きえます。
手で触っただけでシャンプーとリンスの区別が付くよう、シャンプーの容器の側面には溝が彫ってあるのが一般的です。これはメーカーによらず共通です。とくに意味はないけれど、統一されていることに意味があります。昇順と降順を表すアイコンについても同様のことができないものかと思うのですが、既に両方とものソフトウェアが存在するので統一するのは難しそうです。
ある定食屋さんの店内で次のようなアナウンス放送が流れました。
「当店では、お車を運転のお客様や未成年のお客様へのお酒のご提供はお断りしております。運転免許証や年齢を確認させていただく場合がありますので、ご了承ください」
車を運転していないことを証明するのは難しそうです。
学校の吹奏楽部にいた頃、指導してくださっている先生が「16 分音符とクレッシェンド (だんだん強く) が書いてあるのが読めませんか。 16 分音符の連続が演奏できないのは理解できますが、クレッシェンドが演奏できないのは理解できません」とおっしゃったことを思い出しました。当時は「無茶言うな」と思いながら、やけくそになって音を出していたような気がしますが、 10 年以上たって、やけくそになってでもクレッシェンドを演奏したことの重要性に気付きました。
ふざけて Windows XP マシンの壁紙に「ウインドウズ・ヴィスタ」という文字を書き加えたら、 Internet Explorer が落ちました。何か高度な処理が行われているようです。さすが 21 世紀。と思いましたが、考えてみると 20 世紀には「テキストエディタでプログラムを書いていて、保存しようかなと思うと PC が固まる」というもっと高度な処理を何度も経験していたのを思い出しました。
自分と通話先の市外局番が同じでも市外通話料金が適用される場合があります (電話番号が足りなくなった結果、こういうわかりにくい事態が起きてしまったようです)。この場合、市外局番からダイアルしないとかかりません。ここで市外局番を付けないと、「おかけになった電話番号は現在使われておりません」というアナウンスが流れるのだそうで、相手の電話番号が変わったのかと誤解したという利用者からの苦情を受けた総務省が NTT 東西に改善を要請しました。詳しくは 1 月 23 日付の総務省報道資料「同一市外局番の単位料金区域間で電話をかけた場合のアナウンス内容等の改善」を参照。 asahi.com の記事 (1 月 24 日付) 「市外局番省くと通話できず 総務省が NTT に改善要請」で知りました。
ここは多くのソフトウェアにならって「呼出に失敗しました」など意味のわからないアナウンスにしておけば誤解の余地がなくなるのではないでしょうか (苦情は減らないと思いますが)。それにしても、 NTT 東西にも苦情がなかったわけではあるまいに、そんなことまで役所が面倒を見なければならないとは大変なことですね。
「2006 年 12 月 ○○ 日」と書かれているファイルをコピーして今日の日付に変えると、「2006 年 1 月 ×× 日」のように、年を変えるのをよく忘れます。月を変えるのは忘れないのに……。
コンビニエンスストアの店頭に燃えるごみのごみ箱やペットボトルの回収箱が置いてあって、「家庭ごみの持ち込みは固くお断りします」と印刷してありました。ということは、事業系ごみなら持ち込んでいい……わけがありません。その場で出たごみは捨てていいけれど、外部からごみを持ち込んでは駄目という意味ですよね。だったら、素直に「ごみの持ち込みは固くお断りします」でいいのではないかと、どうでもいいことを思いました。
空腹のときに自分のウェブサイトを見るとパフェを食べたくなるというのは、命名でどこか損をしているような気がします。
「軽い病気」の反対は「重い病気」だと思いますが、「軽い咳」の反対は「重い咳」かどうか迷います。「見つける (見付ける)」という語は「見る」と「つける (付ける)」の複合語だと思いますが、「見つかる (見付かる)」という語は「見る」と「つかる (付かる?)」の複合語とは思えません。
「フルーツチョコレートパフェ」の今のタイトル画像を作る前に作っていた画像です。使っている書体は Windows についてくる Georgia (Georgia Italic バージョン 2.10) です。字間を詰めて少し横に拡大しています。
なんか雰囲気が合わないなあ、ということで没にしました。 LVDC Sweet Days フォントを見つけたことで今の画像ができたことを考えると、書体の影響力がいかに大きいかがわかります。僕が絵を描かないから余計にそうなのかもしれませんが。
Internet Explorer では、ユーザースタイルシートに
html { filter: progid:DXImageTransform.Microsoft.BasicImage(grayscale=1); }
と書くとウェブページをグレイスケールで表示できます。自分のウェブページをグレイスケールで表示してみると、なかなか新鮮です。ひょっとしたら色の見えない人から見たアクセシビリティーの改善の参考になるかもしれないと思いましたが、たかが 1 行のユーザースタイルシートに過剰な期待は禁物ですね。
タイトルを画像にしてみました。 Lovedesign Co. による LVDC Sweet Days というカタカナのフォントを使っています。こんな楽しいフォントが無料で使えるのはありがたいことです。加工は他の画像と同様 GIMP でしています。
昨日の「最近の fcp」で、ジャギーの激しい画像を載せてしまいました (修正済みです)。同じミスをする人が減ることを願って「GIMP で綺麗に楕円を描く方法」を書きました。
僕はときどき Google ウェブマスターツールを使って、 Google でどういう検索をしたときに当サイトのページが表示されたかを示す統計情報を眺めて遊んでいます。これまでは当サイトのページが検索結果に表示されるだけで、たどってもらえることはほとんどありませんでしたが、ついに統計情報に初めて「クリックされたページ」の欄が表示されました! 栄えある当サイトのクリック数の稼ぎ頭 (?) は、なんと「虚数は捏造…科学界を突如襲う崩壊の危機」でした。 Google で「ボンベリ」で検索して飛んできたかた、しょうもない内容ですみません。
ジャストシステム社の第二回 全国一斉! 日本語テストをやってみました。詳しくは「第二回 全国一斉! 日本語テストの感想」をご覧ください。
