NTT DoCoMo が儲かっているらしい。 iモードの利用が増えたのが原因らしいのだが、 こちらは、最近やっとiモード対応の携帯電話を使い始めたところである。 日頃VAIOを持ち歩いている環境だと、 iモードでWebを見るというのはどうも抵抗があるしお金もない。 便利なのは、やはりメールで、着信したらすぐに分かるというのがよい。

※ 当時は定額で使い放題という料金プランは存在しなかった。 使えば使うだけ課金が発生する。

実はノートpcだと同じことができない。 当面のネックはバッテリーの持続時間である。 電源を入れたままだと5時間ほどしか持たないし、 電源を切ってしまうとメール着信の確認ができないのだ。 自宅でサーバが動いているのだから、定期的にサーバに対して着信チェックして、 メールが着信した時だけiモードに通知するように設定しておけばよいのだが、 いまいち危機感がないため実現していない。 単に回送すると、最近とんでもないサイズのメールを送って来る人もいるので、 たとえ最大サイズが決まっているとしても、いまいち面白くない。

塵も積もれば山となるというが、 DMというか、spamというか、勝手に送って来るメールが実にうっとおしかった。 逆にpcでメールを見る時には、特に追加料金はかからないから、 別に1MBのメールだろうが、ウィルスが入っていようが、あまり気にならないのだ。 iモードだと、メールを読む時にも料金を支払うことになる。 勝手にセールスのメールを一方的に送りつけられて、 しかもそれを見るのに金を取られるというのが納得できない。 NTT DoCoMo が大儲けするというのが分かる。 これではspamが増えれば増えるほどDoCoMoが儲かるシステムになっている。

※ その後、受信は無料にするとか、 ある程度までのメールは無料で使えるようにする、 というような策が登場した。

いや、DoCoMoが儲かるのがけしからんと言いたいのではない。 例えば、受信時の料金を無料にする代わりにメール送信の料金を倍にしてもいいか? そうしないと採算が取れないというのなら、別に構わないと思う。 普段メールをやりとりしている仲間なら、 トータルでは送信と受信が同じ位発生するから、 最終的な料金が増えることはないと思うのだ。 逆に、spamとかが来ても料金が発生しないだけ、支払い額は減りそうである。 割を食うのはspamを送る側だが、そんなの私の知ったこっちゃないし。

ところで、iモードにはメールアドレスの設定機能というのがある。 spamは電話番号を総当りで送りつけてくるという噂だ。 例えば、090-0000-0000 という携帯電話番号だったら、 09000000000@docomo.ne.jp だっけ、そういったアドレスになる。 つまり、数字の連番を発生するソフトがあったら、簡単にアドレスを生成できるのだ。 あとは適当に送ってみて、エラーで戻ってこなければ実在することが分かる。

これに対して、メールアドレスの設定機能というのは、 ユーザが好きな文字列を指定するのである。 例えば appare@docomo.ne.jp (もちろん、これは今使っているアドレスとは違うので、 試しにメールを送ってみたりしないように) のような感じになる。 数字だけではなく、 アルファベットを組み合わせたアドレスを自動生成するのは流石に無茶なので、 spamを送る側も困るようだ。 また、数字だけで十分な送信先が確保できれば、 そこまで自動生成するメリットも少ない。

という理由でもあるのか、 メールアドレスを指定してから、spamは一切来なくなった。 便利なものだ。 こんな機能があるのなら、使わない手はない…と思うかもしれないが、 実は使えない人もいるのである。 というか、このメールアドレスの設定方法が分からないらしいのだ。

分かるだろ? といわれても、実際、分からなかった人がいたのだから仕方ない。 一応、取り扱い説明書を見ようという努力はしたようだが、 見ても書いてなかったのか、見落としたのか。 実は説明書など見なくても、iモードを接続して「i Menu」という所からたどれば、 それらしきサービスが見つかるのだが、 それほど分かりやすい場所でもなさそうだし、 それに、「i Menu」を見ている人がどの程度いるのかが、今ひとつピンと来ない。 i Menu には新着サイトのPR情報なども出ているから、 「これは不要だ」と一度思ってしまったら二度と見ない人も結構いそうな気がする。

§

ちなみに、VAIOでメールが使えるようなモバイル環境があるのに、 わざわざiモードでどういうメールを送受しているのかというと、 電報みたいなものである。 例えば、新宿駅で待ち合わせる時。 駅に付いた時点で相手がいなければ「南口についた」 というメールを出す。 冗談ぬきで、本文はこの「南口についた」の6文字だけである。 いや、ひょっとしたらタイトルが「南口」で、本文は「着いた」だけかもしれない。 これだと何時に着いたのか分からなそうだが、 メールの送信時刻で分かる仕組みになっている。 こういうメールを待ち合わせとかで使うのだが、 文字数が少ないのは、何もパケット通信料金を節約しようというわけではなくて、 単に文章入力するのが面倒だからだ。 やっぱりキーボードで文章作った方が100倍楽である。

余談だが、最近、田舎の方でCATVを使ったネットワークへの移行を検討したことがあった。 これを使うためには毎月5000円のコストが発生する。 ヘビーに使うのであれば、この金額で下り30Mbpsというのは興味がある。 ただ、この時に使う人が、殆どメールしか使っていないことが分かっている。 現在モデム経由でダイヤルアップする環境だが、 課金明細を確認してみたら、毎月の支払いが1000円程度なのだ。 30Mbpsになっても、10秒かかっていたメール送信が一瞬になるだけでは、 殆ど意味がない。

では、メールだけならiモードでもいいような気がしますか? 携帯電話のあの小さいボタン、ある程度の年齢になると押すのが大変だし、 画面は小さくて読みにくいし、 少し年齢の高い人達には、携帯電話というのは、 そのような所が壁になっているらしい。

§

日時といえば、2000年問題というのが過去の笑い話になったかどうか、 微妙な問題かもしれないが、 一般的に、日付の処理というのは結構頭が痛いものだ。 結構ありがちな処理として、何年何月何日は何曜日、というものがある。 この件は定石があるので省略するとして、 もう一つよくある処理は、何月何日の何日後(前)は何月何日、というものだ。

プログラマーズフォーラムの公式サイトには、 なぜか時事をネタに好き勝手な評を書いている「今日の戯言」というコーナーがある。 例えば1月1日の場合、

※ 感触としてはかなり評判がよかったのだが、 フォーラムそのものが消滅してしまった。

http://www.nifty.ne.jp/forum/fprog/today/20010101p.htm

というURLで参照できる。 このコーナーをiモードでも読めるようにしようと思ったことがあったが、 ここだけの話、実は意欲がなくなって頓挫していたりする。

このように年月日を含んだ名前を使う場合に、 次の日はどうなるかを知りたいことがよくある。 "20010101" の次は "20010102" だから簡単だが、 問題は "20010131" の次とか、 "20010101" の一つ前を知りたい場合。 オーバーフローした場合の次の値がちょっと難しい。

この処理には perl を使っているのだが、 最初、List 1 のようなサブルーチンを自前で作っていた。 リファレンスを使ったcorrect というサブルーチンがどう見ても「?」という感じだし、 実際、1か月以上の間隔があったら、これではうまく動かないのである。 ただ、最初は日付処理といっても、次の日と前日を計算することしかなかったため、 これで十分だったのだ。 呼び出しは &add_date(20010101, 1) のようにする。

-- List 1 (日付の加算、その1) --

# 20000101 のような値から、先週の値を計算する。
sub add_date {
  my $date = shift;
  my $add = shift;

  my ($y, $m, $d);

  $y = int($date / 10000);
  $m = ($date / 100) % 100;
  $d = $date % 100;

  $d += $add;
  &correct_date(\$y, \$m, \$d);

  return $y * 10000 + $m * 100 + $d;
}

# 日付を補正する。日が範囲を超えていたら月、年で調整する。
sub correct_date {
  my ($y, $m, $d) = @_;
  my @maxday = (0, 31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31);

  $maxday[2] = 29 if ($$y % 4) == 0;

  if ($$d < 1) {
    $$m--;
    if ($$m < 1) {
      $$y--;
      $$m = 12;
    }
    $$d += $maxday[$$m];
    $$d++ if ($$y % 4) == 0;
  } elsif ($$d > $maxday[$$m]) {
    $$d -= $maxday[$$m];
    $$m++;
    if ($$m > 12) {
      $$m = 1;
      $$y++;
    }
  }
}

---- List 1 end ----

今みても結構笑えるというか、 なんとかしてくれみたいなソースだ。

ところが、使い込んでいると、要求仕様が徐々に変化していって、 ちょっと飛んだ日付も処理したくなってくる。 その時に、果たしてこのサブルーチンは2日以上の差があっても大丈夫なのか、 というので一瞬心配になった。 その時、コードを読み直して、多分これは1か月以内なら大丈夫だろう、 と考えてそのまま使っている。 ちゃんとコメントで条件を書いておくべきだったが、 面倒がってまだ書いてなかったりする。

しかし、ちょっと考えてみると、 こんな処理を自前で書く必要があるのか疑問に思えてくる。 日付を扱うような関数ライブラリが既にあるような気がするのだ。 そこで調べてみたわけだが、真面目に調べなかったため、見つからない。 ただし、localtimeの逆の関数はすぐに見つかった。 年月日、時分秒という情報を与えて、1970年1月1日からの秒数を返す関数である。 ということは、1日の秒数は86400秒なのだから(うるう秒は考えない)、 次の手順で処理すれば日数が離れていても問題ないはずだ。

(1) 現在の時刻を timelocal 関数を使って1970年1月1日からの秒数に変換する。
(2) 加減したい日数の86400倍を加減する。
(3) 得られた秒数を localtime 関数を使って日時情報に変換する。

実際に処理してみたのが List 2 である。 最初、use Time::timelocal とかやってしまってエラーが出たのが愛嬌。

-- List 2 (timelocal 版) --

use Time::Local;

sub add_date {
  my $date = shift;
  my $add = shift;

  my ($y, $m, $d, $time);

  $y = int($date / 10000);
  $m = ($date / 100) % 100;
  $d = $date % 100;

  $time = timelocal(0, 0, 0, $d, $m - 1, $y - 1900);
  $time += (60 * 60 * 24) * $add;
  ($d, $m, $y) = (localtime($time))[3..5];

  return ($y + 1900) * 10000 + ($m + 1) * 100 + $d;
}

-- List 2 end --