Diary

もともとは研究用ソフトウェアの開発履歴に関するページだったのですが、開発関連よりも雑談の方が多くなったので、2001年分から別のページを用意することにしました(過去のページの一覧はこちら)。リンクは勝手にしてください（でもリンクしたい人なんているのでしょうか）。それから海外出張の写真一覧はこちらにのせてあります。筆者のプロフィールはこちらです。

2008年5月14日

Windows Vistaは発売から一年以上たっていますが、新しい物好きのまわりの研究者を見ても使っている人は少ない。VistaはマイクロカーネルOSと同じ失敗をしたのかもしれませんね。マイクロカーネルOSと同じ失敗をしたのかもしれませんね。マイクロカーネルOSはカーネルが提供する機能を必要最小限にして、それ以外のOSが提供すべき機能はアプリケーション(ユーザレベル)で実現することにより、機能の変更や拡張可能にしました。しかし、通常のOSではカーネルで提供される機能も、カーネル内とカーネル外で切り替えながら実現するので、実行コストが大きくなってしまいました。しかし、ユーザは機能拡張や変更をするわけではないので、モノシリックOSに対して機能的な違いは見いだせない。ユーザはパフォーマンスが速いOSを求めますからから、どれだけアーキテクチャが優れていても普及しませんでした。さてVistaですが、リソース食いとパフォーマンスの悪さの原因は.Net Frameworkをベースにした高水準APIにありますが、高水準APIはアーキテクチャ的には優れたものであっても、所詮は低水準APIを組み合わせたモノなので、低水準API(を組み合わせて)で実現できない機能を実現してくれるわけではない、その一方でパフォーマンスは悪くなりますから、ユーザから見ると機能は同じだけど、遅いだけのOSにみえてしまいます。VistaのGUIはダメダメなのですが、Microsoftの立場から見ると、Vistaは開発者から見たインターフェース、つまりAPIは変わっても機能そのものには進歩がないので、ユーザ側からみたインターフェース、GUIで進歩性を出そうとしたのかもしれませんね。だって、VistaのGUIがWindows XPのGUIと大差なかったら、機能は同じで見た目も同じで、ただ遅いだけのOSになってしまいますから。

2008年5月13日

今日は博士課程の学生さんの中間発表。発表する学生さんもたいへんなのですが、こちらの方も気苦労が多いです。それにしても出張後は仕事がいろいろたくさんです。勤務先のネットワークは、Macintoshはつながるけど、Windowsはつながらないという事態に。DHCPでトラブルが起きているみたいなのですが、謎ですね。それも同じフロアーだけの問題みたい。ただ、同じフロアーの方々はMacintoshユーザが多いのでトラブルに気づいてもいない始末。もっとも当方もMacintoshなのですが、秘書さんのコンピュータはWindowsなので気づいたのでした。

2008年5月12日

ニューヨーク発便なので14時間の長旅。プレミアムエコノミーにアップグレーとしていただいたので電源確保。機内では2時間ほど寝たものの、それ以外はお仕事。論文執筆と、その論文用の性能評価プログラムの作成。もっともネットワークが絡む性能評価が必要なので、機内でベンチマークまではとれませんでしたがね。

2008年5月11日

いよいよ帰国の途に。ANAのニューヨーク発成田行きに搭乗。それにしてもアメリカ出張はつらいですね。さて今回の出張では、2000行程度のプログラミングと論文一本を書き上げる予定でしたが、どちらも中途半端。前者は設計を間違えて無駄なコードを乱造、後者は半分ほど書いたところ。あとは復路の飛行機ですね。それからもうひとつ今回の出張ではPythonを覚える(正しくいうと思い出す)というのが目標なのですが、こちらはだいぶ思い出してきました。頭の体操も兼ねて、毎年、一つ以上のプログラミング言語は覚えるようにしていますが、なんか最近は前に覚えて言語の復習ばかりで、言語の数が増えていません。

2008年5月10日

Rutger大学は全米では8番目に古い大学だそうですが、たしかにキャンパスによっては1800年代の建造物がいっぱいです。今日のように土曜日は大学ラグビーの試合があって、今回訪問したキャンパスの試合がある土曜日は車でいっぱいになるそうです。今回はスタジアムが工事中のようでしたがね。帰国の準備のためにニューヨークに移動。ニューヨークのメトロポリタンオペラで、オペラ「The First Emperor(始皇帝)」を観劇。始皇帝役はあの３大テノール歌手の一人、ドミンゴ(Domingo)。ストーリや曲に関しては？マークがかなりつく作品でしたが、ドミンゴがひとりでオペラとして維持している感じでした。お姫様役(Sarah Coburn)なかなかよかったですね(また昨年とは違う方だそうですが、あとのメンバーは去年とあまりかわりないようです)。指揮は作曲者自身のようでしたが、オーケストラ演奏自体はいいのですが、問題は曲がいまひとつなので、盛り上がりにはかけました。舞台や演出はさらに？マークが連発なのですが、唯一Wada Emiがデザインした衣装は東洋性と美術性のバランスをとったものですごくよかったです。おそらくアメリカ人からはオペラ作品という以前に、東洋的な雰囲気で楽しめるのでしょうが、ストーリーは稚拙というか、かなり無理があるし、楽曲的には善し悪し以前、歌は中国語ではなく英語で、さらに舞台もモダン風なので中国的な雰囲気は少ない。ということでドミンゴと衣装だけでもっていたような作品でした。去年、初上演されたときも評価がわかれたようですが、たしかに評価の難しい作品ですね。ただ、純粋にドミンゴの歌を楽しむのであればいい作品かもしれません。ドミンゴは声量もありますが、声質と(歌的な)演技力はオペラ歌手の中でも抜きん出ています。やはりドミンゴは3大テノールといわれただけはありますね(いまは2大テノール?)。それにしてもこの半年間で2回もドミンゴの歌を聴けるとは思いませんでした。贅沢ですね。メトロポリタンオペラも半年間で3回目。これもあり得ない数です。

2008年5月9日

今日もRutger大学でワークショップです。さすがに質問をするのにも疲れてきました。それにしても無線LAN、それもRSSIをつかった位置推定や省電力制御の話題が多いワークショップです。ただ、今日の発表にRSSIはいかに不安定で使えないパラメータであるかという研究があり、この発表を先にやっておいてくれたら、一昨日や昨日他のRSSI絡みの発表はすべて無意味な研究ということになったのですがね。それにしても無線LANの研究は難しいですね。数年前までは無線LANはコンピュータ向け専用通信技術という位置づけでしたが、コンピュータ系の研究室でも手を出せましたが、携帯電話などの無線技術の主戦場と電波伝送的にも近くなっているので、コンピュータ系の研究室が無線LANでもRSSIのような物理層に近いレイヤーの話題に手を出しても、高価な測定機器やや電波暗室を持っている無線専門の研究室には絶対に勝てません。実際、今回のワークショップでも、大学、それもコンピュータ系の研究者による無線LAN関連の研究はレベルが低すぎ。おそらく無線系の会議だったら卒論発表としてもみても失笑レベルだったのではないでしょうか。もちろん、コンピュータ通信関連のトップ会議に採択される無線関連の論文でも、やはり無線を専門にしている研究者から見ると失笑レベルのものが多いそうですから、仕方ないといえば仕方ないのですがね。ところでRutger大学は学食の調理が本格的でおいしいですね。やはり研究のアクティビティにとって、食事のクオリティは重要かも。ところで米国に行くとiPhoneを使っている人が多いですね。それとiPod Tocuhを使っている立場からいうと、多くの人がイヤホーンをせずに使っていることがある意味、新鮮。つまりiPhoneを電話やPDAとして使っているということなのですが、やっぱり新鮮。ただ、個人的にはiPhoneはちょっとパスかも。むしろiPhoneはAPIの公開に踏み出したということの方が重要かも。iPhoneにしてもAndroidにしてもほとんど全部のAPIを公開したのですが、これまでの携帯電話はJavaやFlashのアプリケーションは独自開発はできるにしても、公開されているAPIはごく一部なのでゲームがせいぜい。その状況を打ち破ったのは大きな意味を持ちますね。さて問題なのはAndroidの方。JavaベースのAndroidはネイティブベースのAPIよりは遅いのですが、携帯電話はレスポンスが要求されますから、どの程度受け入れられるでしょうか。

2008年5月8日

今日もワークショップです。そして60分の講演。オーディエンスの背景知識がわからないので、すごく話しにくい。さてワークショップは質問をするのが仕事のような状態になっていますが、他の講演の多くは無線関連で、質問をするのもなかなかたいへん。誰も質問をしないので、手を挙げてから質問を考える始末。それにしてもフィンランド人の研究者は日本人研究者並におとなしいですね。ほとんど質問をしないです。もちろん、むやみに質問をされるのも困りますが、無反応なのも困りものです。

2008年5月7日

Rutger大学(ニュージャージー州立大学)でワークショップ。Rutger大学関係者とHelsinki大学、Helsinki工科大学の関係者がメイン。6時過ぎにPrinceton大学訪問。メインのキャンパスやアインシュタインのオフィスがあったキャンパスなどを訪問。イギリスの古い大学のような雰囲気。ただし、古いといってもアメリカの基準で古いということになりますが。いまいるのはニュージャージーですが、サンフランシスではJavaOneを開催中。Java自体はJavaFXぐらいしか話題がないのですが、もりあがっているのでしょうかね。そのJavaOneでSun MicrosystemsのCOEの講演の記事が出ていましたが、COE曰く「ソフト価格で許されるのは無料だけ」だそうです。つまりソフトウェアはサービスやハードウェアを売るためのオマケ。でもそのオマケがないとサービスやハードウェアは売れないそうです。いちおうそのソフトウェアの研究を仕事にしている立場からいうと、いろいろ複雑。ある意味、当たっているところはありますが、逆に言うとソフトウェア専業メーカはやっていないということですよね。Sun Microsystemsのようにデータセンター向けのハードウェアやサポートで収益があげられる企業はいいの、ですが、ソフトウェア専業メーカーはソフトウェアを作って売ることしかできないわけで、そのソフトウェアが無償になったら儲かりません。ハードウェアやサポートを売るためのインセンティブになっても、ソフトウェアに対してハードウェアやサポートによる収益を超えるような研究開発には及び腰になるでしょうから、今後はソフトウェアの研究開発は長期的には停滞していきますよね。

2008年5月6日

ひたすら移動です。長い一日になりそうです。ところでSun Microsystemsに続いて、Microsoftもデータ・計算センターの設備をラックから(貨物用)コンテナに移行しているようですね。従来はコンピュータを何枚もさしたラックを管理単位にしていたのですが、コンピュータの数が多くなるとラックでは管理も煩雑だし、場所も食いますからね。多数のサーバ類は製造段階でコンテナに格納し，コンテナごとデータ・計算センターに搬入して，コンテナ単位で冷却を行うそうです。Cloud Computingが普及すると家庭やオフィスの計算やデータ管理はCloud Computingのインフラに任せてしまうので、サーバを個人や一般企業が購入・運用することは皆無になってしまうかもしれません。そうなるとサーバというハードウェアのマーケットはCloud Computingインフラ向けだけとなってしまう。つまりコンテナが主体になってしまって、いまのようなサーバ用コンピュータ単体やラックは見なくなるかもしれませんね。ちなみにCloud Computingのインフラというのは広い敷地にコンテナが整然と並んでいるような風景なのでしょうか。そしてコンテナの中にあるサーバが調子悪くなったら、コンテナごとフォークリフトでトラックに乗せて、メーカのサービスセンターに送るのかもしれません。こうかくと冗談っぽく聞こえますが、かなり現実味を帯びているから怖いですね。

2008年5月5日

午前中はオフィス、午後は新国立劇場でオペラ「軍人たち」をみる。欧州のオペラハウスの演出を引き継いだようですが、まさに最近の欧州オペラではよく見られる前衛的演出、舞台、衣装。歌手も非常にいい出来でヒロイン役(マリー役)のVictoria Loukianetz、男爵役のPeter Hoareは退廃的な役所なのですが、うまく歌いきっていました。また演奏は新日本フィルハーモニー交響楽団ですが、現代音楽調の難曲を見事に演奏して非常によかったです。この水準のオペラを国内で見られるとは思いませんでした。藤原歌劇団や二期会はいいオペラ団だとはおもいですが、収益性が求められるので、こうした前衛的な作品は取り上げない。欧米オペラ座は自国では前衛作品を取り上げますが、来日公演ではこうした演目はさけるのが常。やはり日本では新国立劇場ではないと上演できない演目だったのではないでしょうか。ただ、このオペラは良くも悪くも通好みなので、オペラらしい作品を見れると思った方は唖然だったと思います。

2008年5月4日

速報という形で報道されていますが、MicrosoftはYahoo!買収を撤回したようですね。これでYahoo!株は大幅に下がるでしょうから、Yahoo!株主は大損害なわけで、Yahoo!経営陣の解任動議に動くはず。そうなるとYahoo!は経営陣と株主のあいだで内紛状態になります。Microsoftにしてみれば、Yahoo!内紛で株価が下がったところで、値切ったうえで再度買収を提案してもいいわけで、買収するにしてもここ撤回発表するのが正解ですね。買収発表があったときのこのページでも書きましたが、Yahoo!経営陣は断る理由などないはずなのですがね。Yahoo!経営陣はいったい何を考えているのでしょうかね。仮に将来にわたってMiscorosftが買収してくれない場合ですが、今回以外の買収騒動とリストラ騒動で嫌気をさしてYahoo!を辞めた社員は少なくないはず。そうなるとYahoo!は技術的にも営業的にも力が落ちているはずで、起死回生の策でもない限りはジリ貧になっていくのではないでしょうか。さて日本のヤフーはYahoo!とは独立しており、今回の買収騒動では蚊帳の外ですが、Yahoo!が内紛に陥って陰りがみえてくると、国内のヤフーのブランド力も下がりかねないので、今回のMicrosoftの買収撤回はグッドニュースではなくバッドニュースでしょうね。

2008年5月3日

Cloud Computingに将来性があるかについて問い合わせをうけたのですが、個人的にはCloud Computingの特徴はスケラビリティーなどいろいろあるとは思いますが、個人的に一番重要だと思っているCloud Computingがフォンノイマン型アーキテクチャに近いこと。Cloud Computingの場合、超巨大なインフラに、データも手続き(プログラム)の両方をおいて、その手続きでデータをアクセすることになります。一方、フォンノイマン型アーキテクチャはデータと手続き(プログラム)を一つのメモリに入れますから、Cloud Computingのインフラを一つのコンピュータと考えれば、Cloud Computingはフォンノイマン型アーキテクチャに極めて近いことになります。いままでもWebサービスなどの類似した試みはいっぱいあったのです、データと手続きは別のサーバに置かれることが多い。ご存じのように非フォンノイマン型アーキテクチャはいままで数多く提案・試作してきましたが、性能的にも価格的にもうまくいった試しがない。もちろん単体のコンピュータと、Cloud Computingのようなネットワーク上のサービスインフラは違うのですが、やはりサービスを定義するプログラムがデータと手続きから構成される限りは、フォンノイマン型アーキテクチャの呪縛からは抜け出せないのではないでしょうか。

2008年5月2日

今日は会議の日です。ところでRuby関連の研究の相談を受けたのですが、こちらとしてはコメントする立場ではないし、こちらがコメントしてもそれを聞くわけでもないでしょうから黙っていましたが、いまさらRuby はどうなのでしょうか。2年ぐらい前、Ruby on Railsが登場したときはエキサイティングな言語という感じがありましたし、実際、Twitterなどの旬なサービスがRuby on Railsを使っていましたからね。ただ、Rubyという言語の今後の発展にとって、Ruby on Railsがいいアプリケーションだったかは今となっては疑問だったりしますが。それはともかく個人的には記述の簡便さよりも可読性を重視するので、Rubyはプログラムを書く気にはなっても、読む気にはなれないのですよね。やはり可読性と記述性は相反しますからね。もちろんスクリプティング言語はお手軽・簡単プログラミングが目的になるので可読性よりも記述性を重視されて設計されることが多いのですが、プログラムレビューが重視されるようになっている現状では、記述の簡便さだけでなく、可読性の方も重要になってくるのではないでしょうか。また、Cloud Computingでサービスを記述する場合、スクリプティング言語でサービス定義に使うことが多くなると、スクリプティング言語はその目的からしてかわってくるのではないでしょうか。

2008年5月1日

月がかわって5月ですね。毎月1日は情報関連メーカが値下げ発表をします。各社の発表、例えばバッファローやIOデータがあります(わかりやすいように希望小売価格があるメーカを上げています)。なぜ毎月1日に集中する理由は意外に知られていないようですが、ヨドバシカメラなどの量販店は毎月1日にメーカにその月の卸価格を出させるのです。このためメーカは毎月1日に価格改定が発表することになります。これは製品価格をオープンプライスをメーカも毎月1日に通知します。さてIT業界はダウンサイジングですから基本的に値下げ発表となります。特にハードディスクやメモリ関連は顕著です。このため、ヨドバシカメラなどの量販店で売っているような機材や部品を購入するときは、月末ぎりぎりの場合は次月の1日に行われる価格改定をまってから、見積＆発注すると安く購入できることが多い。ただ、ここで注意しないといけないのは購入先が小売りなどをしている場合です。店頭在庫などを持っていると、その在庫の卸価格をもとに見積もりを出してくることがあります。いずれにしても機材の見積&発注では予算を有効利用したいですね。

2008年4月30日

MacOS 10.5用のJava SE6が正式リリース。まぁデバロッパー版が前からリリースされていたとはいえ遅い、遅すぎですよね。そのうえ64bitマシンだけ(実はMacOS 10.4用にはJava SE6の評価版がリリースされているので、32bit版も動きますがね)。AppleはMacintoshもiPhoneもCocoaベースのネイティブAPIに主軸をおいているので、仮想機械ベースのAPIには関心がないのでしょう。確かにネイティブAPIは実行コストが小さく、iPhoneのような組込コンピュータでも動くというメリットがあります。一方、JavaやMicrosoft .Net Frameworkのような仮想機械によるAPIはマシン非依存のアプリケーションが作れますが、実行コストが大きい。ただCloud Computingに代表されるように、ソフトウェアの実行場所がサーバー側に移行すると、ネイティブAPIに活躍場はないし、そのネイティブAPIに固着したAppleは先がない。おそらくAppleの戦略は。AppleはPDA以上、PC未満の端末と組込コンピュータに注力するつもりかもしれませんね。逆に言えば、ここはMicrosoftが一番手薄な市場ですから、ビジネス的にはねらいところではあります。つまりWindows Vistaは非力マシンのOSとしては重すぎますし、Windows CEは使い勝手に難があります。もちろんLinuxベースの簡易端末もありえますが、使い勝手を考えるとMacOS Xの方がいい。仮にAppleが軽量版MacOS X＋Safariを用意して簡易端末を売られると他社は対抗ができませんからね。ただ、OSとWebブラウザだけの端末は価格競争になるでしょうから、iPodやiPhoneなみに市場に関連商品エコロジーでも作って大きなシェアをとらないと採算性はとれないはず。

2008年4月29日

いまフィルムカメラを使っている方はどれぐらいおられるのでしょうかね。カメラの業界団体(カメラ映像機器工業会, CIPA)は、フィルムカメラ(銀塩カメラ)の生産・出荷台数の統計の発表をやめたそうです。1月の統計はフィルムカメラの生産が1580台(約4600万円相当)、出荷は1万1573台(約1億7200万円相当)と微々たるもの(使い捨てカメラは含まれていませんが)、そしてついに2月の統計ではフィルムカメラはなくなっています。CIPAの規定上、統計発表の対象から外れるのが理由だそうです。それにしてもカメラの国内最大業界団体自らフィルムカメラを統計対象から外したのは一つの時代の終わりをしめす象徴かもしれません。実は当方はいまだにフィルムカメラを使っており、心境的にはやや複雑だったりします。たしかにカメラ量販店でもフィルムカメラは片隅にあるかないか、フィルム売り場もどんどん小さくなっていますね。この分だとフィルムカメラへの需要は減って、フィルムもその現像＆プリント代も高くなりそうです。ちなみに手持ちのフィルムカメラはContax T3、Minolta CLE、Nikon FM3Aなのですが、さてこれらのカメラをわかる人はどれぐらいいるのでしょうかね。

2008年4月28日

午前中は慶大の大学院授業。今年は履修者27人だそうです。大学院の授業としては多いですよね。さてここ数日はMicrosoftのMeshの研究。だんだんGrooveに似てきていますよね。Grooveを率いていたRay OzzieがMicrosoftを率いているわけですから、当然といえば当然ですが。Meshはまだまだこなれているとはいえませんが、GoogleのApp Engineと同様に今後のコンピューティングにつながる道にはなるでしょうね。その意味ではAppleは先がないですよね。ハードウェアとソフトウェアの一体化と独自APIに拘るたために、サービスという概念にすら行き着いていませんからね。Appleはいまはいいですが、PC時代の終焉とともに終わりそう。ところでGoogleのApp Engineなどは(いまのところ)Pythonだけをサポートしていますし、MeshもプロタイプはPythonを使っているそうです。これを書くとRuby愛好家の方は怒るわけですが。ただ、すくなくても現状ではクラウドコンピューティング系の最新技術を使うにはPythonを使うしかないのも事実。ちなみにRubyに関してはスクラッチにちょっと処理を書くときはいいと思いますが、サービスコンポジションを書く限りはオブジェクト指向ではなくてもよく、Rubyのように開発者にオブジェクト指向を要求する言語は使いやすいとは限らないのですよね。ところでMicrosoftの作るMeshのアプリケーションは個人向けのものばかりなのでしょうかね。Meshというか、Grooveの特性を考えると個人向けよりも業務向けの方が向いているし、需要も大きいと思うのですがね。

2008年4月27日

最近、Webに出回っていますが、Ray Oggieのメモ。今後の技術トレンドを考える上で、2005年のメモととともに重要なドキュメントになりそうですね。技術ポイントは大きく分けて3つなのですが、その3つめに関するプログラミングを解説したビデオも公開されていますが、これもなかなかおもしろい。ユビキタスコンピューティングとかを語る前に見ておきたいですね。それにしてもいまは1995〜97年ぐらいのWeb聡明期と同じぐらいIT技術が大きく変わっていますし、エキサイティングですよね。

2008年4月26日

オフィス前では撮影中。ドラマのようですが、最近は多いですね。さて昨日の続き。研究者にとって論文発表は必須なのですが、IT系に限ると論文のライフサイクルは技術のライフサイクルについていけてない。例えばソフトウェア系を例にとると、当該分野で代表的な論文誌であるIEEE Transaction on Software Engineeringという論文誌がありますが、採録から掲載までに2年以上かかることも珍しくない(当方の場合は1年程度でしたが)。いくらいい研究でも2年もたったらその研究は陳腐化しています。国際会議は研究者同士の情報交換として生き残るでしょうが、論文誌は研究発表の場にならなくなっています。こうした問題への試みとしては、韓国の情報処理学会に相当する学会が、投稿から掲載まで半年をウリにする英文論文誌を始めましたが、同様にスピードをウリにする論文誌がでてきそうですね。自然科学の学術誌Natureの試みですが、Nature Precedingsという雑誌では投稿された論文は、査読なしでネット上で掲載して、読者からの評価をうけるというスタイルを試みています。この場合、読者評価というのはある種の人気投票になってしまうので、研究としての価値と人気度は一致しないという問題もありますが、少なくても早い段階で研究成果を公開できるというメリットはありますよね。いずれにしてもベストの論文採択方法がない以上は、これも論文評価方法のひとつにはなるかもしれません。

2008年4月25日

昨日の論文誌の続きですが、和文論文誌ってどうなんですかね。和文論文誌は理学系学会では廃止方向ですが、情報系はむしろ増えている感じ。日本語の論文はいくら書いても海外で読まれることは皆無だし、海外からみると研究成果として認められるわけではない。萌芽的な研究を扱う研究会などは日本語でも仕方ないでしょうが、完成された研究を発表する論文誌は英語論文だけにしてもいいと思うのですがね。国内指向を続けていても海外から取り残されるだけなのにね。同様に研究者の実績でも、日本語の論文誌は何本あっても、海外からみるとゼロ本と同じ。もちろん情報系研究者の場合、研究実績が和論文が中心の方が多く、そうした方は研究実績が大きく目減りすることになるので強い抵抗があると思いますが、いつまでも国内情報系だけで独自基準が通用するわけではないの事実ですよね。

2008年4月24日

数日前ですが某国内学会から、学生さんの書いた論文(当方は共著)の別刷りが、その請求書とともに到着。国内学会の場合、別刷りを著者に強制的に買わせないと財務的に論文誌の刊行ができないのはわかりますがね。ちなみに海外の出版社の多くは、校正や整形作業はインドに外注するようになっています。この結果、コストも下がったそうですし、時間も大幅に短縮できたそうです。情報系の国内大手情報系学会の場合は、なぜか同じ印刷会社に整形から校正、印刷まで委託しているようですが、せめて英文論文誌は海外に外注に出してもいいような気がします。もちろん左右ページの行揃えなど日本特有の印刷品質は維持できなくなりますが、そもそも紙媒体にするにしても、オンライン化された論文PDFファイルをダウンロードして、プリンターで印刷する限りは無駄な品質ですよね。学会事務もオフショアの時代だと思うのですがね。

2008年4月23日

国際会議の査読論文が15本ほどためてしまって、ひたすら査読です。そんななかちょっとわけがあって、深夜Javaでマルチスレッド絡みのプログラミング(現実逃避ともいいます)。実は久しぶりにWindowsで開発＆実行しましたが、マルチスレッド絡む処理の場合(それも頻繁にスレッドの生成と消滅を繰り返す)、Windowsは速いですね。まぁJava VMがWindowsに最適化してあるというのもありますが、同じプロセッサ(Core 2 Duo)で、クロックはWindows Vista マシンは1.2GHz、一方のMacintoshは1.8GHzなのにWindowsの方がやや速い。もちろん、かなり特殊な事例で、1コアに割り当てる逐次処理ではMacintoshがいくぶん速いのですが、それでもクロック差はない。MacOS XはWindowsと比較してスレッド生成コストが大きいですよね(MacOS XはLinuxとスレッド生成コストと大差ないしね)。もうすこし解析したいのですが、いまはそれどころではないのでパス。

2008年4月22日

さすがにあきたのでCloud Computingの話はひとまずお休み。WebニュースにHDDとSSDのセミナーに関する記事が出ているのですが、なかなかおもしろいですね。SSDはHDDに対して消費電力はアクセス時に3分の1、アイドル時に6分の1、重量は3分の1、耐衝撃性は3倍だそうです。速度比較はありましたが、消費電力の比較ははじめてみました。また2010年には、GB単価の違いが2倍程度と予測されるそうです。また、人間社会の情報量と記憶媒体の総容量に関する議論がありますが、なかなかおもしろい。

2008年4月21日

午前中は先週から始まった慶大の大学院の授業の二回目。まじめに理論計算機科学の話。90分話すとのどがかれますね。ところでそろそろ自分でも飽きてきたのですがCloud Computingのこと。立場上、制度設計的なことを考えないといけないのですが、Cloud Computingになると日本は税収が大きく下がるかもしれませんね。理由は２つありますが、一つ目は直接的な税収減です。Cloud Computingでは利用者側、つまりユーザや企業はコンピューティングやデータストレージはCloud Computingに任せることになるので、ユーザや企業の情報システムのリソースは少なくてもいい。そうなると情報システムへの投資は大幅に減ります。この結果、情報システムの販売・維持に関わる市場は小さくなり、それにともなう消費税収が減ります。当然、システムを販売・維持をする事業者側の売り上げ減になると法人税収も減ります。サービスを実現するソフトウェアはCloud Computingになっても必要なのですが、問題はSI事業者。SI事業ではソフトウェア開発だけでなく、システムやネットワーク構築で稼いでいるのですが、システムやネットワーク構築はCloud Computingのインフラを使えばいいので、業務は激減することになります。いまはSI事業は人気のようですが、長期的には先行きは不透明ですよね(SI会社は学生さんの就職先と有力なのですが、もしCloud Computingが普及すると、ネットワークやデータベースなどのシステム管理スキルへの需要は減るので、いまから就職しても一人前になった頃はいらない人材になっているかも)。いずれにしても一般ユーザや企業の情報システムへの投資は減少することになります。でもCloud Computingのインフラの設備投資が増えれば相殺されるかもしれませんが、日本に限ると国内でそのインフラを維持・運用することはすくないのではないでしょうか。ということで国内ではIT関連の税収は落ち込むことが予想されます。さて理由の2番目ですが、これはCloud Computingインフラがおかれる国と利用者側の国が違った場合におきます。現状の(企業間を含めて)電子商取引では、売る側および買う側も商取引を行う人またはコンピュータはそれぞれの国にあるわけで、商取引に伴う税金は売る側および買う側の国に支払うことになりますが、Cloud Computingの場合は、売り手の商取引サービスも買い手の商取サービスもCloud Computingインフラ上で動いていますから、商取引を発生する国はどこなのかという議論が出てきますし、Cloud Computingインフラが売る側および買う側の国と相違する場合、売る側および買う側の国はCloud Computingインフラ上の商取引を補足するのは難しくなります。もちろん商取引サービスが売り手または買い手が占有的に利用するものであれば単純なのですが、プログラムではなくサービスなので、他の売り手や買い手の商取引を代行しているはずで、特定業者に関わる商取引だけを把握するのは事実上困難でしょう。逆にCloud Computingインフラを保持している国は商取引に関わる税金をかけやすくなりますから、Cloud Computingインフラを持つというとは、貿易都市や商業都市を造ることと同じになります。ロンドンなどの金融都市を作るより、Cloud Computingインフラを誘致した方が手っ取り早いし、税収も多いのではないでしょうか。もちろんそのためにはCloud Computingインフラ設備に電力を安価かつ安定して提供するインフラ整備が必要なのですが、日本は仮に電力供給ができてもダメですよね。理由は地震がありますから。地震のリスクを考えると、日本はCloud Computingインフラの整備・運用に向きません。

2008年4月20日

同じ話題が続いていますが、Cloud Computingのこと。システム的なことはある程度、予測できてしまうので、いまの関心は利用料金。まずインフラの使用料とサービスの使用料は分けて考えますが、前者のCloud Computingのインフラの使用料は利用した計算量、利用時間、ストレージ量、通信量などが重要なファクターになるはず。Cloud Computingはスケラビリティ確保が最大原則になりますから、そのスケラビリティを確保するために使った分だけ払うという料金モデルを導入して、いまのインターネットのようにリソースを使った者勝ち的な状況はさけないといけません。その意味ではCloud Computingインフラの使用料は電気代や水道代に近い存在になるはず。上記の料金ファクターで電気代や水道代に相当するのは、計算量なのですが、コンピューティングの場合、ところでリアルタイム性も要求されるので流量に近い概念かもしれませんね。Cloud Computingインフラ事業は、コンピューティング・データストレージというリソースの提供サービスなので、先物取引的なリソース確保はあると思いますし、卸売り的なビジネスも可能でしょう。つまり前者はリソース予約そのものなのですが、問題は事前予約したリソース使用権の売買が可能になるかですよね。次にサービスの使用料ですが、これはサービスによりますよね。例えば従量課金が向いているサービスもありますが、利用度は少なくても重要なサービスは従量課金に向かない。また、利用者の多いサービスでも従量課金にするのとサービス提供者は売り上げが変動するのをいやがって、月単位などで契約する形態になるかもしれません。料金の徴収はCloud Computingのインフラ事業者が支払い代行をするでしょうが、実はこれまで1セントや1円以下の支払いを扱うマイクロペイメントはうまく行った事例がほとんどないのです。理由は料金支払いシステムのコストが支払額よりも高くつくことも多く、経済学者のいうようにマイクロペイメントはうまくいかない。

2008年4月19日

ここ数日はCloud Computingのことを書いたのですが、問い合わせを受けたのでここで返答しておきます。いくつかあるのですが、一番多いのはいつぐらいにCloud Computingに移行するかです。当方の意見を書くと、良くも悪くも急激にCloud Computingに移行することはないと思っています。やはりCloud Computing向きのサービスとそうでないサービスがあるので、まずは移行しやすいものから徐々に移行すると思いますし、現行手法とCloud Computingのハイブリットな状態は10年以上は続くと想定しています。ただ、大きな流れとしてはデータも計算も、ネットワーク上のインフラに移行してくのだと思います。Cloud Computingに移行する理由がわからないと質問されたのですが、これは単純で、自前でコンピュータを持つよりもCloud Computingインフラを利用したときの方が安くあがるということになれば、企業も個人も経済的合理性にもとづいてCloud Computingへの移行が進むと思います。ただ、最後にダメ押しするのは意外にも環境問題かもしれないと思っています。なんらかの二酸化炭素排出に関わる課税措置などの経済的なペナルティが導入されて、自前でコンピュータを維持するより、Cloud Computingインフラを利用したときの方が二酸化炭素排出が少なってことになれば(ペナルティが減ることになれば)、Cloud Computingインフラに移行するかもしれませんね。一方のクライアント側ですが、計算能力もストレージも少なくて済みますから、性能的にダウングレードするでしょうし、結局、価格勝負の世界になって、100ドルぐらいになるかもしれません。これを考えるとIntelが、稼ぎ頭の高機能x86プロセッサ市場を脅かすかもしれない低価格x86プロセッサ(Atom)に力を入れるのも合理性がありますね。

2008年4月18日

今日も貫徹明けです。6時半頃に出勤。中一日で貫徹だと辛い。さてこのところCloud Computingの話題が続いてしまっていますが、今日もその続き。日本の場合、年金や税金などの管理に巨大情報システムを作っていますが、まぁそのクオリティの問題は別にしても、行政機関のシステムは、年度末などの特定の時期には負荷があがるという傾向がありますが、それ以外は負荷が小さい。しかし、最過負荷時を想定してシステムを作っているので、通常時は無駄にシステム規模が大きく、導入コストも維持管理コストも無駄このため行政機関の情報システムはCloud Computingに向いているといえます。もちろん、日本の場合は行政機関の大規模情報システムは、国内IT 産業というか、ITゼネコンの維持が目的だったりすることもあるので難しいのですがね。仮に行政機関の情報システムがCloud Computingに移行した場合ですが、特に中央官庁の仕事の多くは事務仕事なので、相当数の仕事はCloud Computingインフラ上でデータベースを維持して、そのインフラ上でアプリケーションを動かすことになります。問題はこの先でして、行政機関の情報システムがCloud Computingインフラで維持・運用するようになったとき、行政機関によって違うCloud Computingインフラ提供業者を使っていると、インフラ間の情報交換に費用がかかるので、Cloud Computingインフラ提供業者は集約されていき、特定の御者に国のデータベースと事務処理を任せることが想定されます。こうなると行政情報も情報処理もCloud Computingインフラ提供業者の手の中にあることになります。つまり税金も年金、行政情報もすべてCloud Computingインフラのデータベース上で管理され、サービスもCloud Computingインフラ上で動くになります。例えば税金を考えると、納税も個人や事業者の税金管理サービスが、Cloud Computingインフラ上で動く国税庁や地方自治体の徴税システムに支払うことになり、税金も国家予算もCloud Computingインフラ上で維持・管理実現されることになります。さらに身分証明などもCloud Computingインフラ上で実行されるサービスが発行することになるでしょうし、そうでなくても国が発行した証明書より、Cloud Computingインフラ上で発行された身分証明の方が信頼されるかもしれません。いずれにしても徐々に行政そのものもCloud Computingインフラ提供業者に依存することになっていくでしょう。そうなったら、国そのものがCloud Computingインフラ提供業者に実質コントロールされているような事態も想定されますし、そもそも国家がいまのように維持できるのでしょうか。だからといって国家が行政向けCloud Computingインフラを提供すべきとは思いませんが、Cloud Computingインフラに国が依存した場合に発生する問題の整理、複数の民間Cloud Computingインフラを利用しながら、リスク分散をする方法などは今のうちに検討しておいた方がいいと思います。

2008年4月17日

Cloud Computingの話題が続いてしまっていますが、またCloud Computingの話。さてCloud Computingのサービス記述言語はどのようなものなのですかね。Google App Engineはいまのところ記述言語はPythonだけですが、AmazonのElastic Computing CloudはXenを使っているようでいろいろ対応できるはず。いずれにしてもCloud Computingのインフラ側のコンピュータで動くわけですが、サービス提供事業者などのインフラ提供事業者以外がが開発したコードも実行することになるので、そうしたコードが悪さをしてもインフラ全体への影響を最小限にするために仮想機械やインタープリター内でコード実行して、他への影響をブロックすることになります。このため仮想機械やインタープリター向けの言語が使われることになります。そうなるとネイティブコードの実行を想定し、さらに低水準アクセスができるCやC++のようなプログラミング言語は排除されてしまうでしょう。もちろん、いまのアプリケーションやサービスはCやC++で書かれていることが多いのですが、アプリケーションやサービスだけでなく、開発者も一変してしまうかもしれません。さて話題を戻しますが、どの言語が本命になるかですが、スクリプティング言語、そしてJavaやMiscroft CLR上の言語あたりが本命になりそうですね。ただCloud Computingがまだまだ実験的な段階ですから、Cloud Computing向けサービス記述言語の機能要件がまだよくわからないので、言語を設計したくても誰もできないというが現状ではないでしょうから。もっとも言語レベルで統一化が進むのか、言語を実装する仮想機械レベルで統一化が進むのかがわからないです。特にCloud Computing上のサービスは開発速度が優先されるので、ドメインごとに言語が作られる可能性もありますからね。その場合はばらばらの言語を使いますが、個々の言語に対してセキュア実行機構を作るのはたいへんなので、その場合は言語向けの仮想機械レベルで統一化される可能性が高いですね。

2008年4月16日

昨夜は貫徹状態。午前中の用事は10時からの会議だけでしたが、早朝6時に出勤。さて続いてしまっていますが、Cloud Computingの続きです。Cloud Computingが普及した場合、要求される人材もかわってきますよね。例えばOSですが、Cloud Computingのインフラ側はスケラビリティを重視したOSが使われるでしょうが、クライアント側、つまりユーザはダム端末のようなコンピュータを使うわけですから、ネットワークにつながって、Webブラウザが動けばいいので、たいしたOSはいらなくなります。そうなるとユーザやプログラマーはOSの知識は不要になるでしょう。また、ネットワークに関する知識についても、Webブラウザをつなぐだけですから(Cloud Computingインフラ側の管理者を除くと)いまほどネットワークに関するスキルはいらないでしょう。また、各種サーバやデータベースもCloud Computingインフラに任せてしまうのですから、サーバやデータベースの維持や管理などのミドルウェアのスキルは一切いらなくなります。つまり技術者や開発者に必要とされるプロフェッショナルスキルは一変してしまいますね。逆にプログラマーやSEに必要な知識は、Cloud Computingインフラ上のAPIやサービスに関する知識。そしてそられを組み合わせて所望のサービスを作ることなります。そうなるとアルゴリズム的なプログラミング能力よりも、使い勝手がよくて、利用料が安いAPIやサービスをたくさん知っているか否かが重要になりそうです。ただ、先日も書いたようにCloud Computingの世界は、サービス開始までの速さが命の世界ですから、手っ取り早く開発できるプログラマーが重宝される時代になりそうです。また、SEさんに関しても設計の自由度はCloud Computingのインフラで相当制約されますし、サービスの提供インフラはすべてCloud Computingのインフラに任せればいいので、仕事は相当経るのではないでしょうか。一方、Cloud Computingのインフラ企業側の管理や開発は、現在のIT技術者に近いでしょうが、かなり特殊なスキルになると思いますし、昨日書いたようにCloudComputingインフラの提供会社が数社の巨大企業に集約されていくと、ごく少数のIT技術者だけの世界になってしまうでしょうね。おそらく自前で、コンピュータにWebサーバを立ち上げたり、データベースをインストールするというのは、今の時代に自動車や家を自分で作って住むのと同じぐらい、危なっかしいし、コスト的にも見合わない行為になるのではないでしょうか。

2008年4月15日

またまたCloud Computingの話題ですが、なんで拘るかというと個人的にはGoogle App EngineやAmazonのElastic Computing Cloudなどが先兵をつけたCloud Computingは、情報サービスやそしてコンピューティングを根本的に変えてしまう大きな変化だと思っているからです。Cloud Computingが普及してしまうと、いまのPCで使われているビジネスアプリケーションやコンシューマーが使うアプリケーションに必要な処理やデータは、Cloud Computing上にある各種サービスを使えばよくなってしまうのではないでしょうか。PCは常時接続とWebブラウザが使えるだけのコンピューティングがあれば十分という時代になって、昔のダム端末に近い存在かもしれません。また各種のネットサービスを提供する企業もCloud Computingによって提供されたインフラを使えばよく、自前でサーバを立ち上げたり、データベースを構築することはなくなるでしょう。むしろCloud Computingインフラの利用者側の企業間でデータベースを共有する、つまりビジネス上の最重要情報を共有することが前提とするビジネスモデルも出てくるでしょう。さてCloud Computingのインフラ提供企業ですが、当初は小中規模のインフラ提供企業もあるでしょうが、ある程度の規模が必要なことを考えると、長期的におそらく現在のネットビジネスの列強、Google、Amazon、Microsoft (+Yahoo)、eBay, Salesforcesあたりが核になって、吸収・合併を繰り返して、最終的には少数だけになるのではないでしょうか(おそらく3つぐらい)。もちろん、10年以上の時間がかかるでしょうが、現在PC上でのほとんどの処理はCloud Computingに飲み込まれていくことになるでしょうし、またそのときにはコンピュータは少数の巨大インフラ提供企業のなかだけで使われる特殊な機械という存在になってしまうかもしれません(もちろん組込系コンピュータはたくさん使われるとは思います)。IBMの初代経営者であるThomas J. Watsonは1940年代後半に「コンピュータにはせいぜい5台分の市場しかない」という発言をしているのですが(この発言は捏造らしいですが)、これは実は正しかったといえる時代がくるかもしれません。

2008年4月14日

昨日の続きです。商業Cloud Computingサービスは、コンピュータサイエンスの研究にどのような影響を与えるのでしょうかね。個人的にはCloud Computing以前、つまりWebサービスはアカデミア研究になりえないという認識でおります。アカデミアでもWebサービスの研究をされている方はたくさんおられるので、袋たたき似合いそうですがね。その理由ですが、例えば研究として新しいWebサービスを思いついたとしても、それを論文に書いて公知になるまでには時間(国際会議なら半年、論文誌だと1年)がかかります。一方、Webサービスの場合は小規模のものであれば比較的短時間で実装ができますし、それを公開して、実ユーザに使ってもらうということもできてしまいます。そうなったら論文を書いているよりは、提案したサービスを公開して、実ユーザに使ってもらった方がいい。サービスを使って好評か否かを調べた方が確実に研究の善し悪しを評価できますし、その方が時間的にも早い。さてCloud Computingサービスは、Webサービスでは必須だったサーバを自前で用意するというステップを省きますから、サービス開始までの時間は短くて済みますし、機材もお金もなくてもサービスを開始できることになるので、研究予算がないのでサーバを買えなとかといういいわけはもう使えない。その意味では個人レベルでも大企業と並ぶようなサービスを提供するケースが出てくるでしょうし、腕のいいプログラマーさえいれば、アイデアを思いついてから、サービス提供まで1ヶ月もかからずに実運用までもっていけるはず。いずれにしても論文という評価基準を規範とするアカデミア研究は、Webサービス以上にCloud Computingの時間の速さについていけないことになります。さらに商用Cloud Computingサービスが普及すると、サービスを実現する基盤システム、つまり研究のコアになる部分は、GoogleやAmazonなどのCloud Computingサービスの提供企業に握られることになりますから、何を研究すればいいの？という自体になってしまうかも。

2008年4月13日

Google App Engineのベータ版ですが、先着アカウント取得に失敗したのですが、近日中に追加アカウントがあるようですね。App Engine SDKでスタンドアローンで遊び始めているのですが、開発用のプログラミン言語のPythonはすっかり忘れている始末。まずはPythonのお勉強のし直しが必要だったりします。それにしてもスクリプティング言語は、お手軽な反面、すぐ忘れますよね。Google App Engineですが、キーテクノロジーはデータベースだと思いますが、Webのように通信コストが大きい状況では関係データベースはいいとはいえず、新しいデータモデルが必要となるかもしれませんね。ところでGoogle App Engineはお値段的にはどうなるのでしょうね。ちなみに同じCloud ComputingサービスであるAmazonのElastic Computing Cloud (EC2)は、最小構成ではメモリ1.7GB、ディスク160GBの場合、時間あたり$0.10、データ転送は1GBあたり$0.10だったりします。個人的には破格にやすいと思うのですがね。それにしてもこうした安価なデータ＆アプリケーション実行サービスのインフラが出てくると、便利になった反面、研究としてはやりにくくなるのも事実。クライアントまわりだでなく、サーバまわりも研究テーマもなかなか難しくなってきます。それでもクライアントまわりよりは研究テーマが残っているでしょうが。いずれにしても、これからのコンピュータサイエンスはは、純粋にコンピュータサイエンスを突き詰めるのではなく、自然科学や実社会の特定分野にコンピュータサイエンスの手法を使って、効率化したり、付加価値をあげることになるのかもしれません。

2008年4月12日

Windows Vistaはサービスパック1(SP1)のリリースにあわせて、大幅値下げだそうですね。MicrosoftによるとVistaは売れているということになっていますが、やはりいろいろ問題があるのでしょうね。個人的にはVistaのGUIには馴染めないのですが、そのGUIは別にすると.Net Frameworkベースの高水準APIなどみるべき点は多いと思いますが(使いたいかとは別ですけど)、もちろんそうした高水準APIが性能を悪化させている元凶ではありますが、コンピュータサイエンスの研究者としては何が性能を下げているかを知るのも仕事なので、構造を知ると同時に、実際にいろいろ試してみることは大切だと思います。いずれにしてもコンピュータサイエンスの研究者としては、いい悪いとか、好き嫌いとかは常に最新のOSを使っていないといけないので、Vistaも使うことになります。コンピュータサイエンスの研究者にとってはコンピュータは研究の対象なので、古いハードウェアや古いOSを使っているようでは時代にあった研究ができるわけがないのです。また、特定のOSやハードウェアに依存しないことも大切なのですが、Windowsしか使わないとか、Macintoshしか使わないとかだと、そのOSの世界しかしらないわけで、OS共通の機能とOS独自の機能が区別できないのです。コンピュータサイエンスの研究している以上は、複数の最新OSを使い続けないのですよね。人間ですから、慣れたOSの方がいいので、複数を使うのは結構たいへん。でも仕事ですからね。

2008年4月11日

科研費萌芽の採択結果の通知。以下は大学業界でないとわからない内容です。すみません。当方の勤務先は科研費の全国採択率ベスト５内を毎年度キープしているそうで、不採択はランキングに悪影響を与えるのでなかなか許されない雰囲気だったりするので、ほっとしますよね。ただ、予算はいただいてからがたいへんなのですよね。当たり前ですが予算に見合った、またはそれ以上のアウトプットを出さないといけませんから。この萌芽以外に基盤(B)もあるので(どちらも研究代表者)、二つを同時に研究するには相当心してのぞまないといけません。ところで、毎年この時期に閉口するのは、予算額や件数を自慢するメールを送ってこられる方々。早速、そうしたメールをいただいたのですが、まぁ御本人は悪気がないのでしょうが、片手では数えられないほどの科研費(分担者を含む)をとって全部きっちり研究できるのでしょうかね。他人事ながら心配になったり。ただ、研究ではなく研究予算を獲得することが目的化しているとしか思えない方もおられますがね。いずれにしても研究者ならば予算額を自慢するのではなく、自慢でできるような研究成果を出さないといけないですね。ところで「萌芽」って、一般ではあまり使わない用語だと思いますが、意味はわかるようでわからないですよね。まさか昨今流行った「萌え」と関係があるわけはないですよね。

2008年4月10日

新国立劇場でWeberのオペラ「魔弾の射手(Der Freischutz)」を鑑賞。先月、同じ新国立劇場で出来がすごくよかった「アイーダ」を観たばかりなので(それも2回も)、アイーダと比較してしまうとちょっとがっかりなのですが、国内オペラとしてはよい出来ではないでしょうか。特にヒロイン役(Agate)は若い歌手(Edith Haller)だったのですが、これがすごくいい出来。主役(Max) のAlfons Eberzはいい歌手のようですが、初日ということもあってまだ調子がでていないのか。隠者役の歌手(妻屋秀和)はよかったですね。舞台装置や衣装、演出もいろいろ新しい挑戦をしているのは好感なのですが、なんか消化して切れていない感じ。演奏は冒頭のホルン重奏がウリなのですが、音があっていないなど演奏は？でした。ただ、やはり「魔弾の射手」という演目そのものに、観客を引き込む迫力がないのです。同じドイツオペラでもワグナーのつもりで観に行くとがっかりするかも。さて今晩で今シーズン(2007-2008)でみたオペラは9つ。今シーズンも10本は見られますでしょうか。

2008年4月9日

次期Windowsの噂がちらほら聞こえはじめしたが、カーネルよりもWinFSを乗せてほしいですよね。ご存じのようにWinFSはWindows Vistaに搭載予定だったけど、結局、搭載されなかった機能。たまたまWinFSのデモビデオをみつけたのですが、確かにこのデモビデオのことができれば、Windows Vistaは時代を変えたOSとして名を残したかもしれません。OSの最も基本機能の一つであるファイルシステムは、データの保存やアプリケーション間でのデータの共有です。こうした機能に立ち返ってほしいところです。WinFSは関係データベースをもとにしていますが、XMLベースのデータが増えている状況では、ファイルシステムの代わりにXMLデータベースにしてしまってもいいかも。それはそれで問題山積なのですが、PCが閉塞状態になっている以上は、次期Windowsには互換性よりも斬新な機能を期待したいところです。

2008年4月8日

PCはダウングレードの時代ですよね。IntelのAtomプロセッサ搭載のPC(NettopやNetBook)の価格レンジはディスプレー込み4万円以下。Atomは非力とはいえ、x86プロセッサ。Windows XPが発売された頃のスペックと考えれば、メールやWeb ブラウジング、簡単な文書作成や表計算であれば十分につかえるはずで、現在のPCのような高性能マシンを一般コンシューマーがわざわざ使う必要はなく、安価PCで済ますことが多くなるでしょうし、それにともなって光ディスクも大容量ハードディスクもいらないということになりそう。そうなると高価格PCで利益を稼いでいる国内PCメーカはつらいことになるのですが、ただ日本の場合、すでにPCの普及率が高いことですから、セカンドマシンとしてAtomプロセッサ搭載のPCの需要がそれなりにあると思いますが。いずれにしてもPCは性能ではなく価格重視になるでしょうし、その性能も初期のWindows XPマシン程度で落ち着いてしまうかもしれません。研究者としてはPCの性能はあがることを前提に、研究している時点のPCでは遅いアルゴリズムも過負荷なシステムも、将来のPCはサクサク動くというと仮定して研究してきたわけですが、これから現時点で遅いアルゴリズムや過負荷なシステムは、将来も遅く、過負荷のままかかもしれません。いずれにしてもPC用のプロセッサは価格が重視されるでしょうし、サーバ用のプロセッサは電力あたりの計算性能が重視されることになるのでしょう。

2008年4月7日

Sun MicrosystemsがJava SE for Businessというサービスを始めるようですね。まだざっと概要をみただけですが、通常のJava SEはサポート期間は3年間ですが、それを最長15年間までのサポートを約束するものだそうです。いまだにJava SE ver.1.4を使っているシステムは多いですから、結構、需要があるかもしれませんね。料金は従業員数で換算するそうですが、グレードによりますが、従業員一人あたり年10〜12.5ドル。古いバージョンを使っている企業は小規模なところがおおいですから、結構リーズナブルかもしれませんね。Javaは"Write once, run anywhere"という理念を掲げていますが、現実にはバージョンに依存している部分も多い。その一方でJavaで書かれたソフトウェア資産が増えてしまった状況では、これからは下位互換性を重視しないといけないということなのでしょうね。

2008年4月6日

IntelのAtomの続きです。4月3日のこのページでMicrosoftのAtomへのサポートがないに等しい、と書いたのですが、その日にMicrosoftはAtomなどを搭載した小型PCを想定してWindows XP Homeの販売延長を発表していたのですね。4月3日にも書きましたが、Atomへのサポートを怠ると、Atom搭載マシンはLinuxばかりになってしまいそうですから、Microsoftとしても静観できなかったのでしょうね。Windows Mobileを除くと、Microsoftにしてみるとマシンスペックが下がるというのは初めて経験だったのではないでしょうか。誤解している人が多いのですが、Microsoftにとってもお客さんは、エンドユーザではなく、WindowsのプレインストールしてPCを製造・販売するPCメーカ。そのお客さんであるPCメーカに儲けさせるためには、PCへの要求マシンスペックが常に高くして、PCの価格が下がることを防ぐことです。その意味ではWindows Vistaのような高スペックを要求するOSはお客さんの想いのすぐれたOSといえます。今回のWindows XP Homeの販売延長は、Windows XPとWindows Vistaという二つのOSの併売ということ以上に、Windowsのビジネスモデルの大きな転換になりますし、PCメーカにとってもPC価格の低下という事態になりかねない大きな変化ですね。次期Windowsでは、低スペックマシンから高スペックマシンまで対応できるようなOSを作らない限りは、Windows XPをまだまだ販売を続けることになってしまいます。この場合、Windows XPが長期にわたって標準的なOSとなって、結果としてOSの進化は遅くなりそう。逆にMicrosoftが低スペックマシンから高スペックマシンまで対応できるOSが提供できたとしても、OSがGUIと一体化された現状では、エンドユーザが低スペックマシン用の使い方になれてしまうと、高スペックマシンの高度なGUIはユーザから求められることが少なくなり、結果として高スペックマシンでも低スペックマシン用GUIを提供することになりかねません。もちろん、ユーザがそれでいいと考えるのならば仕方ないのですが、今後コンピュータの技術トレンドは保守的なものになっていくのでしょうね。IntelのAtomは、通常x86プロセッサの売り上げに影響するでしょうから、Intelにとっては諸刃の剣になるでしょうし、MicrosoftにとってはOSの機能的な進化が難しくなり、Windows XPまたは相当のOSを長く売り続けることになり、(新規開発が減るので)利益は上がるかもしれませんが、売り上げは減少をもたらしかねない。そしてコンピュータ技術にとっては低スペックのコンピュータが市場にあふれることになって、長い停滞の時代を作ってしまうかもしれません。

2008年4月5日

三菱東京UFJ銀行は旧東京三菱銀行と旧UFJ銀行の統合作業のため、4月の週末からシステムを止めるそうですが、おおがかりですよね。実際、システム統合に伴う費用は3300億円だそうですが、みずほ銀行のような事態をさけるために慎重にやるつもりなのでしょうが、この費用は尋常ではないです。両銀行のシステムは大きく違っていますし、旧東京三菱はIBM製、一方、旧UFJは日立製。特に旧UFJ は基幹システム系はメインフレームですが、それ以外はLinuxを多用する斬新なシステムだったのですが、旧東京三菱のシステムを拡張することで統合することになったようですね。今の時代、銀行はシステム産業ですから、システムの出来不出来が銀行の善し悪しを決めることになりますし、行員の人事評価もシステムが使いこなせるか否かは大きな要素になりますから、銀行統合ではシステム的に主導権をとれなかった銀行(つまり吸収された銀行)の行員は、(不慣れな)吸収した側のシステムを使うことになり、システムが使いこなせない＝能力不足のレッテルを貼られて早々に辞めていくことになります(というか辞めさせられていくというのが正しい表現かもしれませんが)。実際、過去の銀行統合では、吸収さえた銀行の行員さんは統合後5年もたつと1割以下になっているそうですね。もちろん例外はあって、三菱銀行と東京銀行の統合の時は勘定系システムは三菱銀行をベースになりましたが、情報系システムや外為系システムは東京銀行のシステムをベースにしたようで、どっちが吸収したのかわからないような感じでしたがね。ただ、三菱東京UFJ銀行では今回の統合で、旧UFJ銀行のシステムは一掃されることになりますから、今後は旧UFJ銀行出身者はたいへんだと思います。こうかくと冷たい表現と思われますが、これが企業吸収合併の現実ですからね。さて今回のシステム統合を仕切るのはIBMですが、IBMとしては三菱東京UFJ銀行のシステムをとれるのは大きいですが、今回の統合作業は必要な人員が多いですから、人員的にはたいへんではないでしょうかね。ちなみに旧UFJ銀行のシステム(日立)ですが、ゆうちょ銀行が引き継ぐことになりました。正しくいうとゆうちょ銀行のシステムを請け負ったNTTデータが日立からUFJ用開発したシステムを流用することになりました。開発費を押さえるという点では正しい判断のですが、すでにシステムの設計は新しいとはいえず、今後の金融商品の拡大に対応できそうもありませんね。

2008年4月4日

AppleのiTunes Storeは今年の1月と2月に楽曲販売数でWal-Martの販売数を抜いたそうですね。ということは全米では音楽販売でトップになったということになります。Appleはコンピュータメーカとしてではなく、コンテンツ販売業者として扱わないといけないのでしょうね。当面、音楽小売ビジネスはAppleを中心にまわっていくことになりそうです。

2008年4月3日

IntelがAtomを発表しましたね。問題はMicrosoftがWindows Vista系もWindows Mobile(Windows CE)系でも低消費電力用パッケージを用意するつもりがないようです。x86系プロセッサ向けOSのノウハウを一番持っているのはMicrosoftでしょうから、Microsoftにとって大きなビジネスチャンスだと思うのですが、いったいどうしたのでしょうかね。特にWindows Mobile系はここ数年は進化がとまっていますよね(もちろん組み込み系市場は保守的なのはわかりますがね)。そうなるとIntelとしてはLinuxをベースにしたAtom用のOSをIntel自身がサポートしないといけないことになりますね。もしかしてMicorsoftはLinuxを側面しているのではないかとまで思ってしまいます。ところで近々Appleが次期iPhoneの発表するという噂ですが、次期iPhoneにIntelの新型x86系小型プロセッサのAtomを搭載してくるでしょうかね。現行iPhoneのプロセッサはARM11のバリエーションの一つだそうですが(ちなみにクロックは620MHzらしい)、問題は消費電力ですよね。AtomはARM11に対して同クロックならば2倍程度ありますが、商品電力はARM11系の場合、製品によりますが、0.50mW/MHz以下。Atomの場合は800MHzの製品の場合でTDPが650mWだそうですから、消費電力は悪くなる可能性が高いので、Atomを搭載する場合はアプリケーションに応じてクロックをきめ細かく制御することが前提になりそう。その意味ではハードウェアもOSも作れるAppleならばAtomを使いこなせる可能性がありますが、消費電力制御はそのノウハウやパラメータを蓄積するのには時間がかかります。仮にIntelが事前に情報を出しているにしても、すぐにAtom版を出荷するのは難しいのではないでしょうかね。もちろんバッテリ持ちよりもプロセッサ性能を重視するのであれば話は別ですがね。それからARM11で思い出したのですが、ご存知のようにiPhoneはJavaを搭載していないのですが、ARM11系プロセッサならばJava用アクセレーターであるJazelleを搭載している可能性は高く、プロセッサ的にはそれなりの速度で動かせるはずなのです。Jobsのいうようにメモリ量的につらいというのはただしい見解でしょう。もちろんビジネス戦略的にJavaをサポートしたくないというのはあり得ますがね。

2008年4月2日

33種のメモリカードに対応したUSBカードリーダだそうです。この製品のメーカの仕様をみると無理してメモリカードの種類を増やしている部分もありますが、それにしても種類が多いですよね。

2008年4月1日

今日から新年度。その前に前年度の宿題を終わらせないと。

昔の日記へのリンク