同じ日付の項目が複数並んでいる場合がありますが、必ずしも間違いではありません。
当サイトのアクセスログを見ていたら、こんな行がありました (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 よりもコミットの情報量が増えた分、気を遣うことが増えたのは確実です。利用者の注意力に頼るのではなく、利用者に間違わせない、あるいは間違っても後で簡単に直せるようにするというのが、使いやすいユーザーインターフェースの鉄則です。
とはいっても、じゃあどうすれば良くなるかと問われると、今のところ僕にはわかっていません。レポジトリーの形式が今のままでは、後から一つのコミットを複数に分割するなどの変更は非効率にならざるを得ないでしょうから、少なくともレポジトリーの形式は変えないと解決しないでしょうが。