_ ソニー、超小型130万画素デジカメ「サイバーショットU」

Oh! No!!!!!!!!!!!! EXILIMを買ったばかりのソニー信者には酷な話だぜ。

_ 富士通ウェブ・アクセシビリティ指針

ごくごくまっとうなことが書いてあるだけだけど、この程度のことも知らないweb制作者は結構いる気がする。あと、わかっているつもりでも、実際にはちゃんとできていない人もいるだろう。俺自身も、わかった気になっているだけの部分が多そうな気がする。

というわけで、あとでWebアクセシビリティスレッドを使って、一項一項ちゃんとチェックしてみよう。

_ Intelがひたすらメモリ帯域の拡大にこだわる理由

インテルがやりたいことは、サーバー系システムでは現実的な回答かもしれないけど、一般人が使うPCレベルのシステムでは全然現実的ではないよね。OSレベルで常時、それなりにCPUパワーのみが必要な（HDDアクセスとかが発生したらダメ）バックエンド処理を行うようにするならばともかく、フロントエンド側で使うアプリケーションはほとんどシングルスレッドで動くようにしか作れない（作らない）だろうし。

投機的マルチスレッドってのも、いまいちアヤシイ。メモリアクセス部を別スレッドで投機実行しておいて、実際にデータが必要になったら“当たり”を引いたスレッドを選択すればレイテンシがなくなるという話なんだろうけど、そんな仕組みで高クロック連続動作するんだろうか？　投機的ロードするデータをストアしておく領域はあまり大きくできないよな。下手したらCPUレジスタのみ？　あと、投機的マルチスレッドを生成する処理ってのも結構負荷が大きそう（当初はコンパイラであらかじめ生成するらしいけど）。

一度にロードするデータを大きくすると、データストア領域が詰まってストール。一度にロードするデータを小さくしたところで、投機的マルチスレッドを生成する処理、あるいは実行ユニットの処理能力自体が不足してストール。といった感じになっちゃいそうだ。まあインテルのことだから、それなりの落としどころは見つけるんだろうけど、上記のようなシナリオを完璧にカバーできるような落としどころってあるのかなー？

_ IPsecで安全ネットワーク構築 -暗号化通信のススメ

個人レベルでセキュアなネットワーク通信を行うための基礎知識。俺はこの辺漠然としか知らないから、こういう基本的なところから説明してくれる文章はとてもありがたい。

_ 「リンクに許可が必要だって？」――NPRの方針に募る反発(上)

日本のweblog＆掲示板コミュニティでもちょっと前に祭りがあったなー。日本もアメリカもネットワークコミュニティの歴史においては同じポイントあたりにいるってことなのかな。それにしても、

「それはホームページの内容による――もしウェブ管理者が特定の主義主張を掲げる人々を擁護している場合、リンクを許すのは適当だろうか？ われわれは擁護団体の片棒を担ぎたくない」

ってのは、「リンクを張られる」＝「被リンク者は、リンク元の主旨に賛同している」という理屈ですか。変わった常識ですね。

そんでもって続き、「リンクに許可が必要だって？」――NPRの方針に募る反発(下) 。

要するに、リンクを制限することに法的な根拠はないけれども、リンクを制限すること自体は違法なわけではないし、って感じだね。で、根拠がないことでも試しに「制限する」と言ってみることに意味を見いだした企業や団体は、「制限する」と言ってみるわけだ。

_ MSのPalladiumは、PCの守護者かプライバシーの破壊者か？

この間の記事よりもずいぶん具体的になった。俺が思っていたような「個人情報保護」向けの規格というよりは、「著作権保護」向けの規格なんだね。向いている方向は個人ではなく権利団体か。まあそんなもんだろう。

で、要するに今まで著作権保護付き音楽データとかを買ったらレジストリなりファイルなりに書き込まれていた権利情報が、今度からはチップ上に標準で搭載されたキーとの組み合わせで暗号化されることになり、確実のそのマシン上でしか再生できないようになる、って感じなんだね。全然うれしくねー。

_ クロスサイトスクリプティング脆弱性蔓延の現状と解決策

1年前に書かれたXSS関連文書。発表するリスクを考えて今まで発表されなかったんでしょう。ケーススタディとしてまとめられた具体例は情報源として貴重。

_ Pocket PC 2002とXScaleの相性はイマイチ？

旧型とは性能がダンチガイだぜ！ってな感じの鳴り物入りで登場したXScaleだけど、OSが最適化されていないというだけで、そんなにパフォーマンスがでないもんなの？　まあCE系はもともと高クロックなCPUを載せているものが多かったから差が出にくいのかもしれないけど、それにしてもPalmみたいにエミュレーションをやっているわけでもないのに、ほとんどスピードが変わらないっつーのはどういうことよ。

_ 件名に「未承諾広告※」表示を義務化　経産省

変えるの早すぎ。そんなんじゃ対応したシステムとかの実装が間に合わないじゃん。まあ日本の省庁が決めたことなんかをベースにシステムを実装する人はそういないだろうけどさ。それにしても、この手の規格はもうちょっとちゃんと話し合って、妥当なものになってから発表・施行して欲しいよ。

_ CDの“タトゥ”は高品位の証し――ヤマハの「DiscT＠2」

発表されたときにはそんなんいらねーよと思ったんだけど、実際の出力イメージを見てみて気が変わった。その機能がついて値段が大して変わらないならばちょっと欲しいかも。思ったよりもかなりきれいに出力できるんだね。

_ ブロードバンド時代のデータセンターの役割とは？

あと関連としてブロードバンド普及でトラフィックはどう変わったか？ なんてのも。

前者はFFXIのトラフィックに関する情報とかもあったりして、面白い。そろそろ個人でもデータセンターにサーバーを置く時代がくるかな？　それとも家にサーバーを置く方がメインになるのか？

で、後者。へー、今のトラフィックの谷間は8時くらい（通勤通学時間）なのか。メンテナンス系の処理は、なんとなく4〜5時くらいを基本に設定することが多かったけど、今はそうとは限らないんだね。

_ 「2ちゃんねる」に400万円賠償命令

これに関しては、いろいろと考えるべきことがありそうなんで、「2ちゃんねるに400万円賠償命令」を受けての方でぼちぼち書いていこう。

_ 企業セキュリティを守る「碁マスター」 - トレンドの企業向け新構想発表

どうもネットワークセキュリティ関連は、各企業（サーバー管理単位）がそれぞれセキュリティ専門家を抱えるというのは無理そうな気配を感じるし、こういった専門メーカーにがんばってもらった方が世の中の為になるのかも。基本的にこういうインフラ的な部分は、特定の企業とは関係ないオープンな方が好きだけど、現状を見ているとそうも言っていられなそうだ。

_ 「日本語ウイルス」作者からの手紙

確かにウイルスへの技術的な興味を持つ開発者は少なくないだろう。でもまあそういう人は、Terrariumあたりで満足しているのが吉。そういえばTerrariumもそろそろゲーム終了だね。

_ マイクロソフト PC初心者向けサポートサイトを開始(WebBCN)

どうなんでしょうねー。ちゃんと情報が集まるんでしょうかねー。やってみた結果が2ch以下だったらバカだよねー。きっと「本来自社でやるべきサポートを、ユーザーに任せるとは」みたいな批判が出たりするんだろうねー。まあ何にしろ、有意義なデータベースができるならばそれはそれでいいよ。

_ MyApp? (11:58)

さっき1470.netのネットワーク帯域がバカみたいな数値になっているのを発見して調べてみたら、今朝の4時からMyAppとかいうUAで、blogmapのとある1ページを分間20回くらいずつGETし続けている人がいたよ。それだけで3.2Gバイトの転送量かよ。従量制の契約だったら怖いことになってたかも。

@homeのネットワークで何かのプログラムを動かしているあなた、多分それ、巡回ロジックか何かが腐ってますよ！

_ XML-RPCサーバーが腐っていた (16:49)

6/24にPEAR XML-RPCライブラリをアップデート（というかpear upgrade-all）したところ、それ以来1470.netのpingサーバーが腐っていた模様です。XML-RPC 1.3.0からXML-RPC 1.2.2に戻したところ、きちんと受信できるようになりました。PEARの中身まではまだ追いかけてないけど、

require_once 'XML/RPC/Server.php';

function weblogUpdates($msg) {
       $value_maps = array(
               0 => 'title',
               1 => 'url',
               2 => 'change_url',
               3 => 'category'
       );
       $params = array();
       foreach ($value_maps as $index => $key) {
               $param = $msg->getParam($index);
               if (!$param) {break;}
               $params[$key] = $param->getval();
       }

       if (updateWebsiteLastModified($params)/* 情報更新 */) {
               $error = FALSE;
               $error_msg = 'success to recieve your ping!';
       } else {
               $error = TRUE;
               $error_msg = 'fail to recieve your ping!';
       }

       $value = new XML_RPC_Value(
               array(
                       'flerror' => new XML_RPC_Value($error, 'boolean'),
                       'message' => new XML_RPC_Value($error_msg)
               ),
               'struct'
       );

       return new XML_RPC_Response($value);
}

$map = array('weblogUpdates.ping' => array('function' => 'weblogUpdates'));
$server =& new XML_RPC_Server($map);

みたいな感じの、ほとんどPEAR XML-RPCに依存した内容だから、こっちのコードの問題じゃないと思うんだけど。XML-RPC関連はテストがめんどいんだよなー。

_ これからのフィードはどの形式を採用するべきか

1470.netリニューアル開発テスト版にはまだRSS出力機能は一つもつけていない。

というのは、新バージョンではURI以外の情報もいろいろ含んでおり、また一つのメモに複数のURIが所属することもできるため、単純なURI＝1アイテム型のRSSで置き換えることができないから、ってことが表面上の大きな理由ではあるんだけど、それ以前の問題として、今から新しく作るアプリケーションではどの形式のフィードを採用するのがいいんだろう、という根本的なところでの疑問もあったりする。

昔はいろいろ考えるのが面倒だし、日本での採用事例も多い（＝提供するフィードを利用するアプリケーション側で扱いやすい）しってんで、基本的にRSS 1.0を使ってきたんだけど、最近ではフィードをハンドリングするライブラリも充実してきたし、後者の理由はもはや大きな理由にはならないだろう。で、前者の理由に関しても、今回はどうせ位置情報とか日時情報とかの扱いが絡むんで、いろいろ調べたり考えたりしなければならないことが多いから、ついでにちゃんと考えてもいいんじゃないかと思ったりしている。

ポイントとしては、URL、位置情報、日時情報あたりをうまくまとめて扱いやすく、将来的な活用可能性が高く（フィードとしてだけでなく、フィード内に含まれる各データ自体もそれなりに再利用性を持つ）、さらに現時点でもそれなりに利用できる（現行のフィードリーダー等でちゃんと扱うことができる）ようにするには、どういうフィードデータを吐けばいいのか、というところ。これもそれPla（ggerで後付けで加工すれば何とでもなるじゃん）禁止。

自分でもぼちぼち調べていきますが、よさげな情報をお持ちの方、ご教示ください。

1470.netリニューアル開発テスト版のアカウントをお持ちの方は

関連しそうな情報を「これからのフィードはどの形式を採用するべきか」グループでメモしておいてもらえるとありがたいです。