Computersの最近のブログ記事

本そのものが発行されたのはそこそこ前ですが英語版を今読んでいます。まあ、理由は長らく4th EditionだったSafaribooks Onlineで5th Editionが読めるようになったから。さすがにこのクラスの本は良書とはいえ値段もそれなりに張るのでそうそう買えないので。

4th EditionはWindows XPあたりまでの記述でしたが、5th EditionはVista、2008が入ってきてアーキテクチャ解説としては直近のものに近くなっています。特にVistaなどの6.0番台はアーキテクチャ上の変更点も多いのでこういう良書は助かります。少なくとも、アーキテクチャ上の作りに関してこの本以上の内容はそうそうないので。

この本の場合には主にメモリ管理、タスク管理のようなOSの中核部の解説が基本なのでDWM等の解説はないんですが。それでも、この本の解説範囲であるI/Oとかでもキャンセル可能なI/Oとかトランザクション対応とか結構、重要な機能追加がありましたので。まあ、アプリケーション開発とかだとここまで深い知識はなかなか使えないと思いますけど。知ってて損はしませんからね。

導入そのものは、Windows XPあたりなんですが、まだそれほど使い込まれていない代物であるファイバーだとかこの辺はさすがにしっかり書かれていますね。でも、日本語版はまだらしい、というか出るのかな? でもこの辺を読んだことがあるのとないのでは大差がつくような。

技術開発等でよく用いられる言葉にコンコルド錯誤がある。実際、超音速旅客機コンコルドの失敗に由来するとされる。Wikipediaによれば代表的な文献には以下のものがある。

日本語で読める文献だと長谷川真理子の著書”科学の目 科学のこころ”のp13-17に進化的な議論が書かれている。基本的には、埋没費用サンクコストの評価に起因する。すなわち、事業の縮小・撤退を行っても回収できない埋没費用が大きければ縮小や撤退の決断は困難になる。そして、決断を先送りし埋没費用がどんどん拡大する。

さて、本題、先日の仕分け会議で所謂、京速計算機の予算削減が議論された。これをめぐってかなりの反応があったがその中に、コンピュータ開発の予算を削減するとは何事かという批判がかなりあった。実際、菅副総理が復活に前向きという話を聞いている。

これは、京速計算機を巡る論点でも書かれているが脊髄反射的な議論では結論を誤ると思う。元々は京速計算機はベクトル型とスカラ型のハイブリッド構成で10PFLOPSを目指すというのが根底にあった。しかし、現実的にはIBMが2012年には20PFLOPSの計算機Sequoiaの運用を開始するという既報の通り1100億で10PFLOPSの計算機を作るというプロジェクトは今の数字としてはかなりおかしい。

もともとこの問題というのは、NIKKEI BP ”スパコン国家プロジェクト NEC脱落の真相”やおごちゃんの雑文 京速計算機の批判の続きあたりから尾を引いている。結局、演算装置を作ってからスパコンの建造にかかるという愚を犯しているのでスパコンが完成するころには世代遅れの演算装置になっている始末である。

既報によっれば富士通のSPARC系のチップをCPUに使うとされているが、確かにSPARCは大規模な計算機系、特にデータベースでは実績があるが、現実的にはこの手の大規模な並列計算機では近年はx86系を多数使った構成がかなりを占めているように見受けられる。実際、Beowolfの発表以来文献でもかなりの数がLinuxとx86の組み合わせであるように思う。データベースを安全に動かすのととにかく計算を回すのとでは要件がかなり違いますし。

そういう意味では、ベクトル系に相当つぎ込んだはずで、しかも迷走しているのに埋没費用に目を奪われて判断に詰まっているというところではコンコルド錯誤の良い見本になっているように思います。

Xbox LiveでのTwitterのサポートのサービスインが11/17に決まったようですが、既に使っていたりします。結構、便利です。何が便利かというと、まあPC側に目を移さずともすぐにTwitterが使えるのは便利です。泣きどころとしては、ダッシュボード上のアプリケーションという形での実装なのでゲームを起動しながらは呟けないことかな。

機能性としてはReTweetを含め、現状でカバーできる機能は大体カバーしていると思います。まあ、Xbox360には通常のWeb ブラウザはないので短縮URLとかの話は何の意味も持ちませんけどね。勿論、PC上の気の効いたTwitterクライアントは相当に使いやすいですが、10feet UIとしては結構それなりに考えられたUIだと思います。

ざくっと、読んでみました。基本的には Processing という電子アートとビジュアルデザインのための開発環境である、Processing を活用した情報可視化の話です。情報の可視化に関しては関心がありますので買ってみました。

一口に可視化といっても立場は様々です。だいぶ前に買った ”The Visualication Toolkit User’s Guide” のように実験データなどの可視化を目的とした話もありますし。vtk なんかだとボクセルやボリュームデータの扱いもあるので、だいぶ前に関わった放射線治療計画システムのような話もいけるかと思います。

放射線治療なんかだと患部にきちっと放射線が当たって、患部外には極力放射線が当たらないように組まなければならないので。放射線を遮断するブロックなどをきちっと組まなければなりませんから。

この本はこういう、3D データの可視化という話は全くなくて、Web アクセスのログの解析だとか、ファイルサイズだとかこういうもののマイニングと可視化がメインの話です。あと、８章のグラフのあたりも面白いです。日本語でグラフと書くと棒グラフとかの話しになるんですが、ここで言うグラフとは有向グラフのことです。

この辺を読んでいて、はて .NET Framework でグラフを処理するのに有効なツールはないだろうかと思ったら QuickGraph なるものを発見。この本でもありますが、やっぱりグラフのところでは Graphviz が出てきますね。

まあ、Processing の開発手法を見るのにはなかなか良い本だと思います。翻訳の出来も読みやすい部類だと思いますし。ただ、個人的には、Processing でなくても実現できるよねと本末転倒な感想も抱きましたが。ただ、グラフや地図の描画に関する色彩や造形といったあたりのところはやや踏み込みが浅いかもと思いましたが。

ビジュアライジング・データ ―Processingによる情報視覚化手法 増井 俊之 (監訳) 加藤 慶彦 オライリージャパン 2008-12-01 売り上げランキング : 5081 Amazonで詳しく見る by G-Tools

Internet Explorer 8 がリリース候補になったこともあり、Web Slice が巷間に単語として出てきている。しかし、概念が難しいこともあり間違った説明も見受けられる。たとえば RBBTODAY の記事、『RSSより簡単で使いやすい？ ―― Internet Explorer 8の「Web Slice」機能とは』などは好例である。

RSS と Web Slice の情報のモデルの違いを考えるとわかりやすい。REST 的な思想で考えれば URI は情報のエンティティを示す。まあ、乱暴な言い方をすればURI は安定で同じ情報は同じ URI で得られることが期待される。超乱暴な言い方をすれば URI はデータベースで言う主キーと同じぐらいの重みがあると考えられるんじゃないかと思う。

ATOM/RSS はリンクという形で URI が時系列で流れてくるのでさまざま雑多な情報を時系列で表現するのに向く。Web Slice は URI を変更可能なシンタックスにはなっていないので、おそらく雑多な情報を流すフィード的な活用は設計時から想定されていないと考えられる。

したがって、Web Slice が向く運用は同一 URI で情報が変動する価格情報や天気予報のようなモデルだ。しかも、時間軸とセットで主キー的な概念を持たない過去の情報はどんどん捨ててしまう形態。たぶん、こういう運用が想定されていると思う。そういう意味では Feed とは全く別のデータモデルで、ある程度運用の仕方も想定された規格だと思う。

また、Microformats の援用である規格の設計を見ると Microformats の一運用形態と見ることも可能だ。おそらく、FireFox 3 + Operator のような運用も可能であるはず。まあ、Operator で運用可能かは吟味していないが。ただ、どっちにしろ、もう少し考えた記事がほしいな。

実際、夢魔の標的のアーティクル『RSSより簡単で使いやすい？ ―― Internet Explorer 8の「Web Slice」機能とはについて、なんですけど......』なんかを見ても、理解に難儀している空気があるし。

まあ、乱暴に言うと Weblog のフィードのためではなく、天気予報や価格情報をどんどん送り、古い情報はどんどん捨てちゃう形態のための規格。過去の天気予報や過去の価格情報に価値はないという状況で機能する規格。でも、最新情報へのアップデートはしたいという状況ね。これをやるにはその情報がいつの話かとかそういう情報を機械が理解できる形で供給しないといけない。

そのための規格と理解しています。

川西 裕幸のブログで見つけた同タイトルのアーティクル、Windows Vista 及び Windows 7 で採用される Direct3D 10.1 の後方互換性に関するアーティクル。後方互換性といってもアプリケーションサイドではなくドライバに対しての。

単純に言うと、Direct3D 10.1 は Direct3D 10、Direct3D 9、ソフトウェアの3つのドライバ仕様があり Direct3D 9 のドライバでも動くほか最悪、ソフトウェアレンダリングでも稼働するという話。もともと、Direct3D 10 自体が、Direct3D 9 くらいまであったあんな仕様もこんな仕様もOKというのを捨てて単純化しているので、そういう単純化で失われるもののフォローの最終段階かと。

InfoQ のアーティクル "CodePlexがTortoiseSVN向けのサポートを追加"を見つけたのでメモがてら。アーティクルそのものはCodePlexがであるが、中身を見ると CodePlex は SvnBridge で Team Foundation Server と Subversion のブリッジを構成していることがわかる。

まあ、まだ SvnBridge は実験したことがないが今度やってみたくなるな。