Ruby on Railsは万能薬ではない 127
ストーリー by mhatta
そりゃ向き不向きはあるよね 部門より
そりゃ向き不向きはあるよね 部門より
pinbou 曰く、
本家/.の記事より。O'Reilly Rubyブログに、2 年後私がRuby on RailsからPHPに戻った7つの理由という記事が載り話題に なっている。オンラインCDショップCD Babyの創業者であるミュージシャン兼プログラマのDerek Sivers氏が書い たもので、優秀なRailsプログラマを雇って一緒に2005年から2年間CD Babyのリ ニューアルに取り組んだがうまくいかず、試しに慣れたPHPで書き直してみたら2ヶ月 でローンチできた、という内容。Railsから学んだことも多く、言語として Rubyがダメというわけではないが、古いコードを捨ててRailsに飛びつく前にい ろいろ考えるべきことがある、と結んでいる。
そりゃそうだろ・・・ (スコア:5, すばらしい洞察)
どんな言語・開発・運用環境にも、万能薬は無いさ。自分の目的のものに対し、どれが優れているのかを見極めるのが技術屋ってもんでしょう。
＃元記事の人はミュージシャン兼務なので強くはいえませんが。
雑誌・ニュース記事など盲目的に「＊＊を導入すればすべて解決！」的な”煽り”宣伝が多く見受けられます。これは書いている本人より、担当者の意向でしょうが、もういい加減、万能薬は無いことがわかってるんだから、スポーツ紙１面のような煽りは止めたほうがいいようにも思う。
雑誌の部数が伸びないのは、この辺の煽りにうんざりした連中が多いのかもしれない。
-- gonta --
"May Macintosh be with you"
Re:そりゃそうだろ・・・ (スコア:5, 参考になる)
http://developers.slashdot.org/comments.pl?sid=305901&cid=20718897
よぉ、おまえら。ひさしぶりだ。
おいらのちっぽけなBlogがSlashdotに載ってるんで驚いちまったよ。
特にタレコミの文章が全然間違ったポイントでフレームの元になってるもんで。
オレはRailsの限界のせいでプロジェクトをキャンセルしたなんて言ってないって。
もっと、こう、
オレは2年間、Railsが向いてないことをさせようとした。それで気づいたんだ。昔の置き去りにした言語（PHPだけど）が、Railsで覚えた知識を用いてアプローチしたらとてもうまくいったんだよ。
それだけのことさ。
----- ここまで
＃んで、万能薬と最初に書いたのは誰？
Re:そりゃそうだろ・・・ (スコア:2)
これはタレコミがフレーム(flame)の元になったというのでなくて、
単に「ポイントを間違えて書かれて(frame)いる」と言っているだけではないですか？
# 実際にフレームが起きたかどうかは別として Siver 氏が L と R を間違えるようなことはなさそうなので
Re:そりゃそうだろ・・・ (スコア:1, 参考になる)
Staffは最高のRubyプログラマを用意したと書いてあります。
問題点として最近の業界の怒涛の変化の波を挙げられてますし、プログラマの名誉のためにも彼は悪くないと書いてあります。
下を守ってあげられるだけ、彼は優秀なPMでしょう。
Re:そりゃそうだろ・・・ (スコア:1, すばらしい洞察)
そんな時、保守的でいるべきか、革新を取るべきかはやってみなけりゃ分からない。
人間なんざそんなに能力があるもんじゃありませんぜ、旦那。
世の中の成功は失敗の積み重ねがあって成り立っているということも
多いもんだし、本件はやり直しが効く時点でやり直したのだから
その点ではマルをあげてもいいだろう。
無能ってのはやり直しが効かないところまで足を踏み入れるPMのことだ。
Re:そりゃそうだろ・・・ (スコア:2, 参考になる)
私もこの点がとても気になったので読んでみました。RailsからPHPに戻した理由は理解できましたが、Railsが不向きな分野・処理が何なのかはいまいちよく分かりません。そこで、記事を元にして私なりに想像してみました。
■あまり複雑ではないプログラムには不向き
PHPに戻した理由3には、Railsは覚えることが多くて大変だし、覚えても大抵の機能は使わない、といったことが書かれています。よってRailsの機能・枠組みを十分に使わなくても済むような範囲のプログラムは、学習コストの問題からRailsは不向きではないか、と考えられます。
■重い処理をこなさなければならない場合に不向き
理由4より想像。しかしtwitterの例があるので、一概にRailsが要求される処理をこなせないとは言えません。ただ確かに資金などの問題で十分なハードウェアを用意できない場合にはRailsは不向きかも。
■SQLを直接書かなければならない場合に不向き
理由6より想像。SQLを全部自分で書くのなら、ActiveRecordのないRailsになるわけで、魅力が激減。
Re:そりゃそうだろ・・・ (スコア:1, 参考になる)
ひょっとするとRubyならエンジン制御もできるかもしれませんけどね。で、RailsはRubyの上に構築されているわけで無理矢理Railsでエンジン制御をさせられるかもしれませんが、向いていないということにはかわりありません。
Re:そりゃそうだろ・・・ (スコア:1, すばらしい洞察)
言語とフレームワークは対立概念ではありませんよ。
Rubyも言ってみればRubyのコードを書くというフレームワークです。
更にいえばOOPだって「ソフトをモノという単位の集合体だと見立てる」というフレームワークです。
また、Ruby内蔵ライブラリも結構フレームワークじみていますしね。Enumerableとかが典型的です。Rubyお得意のBlockや特異メソッドもフレームワークみたいなものだし。
要するにフレームワークってのは、それ自体が再帰的に階層を成すような概念です。
Aフレームワークの上にBフレームワークが乗り、更にCが乗り…。
そして「乗っている」フレームワークは「乗られている」フレームワークより、
より具体的であり、そのぶん「やれることが限定」されます。(その限定された範囲内ではソフトが作りやすくなる)
そういう意味では逆にいえばRubyも万能ではないわけです。なにかをやりやすくしてあるぶん、何かを苦手としますからね。
>Rubyならエンジン制御もできるかも
問題は処理速度でしょう。
Rubyでも足りる処理を分担させればRubyで出来る。
Railsでも足りる処理を分担させればRailsで出来る。
ただ、DBアクセスとかWebとかといった、特定形態のアプリを作ることに特化したFWだという意味では、Railsでやれることは色々限られるでしょうね。
といっても、UIをWebで構築し、情報をDBで保存し、いっぽうで裏でエンジンにアクセスして制御する、というアプリは(もしRubyの処理速度が間に合えば)出来そうですし、そんなに無理ではないのでは？
問題は、使い物になる機能＆性能の、拡張ライブラリToyotaEngine/Rubyを実装する人が居てくれるかどうかではなかろうか？
翻訳 (スコア:5, 参考になる)
“IS THERE ANYTHING RAILS/RUBY CAN DO THAT PHP CAN’T DO? … (thinking)… NO.”
2. 社内にPHPの利用者が多く、Railsに移行するには再教育が必要
OUR ENTIRE COMPANY’S STUFF WAS IN PHP: DON’T UNDERESTIMATE INTEGRATION
3. Railsは冗長
DON’T WANT WHAT I DON’T NEED
4. phpは小さくて早い
IT’S SMALL AND FAST
5. phpは自分好みにいじれる
IT’S BUILT TO MY TASTES
6. phpだと自分でSQLを書ける
I LOVE SQL
7. Ruby on Railsを学んだことでphpでもっといいコードが書けるようになった
PROGRAMMING LANGUAGES ARE LIKE GIRLFRIENDS: THE NEW ONE IS BETTER BECAUSE *YOU* ARE BETTER
かなり意訳ですみません．．．
違うだろって所は修正してもらえると助かりますm(_ _)m
Re:翻訳 (スコア:5, おもしろおかしい)
7、プログラミング言語はガールフレンドのようなもの。つまり、…
a、経験のない連中はモノにできない
b、力づくで言うことをきかせるな
c、本で読むのと実践は異なるよ
d、前カノと比較もほどほどに
e、すべては幻想だ。とほほ
Re:翻訳 (スコア:3, おもしろおかしい)
Re:翻訳 (スコア:1, おもしろおかしい)
Re:翻訳 (スコア:3, おもしろおかしい)
Re:翻訳 (スコア:2, すばらしい洞察)
Re:翻訳 (スコア:1, おもしろおかしい)
俺がMITで習ったのとは違うなー
g. 全てのプログラム言語は二次元に帰結（やっぱり二次元は最高だぜ）
h. 三次元はウンコになるが、二次元はウンコという概念が存在しない
i. 俺は車だけじゃなく、プログラム言語まで日本人から買わなきゃならんのか！
いやはや仰るとおりで (スコア:1)
Youthの半分はバファリンでできています。
Re:翻訳 (スコア:3, 参考になる)
3. DON’T WANT WHAT I DON’T NEED
→ 「余計な機能が多すぎる。9割の機能は使うことがなかった。」
7. PROGRAMMING LANGUAGES ARE LIKE GIRLFRIENDS: THE NEW ONE IS BETTER BECAUSE *YOU* ARE BETTER
→ 「新しい言語のほうが良いと思えるのは、貴方が成長したから。」
こんな感じでいかがでしょうか。
7番目については原文読んでもちょっと意味不明です。
たしかに、rubyを触ってみた後、過去の自分のphpコードをみて反吐が
出そうになったとは書いてありますが、本題のほうはどこへいったのかと。
さて、7番目以外の項目については色々と突っ込みどころがあるかと思いますが、
そこらの議論は他の方に任せます。rails信者とバレるのは嫌なので。
Nice abort.
Lv5以下の社員全員にデスマーチ！
Re:翻訳 (スコア:3, すばらしい洞察)
実現されるって事でしょ。
つまり、RoRをみて「カコイイ！」と方法論の違いとか優劣を認識できるのは、
あなたがレベルアップしてるからであり、従ってPHPでも（あなたがいる限り）できる。
Re:翻訳 (スコア:1)
7場面目の今意味が分かった気がします。
Re:翻訳 (スコア:2, 興味深い)
それってつまり、Webアプリフレームワーク的な部分が、言語に最初からビルトインなのか、後付けライブラリなのか、ってことですから。つまり大小は本来「見えない部分」であるはず。
特に「phpは自分好みにいじれる」というのが本当だとしたら、その自由度のぶんだけむしろPHPのほうが「大きい」はずです。
結局のところ「大きい小さい」という議論は、論拠も怪しげだし、その結果も怪しげだ、というだけだと思います。
個人的には大きさというより形なんじゃないかと思っています。
道具が、自分の体(?)や慣れに対し、ぴったりフィットする「かたち」だったかどうか。
この人の場合はPHPに体が慣れていた、と。
>「余計な機能が多すぎる。9割の機能は使うことがなかった。」
そのためのプラグイン方式なような…
>phpだと自分でSQLを書ける
ここ痛し痒しなんですよね。
ActiveRecordやもっと一般的にO/Rマッピング系の技術では、
SQLを書かせだしたらキリがないという面があるんで。
で、一方で最近気になっているのが、Rails(やSeasar)における、
RDBの使い方の「しばり」の「有用性」です。
なんの有用性かというと、教育効果と見ての有用性です。
Rails(やSeasar)は「テーブルにIDという人工PKを設けろ」と強制します。
これは、変化に強いテーブル構成という意味でも、
OOPとのインピーダンスミスマッチを下げるという意味でも、
有意義な考え方／規約なのですが、
人工キーは普通のRDBの使い方から見て「直感的ではない」という面もあります。
つまり凄く悪くいえば、自然キーは「麻薬」なんです。
直感的に判りやすい項目をPKにしたくなるものですが、そうすると変更どうするよ？とか、OOPと合わなくて悶えるとか、色々あるんで。
そこをID方式を強制することで凌いでしまう、ってのは、1つの興味深い考え方です。
「SQLを愛する」のはいいんですが、問題はその愛してる人が優秀かどうかです。
優秀な人が愛してSQLを書けばそりゃ当然、色々メリットだらけのシステムになるはずですが、
逆に優秀でもなんでもないけど馬鹿の一つ覚えでSQLしか愛したことが無い人なら、
システムはむしろデメリットが多いゴチャゴチャなものになってしまいがち。
Re:翻訳 (スコア:1)
Re:翻訳 (スコア:1)
＃女房と味噌は古いほど良い、とも。
Re:翻訳（「1.Ruby on Railsでなければできないことは実は無い」とOOPの考察） (スコア:1)
“IS THERE ANYTHING RAILS/RUBY CAN DO THAT PHP CAN’T DO? … (thinking)… NO.”
PHPとRubyの対比という全体的な意味で捉えると、
この文には「PHPでのオブジェクト指向」なども含まれてるのかな。
個人的には、何でもオブジェクト化する必要は無いと思ってます。
特にWEBプログラミングは、文字列操作と組み込み型（リスト、ハッシュ）操作、
共通部分の関数化で済んでしまう、わりあい平坦な構造のプログラムが
多いです。こういうとき、OOPは単に冗長なことが多いです。
名前空間としてOOPするなら別ですが、本格的なOOPの導入は、
手続き型のコードでは可読性が損なわれてしまう程度に
複雑な処理が必要になってから考えればいいことだと思います。
その場合でも、ライブラリだけOOPするとか、段階的な
導入のほうが上手くいくと思います。
金槌で全てを叩くだけが方法ではないのです。
Re:翻訳（「1.Ruby on Railsでなければできないことは実は無い」とOOPの考察） (スコア:2, 興味深い)
いろいろ反論ありそうですが。私も同感です。
私も（職業ではありませんが）大きなプロジェクトになりそうなものは
OOPで作り始めました。必要なライブラリもOOPで拡張するようになっ
てましたし、PHPのオブジェクトは書きやすいから好きでした。
（モノにはなりませんでしたが）
一方、つい最近、ごくごく簡単なPHPスクリプトを作りました。
HTMLとPHPが混じった綺麗とは言い難い内容ですが。
ニーズが少なすぎてメンテする人さえいない状態で、
とりあえず動くモノを早く提供する事が大切という点では、
OOPにこだわらずに作るのもアリだと思いました。
いくつかfunctionは使ったので、classにまとめることも
できたんでしょうけど。そこまでの必要性が無かったから
しなかった。それだけのこと。
#以上、チラシの裏でした
Re:翻訳（「1.Ruby on Railsでなければできないことは実は無い」とOOPの考察） (スコア:1, 興味深い)
C++やJavaみたいに「オブジェクト(とかクラスとか)を構築するのにかかる手間」が大きい言語では、回避したくなる気持ちも判りますが、
Rubyについてはそういう無駄なストレスが極限まで減らせれるよう言語デザインされてるんで。
そういう意味では、「オブジェクト指向」「スクリプト」言語っていうRubyの立ち位置は秀逸です。オブジェクト(指向)を気楽にスクリプティングできる言語。本当に必要な最小限の手間だけでオブジェクトをいじれる言語。
>文字列操作と組み込み型（リスト、ハッシュ）操作、共通部分の関数化で済んでしまう
たしかにRubyでも、このへんを(も)おおいに使って楽しますね。
正規表現リテラルとか、リスト(配列)リテラルとか、ハッシュリテラルとか、
あとSymbolやRangeのリテラルの存在も大きいです。
やっぱり幾つかの重要なオブジェクトがリテラルでサクっと書けるってのは重要。
文字列リテラルのない言語なんて誰も使いたくないでしょう。それの延長です。
そういう意味では、正規表現もハッシュもリテラルで書けないJavaは、つらいですね。
特に正規表現なんてUNIX Cで正規表現使うのと同じくらい面倒で、使う気にならない。
気軽に書けるってことは導入を躊躇しなくて済むということで、そのぶんご利益は広がります。
Rubyだとそれにくわえてもう1つ。
「(無名)関数のリテラル」ってのが重要な位置を占めます。
というか、これを重要な位置に据えることで、更にコーディングが楽になる。
いわゆるイテレータとかブロックとかいうあれですね。
Ruby(など)はこの技術の恩恵をおおいに受けてる。
そのぶん更にコードがシンプルで読み書きしやすくなる。
で、オブジェクト/クラスを作るのが楽だという性質によって
更にコーディングしやすさに拍車をかけてくれるのがRubyです。
特にいいのは、クラス定義機能というよりは、
includeやextendなどの
クラス混ぜ混ぜ機能や
特異メソッド機能のあたりですね。
これで「OOPがぐっと身近に」なります。
>手続き型のコードでは可読性が損なわれてしまう程度に
>複雑な処理が必要になってから考えればいいことだと思います。
そうかなあ？最初からOOP的に考えておいたほうが楽だと思います。
というのは、「途中からOOP流にコンバートする」のは凄く大変だからです。
いちから書くより多分ずっと大変です。
手続きベースかOOベースかの違いって奴は、実装だけじゃなく考え方(デザイン)まで影響してしまいますので、さかのぼらないとならない部分が多すぎ。
挫折する人らの何割かって、もしかすると、
途中でコンバートしようとして挫折してるんじゃないかな？
それ一番難しい作業ですから。最初からやったほうが絶対楽。
あと、同じことはOOPに限らないと最近思っています。
たとえば「関数型言語」ぽい考え方も、最初から少し導入しておいたほうが、つくりが綺麗になると思います。
Re:翻訳（「1.Ruby on Railsでなければできないことは実は無い」とOOPの考察） (スコア:2, 興味深い)
とおっしゃっていますが、 私はこの意見に全面的賛成はできないという立場です。 複雑な問題に立ち向かう時、事前にしっかりとした設計をする必要があるのなら、 その設計段階にあたっては、 「オブジェクト指向」プログラミングすることによって、 何が得られ、何を諦めなくてはならないのか、 そこを明確に意識する必要があると思っています。
この前後のコメントで「いわゆるOOP」の利点について述べていると思われるところを拾ってみると(表現はちょっと変えていますが)、
というような考えがあるように読めます。
始めの2つは少々抽象的ですが、3つ目は
の表現から、 おそらく、 「いわゆるOOP」によりプログラムのモジュール化ができる、 ということを述べているのだと思われます。 上に列挙した1番目の考えも、同コメントに 「名前空間としてOOPするなら別」「ライブラリだけOOP」といった表現があることから、 やはりモジュール化についての考えを述べているようにも読めます。
実はこのコメントで主張したい二つの点の内の一つはここなのですが、 「プログラムを綺麗にモジュール化するために、 『オブジェクト指向』は本当に必須なのか」を考えてみて欲しいのです。
確かに、C++やJavaといった、いわゆる「オブジェクト指向言語」では、 モジュール化の仕組みとクラスベースオブジェクトシステムが密接に関係しています。 というより、むしろ、モジュール間の階層構造等の関係や、 名前空間の分離、名前の隠蔽や公開といった仕組みが言語仕様上大幅に省略され、 代わりにクラスベースオブジェクトシステムの上のクラスの階層構造や クラスの定義が、そうしたモジュール機能を肩代わりしています。 このため、プログラマは、自分が 「オブジェクト指向」による恩恵を得ているのか、 「モジュール化」による恩恵を得ているのか、 明確に意識することが難しくなっています。 本当に必要だったのは、「オブジェクト指向」ではなく、 「モジュール化」だった可能性はありませんか?
さて、「いわゆるOOP」の機能の一部を 「モジュール」と言い換えるかどうかはともかくとして、 それ以外の部分に「オブジェクト指向」を導入して失うものが無いなら、 それはそれで問題はないはずです。 では、実際に「オブジェクト指向」で失うものは有るのでしょうか?
元コメントの前後を見ると「とりあえず動くモノを早く提供する(#1224227)」ために OOPしないのだ、という意見があるようですが、 ここではその考えは採りません。 最初に述べたように、このコメントでは「事前にしっかりとした設計」という大前提で考えます。
一旦立ち戻って、そもそも「オブジェクト指向」とは何でしょうか。 これは人により様々なことを言う人がおり、 前述の「モジュール化」の機能もオブジェクト指向に含めて述べる人もいます。 とはいえC++やJavaにおけるモジュール化機能は、 「オブジェクト指向」は「オブジェクト指向」でも、 クラスベースオブジェクトシステム前提となっているので、 例えばJavaScriptのようなプロトタイプベースオブジェクトシステムではそのまま当てはまらない要素が多く、 そのためこのコメント中では、「モジュール化」は「オブジェクト指向」の必須機能ではないとしました。
クラスベースオブジェクトシステムとプロトタイプベースオブジェクトシステムで共通する要素はいくつかありますが、 私の知る限りほとんどすべての「オブジェクト」の定義に登場する要素は、
の二つです。 「メッセージ」と言っているのはアクター理論からの借り物ですが、 Smalltalk始め多くの「オブジェクト指向言語」は、 「メソッドの呼び出し」という形でメッセージを受け取って、 インスタンス変数を変化させる、という機能をほぼ必ず持っています。
私がここで「オブジェクト指向にしない理由」の一例として挙げたい点が、 正にここにあります。
つまり、「オブジェクト指向」の設計においては、 「内部状態の変化するオブジェクト」がお約束のように登場してきます。 「オブジェクト指向プログラミングは綺麗なプログラミング」と思い込んで設計をすると、 そこに何の疑問も生じないのですが、 実はここで「綺麗なプログラム」と考えられる性質の一つを、 無意識に捨てているの
Re:翻訳（「1.Ruby on Railsでなければできないことは実は無い」とOOPの考察） (スコア:2, 興味深い)
>「いわゆるOOP」によりプログラムのモジュール化ができる、ということを述べているのだと思われます。
元の人がどう意図したかは知りませんが、その解釈は違うかも知れませんね。
OOPがアクセスを抑止(あるいは警告？)するのは、
ほかの「クラス」へのアクセス(だけ)じゃなく、
ほかの「インスタンス」へのアクセスも、です。
もっとも、C++/Javaがそういう設計なもんだから誤解されることが多いですね。
privateなのに「ほかのインスタンス」へアクセス可能だってのは、まずい設計だと思っています。
それこそC++/Java作者がOOPとモジュールプログラミングを混同してたんじゃないの？と疑ってしまう。
この面はそれこそRubyのほうがマシです。
>オブジェクトは内部状態を持つ。
データベースも含めて「状態」を考えると、
少なくともRailsがターゲットとしてるような「普通のWebアプリ」において(も)、
「内部状態を持つ」はそれなりに成り立ってると思います。
RailsのObjectが、というよりは、細かくいえば「(RailsのO/Rマッピング機能である)ActiveRecordのObjectが」ですね。
>「参照透過性」
たしかに完全な参照透過性とOOPは相性が悪いですが、「関数型もどきコーディング」のご利益とOOPとくらいならば両立できるように見えます。
まさにその実例のメジャー(今となっては)なものが、Rubyのコーディングだと思われます。
そういう意味では、「ほかのメジャー言語と似てない機能は使わない」という方針で書かれたRuby入門書は、筆者には悪いけどゴミだと思っています。初心者だっていうならむしろ「最初から」Rubyの関数型っぽい面とかを使いまくったほうがいい。あれはJavaとかに染まった人のほうが抵抗感を感じるはず。
>boost前提で良いのなら、「オブジェクト指向」だけでなく、かなり「関数型」の考えを取り入れたプログラミングが
ああ。それはありますね。
もっともコーディングの面倒＆難解さから、Rubyの楽さと比べる気にもなりませんが。
>Firstclass objectとしてのcontinuationや、 monadは、案外web application開発と相性が良いのではないか、なんてアイデアもあるようです。
Continuationについては、KahuaというかGauche…の中の人…の話が、猛烈に秀逸なうえにNativeジャパニーズで読めるので、凄くいいです。Shiroさんは日本の宝の1つだと思う。あとコミュニティもね。
あの人のサイトを骨の髄まで読むといいと思います。Kahuaでは実際にCont.が Webアプリ構築フレームワークの中の中心(!)に据えられてますし、いっぽうで「(Gaucheを実装してる)Cのいわゆるスタックは、Cont.と相性最悪である」などといった現実面での嘆きとか、そういう色々な視点からの話が読めます。
>結局PHPに戻って、2年後に
PHPじゃなくRubyに戻る、っていうコースも有るかも。
OOPでないと生きていけない体に (スコア:1)
仕事ではそりゃ言語を自分で選ぶことはできませんし、
言われたままの規約に従ってコーディングするしかありませんが、
自分のために各ツールなんかは C++ + boost がないと生きていけない…
フラットな構造になってるとなんか覚えておかなきゃならないことが
多すぎて困りませんか？「お前、アクセスされる必要もないのに
なんでそこにいるんだよ、グローバル？あっちいけよ。」
とか、そんな感じです。
屍体メモ [windy.cx]
Re:翻訳（「1.Ruby on Railsでなければできないことは実は無い」とOOPの考察） (スコア:1, おもしろおかしい)
万能な言語なんてものは無いでしょ？ (スコア:5, すばらしい洞察)
それぞれ長所と短所があるし、長所はシーンによっては容易に短所に変わる.
さらに、使い慣れた言語の開発効率は、使い慣れない「より開発効率の高い言語」のそれを容易に上回る.
日本人が日本語を使うのと、日本語にあまりなじみの無い外人が日本語を使うのと、どちらが苦労するだろうか.
逆もまた然り.
# ただし、上記は同程度に問題の無い開発環境が与えられているのが前提である.
# 特にデバッガの性能は開発効率に決定的な差を与える.
PHPの様に軽いRubyはないのですか? (スコア:2)
PHPと比べて、RoRが重いのはわかったのですが、 PHPの様に軽い、Rubyを使ったシステムはないのですか?
いつも主観で書き込んでいます
Re:PHPの様に軽いRubyはないのですか? (スコア:1)
PHPとRuby比べるなら分かるし、
（本来の）Rubyのように速く動くほにゃららって文脈なら分かるけど。
PHPだってフレームワーク通したらうんざりするほど遅くなる。Rubyもそうなんじゃないのかな。
Rubyほとんど触ったことないですけど。
#FWて「書き方を強制する」っていうメリット以外は感じたことがないなー
#そしてそれをメリットと感じる機会はほとんどない
似て非なる事例 (スコア:2, おもしろおかしい)
＃だめなのはそいつら
---- 末は社長か懲戒免職 なかむらまさよし
Ruby on Railsを使わなかった理由 (スコア:1, すばらしい洞察)
・さくらインターネットとかロリポップなどのレンタルサーバーで（せっかく）作ったアプリを動かせない
すいません、へたれですorz
Re:Ruby on Railsを使わなかった理由 (スコア:1)
特に痛いのが2番目で、一応cgiとしても動きはするのですが、
リクエストの度に膨大なライブラリを全て読み込まなくてはいけないので
普通のPCサーバーだと2～3秒/reqくらいかかってしまいます。
実用的な速度を求めると、fastcgiかwebrickかmongrelという選択肢に
なるのですが、これらはプロセス常駐型なのでサーバー貸し切り型の
プランでないと稼働させることができないんですね。
rails自体の性能は、実行速度面でも開発速度面でも十分実用的なのですが、
こうも導入障壁が高いと、そのうち新しく出た物に負けてしまいそうです。
なんかいいアイデア無いものでしょうかね。
Lv5以下の社員全員にデスマーチ！
Re:Ruby on Railsを使わなかった理由 (スコア:2, 興味深い)
それにデータも、いちいちDBやファイルに落とす義務があるよりは、メモリに持っているほうが楽なのだし。
つまり常駐型に移行するほうが地球(?)に優しい。
常駐型のプログラムを、いかに安全に(サンドボックスに押し込めて)実行させるか？という技術に、磨きをかけるほうが生産的だと思います。
ーー
あと有りえるとすれば、スクリプトの「コンパイル」かな。
コンパイルといっても動的言語では機械語まで落とすのは困難だけども、少なくともAbstractSyntaxTreeにまで落としといてファイルにするだけでも、結構違うはずだ。
そういえば、"J"Rubyの配布物には、ASTという拡張子のファイルが幾つか入っていますね…。
あるいは、その裏返しとして、
OSかWebサーバのほうが歩み寄るという手も有りますね。
Qt/KDEで「C++アプリの起動時間を短縮」するために使われてる技術として、
プロセスを起動し、内部の幾つかの関数ポインタテーブルとかを初期化した状態「で」プロセスを停止してメモリに放置プレイしておき、
プログラムを使いたくなったら随時、その放置プロセスを「fork」させ、生まれたプロセスのほうを自分で使う、という方式。
起動のコストを分割するわけですね。
それと同じことをWebアプリでもやればいい。
ただしこれにはCGIの起動を司るOSかWebサーバの協力が必要だし、
アプリにも(外からforkのタイミングを指示するための)仕組みが居る。
要はこれまた1つのフレームワークを成す必要がある。
フレームワークといえば拒絶反応を示す人も居るけど、そういう人は考えてみて欲しいんだけど、たとえばCGIという仕組みだって、それどころかプロセス起動という仕組みだって、1つのフレームワークです。
つまりこれは、素CGI(プロセス起動)、FCGI、mod_hogeなどなどといった「幾つかのフレームワーク」の、性能競争なのであって、フレームワークの「有無」の競争ではない。
それよか不思議なのは、
mod_hogeとかの常駐型を許さないレンタルサーバが、
同じ常駐型であるPHPは許すって点です。
要するに「常駐型は危険」という切り分けは迷信でしかないということ。
Re:Ruby on Railsを使わなかった理由 (スコア:2, 参考になる)
mod_phpはインタプリタが常駐するだけで、各種シンボルテーブル等は
リクエストの度に初期化される（リクエスト終了時に必ず開放される）ので
mod_xxx経由でスクリプト自体が常駐する他言語のApacheモジュールとはまた勝手が異なります。
また、PHPのアドバンテージとしてCGI/FastCGI、Apache他のサーバモジュール、
どの環境でも同じように動くという点もあります。
CGIの場合、httpdの設定によっては正しいPATH_INFOを取得するためにphp.iniの設定を
変えないといけないこともありますが、スクリプトは全く同じものが利用できます。
言語自体の良し悪しとか速い遅いではなく、開発環境と実行環境の差違を
あまり気にしなくてよいのがPHPが広く使われている理由ではないかなと。
Re:Ruby on Railsを使わなかった理由 (スコア:2, 参考になる)
「設定より規約」という考え方を徹底したのが素晴らしい (スコア:1)
「設定より規約」という考え方にあるのではないでしょうか？
もちろん大昔からプロジェクトごとのコーディングルールという考え方はあったわけですが、
「ただなんとなく、みんながそうしているから、プロマネに怒られるから」というあまり
積極的な理由ではなく、その規約に従うことでコードの大規模な自動生成という見返りが
得られるということがミソだったとおもいます。
これはプログラミング言語によらず適用できる考え方なわけで、今後は他の言語でも
on Rails 的なアプリケーションフレームワークが出てくるかもしれませんね。
屍体メモ [windy.cx]
Re:「設定より規約」という考え方を徹底したのが素晴らしい (スコア:2, 興味深い)
自動生成に限らず、手書きコードもその規約に従うとご利益が色々と…ですね。
で、規約によるDRYってのは、逆に
「テーブルの存在なんかプログラマからは完全に隠蔽してしまえ」
(ましてテーブル名前なんか知らなくてもいい)
という隠蔽というか階層型のシステム構成／開発体制とは、
実はあまり噛み合ってないってのは味噌。
ほら。Railsは「アジャイル」開発ツールですから。
各開発者がシステムの隅から隅まで一通り知ってるっていう体制が前提。
分業体制においては、テーブル名にコードをあわせるという規約は、
DB担当者以外にとっては「意味不明の暗号に合わせる」ことにしかならない。
Railsが出たときの解説の1つとして「疎結合より密結合」ってのがあったけど、
それは実装だけじゃなく、開発(者)の体制のことも意味するのよね。
>他の言語でもon Rails 的なアプリケーションフレームワークが出てくるかもしれませんね。
既にいっぱいあります。
GroovyによるGrailsとか。
知らないけどPythonにもきっとあるよね。
あと出所とかは違うけど結果的に似てるのがSeasar2とか。
ところで誰も気づいてないみたいだけど、
VisualuRuby (WindowsGUIバインディング)も実は名前規約ベースだよな。
イベントプロシジャのバインディングに名前を使っている。
というか、VRが手本にしたというVisualBasicに、起源を問うことも出来そうです。
あれも、中身がどうなってるかはよく判らないけど、見かけ上は名前ベースですよね。
なんだ、MSは20年も前から規約によるDRYを実現してたわけか…。
実際VBでも、GUIとコードのバインディングに、設定ファイルなんて書かされないもんね。
待てよ？そもそもRailsの他の売りである「フルスタック」も、
MSの商売戦略と同じですよね。
「同じブランドで出してるツール郡だからまとまりがある」っていう奴。
Re:「設定より規約」という考え方を徹底したのが素晴らしい (スコア:1, 興味深い)
その辺、かけてるのが多いんじゃない。
規約っつーか、もう暗黙の塊みたいな・・・
末端プログラマはそれでいいのかもしらんが、
まとめるほうは逆に覚えること多すぎでやってられん。
シンプルに保つという見方からは、逆行してるとも思う。
Seasarとかもうついていけないね。
あえてdisってみたのでは？ (スコア:1, おもしろおかしい)
# Java と Ruby って最近縁近いしなあ･･･
こいつはマジで馬鹿なんじゃあるまいか (スコア:1, すばらしい洞察)
要するに２年間プロト版を開発・設計した成果なんじゃね？
Re:タレコミ人は本家記事読んだのか？ (スコア:2, すばらしい洞察)
Re:タレコミ人は本家記事読んだのか？ (スコア:1, 興味深い)
Re:タレコミ人は本家記事読んだのか？ (スコア:2, すばらしい洞察)
たとえばこれがどこかRuby関係以外のブログに書かれていたら、「あっそう」で終わりそうですが。
つまり、O'ReillyとしてはRubyを褒め称えるのではないブログもOKですよ、という事でしょうか。
＞「PHPで問題なく動いてるシステムをわざわざ書き直す馬鹿が悪い」
もっと良くしたかったのかもしれませんよ？
まあそれで失敗してしまうのは、ちょっと情けないですが。
Re:結局のところ (スコア:2, おもしろおかしい)
Re:結局のところ (スコア:1)
# と混ぜっ返してみる。もちろんバイナリ表現が0じゃないというのも存じておりますw
Re:ローンチ（オフトピ：-100） (スコア:2, おもしろおかしい)
昼ごはん食べれなくなる人続出しちゃいます。
(オフトピック)リナックスじゃなくてリヌクス (スコア:2, おもしろおかしい)
昔地方のユーザズグループの宴会でのこと。宴会場の予約ボードに書かれていたのは「リラックスユーザーズグループ」だったそうな。まあリラックスして話しているんだけどね。(笑
以来その時の参加者はリナックスじゃなくてリヌクスを使うようになった…のかは定かではない。
vyama 「バグ取れワンワン」