トップ «前月 最新 翌月» 追記

2002|01|02|03|04|05|06|07|08|11|12|
2003|01|02|03|04|05|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|02|03|04|07|

2003-08-01 [長年日記]

_ qpopperの逆引き対策 (13:50)

ネットワーク構成を変えるために、会社のサーバーを(物理的に)いじっていたら、メールサーバーへの接続がやたらと遅くなった。ずいぶん前にメールサーバーにはLAN内からは直接ローカルアドレスを使って接続するように変えていたんだけど、qpopperがローカルアドレスの逆引きタイムアウトを待ってしまうらしい。今まではたまたま特定のゲートウェイ経由になっていて、そこがhostsに登録されていたから助かっていたのかな。しょうがないんでLAN内用DNSサーバーにローカルアドレスを一通り逆引き設定して対処。泥縄っぽい対策だ。やっぱり専任のサーバー管理者が欲しいなー。設計するための知識は欲しいけど、管理するための知識まで集めていられないよ。

_ はてなダイアリークラブ的アプローチ (13:50)

blogムーヴメントで重要な要素とされる、個人Webサイトを集約するためのさまざまな仕組み。RSSを使った連携だったりTrackBackCommentを使った情報交換だったり、blogdexなどによるインデックス/ランキング作成だったり。

まああれはあれで面白いんだけど、もう一つ追求する可能性がありそうなネタとして、はてなダイアリーにおけるはてなダイアリークラブ的アプローチがあるな。

あれはつまりは、あるテーマに沿った文章をみんなで発表する雑文祭とか、昔日記猿人(才人)で突発的に起こっていたような「みんなで同じネタを扱った日記を書きはじめる」イベント的な状況とか、あの手のものをうまくキーワードリンクをベースにシステム化して、「クラブ活動」というタイトルを付けた感じ(はてな側が作ったのではなく、ユーザーがそういう利用方法を思いついた形だけど)。Wikiを使った話題別リンク集とは、ユーザーが能動的に参加するところがちょっと違う。

こういう個人Webサイトをまたがって発生する単発的なイベントをうまく吸収する仕組みってのが、はてなに特化しない形であるといいかもね。昔考えていた話題ベースの更新報告型リンク集みたいなものを、クラブ活動の場だと捉えてデザインするとそれっぽくなりそうかも。

ただ、はてなダイアリーみたいに

  • (一般的にはあまり使わないであろう)クラブ名を決める
  • クラブ名を文章中に記述するだけで(クラブ活動に)参加できる

という敷居の低さがあってこそ、って部分もあるんだよなー。まあblogmapの取得対象サイトだったら、ある程度似たようなことが出来るかな。


2003-08-02 [長年日記]

_ デジタル土方 (13:50)

久しぶりに会社のネットワーク回りを大幅にいじるために土曜出社。もうずいぶん長いこと使っていた(ここ3年くらいはDNS解決のためだけに)OCNエコノミーとおさらばするための最後の作業でもある。

社内ネットワークの基幹の電源を全部切って、線を全部引っこ抜いて、残すサーバーだけ新しいラックに詰め込んだ。電源を入れ直したら、一発で起動しない怪しいサーバーもあったけれども、まあなんとか一通り動いている模様。環境の良くない場所にずっと置いてあったネットワーク機器は真っ黒なホコリまみれで、手だけでなく着ていた服まで真っ黒になった。

ついでに買うだけ買って放置してあったミラーリングボックス(ACS-7500)を接続しようと、久しぶりにPCサーバーをばらしたら手が傷だらけになった。最初にロックした方がソースドライブになるという簡単操作は、危険な操作を手軽にさせすぎてよくない気がするよ。もうちょっと手間がかかってもフェイルセーフが働くようなインターフェースの方がいいんじゃないか。

_ 2003F1ドイツGP (13:50)

予選1日目

ジャガーのピッツォニアが馘首になって、代わりにミナルディのジャスティン・ウィルソンがジャガーに移籍したとか。まあどうでもいいけど。

久しぶりにちゃんとした予選1日目を見た気がするけど、もう上位陣はあんまり真面目にタイムアタックしていないように見えるな。予選2日目にタイムアタックする順番を遅くするためだけに、それほどがんばってもしょうがないし、逆にフルアタックの情報をライバルに与えるデメリットまである。すでに実績があるドライバーにとっては、予選1日目に結果を出したところでまったく意味がないからなー。

それにしてもヴィルヌーヴ。本当にもう今シーズンは途中でやめた方がいいんじゃないか? もうお金はいらないだろうから、途中でやめるのに十分な言い訳さえ見つけられればやめそうだ。BARもそういう言い訳を見つけてあげればいいのに。でもまだヴィルヌーヴはF1に未練があるかなー。でも上位チームがヴィルヌーヴを拾ってくれる可能性は薄いよなー。

予選2日目

またウィリアムズが速いのか。フェラーリも予選1日目ほど悪くはないな。トヨタも十分に速いけど、また決勝の結果に結びつけられないのかな?

決勝

うわー、ライコネンとバリチェロとラルフが一瞬で消えたよ。誰が悪いと言いにくい状態だけど、強いていえばライコネンかなー。ライコネンが中途半端に抜ききらない状態で幅寄せしてきて、バリチェロがぎりぎりまでよけたけれども逃げ切れずにラルフに接触し、跳ね返ってライコネンにも接触し、みんなまとめてリタイアって感じか。久しぶりにトップ3が3台もいないと、ポイント圏内下位の争いが激しくなりそうだな。

途中ばたばたした斜め見してしまった。

クルサードはいいレースをしたなー。でもあれだけいいレースをしたんだったら勝たないとな。これが今シーズンのベストレースだったりして。

モントーヤは文句なしの完勝だったけど、ラルフ、ライコネン、バリチェロがいたらどうなったのかは微妙だな。特にラルフが最大の敵になっただろうし。なんとなく今シーズン、車はウィリアムズが最高だという評価を得つつも、ラルフとモントーヤがチーム内で争った結果、結局ミハエルがチャンピオンを持っていってしまうというオチになりそうな予感。

ミハエルも優勝を狙わない方向での最高の走りだった。ミハエルのすごいところは、あれだけ強くて実績があるドライバーなのに、下位を走っているときも全然手を抜かないところだな。とにかく取れる限りの最高のポイントを得ようとする。2位まであがれたのは僥倖だったけれども、それをパンクで失ってもきっちり2ポイントは稼ぐあたりが強いな。

トヨタは予選だけでなく結果も残した。このまま強くなっていくのかな。それともそろそろ頭打ちなのかな? トップチーム群の次のポジションまで来れたチームはたくさんあるけれども、トップチームの仲間入りが出来たチームは数少ない。ここが一番大きな山か。


2003-08-03 [長年日記]

_ バイク復活 (13:50)

半年以上乗っていなかったバイク(DJEBEL125)。半年前にも半年ぶりくらいに1回だけ乗ったはずなので、ほぼ1年くらいほとんど乗っていなかったことになる。

DJEBEL125はキックがついておらず、バッテリーももちろん上がっているので、まずはバッテリーの充電からスタート。車とブースターケーブルでつないでくそ暑い中20分ほど待つ。ブースターケーブルをつないだままエンジンをかけてみる。5分ほどトライしているうちにエンジンがかかるようになった。それからさらに10分ほど待ってから、ブースターケーブルを外す。ニュートラルランプすら点灯しなかった。全然充電されていない。これはバッテリーが完全に死んでいるか。

しょうがないんで近所のカー用品店にお買い物に行く。ついでに、いまだにスタッドレスを履いていた車も、夏タイヤに変えておこう。小さいカー用品店なんだけど、バイク用のバッテリーも一通り置いてあった。ちゃんとDJEBEL125対応と書いてあるバッテリーが置いてあったのでそれを買う。1万円ジャスト。まあそんなもんか。さらに、バイクのエンジンオイルがずいぶん減っていたのを思い出して、適当な車用のエンジンオイルを1リットル買っておく。オフ車のカブと呼ばれるDJEBELだし、安い車用オイルで十分だろう。

タイヤ交換が終わって家に帰り、バッテリーをつけなおしてエンジンオイルをつぎ足して(面倒なんで交換はしない)エンジン始動。チェーンがからからに乾いていたんで、昔使った湿式チェーンオイルの残りをまぶす。ギアの動きがとても悪いけれど、CRC556が見あたらないんでひとまず放置。あとで見つかったら、CRC556で磨かれちゃっても構わなそうな稼働部に吹き付けておこう。

そのあたりを一周ぐるっと回ってきたところ、バイクの調子は1年前と全然変わっていない感じ。人間の方も、ほぼ1年ぶりに乗った割にはまったく無意識に運転できた。さすがに一時期は通勤で毎日乗っていただけに、完全に体が覚えているんだろうな。これで夏休み中にツーリングに行く準備が(バイクの方は)出来たかな。


2003-08-04 [長年日記]

_ 丸刈りータ (13:50)

五分刈りにしてきた。多分今までで一番短い。でもよく考えてみると、前髪がなくなっただけの話で、頭頂部から側頭部、後頭部にかけての長さだけならば、これくらい短くしたことがある気がする。結局坊主頭かそうじゃないかは、前髪2センチくらいの差だけなのかな?

_ バイクというよりは人の慣らし (13:50)

夏休み中にツーリングに行こうという話があったんで、バイクを復活させたわけだけれども、オフロードとかに入っちゃう可能性が高いので、もうちょっと大丈夫かどうかを確認しておかないと怖い。バイクよりも人間の方のスキル的に。

というわけで、今日はバイクで近場をうろうろ。たっぷりチェーンオイルを吹き付けておいたけれども、なんだかまだかっちゃんかっちゃんうるさい。チェーンがゆるんでいるのかなー。前はチェーンオイルをたくさんつけたら大丈夫になったんだけど。

1年くらい乗っていなくてもエンジンは大丈夫そうだけど、ギアおよびチェーンのあたりがちょっと不安。あとタイヤがものすごく不安。ひび割れたりはしていないけれども、乗っていてなんだかやたらとグリップがない気がする。路肩よりのちょっと斜めになったところなんかで、思ったようにグリップしてくれない。どこかでちょっと荒い運転をして、タイヤの皮をむいておかないとダメかな。


2003-08-05 [長年日記]

_ 家サーバー死にかけ? (13:50)

今朝起きたらblogmapが死んでいた。見てみたら、DBMySQL)へのアクセスが出来なくなっていた。myisamchkで修復しようとしてみてもread onlyエラーが出る。しょうがないんで、一度マシン自体を再起動しようとしてみたら、終了プロセスの途中で死んでしまった。ハードリセットしてみたところ、起動プロセスの途中でHDDのI/Oエラーが出まくってそのまま死亡。あかん、完全に死んだか。と思いきや、もう一度電源を完全に落としてから再び起動してみたら、何事もなく起動してすべてのプロセスがちゃんと動作し始めた。うーん、気色悪いなー。ひとまずいろいろとバックアップを取ってから、そのまま放置中。もう一度おかしくなったら新しいHDDを買ってきてセットアップし直そう。家サーバーも、動かしはじめてもう1年以上は経ったかな。

_ 大雨ハロー警報 (13:50)

ツーリングには明日行くことになったんで、もうちょっとバイクに慣れておこうと今日も遠出。久しぶりにバイク通勤シミュレーションでもしてみようと、渋谷へと向かってみた。

今日はフルフェイスの方のヘルメットをかぶってみたところ、しばらく走っているうちに前頭部がじりじりと熱くなっていった。ヘルメットの通風口の開け忘れ。手探りで後頭部の通風口を開けたところ、風が通って一気に温度が下がった。

相変わらず混んでいる17号、明治通りルートを通って渋谷まで1時間強。久しぶり過ぎてすり抜けをどの程度やっていいのか判断に迷う。そしてケツが痛い。かなり疲れたんでマンガ喫茶で休憩。ちょっとのつもりが3時間かけて、前途中まで読んだ「クロカン」の残りと、ちゃんと通して読んだことがなかった「シャカリキ」を全部読んでしまった。

マンガ喫茶を出ると、空がやけに暗かった。黒い雲が北側、帰り道の方向に広がっている。本当はもうちょっとうろうろしてから帰るつもりだったのだが、いやな予感がしたのでそのまま帰ることに。帰り道は246、環七、目白通り、環八、17号バイパスというルート。しかし、環八に入ったところで雨が落ち始め、すぐに雷を伴う大雨に変わった。

すぐにやむ夕立かと思って、いったん道ばたにバイクを止めて雨宿りしてみたんだけど、30分くらい経っても雨足が弱まる気配がない。しょうがないんで、一応持ってきていた雨具を身につけて出発。視界が悪すぎ。雨のバイクってこんなに視界が悪かったんだっけ? 結構ちゃんとした雨具なんで体は濡れないんだけど、靴がすぐぐしゃぐしゃになった。

なんとか家に帰り着いた頃には、なんだかぐったり疲れていた。さらに最初にちょっと雨に濡れたせいか、微妙に頭痛がする。こんなんで明日ちゃんと出かけられるのかな?


2003-08-07 [長年日記]

_ 東秩父いいねー (13:50)

昨日は予定通りツーリング。11時過ぎにさいたまを出発し、17号バイパス浦和所沢バイパスR463R299と通ってまずは飯能まで。ほとんど渋滞なしの快適な道程だった。いやー、こんなに快適な道は都内&川崎に住んでいた頃はなかったなー。

で、飯能から飯能名栗線に入ろうとしてしばらく迷う。名栗という標識を見るたびにそちらに曲がってみるのだけれども、曲がった後にはまったく(名栗と書かれた)標識が現れず、そのあたりの地名に詳しくない人間にはどっちに行っていいのかさぱーりわからん状態。一度標識に地名を出したら最後まで責任もって案内せんか。

で、飯能駅周辺をぐるぐる回っているうちに、ようやく再び名栗の文字を見かけて曲がってみたら、いつの間にか飯能名栗線に入っていた。川沿い&山間の道を走るととたんに気温が数度下がる。ときどき寒いくらいまで下がる。天気は曇りときどき晴れといった感じで、夏のツーリングとしてはベストといえるだろう。このまま天気が崩れて雨さえ降らなければ。

名栗でダム方面に行こうとしたら、二輪車通行禁止だった(多分走り屋対策)。おとなしい125ccのオフ車ですけん、許してつかーさい。と思ったけれども、まあしょうがないんであきらめて引き返す。

飯能名栗線を抜けるとそのまま県道53号を北上。そのあたりから微妙に脇道林道が増え始めるので、適当に逸れてみる。ぐねんぐねんと曲がりながら登る山道に、ときどきダートがあったりしてなかなか楽しい。正丸峠で飯を食うと、再び県道53号を北上。そのままR299に入り、そして県道11号方面に曲がってみる。

ここからは本格的に脇道がたくさんあって楽しい。ときどき、出口にだけ二輪車進入禁止の看板があったりしたけど(まあ不可抗力だよね)、とにかくツーリングマップルには載っていない細かい枝道がたくさんあって楽しい。定峰あたりから適当に逸れたら、いつの間にか県民の森あたりに出てきたんで、大野峠白石峠を通って定峰峠に戻り、再び県道11号を北上。そこから二本木峠方向に逸れ、釜伏峠を通って寄居方面へ。そろそろ17時近いし帰りのルートへ。

寄居方面に向かっているうちに、いつの間にかR254に合流。R254をどちら方向に行くか迷う。勘で曲がったところ、行く先方向に川越があると表示されて、一瞬間違ったかと勘違いする。電車の感覚で言うと、川越と言ったら埼玉のかなり北の方だ。さすがに川越よりも北までは来てないよね。と思って地図を確認したら、川越なんて目じゃないほど北にいた。

あとはひたすらR254を南下。予想よりもずいぶん距離を走っていたため、比較的空いているR254を飛ばして帰っても全然家が近づかない。途中、でかい交通事故でR254の一部が封鎖されていたけど、バイクなんで適当な脇道を抜けて回避。車だとはまっただろうなー。そのあたりは近くに代替となる大きい道路がない場所だったし。

そろそろR254が混んできた頃に、有料の富士見川越道路があったんで使ってみた。原付は20円だった。普通二輪車は200円。ここまで安いんだったら原付から金を取らなくてもいいのに。あと、あの道って料金所が終盤の一カ所しかないけど、そこさえ通らなければお金は取られずに済むのかな? たくさん交差点があって、どこからでも降りられそうだったけど。

結局帰宅は18時半過ぎ。飯を食っている間以外はほぼ走り続けたんで、ケツがとても痛い。久しぶりのバイクだったためか疲労も激しく、シャワーを浴びて飯を食ったらすぐに限界が来て21時前には落ちた。そして朝目を覚ますと、全身が痛い。これは筋肉痛? それとも振動に晒され続けての打撲か何か? 体中のどこに力を入れても痛いんで今日は一日酒を飲んでごろごろ。ああだりい。

_ 消費者に理解されていない「ICタグ」 from ITPro 記者の眼 (13:50)

ユニークIDを第三者が確認できる形で持ち歩くこと」のリスクが理解できないのか、その存在にも気付いていないのか、知っていて見ないふりをしているのか。

ユニークID-ユニークIDというn:nのデータは、コンピュータで非常に効率よく管理できる。そのデータサイズは小さく、検索は高速だ。そうなると、RFIDリーダーで認識されたすべてのデータを保存しておくことは難しくないし、そういうデータが存在するならば流出する可能性もある。

ある場所で収集されたユニークID-ユニークIDデータは、それ単体では大して意味を持たないかもしれない。しかし、コンピュータは、さまざまな場所で入手したデータをユニークIDをキーにリンクさせていくことが出来る。

ユニークIDのリンクをたどっていった結果、最終的に一つのデータでも個人情報と結びつきさえすれば、そのユニークIDとリンクしているすべてのユニークIDを持つデータが、個人情報と結びつくことになる。

しかも、その情報収集はRFIDの本来の使い方とも重なっているため、どこからどこまでがOKでどこからどこからがダメと明確に定義しにくい。また、一般消費者にはどこでどの程度の情報が収集されているのかは関知できない。法律で縛ろうとしたところで実効性はないだろう。

_ 同好の士がリンクし合う「オンライン・クリーク」 from HOT Wired (13:50)

リーダーの権限および入会資格ルール)が厳密なWebRingって感じかな。コードってのは要するにバナーのことだった。

こういう個人Webサイト持ちをある特定の要素(趣味)をベースにまとめあげるコミュニティ用のシステムってのを作るのも面白そうだな。ホームページ+メンバーリンク集+WebRing+バナー倉庫+ルール表示+BBS(+ML)+チャット(+メッセンジャー)あたりを用意すればいいのかな。


2003-08-08 [長年日記]

_ 新説「ティラノサウルスは殺し屋ではなく掃除屋」 (13:50)

そうだよなー。確かにあのサイズ(体重)であのくらい頭が大きいとなると、それほど俊敏に動作できたとは思えないよな。口(歯)のでかさだけ見ると凶暴な肉食獣って感じだけど、冷静に運動能力について考えてみると、屍肉漁りである可能性が十分に高そうだ。

_ GVN撤退? (13:50)

>>781 :名無しさん@お腹いっぱい。 :03/08/08 11:18 >>まいったなぁ。8月末にgvn撤退ですよ。

まぢですか? GVN立ち上げの時に真面目に借りてみようと検討していたし、今でもときどき検討対象に入れていたんだけど。そういや今はもうまちBBSもGVNじゃなくなってるんだよな。


2003-08-09 [長年日記]

_ 「ペニスを大きくするサプリメント」のスパム広告に注文殺到 (13:50)

「あなたのペニスを巨大にする」スパムを使って、怪しげな飲み薬を販売していたオンラインショッピングサイトから顧客情報が流出し、それによって実はその怪しげな薬が結構売れていたことが分かった、という話。一月弱で50万ドルの売り上げとはすごいなー。雑誌とかに広告を出している伸長法(みるみる身長が伸びる!)とかも実は結構売り上げを上げていたりするんだろうなー。

本日のツッコミ(全1件) [ツッコミを入れる]

_ ハイド [両端にあなの開いたガラス瓶のなかへ、ペニスをいれ瓶の片方へ掃除機のホースをつなぎ中の空気をすいだすと、中が真空状態と..]


2003-08-12 [長年日記]

_ 反撃するフィルタ --- Filters That Fight Back (13:50)

>>spam業者はベイジアンフィルタを破るために何をしているのだろうか。そして、フィルタ開発者はどうやって反撃できるだろうか。 >>そそられるアイディアの一つは、文字通り、反撃するというものだ。受け取るメールに含まれている全てのリンクをフィルタが自動的にたどるようにすることで、spam業者のサービスを止めてしまおうというものだ。

なるほど、変なアタック(クラックとか)をして反撃するのではなく、単純にスパムで宣伝されているURLにコンピュータが自動的にアクセスするだけで、十分に反撃になる(スパム送信元が運営するWebサイトの負荷、帯域使用量が増える)という考え方か。しかも、スパムを大量に蒔けば蒔くほどダメージが大きくなるというあたりもポイントが高い。できればプロバイダのメールサーバーとかのレベルでやって欲しいかも。

ただ、これが流行るとこの仕組みを使ったDoSアタックが簡単に出来ちゃうな。攻撃したいサイトのURLを含んだスパムを蒔くと、みんなが自動的にアタックしてくれる。URL表現はいろいろ偽装する(簡単な手段としてはホスト名をIPアドレスで表現するとか)ことが出来るから、ホワイトリストで遮断ってのも結構難しいだろうな。

とか考えると、完全自動で反撃するのではなく、メーラーにスパムフォルダ(ベイジアンフィルタで自動的に分別してもいい)みたいなものを用意しておいて、ユーザーが手動でそのフォルダ内のメールに対して反撃する(間違い反撃を気にするならば、スパム以外のメールが含まれていないことを確認してから)、とかした方がいいかも。

_ PHPでUserAgentを変更する (13:50)

PHPURL対応のfopen_wrapperを有効にしているときに、file_get_contentsなんかでHTTP(とかFTP)ごしに、他のサイトからデータを引っ張ってくる際に、HTTP_USER_AGENTを自分で好きな文字列に変更する一番手軽な方法。

ini_set('user_agent', 'my useragent name');

PHPのどのバージョン以降で有効なのかは未確認。Curlライブラリを使ったり、fopensocketを使ったりしなくても、単純にHTTP_USER_AGENT文字列を変えたいだけならばこれで済む。

_ 背中が痛い (13:50)

先週ツーリングに行って以来、背筋痛が治らない。もともと背筋痛は3年前(http://ishinao.net/ruins/diary/200004.htm#20001107191205)にサスペンションの壊れたバイクに乗って痛めて以来の持病で、何かと痛くなりがちだったんだけど、1週間経っても痛みがひかないってのは珍しいな。ここ数年健康診断の時に側湾症の診断がついちゃっているし、一度整形外科にでも行って来ようかなー。でも、

を見ると、いまいちいい治療法はなさそうだな。それよりも、スポーツクラブとかに通ってきちんと運動する習慣をつけた方がいいのかな?

_ Re:TrackBackは相互リンクか一方通行リンクか? from ARTIFACT (13:50)

blogmapのTrackBack対応は、すでに話題になっているネタ(しかもURL付き)を集約する方法としては使えるけれども、まだ話題になっていない(blogmapに登録されていない)ネタや、すでに話題になっていてもblogmapには登録されない(キーとしてのURLがない)場合には使えない、というのがいまいち。

そのあたりを解決する手段として、はてなダイアリークラブ的アプローチなども考えているけれども、それでもすべてが解決できるわけではないしなー。

ちなみにblogmapのTrackBackは、どちらかというとblogmapベースの書評リンクの土台としての機能の方を重視しているつもり。URLランキングの情報は比較的賞味期限が短いし、個人ニュースサイトの多くがほとんど自分の意見を書いていないんで、リンク元をたどっていってもあまりおもしろみがないし。

ただ、わざわざTrackBackを送ったサイトならば、それなりに意見が書かれている可能性が高そうだから、TrackBack数が増えてくればそれなりに面白くなるかな? ただ、bulknewsがTrackBack対応してもあまり利用者が増えない現状を考えると、やっぱりTrackBackは結構敷居が高いんだろうなー。

_ RDF埋め込みを追加 (13:50)

wikilogに、ページごとのRDF埋め込みを追加。コメントタグでRDFを埋め込むのはHTML表現として美しくないし、ほとんど利用されない割には転送データ量が増えるし、あほらしいよなーと思っていたんだけど、Bookmarkletを使ってうちにTrackBackを送ろうとしたときに、TrackBack Ping URLが自動取得できないというのも申し訳ないような気がしたんで、一応つけてみた。

なんかでも、もっと美しいやり方があるはずだ、というか、もっと美しいやり方を標準化するべきだ、という気がしてならないよ。


2003-08-13 [長年日記]

_ ネットがもたらした「ファンタジースポーツ」ブーム from ZDNet (13:50)

ずいぶん前からオンライン草野球ゲーム(プレイヤー自身が選手となる育成&対戦シミュレーション)の企画を練っているんだけど、やっぱりそういうのよりもプロ野球選手を使った方が面白いと思う人が多いのかなー。とか思いつつも、まあこのネタはどうせ趣味でやることになるだろうし、一般受け度はそれほど考えなくてもいいかな。でもさすがにオンラインゲームとなると、ちょっとした余暇で一気に作って立ち上げるってのは難しいなー。会社に余力があれば仕事としてやりたいところなんだけど。

_ 名機か迷機か? 新スタイルCLIE「PEG-UX50」を試す (13:50)

実際に使ってみた人の感想を読んでも、やっぱりいまいち感が漂っている感じだ。パーツレベルでは良さそうなマシンだから、このパーツ類をもっとちゃんとしたコンセプトの元にとりまとめた新しい製品を待った方が良さげ。「これを買うくらいならばSL-C760を買っておけ」というには、まだLinux Zaurusマルチメディアプレイヤーとしての能力は低いんだよなー。ハードウェアとしては十分なんで、そのうちなんとかなるとは思うんだけど。

_ 経産省、ショッピングサイトなどでの Cookie 盗聴を警告 (13:50)

SSLセッションCookieを使ったシステムのセキュアさに関しては、ほぼ無条件に信頼しがちだったんで、HTTPHTTPSを行ったり来たりする場合にセッションCookieが経路上で盗まれる可能性に関して考えたことがなかったなー。まあもともと、経路上で情報を盗まれるパターンに関して、あまり真面目に考えたことがなかったってのもあるけど。経路上での盗聴って、どの程度対策しておくのが基本なんだろうなー。XSS対策はいつでも考えておくべきだと思うんだけど。

ちなみにWeb XPでは、基本的にPHPのセッションCookieを利用しつつ、n%の確率(設定による。デフォルトは0%)でセッションIDをregenerateしつつ、さらにIPアドレスn桁マッチチェック(設定による。デフォルトは未チェック)と、HTTP_USER_AGENT文字列のチェック(設定による。デフォルトは未チェック)を行うことでセッションIDを保護していたんだけど、さらにHTTPSがonの場合にセッションCookieがsecureじゃなかった場合は、強制的にセッションIDをregenerateしてsecureなCookieを吐き直すようにした。これでほぼ安全かなー。

_ photologを追加 (13:50)

photologというか、携帯デジカメで撮影した画像をメールで送ってアップロードする機能をwikilogに追加。といっても、WikiLikeにもつけていた機能をデグレードしたものだけど。いろいろリッチな機能を持たせることも出来るんだけど、面倒くさいリッチな機能なんて作り込んでも、いちいち使ってられない。小さい(低画質の)写真を撮影してタイトルを付けてメールで送るだけならば、何とか使う気になれるかな? ある程度データがたまったら、もうちょっとインターフェースを考えよう。

_ Google電卓 (13:50)

Googleで計算が出来るってネタがあちこちで話題(http://slashdot.jp/article.pl?sid=03/08/13/071230)になっているみたいだけど、この機能ってずいぶん昔にもあったよね? 過去ログを探してみたら、2001年11月の日記の、

でネタにしていた。上記で「知らなかったよ」にリンクしている先は、現在移転していて、

にある。ただし、この後しばらくしたら電卓機能が使えなくなっていたんで、非公式の実験だったんだろうなーと思った覚えがある。それからしばらく復活しなかった機能が、なぜに今さら復活したんだろう?


2003-08-16 [長年日記]

_ 過去ログ移行中 (13:50)

wikilogシステムに、読書感想日記を中心とした過去ログを移行中。複数のシステムに分かれていると検索性が悪くて不便だし。

ただし、過去ログはさまざまな(非定型)フォーマットに分かれているし、その当時のシステムに依存しているようなネタは、このシステムに移行したくないんで、内容を確認しながら一つずつ手作業で移行している。ああだるい。自動移行スクリプトを書いて、後でゴミを消すという手もあるけど、手作業の方がトータルでは楽そうだ。5年分のログとはいえ、しょせん分量は限られているしいつかは終わるだろう。

_ Re:03.08.16 from K.Moriyama's diary (13:50)

>>なぜ結城さん携帯電話のことについて書かないのか、ということ。

携帯電話の位置情報は、契約したキャリアしかその情報を利用できない。RFIDに関しては、その情報がどの程度公開されるかは不明だが、おそらくある程度公開規格的になる(=不特定の人々がその情報を利用できる可能性がある)と思われる。この違いが大きい。

取得できる位置情報の正確さは、携帯電話の場合数十〜数百メートル程度の範囲までしか特定できないという差もあるけれども、位置情報の木理が粗いからといって問題にならないわけではないので、こちらは質的な違いはない。

>>ユビキタス系サービスを受けようと思ったら、機械に(人間じゃなくてもいい場合も多い)自分がいまどこにいるか提示しないとまず無理ですよ。

これには同意。まったく情報を提供しないでサービスを受けることは難しい。ただし、「自分がいまどこにいるか提示する」のに「RFIDを使って常時情報を提供し続ける」必要はないと思う。それともユビキタス系サービス(という表現も曖昧なんで、どういうサービスを想定しているのか違っていそうだけど)を受けるためには、人間がまったくアクションすることなく、周囲の機械に自動的に個人の識別情報を読みとらせることが絶対条件なのだろうか? まあその方が便利かもしれないが、サービスを受けたいと思った人が機械に対して情報を提示するアクションを行う(「識別カードを提示する」でもいいし、「情報発信装置をONにする」でもいい)でも十分だと思う。

>>Suicaは今のCLIEの一部機種でも読みとれるんだけど、ポケットの中のカードの履歴を読みとるためにCLIEを手にそーっと近づいている人がいると想定してみましょう。

Suicaのリーダーは誤認識(前後の人と混ざる)を避けるためにわざと感度を下げているはず(確か実験のときはもっと感度が良かったと聞いた気がする)だし、PDAであるCLIEは電力消費を抑える必要があるため、こちらも感度を高くしているとは思えない。つまり、現在のSuicaの読み取り可能距離が限界というわけではないだろう。

CLIEのリーダー部を改造して感度を高めている例とかはないんだろうか? たとえば50センチくらいまで感度を上げることが出来たならば、その脅威はかなりの物だ。確かRFIDには、1〜2メートル程度まで離れたところから読みとる用途を想定して開発されているものもあったはず。

久しぶりに森山さんがRFID関連の話を書いたけれども、なんか説得力がないなー。いろいろ関係各社を取材した結果として、推進派よりの見解に達したのならば、もうちょっと説得力のあることを書いて欲しい。否定派はどちらかというと想像で物を言っている(いわゆる杞憂の可能性が高い)のだから、何か具体的な情報を持って否定してもらえるのならば、それに越したことはないのだから。


2003-08-17 [長年日記]

_ 眠れない (13:50)

休みの間、遅寝遅起きを励行しすぎたせいか全然眠れない。無理に寝ようとしても無駄だから、普段は眠くなるまでは無理に寝ようとせずにだらだら過ごすのだけれども、今日はその調子だとそのまま朝を迎えてしまいそうだ。というか、もう朝じゃん。タイムリミット(ムスコの登園時間)まであと2時間だし、今から中途半端に寝るのも逆にきついかなー。ということで、半分寝るのをあきらめてPCを引っ張り出した次第。まあ今日は特に急ぎの仕事もないはずだよな。適当に過ごしてとっとと帰って寝るか。

_ QuickMLをグループウェア化する (13:50)

いつのまにやらQuickMLはソースコードが公開されていたんだね。QuickMLはMLにおけるWiki的なものとして使えそうだなーと思っていたんで、どうせならば途中まで作りかけていたMLを核にしたグループウェアもどきを、QuickMLと連携させて構築してみようかな。

Webベースのグループウェア(とかコラボレーションツール)は、それはそれで悪くないけれども、メールのお手軽さに比べるとどうもいまいち使い勝手が良くない。メールはいろいろ制約が大きいし、セキュリティ的な甘さが大きいけれども、現在のインフラ上では一番お手軽なインターフェースになりうる。

QuickMLはもともとオープンなMLを作成するためのシステムなんで、セキュリティとアーカイブ保存とかの機能がほとんどない。セキュリティについては、まあお手軽さとのトレードオフなんであきらめるとしても、アーカイブは保存しないとグループウェアとして使いづらい。

一瞬、QuickML自体に手を加えて、アーカイブ保存機能を追加しようかと思ったけれども、そこまで手を加えるくらいだったら、QuickML的なコードをはじめから自分で書いた方が話が早そうだよなー。と、ソースを追っていったところ、mail.rbのsend_mailをrecipients+['foo@bar.com']なんて感じにして、特定のアドレスにQuickMLあてのメールをすべて転送してしまえば、あとはそっちのアドレスで独自にログを記録できそう。

というわけで、QuickMLをインストールして(サーバーのRubyのライブラリディレクトリが、QuickMLのライブラリインストールディレクトリと違っていたので、そのあたりをln -sする必要があった)、mail.rbを1行書き換えた。で、すでに作ってあった転送用メールアドレスをフックして、添付ファイルを分離しつつDBに保存するスクリプト(Perl製)と連動させてみた。一応動いているっぽい。

QuickMLの生成するSubjectはきれいだから、それをキーにちゃんと分類も出来そうだな。こういうアプローチでMLベースのグループウェアが簡単に作れそうだ。社内用システムとしてしばらくいじってみよう。


1日使ってみた感触では、QuickMLの適当な名前を付けてメールを投げるだけでML=グループが作れるという仕組みはやはり便利。ほんのちょっとした集まりレベルのグループが簡単に作れる。メンバーに関してもCCでメールを投げるだけで追加できるから、あまり深く考えずにひとまずグループを作ってから、あとでメンバーを考えてもいいわけだし。

ただし、やっぱり仕事で使うにはこのセキュリティ的なルーズさはかなり問題。ちょっとでも機密情報が関わりそうな用途には使う気になれないもんな。一応独自サーバー上で(社内LANに完結した利用を中心に)動かしている分、本家QuickMLサービスを使うよりはましだけど、MLのアドレスと参加者一人のアドレスが分かれば、誰でもMLに参加できてしまうというのは怖ろしい。

ただ、メールってのは基本的にセキュアじゃないもの(ヘッダ情報が信用できない)だから、メールレベルでセキュリティ対策を取ったところで根本的な対策にはなり得ないんだよな。かといって、Webアプリで設定するとかやるとお手軽度が一気に下がるしなー。

QuickMLのいいところを残しつつ、企業がちょっとした機密情報程度ならば載せる気になれる程度のセキュアさを持たせることはできないだろうか。やっぱりWebアプリとの連携でセキュアさを動的に変更できるようにする、とかになっちゃうかなー。


2003-08-18 [長年日記]

_ そんなこと俺が知るか! (13:50)

スカパー仮面ライダーストロンガーを(ムスコが)見ていた。ストロンガーは俺の(リアルタイム当時の)記憶と比べると、信じがたいほど格好悪く(頭でかすぎ)、ストーリーや台詞回しがとてつもなくチープすぎて、半分笑いつつも背中が痒くなるのだけれども、今日見た回はとても面白かった。

ストロンガーが怪人に捕まり、人を操るガスを嗅がされ、仲間である電波人間タックル(これもひどいキャラクターだ)を襲わされる。タックルの首を絞めるストロンガー。しかし、その動きは芝居だった。隙を見てストロンガーは怪人へと襲いかかる。「なぜガスが効かない!」「そんなこと俺が知るか!

てっきり後でガスが効かなかった理由を教えてくれるのかと思っていたら、そのまま怪人を倒して番組は終わってしまった。すごいなー、「そんなこと俺が知るか!」がありなのか。でもGoogleで「ストロンガー 俺が知るか」で検索をかけたら結構ヒットした。マニアには有名なネタだったのね。

_ メールを使った認証システムの案 (13:50)

サーバーに対して、HTTP(S)アクセスもしくは空メールを送る。すると、指定されたメールアドレスに対して、Subjectワンタイムパスワード文字列が含まれたメールが送信される。そのメールに返信する形で、メールを使ったコマンド(本文)を送る。FromアドレスとSubjectに含まれる(Re:とか付加されても大丈夫)ワンタイムパスワードを使って認証し、コマンド(本文)を実行(登録)する。

って感じでメールベースの認証システムを実装するのはどうだろう。

普通にメールを送った場合は、権限の弱いコマンドしか実行できなかったり、後で管理者がチェックをしないと実際にはコマンドが実行されなかったりするけれども、上記の手法でワンタイムパスワードをつければ、権限の強いコマンドが実行できる、みたいな感じにすると利便性とのバランスがいいかな。


2003-08-19 [長年日記]

_ Re:NaverのBOTさらに悪質化 from ただのにっき (13:50)

>>ついに「GoogleBot」を詐称するようになったもよう。

うわー、これは最悪だ。これはもう、Naverの所有するすべてのIPアドレスに対してdenyするしか、拒否する方法はないかな。どこかにNaverの所有するIPアドレス一覧はないだろうか。ちなみにうちのアクセスログに残っていたNaverBotのIPアドレスは、

61.78.61.163
61.78.61.162
61.78.61.170
61.78.61.193
220.73.165.81
218.145.25.77
218.145.25.81
218.145.25.113 

ただ、NaverBotと名乗っているすべてが本物のNaverBotとは限らないけど。

もうちょっと調べてみた。これらのIPアドレスに関するアクセスログは、

dloader(NaverRobot)/1.5
minibot(NaverRobot)/1.0
GoogleBot
Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Mozilla/3.01 (compatible;)
Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.0.3705; .NET CLR 1.1.4322)

なんてのが残っていた。普通のブラウザっぽいUserAgentも結構残っている。これらのIPアドレスはBot以外でも使っているのかな? あるいはもしかしたら、ランダムにUserAgent文字列を適当に付け替えるブラウザ(って確かあったよね)とかを使ったアクセスだったりして。

ちなみにうちも、robots.txtへのアクセスだけはGoogleBotだった。


2003-08-20 [長年日記]

_ 悲観的になる理由 (13:50)

RFIDセキュリティに関する議論が、もしも技術に対して楽観的な立場を取る(善用を重視する)か、悲観的な立場を取る(悪用される可能性を重視する)か、という違いだったとして。

現在の世の中は、非常に楽観的な設計によるシステム(コンピュータ技術に限らず、社会的なシステムもそう)で構成されている。さまざまなシステムに裏口があることは知られているし、実際にその裏口を使ったさまざまな被害が起きている。

コンピュータ技術においては、最近流行っているウイルスワームなどの問題や、顧客情報の流出、あるいはブラクラブラウザークラッシャー)や迷惑メールなども、システムの楽観的な設計が原因の被害であるといえる。

また、住民票などのセキュリティが非常に甘い(なりすましによる取得や届け出が可能)という現状や、いわゆる悪徳商法とよばれるものもその多くは、その原因(の一部)としてシステムの楽観的な設計が挙げられる。

それでも今まではそれなりにうまく回ってきたし、これからもそれなりにうまく回っていく可能性は確かにある。

しかし、コンピュータ化が進むと、小さな力で大きな影響を生み出すことがどんどん容易になっていく。それは、コンピュータウイルスの影響力が、昔と比べてどんどん大きくなっていることからも類推できる。昔も今もコンピュータウイルスを作るための手間はそれほど変わっていない(はずだ)が、被害は桁違いに増えている。

たとえばインターネット上を見回してみよう。もともとインターネットは善意のユーザー(コンピュータ)を期待する要素が多い設計だが、最近では悪意のユーザーに対抗するための技術も充実しつつある。アクセスコントロールパケットフィルタリング暗号化などさまざまな技術が作り出され、利用されている。

しかし、そのような安全な技術を用いているのは、ほんのごく一部だけだ。インターネットを構成するさまざまな部分に、楽観的な設計による穴が空いている。たまたま無事に過ごせているだけで、もしもそこを集中的に攻撃されたらひとたまりもない。それは、これだけさまざまなウイルスによる被害が報じられてもなお、新しいウイルスが発生すると同じように多くの人たちが感染していることからも分かる。

そういう現状を見ていると、これだけ穴だらけの世の中で、致命的なほどに大きな問題がなかなか起きないのは、本当にただの偶然というか、幸運であるに過ぎない、という気がしてくる。

で、RFIDだ。RFIDも、現状を見ている限りでは、同じように楽観的な設計によるシステムとして実用化されてしまいかねないもののように見える。しかも、RFIDはインターネットのような仮想世界的な要素が強いものとは違い、現実の世の中の人々の生活に直接影響を及ぼすような要素となりうる。さらに、新しくてスマートな技術はその悪用方法もスマートになりそう(秩序だったハイテクほどあらゆる意味で使いやすい)。

もしもインターネットと同程度の穴だらけのシステムを、現実の世の中の人々の生活にまで持ち込まれたらたまらないよなー。ちょっとでも危険性がありそうだったら問題視しておかないと、あぶなそうだなー。というのが悲観主義者(私)の考え方。


2003-08-21 [長年日記]

_ QuickML de GroupWareその2 (13:50)

QuickMLをグループウェア化するの続き。

名前(メールアドレス)を決めるだけでメーリングリストグループ)が作成でき、メンバーの追加はCCに入れるだけで済む、というのはやはりとても便利だ。このくらい敷居が低ければ、どんどんMLを作ってしまおうという気にもなる。

グループウェア的に利用する場合、基本的にプロジェクト単位でML(グループ)を作ることになる。そのプロジェクトに関するメールのやりとりをすべてML経由にすることで、メールを書くたびに、そのメールを誰と誰に送るのかをいちいち考える必要が無くなる。またSubjectが定型になるので、メールの自動分類も簡単だ。ただし、MLのメンバーではない人にそのプロジェクトに関するメールを送るときの処理はちょっと考える必要がある。

MLログをアーカイブしてWebベースで閲覧できるようにしておくと、自動的にそのプロジェクトに関する資料が生成されていることになる。まだ途中までしか作っていないが、添付ファイルを管理する文書管理システムを構築し、メールと添付ファイルを全文検索システムで検索できるようにすることで、その有用度はさらに高まるだろう。

というあたりが利点。しかし、ML管理が手軽な分に応じたセキュリティ的な甘さがやはり問題。

たとえば、間違ってCCにメンバーにしたくない人を入れてしまった場合、ほかの誰かによってMLあてに送られたメンバー以外に公開したくないメールが、本来送られては困る人に送られてしまう可能性がある(間違ったことに気付いてメンバー削除メールを送っても間に合わない場合があり得る)。

また、Webベースのログ閲覧システムにおいて、MLメンバーを妥当に認証することが困難。もともとMLメンバーはメールアドレスだけを頼りにルーズに管理されているので、それぞれに対して妥当な権限認証システムを用意するのが難しい。妥当な権限と認証システムを用意しようとすると、QuickMLの利点をスポイルしてしまうことになる(ようなものしか思いつかない)。

解決のためのアプローチは二つある。

QuickMLの利点を出来るだけスポイルしないように(=多少はスポイルすることをあきらめつつ)、外付けの認証システムを追加していく、というのが一つ。そうすると、ある程度安定しているQuickMLをそのまま利用しつつ、外付けの認証システムでそれなりにセキュアにすることが出来る。

もう一つは完全に新規に、QuickML的な利便性を持ちグループウェア的なセキュリティ機能を兼ね備えたMLシステムを設計する、というもの。QuickMLの思想だけをもらって、システム的には新規に設計する。

根本的に設計からやり直すとなると、実は妥当なエイリアスメールアドレス管理をするだけでも結構いけるのではないか、という気もしてくるな。

ああ、完全にLAN内でしか通用しないシステムとして運用する手もあるな。MLシステムのアドレスはローカルアドレスだけを振り、外からは絶対にメールが送れない。MLアドレスにメールを送れるのはLAN内の人だけ。LAN外のメールアドレスに対してメールを配送することは可能。完全な社内システムとしてならこれもありかな。

とかいうことを本格的にやっている暇はないので、考えているだけ。

_ 迷惑メールが地球上の全メールの50%を超えた〜米Brightmail調査結果 from INTERNET Watch (13:50)

この数字がどのくらい信用できるのかはさっぱりわからない。「全世界のメールトラフィックのうち約10%をフィルタリングして」いたとしても、その対象がたとえばHotmailのようなスパムだらけのトラフィックを中心にしたものだったとしたら、それは全然妥当なな調査対象とはなりえないし。

ただ、実際問題このまま寛恕としてスパムを受信し続けていたら、確かにトラフィックの50%くらいはスパムになってしまうかもね。「反撃するフィルタ --- Filters That Fight Back」みたいな反撃方法を模索したり、あるいは法的に巨額な罰金で制裁したりとかしないと、このままではスパムが減っていくことはなさそう。「「ペニスを大きくするサプリメント」のスパム広告に注文殺到」みたいに、スパムがある程度の効果を上げていることは本当らしいし。

_ SCOの「証拠コード」にLinux関係者から批判続出 from ZDNet (13:50)

どうやら、SCOは自社のソースコードとLinuxのソースコードの単純な類似性のみを抽出したのであって、そのソースコード部分の細かいライセンスまでは調べていなかったっぽいなー。

ただ、たまたま今回表に出た部分がすでにBSDライセンス(風?)として公開されたものであったとしても、ほかにライセンスに抵触する部分が見つかったら、それはそれで十分SCO的には意味があるのだから、鬼の首を取ったように部分を否定してもしょうがないと思う。

まあ、これだけ隠してきてようやく公表した部分がハズレだった、となると叩きたくなる気持ちは分かるけど。

_ 有料検索は商標侵害? 訴訟に発展の可能性も from ZDNet (13:50)

検索エンジンの検索キーワードとして使われる商標文字列は、商標権で保護されるべきものなのか? 企業(検索エンジン会社)がその文字列の権利を売るとなると、やっぱりそれは商標権の範疇って感じがするな。自社の商標で検索したら、ライバル会社の広告が出る、なんてのは結構きつい。と思いつつも、それは単に比較広告の一種に過ぎないような気もしてくる。

_ ウイルス感染者に対して下される“社会的制裁” from ZDNet (13:50)

この中途半端なショートショート創作)はなんなんだろう?(いろいろつじつまがあわない部分があるよね) こうやって脅すことによってウイルス対策を万全にするよう啓蒙しようってことなのかな? それとも実話を面白くしようとツクリを入れすぎたのか?

_ 互換性問題がZipに破滅をもたらす――? from ZDNet (13:50)

PKZipWinZipのもつ相互互換性のないセキュリティ機能なんて誰も使わないからどうでもいい、って結論だったりしないかな。っつーか、ある意味対応するソフトがないと開けないってのは、セキュリティ対応としては正しい気もするんだけど。

_ PSP、PSX、UMDの真の狙いは?――ソニー・久夛良木氏が解き明かす“点と線” from ZDNet (13:50)

ソニー関連でも、久夛良木さんが考えていること(製品)は、その(今後の戦略的)意図とか(市場や技術に関する)読みとかが感じられて面白いなー。それにひきかえ、

と来たらなー。同じような技術力を背景にしているのに、なんでこうも中途半端なものを出してくるのか。そしてその言い訳も中途半端だし。

どうせなら素直に「場つなぎにプロトタイプ機を発売しちゃいました、てへ」とか言えば面白いのに。


2003-08-22 [長年日記]

_ 「IEが特許侵害」評決、波紋はどこまで? from ZDNet (13:50)

>>Eolasは1999年、MicrosoftIEプラグインアプレットを使えるようにしたことが、同社が保有する特許の侵害にあたるとして訴訟を起こした(1999年2月の記事参照)。シカゴの連邦裁判所は、IEがEolasの知的所有権を侵害しているとの判断を下した。

これは、Webブラウザにプラグインアプレットの機能を取り込んだことが特許に触れる、という話なんだよね。単にプラグインやアプレットという考え方自体が特許に触れるというわけじゃないよね。だとすると、Webブラウザに限らず、アプリケーション種別(メーラーとかワープロとか)ごとにプラグインやアプレットを組み込むことに対する特許が成立しうるってこと? 逆にいうと、プラグインやアプレットを組み込む場合には、その対象アプリケーション種別ごとの特許の存在を気にかけなければならないってこと?

>>特許の仕組みはソフトウェアにおいては壊れているようなものだ

というのはうまい表現だな。単に壊れているだけでなく、壊れているくせに(まるで壊れていることを気にかけずに)動作をし続けているって感じだ。

_ “クローン携帯”、携帯各社は「あり得ない」 from ケータイWatch (13:50)

2003/08/22

>>NTTドコモによると「技術的に不可能。また、現時点でユーザーからの苦情はない」とのこと。またKDDIは、「あり得ない。アナログ方式からデジタル方式へ変更されたことも“クローン携帯”の実現を困難にしている」と説明。さらにJ-フォンも「苦情はゼロではないが、あり得ない事象と判断している。他社も同様と思われるが、ネットワーク上に同一の番号が2つあればすぐわかる」としているほか、ツーカーセルラー東京も「あり得ないという認識。取り沙汰されている話も明確ではない」としている。

これは、具体的にどのキャリアのどの窓口に対して、どのような表現で問い合わせたところ、どういう立場の人間からどういう返事(記者が意訳せず、できるだけ忠実に)が返ってきたかを書かないと、いろいろ誤解の種だよなー。

一般論として「クローン携帯ってあるの?」と聞いたら、携帯キャリアは「技術的にそういうことはありえない(ように作っている)」と答えるだろう。

今回の問題はあくまでも「使った覚えのない課金が請求される」という事象を主張する人たちがいて、その原因として「クローン携帯」という可能性を思いついた人がいるというだけの話であって、ほかにもいろいろな可能性はあり得る。ショッキングな「クローン携帯」なんて言葉に引きずられ(すぎ)ることはない。

2003/12/22

先月はAirH"が手元になかったんで、出先でネットにつなぐ必要があるときには、しょうがなくau携帯のパケット通信を使っていた。固定料金制じゃないんで、とても気を遣ってまめに切断していたんだけど、それでも今月の請求書を見たらパケット料金だけで5000円を超えていて、ちょっとびっくりした(感覚的には使っても2000円くらいのつもりだった)。一瞬本気でクローン携帯(的な課金被害)の可能性を疑ってしまったよ。

クローン携帯って言葉が過剰に流行ると、こういうちょっと予想外のふつうの課金までもがクローン携帯のせいだとか言われてしまったりして、逆に真実(どの程度の異常がどのくらいの割合で起こっているのか)が見えにくくなる気がする。異常を疑うのは、正常な可能性が本当にあり得ない場合だけにしてね、と思った次第。

2004/2/4

ここのコメント欄とかでだらだらやっていた話をきれいにまとめたような記事が出ています。気になってる方々、参考にどうぞ。

_ サーバーとドメインの引っ越し (13:50)

やっぱり家サーバーレンタルサーバーに分散した環境は面倒くさい。家サーバーは物理的な部分が信頼できないし、かといって共用レンタルサーバーではあまり無理が出来ない。あと双方ともに、ごちゃごちゃライブラリとかフレームワークとかを(裏側で)作り続けている関係で、システムの構成がとても煩雑になっていて、とても美しくない(=管理しにくい)。どうせなら何もかもきれいに作り直したい。

なんて考えているうちに、専用サーバーをどこかで借りようかなーという気になってきた。国内だとさくらインターネットの1万円が(GVNがぽしゃった今となっては)最安値なのかな(Bフレッツサーバーとかではもっと安いところもあるけど)。海外まで探せば、さくら程度のところはいろいろ見つかる。

まあ年に10万円ちょっと出す気になれば、そこそこの専用レンタルサーバーが借りれそうだ。年に10万円ってのは安くはないけれども、俺くらいサーバー(ネットワーク)を使い倒している人間にとっては高くもないよな。ただ、俺が使っている帯域が実質どのくらいになるのかはちょっと不安(海外では転送量で課金がかかるのが一般的だし、さくらはあまり転送量が多いと追い出されるらしいし)。

あとちょっと気になるのは、いつの間にかSo-netが自前のダイナミックDNSサービスを開始していた。月額200円でプロバイダ経由の安定したダイナミックDNSが使えるのか。まあdyndns.orgも安定していたと思うけど、IPアドレス変更時の追随性とかはやっぱりプロバイダ直営サービスの方が良さそうだよな。それがかなり安定しているのだったら、やけくそでそっちをメインにしてしまうという手もある。でもそこまでやるなら、光回線に変えたくなるよなー。とか言い出したらIPもらえる契約に変えたくなるよなー。とか言い出したら、専用サーバーをレンタルする以上に金がかかりそうだ。

などと迷い中。年末にはこのサーバー&ドメインの更新時期なんで、ドメインの方まで考えると秋頃には決断して動き出さないと行けないだろうなー。それにしても2ch海外サーバーの情報少なすぎだよ。今のところ、WebHosting Talkhttp://www.webhostingtalk.com/)あたりを見て海外サーバーの情報を物色中。


2003-08-24 [長年日記]

_ 2003F1ハンガリーGP (13:50)

予選1日目

おお、トゥルーリがトップタイムだったよ。って以外は記憶にない。

予選2日目

午前中のフリー走行でファーマンがクラッシュ。最近ストレートを走っていてリアウィングが外れる事故って変に多くないか? 最近のF1のレギュレーションが変なんじゃなかろうか。

ミハエルというかフェラーリの神通力は尽きたか。車の能力はもうウィリアムズが頭一つ抜けて、マクラーレンとフェラーリが並んでいる感じだな。しかもルノーもトータルではフェラーリ、マクラーレンとの差は小さそう。

パニス−トヨタもなかなか速いなー。これは本当に一皮むけたというか、トップ4チームに続くポジションを確実に確保した感じだ。

うげ、アロンソはえー。いや速いのは分かっているんだけど、ここまで速いのはおかしい。いやおかしくはないか。でも、あの速かったウィリアムズよりもコンマ5秒速いってのはすごすぎるよ。それほどハンドリングコースって訳でもないのに。

うげ、マーク・ウェバーが暫定2番手ですか。これはウェバー/ジャガーが速いと考えるべきか、それともコースコンディションの影響の方が大きいと考えるべきか。

うーん、トゥルーリもったいない。ミスらなければ十分にポールをねらえる状況だったのに。

決勝

ラルフはなんなんだ? 異常にスタートが遅かったし、その後の加速も出遅れた以上に遅かった。しかもおまけでスピンまでつけて出だしから最後尾か。

バリチェロはおいしい3番手。ミハエルはなんとか踏みとどまった感じか。モントーヤの前に出られたのは大きいな。

アロンソ出だしから楽な展開になった。さりげなくウェバーもスタート成功しているな。

ああ、バリチェロもったいない。トゥルーリに前に行かれたのはかなりきついかも。

アロンソすげー独走状態。これは本当に圧勝できるかも。

今回はなかなか面白いな。ピットストップで派手に順位が変わる。

なんじゃこりゃ。バリチェロの右リアが突然吹っ飛んだ。バリチェロって本当に、自分が調子のいいときに自分のせいじゃないリタイヤになることが多いよなー。一瞬、モントーヤが前のコーナーあたりでぶつかっていたりしたのかと思っちゃったよ。疑ってごめんね、モントーヤ。もらい事故にならないで良かったね。

アロンソはえーなー。ライコネンが追いつけないってことは、展開のおかげというだけでなく、本当に単体でも速いってことか。

あららら、ミハエルというかフェラーリは、レース戦略における神通力も失ったか。これじゃまるでダメなときのマクラーレンみたいじゃん。

ミハエルが周回遅れか。

というわけで、アロンソ楽勝。ライコネン2位、モントーヤ3位。そして、ミハエルは8位。ドライバーズポイントは、ミハエル、モントーヤ、ライコネンと1ポイント差で3人が並んだ。コンストラクターズポイントはウィリアムズが突き放した。

こうなってくると、モントーヤが一番有利でライコネン、ミハエルが僅差で並ぶ感じかな。大穴でラルフとかアロンソが連勝したりして、一気に70ポイント前後で4人並んで最終戦って語りになったりすると面白いんだけど。


2003-08-25 [長年日記]

_ 家サーバー死亡 (13:50)

この間からやばい状態が続いていた家サーバーが完全死亡fsckしながらだましだまし使っていたんだけど、とうとうクリティカルな部分まで逝ってしまわれた模様。家サーバーを復活させるにしろ、外のサーバーを借りるにしろ、ある程度時間がかかりそうなんで、しばらくは家サーバーに依存したサービス(主にblogmapwikistmania)は止まっています。


2003-08-29 [長年日記]

_ 新サーバー (13:50)

新しいサーバーを借りて、ひとまずそっちでblogmapだけは動かしはじめました。ただ、せっかくサーバーを借りたんで、現状の分散環境はやめて、全面的に新しいサーバーの方にするつもりです。DNS回りから根本的にいじるんで、しばらくの間いろいろ不調になるかもしれません。