楽天テクノロジーカンファレンス2007という催しがあったようです。
＠ITの記事によると

2007年11月24日、「楽天テクノロジーカンファレンス2007」において、Ruby言語の開発者で楽天技術研究所フェローのまつもとゆきひろ氏は、開発中の大規模分散処理基盤「Roma」（ローマ）と「Fairy」（フェアリー）のコンセプトを語った。研究段階ではあるものの、米グーグルなど世界トップクラスのネット企業だけが持つ大規模分散処理技術に真っ向から挑戦する試みだ。
(中略)
Romaの応用として、巨大セッションを保持するコンテキスト基盤などを考えている。Romaの技術的な位置づけは、米グーグルの「GFS」（Google File System）、米ヤフーの「Hadoop」（ハドゥープ）、米オラクルの「Coherence」（コヒーレンス）、米アマゾンの「Dynamo」（ダイナモ）など大規模分散ストレージ技術と似ている。楽天技術研究所代表の森正弥氏によれば「特にDynamoに位置づけが近い」とのことである。
(中略)
楽天取締役常務執行役員 チーフプロデュースオフィサー開発・編成統括本部長の杉原章郎氏は、カンファレンスの狙いについて「楽天のテクノロジーを知ってもらい、社内外への刺激としたい」と話す。「現在、楽天社内と協力会社を含めて1100人規模の技術者がいるが、3年後には3倍といったスケール感で数を伸ばしていきたい。当然、東京の開発者だけでは足りない。すでに全国主要都市に開発拠点を立ち上げつつあるが、海外拠点を作ることもありうる」

楽天というと、「古い・遅い・使いにくい」というイメージがあります。特に楽天ショップはいくつものアプリケーションが混在していて、キメラのようなサービスです。外部向けにAPIなどを昨年やっと公開しましたが、いまだに楽天ポイントなどの連携はCSVファイルをFTPアップするといった仕様が残っていたりと、「技術的に時代遅れな会社」という実情です。

こういったカンファレンスを開くのは、「楽天＝ネット技術のリーダ」というブランドイメージをつくるためだとおもいます。

さて、タイトルでは楽天OSとつけましたが、「Roma」は実際にはどうなのでしょうか？

プラットフォーム開発ナメンナよ！

Romaの詳細を読む前の第一印象です。
分散ストレージは、いくつもの会社がH/W、S/Wに莫大な投資をしてディスクシステムとしての信頼性とパフォーマンスを向上させています。H/W製品の開発もしたことのない会社がつくるソフトウェアアプローチの分散ストレージシステムなんてオモチャだろう・・・と常識的に考えれば一笑にふすところです。

記事内容を少し読み進めると・・・

まつもと氏は、Romaのコンセプトについて「CPUやネットワークに比べてハードディスクの速度は上がっていない。メモリ上にデータを保持し、マシンを大量にネットワーク上にばらまいたら、そちらの方が速い」と説明する。「単にメモリを分散するだけならmemcached（注：大規模Blogサイト LiveJournal.comの性能向上のために作られたオープンソースの分散キャッシュ・システム）でいいと思うかもしれないが、マシンを1000台並べ、そのうち1台が壊れても止まらない信頼性と一貫性を確保することを考えると、より高度なアイデアが必要。ただしその分、実用化までには壁がありそうだ」（まつもと氏）。

Dynamoに近いシステムで上記のような仕組みを考えているそうなので、P2Pアプローチのキーとオブジェクトをペアリングできる巨大なハッシュテーブルだということがうかがえます。

かわいそうに・・・技術者の玩具に、技術をわからない経営層が踊らされている

巨大なストレージシステム(現在だと100T Byte以上)を構築する場合、一般には集約型で構築します。集約型のメリットは管理コストが安い点にあります。そのかわり、ストレージにアクセスが集中するためパフォーマンスをだすために、分散型キャッシュを導入するようになります。特に、大企業などでいろいろ地域に業務拠点をもっている場合は、ネットワークのレスポンスも配慮して、各拠点にキャッシュが保持されます。また、巨大なストレージシステムはH/Wコストは高くなりますし、導入コスト・時間などもかかります。

これに対して、パソコンは安いから、みんなのパソコンに少しずつファイルを置かせてちょうだいよというのが分散型ストレージシステムに根底にある思想です。ファイルデータを細切れにして、いろいろなパソコンに多重に配置して、一番負荷の少ないパソコンから、ファイルデータを読み出してくるという仕組みです。

これね・・・読込み(Read Aaccess)特にランダム読込みはそこそこ性能いいんだけど、書込み(Write Access)の性能がでないんですよ。理由は下記の図をみてください。

もう1点致命的な設計思想上の欠落としては、「メモリ上にデータを置いた方が早い」という点です。そりゃ、早いよ、でも全データなんてメモリに置けません。いま、一番廉価な価格帯のPCサーバだと4GByteのメモリを載せるのがコストパフォーマンスがよいですが。1000台=4T Byte用意するために2~5億円必要です。(分散サーバなので冗長性分やOS利用分を配慮しないといけませんが・・・省略します)
これに対してNECのiStorageですと、S1850ATでも16Gが最大ですが1~3000万円くらい。コスト差20倍です。

単一のアプリケーションで4TByteものファイルデータをメモリにおく需要なんてほとんどありません。もし4Tもファイルがメモリ上に展開されていないとパフォーマンスが発揮できないのだとしたらアプリケーションのアーキテクチャが悪いのです。

その中でどうしても単一のアプリケーションで巨大なファイルを利用する必要があるのがDBです。うっかりしているとDBファイルのボリュームが100GByteを超えることがあります。
おそらく、各社の分散ストレージの開発者達は、DBのファイルの利用を前提に考えているかとおもいます。そうなると、インターフェイスはファイルシステムではなく、SQLをインターフェイスにした、分散DBシステムをつくったほうが需要があります。

この場合、完全なシンメトリっくなシステムにするのではなく、クエリのコンパイルスケジューリングをするノード、インデックスを管理するノードと、データエンティティを管理するノードを別のグループとして設定し、ノードのキャッシュデータを局所的に同期するような工夫があるとすごくうれしいですね。懸念としては、行ロック情報の同期負荷を軽減するために、ロックエスカレーションがおきやすくなるのではないかという点です。

DBは既存品を使ってファイルシステムレイヤーのソフトウェアの工夫だけでDBのパフォーマンスを向上させることができれば大変素晴らしいのですが、DBの場合Insert、Updateのコミットデータのキャッシュ同期だけでシステム全体をブロックしてしまうので、分散ストレージは読み込みのためにしか機能しません。それだったら、DBレプリケーションをしっかり設計した方がシステムとしてはずっと安定性が高いというものです。

開発者の方は反論あるでしょう、GoogleのGFSという実績もあります。
ですが、Romaというシステムが楽天のメインストリームサービスで利用されることはないと予測します。

たんなるブランド形成なんでしょうねー。でも楽天の迷走感のほうが表にでてるなぁ・・・。

万能細胞(ES細胞=Embryonic Stem cells)に関する研究は、中国などで実際の再生治療に使われ始め、ここ数年メディアに多くとりあげられています。

ES細胞の培養には人の卵子を必要とするので、キリスト教圏では倫理的に研究に対して政府が助成金をださなかったため、アジア圏での研究が盛んであるという興味深い状態が続いていました。(韓国では偽論文で大騒ぎになるほどです)

万能細胞のすごいのは、拒否反応ゼロの臓器をつくれるという点です。この技術が医療現場に普及し一般化すると、臓器系の疾患はすべて移植で治療できてしまいます。また、脊髄損傷などの神経系の治療にもなります。おそらく、研究が続けば老化に伴うほとんどの病気が克服できるでしょう。

乳児死亡率の低下と抗生物質が平均寿命を格段に伸ばしたように、万能細胞による医療進歩は先進国の平均寿命を10～30歳ほど伸長することになるはずです。将来的には、環境・食糧・エネルギー問題を別にすれば2050年以降に生まれる人間たちの平均寿命は120~150歳になるのではと夢想しています。(医療データをもとに厳密な推測してみたい・・・)

山中教授[ Wikipedia ]の研究が画期的なのは、卵子を利用しないで万能細胞(ヒト人工多能性幹細胞（ｉＰＳ細胞）)を作り出すことに成功した点です。

記事を引用すると・・・次のようなことらしいです。

京大の山中伸弥教授と高橋和利助教らは、体細胞を胚の状態に戻し、さまざまな細胞に分化する能力をよみがえらせる「初期化」には四つの遺伝子が必要なことを発見し、昨年８月にマウスの皮膚細胞からｉＰＳ細胞を作ることに成功。これを受け、世界の研究者がヒトのｉＰＳ細胞の開発を目指し、激しい競争を繰り広げていた。

　山中教授らは、マウスでの４遺伝子と同様の働きをするヒトの４遺伝子を成人の皮膚細胞に導入し、ヒトのｉＰＳ細胞を開発することに成功。この細胞が容器内で拍動する心筋や神経などの各種細胞に分化することを確認した。ｉＰＳ細胞をマウスに注入すると、さまざまな細胞や組織を含むこぶができ、多能性を持つことが示された

 これで、倫理的な問題を回避し、拒否反応のない万能細胞を低コストに生成することが現実的になりました。

ウィスコンシン大学のジェームズ・トムソン[ Wikipedia ](James A. Thomson)教授の研究も取り上げないのは不公平でしょう。

 両者の研究は、ES細胞のどの遺伝子(山中：Oct3/4,Sox2,c-Myc,Klf4) (Thomason:OCT4, SOX2, NANOG, and LIN28)を組み込むかという違いがあるものの、アプローチも一緒ですし、発表も11月20日と同じです。

山中教授のCell論文 Induction of Pluripotent Stem Cells from Adult Human Fibroblasts by Defined Factors(PDF)

James A. ThomsonのNature論文 Induced Pluripotent Stem Cell Lines Derived from Human Somatic Cells (有料PDF)

Cellは過去の論文も全部読めるよ・・・すごい、感動だ。(問題は読んでも理解できない点)

論文はともかく、万能細胞研究は日本の医療費問題を根本解決できるくらい夢のある技術なんだから行政はもっとしっかりバックアップしてほしいですよね。500ページの報告書を書かせると研究が進むとおもっているんでしょうか？

Yamamoto Said:
There were two terrible flaws with official Japanese attitudes to stem-cell research, he said. To illustrate the first, he pulled out a 500-page wodge of paper. This, he said, is what I have to fill out in triplicate every time the laboratory wants to use a single human embryonic stem cell for a single experiment.

5年で70億円とか言ってないで、もっと障害を取り除くようにしてほしいですよね。

His second attack was on the dangerous fickleness of Japan's Health Ministry - a fault that effectively forced hugely promising long-term scientific projects either to be squeezed uncomfortably into too short a space of time or abandoned due to lack of funding.

関連ニュース：

Breakthrough Set to Radically Change Stem Cell Debate

Is the synthetic stem cell Japan's greatest ever invention?

関連データ：

基礎知識

Visual Studio 2008の正式出荷が始まりました。

VS2005の出荷が2005年末でしたから2年経っていません。
うちの会社ではようやく先月全員がVS2005に移行したばかりだというのに・・・。レガシーなコードまだいっぱい残っているのに・・・。

Visual Studio 2008の大きな特徴といえば.Net Framework 3.5で導入されるLINQでしょう。DBへのクエリーをC#のコードレベルで動的に生成できるので、複雑なクエリーもプロシージャではなくアプリケーションレイヤーで記述することができます。

SQLに造詣の深い方にはあまりメリットを感じないかもしれませんが、実行時ではなくコンパイル時にクエリーのタイプミスなどを発見できるので、検証クオリティがあがります。実際、私の会社では、ストアドプロシージャは原則禁止で、社内製のSQLクエリー生成オブジェクト経由でDBアクセスをしています。

LINQのクラスライブラリをざっと眺めてみると、どのような複雑なクエリーでも書けるかというとちょっと苦しい部分もあります。高度な副呼び出しや、ロックヒントをきめ細かく設定しようとすると、直接クエリーを書いたほうがいいです。

感覚的にはLINQ関連のライブラリに一層ラッパークラスを被せておいて、多頻する記法を使いやすくする工夫が必要な気がします。

開発環境が定期的にメンテされるのは開発者にとって大変ありがたいことですが、2年に1度メジャーバージョンアップだとちょっとペースが速くてついていくのがつらいです。

1.0 → 1.1 → 2.0 → ( 3.0 → ) 3.5、このように変遷してきました。
1.1で本格的に.Net FrameworkのライブラリとASP.Netの開発作法を習得している矢先に2.0がでてきてしまっています。
1.1のweb.configやmachine.configの記法すら全部覚えていないところに2.0がでてきて、機能差分や挙動の違い、1.1と2.0を共存させるノウハウなんかを身につけなくてはと苦しんでいるところに、3.5です。(3.0は無視)

お願いだから、VM実行環境を下位互換もつ形にしてほしい・・・。Webアプリにはつらすぎます。

歳を経るにつれて、自分がどんどん馬鹿になってる・・・という恐怖に襲われることがあります。

定期的に記録している自分への客観評価を見る限り、視野は広がり、知識は増えているようですが、それでも「昔はもっと賢かった気がする」という気持ちになります。

コンピュータの研究をしていたころは、与えられたドメインの中で新しいものを探しますが、「けっ、このドメインには簡単に成果の出せる新しいものなんてなんにもないぜ」なんてヤサグレていました。

所かわってビジネスの世界で、「限られた予算の中で新しい商売を見つける」というテーマにとりくんでいます。
そうすると、「もっと予算があればなんでもできるのになぁ」と思うようになります。でも、これってないものねだり以外のなにものでもありません。限られたリソースの中で最適解を見つけるというゲームみたいなもんだと思うと気が楽になります。

研究という仕事と、経営という仕事は似た苦しみを持っていますが、チームで働くことの相乗効果が得やすいため、経営のほうがずっと効率が良いです。まあ、昔いた研究組織は、個々の能力に寄り過ぎて、チームで成果を出すことに無頓着すぎました。それがわかっていながらもマネージメント層は大組織ゆえに問題を改善することができなかったようです。

そんな経験を通して、最近もっと賢くなりたいと強くおもうわけです。

賢さって、強さとか、優しさなんかと同じで、元来相対的なもので絶対的な尺度のあるものではないわけです。全知全能などという絶対的な賢さは欲しいけど、本気でそんなことを考えているようでは脳味噌がとろけています。実際には、自分の競争相手より賢ければいいわけです。

ところが、ソフトウェアの世界だと、競争相手が世界じゅうなのでそれが簡単ではないわけですよ・・・。うにゃうにゃ

SeesaaとかFC2とか無料ブログにはかっちょいいJavascriptのHTMLエディタがついていて、文字装飾が簡単にできるんだけど、自サーバのMovableTypeだと、HTMLを直接かく必要があってなかなか、見栄えに凝ることができませんでした。

MT4にはHTMLエディタ標準搭載なのよ！

・・・でもちょっといまいち。Font装飾がないじゃん・・・、色は自分でつけるのか。

ついには、テストコードまで書きはじめモジュール単位でテストをし始めてしまったのですが、ふと我にかえってエラー文を読み直してみました。

unblessed referrence......unblessed.....

Perlはまったくの素人なので、unreferrence・・・参照メソッドがないって思いこんでいたのですが、エラーが言っているのはblessされていない参照ってことです。
コードではしっかりとオブジェクトがブレスされているのですが・・・・

他にも苦しんでいる人がいる・・・・・

も、もしや、ベータ版から上書きしている人には呪いがかかっているのでは！

・
・
・

解呪

どうもプラグインフォルダにのこっていたExtensibleArchivesが癌らしい。

同じ苦しみを味わっているひとに少しでも祝福を！

先日セットアップしたMovableType4.01に本格的に移行しようとおもい、新しいサーバにMySQLとPerlをインストールして、データを移行しました。
インポートも無事にすみ、さあ再構築！というところでエラーです。

close Can't call method "archive_label" on unblessed reference at lib/MT/App/CMS.pm line 13925.

Can't call method "entry_class" on unblessed reference at lib/MT/App/CMS.pm line 13215.

    if ( $at && $at ne 'None' ) {

        @blog_at = split /,/, $at;

        foreach my $t (@blog_at) {

            $archiver = $app->publisher->archiver($t);

            next unless $archiver;    # ignore unknown archive types

            push @at, $t;

            $archive_label = $archiver->archive_label;

            $archive_label = $at unless $archive_label;

            $archive_label = $archive_label->()

              if ( ref $archive_label ) eq 'CODE';

            push(

                @data,

                {

                    archive_type       => $t,

                    archive_type_label => $archive_label

                }

            );

        }

    }

Blogの公開設定がきちんとされていない場合は、公開設定をするように警告すべきところのロジックになんらかのバグがあるっぽい。
なんかarchive(書庫)関係のデータがNull参照しているっぽい。

データベースがなんらかの不整合を起こしている可能性を疑い、新しいDBインスタンスや、SQLLiteに変えてみても改善の兆候がないです。

ネットで原因探そうにも、「IIS MovableType 4.0」とかで検索すると自分のサイトが一番上にくるありさま・・・。

仕方ないので、ソースコードに手をいれてみました。13215～13225行までコメントアウト！

    for my $at ( split /\s*,\s*/, $blog->archive_type ) {

        my $archiver = $app->publisher->archiver($at);

        next unless $archiver;

#        next if 'entry' ne $archiver->entry_class;

#        my $archive_label = $archiver->archive_label;

#        $archive_label = $at unless $archive_label;

#        $archive_label = $archive_label->() if ( ref $archive_label ) eq 'CODE';

#        push @data,

#          {

#            archive_type_translated => $archive_label,

#            archive_type            => $at,

#            archive_type_is_preferred =>

#              ( $blog->archive_type_preferred eq $at ? 1 : 0 ),

#          };

    }

そうすると、一応公開設定の画面が表示されるようになって、本来優先するテンプレートがドロップダウンで指定できるはずの場所が空です。

優先アーカイブタイプ 有効なアーカイブがありません。

この情報を元にコードを追っかけていくと、WeblogPublisher.pmのcore_archive_typesメソッドあたりにたどりつきます。
この中で指定されているArchiveTypeの定義が下のほうに書いてあるので、確認するときっちりentry_classがあります。
でも、エラーをみるとこのエントリークラスが呼び出せていないようです。
3.3までのWebPublisher.pmみるとこんなクラスないんだよなぁ・・・このあたりのPerlの基本設定でどこか環境依存のコードがまじっていそうなんだけど見当がつかない・・・。

あきらめ半分で、3.3の動いている古い環境ににMT4をインストールしてみる。
・・・うごくじゃん、構築できるじゃん。

なにが違うんだー、Active PerlをアンインストールしてXAMPPいれなおしてみるもダメ。
フォルダ権限から、IISの設定まで全部見直してみたけどダメ。
エラーメッセージやオブジェクトの名前で検索してもダメ。

・・・もうFedora Coreの入っているサーバにインストールしたほうがいいか・・・。