Web屋のネタ帳

アマゾンがいつのまにかコンビニ受け取り対応。なるほど、ローソンのロッピー端末を使うのか。

• Amazon.co.jp: ヘルプ > 配送 > コンビ二受取
• Amazon.co.jp: ヘルプ > 配送 > コンビ二受取 > 商品の受取方法

昼間不在がちな人にはすごく便利なはず。 コンビニ受け取りは事実上Yahooブックス＋セブンイレブンだけの目玉サービスだったのだが、 これで、あやうしYahooブックス。

少々アサヒってる気がしないでもないが釣られてみよう。

asahi.com（朝日新聞社）：「誰でも入れる」保険の真実（上） - 保険のカラクリ - 生命保険特集 - 健康(2008/7)

そもそも、この商品は「生命保険」ではありませんし、もちろん「医療保険」でもありません。ポイントは「病気での入院」に対して保険金が支払われるとは、一言も言っていないことです。 「治療や入院の実費を最高１００万円まで保障」とありますが、それは「ケガでの治療」に限られているのです。また、「お葬式の費用を保障」というのも、亡くなった場合に払われるのではなく、親族が負担する葬祭費用の「実費」を一定限度まで保障するというもの。

つまり、これは「損害保険」商品なのです。

なるほどなるほど。で、件のCMがその会社のWebサイト上で公開されているので見てみた。

ビジネスとはそんなものである。

なお、件の某社は某隠しリンク屋さんのクライアントでもある。

追記

Ｘ長期保障障害保険
○長期保障傷害保険
だってまじで字、小さいんだもん。(笑) ちなみに、商品詳細のどこを探しても、長期保障傷害保険の文字は出てこない。ぱっと見には。 がしかし、よーく見ると書いてある。

CoolなURLを作るには（ギークなお姉さんは好きですか 2008/7）

完全に甘く見ていた。「変数をごにょごにょすればできるっしょ＾＾」とタカをくくっていた。 ぜんぜん違う。そんな小手先の修正じゃダメだ。

うん。言葉が適当かわからないが、気づく、違うということに気づく、表面じゃない根本的な何かに気づく、のは重要なことだ。

URLと動的/静的なページとの関係と影響についてはこのブログでも何年か前に取り上げたことはあるが、より具体的な方法については書いたことがほとんどない。なぜならググれば他で出てくることだから。

がしかし、いつまでたってもmod_rewriteだのPATH_INFOだのの小手先テクニックの話が出てくるだけで、Webサイト自体の拡張性をも見据えた全体設計の中のひとつとしての「coolなURI」の作り方はどうあるべきなんだろう？という話は一向に出てこない。

俺それ知ってるぜ、なんておこがましい自信はまったく無いし答えはひとつじゃないはずだけど、全体から見てどうあるべきなのというところから考えたほうがあとあといいことあるよ、とは気づいてるつもりだ。

話がそれるけど、

ギークなお姉さんは好きですか ギークはベストなコードを目指すべし！

URLがモロパラメータ丸出しだけど
こんな風にできたらCoolだと思います。

http://geekdb.jp/geek.php?id=1
↓
http://geekdb.jp/geek/yusukebe

間違いない！ちょ、これ早急に実装せねば(｀･ω･´)

?も=もいくないよ！(2003/10)と叫んでも「ポカーン」とされていた時代の筆者と比べると、Coolだね！の一言で通じる今の世代がうらやましいぜ。

われながら相変わらず前置きが長い。まあいいや。

目標

http://geekdb.jp/geek.php?id=1
を
http://geekdb.jp/x/geek/foo
にする。（fooは1でもかまわない）

「x」がポイントだ。いや、確かに邪魔かもしれないが、シンプルさと作りやすさとわかりやすさとセキュリティを与える意味で実は重要な妥協である。

apacheの設定をちょっといじる

    AllowEncodedSlashes On
    <FilesMatch "^x$" >
        ForceType application/x-httpd-php
    </FilesMatch>

mod_rewriteは使わない。mod_rewriteが100%悪だとは言わないが、あれはやはり麻薬だ。 便利だと思って使いすぎて、rewrite設定が数十、数百ステップにおよんでしまってもはやそれは設定ファイルなのかソースコードなのか区別がつかず、もう誰もメンテできない、なんていう話はザラにある。

なお、AllowEncodedSlashes は無くても動くが、スラッシュなどの記号がURLエンコード(%2F)されてGETパラメータに入るときに必要となる。

ファイル「x」をつくる

ファイル名はx.phpではなく、x。 yでもzでもいいけど、お好みで。短いほうがいいでしょ？

<?php
$args = explode("/",$_SERVER["REQUEST_URI"]);
switch ($args[2]) {
    case "geek":
        include("DocumentRootじゃないどこか/geek.php");
    case "book":
        include("DocumentRootじゃないどこか/book.php");
    default:
	header("Not Found", TRUE, 404);
        echo "ねーよ";
        exit(0);
}
?>

なお、ファイルxには

<?php include("DocRootじゃないどこか/x.php"); ?>

とだけ書いて、x.phpのほうにさっきの内容を書く、というのでもいいかもしれない。 拡張子なしのファイルは何かと扱いにくいしね。

以上で、
http://geekdb.jp/x/geek/foo
へのアクセスは、
$args[3] に"foo"が入る。あとは好きに料理できる。

ついでに言うと、
http://geekdb.jp/x/geek/foo/bar/a/b/?c=3&d=4
へのアクセスは、
$args[1] は"x"
$args[2] は"geek"
$args[3] は"foo"
$args[4] は"bar"
$args[5] は"a"
$args[6] は"b"
$_GET["c"]は"3"
$_GET["d"]は"4"
になる。

ポイントは３つ。

1. 設定ファイルは1行でも短いほうがいい。（ここではapacheの）
2. DocumentRootに余計なものを置かないほうがいい。
3. どうせならMVCを根本から実践してみるのもいい。

1. (apacheの)設定ファイルは短いほうがいい

これは人によってポリシー違ってくるとは思うけど、少なくとも筆者は、 設定ファイルに長ったらしく妙なロジックを詰め込むのは極力避けたほうがいいと考えている。 apacheの設定に限らず、どんなソフトウェアどんなアーキテクチャであれ、 ロジックを詰め込むのはphpなりjavaなりperlなりそのサイトが基準とする言語のソースコード上だけでたくさんだし、バージョン管理/ビルド管理の対象ジャンルをいたずらに増やさないほうがあとあと管理が楽だし。 （JavaのDIコンテナと設定ファイルの関係はあれはあれで話が複雑になるので別んとこでやってくれ）

その意味で、夢も設定も無駄に膨らみがちなmod_rewriteの多用はあえて避けている。また、特殊なことをする対象を「x」ひとつに絞っている。geek.php をgeekに、book.phpをbookに、、、と考え出すと考えた数だけ設定が増えちゃう。

2. DocumentRootに余計なものを置かないほうがいい

この方法だと、極端な話DocumentRootに置くべきものはxだけである。 あとは画像と*.cssと*.jsくらいか。 Webサイトが膨らんでくると、古くてもう使わなくなったクラスファイルとかjsp/phpとかが出てきて、そしてほったらかしになるものだが、上記の方法だとxの内容さえちゃんとメンテしていれば、古いスクリプトが残っていてもセキュリティリスクは小さくなる。

3. どうせならMVCを根本から実践してみるのもいい

察しのよい人は冒頭のURLとソースの例を見ただけでお気づきだろうが、 「x」はMVCの概念(Model, View, Controler)で言うところのCだと考えることもできる。 CoolなURLを作ろうと思うとCoolな概念に出会う。 答えはひとつだけなわけじゃないけれど、でも結局Coolの目指すところ行き着く先は、同じだ。

see also:

• 動的ページと静的ページ(1) 一般論 (2004/10)
• URLを変えるな！(1) － 後悔しないためのWebデザイン (2006/10)
• 良いURLについて考える - builder by ZDNet Japan (2008/1)
• 画像もDBに格納して管理する話とCoolなURLの作り方の話をまとめて補足。 (2008/7)
• CoolなURLを作るときのHotな落とし穴 (2008/8)

数週間前のiphone発売予定が発表されたときに、

iPhoneって端末シリアル番号は出力されるの？ (2008/6)

っていう素直な疑問をちょろっと記事にしてみたら、「でるわけねーだろタコ」的な小反応をいくつかいただき、いやですから状況はそんなに単純じゃないんですよという話を書こうかと思ったけど5秒で挫折した。 なぜなら、携帯電話端末の契約者識別符号の必要性や問題点について誤解の無いようにかつわかりやすく説明すると、こうなるから↓

高木浩光＠自宅の日記 - 日本のインターネットが終了する日 (2008-07-10)

その手の話のプロだからこの程度の長さの説明で済むのであって、俺程度の文章力と調査能力と洞察力と解析能力ではまず無理ですはい。

ちなみに、スマートフォンにそんな機能あるわけないという指摘は見事に崩れている。そりゃそうだ。無線通信キャリアがあってのスマートフォンなんだから。

3月28日から、イー・モバイルが音声通話サービスを開始したのだが、それと同時に「EMnet」というサービスが開始された。ケータイWatchの記事では、「携帯向けインターネットサービス」、「iモードやEZweb、Yahoo!ケータイにあたるもの」と形容されている。このEMnetを契約して（接続先をEMnetに設定して）いると、Windows MobileのInternet Explorerでアクセスした際に、全てのWebサイトに対して、契約者固有IDをHTTPのリクエストに独自ヘッダ「x-em-uid」として送信するようになっていたのである。
このことは、イー・モバイルの技術情報のページに書かれているし、実際に、EMONSTERを買って試してみたところ、送信されていることを確認できた。

で、ソフトバンク+iphoneには上のイーモバイル+EMONSTERみたいな機能はあるの？ないの？教えて買えた人！

See also:

• iPhoneと携帯契約者固有IDと複アカと青少年ネット規制によるケータイ闇ナベ狂想曲 (2008/7)
• iPhoneと契約者固有IDにからむ希望的観測などはこれっぽちも感じておりませんので。 (2008/7)

去年の今頃書いた 画像もDBに格納して管理する －扱いがめんどうなLOB(ラージオブジェクト)は使わない方法も含め(2008/8)と、こないだのCoolなURLを作るには(2008/7)の記事は、URLの処理をちょこっと工夫してシアワセになろうよ、という点で共通している。ついでなのでまとめて続編みたいなことをしてみようかと。

まず、画像もDBに格納して管理するで紹介したmod_rewrite設定が実はおかしいという、約1年後のいま明かされる真実(笑)。

と言っても本格的に間違ってるわけじゃなく結果的な動作に問題は無い。ただちょっと余計なものがある。

RewriteCond %{REQUEST_FILENAME} ^dbimage_\d+\.(jpg|gif|png)$
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^.*dbimage_(\d+)\.(jpg|gif|png)$ /getimgfromdb_and_makefile.php?id=$1&type=$2 [R]

一番最後の[R]はいらない（と思う。めんどいので未検証）。 RはつまりRedirectのことで、指定したURIにHTTPリクエストしなおせ！とブラウザに伝えてくれるのだが、よく考えるとそんなことをせんでもここまででリライト処理はできている。あとはほっといてもサーバはブラウザに /getimgfromdb_and_makefile.php?id=$1&type=$2 の結果を返してくれるので目的は達成される。

しいて言えば[R]の代わりに[L]と書くべき。これはlastの意味で、そこでリライト処理を終了してくれる（その後にrewrite設定が続いていても無視）。

次に、現場の状況によっては逆のパターンのほうがいいかもしれないという話。

RewriteCond %{REQUEST_FILENAME}    /getimgfromdb_and_makefile.jsp
RewriteCond %{QUERY_STRING}    id=([0-9a-z]+)&type=(jpg|gif|png)
RewriteCond /home/htdocs/imagecache/dbimage_%1.%2    -f
RewriteRule .*    /imagecache/dbimage_%1.%2 [L]

# 注：画像のキャッシュファイルはDocumentRoot配下ではなく /var/tmp/ 配下とか
# とにかく別なところに置いてAliasを張ったほうが管理しやすいと思う。
# そんな事情もあるので、本ブログで書いているapacheの設定は
# 本来はvirtualHostやAlias設定なども使ってもうちょっと本格的な設定に
# すべきだが、安価な共用型レンタルサーバでも使えるように 
# .htaccessファイル上で設定できる（そうな）書き方をしている。
# 要するにこれらはあくまで最低限の設定例に過ぎないです。

つまり、
http://example.com/getimgfromdb_and_makefile.jsp?id=abcd1234&type=jpg
を
http://example.com/imagecache/dbimage_abcd1234.jpg
にリライトする方法。ただしDB上の画像が既にキャッシュファイル化されいてdbimage_abcd1234.jpgとしてファイルが存在するときに、という条件つき。

Web層とAP層が明確に分かれている場合にはこっちのほうがいいんじゃないだろうか。典型的なのはWebサーバがApacheでAPサーバがTomcatというケース。

Tomcat上でjavaアプリを動かす場合、開発者は自分のPC上にTomcatサーバだけをを立てて開発をしていることがある。apacheを経由してないのでmod_rewriteが効かないため、<img src="dbimage_12345.jpg" /> と書いてあっても画像が出ない。上の方法だと<img src="getimgfromdb_and_makefile.jsp?id=12345&type=jpg" /> という一つの書き方で、本番環境のApache+Tomcatならばmod_rewriteによるキャッシュ機構が働くし、開発過程でのTomcatオンリーな環境であっても画像は（キャッシュ機構は動かないけど）表示される。 また、画像キャッシュ機構のオン／オフを切り替える機能の実装もやりやすくなるだろう。

話は変わって今度はCoolなURLの作り方の件。

geekデータベースアプリが http://example.com/x/geek/　、bookデータベースアプリが http://examle.com/x/book だとして、そのサイトのトップページを同じMVCフレームワークで動的にやりたいとすると、トップページのurlは http://example.com/x/ とか http://example.com/x/index とかになっちゃうの！？かっこ悪くね？ という意見をいただいた。

そのとおりだ。Webサイトのトップページは http://example.com/ だけのほうがCoolだ。そこで、こうする。

DirectoryIndex  x 
# DirectoryIndex  x  index.html  index.php 
# のようにしてもよい。詳しくは マニュアル。

これで、

トップページ	http://example.com/
geekアプリ	http://example.com/x/geek/foo/bar....
bookアプリ	http://example.com/x/book/foo/bar....

ということになる。このときのxの中は例えばこんな感じ↓

<?php
if ($_SERVER["SCRIPT_URL"] === "/") {
    include("DocumentRootじゃないどこか/toppage.php");
} else {
    $args = explode("/",$_SERVER["REQUEST_URI"]);
    switch ($args[2]) {
        case "geek":
            include("DocumentRootじゃないどこか/geek.php");
            break;
        case "book":
            include("DocumentRootじゃないどこか/book.php");
            break;
        default:
	    header("Not Found", TRUE, 404);
            echo "ねーよ";
            exit(0);
    }
}
?>

しかし、「やっぱりxは邪魔だ！Coolじゃない！」と感じる人もいるだろう。 それはそれで一つのポリシーであるので、

<FilesMatch "^(geek|book)$" >
    ForceType application/x-httpd-php
</FilesMatch>

のようにすることで、 http://example.com/geek/foo/bar , http://example.com/book/foo/bar のように余計な「x」を排除する方法を取ってもよいと思う。 ただしgeekとbookのほかにblogとsnsとbbsとrssreaderと、、、、を追加するたびに

<FilesMatch "^(geek|book|blog|sns|bbs|rssreader)$" >
    ForceType application/x-httpd-php
</FilesMatch>

というふうになってゆく。CoolなURLを追求しすぎて設定ファイルがCoolじゃなくなっている。 が、この程度は人それぞれの感じ方の問題だろう。結局はapacheの設定ファイルに書くか「x」の中に書くかの違いでしかないのだから。

ところで、mod_rewriteによる画像キャッシュ機構と、CoolなURL作りと、コントローラースクリプト「x」によるMVCフレームワーク（っぽいもの）の話とを、全部まとめてやってやろうとすると、こうなる。

DirectoryIndex  x index.html index.php
<FilesMatch "^x$" >
    ForceType application/x-httpd-php
</FilesMatch>
RewriteCond %{REQUEST_URI}    /x/getimgfromdb_and_makefile
RewriteCond %{QUERY_STRING}    id=([0-9a-z]+)&type=(jpg|gif|png)
RewriteCond /home/htdocs/imagecache/dbimage_%1.%2    -f
RewriteRule .*    /imagecache/dbimage_%1.%2 [L]

たった8行だが、これでもはじめての人にとってはチンプンカンプンだろう。 プログラミング言語の使い方を覚えるだけでも大変なのにね。

筆者は、ソフトウェアの設定ファイルを書くのもプログラミング言語でソースコードを書くのも同じ「開発」と捉えている。だったら少しでも単一の言語体系に寄せて、かつ、メインじゃない言語体系のもの＝設定ファイル＝を書き増す可能性を少しでも小さくするほうがcoolだと思う。だから「x」で妥協するプランのほうを示した。いろんな言語や出来合いのソフトウェアを使って遊ぼう|学ぼうというのなら話はまたちょっと違うけど。

また、mod_rewriteは麻薬だ。などと言うわりに実は1年も前にmod_rewriteを使った話を書いていて、それがこのブログでのソーシャルブックマーク数の一番多い記事（こことかこことか参照）だったりする。うん。ハサミと麻薬は使いよう。（笑）

see also:

• CoolなURLを作るときのHotな落とし穴 (2008/8)

IT業界来し方行く末 > 安易なシンクライアント化を絶対に阻止する : ITmedia オルタナティブ・ブログ

一理いや0.5理くらいあるかもと思って読んだがよくわからんかったし、そもそもポジショントークすぎるので、却下。

きわどい話をするときはもうちょっと根拠をはっきりさせましょう（え？俺のこと？気にしない方向で）。

• セキュリティを意識してシンクライアント化するメリットとデメリットが具体的にどうなのか、とか、
• 本当にセキュリティ「だけ」を意識して推進されているのか、とか、
• どういう責任があるはずなのにそれがどういうふうに回避あるいは転嫁されるのか、とか。

そういう話をしないままに、

社長さん、ご自分の会社は大丈夫ですか。社内のIT部門が、責任回避のためにシンクライアントを推進しているという本質に気付かないと、会社の将来を危うくしますよ。

などと口走るのは、全国3000万（うそ）のIT部門の人間に対してものすごく失礼であることに気づいてるんだろうかこのおっさん。 商売敵のシンクライアントメーカー（SunとかNECとか日立とか）をこき下ろすんならともかく、自分の商売のクライアントとなりうる人々を責任逃れ野郎呼ばわりしたところで誰一人幸せになれないことくらいは、いい年こいた社会人ならすぐわかりそうなもんだが。

あ、しゃべってる相手はIT部門じゃなくて社長なのかそうかなるほど。それにしちゃ書く場所間違ってる気がするけど。せめて自分の個人的ブログだけにしといたほうが（以下略）

ライターに原稿料を払う余裕の無いメディアサイトが「読者ブログ」に頼るという台所事情はCNETもITMediaも同じなんだよね。そういう形でタダでものを書く人ってのは、本当にピンキリ。 けんじろう と コラボろう！ : ITmedia オルタナティブ・ブログの人はなかなか面白い。 一方でCNET読者ブログにはこんなやつもいたねそういえば。→CNET「読者ブログ」上でSEO業者が検索エンジンスパムな記事を何本も書いている件(2007/12)

話をシンクライアントに戻そう。 去年、家庭にはPCの代わりにThinClient（シンクライアント）を(2007/4)という記事を書いた。 あれは企業ユースではなく消費者ユースを想定した記事だったのだが、 「家庭」という単語を「企業」に脳内変換しながら読んでもそれほどおかしくもないことに気づいていただければ幸いである。

インターネットはクライアント＝サーバ型じゃない - 池田信夫 blog

クライアント・サーバー（以下C-S）システムは「LANとはまるで異なる」ものではなく、ほとんどすべてのLANはイーサネットというC-Sシステムである。

意味がわからん。

どっちかいうと技術的な話題ではなく政治的な話題の色合いが強い、「ITを使えない日本は、ソ連のように崩壊する──野口悠紀雄が語る ascii.jp 2008/7」という対談記事に対して、変に技術的に厳密なツッコミをいれてしかもそれが微妙にズレているあたりのグチャグチャ感に夏を感じます。もう麦茶ないのかよ。

情報システム分野でよく用いられる「レイヤー（層）」という概念をご存知ないわけじゃないと思われるので、そのへんもうちょっと整理したうえで語らないと、とどのつまり「なんで対談に俺を混ぜねえんだ」的なことを言ってるようにしか見えない気がするのは俺がひねくれてるせいですよね気にしないでね。

昨日からおっさんの微妙な主張にツッコミ入れるパターンが続いておりますが単なる偶然です。いや暑いですからねほんと。

イントロはmixiだったのかもしれない。

1. 2007年3月、「mixiの新規登録時に携帯メールアドレスが必須になる」というInternet Watchの記事いわく、「1人で複数のアカウントが登録されるのを防ぐ措置とみられ、（以下略）」
2. 「携帯のメールアドレスを一時的に変えればまたmixi登録できるよなあ？1日3回までなら変更できる（ドコモの場合）し、そんなので複アカ対策になるの？」 と勘違いをするユーザー。
3. mixiに再入会しようとしたら携帯電話の端末番号が使用済みと表示される。何それ？ :教えて君.net というところまで行って初めて状況の詳細を知るユーザー。
4. 実はmixiよりもずいぶん先に携帯端末を認証に積極活用していた携帯サイト。特に掲示板等のコミュニティサービス系。目的はやはり複アカ荒らし君対策。
5. 一方、「パソコンなんて持ってないわケータイだけで十分だしー。」というごく一般的な女性をターゲットにしているためPC用サイトの構築なんてハナから眼中になく携帯サイトオンリーでやってる中小企業＝お料理教室の予約サイト、ヨガスタジオの予約サイト、美容室、ショートエステの予約サイトetcetc＝においては、IDとパスワードの入力の手間を省く＝俗に「簡単ログイン」と呼ばれる機能＝が、携帯端末認証の当初目的だった。
6. が、端末情報と会員情報と紐付けしてしまえば、上のコミュニティ系サービスと同様に複アカ荒らし君対策＝ここでは予約したくせに現れないドタキャンDQN（ホテル業界用語ではノーショウという）や、ライバル同業他社によるノーショウ攻撃（古典的業務妨害メソッド）＝から身を守るための、低コストかつかなり有効な手段になってたりする。なにしろCookieしか使えないPCサイト自体を初めから作ってないし。
7. 2007年10月、Googleアドセンスにモバイル版始まる。ただしソフトバンクとauだけで、ドコモ端末では広告が表示されない状態。 2008年1月、NTTドコモがグーグルと提携--検索や広告、YouTubeなど全サービスで協力を開始。 2008年3月、ドコモの契約固有ID送信機能「iモードID」が提供開始。 2008年5月、アドセンス広告がドコモ端末でも表示されるようになる。
8. 上の一連の流れは、「ソフトバンクとauではサブスクライバID(EZ番号)やら端末シリアル番号やらの自動送出機能があったのでアドセンス広告の不正クリック被害に対する対策をしやすかったのに対し、ドコモでは「携帯電話／FOMAカード(UIM)の製造番号を送信します YES/NO」のダイアログが必ず出てしまう仕様＝広告リンク向きとは言えない＝だったためにGoogleもアドセンスの配信を控えていたのが、1月の業務提携後にただちに仕様追加してutnとはまったく別に「iモードID」をリリース＆それを待ち構えていたGoogleアドセンスもただちにドコモ対応した」と考えると合点がいく件。（でも実はドコモ側の事情はそれだけじゃないことがあとで表面化。後述。）
9. 筆者のどうでもいい感想→「端末識別番号」「端末製造番号」「契約識別符号」「個体識別番号」「固有ID」「FOMAカード製造番号」「iモードID」「サブスクライバID」「端末シリアル番号」、、、頼むからまず最初に用語を統一してくれよ。それに契約者単位なのか端末1台単位なのかすらまちまちでよくわからんし。
10. 一方で、学校裏サイト（筆者的にはただのBBSじゃんくだらん）という絶妙なネーミングにネタ感を嗅ぎ取ったマスコミ（主に毎日新聞）とみのもんたによる煽り。ネーミングに気取られて無駄に不安視する親。正面切ってゴルァするマッチョ父。
11. 不思議なことに「Webサイトのフィルタリングを強制すればＯＫっしょ！？」という斜め上の展開。なんでそうなるの。 点数を稼ぐチャンスとばかりに無茶を言う無知なヒステリック国会議員。性急すぎるフィルタリング導入の結果見れなくなるサイトが続出。あおりを食ったモバゲータウン激怒。 アホちゃうか観点が違うだろとつっこむ冷静な識者。
12. 2007年暮れ頃から導入したばかりの携帯キャリアのURLフィルタリングが8月にはホワイトリスト方式からブラックリストへ切り替え（ドコモ）。ブラックだろうとホワイトだろうとイエローだろうと「短期間で無限に増減を繰り返すモノをリスト化する」というアプローチ自体にそもそも無理があるわけで、予想通りの場当たり対応。以降泥沼化の予定。 顛末は「青少年ネット規制」で検索。
13. 悪質サイトのフィルタリングはブラックリスト方式かホワイトリスト方式か？みたいにアサッテの方向に議論が展開している間に、実は、あるお役人が「認証基盤のオープン化」の名の下に「とりあえずユーザー毎に固有のIDを振って、サイト側がいつでもアクセスできるようにすりゃ、おかしな変態とかそういうユーザーを締め出しやすくなるんじゃね？」的な活動を展開→通信の課金・認証機能をオープン化すべきか――デジタルコアが勉強会 インターネット-最新ニュース:IT-PLUS（2007/11）。同時期にGoogleアドセンスとドコモのカラミの件もひっそり進行（先述どおり）。
14. このへんで高木氏＠産総研が察知。

    高木浩光＠自宅の日記 - 日本のインターネットが終了する日(2008/7)

    「なるほどそういうことか。」と理解した。つまり、悪質なユーザを締め出すために、契約者固有IDの勝手サイトへの送信を必要としているわけだ。 このことは、（2008年）5月28日の日経デジタルコアの討論会「民間主導によるネット有害情報への取り組み」を聴講して明確になった。

15. そう。「悪質サイト」ではなく「悪質ユーザー」にフォーカスをあてようかということらしい（筆者的解釈）。やや極端な例になってしまうが、2007年11月のモバゲータウン経由で知り合った同士の殺人事件のケースでは、悪質サイトがどうのというアプローチをとってもしょーがない。だって、モバゲーが悪質サイトかぁ？。しかし、悪質「ユーザー」にどう対処しようかという方向にゆくのは一理ある。
16. なお、 携帯電話事業者よ、認証基盤をオープンに--有識者が訴え:モバイルチャンネル - CNET Japan(2008/7)といった話題について、 ここでいう「認証基盤」って具体的になんなの？ねえなんなの？というツッコミを誰もしてないという違和感。
17. 2008年7月。ここへきてiPhoneが豪快に殴りこみ。もちろん空気読む気なぞさらさら無し。携帯契約固有ID？端末シリアル番号？はぁ？日本の事情なんか知るか。っていうかお元気ですかそこのガラパゴス諸島のみなさん。俺様はアップルだ、いいからそこに行列しろと。
18. そもそも、

    携帯ビジネス破壊？　アイフォーン情報統制戦略 (MSN産経ニュース2008/6)

    アイフォーンにはソフトバンクのロゴマークは記されない。あくまでアップルブランドの製品との位置づけだ。インターネット上では、アップルのサイトにだけ端末の詳細情報を紹介。ソフトバンクは自社サイトでの掲載を制限された。
    　今回、端末代金が実質２万３０４０円と安価に抑えられたのは、ソフトバンクがその２倍に当たる１台当たり４万６０８０円もの「販売補助金」を負担するからだ。補助金は、アップルが決めた価格（１９９ドル）に合わせるため、アイフォーンを販売する各国の通信事業者が負担する。ソフトバンクは価格の決定権を失うと同時に、利益を圧迫された格好だ。

    というむちゃくちゃな超不平等条約であっても飛びついちゃった孫正義。 こんなんじゃ日本の事情に合わせたローカライズなんて一切やってないだろうなあ。 注：筆者はローカライズするべきだ！とも、するべきでない！とも言ってませんので勘違いしないように。
19. とりあえず「で、iPhoneって契約者固有IDは出力されるの？」と軽くポーリングしてみる筆者。案の定、何も出力されてなさげ。
20. 招かれざるユーザーを締め出しやすくしたいという目的はそう悪くはないんだが、ユーザーの意図に関係なくそのユニーク値を固定でバラまくという手段（設計思想）が粗雑すぎる。しかしもはや止められない段階にきているので、これはもうだめかもわからんね。とサジを投げた高木氏。→高木浩光＠自宅の日記 - 日本のインターネットが終了する日(2008/7)
21. どこか遠いところに行ってしまった江島氏。→ iPhoneという奇跡:江島健太郎 / Kenn's Clairvoyance - CNET Japan
22. ところで、iPhoneのメールアドレスであるところの****@i.softbank.jp って、mixiの招待メールが送られるとどうなるの？
    (A)[mixi] ヘルプ＞「製造番号が取得できませんでした」と表示されるの状態になってにっちもさっちもいかなくなる。
    (B)普通にmixi会員登録できてしまう。
    もし(B)だとすると、メールアドレス変更しながら複アカ作り放題というもとのもくあみに。。。 （教えてiPhone持ってる人！）
23. 同様に携帯端末番号による複アカ防止策を取っていた他のWebサイトや、携帯アフィリエイトサービス会社の中の人は、iPhoneのユーザーに対してはどういう策を取るのだろう？
24. 200X年X月。携帯でアダルトサイトうっかり覗いたら「見ましたね。利用料5万8000円いただきます。あなたの個体識別番号はxxxxxxですね（←注：従来はこの部分はブラフに過ぎなかった）。自動的に通信会社に照会されました（←これはブラフ。実際はECサイト等からの情報流出）のでご住所ご氏名は次のとおり判明しておりますよxx市xx町1-2-3の山田太郎さん。3日間以内に料金が振り込まれない場合には（以下略）」みたいなことになった！という相談が消費者センターで多発。高木氏の懸念が現実のものに。 という話はフィクションです。
25. 被害を受けた山田さんの証言：「個体識別番号なんて聞いてないっすよ。携帯をいったん解約しないと変更できないなんてもっと聞いてないっすよ（涙）」
    野次馬Ａの証言：「個体識別番号なんて出さないiPhone使ってるオレ勝ち組。」
    野次馬Ｂの証言：「iPhone（またはWindowsMobile）をハックしてUser-Agentや個体識別番号を自在に偽装しているオレ最強。（真偽不明）」
    通信キャリアの中の人の証言：「．．．．．（黙秘）」
    お役人の証言：「当時の係官は異動しました。議事録は残っておりません。」
    という話はあくまでもフィクションです。

この壮大なバーチャル闇ナベのごときぐちゃぐちゃな設定と展開を大団円まで持ち込めるのは宮藤官九郎か三谷幸喜ぐらいだろう。面白かったよザ マジックアワー。

ここから追記：

× 固体識別番号
○ 個体識別番号
文中の一部を修正しました。

See also:

• iPhoneと契約者固有IDにからむ希望的観測などはこれっぽちも感じておりませんので。 2008/7

タイトルはつまらん釣りなので忘れてください。 そろそろネタとしては終わった感がありまくりの話ですが気にせずGO。

まず、ここぞという一番肝心なタイミングでちょっとのガマンができないがゆえに二度同じミスをするってのは社会人としてどうかねという至極まっとうな総論にまとまる女性の件。しかし、オトナ同士が飲み屋で意気投合してホテルへGOってのがそんなに悪いのかと。自分がスキャンダルやってると政治家の女性スキャンダルとかも追及しにくくなるからしょーがないと言う話もあるにはあるにせよ。

うら＠らむ　村山らむねの裏ブログ: 山本モナを見習え

大人の女性でしょ？誰と遊んだっていいじゃん。彼女に対して怒り攻撃できるのは、二岡の奥さんだけ。あとは、黙って見守ればいいと思う。なんで、みんなでよってたかって、自覚がないとかいうんだろう。

恋愛する女性をもっと褒め称えよ。メスであることを激賞せよ。 仕事も恋も、止まらない。そんな山本モナに万歳である。10年後にはこの事件も伝説になるだろう。そうなってほしいものである。iPhoneなんかに並ぶよりもずっと素敵な夜の使い道を、少なくとも彼女は知っているのだから。

うん。俺もそう思う。「俺も二丁目のバーに行ってみようかな」と一瞬でも思った奴は手を挙げろ。(笑) ただし遭遇するのはモナじゃなくてこんな感じだけどな。

次。霞ヶ関のお役人がタクシーチケット使いすぎ＆タクシーも公務員相手にサービスしすぎ、の件。

筆者は公務員ではないが、霞ヶ関や虎ノ門近辺で深夜まで仕事するはめになってタクシー帰宅しまくりだったことがある。そりゃもう、お役所の周りを空車タクシーがずらーっとトグロ巻いてた。

そのうちの1台（提灯のついた個人タクシー）に筆者が乗り込んだら、運ちゃんがあからさまにいやな顔をしたのは見逃さなかった。そのときスーツじゃなくてジーパンにポロシャツだったから、近所のホテルに行くだけの観光客か何かと思われたのかもしれない。行き先に郊外を指定すると、ホッとした声で「そこの肘掛の下に冷たいビールとウーロン茶と柿の種があるんでお好きなのをどうぞー」と。

さらに助手席の背中あたりのフタがあいて足置きが出現。どうぞ足伸ばしてくださいと。なるほどこれは快適。ワンセグテレビもついていて、ニュースなど眺めながらウトウトしてみたり。降りるときには「高速代はサービスしときますよ」「次回も同じ条件でいいですよ」「これ、名刺。携帯で呼んでください」みたいな感じ。

＜タクシー接待＞石原都知事「おれなら飲んじゃう」（毎日新聞） - Yahoo!ニュース(2008/7)

石原知事は「キックバックみたいに金銭をもらったら問題だろう。いいとは言わない」と断ったうえで「料金をまけてもらうわけじゃなく、相手のサービス、心遣い。運転手さんが深夜『ご苦労さんです。またよろしくお願いします』って缶ビール１本を出したら『ありがとう』って飲むのが人情だよな」と語った。

うん。まあ、そうだよな。居酒屋タクシー問題の面白いところは、

• 酒や金券はまずいだろ。現金のキックバックはもっとまずいだろ（公務員的に）
• そもそもタクシー使いすぎだろ。どういう仕事の仕方してんの？（労務管理的に）
• 特定の人にだけそういうことやっちゃマズくね？ （公共交通機関としてのタクシー的に）

といった本来別々の三点がひとくくりにされているがゆえに街の人のインタビューもご意見番のコメントも全部まちまちなのである。

「具体的に何がどういう風に問題で、対策は何？」と振ると言う人聞く人書く人読む人によってぜんぜん違ってくる話であるがゆえに好きなように囃したててネタにできるところがマスコミには好都合だ。山本モナの件と居酒屋タクシーの件は実はこの点で共通している気がしたので並べて書いてみたというのはうそで単に書きかけの草稿記事を強引につなぎ合わせただけです。

see also:

ワンボックスのタクシー (2005/5)

正確にいつだったか忘れたが、ゴールデンウィークごろだったかな？このブログをホストしてるレンタルサーバのMysqlサーバ群がお亡くなりになったらしく、ブログの更新やら何やらが2、3日できなくなったことがあった。

レンタル屋さんはどうにかバックアップから復旧させたらしいのだが、最近のブログ記事のデータが何本か吹っ飛んだまま。おいおいおい。格安クオリティってのはそんなもんかね。

手元に取っておいたMySQLエクスポートファイルからデータベースを復元し、MT(MovableType)上で全記事を再構築して元に戻した。cronにしかけておいたコマンドが以下。

/usr/bin/mysqldump -h dbserver123.rental.example.jp -c -u netadbuser --password=hogehoge netadb | gzip | uuencode netadb-mysqldump.txt.gz | mail -s 'netadb-mysqldump.txt.gz' hogehogefugafuga@gmail.com

これをcronにしかけておくと、MySQLデータベースのエクスポートファイル（全データがSQLのInsert文の形になったテキストファイル）がgzip圧縮されてメール添付ファイルの形でメールされる。dbホスト名とかデータベース名とかデータベースユーザー名とかファイル名とかあて先メールアドレスとかはお好きなように。これを毎日実行にするとか週イチ実行にするとかもお好みで。こんなときgmailだとメールの容量気にしなくていいので助かる。

DBパスワードがナマで書いてあるのがちょっと気になるが仕方がない。MTであればmt-config.cgiにもナマで書いてあることだし。

エクスポートファイルから戻す（インポート）のもコマンド一発。が、筆者はそのとき面倒くさかったのでphpMyAdmin画面上のインポート機能を使ったので説明は省略。

やっぱり独自のコールドバックアップもやっておくもんです。

なお、このやり方だと、DB管理されてない情報＝静的なファイル＝画像とか＝はバックアップされないので別途方法を考える必要がある。筆者はrsyncを使っているがその話はまた今度。

高木浩光＠自宅の日記 - 無責任なキャリア様に群がるIDクレクレ乞食 ―― 退化してゆく日本のWeb開発者っていう記事で筆者のこないだの記事が引用されている。

引用の引用になってしまうのでややわかりづらいんだが、

これに対し、「iPhoneがきっとそれを止めてくれる」と希望的観測を示す人が続出した。

• iPhoneと携帯契約者固有IDと複アカと青少年ネット規制によるケータイ闇ナベ狂想曲, Web屋のネタ帳, 2008年7月21日

  2008年7月。ここへきてiPhoneが豪快に殴りこみ。もちろん空気読む気なぞさらさら無し。携帯契約固有ID？端末シリアル番号？はぁ？日本の事情なんか知るか。っていうかお元気ですかそこのガラパゴス諸島のみなさん。俺様はアップルだ、いいからそこに行列しろと。

• むしろ「ケータイ」を変えようよ, 崎山伸夫のBlog, 2008年7月23日

  iPhoneはyomoyomoさんがFSFの批判を紹介しているように決して自由な端末ではないが、日本のケータイ文化の文脈とは縛るところが明らかに異なる端末であって、そうした多様性が日本のケータイ文化を市場を通して揺るがし、コンテンツプロバイダーとキャリアの態度を変えさせることに私は期待している。

なぜ、iPhoneだとそうだと思えてしまうのだろうか。

筆者＝「iPhoneがきっとそれを（携帯に個体IDをふって公開するという粗悪な設計思想の蔓延を）止めてくれる」と希望的観測を示す人と思われてしまったらしい。おいおいおい。自分以外はすべてバカだと思い込（以下略）ドラえもんの独裁スイッチ（以下略）

• iPhoneって端末シリアル番号は出力されるの？ (2008/6/23)
• で、iPhoneって契約者固有IDは出力されるの？ (2008/7/11)
• iPhoneと携帯契約者固有IDと複アカと青少年ネット規制によるケータイ闇ナベ狂想曲 (2008/7/21)

上記三つのエントリについて読む人がどう解釈しようが勝手だけどね。少なくとも筆者は事情はわかっていつつも話が込み入りすぎてるのでとりあえず軽くポーリングしながら情報収集してただけですよ。で、最後に闇ナベ狂想曲と題して囃してみただけ。この闇ナベにソフトバンクが後で何をブチ込むかなんてわかったもんじゃございませんよ。だから闇ナベなの。

なお、この記事では筆者にしては珍しくコメント欄にも書き込んだりしてるのでそちらもごらんいただきたく。