Landscape - エンジニアのメモ 2005-11

C# で文字列連結するとき、string 型を += で連結するとパフォーマンスが落ちるので、ある程度の回数以上の文字列連結には StringBuilder を使うということが常識となっている。string は不変なので、連結の度に新しいオブジェクトの生成と破棄がおこなわれるからというのが差の発生原因。

ただ、私は実際どの程度性能が劣化するのか計測したことがない。このままだとコードレビューの時に「StringBuilder 使え」と指摘をしても、その根拠となる数値を示せない。後輩などに「計測もしないで性能が落ちるなんて言ってるんですか? 性能を理由にコードを書き換えるときはまず計測しろって言ってたのは斎藤さんじゃないですか?」とか言われかねないので、計測してみる。幸いなことに、私の所にはこの程度の指摘をする必要のある後輩はいないので問題ないけど。

- 計測用コード

傾向がわかればいいので、コードは簡単に書いた。

using System;
using System.Text;

namespace ConsoleApplication1
{
    /// <summary>
    /// Class1 の概要の説明です。
    /// </summary>
    class Class1
    {
        /// <summary>
        /// 文字列連結の速度比較
        /// </summary>
        [STAThread]
        static void Main(string[] args) {

            int times = 100000;
            Console.WriteLine("{0:d} times loop.", times);

            DateTime start_str = DateTime.Now;
            string str = string.Empty;
            for (int i = 0; i < times; i++) {
                str += i.ToString();
            }
            Console.WriteLine("String += : " + (DateTime.Now - start_str).ToString());


            DateTime start_str_builder_default = DateTime.Now;
            System.Text.StringBuilder sb_default = new System.Text.StringBuilder();
            for (int i = 0; i < times; i++) {
                sb_default.Append(i);
            }
            Console.WriteLine("StringBuilder: " + (DateTime.Now - start_str_builder_default).ToString());
        }
    }
}

ちなみに実行環境は以下の通り。
富士通 FMV-E600 Celeron 1.7GHz 512MB Memory
Visual Studio 2003 C# のコンソールアプリケーションとして作成。
Debug モードでコンパイルし、CTRL + F5 で実行。

- 計測結果

計測した結果。times の数を変えて3パターン計測。

1000 times loop.
String += : 00:00:00.0156250
StringBuilder: 00:00:00

千回のループ。StringBuilder を使ったときの所要時間がゼロになってる。このタイマーの精度は 15ミリ秒単位で出力できる程度だっけ? その範囲内に収まっちゃったってことか。何にせよ1000回じゃ少ないなあ。

10000 times loop.
String += : 00:00:01.8125000
StringBuilder: 00:00:00.0156250

一万回のループ。百倍くらい違うな。実際にはいろいろ無茶をやった分に付随するコストも加算されるだろうから、環境によって差は変動するかもしれない。

100000 times loop.
String += : 00:05:20.5000000
StringBuilder: 00:00:00.0781250

十万回のループ。+= の方は耐えられないくらい遅い。指数的に処理時間が増大している。一方、StringBuilder は安定しているな。

これだけ差があれば、StringBuilder 使えという根拠は示せるね。使う基準としては、ループ内だったら迷わず StringBuilder。回数が固定的なループでも、設定の値や仕様が変わってループ回数が変わるのは良くあることだし。ループ外でも回数が多ければ StringBuilder。ループ外で、かつ一桁程度の回数しか連結しないんだったら += でもいい。

ところで、コンパイラは += を StringBuilder に置き換えるという最適化とかしてくれないのかな。この問題については、人間が適切な文字列連結手法を選ぶ方がスマートだと思うけど、コンパイラによる力業で解決できないのかな。

- StringBuilder のキャパシティの初期サイズによる速度の違い

StringBuilder は内部バッファを持っている。扱うデータのおおよそのサイズがあらかじめわかっているなら、そのバッファのキャパシティをコンストラクタに指定しておいた方が、バッファの拡張のオーバーヘッドを抑えられるので速くなるとのこと。これについても計測してみた。

計測に使ったコードは以下の通り。環境は変更なし。
バッファサイズは 1, 8, 64, 256, 1024, 8192, 16384, 65536, 16777216 を試すことにした。この数値の根拠は勘。ちなみに何も指定しない場合のデフォルトは 16 だそうだ。

using System;
using System.Text;

namespace ConsoleApplication1
{
    /// <summary>
    /// Class1 の概要の説明です。
    /// </summary>
    class Class1 {
        /// <summary>
        /// 文字列連結の速度比較
        /// </summary>
        [STAThread]
        static void Main(string[] args) {

            int times = 1000000;
            Console.WriteLine("{0:d} times loop.", times);

            DateTime start_str_builder_default = DateTime.Now;
            System.Text.StringBuilder sb_default = new System.Text.StringBuilder();
            for (int i = 0; i < times; i++) {
                sb_default.Append(i);
            }
            Console.WriteLine("StringBuilder: Capacity: Default: " + (DateTime.Now - start_str_builder_default).ToString());

            int[] capacity_list = {1, 8, 64, 256, 1024, 8192, 16384, 65536, 16777216};
            foreach (int capacity in capacity_list) {
                DateTime start_str_builder = DateTime.Now;
                System.Text.StringBuilder sb = new System.Text.StringBuilder(capacity);
                for (int i = 0; i < times; i++) {
                    sb.Append(i);
                }
                Console.WriteLine("StringBuilder: Capacity: " + capacity.ToString() + " : " + (DateTime.Now - start_str_builder).ToString());
            }
        }
    }
}

1000000 times loop.
StringBuilder: Capacity: Default: 00:00:00.8437500
StringBuilder: Capacity: 1 : 00:00:00.8281250
StringBuilder: Capacity: 8 : 00:00:00.8593750
StringBuilder: Capacity: 64 : 00:00:00.8281250
StringBuilder: Capacity: 256 : 00:00:00.8593750
StringBuilder: Capacity: 1024 : 00:00:00.9375000
StringBuilder: Capacity: 8192 : 00:00:00.8593750
StringBuilder: Capacity: 16384 : 00:00:00.8750000
StringBuilder: Capacity: 65536 : 00:00:00.8593750
StringBuilder: Capacity: 16777216 : 00:00:00.8125000

まずは百万回。うーん、あんまり変わらないね。ほんの少しだけ値が変動してるけど、百分の一秒レベル。F-ZERO でタイムアタックするなら大きな違いだけど、ここではそこまで重要な意味は持っていないと思う。誤差の範囲。

3000000 times loop.
StringBuilder: Capacity: Default: 00:00:02.7031250
StringBuilder: Capacity: 1 : 00:00:02.6562500
StringBuilder: Capacity: 8 : 00:00:02.7968750
StringBuilder: Capacity: 64 : 00:00:02.8437500
StringBuilder: Capacity: 256 : 00:00:02.9687500
StringBuilder: Capacity: 1024 : 00:00:02.8437500
StringBuilder: Capacity: 8192 : 00:00:02.9687500
StringBuilder: Capacity: 16384 : 00:00:02.8593750
StringBuilder: Capacity: 65536 : 00:00:02.9687500
StringBuilder: Capacity: 16777216 : 00:00:02.9062500

三百万回に増やしてもあまり変わらないね。本当はこのあと一千万回も試そうとしたんだけど、512MB のメモリしかない私のマシンではメモリを使い尽くしてスワップが発生し始めたので取りやめた。

キャパシティを指定した場合とそうでない場合で有意な差は見いだせなかった。もちろん、実行環境やデータのサイズによっても変動してくるとは思う。ただ、キャパシティの値はとりあえずデフォルトでも良いかなあ。とにかく += じゃなくて StringBuilder を使う方が大切ってことだな。極限までチューニングする必要があるときは、計測した上でどうするか決めれば良い。でも、そういう時ってたぶん StringBuilder 以外にボトルネックがありそうな気がする。

「Winny の技術」を読了した。この本はピアツーピア (P2P) のファイル共有ソフト Winny を、その作者の金子勇氏が解説した技術解説本。純粋に Winny の設計と実装を解説した技術本であるため、Winny の使い方や法律論などは載っていない。

2005-10-05 の『Winny の技術解説本「Winny の技術」を発注』で購入しておいたのだが、読むのがだいぶ遅くなってしまった。

- 資料的価値がある

今まで Winny のソースコードやプロトコルは非公開だった。Winny の設計や実装を学ぶためには、配布された実行ファイルをソースコードに逆変換したりするリバースエンジニアリングや、通信パケットを解析するのが一般的だったようだ。また、作者自身とユーザーが掲示板などに書き込んだ情報を元に推測するということもおこなわれていた。

Winny のネットワークは大規模といえるレベルまで成長しており、その設計と実装を作者自らが解説したこの本は、資料的価値がある。以下に参考になった部分を列挙する。

- 上流と下流によるノードの重み付け

Winny では、Winny ネットワークに参加するノードを対等な関係とするのではなく、上流と下流という概念を取り入れ、回線速度や処理性能で分類している。

過去の P2P アプリケーションは参加するノードが入り交じり、全体の効率を落としていた。回線と処理性能に余裕があるノードは上流に位置づけ、大量のデータをやりとりさせる。また、人気のあるファイルは上流でキャッシュするようにし、Winny ネットワーク内での流通速度を上げる。一方、回線や処理性能に余裕のない下流ノードは上流のノードにぶら下がるようにし、相応の負荷に抑える。

この仕組みであれば、上流は負荷が高いがその分大量のファイルを受信できるし、下流よりも広い範囲でファイルを探すことができる。下流は自分の身の丈にあった範囲でファイルを探すことができ、それぞれの住み分けができる。

上流と下流の概念があることで、どんな参加ユーザーでも受け入れることができ、ネットワーク全体の受容能力が高まる。ネットワークの価値は、まず参加しているノードの数で決まる。もちろん、各ノードの持っているリソースの質も重要だが、量は質に転換する。それを踏まえた設計になっているのが素晴らしい。

- クラスタリングによる分割統治

Winny はクラスタという概念を取り入れ、ネットワークの規模が大きくなっても効率を落とさない仕組みを実現している。

参加しているノードの数が増え、ファイルの流通量が爆発的に増えると、流通量全体に占める目当てのファイルの比率が下がる。これはネットワークが成長すると避けられない事態だ。この問題への対処は上流と下流だけでは難しい。そのため、目当てのファイルや保持しているファイルの傾向でノードを分類し、集団 (クラスタ) を形成するようになっている。これにより、目当てのファイルの検索ヒット率と、キャッシュヒット率が向上する。

問題解決の基本は「分割して統治せよ」だ。上流と下流という一次元の軸しかなかった Winny ネットワークにクラスタという別の次元の軸を与えることで、大量のノードを分割して統治することができる。しかも、お互いのクラスタは明確に分割されるのではなく、ある程度のつながりを保持したままゆるく分割されていく。良くできた仕組みだ。

- 自動ダウンロード、自動ハッシュチェック

Winny は自動ダウンロード、自動リトライ、自動ファイルハッシュチェックなど、Winny ネットワークとアプリケーションの信頼性を高める仕組みを導入している。

欲しいファイルを「予約」して Winny を起動しておけば、あとは Winny 自身が勝手にファイルを持っているノードを検索し、リクエストを発行してダウンロードし、ファイルの整合性のチェックまでしてくれる。

この仕組みはユーザの手間を減らすという点で非常に強力だ。とくに、ネットワークアプリケーションで懸念されるデータ化けやファイル破損を、MD5 ハッシュのチェックをおこなうことで回避している点が良い。TCP 自体にエラーチェックの仕組みがあるが、アプリケーションが保証していることが重要だ。

この仕組みがあることで、数百メガバイトを超えるファイルの共有も安心してできるようになる。チェックは自動でおこなわれるので、ユーザーに手間をかけさせない。安心して任せられるので、流通するファイルが増える。その結果、Winny ネットワークはより大きくなる。

全体的に見て、Winny はファイルの交換を促進する良い仕組みを持っている。IX やプロバイダーが Winny のトラフィックの増加に悩んでいたようだが、これだけの機能を備えていれば、それも頷ける。

- 疑問点

共有できるファイルサイズの上限が 2GB というのはちょっと少ない。たとえば、Debian GNU/Linux sarge の DVD ISO イメージは 4GB くらいあったはず。こういう巨大ファイルは分割しなければならない。開発当時のネットワーク回線事情では、この程度のサイズのファイルを気軽に流通させることはできなかったのかもしれない。

表紙がグレーなのは、Winny の利用される形態が「グレーゾーン」だからかな?

2ページ目の鍵の指紋が気になる。金子氏はこれで何をしようとしているんだろう?

Fingerprint:

16B6 7953 A7C1 2DCA 9DEF C7D1 2546 1CCE C03F 2BA3

- Winny の技術 pdf 版を Winny でダウンロード

Winny の技術 winny ネットワーク上で流通しているようだ。以下がファイル情報。左から順に、ファイル名、 Winny 上のトリップ、ファイルサイズ、md5 ハッシュ。

PDF(一般書籍) [金子勇] Winnyの技術 [05-10-03].zip cbwdWRCPoE 1,900,259 9d2dd618c580e38ea6869c51d9ed1107

タヌキ商店のたぬきちがアイテムを買い取ってくれる価格のリスト。五十音順。
今日釣ったり拾ったりしたものだけなので、全然網羅してない。攻略サイト見れば全部載ってるだろうけど、それじゃ楽しくない。

追記。2005-12-02 に「おいでよ どうぶつの森 タヌキ商店 買い取り価格リスト Ver.2」を書いた。

- くだもの

さくらんぼ 100ベル

私のソニック村にはさくらんぼがいっぱいあるので、買い取り価格は100ベルと安め。他の外来の果物なら200ベルになるんじゃないかなあ?

- 魚

アジ 150ベル
ウグイ 200ベル
カレイ 300ベル
スズキ 160ベル

ウグイはちっちゃいのに意外と高い。イシダイとかシーラカンスとか早く釣りたいなー。あれは四匹か五匹釣れば、家が建つくらい高いもんね。まるでマグロ一本釣りみたいだ。

- 貝

エビスガイ 90ベル
サンゴ 250ベル
サンドダラー 60ベル
タカラガイ 30ベル

サンゴは見た目もわかりやすい。見つけたら速攻拾うべし。
ところで、サンドダラーってゲームキューブ版にもあったっけ? そもそもサンドダラーって何?

運用系でやってしまった。監視システムから障害報告が上がってきて驚いた。

「おいでよ どうぶつの森」をプレイするために、ニンテンドー DS を購入。

色は基本のプラチナシルバーを選択。グラファイトブラックとどっちにしようか迷ったんだけど、前のゲームキューブはブラックを選んだし、暗いところでも見つけやすい色にしたかったのでシルバーとなった。

- ヤマダ電機テックランド宇都宮南店

購入先はショッピングセンター アピタの敷地内にできたヤマダ電機テックランド宇都宮南店。11月25日に開店したばかりでオープニングセール中のため、税込13900円で1807ポイント還元という値付けになっていた。ポイントを考えると、まあまあ安いかな? 2005-10-10 の「MCP 70-316 を受験して合格した」で計上した自分用ご褒美予算を使った。本当はプレイステーション3用の予算だったんだけど、おいでよ どうぶつの森とマリオカート DS の魅力には抗えずに使ってしまった。PS3 の予算については発売日が決まった後もう一度考えよう。

ヤマダ電機テックランド宇都宮南店はそんなに広くはない。PC 用マウスの展示が他のヤマダの支店よりもちょっと多めだったかな? 開店から間もないため、店員も客も多かった。DS を買いに来ただけなので、ざっと見て、あとは消耗品だけ買って帰った。

- おいでよ どうぶつの森をプレイ

2005-10-29 の「おいでよ どうぶつの森 ニンテンドーDS をちょっとやりたい」から一ヶ月。とうとう買っちゃった。
2005-10-29 で書いたように、このゲームは動物たちのいる村で生活するというとてものんびりした内容となっている。そのためこのゲームは「毎日ちょっとずつ楽しむ」というプレイスタイルが適している。私は今他にも3本のゲームを進めているのだが、それらの後の息抜きにプレイするのがよさそう。

さあ、ゲームスタート。

お、前作の GC 版のオープニングでは電車で村へ向かってたけど、今回はちょっと違うのね。この話相手のどうぶつ、後ろ姿しか見えないけど、前作にも出てきた彼かな? 今回はまだ歌は聴かせてくれないのか。

自分の名前は、いつも使ってる「あくあ」にしておこう。ゲームによってはアルファベット表記にしたりカタカナ表記にしたりするけど、どうぶつの森だったらひらがなにしておいた方が雰囲気に合ってるかな。村の名前は「ソニック村」で決まり。話相手の彼と話しているうちに村へ到着。

タッチスクリーンの操作にはすぐに慣れた。ボタンと十字キーを使うよりやりやすいかも。役場で地図をもらい、用意された自宅に向かう。自宅みっけ。中に入ると、みかん箱の上にろうそくが一本と、ラジカセが一台あるのみ。うわー、質素だー。怪談とかを話すにはいいかもしれないけど、これじゃあなあ・・・。まあ、これからいろいろコーディネートしていけばいいか。

家の代金を支払うために、ソニック村唯一のお店のタヌキ商店でバイトすることになった。村の掲示板にお店の宣伝を書いたり、お使いしたり、住民に挨拶したり。前もそうだったけど、ここまでがチュートリアルなんだな。良くできてるよなあ。よし、バイト完了。今日はここまでにしておこうか。釣り竿を買ったので、明日は釣りに出かけよう。

ニンテンドーDS の音質はなかなか良いね。少なくとも、ゲームボーイアドバンスのような劣悪な音じゃない。これはすごく重要なこと。私が任天堂の携帯機にそんなにはまらなかった最大の理由は音質の悪さだが、ニンテンドーDS はそれが解消されている。

HttpApplication オブジェクトから発生するイベントの一覧。

セキュリティ保護された ASP.NET アプリケーションの構築 : 動作のしくみ
http://www.microsoft.com/japan/msdn/net/security/SecNetAP04. ...

各 HTTP モジュールには、これらのイベントをフックするイベント ハンドラを実装できます。

BeginRequest    要求処理の開始前に発生
AuthenticateRequest    呼び出し元を認証
AuthorizeRequest    アクセスチェックを実行
ResolveRequestCache    キャッシュから応答を取得
AcquireRequestState    セッション状態をロード
PreRequestHandlerExecute    要求をハンドラ    オブジェクトに送信する直前に発生
PostRequestHandlerExecute    要求をハンドラ    オブジェクトに送信した直後に発生
ReleaseRequestState    セッション状態を保存
UpdateRequestCache    応答キャッシュを更新
EndRequest    処理の終了後に発生
PreSendRequestHeaders    バッファ内の応答ヘッダーを送信する前に発生
PreSendRequestContent    バッファ内の応答本体を送信する前に発生

友達に「http://sonic64.com/img/mail.png の画像ってどうやって作ったの?」と聞かれた。どこかの画像生成サービスで作ったということは覚えてるんだけど、サービスの URL がわからない。「ウェブ全体から検索」に切り替えたうえで、Google で Gmail Icon を検索するとヒット。

E-Mail Icon Generator
http://services.nexodyne.com/email/

このページだったかなあ? 違うような気もするけど、とりあえず生成してくれる画像は想像通りなので、たぶんここだろう。

E-Mail Icon Generator は多数のメールサービスに対応していて、それぞれのサービスの意匠を反映した画像を作ってくれる。こんな感じ。

Gmail
http://services.nexodyne.com/email/icon/b6N0IZUe0MU%3D/ZRw7P ...

Yahoo.co.jp
http://services.nexodyne.com/email/icon/JxajfHjVQRk%3D/hklZ% ...

Hotmail
http://services.nexodyne.com/email/icon/gSwcZ9PsmoM%3D/6vmnU ...

現時点で対応しているサービスは以下の通り。

AOL
ATT
Bigfoot
Blueyonder
Comcast
Cox
Earthlink
GMail
Hotmail
Lycos
MSN
Mac
Netscape
QQ
Rocket
Rogers
SBC
Sina
Spymac
Sympatico
VIPSina
Verizon
Yahoo

- みんなが同じ画像生成サービスを使うと、スパム業者に画像解析されちゃうのでは?

メールアドレスをテキストではなく画像にする理由の一つは、スパム業者やワームにアドレスを収集されないようにするため。でも、みんながみんな同じメールアドレス画像生成サービスを使っていると、画像のパターンからアドレス文字列を解析されてしまうかもしれない。

とくに、画像を自分のサイトにアップロードせずに生成サービスの URL を直接参照して画像を表示させるようにしていると、アドレス収集者に「この画像はメールアドレス画像」というヒントを与えてしまうことになり、より危険性が増すだろう。それを防ぐためには、自分の管理しているドメインや無料ホームページスペースに、メールアドレス画像と類推されないようなファイル名を付けてアップロードするのがよい。前述のメールアドレス画像のサンプルへのリンクなどは危険だ。たとえば、Gmail のメールアドレス画像 URL http://services.nexodyne.com/email/icon/b6N0IZUe0MU%3D/ZRw7P ... なら %3D/R01haWw%3D/0 という文字列が入るようだし。

なんか過敏になってるような気もするが、そのくらい用心しないとスパムは減らない。

無線 LAN ルータを壊してしまった。原因はファームウェアの更新失敗。


壊したのはバッファローの AirStation WHR-G54S という無線 LAN ルータ。ニンテンドーDS の「おいでよ どうぶつの森」を接続するために、2005-11-18 の「ニンテンドーWi-Fiコネクション用 無線LANルータ/アクセスポイント選び」でいろいろ検討した結果選んだものだ。

- WHR-G54S の最新ファームウェア 1.23 ではいくつかの不具合修正済み

amazon で購入し、今日のお昼頃に我が家に配送されてきた。いろいろ設定などをしていたところ、ファームウェアが最新のものでないことに気づいた。私の WHR-G54S のファームウェアのバージョンは 1.20 で、最新版は 1.23 だ。

ちなみにファームウェアは、 ハードウェアほど固定的でなく、ソフトウェアほど頻繁に変更されないものを指す。ファームのスペルは firm で、固いという意味。組み込み機器に搭載されたソフトウェアをこう呼ぶことが多い。

ファームウェアは組み込み機器自身を制御することが多いため、アップデートに失敗するとその機器が使えなくなったりするというリスクがある。リスクがあるので、私はアップデートの必要がなければ手を出さない派なのだが、1.23 では機能追加だけでなく、いくつかの不具合修正がなされているとのこと。

ドライバ ダウンロード WHR-G54S
http://buffalo.melcoinc.co.jp/download/driver/lan/whr-g54s.h ...

Ver1.21→Ver1.23

【不具合修正】

1. マルチクライアント機能を有効にしたイーサネットコンバータを使用した機器が
　　IPアドレスの更新が出来ない不具合を修正しました。
2. 機能設定「インターネット対応ゲームを使う」の設定画面内の補足説明を変更
　　しました。
3. IPフィルタ設定で登録最大数まで入力するとページエラーになる不具合を修正
　　しました。
4. エアステーション名に不正な入力が出来る不具合を修正しました。
5. Flash-ROMへ設定保存時、異常に時間がかかる場合がある不具合を再度、修正
　　しました。
6. システム情報ページの「製品名」項目に詳細な機器情報を表示する様にしました。
7. アドレス変換を使用しない設定で使用した場合に正常に動作しない不具合を修正
　　しました。
8. アタックブロック情報を消去しても再表示される不具合を修正しました。
9. DHCPサーバ設定のDNSサーバとWINSサーバ項目に不正な入力ができる不具合を修正
　　しました。
10. パケットフィルタの設定変更した場合、わずかな時間だけフィルタが効かなくなる
　　不具合を修正しました。
11. ブリッジモード時に機能設定「無線LANの暗号化を設定する」のページで表示されない
　　ページがある不具合を修正しました。
12. アドレス変換設定でポート変換テーブルを既存のグループに対して新規追加した場合に、
　　既存グループの有効無効状態に合わせて追加するように修正しました。
13. WEB設定画面のヘルプの誤記修正/内容追加をしました。

気になるのは 5番、10番、11番だ。私はブリッジモードで使う予定なのでとくに11番は困る。10番のセキュリティ系の不具合も、ルータモードの時のみに問題になることなのですぐには影響がないかもしれないが、こういうのは早めに手当てしておきたい。

- WHR-G54S のファームウェアをアップデートする

アップデートした方が良さそうなので、バッファローのウェブサイトからファームウェア whrg54s-123.exe をダウンロード。自己解凍ファイルを展開して、ブラウザの AirStation 設定画面からアップデートファイルのパスを指定して POST する。「更新には180秒ほどかかる」という画面が出た。どうやら正常にアップデートファイルを WHR-G54S に転送できたようだ。更新が終わるまでしばらく待つ。

しかし、更新中を示す本体のランプの点滅がいつまで経っても収まらない。1時間くらい待ってもずーっと点滅中。不具合の5番「Flash-ROMへ設定保存時、異常に時間がかかる場合がある不具合」に該当しているのかもしれないが、それにしても時間がかかりすぎる。やばいかも。

メーカーのウェブサイトの FAQ を探してみる。

ファームウェアの更新に失敗した場合の対処方法【AirStation、BroadStation】
http://qa.buffalo.jp/eservice/qid.asp?id=BUF2943

ファームウェア更新失敗後、製品本体前面のDIAGランプが点滅(点灯)している場合、
一度電源の抜き差しを行ない、点滅(点灯)が消えることを確認ください。

うん、やってみよう。・・・。DIAG ランプの点滅は収まったけど、パワーランプしか点灯しなくなった。これってどうなの?

電源の抜き差しを行ってもDIAGランプが点滅(点灯)し続ける場合、もしくは
　Powerランプのみが点灯し、Wirelessが点灯しない場合、誠に申し訳ございませんが、
　製品本体とACアダプタを弊社修理センターまでお送りください。

ダメじゃん。壊れたー。一応本体の初期化スイッチを押してみるが、症状は変わらず。えー、ファームウェアのアップデート失敗って、こんな簡単に発生するものなの? マニュアルの手順を踏んだだけなのに? 今までマザーボードのファームウェア更新とか何度もやってきたけど、失敗したのは初めてだ。マザーボードなどでは、BIOS 用のフラッシュメモリを複数搭載していて、一個がダメになったらスペアから起動できるようになってるものがあるが、家庭用ルータではまだ一般的ではないようだ。

あ、ファームウェアが壊れていても、無線とルータ部分が使えないだけで、スイッチングハブとしては使えるのね。って、それじゃあ買った意味がないよー。購入してから5時間くらいで、無線 LAN ルータが単なるスイッチングハブになっちゃった・・・。

仕方ないのでメーカーのサポート行き。web から修理依頼をかけて修理受付番号を発行してもらい、それを書いた紙を添えてメーカーに送る。早くよくなって帰ってきてね。

- 「おいでよ どうぶつの森」もまだ届かない

ちなみに今日はニンテンドーDS の「おいでよ どうぶつの森」の発売日。amazon にはすでに発注済みだけど、まだ発送されていない模様。

なんだか不運が続くなあ。もっとも、まだニンテンドーDS 本体を買ってないから、ソフトだけ到着してもプレイできないんだけどね。ルータの修理には6から9営業日かかると書いてあったし、まあ気長に待ちますか。

先日、Visual Studio のユーザーグループ VSUG が発足した。

Visual Studio User Group > ホーム
http://vsug.jp/

vsug.jp にはユーザーが投稿できるフォーラムと呼ばれる掲示板があり、RSS も提供されている。しかし、それらを一気に RSS リーダーに登録する簡単な方法がない。RSS Auto Discovary もないし、OPML もない。

手軽に登録したいので OPML を作った。以下をファイル名 opml.xml などとして文字コード UTF-8 で保存し、OPML 対応の RSS リーダーに読ませればすべてのフォーラムを一気に購読できる。

<?xml version="1.0"?>
<opml version="1.1">
<head>
  <title>Planet .NET Japan</title>
  <dateCreated>Tue, 22 Nov 2005 15:18:02 +0000</dateCreated>
  <dateModified>Tue, 22 Nov 2005 15:18:02 +0000</dateModified>
  <ownerName>Saito Hiroaki</ownerName>
  <ownerEmail><img src="http://sonic64.com/img/mail.png" /></ownerEmail>
</head>

<body>
  <outline text="VSUG - .NET Framework" title="VSUG - .NET Framework" type="rss" xmlUrl="http://vsug.jp/Rss/GetRss.aspx?forumid=51&amp;nossl=x"/>
  <outline text="VSUG - Office 開発・VSTO" title="VSUG - Office 開発・VSTO" type="rss" xmlUrl="http://vsug.jp/Rss/GetRss.aspx?forumid=54&amp;nossl=x"/>
  <outline text="VSUG - VSUGからのお知らせ" title="VSUG - VSUGからのお知らせ" type="rss" xmlUrl="http://vsug.jp/Rss/GetRss.aspx?forumid=70&amp;nossl=x"/>
  <outline text="VSUG - Visual Basic" title="VSUG - Visual Basic" type="rss" xmlUrl="http://vsug.jp/Rss/GetRss.aspx?forumid=44&amp;nossl=x"/>
  <outline text="VSUG - Visual C#" title="VSUG - Visual C#" type="rss" xmlUrl="http://vsug.jp/Rss/GetRss.aspx?forumid=45&amp;nossl=x"/>
  <outline text="VSUG - Visual C++/CLI その他" title="VSUG - Visual C++/CLI その他" type="rss" xmlUrl="http://vsug.jp/Rss/GetRss.aspx?forumid=46&amp;nossl=x"/>
  <outline text="VSUG - Visual Studio 2005" title="VSUG - Visual Studio 2005" type="rss" xmlUrl="http://vsug.jp/Rss/GetRss.aspx?forumid=42&amp;nossl=x"/>
  <outline text="VSUG - Visual Studio 旧環境" title="VSUG - Visual Studio 旧環境" type="rss" xmlUrl="http://vsug.jp/Rss/GetRss.aspx?forumid=43&amp;nossl=x"/>
  <outline text="VSUG - Web アプリケーション" title="VSUG - Web アプリケーション" type="rss" xmlUrl="http://vsug.jp/Rss/GetRss.aspx?forumid=47&amp;nossl=x"/>
  <outline text="VSUG - Web ホスティングアプリケーション" title="VSUG - Web ホスティングアプリケーション" type="rss" xmlUrl="http://vsug.jp/Rss/GetRss.aspx?forumid=55&amp;nossl=x"/>
  <outline text="VSUG - データベース・データアクセス" title="VSUG - データベース・データアクセス" type="rss" xmlUrl="http://vsug.jp/Rss/GetRss.aspx?forumid=49&amp;nossl=x"/>
  <outline text="VSUG - マイグレーション・COM 相互運用" title="VSUG - マイグレーション・COM 相互運用" type="rss" xmlUrl="http://vsug.jp/Rss/GetRss.aspx?forumid=53&amp;nossl=x"/>
  <outline text="VSUG - モバイル・スマートクライアント" title="VSUG - モバイル・スマートクライアント" type="rss" xmlUrl="http://vsug.jp/Rss/GetRss.aspx?forumid=50&amp;nossl=x"/>
  <outline text="VSUG - ライティング・セキュアコード" title="VSUG - ライティング・セキュアコード" type="rss" xmlUrl="http://vsug.jp/Rss/GetRss.aspx?forumid=56&amp;nossl=x"/>
  <outline text="VSUG - リッチクライアント・UI コントロール" title="VSUG - リッチクライアント・UI コントロール" type="rss" xmlUrl="http://vsug.jp/Rss/GetRss.aspx?forumid=48&amp;nossl=x"/>
  <outline text="VSUG - 談話室" title="VSUG - 談話室" type="rss" xmlUrl="http://vsug.jp/Rss/GetRss.aspx?forumid=58&amp;nossl=x"/>
  <outline text="VSUG - 運用管理" title="VSUG - 運用管理" type="rss" xmlUrl="http://vsug.jp/Rss/GetRss.aspx?forumid=57&amp;nossl=x"/>
  <outline text="VSUG - 開発プロセス" title="VSUG - 開発プロセス" type="rss" xmlUrl="http://vsug.jp/Rss/GetRss.aspx?forumid=52&amp;nossl=x"/>
</body>
</opml>

VSUG に投稿しておいた。

Visual Studio User Group > フォーラム > VSUG フォーラム RSS の OPML を作りました
http://vsug.jp/tabid/63/forumid/58/postid/479/view/topic/Def ...

崩撃雲身双虎掌 (ほうげきうんしんそうこしょう) は、セガの格闘ゲーム「バーチャファイター」の主人公である結城晶 (ゆうき あきら) の奥義。彼が使っている八極拳に本当にこんなコンボがあるかどうかは知らない。アキラスペシャルとも呼ばれるらしいけど、崩撃と略す方が私の周りでは一般的だった。

「ふっ ふっ はぁっ」のかけ声とともに3段攻撃を放つ。作品によっては技の一部が投げ技になったり打撃技になったり、投げ抜けできたりできなかったりする。でも、そんな細かいこと覚えてても、ゲーム中に投げ抜けコマンドなんか入力する余裕を私は持ち合わせていないので無意味。というかそもそも私はアキラ使いじゃないし、こんな難しいコマンド技出せない。バーチャジャンキーでアキラ使いの弟は出しまくってた。

1段目は崩拳 (ぼんけん）。
両手を大きく広げるタイプの中段攻撃。
強い踏み込みを伴う 震脚 (しんきゃく) を伴うため、画面が揺れたりしたような気もするが、もうあんまり覚えてない。

2段目は鷂子穿林 (ようしせんりん)。
相手の背後に回り込み、自分の背中で体当たりする。鉄山靠 (てつざんこう) との違いを弟が解説してくれたけど全部忘れた。

3段目は双掌 (そうしょう)。
相手を吹っ飛ばす。ガイーンはクリティカルヒットかな? 毎回この音鳴ってたっけ?

有料でもいいから、誰かなんとかして
http://salad.2ch.net/hard/kako/987/987858002.html

7 ：不明なデバイスさん [sage ] ：2001/04/21(土) 22:17
　　　　　ﾌ ｯ
　　　 Λ＿Λ　　　　 ∧＿∧
　 ミ （　´∀｀）　　　 （´Д｀　）
　⊂ニ　　　　ニつ☆（　　　　⊃
ミ　　｜　Π　|　　　 ｜ ｜ ｜　））
　　 （_＿）（＿）　　 （＿（_＿）
　　　　　　　　　　　　　ﾌ ｯ
　　　∧＿∧　ミ　　Λ＿Λ
　　 （´Д｀　）　 ∩（　　´∀）　　ノ
　　⊂　 ⊂　）☆＼_　　　　ニつ　ノ
　　　く　く　く　　ミ ｜〇＼＼　　　ノ
　　　（＿（＿）　　　（_＿） ［＿）
　　ｶﾞ ｲ ｰ ﾝ
　　　∧＿∧　　　　Λ＿Λ
　　 （´Д｀　）☆　 （´∀｀　）　 ﾊ ｯ !
　　　し　　し）　∩ニ ∩ニ ）　≡
　　　　＼＼＼　　　〈 （~＼＼　≡
　　　　　 し し/　　（＿）　（＿|

アスキーアートは古いログを整理していたら見つけた。

よりオリジナルに近い見た目でアスキーアートを鑑賞するには、以下をクリックしてください。フォントの種類や行間の指定などを解除できます。
スタイルシート解除の Bookmarklet (クリックして実行)

?B ってソーシャルブックマークサービスの「はてなブックマーク」の略記だったのね。今まで Unicode 文字が文字化けしてるのかと思ってたよ。

Google Analytics のサポートへ送信した質問に回答があった。意外と早かったね。

ちなみに 2005-11-17 に書いた「Google Analytics のタグを head に入れる理由は?」で送信した質問は以下の通り。

トラッキングコードのインストール位置についての質問です。
質問は二つありあます。

1.
トラッキングコードが JavaScript なのであれば、head 要素以外の場所に
インストールしても動作するのではないでしょうか?

2.
もし head 要素以外の場所にインストールした場合、何か問題はありますか?
たとえば、トラッキングが正常におこなわれない、トラッキングの精度が落ちる、
Google がトラッキングコードを認識しにくくなる、といった不都合はありますか?

以上、よろしくお願いいたします。

Google Analytics サポートからの回答を以下に転載。私の本名の部分は伏せたが、それ以外は原文のまま。

******** *** 様

平素より Google Analytics をご利用いただき、誠にありがとうございます。

このトラッキングシステムは <HEAD></HEAD>タグの間に挿入していただかなければ正常に作動いたしません。
何卒ご理解賜りますようお願い申し上げます。

Google Analytics サポート

ほとんど質問の答えになってない。要するに企業秘密があるので答えられないか、答えたくないか、ヘルプデスク担当者向けマニュアルがないかのいずれかなんだろう。

- 「正常に動作しない」というのはどういうこと? 本当に動かない?

正常に動作しないというのはどういうことだろう? 精度が悪くなる? トラッキングが全くなされない? 「サイトの確認」ができない? 何だろう? ただ、2005-11-17 で書いたように、トラッキングコードを head 要素に入れずに html の一番下の方に配置するように変更したが、問題なくレポートが継続して表示されている。dkiroku さんも私と同様にレポートが表示されているそうだ。

Google Analytics のタグを head に入れる理由は?
http://dkiroku.com/2005-11-18-15.html

で、疑問に思っているのは、なんでトラッキング用のコードのインストール位
置が head 限定なのかということ。

知らなかった。
でもheadに入れてなくてもレポートは出ていますよ。

私と dkiroku さんの2例しかないが、とりあえず解析は可能なようだ。

ただ一つ気になる点がある。私は最初は head 要素にインストールして「サイトの確認」を済ませ、その後疑問に思ってトラッキングコードを html の下の方に移動させた。そうせずに、全く最初から head 要素以外の場所にインストールした場合はどうなるだろう? とりあえず http://sonic.s54.xrea.com/ を解析対象に追加して実験してみることにした。これでいつまで経ってもサイトの確認がなされない場合は、サイトの確認の問題が原因の一つだと推測できる。

追記。
最初から head 要素以外の場所にインストールした http://sonic.s54.xrea.com/ も、レポートが表示されるようになった。とりあえず問題なさそう。

- インストール位置による HTTP トランザクションの中身の変化はない

ふと思ったので、ブラウザが www.google-analytics.com に送信している内容とその応答、いわゆる HTTP トランザクションの中身を比較してみることにした。たぶん違いはないと思うけど。でも、これ載せちゃっていいのかな? 私の環境固有の情報とかかなり入ってるんだけど・・・まあいいか。

まず、当サイト Landscape 流に html の末尾付近に配置した場合。

GET /__utm.gif?utmwv=1&utmn=1809224424&utmsr=1600x1200&utmsc=32-bit&utmul=ja-jp&utmje=0&utmfl=6.0%20%20r29&utmdt=Google%20Analytics%20%u306E%u30BF%u30B0%u3092%20head%20%u306B%u5165%u308C%u308B%u7406%u7531%u306F%3F&utmhn=sonic64.com&utmr=0&utmp=/2005-11-17.html&utmac=UA-54034-1&utmcc=__utma%3D160379711.1091067899.1131959904.1132385137.1132444634.6%3B+__utmb%3D160379711%3B+__utmc%3D160379711%3B+__utmz%3D160379711.1131959904.1.1.utmccn%3D%28direct%29%7Cutmcsr%3D%28direct%29%7Cutmcmd%3D%28none%29%3B HTTP/1.1
Host: www.google-analytics.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.7.12) Gecko/20050919 Firefox/1.0.7
Accept: image/png,*/*;q=0.5
Accept-Language: ja,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: Shift_JIS,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://sonic64.com/2005-11-17.html
Pragma: no-cache
Cache-Control: no-cache

HTTP/1.x 200 OK
Content-Type: image/gif
Last-Modified: Sat, 19 Nov 2005 14:09:27 GMT
Server: ucfe
Content-Length: 35
Date: Sat, 19 Nov 2005 23:57:30 GMT

Google Analytics の指示通り head 要素内に配置した場合。

GET /__utm.gif?utmwv=1&utmn=1910400003&utmsr=1600x1200&utmsc=32-bit&utmul=ja-jp&utmje=0&utmfl=6.0%20%20r29&utmdt=Google%20Analytics%20%u306E%u30BF%u30B0%u3092%20head%20%u306B%u5165%u308C%u308B%u7406%u7531%u306F%3F&utmhn=sonic64.com&utmr=0&utmp=/2005-11-17.html&utmac=UA-54034-1&utmcc=__utma%3D160379711.1091067899.1131959904.1132385137.1132444634.6%3B+__utmb%3D160379711%3B+__utmc%3D160379711%3B+__utmz%3D160379711.1131959904.1.1.utmccn%3D%28direct%29%7Cutmcsr%3D%28direct%29%7Cutmcmd%3D%28none%29%3B HTTP/1.1
Host: www.google-analytics.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.7.12) Gecko/20050919 Firefox/1.0.7
Accept: image/png,*/*;q=0.5
Accept-Language: ja,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: Shift_JIS,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://sonic64.com/2005-11-17.html
Pragma: no-cache
Cache-Control: no-cache

HTTP/1.x 200 OK
Content-Type: image/gif
Last-Modified: Sat, 19 Nov 2005 14:09:19 GMT
Server: ucfe
Content-Length: 35
Date: Sun, 20 Nov 2005 00:05:49 GMT

相違点は utmn=1809224424 が utmn=1910400003 になっているところだけ。名前から推察するに、これはタイムスタンプだろう。それ以外はまったく同じだった。

あともう一つ気になったことが、Cookie を使ってないというところ。同じユーザーかどうかを調べるには、Cookie を使うのが手っ取り早い。そうしない理由は何だろう? 他のパラメータ中に GUID みたいなものがあるんだろうか?

- トラッキングコードのインストール位置、どうする?

トラブルを避けたい人は Google Analytics の指示通り設置するのが良い。HTTP トランザクションレベルでは相違点が見つからなかったが、私が何か見落としている可能性もあるし、また今後何か変更が加えられるかもしれないからだ。

トラッキングコードを head 要素に入れるという条件を満たせないためにGoogle Analytics の利用を見合わせている人は、とりあえず試してみる価値はある。解析結果に100% の精度は得られないかもしれないが、参考にはなる。全く利用できないかもしれないが、とりあえず無料なんだし、試すだけなら簡単。アクセス解析で大変なのは、集計よりは結果の分析の方だし。

私はとりあえず傾向がわかればいいというレベルなので、このまま head にはトラッキングコードをインストールせずに、html の末尾に配置しておくことにする。

2005年12月25日追記。
タグ位置が body 要素の末尾に変更になった。2005-12-25 の「Google Analytics のタグ位置が body の末尾に変更」を参照。

任天堂公式サイトで、ニンテンドーWi-Fiコネクション対応の無線 LAN ルータやアクセスポイントの製品一覧が発表された。

Wi-Fiコネクションサービスにつながる動作確認済み「無線LANアクセスポイント」機種一覧
http://wifi.nintendo.co.jp/information/router/

2005-11-15 の「ニンテンドー DS の Wi-Fi コネクションの接続テスト」では「ニンテンドーWi-Fi USBコネクタ」を検討したが、他に接続したい PC もあるし、そろそろ我が家のネットワークにも無線 LAN を導入しても良い頃。では、私はどの機種を買ったらいいんだろう?

- 我が家のネットワーク構成

確実に無線で接続する機器は、ノート PC 2台とニンテンドーDS。デスクトップ PC は有線 LAN で接続予定。
この他に、PSP (プレイステーションポータブル)、プレイステーション3、任天堂の次世代機「レボリューション」もいずれ購入するので無線で繋ぎたい。購入予定は全くの未定だが。XBOX360は今のところ購入予定無しなので気にしない。

ルータは持っていないが、プロバイダ貸し出しのモデム付きルータはある。貸し出し品なのでプロバイダを乗り換えると返却しなければならない。スイッチングハブは4ポートのものが1台、8ポートのものが1台ある。

- 無線LAN 機器の種類

無線 LAN 機器の種類をメモ。

無線 LAN アクセスポイント
無線 LAN 対応機器の基地局となり、各機器の中継をするもの。「無線 LAN ブリッジ」や「無線 LAN ルータ」などのこと。

無線 LAN ブリッジ
無線 LAN 機器をレイヤ2で接続するだけの無線 LAN アクセスポイント。スイッチングハブのようなもの。

無線 LAN ルータ
レイヤ3のルーティング機能を持った無線 LAN アクセスポイント。ルータモードとブリッジモードを切り替えられる機種もある。

- ニンテンドーWi-Fiコネクション用 無線LANルータ/アクセスポイント選び

私はルータを持っていないので、家庭用のものなら一台くらい手元にあってもいい。というわけで、無線 LAN ブリッジではなく、無線 LAN ルータを買おう。

予算は2万円で。安い機種でもいい。
メーカーにもこだわりがないが、ニンテンドー DS は BUFFALO 無線 LAN 自動設定ツール「AOSS」と NEC の 無線 LAN 自動設定ツール 「らくらく無線スタート」に対応しているので、これら2社のものがいい。私はエンジニアなので、自動設定はたぶん使わないと思うけど。

IEEE802.11a は不要。あってもいいけど、無くても構わない。IEEE802.11g があればいい。


で、選んだ機種が BUFFALO の WHR-G54S。1万円でおつりが来る。無線 LAN ルータとブリッジを切り替えられる。IEEE802.11g にも対応。4ポートのスイッチングハブ付き。私にはこれで十分だな。


WHR-HP-G54 は交信性能を強化したハイパワー版。こっちも検討したけど、私の家ならたぶん WHR-G54S で十分だと思う。


NEC の AtermWR7850S と AtermWR6650S の2機種は IEEE802.11a にも対応。でも、IEEE802.11a は必須じゃないし、BUFFALO の方が手頃な値段なので見送り。

- 動作確認済みルータ・無線アクセスポイント

任天堂のオフィシャルサイトから、動作検証の結果に ○ が付いていた機種を抜粋。なので、NEC のモデルは掲載していない。すべて2005年11月18日現在。たぶん今後検証機種は増えていくだろうし、ユーザーからの報告もあるだろう。

Wi-Fiコネクションサービスにつながる動作確認済み「無線LANアクセスポイント」機種一覧
http://wifi.nintendo.co.jp/information/router/

amazon で買うのも楽でいいけど、これを印刷して近くの電器店に行って品定めして買うのが良いと思う。そのために価格と納期がわかるような形で表示した。

- BUFFALO の Wi-Fiコネクション動作確認済み無線LANアクセスポイント

バッファローは任天堂と提携しているだけあって、最多の動作確認済み機種数を誇る。ただ、どう見ても業務用としか思えないモデルも入ってるね。値段も3倍くらいするものとか。

- コレガの Wi-Fiコネクション動作確認済み無線LANアクセスポイント

「無線ＬＡＮアクセスポイントの送信レートを2Mbpsに設定する。」「無線ＬＡＮアクセスポイントのXR機能をオフに設定する」必要があるものは除外したので、4機種のみ。

- ELECOM の Wi-Fiコネクション動作確認済み無線LANアクセスポイント

- ICOM の Wi-Fiコネクション動作確認済み無線LANアクセスポイント

- I-O DATA の Wi-Fiコネクション動作確認済み無線LANアクセスポイント

- LINKSYS の Wi-Fiコネクション動作確認済み無線LANアクセスポイント

- NETGEAR の Wi-Fiコネクション動作確認済み無線LANアクセスポイント

- PLANEX の Wi-Fiコネクション動作確認済み無線LANアクセスポイント

- Apple の Wi-Fiコネクション動作確認済み無線LANアクセスポイント

- マリオカート DS 動画

マリオカート DS の動画。やばいよ、これ。ちゃんと秒間60フレームで動いてる! Wi-Fi 通信対戦だとここまでのフレームレートは出ないかもしれないけど、普通の通信対戦ならこれくらい行けるのか。

http://media.ds.ign.com/media/682/682877/vids_1.html

私は Google が好きなので、御多分に漏れず Google Analytics を導入している。

Google Analytics
http://www.google.com/analytics/ja-JP/

で、疑問に思っているのは、なんでトラッキング用のコードのインストール位置が head 限定なのかということ。導入の説明やヘルプセンターのサポート文書にもすべて、head 要素内の meta 要素の後 に入れるようにと書いてある。

こういうオプション的なものって、私はページの一番下に配置したい。読み込みとかレンダリングのスピードに影響を与えるだろうし、検索エンジンは先頭 n バイトしかキャッシュしないことが多いから。サイドバーを html 的にメインコンテンツの後に置いているのも同じ理由。はてなの Hatena ID Auto-Discovery も html の最後の方に配置してる。

Google Analytics のヘルプを読んでみる。

ウェブ サイトにトラッキング コードを追加するにはどうすればよいですか。
http://www.google.com/support/analytics/bin/answer.py?answer ...

すべてのウェブ ページの <head> タグと </head> タグの間で、<meta> タグの後に次のコードを挿入します。 インクルードまたはテンプレートを共有している場合は、これらのファイルのいずれかに挿入します。

<script src="http://www.google-analytics.com/urchin.js" type="text/javascript">
</script>
<script type="text/javascript">
  _uacct="UA-xxxx-x";
  urchinTracker();
</script>

やっぱりとくに理由は書いてない。なんでだろう? urtin.js を2分くらい読んだけど、理由になるようなものは見つけられなかった。あ、もしかしてサイト滞在時間とかを厳密に計測するため? それとも Google がトラッキングコードの存在を認識する精度を上げるため?

トラッキングコードの存在を認識する精度を上げるためだったら、認識した後は位置を変えても問題ないんじゃないのかな? 頻繁に再認識してるならダメだけど。

とりあえず試してみるか。「データの待機中: sonic64.com Analytics を正常にインストールし、データの収集を開始しました。 最初のレポートは 12 時間以内に表示できます。」という表示も出たし、レポートも正常に表示されるようになった。この状態で、トラッキングコードを body のかなり下の方に貼り直してみた。さあ、どうなるかな。

考えても埒があかないし、実験だけだと不足なので Google Analytics サポートにも質問を送信した。

トラッキングコードのインストール位置についての質問です。
質問は二つありあます。

1.
トラッキングコードが JavaScript なのであれば、head 要素以外の場所に
インストールしても動作するのではないでしょうか?

2.
もし head 要素以外の場所にインストールした場合、何か問題はありますか?
たとえば、トラッキングが正常におこなわれない、トラッキングの精度が落ちる、
Google がトラッキングコードを認識しにくくなる、といった不都合はありますか?

以上、よろしくお願いいたします。

回答待ち。

追記。
Google Analytics サポートから返答が来た。詳しくは 2005-11-19 の「Google Analytics サポートからタグ位置について返答」を参照。

2005年12月25日追記。
タグ位置が body 要素の末尾に変更になった。2005-12-25 の「Google Analytics のタグ位置が body の末尾に変更」を参照。

2005-11-12 の「フレーム内にある .jpg のリンクを開く JavaScript ブックマークレット」を修正。リンク先が CGI だったら開かないようにした。URL に ? が入っていたら CGI とみなして開かない。

変更した理由は、CGI を連続的に開くとサーバに負荷がかかるから。あと、jpg じゃないのに CGI のクエリ文字列が .jpg で終わってるため jpg と誤判定して開くのを防ぐという目的もある。

javascript:(function() {var max=30; for (var f = 0; f < frames.length; f++) {var z=frames[f].document.links; for(var i = 0; i < z.length && 0 < max; ++i) { if (z[i].href.match(/\.jpg$/i) && z[i].href.indexOf('?') == -1) { void(window.open(z[i].href)); max--;}}}}) ();

フレーム内にある .jpg で終わる URL へのリンクをすべて開く (CGI 除外版)

2005-10-29 に書いた、ニンテンドー DS の「おいでよ どうぶつの森」の発売日が近い。このゲームは無線 LAN の Wi-Fi に対応しているので、そろそろネットワーク環境をどうするか考える。

ニンテンドー DS は標準で IEEE802.11b と 独自規格の無線 LAN に対応している。実際にプレイヤーが集まれるなら独自規格の LAN の方だけで十分。しかし、インターネットを経由した通信や対戦の場合、一般の無線LAN機器はニンテンドー DS の独自規格には対応してないので、どうにかして IEEE802.11b で接続する必要がある。

ニンテンドーWi-Fiコネクション http://wifi.nintendo.co.jp/ のオフィシャルサイトによると、選択肢は3つ。

1.全国に設置される無線欄スポット「ニンテンドーWi-Fi ステーション」に DS を持って行ってプレイ。
2.無線 LAN アクセスポイントや無線 LAN ルータを買って、自室でプレイ
3.「ニンテンドー Wi-Fi USB コネクタ」買って、PC を無線アクセスポイント化する。

1. は恒常的にやるのは無理。自室でリラックスしてプレイしたい。
2. は検討に値する。プレイステーション3も任天堂の次世代機レボリューションも無線 LAN 対応だっていうし、無線 LAN ルータ買ってもいい。
3. もいい。何より簡単そう。

- ニンテンドーWi-Fi USBコネクタと接続テスト

ニンテンドーWi-Fi USBコネクタはなかなかいいな。エンジニアの遊びとしては、こんなものに頼ってないで自分で無線 LAN ルータを設定すべきかもしれないけど。

オフィシャルサイトにニンテンドーWi-Fi USBコネクタを使って接続できるかどうかを確認できるページがあるので、やってみる。ActiveX をオンにして、いざテスト。

http://wifi.nintendo.co.jp/information/check/

接続不可

現在のお客様のネットワーク環境では
ニンテンドーWi-Fiコネクションは
ご利用になれません。

ええええー、そんなー! なんで? うちがプライベート IP アドレス環境だから? プロバイダ変更しなきゃならないかなあ・・・。

結構落胆した。で、何の気無しにブラウザでページをリロードしたわけですよ。そしたら、

接続可能

お使いのネットワーク接続でご使用になれます。

とか言われた。なんか信用できないぞ・・・。まあいいや。

こういうテストって判定の意味がいくつかある。そのテストが「絶対に大丈夫」であることを判定するのか、それとも「全然ダメ」であることを判定するのか、テストによって意味が異なる。

今回は「全然ダメではない」ということなんだろう。何しろ私の環境は2重に NAT された プライベート IP アドレス環境だし、それでも大丈夫な可能性があるとわかっただけでも十分。

ところで、取扱説明書 pdf http://wifi.nintendo.co.jp/usb-connector/usb_manual.pdf の19ページ目「その他: USB ハブや USB1.0/2.0 インターフェイスカード/ボードでは動作しません。」が気になる。私はこれを使うとしたら PC 本体に接続するから問題ないけど、ハブとかじゃダメなんだ。なんでだろう? 供給される電力が足りないとか? そんなことないか。