2006年03月01日

☆ サービス間のコミュニケーション

あー, あるある。 確かにちょっと考えると DB から直接データもらったほうがよさげに見えるよね。 Web アプリケーションに限らず, サービス間でのやり取りにおいてサービスの内部に直接アタッチするのは筋が悪い。 疎結合というかサービス間のコミュニケーションの問題と考えるべきだろう。 最近はさっぱり聞かなくなったけど「エージェント指向コンピューティング」的なものを思い浮かべればいいかも。

少し前までは「ハック」と称してサービスの内部構造を引きずり出してアタッチするのが「クール」だなんて言われてたけど, セキュリティに過敏な今ではそういうのはだんだん「クール」じゃなくなってきている。 むしろあるサービスについてコミュニケーションのための(もちろん公開された)アクセプタが存在するかどうかというのが凄く大事になってきているんだと思う。

☆ 「信頼」というセールストーク

ウケた。 この記者は意味が分かって書いているのか。 「“脅威”から“信頼”」ってそりゃあ典型的なマッチポンプ広告ですがな。

セキュリティ製品が謳う「信頼」とは何なのか。 今巷に溢れるセキュリティ製品ができることは「信頼できないもの」を排除することだ。 では「信頼できるもの」と「信頼できないもの」の違いは何だろう。 それはセキュリティ製品に組み込まれているものが「信頼できるもの」で, 組み込まれていないその他全てのものは「信頼できないもの」なのだ。

ユーザ企業も消費者もあらゆる説得や広告によりこの奇怪なシステムを信じ込まされる。 製品を導入する企業や製品に組み込まれる消費者だけが「信頼できるもの」で, それ以外の全ての企業や消費者は「信頼できないもの」と刷り込まれるのだ。 そしてみんなが「信頼できるもの」になるためにセキュリティ製品に組み込まれようと(例えば莫大なコストを払って,あるいは個人情報を差し出すなどして)努力をしている。 なんと滑稽なさまであるか。

今の世の中の「信頼」はお金や情報を対価として「与えられる」ものだ。 2004年末の「はてな」の騒動を思い出す人もいるだろう。 当時の「はてな」はユーザを信頼してあげる代わりに個人情報を差し出させようとした。

最近の銀行は「パスワードは時代遅れ」と説得され高価で面倒臭いワンタイムパスワードやト−クンを使った認証を導入してユーザに強要しようとしている。 この製品を導入した銀行だけが「信頼できる」銀行であり, この手順に従ったユーザだけが「信頼できる」ユーザなのだ。 ビッダーズは加盟店舗を対象に X.509 ベース(多分)のクライアント認証システムを導入するそうだ。 しかも笑うことにクライアント認証に必要な電子証明書は店舗が発行するらしい。 ユーザはその電子証明書をインストールして使うとあって, そうなるとつまり公開鍵も秘密鍵も店舗が握っているということになり, 「店舗はその秘密鍵を使ってショッピングし放題」とかツッコむ人などきっと皆無なまま皆ありがたく授けられた鍵でアクセスするのである。

これがセキュリティ製品が謳う「信頼」の実態である。 良いか悪いかではない。 もうそういう世の中になってしまったのだ。

ツッコミはこちら

2006年03月02日

☆ 入門 JSON

遅まきながら JSON の勉強を始めている。

とりあえずここの戯れ言の RSS を JSON 形式で吐いて Javascript で表示してみようかと。 JSON 形式のファイル出力にはまたも yarss.rb を改造した。 Atom っぽいフォーマットで rss.json に出力している。 Javascript のソースはこんな感じかな。

<div id="rsslist">読み込み中...</div>
<script type="text/javascript" src="css/jkl-parsexml.js"></script>
<script type="text/javascript"><!--
  var url = "rss.json";
  var xml = new JKL.ParseXML.JSON(url);
  var data = xml.parse();
  var src = "<ul>";
  for (i = 0; i < data.feed.entry.length; ++i) {
    var item = data.feed.entry[i]
    src += "<li>"
    src += "<a href=\"" + item.link.href + "\">" + item.title + "</a>"
    src += "</li>"
  }
  src += "</ul>";
  document.getElementById("rsslist").innerHTML = src;
// --></script>
<noscript>Javascript を有効にしてください。</noscript>

早速試してみる。

読み込み中...

うんうん, こんな感じ。 データの構文解析には JKL.ParseXML クラスライブラリ を使わせていただいた。 ただし, このライブラリで JSON 形式のファイルを読むとノーチェックで eval() にかけてしまうため, かなり危ない。 「JSON.parse() を使え」とあるが, まともに動かないんだよなぁ。 なんで? (なんでか分かった。スクリプトは修正済み)

ツッコミはこちら

2006年03月03日

☆ 入門 JSON 2

なるほど, 分かった。

{name: "string"} という形式の場合, {"name": "string"} という感じでクォーテーションで囲ってあげないと JSON.parse を通らないようだ (string 型であることを明示する必要があるということかな。理屈はわかる)。 rss.json の出力を修正する。 昨日のフィルタ yarss.rb は新しいものに更新しておいた。

スクリプトは以下のように変更する。 (昨日のスクリプトは変更済み)

<div id="rsslist">読み込み中...</div>
<script type="text/javascript" src="css/jkl-parsexml.js"></script>
<script type="text/javascript" src="css/json.js"></script>
<script type="text/javascript"><!--
  var url = "rss.json";
  var json = new JKL.ParseXML.Text(url);
  var text = json.parse();
  var data = JSON.parse(text);
  var src = "<ul>";
  for (i = 0; i < data.feed.entry.length; ++i) {
    var item = data.feed.entry[i]
    src += "<li>"
    src += "<a href=\"" + item.link.href + "\">" + item.title + "</a>"
    src += "</li>"
  }
  src += "</ul>";
  document.getElementById("rsslist").innerHTML = src;
// --></script>
<noscript>Javascript を有効にしてください。</noscript>

json.js は「JSON in JavaScript」で公開されているものを使用した。

ところで, JKL.ParseXML はソースの読み込みに XMLHttpRequest を使っている。 このメソッドはセキュリティ上の理由から異なるドメインにはアクセスできないようになっている(クロスドメインの制約)。 従って上記の方法では他所のサイトが提供している JSON データを取り込むことができない。 もちろんこれは JKL.ParseXML に限るわけではなく, Javascript で処理を行う際には必ずつきまとう話だ。 これを回避する方法は2つある。 ひとつはサーバ側で JSON データを受けて HTML データにインポートする方法。 もうひとつは

<script type="text/javascript" src="json.js"></script>

のような形で Javascript ソースとして読み込む方法だ。 ただし, 後者の場合は厳密には JSON 形式ではなく Javascript のデータ表現でなければならない。 例えば del.icio.us は JSON 形式でのフィードを提供しているが, クロスドメインの制約を回避するために以下のようなフォーマットになっている。

if(typeof(Delicious) == 'undefined') Delicious = {}; Delicious.posts = [...];

これを厳密に JSON 形式に開くなら以下のようになるはずである。

{ "Delicious" : { "posts" : [...] } }

この方法は便利なのだが, フィードをオブジェクトとして無条件に受け入れてしまうため, かなり危険でもある。 あるいはデータ部分を文字列表現に置き換える方法なら多少マシかもしれない。

var json = "{ \"Delicious\" : { \"posts\" : [...] } }";

JSON はユーザにとって加工しやすく都合のいいフォーマットである。 一方でサービス提供者(サーバ側)にとってはちょっと厄介な存在になるかもしれない。 いろんな意味で注目である。

(追記) 向こうでも書いた記事。

ここよりは多少分かりやすく書いたつもり。

ツッコミはこちら

2006年03月04日

☆ 文章を書くのは難しい

これを読んで新人の頃を思い出した。 ある打ち合わせの議事録を書いて提出したら「君の議事録は論文みたいだな」と言われたことがある。 若気の至りである。

文章を書くのは難しい。

☆ 「MUSES−C君の冒険日誌」

TPS-J も粋なことをする。

「MUSES−C君の冒険日誌」の初出は2001年でまだ打ち上げ前。 だから探査機も「はやぶさ」ではなく「MUSES-C」だし, 目的の小惑星も「イトカワ」ではなく「SF36」なのだ。 無事に地球に還って本当に「伝説」になれるといいね。

無料版のポスターをダウンロードしてみてみたが素晴らしい出来。 A1 版もちょっと欲しいかなぁ。 ちなみにターゲットマーカには私の署名も入ってる。

☆ 日本人総出歯亀状態?

なんだかなぁ。 まさに「覆水盆に帰らず増殖する」状態。 こういうのって昔の日本じゃ「出歯亀」って呼ばれて蔑みの対象だった思うが, 今の日本人のメンタリティでは「全然 OK」なのかねぇ。 これじゃ IPA/ISEC が喉をからして叫ぼうが改善する筈もない。 というわけで, 「やはりシステムで止めるしかない」という話にならざるをえない。

ここに至って, もはや Winny は「リスク」ではなく「ハザード」であると言ってしまおう。

☆ それが未然防止

「ルブラン氏によると、セキュリティバグの50%は「デザイン上の失敗やミス」に起因する。誤って設計されたものを後から手直ししようとしても、多くのコストや手間がかかってしまう。「したがって、初めからセキュリティを組み込んで設計することが重要だ」」

これは典型的な未然防止手法の例。 製造業では既にやってることなんだけどね。

とはいえ, 「デザイン上の失敗やミス」を防ぐのは未然防止手法でできるけど, 「初めからセキュリティを組み込んで設計する」のは容易ではないし徒労に終わることも多い。 何故ならセキュリティ・リスクは時代(つっても今では2,3年のタイムスケールだが)によって変わるからだ。 設計・製造時には予測しなかったリスクが後々発生(暴露?)することはよくある。

H/W (組み込み S/W も含む)は作ったら基本的に修正できないので, 設計時に(試作を積み重ねながら)徹底的に問題点を洗い出そうとする。 しかし S/W はある意味で全てのバージョンが「試作品」なので, 製造業がやっていることをそのまま導入しても無理がある。 故に「初めからセキュリティを組み込んで設計する」よりも, 後から手を加えやすいようなデザインを徹底することが未然防止の観点からは合理的といえる。 これもまた難しいけどね。

☆ Wikipedia で母校を検索

某所で見かけたので調べてみたら私の母校もあった。 びっくり。

あれ? 北校と南校の説明が逆じゃないか? どっちかって言うと北校のほうがリベラルで南校のほうがガチガチの進学校だったような。 補習科があったのも南校だし。 それとも今じゃ逆なのかな。

☆ サイトレーティング・プラグイン

こりゃあええ。 Websense などの普通のレーティング・サービスは妙なカテゴリでよく分からない基準でページを遮断してしまうが (私の管理してるあるページも遮断されていて非常に迷惑), これはセキュリティ上問題があるかどうかだけをチェックし警告を出す(有料バージョンではページに行かないようにも出来るらしい)。 面白いのが Google の検索結果画面との連動。 それぞれのリンクについてチェックしていってチェックマークを表示する。 通常のページの場合は「View Site Details」で詳細ページを開くとリンク先の情報も出てくる。

ツッコミはこちら

2006年03月05日

☆ pro アカウントにしました

地面から虫も涌き出す(ちなみに啓蟄は明日)今日この頃。 私のほうもカメラの虫がうずきはじめる。 いや, いつも持ち歩いてるんだけどね, カメラ。

というわけで, 向後の憂いを絶つために Flickr を pro アカウントにした。 これで枚数の制限はなくなったぞ。 まぁアカウントは pro になっても写真がヘタレなのは変わらないのだが。

もう桜の写真がアップされてるんだよねぇ。 1年経つのは早いものだ。

☆ 宇宙でのごみ処理方法

なるほど。 使用済みの補給船にゴミを詰め込んで大気圏で「焼却」してしまうわけか。 世界一高価な「ごみ箱」だな。

☆ 文書のフォーマットと保存先

私も結城浩さんと同じくテキストエディタで書いてテキスト文書をマスタとして手元(ローカルマシン)に残すようにしている。 少なくとも私文書はそう。

「ワープロ」文書というのは最終的に紙に印刷することを目的としているので, 紙に最終出力されれば作業ファイルは不要になる。 オフィスでもテンプレート・ファイルなどはファイルレベルで管理・維持されるけど, 「最終出力」を終えた文書ファイルは「バックアップ」されるだけで再利用することはあまり考えられていない。 つまりオフィスの文書管理プロセスは最終的に紙で保存することを前提に構築されている。 いつまで経っても「ペーパーレス時代」が来ない筈である。

「今だったら逆に全部Web上に置いておいた方がデータを失わずに済むんじゃないかという気もする」 という話もあるらしいが, 個人的にはこれも疑問。 Web が今のような形で今後とも維持されるとはとても思えないし, 変わっていく過程で過去の資産が破棄されることも十分ありうる。 何より Web 上の文書は最終的に「データベース」として保存される。 つまり Web 上の文書はデータベース・システムのライフサイクルの中でしか生きられないのだ。 現行のデータベース・システムの最たるものが Google なんだけど。

☆ Flickr: Explore!

mixi の某コミュニティで「"Flickr: Explore!"に載ったら報告するトピ」ってのがあって, 「私は関係ないや」と思っていたのだが, 何気に上のツールで自分の ID を入れてみたら一枚だけあったのでビックリ。 前に紹介した広島城の写真である。

どうりで(うちにしては)やたら見に来る人が多いと思ったよ。

ツッコミはこちら

2006年03月06日

☆ 怒涛の買い物

さて予告していた怒涛のコミックス買い, と思っていたのだが予定のものは半分しか買えず予定外のものを買う羽目に。

  • 『8マン・インフィニティ』 1,2,3 七月鏡一・鷹氏隆之 (講談社)[bk1] [bk1] [bk1]
  • 『さくらの境』 2 竹本泉 (メディア・ファクトリー)[bk1]
  • 『よみきり♥もの』 10 竹本泉 (エンターブレイン)[bk1]
  • 『さゆりン』 3 弓長九天 (芳文社)[bk1]
  • 『市立鋳銭司学園高校放送部』 3 ふじもとせい (芳文社)[bk1]

嗚呼, 『8マン』。 手塚治虫さんと石森章太郎さんと桑田二郎さんの絵が大好きだった子供時代。 タイトルだけで買ったとしても誰が責められよう(力説)。 『よみきり♥もの』と『市立鋳銭司学園高校放送部』は最終巻。 『よみきり♥もの』はもうちょっと続いて欲しかったというのが本音だけど。 「飽きっぽい」と噂の竹本泉さんにしては驚異的な継続力だったような気がする。 何にしてもご苦労様でした。

で, 事態はこれで収まらず, 買っちゃったんだよ『デビルサマナー』シリーズ最新版。 だってもう中古が出てるんだもの。 というわけで, これからゲームに忙しくなる予定なので, 何かと滞るかもしれないが悪しからず。

一瞬で諭吉先生が飛んでいった。 給料前にこれは辛い。

☆ ヤフーの Google 化?

なにやら先週末から騒がしい。 巷では「Google化するYahoo!」などと言う人もいるらしい。 ケータイをなめるな! と言いたい。

ケータイくらいガチガチで不自由なデバイス/プラットフォームはない。 個人的な印象ではむしろ

に書かれている内容に近い。 そもそも(本家の Yahoo! はともかく) Yahoo! Japan は「Web 2.0」企業ですらない。 大変化が起こると予測されている方々は「Yahoo! blog」の有様を見たことがあるのだろうか。 あれは「blog 版出会い系サイト」とでも言うべきものだ。 日本版「Yahoo! 360°」は入れないのでどんなものか知らないが, 現状はともかくいずれ「SNS 版出会い系サイト」に堕ちるのは目に見えている (まぁ orkut や gree や mixi も初期には「SNS と出会い系は何が違うの?」などと言われていたので大化けする可能性もあるが,そもそも客層が違うからなぁ)。 そんなところと国内第3位とはいえすっかり落ち目のボーダフォンが組んだところで「大変化」が起きるとはとても思えない。

日本の市場は「ポータル事業」にすっかり満足しきっている。 ユーザもポータルサイトの中で何でも出来てしまうので敢えて外に出る必要はない。 辺境にある自給自足の村のようなものだ。 日本のネットの尻尾は思ったより短いのかもしれない。 ボーダフォンとヤフーとの組み合わせで起こることはボーダフォン・ユーザのヤフー・ポータルへの囲い込みであり, 変化がおきるとすれば現在のケータイ業界の構造を強化する方向に変化すると思う。

だいたいコンピュータ雑誌ですら「Web2.0を日経コンピュータは取り上げるべきか?」なんてなレベルで悩んでるのが日本の現状。 こんな状況でどんな「大変化」が起こるというのか。 そのうちアメリカあたりで「辺境の国ニポンにケータイで自給自足を行う謎の原住民を見た!」なんて特集が組まれるかもしれない。

まぁ私の予測は当たった試しがないが, 万一当たった場合の言質としてここに書いておく。 何事も「当たるも八卦,当たらぬも八卦」。 全ては天数に定められている。

参考:

ツッコミはこちら

2006年03月07日

☆ 「RFIDは「獣の刻印」?」

この手の話は yomoyomo さんのところでもあったな。 「獣の刻印」の連想は日本では既に綺羅さんが指摘されているわけだが, これをキリスト教圏でやられるとシャレじゃすまないような気がする。 やれやれ。

ところで先月号の「CRYPTO-GRAM」の記事によると, 生体認証を取り入れた US-VISIT プログラムでは1,000人の犯罪者を捕らえるのに150億ドルものコストがかかっていることを指摘している。 リスク管理の観点から見ても完全な失敗プロジェクトだろう。

☆ 「戯れ言++」です。

向こうの blog に書いた「入門 JSON」「はてなブックマーク」あたりで思った以上の反応があるようでうれしいのだが, 一応タイトルは「戯れ言」ではなくて「戯れ言++」です。 「++」の部分に私の(それなりに)真面目な姿勢を込めてますのでよろしゅうに。

ブックマークレットのバグかしらん。

ツッコミはこちら

2006年03月08日

☆ 「すべてはここから始まった」

よくできた記事。 ところで

という記事がある。 GnuPG で SHA-256 等のハッシュ関数を使うのは難しくないのだが, この記事によると, DSA を使うには 160 bit のハッシュ値でなければならないらしい。 実際に手元で試してみたら確かに「DSAでは160ビットのハッシュ・アルゴリズムの使用が必要です」というメッセージが出る。 そこで「暗号の話」から DSS の項を見てみると,

「DSA は ElGamal 署名方式を補整して、 L ビットの素数 p を使って 160 ビットのメッセージに 320 ビットの署名を付けるものである。」

とある。 つまり SHA-1 が使えなくなる時点で事実上 DSA も使えなくなってしまうのである。 (ただし DSS には現時点で既に RSA 署名方式も含まれているため, 即「電子署名が出来ない」ということにはならない。 なお「RIPE-MD/160 があるからいいぢゃん」と言う人もいるが, それは「パンがないならお菓子を食べればいいじゃない」と言っているに等しい)

2010年までにはまだしばらくあるが, 各暗号ツール・サービスは SHA-2 系の電子署名システムに移行するためのロードマップを出来るだけ早く示すべきなんじゃないだろうか。 特に OpenPGP。 OpenPGP って鍵への署名(自己署名)なども DSA/SHA-1 なんだよねぇ。

☆ 微妙に評判がいいみたいなので

調子こいて続きを書いてしまいました。

いや, 前回のデータフォーマットの説明が自分でも今ひとつピンと来ていなかったので, より厳密な記述に変えてみた。 次はない, 多分。 もう大体分かったし。

☆ Vine Linux BTS

「usami-k 雑文配信」の記事より。

「Vine Linuxバグトラッキングセンター」が出来ているらしい。 ってか今までなかったのかよ。 Bug Tracking Tool には「影舞」が使われている模様。 RSS で通知してくれるのはいいな。

ツッコミはこちら

2006年03月09日

☆ CCJP シンポジウム

少し前から某所で予告されていたが, 詳細が公開されていたのでご紹介。 新体制 CCJP のお披露目って感じかな。

だうー, なんで年度末のく〇忙しい時期のしかも月曜日になんかやるかなぁ。 東京遠いし。

☆ コンテナ産業

なんでこう似たようなサービスがボコボコできてしまうんだろう。 柳の下に何匹もドジョウがいる筈ないのに。 似たようなサービスをいくら作ってもユーザはつまみ食いを繰り返しながらサービスの間を回遊するだけ。

逆にヘビーユーザは似たようなサービスがいくら出来ようが見向きもしない。 例えば私は del.icio.us で既に 7,600 を超えるアイテムをクリップしている。 こういう人が今更「はてなブックマーク」や他のソーシャルブックマーク・サービスに乗り換えるかどうかは疑問(予備系を用意したりというのはあるだろうけど)。 bloglinesFlickr も同様。 それよりは SuprGlu のようなサービスや

といった仕掛けのほうにより魅力を感じる。 何故そう感じるのか, ネットに数多あるサービスプロバイダ達は真剣に考えたほうがいいんじゃないだろうか。 もはやコンテンツはコンテナに収まりきらなくなっている。 「Web 2.0」が露にしたものは, 「コンテンツ産業」などと呼ばれている業界・企業のやっていることが実は単なる「空箱(コンテナ)」の量産でしかなかったということではないか, などと最近思うようになってきた。 だからコンテンツ産業(=コンテナ産業)は DRM を指向するのだ。

ツッコミはこちら

2006年03月11日

☆ Open Source Software Freeriders of Japan

昨日, 「OSSFJ」に早速入った。

設立の趣旨は素晴らしいが, 分科会には面白そうなものがないので当分静観。 フリーライダーだし(笑)

☆ Google のサポートは最悪らしい

お気の毒。 まぁ Gmail で「超重要なメール」をやりとるするなっちう話なのかもしれないが。 そもそも Google Desktop であれだけの拒絶反応を示しておいて, Gmail では普通に仕事に使ってたりするのが理解できない。

「規約違反になる使い方(代表的なのがGmail Driveなどによるファイル置き場利用)をしてると、警告無しで消されることがあるという書き込み」

が本当だとすれば, Google は常に Gmail 上のやり取りを監視してるってことになるし。

☆ 日本のインターネットはヤバくない

最近言われているインフラのただ乗りがどうのってやつね。 馬鹿馬鹿しい(上の記事が馬鹿馬鹿しいと言う意味じゃないよ,念のため)。 そういや10年くらい前にも似たような議論があったな。 みんながダイアルアップ等で「インターネット」に入ってきて HTTP がトラフィックの多くを占めるようになり, 当時の網間の容量が危なくなってきたときだ。 当時「ホームページ」で情報発信する人たちは帯域を食いつぶす「ごくつぶし」呼ばわれされたものである。 信じられないだろう。 でもこれは本当の話だ。 だから今回もどうってことはない。

国外と比較するのも意味がない。 何故なら国外各国の網と日本の網は競争状態にあるわけではないからだ(政治的にはあるかもしれんが)。 それぞれの国にはそれぞれのお国事情がある。 それを無視してアメリカや韓国と比べるのは筋違いだ。 特に日本の網は今でもほぼ NTT の独占状態で, 多くの接続業者はそれにぶら下がっている格好になっている。

網には「網間」と「ユーザ・網インタフェース」の2種類がある。 両者は互いに競うようにリソースを増強しつづけた。 ここ何年かは ADSL や 光接続のおかげで「ユーザ・網インタフェース」のリソースは驚くほど充実してきた。 現在はそれに「網間」が追いついていないだけである。 もともとは NTT (や他の接続業者)自身がまいた種なんだから自分達で何とかするのが筋。 それをコンテンツ・サービスの発信者に追加料金を払わせようなどとはずうずうしい。 それって要するに接続料金等を上げてユーザが離れるのが怖いので, サービスの発信者のせいにして連中から銭を搾り取ったほうが手っ取り早い, とかそういう発想だよな。 実にあくどい。

だいたい「ネットでビデオオンデマンド」は NTT 自身が INS サービス(ISDN のこと)で夢見てたことじゃないか。 私は当時の INS セミナーに参加してたから知ってるぞ。 それを他所が実現したからってひがむなよ。

(おおっ今日は口が悪い)

☆ 天文ファンこそ写真共有 SNS をもっと活用すべき

Flickr で最近お気に入りなのは「Astrophotography」「Astronomy」の両グループ。 いや, 両者の写真は結構カブるのでどちらかでもいいのかもしれないが。

天文ファンで写真を撮る人ほど Flickr のような写真共有 SNS は便利だと思うけどね。 既存サービスの敷居が高いのなら AstroArts あたりを脅してそういうサービスを作らせてもいいんじゃないかな。 AstroArts で公開されている写真はどれも素晴らしいと思うのだが, なんていうか, ただ「展示」してあるだけでそこから先の展開がないんだよね。 私なんかは今や機材も足もないので他人の写真を見てため息をつくだけだが, せっかく撮って公開しているのに凄くもったいないような気がする。

まぁ私がそう思うだけで彼等にとってはどうでもいいことなのかもしれないが。

ツッコミはこちら

2006年03月12日

☆ e-Japan は「無償の奉仕」が支えてる?

まず「7万台の私物」というのに呆れた。 つまり, パソコン経費を1台あたり1万円としても, 億をゆうに超えるリソースを無償で供出させていることになる。 ノーズコーンがうまく機能したくらいで浮かれてないでちゃんと足元を見ろよ。

「正社員の3分の1が自宅でサービス残業」はちょっと微妙な感じ。 どこまでを「サービス残業」と見なすかにもよるんだけど。 自分のスキルが足りないうちは「うち帰ってでも何とかする」ってのはよくある話だし。 もっとも,そこにつけこんで出来ないスケジュールを強要するバカ管理職もいるから話がややこしい。 さらに「うち帰ってでも何とかする」から「でも何とか」が抜けて常態となり, 自分が今やっている仕事が社外秘で機密情報を扱っているという意識ゼロなバカ従業員も多くなってきたというのも問題をややこしくしている。 まぁぶっちゃけて言うと組織として破綻しているわけですな。 手前がぶっ壊れてるのに Winny のせいにするなと言いたい。 (念のために言うと Winny が問題ないといっているわけではない。 日本のいくつかの企業・組織のセキュリティ意識は Winny 以下だということだ)

週末は久しぶりに昼のワイドショウなんか見たけど, ダメすぎ。 日本のマスコミやお役人(学校も含む)等はそうやら Winny を「鬼ごっこ」の鬼に決めたようである。 バカだなぁ。 個人情報や機密情報を狙う malware なんか世界中に掃いて捨てるほどある。 Winny 自身は単なる「感染経路」(のひとつ)に過ぎない。 Winny 以外にもファイル共有型の P2P サービスはいくらでもあるし, ファイル共有ソフトなんかなくてもメールや IM や場合によっては Web ブラウザからだってやられるときはやられるのだ。 それらを全部嫌ってネットから切り離すことが「セキュリティ」だというのなら, それはもう「日本(人)はネットすらまともに扱えないおバカの軍団」だと世界中に吹聴して回っているようなものだ。 それで知財戦略がどうのとか言ってるんだからチャンチャラおかしい。

それが e-Japan (改め u-Japan)の実態というわけだ。 こんな連中にユビキタスなんか与えたらろくなことになりませんよ > 某教授。

☆ ケータイのメールで充分!

おおっ, こういう話は大好物だ。

友人との連絡はケータイ・メールか BBS。 音声は受けることはあってもかけることはまずない(待ち合わせのときくらい?)。 ケータイ・メールの利点はケータイで受けれることだ。 ある場所(家とかパソコンとか)で受けるのではなく「私」が受ける。 そんな身体感覚がケータイにはある(逆に仕事がらみは「私」にかかって欲しくないので原則としてケータイでは受けない)。 その点で今の IM や VoIP 等のコミュニケーション・ツールは圧倒的に不利だ。

ケータイのおかげでやっと固定電話から解放され, 更にケータイ・メールのおかげで「着呼してるから出なくちゃ」という強迫観念からも解放された。 私の知り合いでケータイのメールアドレスしか知らない人は結構いる(必要ないから)。 なのになんで今更パソコンに拘束されなきゃいけないの。 惜しいのはお金じゃない。 時間と空間である。

というわけで, VoIP がケータイ(PDA じゃないよ)に組み込まれるようになるまで, 私がその手のツールに興味が涌くことはないだろう。

ツッコミはこちら

2006年03月13日

☆ これが噂の POTION

試しに噂の POTION を買ってみた。

飲んでみたけど... 不味い。 なんか香草が入ってるみたいだが, これならアブサンのほうがマシである。

☆ 追記

ええっと, 唐突に... 見えるかな, やっぱり。 もう少しリンクを(新しいのも含めて)追加してみるか。

セキュリティのためにインターネットから切断する例はある。 例えば防衛関係, 例えば金融ネットワーク, 例えば医療関係, 等等だ。 防衛関係の情報管理はそれほど詳しくないが, 防衛関係の場合は外部からの隔離が優先されるのでネットからの切断が合理的である場合もあろう。 しかし金融関係や医療関係はそういうわけにもいかなくなりつつある。

大事なことは内と外を分ける「セグメント」をどう設計するか, そしてセグメント間のチェックイン・チェックアウトをどのように実装するか(もちろんこれはネットだけの問題に限らない), である。 それがセキュリティ設計である。 どんなシステムでも必ず内と外をつなぐ接点がある。 外部から完全に隔離されたシステムは存在し得ない。 ネットから切り離すということはネット以外の部分で接点を持つということだ。 その接点におけるセキュリティ設計は果たして大丈夫なのか。 Winny 絡みの暴露を見るとむしろネット以外の経路による漏洩(つまりチェックイン・チェックアウトが機能していない)としか見えない。 Winny は経路の最後のノード(のひとつ)に過ぎない。

この辺を考えずに闇雲に Winny を禁止したりネットから切り離して安心感を得ようとしても, 他に(チェックイン・チェックアウト手続きを経ずに)セグメントを越える手段が存在するならまるで的外れな対策だし無駄なコストをかけていることになる。 自衛隊も警察も島根県教委もそこをちゃんと押さえていますか(いや,押さえていないだろう)ということである。 まぁ今のところこのダメダメリストに住基ネットが含まれないのが奇跡というか時間の問題というか。

そしてこのように日本に蔓延するネットワーク設計あるいはセキュリティ設計のダメさ加減が e-Japan の成果だというのは別に唐突でもなんでもないと思う。 私は日本にも NSA や BSI のような機関が必要だと思っている。 今のところ(セキュリティ関連のアドバイスに限れば) IPA がそれに近い位置にいると思われるが縦割り行政のおかげかあまり影響力をもっていないように見える (そもそも IPA は諜報機関じゃないしね)。 結局は e-Japan (およびその後継としての u-Japan)の実態は日本のお家芸である「土建屋行政」の延長であり, それも割れ鍋のごとき箱(コンテナ)の量産でしかなかったというわけだ。

☆ 記念すべき 7,777 番目のブックマーク

「ひろゆき氏「市民メディアはマスコミに勝てない」」だった。 ちなみに IT 戦士・岡田有花さんの署名記事。

そういえば「はてなワンワンワールドとTropy」という記事があって, (良い悪いは別として)実に日本人っぽい発想だなぁ, と思ってしまった。 いや, 日本人らしいというか「はてな」市民らしいと言うべきなのか。

ちなみに私のところのはてなブックマークのお気に入りは何故か機能しない。 Bloglines で引っ掛けているのだがさっぱり更新されないので普段は存在すら忘れている。 del.icio.us の inbox は重宝しているが, ノイズが多いので情報源としてはあまり重要視していない。 まぁノイズの中に稀に面白い記事(特に海外の記事)があるので無視できないのだが。

私はソーシャル・ブックマークを忘れるために利用している。 ブックマークすることで私はその記事を忘れ他のことに専念できる。 そういう意味で私にとってソーシャル・ブックマークは拡張された脳の一部のようになっている。

☆ 再勉強

JSON 弄ってて痛感したのは私の Javascript の知識とスキルは古くて偏っているということだった。 というわけで反省してこの本を買ってみる。

  • 『JavaScript 第3版』 David Flanagan 著,村上列 監訳,安藤進・垰井正雄 訳 (オライリー・ジャパン)[bk1]

生涯勉強だよ。

ツッコミはこちら

2006年03月14日

☆ ビビった

朝起きたらルータが騒いでいる。 チェックしてみると「ID かパスワードが違う」とかなんとか抜かしやがる。

一瞬顔が青ざめたが, とりあえずマシンをひとつづつ落として状況をチェック。 すると突然通信が回復。 もしやと思って ISP のページを見に行くとやはり早朝からメンテで接続を切っていたらしい。 もう勘弁してよ。 そんな大事な話はメールでもよこせっつうの。

☆ 手前も一年岩国で暮らしてみやがれ!

と言いたい気分。

まぁ今まで住民の口を銭で塞ぐよな真似をしてきたんだから当然の結果なのだが, それをあんなコメントするとはさすが「毅然として何もしない」小泉首相。 岩国にしろ沖縄にしろ現状を分かって言っているのなら相当あくどい。 「(住民投票の結果が在日アメリカ軍の再編計画全体に)影響がないよう努力していく」 の括弧の中身はきっと 「(防衛利権の確保に)影響がないよう努力していく」 の間違いに違いない。

「防衛は国の専権事項」だというのなら, 同じ台詞をアメリカにも言ってみろよ。 話はそれからだ。

☆ PSE 法その後

驚いた。 今回の措置に対して世間の評価は分からないが, この時期にこの内容は結構画期的なような気がする。 署名の効果があったのか, 経産省が凄いのか。

☆ 光害 (Light Pollution)

天文学の立場から主張してもなかなか理解してもらえない。 日本は特に。 環境問題(夜間の照明が近所の生態系を狂わすとか照明を上に向けることによるエネルギーのロスとか)としてなら説得力があるかなぁ... 例えば 「Astronomy Picture of the Day」に夜の地表を世界地図風に展開したものがあるけど, あれを見て「綺麗」と言う神経はどうよ, という話だ。 あの明るく見える部分は実は呆れるほどのエネルギーの無駄遣いの結果だという想像力が働くかどうか。

参考:

ツッコミはこちら

2006年03月18日

☆ Keep alive

職場の人から「最近更新ないみたいだけど体調大丈夫?」ときかれる。 ありゃりゃ, そんな風にチェックされているとは。

出張や長めの休暇以外で更新が滞るときは, 大抵呑んだくれてるかゲームにハマってるかのどちらかです。 まぁホントに体調が悪いときもありますが。

春は美味しいものがたくさんあるからね。 タコでしょう。 竹の子とか山菜でしょう。 新たまねぎとか春キャベツとかもあるし, トマトも美味しくなる。 ついつい呑んだくれてしまうのよ。

ちなみに昨夜は勤務先(職場ではない)の歓送迎会だった。 (幸か不幸か)入ったばかりでいきなり長期出張らしい。 今の勤務先は一応職安に求人は出してるけど, 基本的には人脈を使ってのスカウト制をとっている。 件の子は LAMP 使いでかつ Java も操れるそうだ。 頑張れよ!

☆ どうしよ

CCJP シンポジウム。 行ってみたかったんだけど, 結局止めることにした。 そういや2年くらい東京方面に行ってない。

いや, 先日マネージャに「確かアセンブラ得意だったよね」と言われちゃったのよ。 アセンブラが必要なプロジェクトといえばアレしかない(ちなみにフルアセンブラ)。 ちうわけで, やっぱり年度末は忙しいのであった。

☆ HashClash

そのうち誰かやるだろうと思っていたが, 遂に BOINC ベースでの暗号関係の分散プロジェクトが登場したようだ。 ちなみに今アタッチしようとしたが新規参加は受け付けてないとかどうとか。 ちょっとガッカリ。 暗号関係のプロジェクトは力業も多いので BOINC に乗せるのは結構有効だと思うけどね。 RSA クラックとか素数探索とかさ。 そゆのもっと出ないかな。

BOINC ベースで分散コンピューティングを行う参加者側のメリットは, 複数のプロジェクトを乗せてスケジューリングできる点だ。 あるプロジェクトがメンテナンスモードになってもその時間を他のプロジェクトに割り振れるというのは意外に便利である。 これはプロジェクト側にとってもメリットになる筈。 LHC@home は普段は休止状態になっていて, 散発的に Task が与えられる。 LHC@home にのみ参加している状態でこれをやられるとかなり苛つくと思うが, 実際には BOINC 上で他のプロジェクトも稼動しているのであまりストレスにならない。

そしてプロジェクト側のもうひとつのメリットとしては, 短期のプロジェクトが組みやすいことがある。 Climateprediction.net が既に実践しているが, メインの長期プロジェクトとは別に短期のサブプロジェクトをいくつか立ち上げている。 例えば BBC といっしょにやっていてあちらでは話題沸騰中(?)の「BBC Climate Change Experiment」とか, 最近登場した「Seasonal Attribution Project」とかである。 もともと Climateprediction.net は計算機リソースへの負荷が高いプロジェクトなので, こうやって小分けにすることでプロジェクトへの参加機会を上げようとしているのだと思う。

☆ 確かに Winny はリスクだがハザードではない

もう, ダメすぎ。 特に安倍官房長官による内閣官房情報セキュリティセンター(NISC)の声明。 今の Winny は確かにリスキーだ(私だって Winny は入れてないが結構ビクビクだ)。 だから緊急避難的な措置として Winny を外すことは効果があると思われる。 しかしそれはあくまで「緊急避難」であることをきちんと説明しなければならない。 まず緊急措置を施しておいて, その後しっかりとした「再発防止」あるいは「未然防止」の対策を打つ。 これが正しいインシデント・レスポンスである。 安倍官房長官の発言はそういうものを全てすっ飛ばして「Winny がなければ安全」みたいなミスリーディングを生みかねない。 (マスコミがそういう風に誘導しているのかもしれないが同じことだ)

今の「Winny 騒動」を見るとかつての「BSE 騒動」を彷彿とさせる薄ら寒いものを感じるのは私だけだろうか。 つまり今や Winny は「リスク」ではなく完全に「ハザード」と見なされている。 それが Winny を削除するウイルス対策ソフトの登場であり, Winny トラフィックの切断であり, NISC の声明なのである。 (もっともぷららの措置はありだと思うけどね。 何故かというと「ぷららを選択しない」という選択肢がありうるから。 ユーザが複数の選択肢を取りうるうちは「切断する」というのもありだと思う。 ただし他の接続業者が「右に習え」するようなら危険)

もうひとつダメだと思うのは, 「再発防止」とか「未然防止」がどういうものなのか誰も分かっていないんじゃないかと思われる点だ。 まぁ他人のことは言えないが, どういうわけか日本人は「再発防止」とか「未然防止」とかいう話になるととたんに軍隊系・体育会系になる。 「従業員を再教育する」とか「周知徹底する」とか言い出す。 挙句の果てに「Winnyで機密情報を流した公務員は懲戒免職,懲役刑に処せ」とかいう話になる。 機密保持という観点で破綻している組織において, その場の一個人を処分したところで何も改善しない。 第二第三者の違反者が現れるだけだ。

目の前の現象に踊らされるのではなく, 「何故そうなったのか」を深く考察していくことによってシステムの不備・欠陥を顕在させていかなければならない。 内部統制というのはそういうことである。 「教育(ってか洗脳)の徹底」によって従業員をコントロールしていくのではなく, そもそも機密漏洩ができないシステムを構築していく。 「環境管理型権力の最適化(リファクタリング)」と言ってもいい。 それにはバランスのとれたリスク・マネジメント能力が必要なのだが, そこで何故か体育会系な発想に陥ってしまうのは, 管理職(官僚・公務員だって国民の管理職だ)あるいは経営者(政治家だって国の経営者だ)としての資質が不足していると言わざるを得ない。 おそらくそれが「Winny 騒動」の本質なのだろう。

☆ 法律は難しい

ツッコミにて。

来週にも「共謀罪」と「ネット規制法」が国会で成立しそうです。成立しちゃったら何も反対できなくなってしまうので、こっちの方が優先度が高いと思います。

ということらしいので。 「ネット規制法」というのは「不正指令電磁的記録に関する罪」のことかな(ネット使用を免許制にしようとかあの辺の話じゃないよね)。 多分そうだろうということで, リンクを羅列してみる。

共謀罪は「あんな変なものが通るわけない」と高をくくっていたのでちょっとビックリ。

もうひとつのほうは正直よく分からない。 私のエンジニアとしての心境としては「作成が罪になるのはおかしい」と思うが, その理由は多分高木浩光さんの書かれているものとはちょっと違うような気がする。 ソフトを「作る」ことと「使う」ことは分けて論じられるべきだ。 ソフトを作る時点ではそのリスクは予想しがたい。 Winny なんてのはその典型だ。 ソフトウェアというのはそれを利用する環境およびユーザの性質・規模が変わればどうにでも転ぶものなので, それを作者のせいにされるのは理不尽に見えるし, もっといえばエンジニアの存在そのものに対する規制とも受け取れてしまう。 例えば Windows にセキュリティ上のリスクが高い ActiveX を組み込んだ Microsoft は「クロ」なのか。 (実際には「クロ」にならないと思うが。 企業にとってあるソフトウェアに悪意がないことを証明するのはさして難しくないだろうし)

しかし社会的にそれが要求されているのだとすれば従うほかないのか?

話は変わるが PSE 法は一向に収束しなさそうですな。

個人的には中古業者をここまで保護する必要があるのか疑問に感じてしまう。 しかもそれを「文化破壊」とまで言ってしまうのはどうなのって感じ。 それは「Mac を機械ってゆーな」というのと大して変わらないレベルのように思うのだが。 中古業者がいないと維持できない「文化」の存在価値って何?

...法律は難しい。

ツッコミはこちら

2006年03月19日

☆ 飲み疲れ

さすがに疲れた。 しばらくはおとなしくしていよう。

昨日は第二回お好み焼き大会だった。 幹事さんが前回で味をしめたらしい。 私は既に胃がお疲れモードだったのであまり食べれなくて残念。

その後ふつうに飲み。 そういや何故か(昔の)西遊記の話になって, 普通子供だったら如意棒とかキント雲とか欲しがると思うんだけど(私だけ?), 「子供の頃は孫悟空の頭の輪っか(緊箍児?金剛圏?)が欲しかった」という人がいて, 「さすがド S の人は違う」と思ったものだった。

☆ 「代金引換を悪用した詐欺」

なんてのがあるらしい。

いろいろ考えるなぁ, お気をつけを。

☆ こういう日は

今日は何もやる気が起きない。 こういうときは非生産的なことをするチャンスである。

というわけで, かねてから計画していた 「del.icio.us のブックマークを「はてなブックマーク」にインポートする」 作業を行った。 作業には「ソーシャルブックマーク管理ツール」を使用。 初期バージョンは使い物にならなかったが今リリースされている 0.07a では遅いながらもなんとか動作した (まぁ8,000アイテム近くあるからな)。 公開されている tsupo さんに感謝。

ツールに関して難を挙げるとすると以下の3つ。

  • エクスポート元とインポート先で登録が逆順になる。
  • ブックマークする際にタグ候補を表示してくれるのは嬉しいが自分が既に登録しているタグを一覧表示して欲しい。その際どのサービスをベースにするか選べるようにして欲しい(「はてなブックマーク」は語句を勝手にタグにしてしまうので嫌い)
  • ファイルにエクスポートする際は OPML ではなく XBEL 形式にして欲しい。もしくはどちらかを選べるようにして欲しい。

というわけで日常的に使うにはまだまだだが, 1ヶ月くらいの単位でのバッチ処理なら問題なさそうなのでこれからも使わせていただこうと思う。

ちなみに以前も書いたが, XBEL ならブラウザと連携しやすくなるしサービス間の互換性もとりやすくなるので, 是非各ブックマーク・サービスは導入して欲しい。 XBEL にはタグの概念はないが separator 要素で代用できるように思えるが...

で, 「はてなブックマーク」にも難がある。

  • タイトルに [ ] があると勝手にタグ扱いするのは止めて欲しい。やるならコメント内のみでやればいい。
  • 「+」記号を無視するのは止めて欲しい。タイトルでもタグでも「+」記号が無視される。何故そうなるのかは大体想像がつくが,直さないのは怠慢。
  • タグの編集機能を作って欲しい。具体的にはリネーム(タグの分割も含む)とマージ。(あぁ,コメントに埋め込む形式だから無理か)
  • 登録データのエクスポート機能をつけて欲しい。XBEL が嬉しいが, del.icio.us のように Netscape の Bookmark ファイル形式でもいい。

「はてな」のサービスは全般的にデリカシーに欠ける部分があって, そこが物凄く苛々するのだが, 一向に改善する気配がない。 いまだにフッタに「All rights reserved」って表示してるユーザページもあるし, terms of service とか privacy policy とか copyright policy とか作ってリンクを張っておけば済む話なのにそれすらやらない。 考えてみたら2004年末から何も進歩してない。 実験サービスを作ってエンジニア自ら楽しむのは結構だが, それもきちんと足元を固めた上での話だ。 今の状況じゃ上述のような問題・要望があっても言う気にならない。

ツッコミはこちら

2006年03月20日

☆ タグの置換・分割

ツッコミで教えていただきました。 感謝です。

って裏技なのか? もしやと思ってコメント欄に「[foobar] foobar」とやって「foo][bar」に置換したら, ちゃんと「[foo][bar] foobar」となっていた。 まっさすがにそこを疑うのは失礼か。

☆ JavaScript 入門

前回 「私の Javascript の知識とスキルは古くて偏っている」 と書いたが, どうも「古くて偏っている」のではなく単に忘れていただけだったようだ。

『JavaScript 第3版』[bk1] を読み進めていくうちにだんだん思い出してきた (同時に Web アプリケーションをやってた頃の悪夢も蘇ってきた)。 忘れないうちに覚え書きの形で記事にしていこうと思う。

といっても, あくまで余暇なので飽きたらやめるかもしれないけど。 そうなったらごめんなさい。

☆ "Lambda expressions and closures for C++"

「#3」の記事より。

C++ にラムダ関数とクロージャかぁ...

☆ 久しぶりにきたねぇ

(新聞系マスコミのページにはリンクしたくないので)

読売は何を今更こんなアホな記事を書いてるんだ。 こんなのは既に3年前に指摘されてる話だろが。 日本のスパイ衛星がダメダメなのは既に周知のことだと思ってたが, そうではないらしい。 諜報機関のない国がスパイ衛星打ち上げてどうするねん。

(追記)

ツッコミはこちら

2006年03月23日

☆ イッキ書き

「C/C++ プログラマのための JavaScript 入門」, 型変換のところまでイッキ書き。

少し頭の中が整理できた。 これでようやくこれらのことを頭から追い出して他のことができる。

ツッコミはこちら

2006年03月24日

☆ 誰が鬼で誰が桃太郎かなんて

おおっ, 素晴らしい文章。

しかし実際問題として大手企業なんかでは既にネットの制限は始まっている。 IM や VoIP はもちろん通らないし(TV/電話会議は既に既存のアプリケーションがあるので今更 skype なんて不要), メールや Web 閲覧も監視されている。 HTTP プロキシは認証をパスしないと通れないし, 通れたとしても Websense のせいで神浦元彰さんのサイトなんかヤバいサイト扱いで見れやしない。 各自の PC はアクセス制限がかけられていて, アプリケーションをインストールするのにもいちいち IT 部門に申請する必要がある。 まぁそこまでやっても私物 PC を持ち込まれて別回線でネットにつながれたらアウトだけどね。

私は(昔はともかく今は)ここ↑までするのが組織として当たり前だと思っているから, やっていないところは逆に「何やっとんじゃい」って思ってしまう。 でもそれはあくまでも組織としての振る舞いだ。 同じ組織でも大手と中小じゃレベルが違うし, 家庭内 LAN だと更に違うレベルで考えないといけない。 (家庭内 LAN なら Winny なんかよりネットで外から遠隔操作できる家電製品のほうがよっぽど危ないと思うけどね)

先ほど紹介した記事にあるように

「ファイル共有アプリケーションを使っていない人に他人事感を与えてしまうこと」

がとても危ない。 みんな茶の間で TV のワイドショウという「桃太郎の鬼退治」を楽しんでいるのだ。 しかもそれに NISC が一枚かんでしまっているというダメッぷり。 安倍官房長官がああいう声明を出すこと自体が如何に彼がこの件に関して興味がないかを如実に物語ってしまっている。 でもそれが日本の「セキュリティ政策」の実情なんだよねぇ。

☆ 「放送と融合するのはむしろモバイル」

「放送と融合するのはむしろモバイル」というのは名言だな。 ケータイというのはインターネットから最も離れたところにあるネットだ。 ケータイは客を囲い込み言いなりに従わせるのに絶好の手段だ。

私は私の周辺でケータイから Google で検索する人を見たことがない。 ケータイのネットでは Google や他のフィード・サービスのような玉石混交をより分けるシステムは存在しないか, 存在しても機能していない。 その代わりに機能しているのはケータイ各社が提供する専用のポータルサイトである。 つまりケータイのポータルページから探せないサイトは存在しないも同然なのだ。 そこにはロングテールもなければ集団知もない。 放送が融合したがっているのはそういう「古き良き」 Controllable なネットなのである。 ヤフー・ジャパンが欲しがっているのも同じものだ。 ヤフー・ジャパンが求めているのはケータイのポータルページにヤフー・ジャパンのサービスを乗せることである。

日本に「ケータイ」が存在する限り「Web 2.0」が普及する日は来ないと思う。

(追記)

「「ケータイ」の国と「Web 2.0」の国が並立して、どちらを「リアル」と呼ぶのか、その取り合いがもう始まっているのかもしれない。」

さすが essa さんはうまいことおっしゃる。 でもそれが本当に「取り合い」ならいいことなのかも。 だって「取り合い」なら競争になる可能性があるもの。 たとえ今はアンフェアに見えても競争になる可能性があるなら悪いことではない。

☆ ツッコミをいただきました

「No wave, No life」の記事より。 「プロローグ」のコメント欄で答えてます。

「WSHでやろうとしているところが凄いな」 と書かれていて「Win版インタラクティブJavaScript」を見てみたけど, これも WSH 上のツールなんだけど??? FireFox の JavaScript コンソールってどうやるのかな。 「Javascript:」ってやるんだけど変なウィンドウが出るだけ。

調査をするときってみんなそうだと思うんだけど, 一応の計画を立てて調査の結果を残しながらやるもんだよね。 ファイルで Javascript ソースを起こして WSH で検証するこのスタイルはまさに打ってつけ。 ちっとも面倒なんかじゃない。 むしろ「Win版インタラクティブJavaScript」のほうが面倒臭い。 だって結果をファイルか何かに(コピー&ペーストでもして)書き残さないといけないじゃん。 私のマシンの中にはあのたった5つの記事を書くために既に十個ものテストコードを書いている。 そして WSH さえあればいつでも同じ結果を再現できる。 これが重要。

私が今回書いているのはあくまで余暇なので調査も全然ぬるい。 多分真面目に細かく検証するなら JavaScript のような言語でも1人月以上かかるだろう。 その間に膨大なテストプログラムを書き, それはいつでも再現できる状態になっている。 調査が終わってそれらの資料が残っていれば後で何か聞かれても即座に答えることができる。

WSH を使うのはもうひとつ理由があって, それは本文中にも書いているのだが, 「JavaScript は Web ブラウザのマクロ言語じゃない」と強調したかった。 実際ある Web アプリケーションのプロジェクトに加わっているときも(Windows プラットフォームだったので) JScript や VBScript のツールを山ほど書かせられた。 修羅場のときは検証用のツールとか配布用のバッチファイルとか何かしら毎日書かせられる日々だったような気がする(あまり思い出したくないが)。

とはいえ WSH を有効にするのは少々リスキーなので万人にはお薦めしない。 悪しからず。

ツッコミはこちら

2006年03月25日

☆ もう「Winny がない世界」には戻れない

武田圭史さんの考えは分からなくもないけど, どうしても違和感がつきまとってしまう。

今回の大量の情報漏洩に関する一連の報道や声明は結果的に Winny の認知度を上げ普及率アップに貢献している。 「winnyに暴かれたNシステムの一端」みたいな皮肉を書く人もいる。 更に人によっては Winny を必要悪と考える人もいるかもしれない。 どうやっても「Winny がない世界」には戻れない。

これは他のコンピュータ・ウイルスやフィッシングなんかでも同じなのだが, 所詮存在自体を否定することはできないのだから, 今ある状況はある程度受け入れつつどうやってリスクを引き下げるかという方向で考えないと, 事態はどんどん非現実的な方向へシフトしてしまう。 例えば BSE (による責任追及)を恐れるあまり他国にも「全頭検査」を強要した某国政府のように。

「マシン内の機密情報を詐取し Web の掲示板や P2P ネットワークにさらす」という手法はもはや一般に認知されてしまった。 今は愉快犯レベルだろうが, いずれもっと凶悪な犯罪行為に発展することは目に見えている。 例えば情報をさらす際に暗号化を施し「金を払わないと復号鍵も公開する」なんて脅しをかける輩も現れるだろうし, そういうのが流行れば何もなくても脅しをかける spam も出回るかもしれない。 なによりそういう「機能」が今あるボット・ネットワークに組み込まれたら? 今の Winny 騒動などメじゃないくらいの大混乱が起きる可能性もある。

「Winny がなければ安全」とのたまう人たちはそこまで考えて発言してますか(いや考えていない【反語】), ということだ。

☆ "Chinese gold farmers"

オンラインゲームはやらんからなぁ。 恐るべし中国。 中国の怖いところは何でもとりあえず人海戦術でできてしまうところだよなぁ。 「甘栗むきました」も中国の工場で手作業でひとつひとつむいてるらしいし。

ツッコミはこちら

2006年03月26日

☆ SETI@home に愛の手を

既に /.-J でも記事になっているので知っている人も多いかもしれませんが, うちでも記事を書いてみました。

寄付は10ドルからOK。 もし SETI@home 参加者で我こそはという方がいらっしゃいましたら是非。

☆ Public Computing

Club-HUAA サイト作成のために今更古い記事を読み漁っている。

BOINC の目標はインターネットそのものをひとつのコンピュータ・リソースとみなして, その上にオペレーティング・システムを構築することなんだよね(個々のリソースを強制的に奪うのではなく,あくまで参加型であることがポイント)。 そういう観点で見れば巷にある P2P 型ファイル交換などはその要素技術に過ぎない。 今の P2P 型のファイル交換サービスが危なっかしく見えるのは, システムとして全体をコントロールする手段がないからかもしれない。 ネット上のリソースを統御する仕組みがなく個々のハッカーがプリミティブな実装を行うから, 問題が発生したときのインパクトが大きくなる。 そうでなくとも参加ユーザの規範に依存しているシステムは(ユーザの性格が変われば)簡単に破綻するものである。

まっ, それはともかく, 昨今のすさんだ日本のネットの状況を憂う人は上述の記事を読んでみるといいかもしれない。

☆ お買い物

やっとあの作品が買えた。

  • 『超人ロック 冬の虹』 4 聖悠紀 (少年画報社)[bk1]
  • 『超人ロック 荒野の騎士』 聖悠紀 (ビブロス)[bk1]
  • 『特ダネ三面キャプターズ』 1 海藍 (芳文社)[bk1]

『特ダネ三面キャプターズ』 1巻って。 それって2巻以降もあるってことなのか? 『トリコロ』は掲載雑誌を変えて継続してるという噂も聞いたけど。 あぁ「電撃大王」か。

今月末も怒涛の新刊ラッシュがある。

ツッコミはこちら

2006年03月27日

☆ Phishing メール

Flickr へ送金するために PayPal アカウントを作成したのだが, その直後からやたらと Phishing メールが舞い込むようになってきた。

今日も自宅に帰ったら「Unauthorized access to your PayPal account !」というメールが来ていてギョッとなる。 どうやらアカウント登録が完了していないから指定の URL にアクセスして完了しろというもの。 でも記載されている URL のドメイン名は paypal.com.updatedatabase.info で, あからさまにニセもん。

ドメイン名から 正引き→逆引き とやると p7w2.geo.re4.yahoo.com というドメイン名にたどり着く(これは BkASPil の機能で簡単に調べられる)。 さて, abuse@yahoo.com に苦情を申し立てるかどうか...

☆ Journal@rchive

素晴らしい!

試しに湯川秀樹さんの「On the Interaction of Elementary Particles. I.」(素粒子の相互作用について I.)をダウンロードしてみる。 もちろん見ても中身はさっぱり分からないが。 どうやらスキャナ画像をそのまま PDF 化したものらしい。 まぁ OCR にかけて云々ってのは手間がかかりすぎてだめなんだろうなぁ(追記: とりあえず画像を PDF 化して OCR 作業は別工程になるらしい)。 たとえスキャナ画像でも読めるだけありがたいということか。

☆ CCJP シンポジウム

おおさっそく記事が上がっている。

JASRAC の人の話はもう少し詳しく知りたいなぁ。

☆ 放送と通信は融合しない

「Noras」の記事より。

こりゃあ事実上のギブアップ宣言か。 放送と通信は融合しない(できない)って言ってるようなものだしな。 (本当はずっと前からそう思ってたんだろうけど)

「ハードとソフトの一致の中で、それを実現するためのツールとして通信を活用している」

の「ハードとソフト」は「コンテナとコンテンツ」と置き換えて読めば分かりやすいか。 要するに放送業者というのはコンテナ業者であってソフト(=コンテンツ)をハード(=コンテナ)から分離されたら商売が立ち行かなくなる, と公言しちゃってるわけだ。 コンテンツをコンテナから解放するネット(特に P2P や Web 2.0)は放送業者から見ればまさに破壊者なんだろうな。

☆ Einstein@Home のすすめ

こちらも遅まきながら。

以前書いた記事をもう少し詳しくした内容。 主にチーム内に向けた記事だけど, それ以外の人にも興味を持ってもらえるとうれしいな。

ツッコミはこちら

2006年03月28日

☆ 「宇宙の電波で情報を暗号化」

「日記/2006-3-27 - Tetsuya Izu's Wiki」より。

昨日の日経新聞を読んでないのでよく分からないのだが, 本当にこんなことができるのか?

ツッコミはこちら

2006年03月29日

ツッコミはこちら

2006年03月30日

☆ プログラミングは難しい

「もしもプログラミング言語が車だったら」を読んでニコっとなる。 この比喩が当たっているかどうかは分からないが, 「言語も車と同じで目的に応じて使い分けるもの」というのは共感する。

「スクリプト言語」でもちらっと書いたけど, 私の「感じ」ではプログラミング言語というのは概ね2つの方向性があって, それは限りなく H/W に近づいていく言語群と限りなく論理に近づく言語群だ。 前者の先頭にあるのがアセンブラで後者の先頭にあるのが Lisp なのかも?(じゃないかも? 追記 4/2: ツッコミをいただきましたその2)。 そういう観点で考えると Ruby や Perl と C/C++ や Java を比較するのは意味がない。

昔語りになってしまうが, 私がペーペーの頃は制御系の業界でも C 言語を操る人はまだ比較的少なかった。 ではなんの言語を使っていたかというと, もちろんアセンブラだ。 だから「C 言語が使えます」ってのは結構売り文句だったわけだ。 私も当時 C 言語は結構勉強したつもり。 でもそこで学んだことはプロセッサのインストラクションを如何に効率的に C 言語に置き換えるかってことだった。 「コード効率」という用語がある。 最初からアセンブラで組んだ場合に比べて C ソースからアセンブラにコンパイルするとどの程度効率が落ちるかという指標だ。 コンパイラを出すベンダもこのコード効率で競争していた面があった。

プロセッサの機能を物凄く端折って言うとメモリ(ポートも含む)操作とレジスタ操作の2つしかない。 どんなシステムでも結局はその2つの機能のバリエーションを如何に組み合わせるかってことに帰着する。 凄く単純な話だ。 構造化もオブジェクト指向も人間側の都合で語られるおまけでしかない。 プログラムは何のために書く? もちろん目の前にあるプロセッサを思い通りに動かすために書いているのだ。

私はこのシンプルさが好きで(間でいろいろ寄り道しながらも)制御系の世界に16年以上もしがみついている。 そういう私から見ると Ruby や Perl 等の言語は想像を絶している。 というかプログラマとプロセッサの間が透過的でない言語(もちろん言語屋さんにとってはどんな言語も透過的なんだろうけど)をみんながごく自然に受け入れていることに脅威を感じてしまう。

こういう言語の2極化(つまりプログラミングの2極化)はどんどん進行していくだろう。 あるプロセッサを理解するためには結局アセンブラまで降りなくてはならない。 しかも今はアセンブラ・ソースも最適化される時代だしね(人間が8本や16本もある並列処理をストゥールさせずに記述するのはほぼ不可能。3本の並列処理を使いこなすプログラマなら知ってるけど)。 さて, 私はどうしよう。

☆ Happy YEBISU

結構珍しいんだそうで。

って最近ビンばっかり撮ってるなぁ。 私はビン・コレクターか!

☆ 買い物

  • 『てけてけマイハート』 5 竹本泉 (竹書房)[bk1]
  • 『えすぴー都見参!』 1 岬下部せすな (芳文社)[bk1]
  • 『棺担ぎのクロ〜懐中旅話〜』 1 きゆづきさとこ (芳文社)[bk1]

私の最近の注目はきゆづきさとこさん。 『GA 芸術科アートデザインクラス』も結構面白いし。 絵もツボをついてるし。

☆ 「防衛目的」の宇宙利用

新聞系マスコミのページにリンクするのはイヤなので「星が好きな人のための新着情報」の記事より。

この辺の解説については 「J-RCOM 最新情報」の 3/29 の記事が分かりやすい。 3年前のドタバタお間抜けっぷりは知ってる人は知ってるんだけど(ここでもスパイ衛星軌道を表示するページにリンクを張ったりしていた), 遂に本腰を入れてきたようだ。 しかしスパイ衛星を打ち上げて「非侵略性」だの「防衛目的」だの聞いて呆れる。 どうなることやら。

ツッコミはこちら