PHS の解約が予想以上に進み、 2月に 417万人だった契約者数は 6月末には 388万人に減った。 7月下旬に予定していた裁判所への再建計画提出も、 「環境が変わった」として 10月に延期していた。
管財人らは、顧客を守るためにも、再建には通信会社の協力が必要と判断。 XGPを引き受けるソフトバンクに、PHS事業への支援に加わるよう求めていた。

朝日新聞 「ウィルコムのPHS事業縮小へ ソフトバンクが協力」 から引用

「顧客を守る」 などと書くと聞こえはよいが、 PHS サービス継続を望む顧客がどれだけいるかなんて、 「PHS の解約が予想以上に進」んでいることから明らかなはず。 現在 388万人(も) 契約者数が残っていると言ったって、 その大半は 2年縛りのせいで辞めるに辞められない人たちであって (私も 6月末時点だと契約者なのでこの 388万人に含まれている)、 現顧客にとって望ましいのはサービス継続じゃなくて 2年縛りを免除してあげることだと思う。

「顧客」 というと 「債権者」 というイメージが強いし、 この報道のように 「顧客を守る」 と書くとますます 「債権者たる顧客を守れ！」 というイメージが強調されるけど、 実状は 「辞めたいけど契約の縛りで払い続けざるを得ない債務者たる顧客」 と 「辞めていく顧客から少しでも多くの資金を回収したい債権者」 という (報道から受けるイメージとは真逆の) 構図であるわけで、 報道がいかに実状をゆがめたイメージを撒き散らしているかの一例だと思う。

私は丸 4年 (なのでちょうど解約可能なタイミングだった)、 ウィルコムの PHS サービスを利用してきた。 また自宅のバックアップ回線として 4年間近くウィルコムADSL を利用してきた。 なぜウィルコムだったかと言えば、 2006年当時まだ珍しかった 「スマートフォン」 W-ZERO3[es] を使いたかったから。 4年前ドコモショップで、 スマートフォンが使いたいから解約すると伝えたとき、 ドコモも近いうちにスマートフォンを出す予定 (hTc Z) と担当者が言っていたのを思い出す。

その後、 W-ZERO3[es], Advanced W-ZERO3[es], HYBRID W-ZERO3 と 3代続けて W-ZERO3 シリーズを使い続けてきたが、 HYBRID W-ZERO3 のあまりのデキの悪さ (そもそも電話の着信音 / バイブレーションが小さすぎて着信に気付けないのだから電話として失格) に幻滅し、 乗り換えを決意した次第。 輝かしい W-ZERO3 の歴史の最後の最後で欠陥品を出してしまうとは (私は使ったことがないが一つ前の WILLCOM 03 も失敗作だった?)、 いったいシャープに何が起こったのか?

iPhone を使いたいがためにソフトバンクに乗り換える人が圧倒的である昨今、 いまさら言うまでもないことだが、 (2006年ごろから?) 通信サービスは端末のオマケに成り下がったとつくづく思う。 いや、 端末ではなくコンテンツのほうがもっと大事だと言う人がいるかもしれないが、 そうなるのはもう少し先 (少なくともあと 3年くらい先)、 端末がコモディティ化した後の話だと思う。 少なくとも現時点では、 どんなに立派で魅力的なコンテンツでも、 それをユーザに届ける窓口である 「端末」 がヘタレであれば何の意味もない。

一般に解約するのは骨が折れる。 多くの場合、解約は電話のみの受付だったり、 解約通知書を郵送しなければいけなかったりと、いろいろ手間がかかる。 Web だけで契約が済んでしまう入会の時とは対照的。 しかも解約の方法は Web を丹念に見ていかないと見つけられなかったりする。 退会率を下げたいという事業者側の気持ちも (職業がら) もちろん分かるのだが、 解約方法を分かりにくくすればするほどサポートコストは増えるしユーザ満足度も下がるわけで、 結局事業者自身の首を絞めることにしかなってないと思う。

特に、 ウィルコムADSL の解約は大変だったので以下にメモ:

まず何より、Web に 「ウィルコムADSL」 の解約方法が書かれていない。 少なくとも 「ウィルコムADSL 解約」 で検索しただけでは適切なページを見つけられない。 どこに電話すべきか、 あるいはウィルコムプラザ (って神奈川県に一ヶ所しかないのか) に行く必要があるのかすら書いていない。 しかたないので総合窓口 0120-921-156 に電話してみたら、 本人認証を行なって解約理由まで聞いておきながら、 「この電話では解約を承れない、今から電話番号をお伝えするのでかけ直して欲しい」 などとおっしゃる。

こちらは最初から 「ウィルコムADSL を解約したい」 と伝えているのに、 10分以上かけていろいろ調べて手続きした挙げ句に 「かけ直せ」 だったので呆れてしまった。 おそらく 「ADSL」 が自分の担当範囲外であることすら分からない程度の知識で電話オペレータをやっているのだろう。 「ウィルコムADSL を解約したい」 と私が言っても、 「ウィルコムを解約したい」 に脳内で勝手に変換して聞いていたのではないか。

まあ、 コールセンタの電話オペレータのレベルなんて、 ウィルコムに限らずそんなものなのだろうが、 だからなおさら、 何でもかんでも電話オペレータが判断しなくても済むように Web を充実させてお客に勝手に判断させたほうが、 お互いハッピーになれるだろうにと思う。

ウィルコムADSL に関することは、 データ通信に関するお問合わせ番号 0120-921-157 に電話すべきだったようだ。 メインメニューの 4番に 「ウィルコムADSL サービス」 があり、 その中のサブメニュー 2番に 「お申込・ご変更」 がある。 しかしここには 「解約」 の文字はない。

メインメニュー 3番のサブメニュー 2番には 「解約」 の文字があるが、 これはあくまでウィルコムの PHS データ通信の解約で、 eAccess のサービスであるところのウィルコムADSL とは関係ないのだろうと予想し、 メインメニューの 4番のサブメニュー 2番を選択し、 解約したい旨を伝えた。 すると、 「解約したいのはウィルコムの音声通話/データ通信サービスではなくて、 ADSL ですね？」 と聞き返された。 少なくともここのオペレータ (だけ?) は ADSL サービスが PHS サービスとは別に存在することを理解しているようだ。

ところが契約者が妻であることを伝えると 「契約者本人でないと解約できない」 などとおっしゃる。 そもそも契約したときだって私が妻の名義で契約した (^^;) のに、 なぜに解約の時だけ本人でないとダメなのか? とは思ったが、 たまたま隣に妻がいたので、電話を代わってもらう。 そうしたら住所と生年月日を確認しただけで 「本人認証」 が完了してしまい、 再び電話を代わる。 もちろん私だって、 妻の住所と生年月日くらいは知っている。 あまりの無意味さに妻も憮然としていた。

ウィルコムADSLサービスは 「年間契約」 での加入だそうで、 1年間の契約期間中の解約は 2100円を請求するとのこと (1年超の場合。契約から1年以内の解約の場合は 4200円)。 月額料金 (2585円) より安いので躊躇せず今月〆日での解約を申し込む (日割精算も可能)。

すると解約日から 10日以内にモデム Aterm WD735GV を、 AC電源アダプタおよび縦置きスタンドと共に返却せよなどとおっしゃる。 なにぶん 4年近く使い続けたモデムなので送られてきたときの箱がまだあるかどうか... 見つからなければ適当な梱包材を準備しなければならない。 しかも送付先は今から口頭で伝えるのでメモしろとのたまう。 きょうび住所を電話で聞かされる羽目になるとは思ってもみなかった。

「かけがわし しもまた」 などと馴染みのない地名を口頭で言われて、 すぐメモできる人がどれだけいるというのか (文字で書くと簡単そうに見えるが、 声で聞くと 「かけがわ」 だか 「たけかわ」 だか聞き分けにくい)。 「『かけがわ』は掛け布団の掛けに川、 『しもまた』は上下の下に水俣の俣」 などと言われながら (こんな表現を聞くのは何年ぶりだろう? 昔の人はフツーにこういう効率の悪いことをやっていたのだろうけど)、 何度も聞き返しながら苦労して書き取ったので掲載:

〒436-8501 静岡県 掛川市 下俣 800
NECアクセステクニカ株式会社 SL製造部 レンタルグループ
TEL 0537-23-1164

この住所で検索してみると、 eAccess の モデム返却先ページが見つかった。 ウィルコムADSLサービスの Web サイト内に、 同様のページを作るか、 eAccess へのリンクを貼っておけば済む話なのに、 電話で口頭で伝えようとするからコールセンタの人件費は余計にかかるは、 ユーザ (つまり私) の満足度は著しく低下するはで、 何一ついいことがない。 さらに言えば、 10日以内に返却する必要があるならその旨と、 同梱すべきものや梱包方法などと一緒に Web ページに記載してあれば、 解約申込みをする前に余裕を持って準備することができただろう。

ちなみに、 「返却 NECアクセステクニカ SL製造部 レンタルグループ」 で検索すると、 同型モデムを利用している各プロバイダのモデム返却ページが続々と見つかる。 ODN, DTI, Biglobe, So-net, @T COM, @nifty, hi-ho, ASAHIネット,... 等々、 数多くのプロバイダがきちんと解約手続きの方法を Web で説明している中、 ウィルコムADSL だけ(?)が解約方法に全く言及していないのはいかがなものか。

どうして Android にはマルチタッチを活用したアプリケーションが無いのだろう？ と思ったので、 マルチタッチを試すテストアプリ MultiTouch.java (apk) を書いてみた:

タッチした位置にタッチの強さに応じた大きさの円を表示するだけの単純なアプリ。 指を移動すれば円も追随する。 Android ではタッチID が順に割り振られるので、 ID が 0 のタッチを赤色の円で、 ID が 1 のタッチを緑色の円で描いている。

プログラム上は ID が 2 のタッチを青色の円で描くことになっているが、 残念ながら現行の Android で同時に扱えるタッチは 2箇所のみ (追記: Samsung Galaxy S は 5箇所のマルチタッチが可能らしい) なので、 3箇所にタッチしても三つ目の円が描かれることはない。 だから例えば iPhone のアプリにあるような鍵盤楽器アプリを作ろうと思っても、 三つ以上の音を同時に鳴らすことはできない。

とはいえ、 2箇所のタッチを独立に扱えれば、 いろいろ応用が効くだろうにと思いつつ、 このテストアプリをいじっていると...

ありゃ?

上の写真の状態から、 左指を上方へ、右指を下方へ動かしただけなのだが、 両方の指の X 座標 (画面では上下方向) が交わった時点で両方の円の X 座標が入れ替わってしまって、 緑円は右指の動きに合わせて下へ動き、 赤円は左指の動きに合わせて上に動いた。 その結果、 指の位置と円の位置がずれてしまった:

つまり複数のタッチ (x_i, y_i), (x_j, y_j) を個別に扱えるのではなく、 X 座標の集合 {x_i, x_j} と Y 座標の集合 {y_i, y_j} として検知している模様。 例えて言うならダイオード無しのスイッチ・マトリックスみたいな感じ。 だから (x_i, y_i), (x_j, y_j) の 2点をタッチしているのか、 (x_i, y_j), (x_j, y_i) の 2点をタッチしているのか、 の区別ができない。

Android のマルチタッチを扱うプログラムの書き方について解説している Web ページをほとんど見かけないので、 MultiTouch.java についても一応解説:

タッチイベントは、 MotionEvent インスタンスとして Android OS からアプリへ伝えられる。 MotionEvent#getAction() メソッドでイベント種別 (ACTION_DOWN ならタッチ開始、 ACTION_MOVE ならドラッグ、 ACTION_UP ならタッチ終了といった具合) が取得できる。

マルチタッチの場合、 すなわちすでにタッチしている状況において追加で別の場所にタッチした場合、 ACTION_DOWN の代りに ACTION_POINTER_DOWN イベントが伝えられる。 パネルから指が離れてタッチが終わる場合、 まだ他の場所でタッチが継続しているのなら、 ACTION_UP の代りに ACTION_POINTER_UP イベントが伝えられる。

今回のテストプログラムの場合、 タッチの座標が分かればよいので、 ACTION_DOWN, ACTION_POINTER_DOWN, ACTION_MOVE は区別せずに、 put_points メソッド (後述) でイベントの座標を記録している。

	public boolean onTouchEvent(MotionEvent ev) {
	    int action = ev.getAction();
	    switch (action & MotionEvent.ACTION_MASK) {
	    case MotionEvent.ACTION_DOWN:
	    case MotionEvent.ACTION_POINTER_DOWN:
	    case MotionEvent.ACTION_MOVE:
		put_points(ev);
		break;
	    case MotionEvent.ACTION_UP:
		points.remove(ev.getPointerId(0));
		break;
	    case MotionEvent.ACTION_POINTER_UP:
		put_points(ev);
		int index = (action & MotionEvent.ACTION_POINTER_INDEX_MASK)
		    >> MotionEvent.ACTION_POINTER_INDEX_SHIFT;
		points.remove(ev.getPointerId(index));
		break;
	    }
	    Canvas canvas = getHolder().lockCanvas();
	    if (canvas != null) {
		onDraw(canvas);
		getHolder().unlockCanvasAndPost(canvas);
	    }
	    return true;
	}

MotionEvent インスタンスには 複数 (現状 2個までだが、 API 仕様的には 256個まで可能) のタッチの座標および強さ (pressure) が格納できて、 getX(i), getY(i), getPressure(i) の各メソッドを呼び出すことにより、 i番目 (i=0, 1,...) のタッチの X座標、Y座標、強さがそれぞれ取得できる。 タッチの個数は getPointerCount() メソッドで取得できる。 マルチタッチをサポートしない Android 2.0 eclair だと getPointerCount() は常に 1 を返す (ちなみに 1.5 cupcake や 1.6 donut だと getPointerCount() は存在しない)。

各タッチは、 指がパネルに触れてから離れるまで固有の ID が OS によって割り振られるので、 アプリは各タッチの動きをそれぞれ追うことができる。 getPointerId(i) メソッドを使えば i番目のタッチの ID が取得できる。

put_points(MotionEvent ev) メソッドでは、 id をキーとし、 TouchPoint (X座標、Y座標、強さの組) を値とするハッシュテーブル points に、 各タッチの現在値を登録している:

    class TouchPoint {
	public float x;
	public float y;
	public float p;
    }
    Hashtable<Integer, TouchPoint> points;
	...
	points = new Hashtable<Integer, TouchPoint>();
	...

	void put_points(MotionEvent ev) {
	    int count = ev.getPointerCount();
	    for (int i=0; i < count; i++) {
		int id = ev.getPointerId(i);
		TouchPoint p = new TouchPoint();
		p.x = ev.getX(i);
		p.y = ev.getY(i);
		p.p = ev.getPressure(i);
		points.put(id, p);
	    }
	}

現状 ID は 0 または 1 の値しかとらないようなので、 ハッシュテーブル (java.util.Hashtable) は牛刀な感を否めないが、 API 仕様上 ID は int 型としか規定していない (つまり最大値が 1ではなく int 型の上限となる可能性がある ^^;) ので、 配列ではなくハッシュテーブルを使った次第。

あとは SurfaceView#onDraw(Canvas canvas) にて、 points ハッシュテーブルに登録された座標、強さのデータ通りに円を描くだけ。

追記:
twitter で Galaxy S のマルチタッチはマトモと教えていただきました (_O_)
以下、頂いたツイートを (時間順に) 引用:

	gcd_org Androidのマルチタッチについて書いてるページが見当たらなかったのでブログを書いてみました http://www.gcd.org/blog/2010/07/613/ NexusOneだと座標を正しく取得できないケースがあるのですが他の機種だとどうですか？ #androidjp 2010年7月26日 10:41:34
	northeye @gcd_org Galaxy Sはわりとまとものようです http://www.youtube.com/watch?v=hVlsRCMltDg 2010年7月26日 10:45:20
	gcd_org @northeye すごい＞Galaxy Sのマルチタッチ。これで3点以上のマルチタッチがサポートされたら言うことなしですね。 RT Galaxy Sはわりとまとものようです http://www.youtube.com/watch?v=hVlsRCMltDg 2010年7月26日 10:54:20
	northeye @gcd_org 5点までいけるそうです http://www.youtube.com/watch?v=KRCDRXYJBCY 2010年7月26日 10:56:10
	nakamichito Galaxy Sではこんな感じです RT @gcd_org: Androidのマルチタッチについて書いてるページが見当たらなかったのでブログを書いてみました http://www.gcd.org/blog/2010/07/613/ #androidjp 2010年7月26日 11:13:40
	nakamichito URL忘れてた！ http://bit.ly/bFBicn RT @nakamichito: Galaxy Sではこんな感じです RT @gcd_org: Androidのマルチタッチについて書いてるページが見当たらなかったのでブログを書いてみました #androidjp 2010年7月26日 12:25:39

すでに同種のテストアプリが Android Market で公開されていたのですね。
車輪の再発明をしてしまった (後悔はしていない ;-)。

Nexus One や iPhone など全面タッチパネルの携帯電話だと、 (受話器として使うために) 耳に近づけたときタッチパネルが反応しては困る。 そこで近接センサを使って顔が接近してくることを感知し、 タッチパネルを無効にする (ついでにディスプレイをオフにして消費電力を抑える)。

私は Proximity なんて聞くと、 Proximity Warning System (接近警報システム) を思い浮かべてしまうくらいで、 携帯電話用の近接センサがどういうしくみか全く知らなかった。 今年1月の Nexus One の発表の時に近接センサのことを初めて知り、 その時はタッチパネル全体への接近を感知する (静電容量の変化を検知して?) のかと想像したが、 後述するように Nexus One の近接センサはタッチパネルの左上にしかなく、 タッチパネルの下方への接近は感知できないことが分かった。

Nexus One のどこに近接センサが搭載されているか、 センサの感応範囲がどれくらいなのか、 私には見当もつかなかったし、 google で検索してもその手の情報は見つからなかったので、 近接センサが感知した値を表示するだけの簡単なプログラムを書いてみた。

実は、 私にとって初めての android アプリ (^^;)。 しかも、 ここ数年 Java から遠ざかっていたので、 久々に書く Java プログラムだったりする。

お膳立ては Android SDK が全てやってくれるので、 わずか 74行のプログラム。 まず SensorManager#getSensorList メソッドで、 PROXIMITY タイプのセンサを取得し (sensor)、

	sensorManager = (SensorManager)getSystemService(SENSOR_SERVICE);
	List<Sensor> sensors
	    = sensorManager.getSensorList(Sensor.TYPE_PROXIMITY);
	Sensor sensor = sensors.get(0);

この sensor の値が変化したときなどにセンサの値を受け取るリスナ (SensorEventListener) を、 SensorManager#registerListener メソッドで登録するだけ。

public class Proximity implements SensorEventListener {
	...
	sensorManager.registerListener(this, sensor,
				       SensorManager.SENSOR_DELAY_NORMAL);
	...
    @Override
    public void onSensorChanged(SensorEvent event) {
	view.update(event.values);
    }

    @Override
    public void onAccuracyChanged(Sensor sensor, int accuracy) {
    }
}

近接センサの値が変化するとリスナの onSensorChanged メソッドが呼び出されるので、 新しいセンサ値を描画する (view.update):

	void update(float[] values) {
	    Canvas canvas = getHolder().lockCanvas();
	    if (canvas == null) return;
	    canvas.drawColor(Color.WHITE);
	    Paint paint = new Paint();
	    paint.setColor(Color.BLACK);
	    paint.setTextSize(40);
	    float height = paint.getTextSize();
	    for (int i = 0; i < values.length; i++) {
		canvas.drawText(" "+values[i], 0, height * (i + 1), paint);
	    }
	    getHolder().unlockCanvasAndPost(canvas);
	}

Nexus One のタッチパネル左上隅近く (黒枠部分) にセンサがあるらしく、 パネルまで 2cm ほどの距離に物体を近づけると反応する (センサの値が 9.0 から 0.0 へ変化する)。 また、 パネルと並行に物体を動かす場合、 センサの真上から 1cm ほど外れると反応しなくなる。

←

鈴を近づけたことにより、 近接センサが反応して、 値が 0.0 になっている

赤外線型の近接センサ (赤外線を照射し、近接する物体からの反射光を測定するセンサ) なので、 凸面の物体など赤外線があさっての方向へ反射してしまって受光素子に正しく届かない場合や、 あるいは黒色の物体などあまり反射しない場合などでは、 より近づけないと反応しない。

例えば、 黒く細い丸棒などだと 1cm 以下に近づけないと反応しない。 逆に白い紙 (凹面〜平面) など、 効果的に赤外線を反射し、かつ受光素子に反射光が効率的に届くケースだと、 2cm より遠くても (8cm くらいでも) 反応する。

ちなみに、 Nexus One に搭載されている近接センサは、 Capella Microsystems の CM3602 という、 環境光センサ付短距離近接センサ (Short Distance Proximity Sensor with Ambient Light Sensor) であるようだ。 名前の通り環境光も測定できる。 おそらく近接センサの受光素子をそのまま使って照度を測定しているのだろう。

前述したプログラムにおいて、 「Sensor.TYPE_PROXIMITY」 を 「Sensor.TYPE_LIGHT」 に置き換えれば、 環境光センサの値を読み取ることができる。

Android SDK において、 Eclipse を使わずにアプリを開発する方法を説明しているページが少ないので、 蛇足ながらビルド〜インストール方法を書いてみる。 まず android コマンド (Android SDK の tools ディレクトリにある) を使って Project ディレクトリを作る:

T:\src\android>android create project --target 1 --path Proximity --activity Proximity --package org.gcd.test
Created project directory: T:\src\android\Proximity
Created directory T:\src\android\Proximity\src\org\gcd\test
Added file T:\src\android\Proximity\src\org\gcd\test\Proximity.java
Created directory T:\src\android\Proximity\res
Created directory T:\src\android\Proximity\bin
Created directory T:\src\android\Proximity\libs
Created directory T:\src\android\Proximity\res\values
Added file T:\src\android\Proximity\res\values\strings.xml
Created directory T:\src\android\Proximity\res\layout
Added file T:\src\android\Proximity\res\layout\main.xml
Created directory T:\src\android\Proximity\res\drawable-hdpi
Created directory T:\src\android\Proximity\res\drawable-mdpi
Created directory T:\src\android\Proximity\res\drawable-ldpi
Added file T:\src\android\Proximity\AndroidManifest.xml
Added file T:\src\android\Proximity\build.xml

T:\src\android>

「--target <target_ID>」 オプションは、 利用する Android platform library を指定する。 <target_ID> の一覧は、 「android list targets」 を実行することで得られる。

「--activity <activity_name>」 オプションは、 アプリを起動したとき最初に表示される画面のクラス名を指定する。

作った Project ディレクトリ T:\src\android\Proximity の中に、 T:\src\android\Proximity\src\org\gcd\test\Proximity.java があるので、 これを書き換える。 私の場合、 T: ドライブは Linux マシン (正確に言えば coLinux) のファイルシステムなので、 Linux 上の emacs を使って書き換えている。

あとは ant コマンドを使ってビルドするだけ。 Eclipse などの IDE (統合開発環境) を使う必要性を全く感じないのだが...

T:\src\android>cd Proximity

T:\src\android\Proximity>ant debug
Buildfile: T:\src\android\Proximity\build.xml
    [setup] Android SDK Tools Revision 6
    [setup] Project Target: Google APIs
    [setup] Vendor: Google Inc.
    [setup] Platform Version: 2.1-update1
    [setup] API level: 7
    [setup] WARNING: No minSdkVersion value set. Application will install on all Android versions.
    [setup] Importing rules file: platforms\android-7\ant\ant_rules_r2.xml

-compile-tested-if-test:

-dirs:
     [echo] Creating output directories if needed...
    [mkdir] Created dir: T:\src\android\Proximity\gen
    [mkdir] Created dir: T:\src\android\Proximity\bin\classes

-resource-src:
     [echo] Generating R.java / Manifest.java from the resources...

-aidl:
     [echo] Compiling aidl files into Java classes...

compile:
    [javac] C:\android-sdk-windows\platforms\android-7\ant\ant_rules_r2.xml:255: warning: 'includeantruntime' was not set, defaulting to build.sysclasspath=last; set to false for repeatable builds
    [javac] Warning: org\gcd\test\R.java modified in the future.
    [javac] Compiling 2 source files to T:\src\android\Proximity\bin\classes

-dex:
     [echo] Converting compiled files and external libraries into T:\src\android\Proximity\bin\classes.dex...

-package-resources:
     [echo] Packaging resources
 [aaptexec] Creating full resource package...

-package-debug-sign:
[apkbuilder] Creating Proximity-debug-unaligned.apk and signing it with a debug key...
[apkbuilder] Using keystore: C:\Documents and Settings\sengoku\.android\debug.keystore

debug:
     [echo] Running zip align on final apk...
     [echo] Debug Package: T:\src\android\Proximity\bin\Proximity-debug.apk

BUILD SUCCESSFUL
Total time: 6 seconds
T:\src\android\Proximity>

T:\src\android\Proximity\bin\Proximity-debug.apk に apk ファイル (Android Package) ができるので、 adb コマンド (これも Android SDK の tools ディレクトリにある) を使って Nexus One へインストールする。

T:\src\android\Proximity>adb install bin\Proximity-debug.apk
296 KB/s (14596 bytes in 0.048s)
        pkg: /data/local/tmp/Proximity-debug.apk
Success

T:\src\android\Proximity>

あるいは、 T:\src\android\Proximity\bin\Proximity-debug.apk を Web サーバ上に置いて、 Internet 経由でダウンロード & インストールしてもよい (アプリケーションの設定にて、 「提供元不明のアプリ」 のインストールの許可が必要)。

以上、 Windows のコマンドプロンプトでの実行例を示したが、 もちろん Linux 上でも全く同様にビルド〜インストールが可能。

ちなみに私は、 1999年に WorkPad 30J を使い始めて以来、 プライベートなデータを PDA / スマートフォンに集積してきた。 今まで使ってきた PDA / スマートフォンをまとめてみる:

WorkPad 30J から HYBRID W-ZERO3 に至るまで、 全て PC とのデータ同期が基本だったし、 それぞれデータ移行ツールが用意されていたので移行は容易だった。 ところが Nexus One で同じような同期を行なうには、 データを PC ではなく Google Calendar へ置かなければならない。

もちろん、 Google Calendar は共有設定さえ行なわなければ他人に読まれることはないだろうし、 「don't be evil」 と言ってるくらいだから、 Google が勝手にユーザのデータを活用する可能性も無い (と信じたい)。

だからといって、 個人的なデータや会社の超機密事項 (議事メモにはそういった情報も含まれる) も洗いざらい Google に預けてしまう、 なんてことは小心な私にはとてもできない。 よく知られているように Google Calendar は 「限定公開 URL」 が漏れるだけで一巻の終わりであるわけで、 漏れることを前提でリスク評価すべき。

というわけで、 議事メモや日記を Google Calendar に置くことはハナからあきらめて、 Google Calendar には直近の予定だけを置くことにした。 万一漏れても、向こう一週間くらいの予定だけであれば、 致命的というほどでもない。

ところが驚いたことに Google Calendar には過去の予定を一括削除する機能がない。 手作業でいちいち消していかない限り、 データは残り続けるようだ。 当たり障りのない 「予定」 でも積み重なればいろいろ見えてくることがあるわけで、 長年にわたって溜った予定データは脅威となりうる。

どうしてこんな超基本機能が無いのだろうと思いつつ google で検索してみると、 見つかるのは 「どうやったら過去のデータを (一括) 消去できるのか？」 という質問のページばかり。 過去データを削除したい、 というニーズは確実にありそうなのに、 なぜ Google は実装しようとしないのか？ そういえば gmail も過去のメールを溜め続けるのが基本だし、 Google Calendar に自動的に削除する機能がないのは意図的なのかもしれない。

無い機能は作ってしまえと、 Google Calendar API のドキュメントを眺めてみる。 API を叩くためのクライアントライブラリが用意されているようだ。 が、.NET とか Java とか Python とか PHP とか、 あまり気の進まない (^^;) 言語ばかりが並んでいる。 Perl は無いのかっと思って CPAN を検索したら、 Net::Google::Calendar があっさり見つかった。

マニュアル片手にテストプログラムを書いてみる:

use Net::Google::Calendar;
use DateTime;
my $cal = Net::Google::Calendar->new;
$cal->login('sengoku@gmail.com', 'xxxxxxxx');
for my $event ($cal->get_events('start-max' => DateTime->now
				- DateTime::Duration->new(days => 7))) {
    $cal->delete_entry($event);
}

たったこれだけ。 最初に login($user, $pass) して、 get_events(%opts) で「予定」データを取り出して、 delete_entry($event) で削除。 get_events の引数で、 開始時刻が一週間以上過去の予定のみ取り出すよう指定している。

ちょっと書き足して、 ユーザID やパスワードを設定ファイルで設定できるようにしたスクリプト gcal_remove を作ってみた。

% gcal_remove -c /path/to/config.yaml -d 7

などと実行すると、 7日間以上前の予定を削除する。

設定ファイル config.yaml は以下のような感じ:

google_user: sengoku@gmail.com
google_passwd: xxxxxxxx

prgmr.com ならば、 RAM 512MB, ディスク 12GB が月額 $12 (年一括払いなら $115.2) で済むので乗り換えてみた。 Linode のようなユーザフレンドリーな Web ユーザインタフェースは無いし、 時々新規申込みの受付を中止したりする (今も RAM 1024MB 以上のプランは受付けていない) が、 逆に言えば Web インタフェースが不要な人 (含む私) にとっては prgmr.com のシンプルさがむしろ望ましく、 レスキュー用のブートイメージなど必要最低限のものは揃っているので、 不便と感じることはない。 また、 いったん申込みが完了してしまえば受付の一時停止は関係ないわけで、 むしろサーバリソースに見合ったユーザ数しか受付けない姿勢は好感が持てる。

Web から Signup すると、 以下のようなメールが届く。

you ordered a xen vps, 512MiB ram, 12GiB Disk 80 GiB transfer Xen VPS,  $12/month username sengoku 

Before I can set you up, I need to know what distro you would like and an OpenSSH format public key (on a *NIX, run ssh-keygen  and send me either the id_dsa.pub or id_rsa.pub file in an attachment)    

on putty/windows, see

http://www.unixwiz.net/techtips/putty-openssh.html#keypair

and scroll down to the screen shot where it says 'openssh format public key for pasting into authorized_keys' - that is what I need.

thanks. 

OpenSSH の公開鍵くらい Web から登録させればいいのにと思いつつ、 「I need to know what distro you would like」 などと聞いてくるということは多少の融通は聞くのかと思い、 パーティションの切り方をついでにリクエストしてみた (6/4 15:46)。 つまり、 自分で作った Linux distro (配布していないから 「distribution」 と呼ぶのは正確性に欠けるのだが、 それなら何て呼んだらいいのだろう?) をインストールしたいから、 最小のパーティション (例えば 2GB) に ubuntu をインストールしておいてもらえるか？ などとリクエストしてみた:

Hi,

At Fri, 04 Jun 2010 05:48:05 +0000,
support@prgmr.com wrote:

> Before I can set you up, I need to know what distro you would like and
> an OpenSSH format public key (on a *NIX, run ssh-keygen and send me
> either the id_dsa.pub or id_rsa.pub file in an attachment)

I'd like to use my own linux-based image that is running on
fremont.gcd.org (linode) now.  Is it possible to make two partitions
(plus swap partition) ?  One is for a normal ubuntu, and the other is
for my own image.  I'd like to switch these two OSs by pv-grub.

Please minimize the ubuntu partition in order to maximize my own image.
For example, 2GiB for ubuntu, 1GiB for swap, and 9GiB for me.

I've attached my public key id_dsa.pub at the end of this mail.


#9860.
http://www.gcd.org/sengoku/		Hiroaki Sengoku <sengoku@gcd.org>

すると、 4日後の 6/8 09:03 に返事が来た。 リクエストはあっさり無視されて、 ディスク一杯に ubuntu をインストールした状態の VPS が提供されただけ。 個別対応しないのであれば、 自動化したほうがいいような。

Your vps is setup now, your host server is whetstone.prgmr.com.
Login with your username and ssh key and follow the instructions
at http://book.xen.prgmr.com/mediawiki/index.php/Quickstart
For more information about repartitioning, see
http://book.xen.prgmr.com/mediawiki/index.php/Repartition
The default root password for the vps is password, and you
should receive a bill soon by email. If you have any questions
please email support@prgmr.com. Thanks very much.
Nick Schmalenberger

言われた通り ssh でログインしてみる:

senri:/home/sengoku % ssh whetstone.prgmr.com
The authenticity of host 'whetstone.prgmr.com (65.49.73.105)' can't be established.
RSA key fingerprint is 97:52:07:d4:52:8d:c0:cc:13:c7:fb:5d:5d:1b:ab:b4.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'whetstone.prgmr.com,65.49.73.105' (RSA) to the list
of known hosts.
Name                                        ID   Mem VCPUs      State   Time(s)
sengoku                                    xxx   512     1     -b----     11.5

Options for sengoku
1. console
2. create/start
3. shutdown
4. destroy/hard shutdown
5. reboot
6. swap i386/amd64 bootloaders (pvgrub)
7. exit
press the number> 

「6. swap i386/amd64 bootloaders (pvgrub)」 が目を引くが、 PV-GRUB は DomainU 側で実行されるので、 PV-GRUB にて 32bit/64bit の両方のカーネルを立ち上げることができず、 PV-GRUB を実行する前にどちらか一方に決めておく必要がある、 ということのようだ。 デフォルトは (残念なことに) 32bit になっていて、 セットアップしてもらった ubuntu も 32bit 版だった。

「1」 を入力して VPS のコンソールを表示させてみる:

press the number> 1

Ubuntu 10.04 LTS sengoku.xen.prgmr.com hvc0

sengoku.xen.prgmr.com login: root
Password:
Last login: Mon May 31 23:51:42 UTC 2010 on hvc0
Linux sengoku.xen.prgmr.com 2.6.32-22-generic-pae #33-Ubuntu SMP Wed Apr 28 14:57:29 UTC 2010 i686 GNU/Linux
Ubuntu 10.04 LTS

Welcome to Ubuntu!
 * Documentation:  https://help.ubuntu.com/
root@sengoku:~# df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/xvda1            11812024   1068124  10143876  10% /
none                    249488       136    249352   1% /dev
none                    253744         0    253744   0% /dev/shm
none                    253744        28    253716   1% /var/run
none                    253744         0    253744   0% /var/lock
none                    253744         0    253744   0% /lib/init/rw
none                  11812024   1068124  10143876  10% /var/lib/ureadahead/debugfs
root@sengoku:~# 

前掲のメールに書いてあった通り、 ユーザ 「root」 パスワード 「password」 でログインできた。 初めてログインしたのに 「Last login: Mon May 31 23:51:42 UTC 2010 on hvc0」 などと出ているが、 この ubuntu イメージを作ったとき試しに root でログインしたのが残ってしまったのだと思われる。 新規ユーザのセットアップのたびに、 5/31 に作ったイメージを使いまわしているのだろう。

ディスク 12GB のプランのはずなのに 1GB ほど足りないのは swap パーティションがあるから？と思い、 fdisk で確認してみる:

root@sengoku:~# fdisk -l /dev/xvda

Disk /dev/xvda: 12.8 GB, 12884901888 bytes
255 heads, 63 sectors/track, 1566 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

    Device Boot      Start         End      Blocks   Id  System
/dev/xvda1               1        1494    12000523+  83  Linux
root@sengoku:~# 

シリンダの最大値は 1566 なので、 72 (=1566-1494) シリンダが使われずに余っている。 試しにパーティションを割当ててみたら普通に使えた。

自前 distro 10GB, swap 1GB, ubuntu 1GB といった切り分けかたにするため、 レスキュー用のカーネル 「CentOS 5.5 rescue」 をブートしてみる:

    GNU GRUB  version 0.97  (65536K lower / 0K upper memory)

 +-------------------------------------------------------------------------+
 | user bootloader configuration                                           |  
 | CentOS 5.5 rescue (2.6.18-194.3.1.el5xen)                               |
 | CentOS 5.5 installer                                                    |
 | NetBSD 5.0.2 installer                                                  |
 | Ubuntu 10.04 LTS installer                                              |
 |                                                                         |
 |                                                                         |
 |                                                                         |
 |                                                                         |
 |                                                                         |
 |                                                                         |
 |                                                                         |  
 +-------------------------------------------------------------------------+
    Use the ^ and v keys to select which entry is highlighted.
    Press enter to boot the selected OS, 'e' to edit the
    commands before booting, or 'c' for a command-line.

二行目の 「CentOS 5.5 rescue (2.6.18-194.3.1.el5xen)」 を選択してブート。 root でログイン (パスワードは無し) して fdisk を使ってパーティションを切り直した。 せっかくセットアップしてもらった Ubuntu も、 3分と使わずにお別れ。

CentOS release 5.5 (Final)
Kernel 2.6.18-194.3.1.el5xen on an x86_64

sengoku.xen.prgmr.com login: root
[root@sengoku ~]# 
	...
[root@sengoku ~]# fdisk -l /dev/xvda

Disk /dev/xvda: 12.8 GB, 12884901888 bytes
255 heads, 63 sectors/track, 1566 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

    Device Boot      Start         End      Blocks   Id  System
/dev/xvda1               1        1306    10490413+  83  Linux
/dev/xvda2            1307        1438     1060290   82  Linux swap / Solaris
/dev/xvda3            1439        1566     1028160   83  Linux
[root@sengoku ~]# mount /dev/xvda1 /mnt
[root@sengoku ~]# 

私は個人で管理している Linux マシン (自宅と職場と VPS 合わせて十数台, もちろん商用サービスを行なっているサーバではない) のディスクの内容を、 コマンド一発で同一に保てるようにしている (つまりマスタで変更/追加/削除したファイルを各マシンへコピー/各マシンで削除)。

もちろん、 各マシンの性能や 32bit/64bit などの CPU 種別、 ディスクの容量に応じて違う部分もあるわけで、 この同期コマンドは同期先の各マシンに合わせてコピーしないファイルのリストを生成した上で rsync を実行している。 なので、 新しくマシンを増やすときもマスタ上で同期コマンドを実行するだけで、 インストールが完了するはずだが...

senri.gcd.org:/ # mirror -v -r /mnt 'core64[sengoku.xen.prgmr.com]'
BEGIN core64[sengoku.xen.prgmr.com] Tue Jun  8 13:59:14 JST 2010
type: core64
target: sengoku.xen.prgmr.com
rsync --relative -a --numeric-ids --delete -v /bin /etc /lib /sbin /boot /lib64 /usr32 sengoku.xen.prgmr.com:/mnt/
bash: rsync: command not found
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: remote command not found (code 127) at io.c(600) [sender=3.0.6]
senri.gcd.org:/ # 

ありゃ、レスキュー用のディスクには rsync がインストールされていないのか...

レスキュー用のディスクは (当然) 書き込みができないので、 rsync をインストールするのも (tmpfs をマウントすれば可能だが) 面倒。 そこで先に /dev/xvda3 パーティション (1GB) に ubuntu をインストールすることにする。 幸い /dev/xvdf で CentOS, Debian, Ubuntu, NetBSD それぞれのディスクを tar+gzip で固めたもの (tar ball) が提供されているので、 64bit 版 ubuntu と思われる ubuntu64.tar.gz を /dev/xvda3 へ展開:

[root@sengoku ~]# mkdir /tmp/xvdf
[root@sengoku ~]# mount /dev/xvdf /tmp/xvdf
mount: block device /dev/xvdf is write-protected, mounting read-only
[root@sengoku ~]# ls -ln /tmp/xvdf
total 1295052
-rw-r--r-- 1 500 500 242130294 May 17 18:10 centos32.tar.gz
-rw-r--r-- 1 500 500 264319597 May 17 16:25 centos64.tar.gz
-rw-r--r-- 1   0   0 184512292 Jun  3 23:30 debian32.tar.gz
-rw-r--r-- 1   0   0 185773340 Jun  3 11:35 debian64.tar.gz
drwx------ 2   0   0     16384 May 24 04:08 lost+found
-rw-r--r-- 1 500 500   4999925 Feb 28 00:46 netbsd64.tar.gz
-rw-r--r-- 1   0   0 219621325 Jun  3 11:30 ubuntu32.tar.gz
-rw-r--r-- 1   0   0 223411583 Jun  3 11:30 ubuntu64.tar.gz
[root@sengoku ~]# mkdir /tmp/xvda3
[root@sengoku ~]# mount /dev/xvda3 /tmp/xvda3
[root@sengoku ~]# tar xzf /tmp/xvdf/ubuntu64.tar.gz -C /tmp/xvda3
[root@sengoku ~]# vi /tmp/xvda3/boot/grub/menu.lst

この tar ball は /dev/xvda1 に展開することを想定しているらしく、 /boot/grub/menu.lst に (hd0,0) と書いてあるので全て (hd0,2) に置換。 /dev/xvda1 にも /boot/grub/menu.lst を置いて以下の行を追加し、 /dev/xvda3 の menu.lst も起動できるようにしておく。

title  Ubuntu
root (hd0,2)
configfile /boot/grub/menu.lst

前述した 「swap i386/amd64 bootloaders (pvgrub)」 を選択して PV-GRUB を 64bit に切り替えておいて、 このインストールしたばかりの Ubuntu を立ち上げる。 そして前述した mirror コマンドをマスタで実行すれば、 /dev/xvda1 への自前 distro のインストールが完了する。

もちろん、 ホスト名などの設定ファイルや /etc/fstab など各マシンで固有のファイル、 /var/log, /tmp などのディレクトリは mirror コマンドではコピー対象外だが、 これらのファイルやディレクトリが存在しない場合は、 ブートスクリプトにおいて勝手に生成する仕掛けになっている。

Using a kernel.org kernel under xen に書かれているように、 Linux カーネルを Xen のゲスト OS として動かすには Paravirtualized guest support (CONFIG_PARAVIRT_GUEST) を有効にしておく必要がある。
また、xen_blkfront.ko (CONFIG_XEN_BLKDEV_FRONTEND) と xen_netfront.ko (CONFIG_XEN_NETDEV_FRONTEND) の両モジュールも必要。 もちろんカーネルに組み込んでおいてもいいが、 私は実サーバと仮想サーバの両方で同じカーネルを使いたいので、 モジュールにしている。

これで /dev/xvda1 からブートすれば、 使いなれた自前 distro 環境が立ち上がるはず...

root (hd0,0)
 Filesystem type is ext2fs, partition type 0x83
kernel /boot/linuz-2.6.31.13-x86_64 root=/dev/xvda1
initrd /boot/initz-2.6.31.13-x86_64

ERROR Invalid kernel: xc_dom_probe_bzimage_kernel unable to LZMA decompress kernel

xc_dom_bzimageloader.c:393: panic: xc_dom_probe_bzimage_kernel unable to LZMA decompress kernel
ERROR Invalid kernel: xc_dom_find_loader: no loader found

xc_dom_core.c:517: panic: xc_dom_find_loader: no loader found
xc_dom_parse_image returned -1

Error 9: Unknown boot failure

Press any key to continue...

うっ、 LZMA 圧縮したカーネル (CONFIG_KERNEL_LZMA) には対応していないのか。 Linode の場合は非圧縮のカーネルのみブートできたのだが、 prgmr.com の場合は gzip 圧縮したカーネル (CONFIG_KERNEL_GZIP) のみブートできるようだ。 VPS ごとに起動できるカーネルの種類が異なっていて面倒。

gzip 圧縮したカーネル 「linuz-2.6.31.13-gz-x86_64」 を用意して再度挑戦:

root (hd0,0)
 Filesystem type is ext2fs, partition type 0x83
kernel /boot/linuz-2.6.31.13-gz-x86_64 root=/dev/xvda1
initrd /boot/initz-2.6.31.13-x86_64

close blk: backend at /local/domain/0/backend/vbd/xxx/51712
close blk: backend at /local/domain/0/backend/vbd/xxx/51776
close blk: backend at /local/domain/0/backend/vbd/xxx/51792
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 2.6.31.13-x86_64 (sengoku@senri.gcd.org) (gcc version 4.3.4 (GCC) ) #1 SMP Tue Apr 13 17:48:44 JST 2010
[    0.000000] Command line: root=/dev/xvda1
	...
[    0.003333] installing Xen timer for CPU 0
[    0.003333] Calibrating delay loop (skipped), value calculated using timer frequency.. 4003.20 BogoMIPS (lpj=6669120)
	...

Welcome to Linux 2.6.31.13-x86_64.

none.gcd.org login:

無事ブートした。

あとは Linode の時と同様に、 自宅サーバ gw.gcd.org との間にトンネルを設置したり、 gw.gcd.org 上の MySQL から VPS 上の MySQL に対してレプリケーションを行なうようにしたり、 MyDNS を動かしたり、 ns4.gcd.org を 65.49.73.116 へ向けたり、 等々...

最後に、 www.gcd.org の IP アドレスとして VPS の IP アドレス 65.49.73.116 を追加した。

すなわち、 いま読者の皆さんが読んでるこのページは、 1/2 の確率で prgmr.com の VPS が送信したページということになる。 すでに一週間近くこの状態を続けているが、 Linode 360 のときよりはメモリに余裕がある:

prgmr:/home/sengoku % free
             total       used       free     shared    buffers     cached
Mem:        534796     501456      33340          0      35568     114452
-/+ buffers/cache:     351436     183360
Swap:      1060280        556    1059724

• サイボウズオフィス6のカレンダーをiCalendar形式に変換するスクリプト。
• サイボウズofffice8と同期するツール暫定版

あいにく職場のサイボウズはオフィス8 なので、 オフィス8 に未対応の前者は使えない。 後者はオフィス8 用だが、 「暫定版」 と書いてある通りいろいろバグがある。 さくっと修正してみて一応それっぽく動かすことはできたのだが、 使い続けていくとなると一から書き直したほうがいいような気がしてきた (わたし的にはこの手のものを PHP スクリプトでは書きたくない) ので、 perl で書き直してみた。

この perl スクリプト cybozu8_ical を、

% cybozu8_ical --conf /path/to/config.yaml

などと実行すると、 オフィス8 の 「月予定」 (月間スケジュール) ページをアクセスして、 iCalendar 形式に変換する。 向こう一週間以内の予定については 「予定の詳細」 ページもアクセスして、 「メモ」 および 「設備」 も取得する。 「月予定」 の全ての予定について 「予定の詳細」をアクセスすると、 オフィス8 サーバに負荷をかけすぎる懸念があったので、 このような仕様にしてみた。

設定ファイル config.yaml は以下のような感じ:

cybozu_url: http://intra.klab.org/cgi-bin/klcb/ag.cgi
calname: cybozu
userid: 73
password: xxxxxxxx
time_zone: Asia/Tokyo
input_encoding: shiftjis
output_file: /home/sengoku/tmp/cybozu.ics

「cybozu_url」 はオフィス8 の URL を指定する (もちろん intra.klab.org は KLab 社内LAN からしかアクセスできない)。 「userid」 と 「password」 はスケジュールを取得したいユーザの ID とパスワード。 「output_file」 に指定したファイルへ iCalendar 形式のスケジュールを出力する。 「output_file」 を省略すると標準出力へ書き出す。

なお 「--conf /path/to/config.yaml」 オプションを省略すると、 cybozu8_ical と同じディレクトリにある config.yaml が読み込まれる。

cybozu8_ical で生成した iCalendar 形式のファイルは、 とりあえず Google カレンダー および Thunderbird + Lightning で読み込めることは確認したが、 なにぶんまだ RFC 2445 を真面目に読んでいないので、 不具合などあったらご指摘頂けると有難い。

私はオフィス8 の API を知らないので、 「月予定」 「予定の詳細」 のページを取得してきて scrape しているだけ。 「繰り返し予定」 は個々の予定として扱っている。 iCalendar の UID (各予定固有のID) が同じままだと 2個目以降の予定が無視されてしまうので、 UID の末尾に通し番号をつけて互いに区別できるようにしている。

サイボウズのスケジュールは 「場所」 を登録できない。 その代わり 「施設」 として会議室を登録する。 ところが私の職場の場合 「施設」 には会議室だけでなく 「ビデオ会議システム」 などもあったりするので、 「施設」 に登録されているデータをそのまま iCalendar の LOCATION として使うわけにもいかない。 そこで 「施設」 に会議室の名称が登録されている場合のみ、 その会議室名を LOCATION として出力するようにしている。

iCalendar の LOCATION として出力すべき会議室名の一覧を、 cybozu8_ical スクリプトの始めの方で、

my @facility = (
	'20F 大会議室1', '20F 大会議室2', '20F 大会議室3',
	'20F 中会議室1', '20F 中会議室2',
	'20F 小会議室1', '20F 小会議室2',
	'20F 和室', '22F 社長室前MTGｽﾍﾟ-ｽ'
);

などと定義している。 ここに列挙されていない会議室等は 「施設」 に登録されていても単に無視される。

日本でも HTC Desire が発売された今となっては 「いまさら」 感もあるが、 SIM ロック フリーな Nexus One を入手する意味はあると思い、 渡米前に Web サイトで Nexus One を購入し (日本からは、 このサイトへアクセスできないと書いてあるページを見かけるが、 トップページ以外は普通にアクセスできるような...?)、 配送先として滞在する予定のホテルを指定しておいた (配送先に日本の住所は指定できない)。 ただし米国のホテルはテロを警戒して、 非滞在者宛の荷物の受け取りを (事前連絡しても) 拒否するそうなので、 購入手続きは出発直前に行なった。
日本を発つ日 (フライトは晩の 20:50) の早朝 4:57 JST (12:57 PDT) に購入手続きを行なったら、 その翌日 0:02 JST (8:02 PDT) に発送され (FedEx overnight)、 ハワイ到着日の翌日昼間 13:30 HAST にホテルに配達された (日本時間でいうと購入日の 2日後の朝 8:30 JST)。 出発日の前日に購入手続きを行なっていれば到着日に受け取れたかもしれないが、 ホテルにチェックイン (12:00 HAST) する前に配達されるとマズイかも？

ホテルのフロントで Nexus One の小包を受け取って、 SIM を入れて電源 ON したら、 勝手に 3G (W-CDMA) でデータ通信を始めてしまった (当たり前 ^^;)。 Pay As You Go (AT&T のプリペイドSIM) は、 Data Package を追加購入せずにデータ通信を行なうと、 1KB あたり 1セントも課金されるので一瞬で (例えば、わずか 10MB で約1万円) パケ死してしまう。 慌てて無線LAN に切り替えたが既に 87セント課金されていた。 さらに、 位置情報を取得するために 1セント (基地局ID の取得?)、 無線LAN 経由だと google アカウントの同期が行なえなかった (ホテルの LAN の問題?) ので 3G でつなぎ直したら 29セントかかった。 この時点で残度数 $22.73 (SIM カード利用開始時は $25)。

Pay As You Go Online で、 「Login」 ボタンの上にある 「Forgot your password?」 をクリックすると 「Request Your Password」 ページに遷移するので、 AT&T プリペイド SIM の携帯電話番号を入力して 「Send Password」 ボタンを押す。 すると、

1111509064: S: Your account status has changed.
ATT Free Msg: Your password has been changed to 8181.

などといった SMS (ショートメッセージサービス) が送られてくる。 このメッセージ中に書いてある password を使ってログインし、 任意の password に設定し直せばよい。 いったんログインできるようになれば、 米国内外を問わず Web 上で度数の追加 (refill) や追加パッケージ (feature packages) の購入が可能。

追加パッケージには、 Unlimited Talk & Text ($60 で通話と SMS が 30日間使い放題), Messaging Packages ($19.99 で SMS 無制限), Data Packages (データ通信), Night and Weekend Minutes Package ($19.99 で通話と SMS が夜間・週末無制限) があって、 Data Package は、 1MB ($4.99) と 100MB ($19.99) のいずれかを選べる。

Nexus One をいじっていたらすぐ 100MB くらいはいくだろうと思い 100MB を購入した。 実際、 google map をナビ代わりに使う (海外旅行ではすごく便利!) と、 20MB くらいはすぐ使ってしまう。 また google アカウントとの自動同期を行なうと、 何もしなくても一日 1MB くらいは使ってしまうようだ。 あっというまに 100MB を使い切りそうなので、 Data Package 100MB を追加購入することにした。

追加パッケージは、 Credit/Debit カードで支払うこともできるが、 SIM カードの残度数で払うこともできる。 つまり、 いったん度数を購入 (refill) してから、 その度数で追加パッケージを購入するということができる。 なんでそんな回りくどいことを？と思うかも知れないが、 refill だと SIM カードの有効期限を延長できるという違いがある。 例えば $100 refill すると有効期限が 1年後になる ($25〜$75 だと 90日後、$15 だと 30日後)。

有効期限は追加できないので、 例えば有効期限が 3ヶ月後の場合 (新規に SIM カードを購入した場合など) に、 $100 refill したからといって有効期限が 15ヶ月後 (=3ヶ月+1年) になるわけではなく、 refill した時点の 1年後が有効期限になる。 有効期限はもちろん短くはならない。 例えば $15 refill だと有効期限は 30日後だが、 refill 以前の有効期限が 3ヶ月後なら、 3ヶ月後のままで変わらない。
一方、 refill 以前の度数も新しい期限まで有効期限が延長される。 つまり有効期限に達する前に refill し続ければ、 度数を失効させずに済む。 ただし一枚の SIM カードに溜められる度数は $500 が上限。

というわけで、 最初に購入した Data Package 100MB の残りがわずかになった段階で、 $100 refill し、 その度数から $19.99 を使って Data Package 100MB を追加購入した。

つまりサーバをリモートから (ネットワーク経由で ssh ログインして) いじっていると、 ちょっとしたミスで操作不能に陥ってしまうことがある。 例えば NIC を down してしまった、 iptables で DROP する設定にしてしまった、 sshd を殺してしまった、 等々。 あるいは、 リモートから再起動を行なう場合、 起動スクリプトのほんの些細な設定ミスで、 リモートからは操作不能になってしまう。

こんなとき、 2台のサーバのシリアルポート同士を RS-232C クロスケーブル (シリアルケーブル) で接続しておけば、 生きている方のサーバからシリアルケーブル経由でログインできて、 リモートからは操作不能に陥ったサーバのネットワーク設定を修復したり、 sshd を起動し直したり、 あるいは再起動の場合であれば、 GRUB を操作することができる (ML115 などであれば BIOS 設定までいじれる)。

職場のサーバ群は、 もちろん IPMI を利用していて大抵の操作は IPMI でできてしまうのでシリアルケーブルの出番はあまりないのだが、 それでもやはり最後の命綱がある安心感は何ものにも代えがたい。 しかも数百円のケーブル一本で済むのだから、 掛けておくべき保険だろう。

シリアルケーブル経由でサーバにログインするには、 そのサーバの /dev/ttyS0 (シリアルポート COM1 の場合) で getty を動かしておく必要がある。 例えば GCD の場合 mgetty を使っているので、 /etc/inittab に

# Dialin lines
s0:25:respawn:/usr/sbin/mgetty ttyS0

などと設定している。 シリアルケーブルでつながった 2台の Linux サーバ senri と asao において、 asao から senri へシリアルケーブル経由でアクセスすると、 senri のシリアルコンソールが表示される:

asao:/home/sengoku % cu ttyS0
Connected.

Welcome to Linux 2.6.31.13-x86_64.


senri.gcd.org!login: root
otp-md5 299 se5047 ext
Response or Password:
Last login: (null) on /dev/ttyS0

senri.gcd.org:/root # tty
/dev/ttyS0
senri.gcd.org:/root # 

たとえ senri のネットワーク機能が全滅していたとしても、 mgetty は /sbin/init から直接起動されるので影響を受けない。 シリアルコンソールから root でログインして復旧作業を行なうことができる。 逆に、 asao のネットワーク機能が全滅したときは、 senri へ ssh ログインした上で asao へシリアルケーブル経由でアクセスすればよい。 ネットワーク機能が麻痺する可能性があるような危険な作業を senri と asao の両方で同時に行なったりしないようにすれば、 何が起きてもどちらかは生きていることが保証できる。

さて、 両サーバで mgetty が動いているときは以上で問題無いのだが、 どちらかのサーバを再起動するときなど、 mgetty 以外のものが動くときは状況が変わってくる。

例えば asao を再起動すると、 まず GRUB2 が動く。

以前は GRUB Legacy を使っていたのだが、 ハードディスクを入れ替えたとき (数年ごとに 2〜3倍の容量のハードディスクと交換している) 勢い余って root パーティションまで ext4 にしてしまい、 GRUB Legacy だと ext4 をサポートしていないことに気付き、 慌てて GRUB2 をインストールした。

GRUB2 では、 /boot/grub/grub.cfg に

serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1
terminal_input serial console
terminal_output serial console

などと設定しておくことにより、 VGA コンソール (/dev/tty1) とシリアルコンソール (/dev/ttyS0) の両方で GRUB の操作 (つまり起動するパーティション/カーネルを選択する等) を行なうことができる。 つまり VGA コンソールで操作しているときも、 同じ画面がシリアルコンソールでも出力され、 途中からシリアルコンソールで操作することも可能。

GRUB Legacy では、 最初にキー入力があった側のコンソールでの操作が有効になる仕様だった。 最初に VGA コンソール (つまり PC に直接接続された PS/2 or USB キーボード) からキー入力を行なえば、 以後キーボードからの操作が有効になり、 最初にシリアルコンソールからキー入力を行なえば、 以後シリアルケーブル経由の操作が有効になる。

一見 GRUB2 の仕様のほうが便利のように見えるが、 二つの Linux サーバをシリアルケーブルでつないでいると、 GRUB2 の仕様は少し困る。 つまり以下のような GRUB2 のメニュー画面が常にシリアルケーブルへも出力されてしまい、 それが相手サーバの mgetty への入力として扱われてしまうので、 mgetty が余計な動きをする。

                             GNU GRUB  version 1.97

 +--------------------------------------------------------------------------+
 |GNU/Linux 2.6.31.13-x86_64                                                |
 |GNU/Linux 2.6.31.13-i386                                                  |
 |GNU/Linux 2.6.31.12-x86_64                                                |
 |GNU/Linux 2.6.31.12-i386                                                  |
 |GNU/Linux 2.6.31.11-x86_64                                                |
 |GNU/Linux 2.6.31.11-i386                                                  |
 |GNU/Linux 2.6.30.9-x86_64                                                 |
 |GNU/Linux 2.6.30.9-i386                                                   |
 |GNU/Linux 2.6.27.34-x86_64                                                |
 |GNU/Linux 2.6.27.34-i386                                                  |
 |Memtest86+                                                                |
 +--------------------------------------------------------------------------+

      Use the ^ and v keys to select which entry is highlighted.
      Press enter to boot the selected OS, 'e' to edit the commands before
      booting or 'c' for a command-line.

すなわち mgetty は何かキー入力があると、 前述したような 「Welcome to Linux ...」 メッセージとログインプロンプト 「senri.gcd.org!login: 」 を出力する。 この出力がそのまま相手サーバの GRUB2 への入力として扱われてしまう。

つまり 「Welcome to Linux ...」 メッセージは前と後ろに 「改行コード」 が出力されるので、 GRUB2 へ改行が入力されてしまう (改行コード以外のアルファベットが GRUB2 によってコマンドとして認識されると、 もっと面倒なことになる)。 すなわち VGA コンソールに表示された GRUB2 メニューにおいて、 どの OS を起動しようか選ぼうとする間もなく、 改行キーが (シリアルコンソールから) 入力されたことになってしまってデフォルトの OS が勝手に起動してしまう。

一方、 GRUB Legacy の場合は、 何かキー入力があるまでシリアルケーブル側へは何も出力されない (正確に言うと 「Press any key to continue.」 というメッセージのみ出力される)。 相手サーバの mgetty が何か出力すると破綻してしまうが、 以下のような簡単なパッチを GRUB Legacy にあてることにより、 「any key」 ではなく mgetty が出力しないコードを入力したときのみ シリアルコンソールへ切り替えるようにできる。 以下のパッチでは ^G (コントロールキーを押しながら G) をシリアルコンソールで入力したときのみ、 GRUB Legacy のメニュー画面がシリアルコンソールに表示されるようにしている。

diff -ur grub-0.97.org/stage2/builtins.c grub-0.97/stage2/builtins.c
--- grub-0.97.org/stage2/builtins.c	2005-02-16 06:58:23.000000000 +0900
+++ grub-0.97/stage2/builtins.c	2009-04-06 13:31:02.288106510 +0900
@@ -4208,10 +4208,13 @@
 		{
 		  if (term_table[i].checkkey () >= 0)
 		    {
-		      (void) term_table[i].getkey ();
-		      default_term = i;
-		      
-		      goto end;
+                      int term_key_code;
+                      term_key_code = term_table[i].getkey();
+		      if( ( (char)term_key_code ) == 7 )
+                      {
+		      	default_term = i;
+		      	goto end;
+                      }
 		    }
 		}
 	    }
@@ -4227,7 +4230,7 @@
 		    if (term_bitmap & (1 << i))
 		      {
 			current_term = term_table + i;
-			grub_printf ("\rPress any key to continue.\n");
+			grub_printf ("\rPress Ctrl+G key to continue.\n");
 		      }
 		  
 		  /* Restore CURRENT_TERM.  */

GRUB2 でも同様のパッチを作ろうと思ったのだが、 GRUB2 は GRUB Legacy と違って、 シリアルと VGA を切り替える仕組みにはなっておらず、 GRUB Legacy の時のような一行パッチでは済みそうにない。

また、 GRUB2 はまだ開発途上ということもあり、 バージョンが上がるたびにパッチを作るのも大変そうである。 GRUB2 以外のブートローダに乗り換える可能性もあるかもしれない。 一方 mgetty は既に枯れたソフトウェアと言ってよい。 そこで mgetty にパッチをあてて、 mgetty が 「Welcome to Linux ...」 メッセージとログインプロンプトを出力するのを抑制することにした。 mgetty が寡黙になりさえすれば、 相手サーバで GRUB2 だろうがその他のブートローダだろうが、 何が動いていても問題は起きない。

シリアルコンソールから ^G を入力したときのみ、 mgetty が 「Welcome to Linux ...」 メッセージとログインプロンプトを出力し、 ^G が入力されない限りは何も出力しないようにするパッチを作ってみた:

--- mgetty.c.org	2006-01-02 02:13:18.000000000 +0900
+++ mgetty.c	2010-04-17 14:20:54.149714734 +0900
@@ -706,6 +706,11 @@
 	       
 	    if ( c_bool(direct_line) )			/* no RING needed */
 	    {
+		char ch;
+		signal(SIGALRM, sig_goodbye);
+		alarm(ring_chat_timeout);
+		int r = mdm_read_byte(STDIN, &ch);
+		if (r <= 0 || ch != 0x07) break;	/* ^G */
 		mg_get_ctty( STDIN, devname );		/* get controll.tty */
 		mgetty_state = St_get_login;
 		break;

このパッチにより、 ^G が入力された時 (ch != 0x07 が不成立) のみ状態 「St_get_login」 へ遷移する。 つまりシリアルコンソールへログインプロンプトを出力する。 ^G 以外が入力されると、 上記パッチ中の if 文の条件が成立し、 状態変数 mgetty_state が更新されず、 状態 「St_wait_for_RINGs」 に留まる。 つまり何も出力されない。

蛇足だが、 状態 「St_wait_for_RINGs」 というのは、 mgetty がモデムからの 「RING」 送信を待っている状態。 モデムに (公衆回線から) 着呼要求が届いたとき (いわゆる電話機が鳴ってる状態)、 モデムは RS-232C 経由で PC に対して 「RING」 を一定間隔で送信する。 mgetty は RING の回数を数えて指定回数を超えれば、 「ATA」 コマンドをモデムに送信して着呼する (いわゆる受話器を取った状態)。

みなさん、入社おめでとうございます。 社長のお話が終わり、みなさんは挨拶が終わって、 緊張もほぐれてきたのではないかと思います。 ここからは各役員の挨拶なのですが、 なぜか私だけは挨拶だけでなく (長くならない範囲で ^^;) 話もしろということになったらしいので、 話を捻り出してみます。

「考えることが大事」ということは社長のお話にもありましたし、 みなさんも既によく知っていることだと思います。 ただ、 知っていることと実際に実行できることとの間には越えがたい壁があることも事実で、 分かっちゃいるけどついつい考えなくなってしまう、 あるいは考えているつもりが、 いつのまにか深く考えることがなくなってしまうものなのでしょう。 そもそも自分がどのくらい考えているかなんて、 なかなか意識するのは難しいですよね。

入社時にはみんな等しく、 これからは「考える習慣」を身につけよう、 と決意を新たにしたはずなのに、 3年で大きな差がついてしまうのが現実です。 考える習慣を身につけた人がどんどん成長するのに対し、 考えることを習慣化し損なった人は停滞したままなので、 その後も差は広がる一方。 10年 20年もたつととんでもない差になってしまいます。

なぜこんなにも差がついてしまうのでしょうか？ ただやみくもに 「考えよう」 としても、 具体的に何をすればいいのかよく分かりませんよね？ なので逆に何をしてはいけないかについて今日はお話ししたいと思います。 今日からみっちり 2ヶ月間、 新人研修でいろいろなことを学んでいくみなさんにとって、 「何をしてはいけないか」 を押えておくことはきっと役に立つと思います。

私は仕事柄、 面接をする機会が多いのですが、 お会いする人の中には考える習慣が全くない人もいます。 ご本人にはそういう自覚が全く無く、 人並みには考えていると思っているようなのですが、 私から見ると正に 「人生オワタ」 状態で、 なぜそうなってしまったのだろうかと考えているうちに、 ついついその人の身の上を根掘り葉掘り聞いて人生相談モードへ入ってしまうので、 そういうことを繰り返すうちに、 だんだん原因が見えてきたように感じています。

考える習慣を持たない人に共通する問題点として 「無知の知」 ならぬ 「無知の無知」 があります。 自分が分かってないことを分かってない、 自分の浅慮では到底及ばない領域があることが全く想像できない、 いわば 「井の中の蛙」 状態ですね。 「無知の無知」 状態になってしまうと、 今の自分の考え方で満足してしまい、 今の自分の枠を越えて考えてみようという発想がでてきません。 当然、 考える習慣もなくなってしまうわけです。 なぜこうなってしまうのか？ 次の 3つのステップを経て 「無知の無知」 状態に至るケースが多いように思います:

1. 後で調べればいいや
2. 何が分からないのか分からない
3. 分かったつもり

「質問する前に考えろ」 「それくらい Google 検索などを使って調べろ」 「ググれカス」 などと言われるようになったのはいつのころからでしょうか？ 確かに何でもかんでも 「教えて君」 では困りますが、 「すぐ質問すること」 ＝ 「悪いこと」 とする風潮はいかがなものかと思います。 こういう風潮が、 「聞くのは恥ずかしい」 「後で調べればいいや」 という意識を生んでいないでしょうか。

ちなみに私は全く正反対で、 「分からないと言える」 ＝ 「カッコイイ」 と中学生の頃から思い込んでるので、 今でも堂々と 「分からない」 を連発しています。 もちろん、 「CTO がこんなことも知らないのか？」 と思われる (^^;) リスクも無いわけではないので、 TPO を考慮せざるを得ないこともあるのがちょっと残念です。

確かに本当に後で調べるのならまだいいのですが大抵は忘れてしまいます。 仮に忘れずに後で調べて言葉の意味を知ったとしても時間は遡れません。 その場で意味を聞いていれば相手と有益な議論を展開できたのかもしれないのに、 その機会は永久に失われてしまうわけです。

そして何より怖いのは、 知らない言葉が出てきても何とも思わなくなってしまうことです。 ふつう、 相手の話の中に意味が取りにくい言葉があれば気持ち悪く感じ、 なんとかその気持ち悪さを解消しようと思うものだと思うのですが、 「後で調べればいいや」 と思ってるとだんだんこの 「気持ち悪さ」 が無くなってきます。 この 「不感症」 が最初のステップです。

そして一つの話の中に知らない言葉がいくつも出てきても、 何とも思わない状態になると次のステップが見えてきます。 知らない言葉が複数出てくれば、 当然話全体が分からなくなるし、 そもそも話自体に興味が持てなくなります。 こうなってしまうと、 「何が分からないか分からない」 状態に陥ります。 いわゆる 「質問したくても何を質問したらいいのか分からない」 状態ですね。

質問しようとしない人に、 「もっと質問しようよ」 と言うと返ってくる言葉が、この 「何を質問すればいいのか分からない」 です。 話を興味を持って聞くということが無くなってしまっているために、 相手が話していない部分を聞き出そうという意欲が失われてしまっています。 もちろん、 人の興味は十人十色ですから、 ある話題に興味が持てないというのは普通でしょう。 問題なのは、 どんな話であっても興味が持てないことにあります。 しかも本人的にはそれが普通な状態なので、 他人の話を興味を持って聞くということがどんな体験だったのか、 もう覚えていなかったりします。 この 「無関心・無気力」 が第2 のステップとなります。

この第2 のステップの怖いところは自覚症状があまり無いことにあります。 自分は 「無気力」 ではない、 と思う人が大半だとは思いますが、 どんな話を聞いても、 質問したいことが思い浮かばないようだと 「第2 のステップ」 がかなり進行中であるわけで要注意です。 なんとか気付いて危機感を持って欲しいですし、 私はことある毎に 「質問しろ〜」 と口を酸っぱくして言ってるのですが、 長年染み付いた習慣というのはなかなか克服できないものなのかも知れません。

第2 のステップは 「分からない」 ということ自体は自覚できているのでまだ救いがあるのですが、 この症状が進むと第3 のステップである 「分かったつもり」 に至ります。 「分からない」 という意識さえあれば何かのきっかけで 「分かろうとする意欲」 が芽生えるかもしれないのですが、 分かっていないこと自体が分からなくなると、 その可能性すら無くなってしまうので末期的です。

何を聞いても 「分かったつもり」 になってしまって、 表面的な理解だけで満足するようになってしまうと、 自分の考え方と相手の考え方が異なっていてもそれに気付かない、 ということが起り得ます。 つまり相手の話を自分の思考の枠内だけで理解してしまうわけです。 まさに 「無知の無知」 です。

と、 いうわけで今日からの研修では決して疑問点を残さないよう、 積極的に質問してください。 また、 「分かった」 と思っても本当に理解しているのか、 今一度自分を疑ってみてください。

例えば、 半年前に内定式で渋滞の話をしました。 忘れてしまった人は私のブログを参照してください。 社会人経験がまだ無いみなさんには、 あの話を完全に理解することはなかなか難しいのではないかと思いますが、 「分からない」 という感覚を持っていますか？ そして分からないとすればどこが分からないのか考え、 何を質問すれば自分の理解を深められるか是非考えてみてください。

まだまだ自分は 「分かっていない」 と自分を疑うことこそが、 考えを深めていくために必要なのだと思います。 KLab への入社が、 みなさんの人生において飛躍のきっかけとなることを期待します。

gcd.jp のマスタネームサーバである ns.gcd.jp と、 スレーヴネームサーバである ns2.gcd.jp (海外サーバ fremont.gcd.org の別名。 名前の通りカルフォルニア州フリーモントにある) とは、 MySQL のレプリケーションによってゾーンデータを同期させている。 したがってマスタ側での変更が即座にスレーヴ側に伝わる。

ちなみに、 ネームサーバ間の同期でよく利用されるゾーン転送 (AXFR) は、 ゾーンデータを丸ごと転送するので (ゾーンが大きくなってくると) 同期頻度を高くすることが難しく、 ダイナミックDNSサービスにはあまり向いていない。 MySQL のレプリケーションでネームサーバ間の同期が行なえてしまう MyDNS は、 ダイナミックDNSサービス向きと言える。

ところが gcd.org では (ダイナミックではない) 普通のネームサーバ ns1.gcd.org も運用していて、 これは tinydns を利用している。 せっかく海外にサーバ fremont.gcd.org を借りたのだから、 tinydns で管理しているゾーンも fremont.gcd.org で引けるようにしたいが、 fremont に複数 IP アドレスを付与するのはお金がかかる (月額 $1 追加) ので、 fremont で MyDNS と tinydns の両方を走らせるわけにもいかない。

私が借りてるレンタルサーバ (正確に言うと VPS) Linode は、 もともと DNS サービス (マスタ/スレーヴどちらでも、ドメインいくつでも) を無料で利用できるので、 DNS のためだけに 1IP 追加する気にはちょっとなれない。

もちろん、 tinydns を止めてしまって全てのゾーンを MyDNS へ移行してしまうという解決策も無くはないのだが、 MyDNS に全面的に依存してしまうのは恐い気もする。 できれば tinydns 側はいじらずに、 tinydns のゾーンデータを MyDNS 側へ反映させる仕掛けを作りたい。

というわけで、 tinydns のゾーンデータを読み込み、 MyDNS のゾーンデータの形式で MySQL へレコードを書込む perl スクリプト tinydns2mydns を書いてみた (CVSリポジトリ)。

なお MyDNS には、 mydnsimport という外部からゾーンデータを取り込むツールが付属していて、 tinydns のゾーンデータもインポートできるのだが、 以下の欠陥があってゾーン転送目的には使えない:

1. ゾーンの全レコードをいったん削除した上でインポートを行なう実装になっている。
2. SRV レコードをインポートできない。

1. tinydns 側で新しいレコードを追加したとき、 対応するレコードのみを DB に INSERT できる実装になっているかと思いきや、 ソースを確認してみると、 いったん全部 DELETE した後 tinydns のゾーンデータを 1レコードずつ INSERT する実装になっていた。

つまり、 短い時間とはいえ、 ゾーンにレコードが存在しないタイミングが存在する。 したがって、 その瞬間に届いたクエリに対して非存在 (NXDOMAIN) を回答してしまう。 mydnsimport のソースをいじって、 DELETE してから INSERT 完了まで読み込みをロックするようにすれば、 NXDOMAIN を返すこと自体は回避可能だが、 ネームサーバとしての性能を大いに損ねてしまう。

2. tinydns には A, AAAA, NS, CNAME, PTR, MX, TXT 以外の任意のタイプのレコードを定義する方法として、 タイプを数値で指定する汎用記法がある:

:fqdn:n:rdata:ttl:timestamp:lo

Generic record for fqdn. tinydns-data creates a record of type n for fqdn showing rdata. n must be an integer between 1 and 65535; it must not be 2 (NS), 5 (CNAME), 6 (SOA), 12 (PTR), 15 (MX), or 252 (AXFR). The proper format of rdata depends on n. You may use octal \nnn codes to include arbitrary bytes inside rdata.

The tinydns-data program から引用

この記法を利用して、 例えば以下のように SRV レコードを定義できる。

:_jabber._tcp.jabber.jp:33:\000\012\000d\024\225\006jabber\002jp\000:300

つまり fqdn が 「_jabber._tcp.jabber.jp」、 n が 「33」 で SRV の意味。 rdata はタイプによってデータの意味が変わってくるが、 SRV の場合は次のような構造になる:

┌─┬─┬─┬─┬─┬─┬─┬─≫┬─┬─┬─┬─≫─┬─┬─┐
│優先度│ 重み │ポート│長│ホスト名│長│ドメイン名……│０│
└─┴─┴─┴─┴─┴─┴─┴─≪┴─┴─┴─┴─≪─┴─┴─┘

つまり先頭から 2バイトずつ 3つの数値 (ネットワークバイトオーダ) を表わし、 複数個の文字列 (先頭に 1バイトの文字列長) が続いて最後に 0。 前述の SRV レコードの場合であれば、 優先度は 「\000\012」 つまり 8進数で 000 012 だから 10進数だと 10 になる。 以下同様に重みが 100 で、 ポート番号が 5269 で、 続く文字列が 「jabber」 と 「jp」 でホスト名 jabber.jp を意味する。

　優先度　 重み 　ポート　ホスト名
┌─┬─┬─┬─┬─┬─┬─┬─┬─┬─┬─┬─┬─┬─┬─┬─┬─┐
│00　0A│00　64│14　95│06│ｊ│ａ│ｂ│ｂ│ｅ│ｒ│02│ｊ│ｐ│00│
└─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┘
　　10　　 100　　 5269 　　　　　6 文字　　　　　　　　　2 文字

ゾーンファイルの書式で書けば次のようなレコードになる:

_jabber._tcp.jabber.jp.	300	IN	SRV	10 100 5269 jabber.jp.

つまり、 ドメイン jabber.jp における TCP/IP の jabber サービスは、 ホスト jabber.jp の 5269 番ポートにアクセスすればよい、 ということを表わす。 同じサービスを提供するホスト・ポートが複数ある場合、 優先度の数値が (アクセス可能なものの中で) 最小のものに接続することが求められる (MUST)。 同じ優先度のホスト・ポートが複数ある場合は、 重みの比率に応じてアクセスを振り分けるべき (SHOULD)。

tinydns2mydns スクリプトにおいて SRV レコードを変換する部分は次のようになっている:

    # :fqdn:n:rdata:ttl:timestamp:lo
    elsif ($top eq ':') {
	my ($fqdn, $n, $rdata, $ttl, $timestamp, $lo) = @_;
	my $domain = &get_domain($fqdn);
	next unless defined $domain;
	my $name = &get_host($fqdn, $domain);
	if ($n == 33) {
	    $rdata =~ s/\\(\d\d\d)/sprintf("%c", oct($1))/ge;
	    my ($priority, $weight, $port, @target)
		= unpack("nnn(C/a)*", $rdata);
	    &record($sth_insert, $sth_update,
		    $Zones{$domain}, $name,
		    'SRV', "$weight $port " . join(".", @target),
		    $priority, $ttl, $lo);
	}
    }

眺めるだけで処理が見えてくる見通しのよいスクリプトだと思う (自画自賛 ;)。 $n が 33 のとき SRV レコードだから 続く $rdata を読み込んで、 8進数表記 \nnn をバイトデータへ変換し、 「優先度」 「重み」 「ポート」 および複数個の文字列に分解する:

$rdata =~ s/\\(\d\d\d)/sprintf("%c", oct($1))/ge;
my ($priority, $weight, $port, @target) = unpack("nnn(C/a)*", $rdata);

C で書けば何十行にもおよぶであろうこの処理をわずか 2行で書けてしまう perl はスゴイと改めて思う。 あとは分解したデータを MyDNS のレコードの形式に組み立てるだけ:

$Zones{$domain}, $name, "$weight $port " . join(".", @target), $priority, $ttl

mydnsimport のソースが C で 2000行近くもある (MyDNS ライブラリ群のソースを除く) のに対し、 tinydns2mydns はわずか 353行で書けてしまい、 しかも上記 mydnsimport にある欠陥を解決できている。 現状では tinydns の汎用記法のうち SRV しか対応していないが、 スクリプトの見通しがよいため他タイプに対応させるのも容易だろう。

tinydns2mydns スクリプトが DB に書込んだレコードは以下のようになる:

mysql> select * from rr where name='_jabber._tcp';
+-----+------+--------------+------+---------------------+-----+-----+
| id  | zone | name         | type | data                | aux | ttl |
+-----+------+--------------+------+---------------------+-----+-----+
| 817 |   13 | _jabber._tcp | SRV  | 100 5269 jabber.jp. |  10 | 300 |
+-----+------+--------------+------+---------------------+-----+-----+
1 row in set (0.00 sec)

外部のサイトから jabber.jp の SRV レコードを問合わせてみると、 fremont も正しいレコードを返すことが確認できる:

% host -t srv _jabber._tcp.jabber.jp fremont.gcd.org
Using domain server:
Name: fremont.gcd.org
Address: 74.207.241.21#53
Aliases: 

_jabber._tcp.jabber.jp has SRV record 10 100 5269 jabber.jp.

% host -t srv _jabber._tcp.jabber.jp
_jabber._tcp.jabber.jp has SRV record 10 100 5269 jabber.jp.

/* UINT4 defines a four byte word */
typedef unsigned long int UINT4;

と書いてある。 すなわち 32bit 整数として UINT4 型を定義している。 x86_64 Linux を始め多くの 64bit Unix は LP64 すなわち long int (とポインタ) が 64bit な整数データモデルを採用している。 したがって UINT4 型の定義が 「unsigned long int」 のままで、 この MD5 リファレンス実装を使ってしまうと、 32bit であるべき UINT4 型が 64bit になってしまい、 間違ったハッシュ値を算出してしまう。

16bit CPU が主流だった大昔なら 「int が 16bit なデータモデルを採用している環境」 が多かったのかもしれないが、 RFC 1321 が出た 1992年ごろは既に 32bit CPU が主流だったわけで、 UINT4 型を 「int」 と定義しておいてくれてもよかったのにと思う。 そうすれば、 「long が 64bit なデータモデルを採用している環境」 が多くなる昨今でも (int は 32bit のままなので) 問題を起こさずに済んだだろうに。

試しにテストプログラムを書いてみる:

#include <stdio.h>
#include <unistd.h>
#include <string.h>
#include "global.h"
#include "md5.h"
#define DIGEST_LEN 16
#define BUFFER_LEN 256

int main(int argc, char *argv[]) {
    MD5_CTX context;
    unsigned char digest[DIGEST_LEN];
    unsigned char buf[BUFFER_LEN];
    int i;
    MD5Init(&context);
    while ((i=read(0, buf, BUFFER_LEN)) > 0) MD5Update(&context, buf, i);
    MD5Final(digest, &context);
    for (i=0; i < DIGEST_LEN; i++) printf("%02x", digest[i]);
    printf("\n");
    return 0;
}

32bit 環境 (i686 Linux) では正しく動く:

senri:/home/sengoku/src/md5 % uname -m
i686
senri:/home/sengoku/src/md5 % ls
global.h  main.c  md5.h  md5c.c
senri:/home/sengoku/src/md5 % cc -Wall main.c md5c.c
senri:/home/sengoku/src/md5 % file a.out
a.out: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.0.0, dynamically linked (uses shared libs), not stripped
senri:/home/sengoku/src/md5 % echo "Hello, world" | ./a.out
a7966bf58e23583c9a5a4059383ff850
senri:/home/sengoku/src/md5 % echo "Hello, world" | openssl md5
a7966bf58e23583c9a5a4059383ff850

ところが、 64bit 環境 (x86_64 Linux) だと:

senri:/home/sengoku/src/md5 % uname -m
x86_64
senri:/home/sengoku/src/md5 % cc -Wall main.c md5c.c
senri:/home/sengoku/src/md5 % file a.out
a.out: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), for GNU/Linux 2.4.0, dynamically linked (uses shared libs), not stripped
senri:/home/sengoku/src/md5 % echo "Hello, world" | ./a.out
fd578222c6a471623ea1e3eb2b6e6f6b

などと、 誤った MD5 の値が出力されてしまう。

MD5 の値を求めること自体が目的であれば、 誤ったハッシュ値が出力されればすぐ気付くのでいいのだが、 値そのものが目的であることは (当然ながら) あまりなくて、 普通はアプリケーションの中で MD5 を利用するので、 32bit 環境で使っていたアプリケーションを 64bit 環境でコンパイルし直して使おうとするとハマる。

私は qmapop-0.3 (Bert Gijsbers 氏が開発した、qmail 用 APOP 認証パッケージ。 とうの昔に obsolete になってる ^^;) を x86_64 Linux でコンパイルし直したら APOP 認証が通らなくなってしまって焦った。

なにぶん古いプログラム (1995年5月リリース) に いろいろ手を加えて使っていたので、 APOP 認証が失敗するのは必要なパッチをあてていないためだろうと思ってしまった。 しかし最後にコンパイルしたのは何年も前 (2002年4月) なので、 どんな修正を行ったか思い出せない。

仕方ないのでソースをながめて原因を探る羽目になり、 動作させつつ処理を追っていたら、 何のことはない単に算出した MD5 の値が誤ってるだけということに気付き、 (qmapop-0.3 が使ってた) MD5 リファレンス実装がデータモデルに依存していることを見つけた次第。

C99 で stdint.h が定義されて、 整数データモデルに依存しない、 移植性の高い書き方が可能になった。 以下のように global.h を修正すればよい:

senri:/home/sengoku/src/md5 % diff -ub global.h~ global.h
--- global.h~	1993-05-14 02:15:17.000000000 +0900
+++ global.h	2010-02-27 23:49:36.553633806 +0900
@@ -13,11 +13,13 @@
 /* POINTER defines a generic pointer type */
 typedef unsigned char *POINTER;
 
+#include <stdint.h>
+
 /* UINT2 defines a two byte word */
-typedef unsigned short int UINT2;
+typedef uint16_t UINT2;
 
 /* UINT4 defines a four byte word */
-typedef unsigned long int UINT4;
+typedef uint32_t UINT4;
 
 /* PROTO_LIST is defined depending on how PROTOTYPES is defined above.
 If using PROTOTYPES, then PROTO_LIST returns the list, otherwise it

短時間とはいえブログが見えないようなことがあると、 たまたまそのタイミングで (検索エンジン等で見つけて) 訪れた人が、 ブログが既に閉鎖してしまったものと勘違いしてしまうかもしれない。 ここは一つ自宅以外の場所にもサーバを立てて、 回線断の影響を受けないようにしたいところ。 海外のサーバなら地域分散もできてなおよい。

道楽で運営している自宅サーバにそこまで可用性を求めるのは、 やりすぎの感もあるが、 近頃流行りの VPS (Virtual Private Server, 仮想専有サーバ) は、 月額 $20 (初期費用無し) 程度で利用できるらしい。 $20 なら試しに使ってみるのも悪くない。

VPSLink 以外は最安のプランで比較した。 VPSLink には、 メモリ 64MB で月額 $7.95 の Link-1 プラン、 メモリ 128MB で月額 $13.95 の Link-2 プランもあるが、 256MB 未満のメモリではできることも限られてしまうので比較対象から外した。

月額基本料だけを比較すると、 ServerAxis が格安に見えるが、 これは帯域課金が含まれていないためで、 例えば 100GB (送受信の合計バイト数) 使うと $5 加算されて $20 と他社並になる。

データセンタの場所 (というかネットワーク上での位置) によって遅延時間が変わってくるので、 どこのデータセンタを使っているかも重要。 例えば同じ Linode でもデータセンタによって、 日本からアクセスしたときの RTT (Round Trip Time, 往復にかかる時間, ミリ秒) が倍以上変わってくる。 それぞれ 10回ずつ ping を打って、 RTT の最小/平均/最大を比較してみる:

米国西海岸だと RTT は 130msec 程度で済むが、 東海岸は 200msec を超えてしまい、 英国はもっと遠い。 西海岸にデータセンタがあるのは Linode と VPSLink だが、 Linode がデータセンタの情報を詳細に公開しているのに対し、 VPSLink は、 Spry Hosting のシアトルのデータセンタを使用している、 ということ以上の情報を公開していない (しかもこのページは 2006年8月の内容のまま) のが少し気になる。

サポートしている Linux ディストリビューションは、 各社だいたい共通で、 CentOS, Debian, Gentoo, Ubuntu の各バージョンが利用できるが、 VPSLink Ubuntu Plan のページに Ubuntu 9.10 Karmic が書かれていない点も、 ちょっと気になった (ちゃんとポリシーを持って 9.10 をサポートしないのならいいのだが、 どうもそうではなく単に運用の手を抜いているだけのような気配がする)。 Web 界隈での評判も Linode のほうがよさげだったので、 Linode を使ってみることに決めた。

サポートしているディストリビューションのバージョンが古くてもアップグレードできるのだろうが、 帯域で課金されるので最初から新しいバージョンをインストールできる方が好ましい。

おそらく各社ともカーネルも入れ替えることができるのだと思うが、 Linode 以外は使っていないので未確認。 Linode の場合は pv_ops (paravirtualization) を有効にしておけば任意のカーネルを利用できる。 したがって (帯域課金さえ気にしなければ ;-) 任意のディストリビューションの利用 (あるいは完全なカスタマイズ) が可能 (私はまだそこまではやっていない)。

なお、VPS サービスは探すといろいろあるようだ。 前述した 4社と比べると公開している情報が不十分 (特に Virtuozzo/OpenVZ な VPS は実際のパフォーマンスを予想しにくく、 実地に使ってみないとなんとも...) なので私は比較検討対象から外したが、 ダメ元で使ってみるのも面白いかもしれない:

と、いうわけで、 Linode 360 を契約してみた。

Linode のページで、 Linode 360 プランを選んで 「Sign Up Now!」をクリック。 氏名、住所、クレジットカード番号を入力し、 月々払い (Month to month) を選んで申し込むと、 $9.27 の注文書が表示された。 最初の月は月割りで月末までの分を注文するということのようだ (ということは短期間試してみたいときは月末近くに申し込めばよい?)。

米ドル支払いなので、 私が米国に滞在するとき使っている米銀のデビットカード (SSN がないとクレジットカードを発行してもらうのは難しい) を試しに使ってみたら、 何の問題もなく普通に使えた (もちろんクレジットカードならどこの国のカードでも普通に使えるはず)。 日本のデビットカード (J-Debit) はキャッシュカードなので取扱店でしか使えず、 J-Debit が使える店の大半はクレジットカードも使えるので、 J-Debit を使うのは家電量販店くらいのものだが、 米国のデビットカードは (決裁までの期間が短い点以外は) クレジットカードと同等なので便利。

2/17 13:18 に「Complete Order」 ボタンを押して注文を確定すると、 「Payment Receipt」 がメールで届き、 1分後に 「Linode Account Activation」 メールが届いた (13:19)。

そのメールに書いてあった Member's area にログインすると、 データセンタの選択画面が表示されたので、 迷わず米国西海岸の Fremont, CA を選ぶ。 パーティションの設定をして、 インストールするディストリビューションとして 「Ubuntu 9.10 64bit」 を選び、 root のパスワードの設定すると、 インストールが始まって 25秒ほどで完了 (13:22)。

注文してからここまで約5分。

ステータス表示が 「Powered Off」 になっているので、 「Boot」 ボタンを押す (13:29) と 8秒で起動が完了し、 ステータス表示が 「Running」 になった。 試しに手元の PC から ssh でログインしてみる (13:31)。 先ほど設定した root のパスワードを入力すると、 無事ログインできた。

注文してからここまで 15分かかっていない。
あっけないほど簡単に VPS が使える状態になった。

次に、 ssh 公開鍵を設定して鍵認証で ssh ログインできることを確認した上で、 sshd_config を修正して sshd に HUP シグナルを送って、 パスワード認証ではログイン出来ないように設定。 続いて、 csh, tcsh, emacs, screen, stone, dbndns, daemontools, apache2, php5, mysql-server, mysql-client, php5-mysql などを apt-get で次々インストールしていく。 実は stone を apt-get で入れたのは初めての経験。 ちゃんと最新版 stone 2.3e がインストールされてちょっと感動 (*^_^*)。 ありがとうございます ＞ 北目さま。

最後に chsh コマンドでシェルを /bin/csh (私の愛用シェルは今でも csh ^^;) に変更して、 私のホームディレクトリの環境一式を手元の PC から rsync で送り込んで、 emacs を起動すれば、 私の作業環境一式が VPS 上でも使えるようになる。

注文してからここまで 1時間かかっていない。

Linode では逆引きを設定させてくれるので、 私の VPS の IP アドレス 74.207.241.21 の逆引きを fremont.gcd.org に設定した。 あとは、 dnscache を動かして外部のキャッシュサーバに頼らず名前を引けるようにしたり、 私の自宅サーバ gw.gcd.org との間にトンネルを設置したり、 gw.gcd.org 上の MySQL からローカルの MySQL に対してレプリケーションを行なうようにしたり、 等々...

もちろん、 Linode でもキャッシュサーバを提供しているので、 自前のキャッシュサーバを VPS 上で動かす必要は必ずしもないが、 名前引きができないことはあらゆるトラブルの元なので、 可能な限り自前で名前を引きに行くようにしたい。 なお、VPS は自身の IP アドレスを DHCP サーバに問合わせて設定しているので、 /etc/resolv.conf を直接書き換えても DHCP クライアントによって書き戻されてしまう。 そこで /etc/dhcp3/dhclient.conf に 「prepend domain-name-servers 127.0.0.1;」 を追加する (元々コメントアウトされているので先頭の # を取り除く)。

普通の ubuntu マシンをいじってるのと何ら変わらず、 しかも ssh でログインしたときのレスポンスも、 日本にあるサーバへアクセスしたときと同程度に速いので普通に使える。 apt-get しまくったので WordPress を動かす準備はすぐ整った。 VPS 上の MySQL のアカウントは、 gw.gcd.org とは (当然) 異なるパスワードを設定し、 WordPress からローカルの (つまり VPS 上の) MySQL へつなぐよう設定する。 これで (万一) gw.gcd.org 側が落ちても VPS 側だけでブログを表示できる。

一点注意すべきなのは、 レプリケーションは gw.gcd.org から fremont.gcd.org への一方通行なので、 VPS 上の MySQL へ何を書込んでもそれは gw.gcd.org へは反映されないという点。 したがってブログへコメントを書込むときは、 fremont.gcd.org ではなく gw.gcd.org 側へアクセスするように、 ブログの URL http://www.gcd.org/blog/ とは別に、 コメントやトラックバックの URL として http://feedback.gcd.org/blog/ を用意した (feedback.gcd.org は gw.gcd.org のエイリアス)。

もちろん双方向レプリケーションを行なうことも可能だが、 Linode の仮想環境に万一脆弱性があった場合に備えて Linode 側で何が起きても構わないように一方通行にしておく方が無難だろう。 さらに、 Linode 側からレプリケーション用の ID 以外で gw.gcd.org の MySQL をアクセスしようとしても、 たとえパスワードが一致しても通信を遮断する仕掛けを gw.gcd.org 側で組み込んである。

そして WordPress が設定するクッキーのドメインを gcd.org に変更して、 feedback.gcd.org なページ (コメント書込み、トラックバック受付) で設定したクッキーを www.gcd.org なページで参照できるようにする。 wordpress/wp-config.php に以下のコードを入れておけばよい:

if ( !defined('COOKIE_DOMAIN') )
	define('COOKIE_DOMAIN', "gcd.org");

最後に、 www.gcd.org の IP アドレスとして VPS の IP アドレス 74.207.241.21 を追加した。

% dnsqr a www.gcd.org
1 www.gcd.org:
61 bytes, 1+2+0+0 records, response, noerror
query: 1 www.gcd.org
answer: www.gcd.org 12657 A 74.207.241.21
answer: www.gcd.org 12657 A 60.32.85.216

すなわち、 いま読者の皆さんが読んでるこのページは、 1/2 の確率で Linode の VPS が送信したページということになる。 すでに一週間近くこの状態を続けていて、 今のところ 360MB のメモリで一応足りているが、 アクセスが増えてくるとどうなるか少し心許無い。

fremont:/home/sengoku % free
             total       used       free     shared    buffers     cached
Mem:        351508     264236      87272          0       4444      35316
-/+ buffers/cache:     224476     127032
Swap:       262136      39656     222480

統合といっても両ブログは微妙(?)に読者層が異なると思われるし、 何よりページの体裁が大きく変わってしまっては読者の方々を戸惑わせてしまうので、 CTO日記を 「仙石浩明の日記」 の一カテゴリという位置付けにして、 かつページの体裁は WordPress のテーマを切り替えることによって、 どちらのブログもあまり大きな変化がないようにしている。

「仙石浩明CTO の日記」 http://sengoku.blog.klab.org/ をアクセスすると、 次のような PHP スクリプトを走らせた上で、 WordPress を呼び出す (末尾の require 文):

<?php
$new = NULL;
if ($_SERVER['REQUEST_URI'] == "/") {
    $new = "/blog/category/cto/";
} elseif ($_SERVER['REQUEST_URI'] == "/feed/") {
    $new = "/blog/category/cto/feed/";
} elseif (preg_match('@^/\d+/\d+/\d+/@',
		     $_SERVER['REQUEST_URI'], $matches)) {
    $new = $_SERVER['REQUEST_URI'];
...(中略)...
}
if ($new) {
    ...(中略)...
    $ORIG_SERVER_NAME = $_SERVER['SERVER_NAME'];
    $host = "www.gcd.org";
    $_SERVER['SERVER_NAME'] = $host;
    $_SERVER['REQUEST_URI'] = $new;
    $_SERVER['SCRIPT_NAME'] = $new;
    $_SERVER['PHP_SELF'] = $new;
    $abspath = "/usr/local/www/wordpress/";
    $themepath = "${abspath}wp-content/themes/sengoku_cto/";
    define('WP_USE_THEMES', true);
    define('TEMPLATEPATH', $themepath);
    define('STYLESHEETPATH', $themepath);
    require("${abspath}wp-blog-header.php");
...(中略)...
}
?>

つまり http://sengoku.blog.klab.org/ へのアクセスは、 パス名に 「/category/cto/」 を追加することによって、 CTO日記カテゴリへのアクセスに変換する。

ページの体裁については、 「wp-content/themes/sengoku_cto/」 ディレクトリが、 CTO日記のテーマフォルダで、 二つの PHP 定数 TEMPLATEPATH と STYLESHEETPATH をこのディレクトリへ設定することによって、 テーマの切り替えを行なっている。

テーマフォルダの中にあるテーマ関数ファイル 「functions.php」 は、 WordPress の初期化中に読み込まれるので、 ここに PHP スクリプトを書いておくことによって WordPress の挙動を変更することができる。 例えばブログのタイトルを 「仙石浩明CTO の日記」 に変更するには、 以下のスクリプトを functions.php に追加しておけばよい:

function option_blogname_cto() {
    return '仙石浩明CTO の日記';
}
add_filter('pre_option_blogname', 'option_blogname_cto');

つまり、 pre_option_blogname フックに、 option_blogname_cto フィルタを登録する。

WordPress では、 ブログのタイトルなど各種オプションの設定値 (DB に格納している) を、 get_option($setting) 関数を呼び出すことで参照している。 例えばタイトルは get_option('blogname') を呼び出すことで得られ、 URL は get_option('home') で得られる。

get_option($setting) 関数は wp-includes/functions.php で定義されていて、 以下のようにフィルタフック pre_option_* が定義されている:

function get_option( $setting, $default = false ) {
    global $wpdb;

    // Allow plugins to short-circuit options.
    $pre = apply_filters('pre_option_' . $setting, false);
    if ( false !== $pre )
	return $pre;
    ...(中略)...
}

つまり、 「pre_option_設定名」 というフックに登録されたフィルタが値を返すなら、 get_option はオプションの設定値ではなくフィルタが返した値を返すようになる。 前述の例なら、 「pre_option_blogname」 フックに登録された 「option_blogname_cto」 フィルタが 「仙石浩明CTO の日記」 という値を返すので、 get_option('blogname') も 「仙石浩明CTO の日記」 という値を返すようになり、 結果としてブログのタイトルを変更できる、というわけ。

ただし、 前述したように CTO日記は 「仙石浩明の日記」 の一カテゴリという位置付けなので、 ブログのタイトルを変更しただけだと、 ブログ 「仙石浩明CTO の日記」 の 「仙石浩明CTO の日記」 カテゴリということで、 ページのタイトル等が 「仙石浩明CTO の日記 » 仙石浩明CTO の日記」 という冗長なものになってしまう。 そこで、 以下のようなスクリプトを 「functions.php」 に追加して、 タイトルとカテゴリ名が同じときはカテゴリ名が表示されないようにする:

function single_cat_title_cto($category_name) {
    $name = get_option('blogname');
    if ($category_name == $name) return "";
    return $category_name;
}
add_filter('single_cat_title', 'single_cat_title_cto');

single_cat_title フックは、 wp-includes/general-template.php で定義されていて、 ページのタイトルなどに表示されるカテゴリ名を変更することができる。

以上で、 「仙石浩明の日記」 の一カテゴリを 「仙石浩明CTO の日記」 の体裁で見せることができるようになる。 しかし、 元が 「仙石浩明の日記」 であるだけに、 リンク先が全て 「仙石浩明の日記」 のページになってしまう。 例えば、 「仙石浩明CTO の日記」 のトップページの一番下に、 「古い投稿 »」 というリンクがあるが、 このリンク先が http://www.gcd.org/blog/page/2/ になってしまい、 たどると 「仙石浩明の日記」 のトップページの 2ページ目へ遷移してしまう。

また、 本文中 (あるいはサイドバー) に現れるリンクも、 DB のデータは 「仙石浩明の日記」 のパーマリンクを用いているので、 たとえそれが 「仙石浩明CTO の日記」 カテゴリに含まれていても、 そのリンクをたどると 「仙石浩明の日記」 の記事として表示されてしまう。

そこで、 遷移先も 「仙石浩明CTO の日記」 として表示したいリンクを、 フィルタで書き換えることにした。 つまり DB のデータは 「仙石浩明の日記」 へのリンクのままで、 ブラウザに送信する前に都度書き換える。

対象となるリンクは、 記事本文中だけでなく、 前述したページナビ 「古い投稿」 「新しい投稿」 や、 サイドバー (「人気記事」 や 「最近の投稿」) にも現れる。 ページ丸ごと (つまり HTTP レスポンス丸ごと) HTML を書き換えられるフックがあるとよかったのだが、 残念ながらそういうフックは定義されていないようだ。 以下のフックそれぞれについてリンクを書き換えればよさげ:

書き換え対象のリンクを決めるために、 まず CTO日記カテゴリに属す記事の ID を取得する:

function setup_cto_id() {
    global $wpdb;
    global $is_cto_id;
    $result = $wpdb->get_results("SELECT object_id FROM wp_term_relationships WHERE term_taxonomy_id=17", ARRAY_N);
    foreach ($result as $row) {
	$is_cto_id[$row[0]] = 1;
    }
}

あるカテゴリに属す記事ID のデータを取得する関数など、 WordPress に含まれているんじゃないかと探してみたのだが、 見つからなかったので DB に問合わせて取得するようにしてみた。 毎回 DB アクセスが発生してしまうが、 キャッシュとかはアクセス数が増えてから考える (^^;)。 「term_taxonomy_id=17」 が CTO日記のカテゴリ (決め打ち ^^;)。 CTO日記カテゴリに属す記事は、 配列 $is_cto_id[記事ID] に 1 を代入しておく。

次に URL を書き換えるスクリプト:

function replace_URL_cto($matches) {
    global $is_cto_id;
    global $ORIG_SERVER_NAME;
    if (!is_array($is_cto_id)) {
	setup_cto_id();
    }
    if (is_null($matches[2])) {
	if ($matches[1] == "category/cto/") return "http://$ORIG_SERVER_NAME/";
	return "http://$ORIG_SERVER_NAME/$matches[1]";
    } elseif ($is_cto_id[$matches[2]]) {
	return "http://$ORIG_SERVER_NAME/$matches[1]";
    }
    return $matches[0];
}

function convert_URLs_cto($text) {
    $textarr = preg_split("/(<.*>)/U", $text, -1, PREG_SPLIT_DELIM_CAPTURE);
    $stop = count($textarr);
    for ($i = 0; $i < $stop; $i++) {
	$content = $textarr[$i];
	if (strlen($content) > 0) {
	    $content = preg_replace_callback(
		    '@http://www.gcd.org/blog/(\d+/\d+/(\d+)|category/cto/)@',
		    'replace_URL_cto', $content);
	}
	$output .= $content;
    }
    return $output;
}

顔文字を画像に変換して表示するフィルタ wptexturize (wp-includes/formatting.php で定義されている) を参考にさせてもらった。 preg_replace_callback() を使って書き換え対象リンクを探し、 replace_URL_cto で記事ID がCTO日記カテゴリに属す ($is_cto_id[$matches[2]] が TRUE) 場合のみ書き換える。

最後に、 この書き換えフィルタ replace_URL_cto を前述したフィルタフックに追加:

add_filter('the_content', 'convert_URLs_cto');
add_filter('the_category', 'convert_URLs_cto');
add_filter('get_pagenum_link', 'convert_URLs_cto');
add_filter('post_link', 'convert_URLs_cto');
add_filter('widget_text', 'convert_URLs_cto');
add_filter('wp_list_categories', 'convert_URLs_cto', 12000);
add_filter('category_feed_link', 'convert_URLs_cto');

wp_list_categories にフィルタを追加すると Category Order プラグインと衝突するので、 優先順位を下げて Category Order プラグインの後で実行されるようにしている。

また、 the_category, post_link, widget_text, category_feed_link 各フックは、 2つ以上の引数を持つが、 第1引数 (書き換え対象の HTML あるいは URL) のみ使用するので引数の数 (add_filter の第3引数) を省略している。

例えば、 HTML文法エラーを修正できない問題点を見つけたときや、 ブログのサイドバーにある 「livedoor Reader」 「RSS」 「livedoor Blog」などのバナーを非表示にしていたら、 ライブドアから警告メールが来て、 やむなくバナー表示を復活させたときなど。 なかでも、 昨年ブログ管理画面 (有料プラン) がリニューアルされたときは、 とても大きなフラストレーションを感じた。 ライブドアはよかれと思ってリニューアルしているのだろうが、 JavaScript を多用した新管理画面は、 私にとっては使いにくいことこのうえないし、 生ログ取得スクリプトも使えなくなった。

そして、 今年に入って 「ブログ共通ヘッダー」 (最上端に表示される livedoor Blogのロゴ, 所属カテゴリ, テキスト広告) が勝手に表示されるようになったのが最後の背中のひと押しとなった。 これを非表示にしたければ PRO プラン (月額 315円) ではなく ADVANCE プラン (月額 840円) に変更しろという趣旨 (要は値上げ) なのだと思うが、 何の連絡もなく画面の一番目立つ最上端に、 醜悪なヘッダー (ADVANCE プランへの移行を促すためにわざと醜悪にしている? *_*) を勝手に挿入するデリカシーの無さに驚き呆れ、 自前サーバへの引越を決めた。

ブラウザ画面最上端 ↑ の 「ブログ共通ヘッダー」 (所属カテゴリ 「IT > プログラミング 」 と 「受験にまつわるエピソードを教えてください」 という広告? 表示) は、 ライブドアのサーバが HTML 中に自動挿入する以下の JavaScript (settings/header.js) によって body 要素へ追加 (appendChild) されている。

(function () {
    var hd = document.createElement('div');
    var str = '';
    str += '<div id="header2" style="z-index:10001"><table cellspacing="0" class="blog-common-header" id="header">';
	...(中略)...
    hd.innerHTML = str;
    document.body.appendChild(hd);
	...(後略)...

ユーザがカスタマイズ可能な範囲の外であるため、 この JavaScript の実行そのものを止めることは無理っぽいが、 追加された子要素を削除する JavaScript を実行して消すことは可能。 例えば以下のようなコードを HTML ファイルのどこかに入れておけばよい。

<script type="text/javascript" src="http://www.gcd.org/sengoku/docs/livedoor.js"></script>

livedoor.js は、 body 要素の子要素 「header2」 を取り除く (removeChild) だけの JavaScript:

(function () {
    var element = document.getElementById("header2");
    element.removeChild(element.childNodes.item(0));
})();

正月早々 「ブログ共通ヘッダー」 が勝手に表示されるようになったことに気付き、 直ちにこの対策を行なって非表示にしたのだが、 以前バナーを非表示にしたときライブドアから警告メールが来たことを考えれば、 今回も警告メールが来るのは時間の問題だろうと、 引越を急いだ次第。

私はブログを書くときも HTML で書いていて、 あまり CMS 的な機能は必要としないので、 トラックバックとコメントを受付けるだけの簡単な Web アプリを書こうと思っていたのだが、 試しにインストールしてみた WordPress が思いの外シンプルな作りで、 ちょっといじっているうちに簡単にカスタマイズできてしまったので、 これを使うことにした。

livedoorブログでエクスポートしたデータを (Movable Type / TypePad のデータとして) WordPress でインポートしたら、 (pre 要素なのに) 行頭の空白文字が削除されてしまって往生したが、 大した量でもなかったので手作業で修正してしまった。 もう少し量が多かったら真面目に PHP コードを追ったのだが...

こんなに簡単にできるなら、 もっと早く WordPress へ移行すればよかった。 既存のテーマを見よう見まねでいじっただけなのだが、 以前のデザインをほとんどそのまま踏襲することができた (むしろ余計な div 要素を排除できたので、よりシンプルになった)。

livedoorブログと WordPress では URL (パーマリンク, permalink) の形式が異なる。 例えば、 あるエントリの URL は、 livedoorブログ (旧URL) と WordPress (新URL) で次のようになる:

一見して、 WordPress のパーマリンクの方が分かりやすい。 正確に言えば、 WordPress のパーマリンクの形式は任意に設定できて、 livedoorブログ (Movable Type ベース) の形式に合わせることも可能だが、 エントリID (上記の例だと 51168556 と 154) が異なるので形式を合わせること自体にはあまり意味はない。

livedoorブログを利用していた時の URL がそのまま使えるように、 旧URL を新URL へ変換する以下の PHP スクリプトを書いた (switch 文で URL ごとにずらずら case を並べただけ)。

<?php
$new = NULL;
if ($_SERVER['REQUEST_URI'] == "/") {
    $new = "/blog/";
} elseif ($_SERVER['REQUEST_URI'] == "/atom.xml") {
    $new = "/blog/feed/atom/";
} elseif ($_SERVER['REQUEST_URI'] == "/index.rdf") {
    $new = "/blog/feed/rdf/";
} elseif (preg_match('/^\/archives\/(20\d\d)-(\d\d)\.html$/',
		     $_SERVER['REQUEST_URI'], $matches)) {
    $year = $matches[1];
    $mon = $matches[2];
    $new = "/blog/$year/$mon/";
} elseif (preg_match('/^\/archives\/cat_(\d+)\.html$/',
		     $_SERVER['REQUEST_URI'], $matches)) {
    $id = $matches[1];
    $new = "/blog/category/";
    switch ($id) {
    case 50026701: $new .= "enlighten/";   break;
    case 50026704: $new .= "business/";    break;
    case 50026703: $new .= "engineer/";    break;
    case 50026699: $new .= "system/";      break;
    case 50035671: $new .= "hardware/";    break;
    case 50026700: $new .= "programming/"; break;
    case 50021362: $new .= "stone/";       break;
    case 50035209: $new .= "la-fonera/";   break;
    case 50041534: $new .= "hawaii/";      break;
    case 50045637: $new .= "hongkong/";    break;
    case 50026702: $new .= "others/";      break;
    default: $new = NULL;
    }
} elseif (preg_match('/^\/archives\/(\d+)\.html$/',
		     $_SERVER['REQUEST_URI'], $matches)) {
    $id = $matches[1];
    $new = "/blog/";
    switch ($id) {
    case 50071073: $new .= "2006/03/8/"; break;
	...(中略)...
    case 51168556: $new .= "2008/04/154/"; break;
	...(中略)...
    case 51552583: $new .= "2009/12/184/"; break;
    case 51555097: $new .= "2010/01/185/"; break;
    default: $new = NULL;
    }
}
if ($new) {
    $host = "www.gcd.org";
    $_SERVER['SERVER_NAME'] = $host;
    $_SERVER['REQUEST_URI'] = $new;
    $_SERVER['SCRIPT_NAME'] = $new;
    $_SERVER['PHP_SELF'] = $new;
    define('WP_USE_THEMES', true);
    require('/usr/local/www/wordpress/wp-blog-header.php');
} else {
    header("HTTP/1.1 301 Moved Permanently");
    header("Location: http://www.gcd.org/blog/");
    exit();
}
?>

http://blog.gcd.org/* にアクセスすると、 ↑ この PHP スクリプトが実行される。

これに加え、 逆方向の変換、 つまり新URL から旧URL への変換も必要。 例えば 「はてなブックマーク」 へ頂いたコメント (例えば前述したエントリに対するコメント一覧) は旧URL に紐づいているので、 各エントリに旧URL を登録しておく必要がある。 WordPress には カスタムフィールド という機能があって、ひとつのエントリに複数の 「キー」 と、 各キーにその値を登録することができる。 そこで沢山の 「ブックマーク」 を頂いたエントリには、 「hatena_b」 というキーで旧URL を登録しておくことにした。 すると、以下のような PHP スクリプトでブックマーク数 を表示できる。

<?php
  $hatena_b = get_post_meta($post->ID, "hatena_b", true);
  if ($hatena_b)
    echo ' <a href="http://b.hatena.ne.jp/entry/' . $hatena_b
       . '"><img style="border:0;" src="http://b.hatena.ne.jp/entry/image/'
       . $hatena_b . '" alt="" /></a>';
?>

最後に、 ネームサーバの設定変更を行なって、 blog.gcd.org レコード (TTL = 3時間) の値を 「CNAME blog-01.livedoor.jp」 から 「CNAME www.gcd.org」 へ変更した。 1/26 19:35 に変更を行なったところ、 19:46 には最初のアクセスが www.gcd.org へ届き、 20時台には大半のアクセスが www.gcd.org へ届くようになった。 20時台にライブドア側へ届いた blog.gcd.org へのアクセスはわずかに 7件、 その後は 1 時間〜数時間ごとに、ぱらぱらアクセスがあるという状況が続いている。 旧レコードを保持しているキャッシュネームサーバが残っていて、 そのネームサーバを使ってるブラウザからのアクセスのみが、 ライブドア側へ届いているといった感じ。

同日 20:20 追記:

そろそろ帰ろうかと思っていたら、 ひろせ31さんからチャットを頂いた:

(19:05:46) ひろせ: curl -I http://www.gcd.org/blog/ | grep X-Pingback
到達不可なヘッダついてますよー
(19:06:46) 仙石: ども、ご無沙汰してます。
(19:06:53) ひろせ: どもどもー
(19:08:21) 仙石: そっか、ヘッダに残ってましたか～
(19:08:34) 仙石: チェックするのを忘れていました。ありがとうございます
(19:08:40) ひろせ: いえいえー

確かにヘッダに 「X-Pingback:」 フィールドがついている。↓

% curl -I http://www.gcd.org/blog/
HTTP/1.1 200 OK
Date: Thu, 28 Jan 2010 10:08:54 GMT
Server: Apache
X-Pingback: http://gt.gcd.org/wordpress/xmlrpc.php
Content-Type: text/html; charset=UTF-8

Pingback って何だろう (^^;) と思いつつ、 「gt.gcd.org」 は GCD (私の個人サイト) 内部でのみ有効なホスト名 (IPアドレスは 192.168.1.1) なので、 このフィールドの目的が何であれ取り除いた方がいい。 実は、 HTTP レスポンス中にも 「gt.gcd.org」 は出力されていて、 ↓

<link rel="EditURI" type="application/rsd+xml" title="RSD" href="http://gt.gcd.org/wordpress/xmlrpc.php?rsd" />
<link rel="wlwmanifest" type="application/wlwmanifest+xml" href="http://gt.gcd.org/wordpress/wp-includes/wlwmanifest.xml" /> 

これは公開前に気付いて取り除いたのだが、 HTTP ヘッダの方はチェックするのを忘れていた。orz

上記二つの link 要素は、 それぞれ rsd_link と wlwmanifest_link というフィルタが出力しているので、 このフィルタを wp_head フックから取り除いてやればよい。 具体的には、 現在のテーマの functions.php ファイルに、 以下のようなコードを追加する:

remove_action('wp_head', 'rsd_link');
remove_action('wp_head', 'wlwmanifest_link');

ひろせ31さんから指摘を受けて、 条件反射的に WordPress の PHP コードを検索してみた:

% find /usr/local/www/wordpress -type f | xargs grep X-Pingback
/usr/local/www/wordpress/wp-includes/classes.php:	 * Sets the X-Pingback header, 404 status (if 404), Content-type. If showing
/usr/local/www/wordpress/wp-includes/classes.php:		$headers = array('X-Pingback' => get_bloginfo('pingback_url'));

classes.php の該当箇所を見てみると、

	function send_headers() {
		$headers = array('X-Pingback' => get_bloginfo('pingback_url'));
		...

ありゃ、ハードコードされてる...

前述した link 要素のように、 フィルタで出力するようになっていれば、 そのフィルタを無効化するだけで済むのに... (*_*)

さて、どうしたものか。 この send_headers() 関数は、 $headers 配列にフィールドを加えていって、 最後に $headers を HTTP ヘッダとして送信する、 という処理の流れのようだ。

さらに読み進めていくと、

		...
		$headers = apply_filters('wp_headers', $headers, $this);
		...

ありがたいことにフィルタ・フックが定義されていた。 この wp_headers フックに、 X-Pingback: フィールドを取り除くフィルタを登録すれば、 うまくいきそうだ。

(19:12:57) 仙石: X-Pingback はハードコードされてますねぇ... > WordPress
(19:13:12) ひろせ: うひー
(19:13:22) 仙石: フィルタで削除するしかないのかな... あるいは WordPress のコードを直接書き換えるか...
(19:13:22) ひろせ: gt.gcd.orgって、内部ホストなんですかね？
(19:13:26) 仙石: です
(19:13:43) 仙石: 管理用なので、外部からはアクセスできないようにしたいです
(19:16:46) ひろせ: Apacheで、 Header unset X-Pingback で消えるかもすね。
(19:17:58) 仙石: なるほど

現在のテーマの functions.php ファイルに、 以下の PHP コードを追加してみた:

function remove_X_Pingback($headers) {
	unset($headers['X-Pingback']);
	return $headers;
}
add_filter('wp_headers', 'remove_X_Pingback');

初めて書く WordPress のフィルタだったが (実をいうと PHP も書き慣れているわけではないので、 配列の要素を削除する方法もマニュアルを調べながら書いた ^^;)、 うまく動いているようだ:

% curl -I http://www.gcd.org/blog/
HTTP/1.1 200 OK
Date: Thu, 28 Jan 2010 10:29:33 GMT
Server: Apache
Content-Type: text/html; charset=UTF-8

めでたく、X-Pingback: フィールドが出力されなくなった。

(19:30:23) 仙石: 取り除きました。＞ X-Pingback:
(19:30:33) ひろせ: oo
(19:30:38) 仙石: functions.php に、
function remove_X_Pingback($headers) {
        unset($headers['X-Pingback']);
        return $headers;
}
add_filter('wp_headers', 'remove_X_Pingback');
(19:30:51) 仙石: を加えました。

ありがとうございました。＞ ひろせ31さん

香港 CSL の Power Prepaid SIM $88 を買った (HK$88 = 約1060円)。 この SIM カードを妻の携帯電話 Motorola ZN200 に入れて、 一週間の香港滞在中、 互いに連絡するときに大いに利用した。 が、通話料が一分間 HK$0.1 (約 1円) と安すぎるので、 HK$82.20 も残ってしまった (つまり HK$5.80 しか使ってない)。

有効期限は 2010年6月15日までの半年間。 期限内にチャージすればチャージした時点からさらに半年間有効。 SIM カードのパッケージの内側には、 海外 (香港でも 「於海外」 「Overseas」 って言うのか...) でのチャージ方法として A. 自動チャージ (香港での手続きが必要) B. バウチャー (香港で事前に購入が必要) C. PPS の三種類があると書いてある。

PPS (Payment by Phone Service ?) というと、 電話をかけて支払う方法だとばかり思っていたが、 インターネット経由でも可能であるようだ (「by Phone Service」 と言いながらインターネットでも可能とはこれ如何?)。 Top up Your Account ページで、 チャージ金額 (HK$50 ～ HK$300)、SIMカードの電話番号、クレジットカード番号 を入力することでチャージできそう。 したがって期限切れ直前にチャージすることにより次回 (たぶん年末に) 香港に行くときに使うこともできそうだが、 一年間使わずに寝かせておくよりはと思い、 Yahoo!オークションに出品してみた。

この SIM カードは日本でも、 3G 対応の携帯電話なら使用できる (Motorola ZN200 は GSM 専用機なので日本では使えない) ので、 HTC P3600 に入れて試しに少し使ってみた (正確に言うと、 課金される実験は HK$1000 Prepaid SIM を使用したので、 Power Prepaid SIM $88 の残度数は減らしていない。 どちらの SIM も機能的には同じ)。

まず、 着信は普通に可能。 日本から 「010-852-6714-XXXX」 (「010」 は日本において国際電話をかけるときの国際プレフィックス、 「852」 は香港の国番号、 「6714-XXXX」 は、この SIM カードに割り当てられた香港内での電話番号) にダイヤルすれば、 この SIM カードを入れた電話機が日本にあっても着信する (Roaming Service)。 ただし 30秒ごとに HK$25 かかる (国によって HK$8 ～ HK$25。 深圳とかなら HK$8)。

発信は、 中国以外だと直接発信ができないのでコールバックしてもらう方式。 つまり 「*108*」 に続けて相手先の電話番号を香港からかける形で押して、 最後に 「#」 を押した上で発信。 例えば東京都の固定電話 03-5771-1328 にかけるのであれば、 「*108*00181357711328#」 とダイヤル。

すると香港から電話がかかってくる (コールバック) ので、 出ると中国語で何やら言ったあと、 相手先 001 81 3 5771 1328 (001 は香港において国際電話をかけるときの国際プレフィックス、 81 は日本の国番号、 3 は東京の市外局番03) を呼び出してくれる。 相手先が出ればそのまま通話できる。 つまり日本国内宛に電話をかける場合も、 香港から日本への国際電話 2本使って通話することになる。 なお、 「*108*」 の代りに 「*108*1*」 にすると、 コールバックの時の発声を中国語のかわりに英語で言ってくれるらしい (試すとまた課金されてしまうので未確認)。

コールバックに応えた時点で、 相手先につながるか否かにかかわらず課金される。 相手先が出てくれなくても 30秒ごとに HK$25 も課金されてしまうので注意が必要。 試しに私の PHS に前述のダイヤル方法 (*108*00181705013YYYY#) でかけてみた。 すると 「通知不可能」 で PHS が鳴った。 ちょっと鳴らしてみただけなのだが、 通話時間 (コールバックに応えてから切断するまで) としては 19秒もかかり、 HK$6.5 もかかった (香港滞在一週間で使った度数より大きい! *_*)。 数秒鳴らすだけで、 香港内同士 (local call HK$0.1/min) なら 1時間分以上の通話に匹敵する課金なのだから恐れ入る。

というわけで通話の Roaming Service は高すぎて実用的ではない (国際ローミングなんてどこもそんなもの?) が、 日本にいながら香港の番号での着発信の確認をできる意味はあるかも (香港に行く前から電話番号を周囲に伝えておく場合など)。

一方 SMS (Short Message Service) は、 一通 HK$3 なので香港内同士 (一通 HK$0.8) に比べてさほど割高ではない (そもそも local で一通 10円というのが高いと思うけど)。 しかも、 受信側は香港内外問わず無料でメッセージを受け取ることができる。 日本ではあまり一般的ではない SMS だが、 日本以外だととても普及している。 SMS は通信キャリア・国を越えて利用できる共通基盤になっているのに、 日本の通信キャリアはいまだに事業者間接続でモメているようだ。 よく知られているように、 twitter の文字数制限が 140文字なのは、 SMS の制限が 140オクテットであることを踏襲している。

日本を除くほぼ全世界で共通のテキスト・メッセージサービスとして定着した。 現在の全世界のSMSの利用者は約24億人で、 世界中の携帯電話ユーザーの約74％がSMSを利用している。

「ショートメッセージサービス」から引用

まず SMS の着信を試してみる。 Skype で SMS を 「+852-6714-XXXX」 に送ってみる (€0.051 = 約8円かかった) と、 携帯電話が日本にあっても着信する。 日本語表示が可能な携帯電話 (HTC P3600) なので、 日本語を含むメッセージも問題なく表示できた。 念のため残度数が減ってないことを確認。

「*109#」 にダイヤルする (もちろん無料) と、 次のような残度数を知らせるメッセージが、 差出人 「179179」 から SMS で届くので残度数を確認できる。

6714XXXX with $82.20 stored-value. The expiry date is 15/Jun/2010.

次に SMS の発信を試してみる。 別の SIM カード (HK$1000 Prepaid SIM) を HTC P3600 に入れて、 HTC P3600 の標準アプリケーション 「メール」 を使って SMS を 「+8526714XXXX」 宛に送ってみた。 宛先欄に 「+」 記号を含めて入力することが重要。 残度数を調べると、 送信に HK$3 かかったことが確認できた。 続いて SIM カードを元の Power Prepaid SIM $88 (電話番号が 6714XXXX) に戻すと、 先ほど別 SIM カードで送った SMS が着信した (SIM カード入れ替えを行なったのは、 手元に 3G 対応携帯電話が一台しかないため)。