InfoQ

News

Rubyとそのハイプサイクル

作者 Werner Schuster, 翻訳者 編集部 投稿日 2007年10月10日 午前2時20分

コミュニティ
Ruby
トピック
Ruby on Rails,
ケーススタディ,
パフォーマンス&スケーラビリティ
Railsに基づいたプロジェクトの失敗に関する最近のブログ掲載(source)が論議を巻き起こしている。予想通り、このディベートにおいて競合となるテクノロジー側は、それをRailsの最期とみなしたことだろう。特にPHPへの切り替えに関しては長々と掲載されていた。しかしながらその記事の本意が一体何だったのか探った人々もいた。Austin Ziegler氏はこのプロジェクトの命取りとなった、非技術的な問題を提示した(source)
彼はこの新たなテクノロジーの技術者達を無視した。彼、また彼の従業員達もRubyで遊ぶことはよそに、それに関して認識してはいなかっただろう。これは経験から的確だとみなされた技術ではなく、マネジメントによって的確とみなされたものなのだろう。(すまない、Derek。コードで手を汚しているかもしれないが、君はまだマネジメントをしなければいけないのだ。)
これはその会社のソフトウェアが完全にPHPに基づいており、デベロッパたちもPHP開発に取り掛かっていたという事実を指摘している。Rails上のRuby内で大きなソフトウェアを記述しながらPHPに投資している会社が問題提示しているのだ。特に最初の記事が明らかに述べているように、Rails環境のほうが快適であると書いたのはフルタイムのRailsデベロッパの一人とそのブログを記載した人のみで、一方残りのデベロッパ達とその会社のソフトウェアはPHPの方が良いと言っているのだ。

Austin氏が提示するもうひとつの問題はそのプロジェクトが既にあるソフトウェアのリライトであるということだ。
Derekはオーバータイムでフェーズするのを考える必要なしに、One Big Dayデプロイメントで環境全体の完全なるリライトととして、そのプロジェクトにアプローチした。一度に壊れた部分を交換できるインターフェースポイントを見つけるのはいつでもと言っていいほど可能なのです。結局これがRails支持者達がみんなに伝えるべきことです。異なるコードベースで一度に一つのエリアを交換し、RESTfulサービスとしてそれをインターフェースします。そして単一のデータベーススキーマに依存させないようにするのです。
David Heinemeier Hansson氏はChad Fowler氏の"The Big Rewrite"という一連の記事(source)を提示しながらプロジェクトリライトの問題を詳細に指摘した(source)

このディベートにはRubyのハイプサイクルにも取り上げられていた(source)。ハイプサイクルは市場に旋風を巻き起こすテクノロジーかその製品でプロセスを描写するという考えなのである。Railsの急速な台頭は現在その人気とマインドシェアを博していることを明確にしている。JavaやXML、または由緒正しいAJAXのようなテクノロジーと同様のアプローチである。

ハイプサイクルの一つの段階は、技術面での期待がピークに達した後にやってくる。そしてその後には幻滅が後を追うものである。現実的にその技術を使用することによって問題が生じたり、それが単なる神話であったことがその時点で分かる。またそれはどんな問題にも対応できる無敵な武器であると信じてそれを採用したものの、過剰な期待が過ぎ去った後にやってくるのだ。その期待によってPHPのみを扱う企業がRailsでソフトウェアの部分をリライトする事を考慮したという事実を明瞭にするかもしれない。

これはRubyにとって悪影響だと言うひともいるかもしれないが、他の技術が同じ段階を踏んでいたことを歴史が証明している。例えばJavaだが、Javaプ ロジェクト用のCorel Office(source)が90年代後半に失敗を犯した時や、またNetscapeのJavagator(source)がキャンセルされ、JavaでNetscape Navigatorをリライトした際に同じような段階を経験しているのだ。

ちょっと遅れていると思われるが、この最近のディベートがRubyに対する反発であるととらえる人もいた。今年上旬により大きく、より公的なRubyベースのプロジェクトが失敗する寸前にあったと思われる。Ruby上で構築されたメッセージシステムのTwitterはパフォーマンス上の問題で苦しんだ。Rubyインタプリタのリマークがこの失敗の根源なのかもしれないが、人々はそれによってRubyに大変な関心を持った(source)

しかしながら6ヵ月後の今、事は変化したように見える。ポイントとして、Twitterはパフォーマンスに関する問題を抱えていたがまだ存在し、動いていて、未だRubyによって実装されている。この問題に対する解決策は、例えば"Twitterのスケーリング”(source)かもしくは”大きくなるためのちょっとした話”(source)として、現在ネット上でドキュメント化されている(source)。そして最終的に問題は全体的にアーキテクチャ的なものである事が判明した。

原文はこちらです:http://www.infoq.com/news/2007/10/ruby-hype-cycle
ブックマーク
digg+,
reddit+,
del.icio.us+,
dzone+,
Hatena

No comments

返信

ジャンル別一覧

ファイルシステムでHello World

この連載では"ファイルシステムの作り方"をご紹介します。第1回目の今回は簡単なイントロダクションと単純なHello Worldファイルシステムの作り方を説明します。次回以降で詳しい解説と本格的なファイルシステムの作り方をご紹介しようと思います。

Guice(ジュース)を早飲みしすぎていませんか?

あなたのチームが、既存アプリケーションを「シングルトンの入れ子」設計から依存性注入(DI)へ移行しようとしているなら、この論文に心引かれるでしょうが、DIへの移行は難しいことが分かっています。論文にはGoogleのJava DIコンテナ(Guice)の名を入れていますが、Javaや.NET、Python、Rubyなどにも当てはまります。

チームがキュービクルと引き換えにコミュニケーションスキルを得る手助けをせよ

アジャイルの「自己組織化チーム」のパラダイムでは、チームのメンバに新しいスキルが要求されます。この記事では、発展しつつあるチームの自己組織化を壊さずに、新たなスキルを伝えるためのいくつかの戦略を提案します。そして、新しいスキルを身につけるのに役立つ資料のありかを提示しています。

F#の土台を越えて - 非同期ワークフロー

今回の記事では、非同期ワークフローと呼ばれるワークフロー機能の面白い使用法を考察しますが、非同期ワークフローは.NETの非同期プログラミングモデルを単純化することを目的としています。

言語としてのアーキテクチャ: ストーリー

アーキテクチャは一般に、Word文書に主として見られるような極めて実体のない、ソフトウェアシステムの概念的な側面であるか、または完全に技術によって駆動されるものかのいずれかです。そのどちらも間違っています。では、どう対処すればよいでしょうか? この記事ではアイデアを説明します、そしてアプローチのキーポイントを要約します。

メタプログラミングを使ってRubyにプロパティを追加する

Werner Schuster氏が、簡単な例を示しながら、Javaのようなプロパティをメタプログラミングを使ってRubyに追加する方法を示します。

BlazeDSとAMFでWebとデスクトップのアプリケーションを構築する

現在のRIAアーキテクチャにおいて、クライアント/サーバーの通信は重要な位置を占めています。本稿では、James WardとShashank TiwariがアドビによるオープンソースのBlazeDSメッセージングサーバーの世界へ飛び込みます。

業務ソフトに手を加えずに暗号化を実現する~秘文の挑戦~

hibun

ウィルス対策ソフトや情報漏えい防止用のソフトは、いわば影の存在です。ユーザの操作性やGUIを工夫する以上に、いかに目立たない存在となるかにその技術を注ぎ込んでいます。ここでは日立ソフトが開発した「秘文」の事例を紹介します。