Railsに基づいたプロジェクトの失敗に関する最近のブログ掲載(source)が論議を巻き起こしている。予想通り、このディベートにおいて競合となるテクノロジー側は、それをRailsの最期とみなしたことだろう。特にPHPへの切り替えに関しては長々と掲載されていた。しかしながらその記事の本意が一体何だったのか探った人々もいた。Austin Ziegler氏はこのプロジェクトの命取りとなった、非技術的な問題を提示した(source)。
Austin氏が提示するもうひとつの問題はそのプロジェクトが既にあるソフトウェアのリライトであるということだ。
このディベートには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
彼はこの新たなテクノロジーの技術者達を無視した。彼、また彼の従業員達も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