パスワードを忘れた? アカウント作成
16356 story

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, すばらしい洞察)

    by gonta (11642) on 2007年09月24日 9時22分 (#1223817) 日記
    >> Ruby on Railsは万能薬ではない

    どんな言語・開発・運用環境にも、万能薬は無いさ。自分の目的のものに対し、どれが優れているのかを見極めるのが技術屋ってもんでしょう。
    #元記事の人はミュージシャン兼務なので強くはいえませんが。

    雑誌・ニュース記事など盲目的に「**を導入すればすべて解決!」的な”煽り”宣伝が多く見受けられます。これは書いている本人より、担当者の意向でしょうが、もういい加減、万能薬は無いことがわかってるんだから、スポーツ紙1面のような煽りは止めたほうがいいようにも思う。

    雑誌の部数が伸びないのは、この辺の煽りにうんざりした連中が多いのかもしれない。
    --
    -- gonta --
    "May Macintosh be with you"
    • by Anonymous Coward on 2007年09月24日 11時01分 (#1223887)
      本家に御本人が来ていたので貼っておきますね。

      http://developers.slashdot.org/comments.pl?sid=305901&cid=20718897

      よぉ、おまえら。ひさしぶりだ。
      おいらのちっぽけなBlogがSlashdotに載ってるんで驚いちまったよ。
      特にタレコミの文章が全然間違ったポイントでフレームの元になってるもんで。

      オレはRailsの限界のせいでプロジェクトをキャンセルしたなんて言ってないって。
      もっと、こう、
      オレは2年間、Railsが向いてないことをさせようとした。それで気づいたんだ。昔の置き去りにした言語(PHPだけど)が、Railsで覚えた知識を用いてアプローチしたらとてもうまくいったんだよ。

      それだけのことさ。

      ----- ここまで

      #んで、万能薬と最初に書いたのは誰?
      親コメント
      • > the lead-in description framed it with the completely wrong point.

        これはタレコミがフレーム(flame)の元になったというのでなくて、
        単に「ポイントを間違えて書かれて(frame)いる」と言っているだけではないですか?

        # 実際にフレームが起きたかどうかは別として Siver 氏が L と R を間違えるようなことはなさそうなので
        親コメント
  • 翻訳 (スコア:5, 参考になる)

    by loginPenguin (7275) on 2007年09月24日 9時34分 (#1223827)
    1. Ruby on Railsでなければできないことは実は無い
    “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, おもしろおかしい)

      by Anonymous Coward on 2007年09月24日 11時05分 (#1223890)
      スラッシュ国民投票

      7、プログラミング言語はガールフレンドのようなもの。つまり、…

      a、経験のない連中はモノにできない
      b、力づくで言うことをきかせるな
      c、本で読むのと実践は異なるよ
      d、前カノと比較もほどほどに
      e、すべては幻想だ。とほほ
      親コメント
    • Re:翻訳 (スコア:3, 参考になる)

      by Lv5DeathMarch (30244) on 2007年09月24日 10時09分 (#1223854)
      3と7がちょっと怪しいかな。

      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, すばらしい洞察)

        by Anonymous Coward on 2007年09月24日 10時17分 (#1223864)
        ソフトの品質は言語で向上するのではなく、あなたが向上することで
        実現されるって事でしょ。

        つまり、RoRをみて「カコイイ!」と方法論の違いとか優劣を認識できるのは、
        あなたがレベルアップしてるからであり、従ってPHPでも(あなたがいる限り)できる。
        親コメント
      • Re:翻訳 (スコア:2, 興味深い)

        by Anonymous Coward on 2007年09月24日 12時33分 (#1223931)
        phpは小さいってのは微妙ですね。
        それってつまり、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しか愛したことが無い人なら、
        システムはむしろデメリットが多いゴチャゴチャなものになってしまいがち。
        親コメント
      • by NOBAX (21937) on 2007年09月24日 11時15分 (#1223893)
        7.プログラム言語ってのはガールフレンドみたいなものだよ:新しい娘がいいに決まっている。だってアンタも少し大人になって女を見る目が肥えたんだから。
        親コメント
    • 1. Ruby on Railsでなければできないことは実は無い
      “IS THERE ANYTHING RAILS/RUBY CAN DO THAT PHP CAN’T DO? … (thinking)… NO.”

      PHPとRubyの対比という全体的な意味で捉えると、
      この文には「PHPでのオブジェクト指向」なども含まれてるのかな。

      個人的には、何でもオブジェクト化する必要は無いと思ってます。
      特にWEBプログラミングは、文字列操作と組み込み型(リスト、ハッシュ)操作、
      共通部分の関数化で済んでしまう、わりあい平坦な構造のプログラムが
      多いです。こういうとき、OOPは単に冗長なことが多いです。

      名前空間としてOOPするなら別ですが、本格的なOOPの導入は、
      手続き型のコードでは可読性が損なわれてしまう程度に
      複雑な処理が必要になってから考えればいいことだと思います。
      その場合でも、ライブラリだけOOPするとか、段階的な
      導入のほうが上手くいくと思います。

      金槌で全てを叩くだけが方法ではないのです。
      親コメント
      • 個人的には、何でもオブジェクト化する必要は無いと思ってます。

        いろいろ反論ありそうですが。私も同感です。

        私も(職業ではありませんが)大きなプロジェクトになりそうなものは
        OOPで作り始めました。必要なライブラリもOOPで拡張するようになっ
        てましたし、PHPのオブジェクトは書きやすいから好きでした。
        (モノにはなりませんでしたが)

        一方、つい最近、ごくごく簡単なPHPスクリプトを作りました。
        HTMLとPHPが混じった綺麗とは言い難い内容ですが。
        ニーズが少なすぎてメンテする人さえいない状態で、
        とりあえず動くモノを早く提供する事が大切という点では、
        OOPにこだわらずに作るのもアリだと思いました。
        いくつかfunctionは使ったので、classにまとめることも
        できたんでしょうけど。そこまでの必要性が無かったから
        しなかった。それだけのこと。

        #以上、チラシの裏でした
        親コメント
      • 逆にオブジェクト指向にしない必要も無いです。

        C++やJavaみたいに「オブジェクト(とかクラスとか)を構築するのにかかる手間」が大きい言語では、回避したくなる気持ちも判りますが、
        Rubyについてはそういう無駄なストレスが極限まで減らせれるよう言語デザインされてるんで。

        そういう意味では、「オブジェクト指向」「スクリプト」言語っていうRubyの立ち位置は秀逸です。オブジェクト(指向)を気楽にスクリプティングできる言語。本当に必要な最小限の手間だけでオブジェクトをいじれる言語。

        >文字列操作と組み込み型(リスト、ハッシュ)操作、共通部分の関数化で済んでしまう

        たしかにRubyでも、このへんを(も)おおいに使って楽しますね。
        正規表現リテラルとか、リスト(配列)リテラルとか、ハッシュリテラルとか、
        あとSymbolやRangeのリテラルの存在も大きいです。
        やっぱり幾つかの重要なオブジェクトがリテラルでサクっと書けるってのは重要。

        文字列リテラルのない言語なんて誰も使いたくないでしょう。それの延長です。
        そういう意味では、正規表現もハッシュもリテラルで書けないJavaは、つらいですね。
        特に正規表現なんてUNIX Cで正規表現使うのと同じくらい面倒で、使う気にならない。
        気軽に書けるってことは導入を躊躇しなくて済むということで、そのぶんご利益は広がります。

        Rubyだとそれにくわえてもう1つ。
        「(無名)関数のリテラル」ってのが重要な位置を占めます。
        というか、これを重要な位置に据えることで、更にコーディングが楽になる。
        いわゆるイテレータとかブロックとかいうあれですね。
        Ruby(など)はこの技術の恩恵をおおいに受けてる。
        そのぶん更にコードがシンプルで読み書きしやすくなる。

        で、オブジェクト/クラスを作るのが楽だという性質によって
        更にコーディングしやすさに拍車をかけてくれるのがRubyです。

        特にいいのは、クラス定義機能というよりは、
        includeやextendなどの
        クラス混ぜ混ぜ機能や
        特異メソッド機能のあたりですね。
        これで「OOPがぐっと身近に」なります。

        >手続き型のコードでは可読性が損なわれてしまう程度に
        >複雑な処理が必要になってから考えればいいことだと思います。

        そうかなあ?最初からOOP的に考えておいたほうが楽だと思います。

        というのは、「途中からOOP流にコンバートする」のは凄く大変だからです。
        いちから書くより多分ずっと大変です。
        手続きベースかOOベースかの違いって奴は、実装だけじゃなく考え方(デザイン)まで影響してしまいますので、さかのぼらないとならない部分が多すぎ。

        挫折する人らの何割かって、もしかすると、
        途中でコンバートしようとして挫折してるんじゃないかな?
        それ一番難しい作業ですから。最初からやったほうが絶対楽。

        あと、同じことはOOPに限らないと最近思っています。
        たとえば「関数型言語」ぽい考え方も、最初から少し導入しておいたほうが、つくりが綺麗になると思います。
        親コメント
        • 逆にオブジェクト指向にしない必要も無いです。

          とおっしゃっていますが、 私はこの意見に全面的賛成はできないという立場です。 複雑な問題に立ち向かう時、事前にしっかりとした設計をする必要があるのなら、 その設計段階にあたっては、 「オブジェクト指向」プログラミングすることによって、 何が得られ、何を諦めなくてはならないのか、 そこを明確に意識する必要があると思っています。

          この前後のコメントで「いわゆるOOP」の利点について述べていると思われるところを拾ってみると(表現はちょっと変えていますが)、

          • OOPは可読性を向上させる。(#1223882)
          • OOPは(プログラムの)つくりを綺麗にする。(#1223965)
          • OOPは「フラット」でない構造を可能にする。(#1224082)

          というような考えがあるように読めます。

          始めの2つは少々抽象的ですが、3つ目は

          「お前、アクセスされる必要もないのに
          なんでそこにいるんだよ、グローバル?あっちいけよ。」

          の表現から、 おそらく、 「いわゆるOOP」によりプログラムのモジュール化ができる、 ということを述べているのだと思われます。 上に列挙した1番目の考えも、同コメントに 「名前空間としてOOPするなら別」「ライブラリだけOOP」といった表現があることから、 やはりモジュール化についての考えを述べているようにも読めます。

          実はこのコメントで主張したい二つの点の内の一つはここなのですが、 「プログラムを綺麗にモジュール化するために、 『オブジェクト指向』は本当に必須なのか」を考えてみて欲しいのです。

          確かに、C++やJavaといった、いわゆる「オブジェクト指向言語」では、 モジュール化の仕組みとクラスベースオブジェクトシステムが密接に関係しています。 というより、むしろ、モジュール間の階層構造等の関係や、 名前空間の分離、名前の隠蔽や公開といった仕組みが言語仕様上大幅に省略され、 代わりにクラスベースオブジェクトシステムの上のクラスの階層構造や クラスの定義が、そうしたモジュール機能を肩代わりしています。 このため、プログラマは、自分が 「オブジェクト指向」による恩恵を得ているのか、 「モジュール化」による恩恵を得ているのか、 明確に意識することが難しくなっています。 本当に必要だったのは、「オブジェクト指向」ではなく、 「モジュール化」だった可能性はありませんか?

          さて、「いわゆるOOP」の機能の一部を 「モジュール」と言い換えるかどうかはともかくとして、 それ以外の部分に「オブジェクト指向」を導入して失うものが無いなら、 それはそれで問題はないはずです。 では、実際に「オブジェクト指向」で失うものは有るのでしょうか?

          元コメントの前後を見ると「とりあえず動くモノを早く提供する(#1224227)」ために OOPしないのだ、という意見があるようですが、 ここではその考えは採りません。 最初に述べたように、このコメントでは「事前にしっかりとした設計」という大前提で考えます。

          一旦立ち戻って、そもそも「オブジェクト指向」とは何でしょうか。 これは人により様々なことを言う人がおり、 前述の「モジュール化」の機能もオブジェクト指向に含めて述べる人もいます。 とはいえC++やJavaにおけるモジュール化機能は、 「オブジェクト指向」は「オブジェクト指向」でも、 クラスベースオブジェクトシステム前提となっているので、 例えばJavaScriptのようなプロトタイプベースオブジェクトシステムではそのまま当てはまらない要素が多く、 そのためこのコメント中では、「モジュール化」は「オブジェクト指向」の必須機能ではないとしました。

          クラスベースオブジェクトシステムとプロトタイプベースオブジェクトシステムで共通する要素はいくつかありますが、 私の知る限りほとんどすべての「オブジェクト」の定義に登場する要素は、

          • オブジェクトは内部状態を持つ。
          • オブジェクトはメッセージを受け取って内部状態を変える。

          の二つです。 「メッセージ」と言っているのはアクター理論からの借り物ですが、 Smalltalk始め多くの「オブジェクト指向言語」は、 「メソッドの呼び出し」という形でメッセージを受け取って、 インスタンス変数を変化させる、という機能をほぼ必ず持っています。

          私がここで「オブジェクト指向にしない理由」の一例として挙げたい点が、 正にここにあります。

          つまり、「オブジェクト指向」の設計においては、 「内部状態の変化するオブジェクト」がお約束のように登場してきます。 「オブジェクト指向プログラミングは綺麗なプログラミング」と思い込んで設計をすると、 そこに何の疑問も生じないのですが、 実はここで「綺麗なプログラム」と考えられる性質の一つを、 無意識に捨てているの

          親コメント
          • >>なんでそこにいるんだよ、グローバル?あっちいけよ。
            >「いわゆる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じゃないと生きていけない体になってます。
        仕事ではそりゃ言語を自分で選ぶことはできませんし、
        言われたままの規約に従ってコーディングするしかありませんが、
        自分のために各ツールなんかは C++ + boost がないと生きていけない…
        フラットな構造になってるとなんか覚えておかなきゃならないことが
        多すぎて困りませんか?「お前、アクセスされる必要もないのに
        なんでそこにいるんだよ、グローバル?あっちいけよ。」
        とか、そんな感じです。
        --
        屍体メモ [windy.cx]
        親コメント
      • by Anonymous Coward on 2007年09月24日 17時48分 (#1224096)
        はいはい、RoRでできることもPHPでできることも、全部チューリングマシンでできますよったら。
        親コメント
  • by Tatenon (20311) on 2007年09月24日 9時36分 (#1223830) 日記
    プログラムを書く人間ならそんなことは誰でも知ってる.
    それぞれ長所と短所があるし、長所はシーンによっては容易に短所に変わる.

    さらに、使い慣れた言語の開発効率は、使い慣れない「より開発効率の高い言語」のそれを容易に上回る.
    日本人が日本語を使うのと、日本語にあまりなじみの無い外人が日本語を使うのと、どちらが苦労するだろうか.
    逆もまた然り.

    # ただし、上記は同程度に問題の無い開発環境が与えられているのが前提である.
    # 特にデバッガの性能は開発効率に決定的な差を与える.
  • PHPと比べて、RoRが重いのはわかったのですが、 PHPの様に軽い、Rubyを使ったシステムはないのですか?

    --
    いつも主観で書き込んでいます
    • 比較対象がおかしい気がする。
      PHPとRuby比べるなら分かるし、
      (本来の)Rubyのように速く動くほにゃららって文脈なら分かるけど。
      PHPだってフレームワーク通したらうんざりするほど遅くなる。Rubyもそうなんじゃないのかな。
      Rubyほとんど触ったことないですけど。

      #FWて「書き方を強制する」っていうメリット以外は感じたことがないなー
      #そしてそれをメリットと感じる機会はほとんどない
      親コメント
  • 似て非なる事例 (スコア:2, おもしろおかしい)

    by masayang (13412) on 2007年09月25日 5時32分 (#1224274) ホームページ 日記
    Javaはだめだっていって、COBOLに戻った人達。

    #だめなのはそいつら
    --
    ---- 末は社長か懲戒免職 なかむらまさよし
  • by Anonymous Coward on 2007年09月24日 10時18分 (#1223865)
    ・なんかコードが読みにくい。規約うぜぇ
    ・さくらインターネットとかロリポップなどのレンタルサーバーで(せっかく)作ったアプリを動かせない
    すいません、へたれですorz
    • 心配ありません。両方とも現在railsが全然流行っていない原因ですから。

      特に痛いのが2番目で、一応cgiとしても動きはするのですが、
      リクエストの度に膨大なライブラリを全て読み込まなくてはいけないので
      普通のPCサーバーだと2~3秒/reqくらいかかってしまいます。

      実用的な速度を求めると、fastcgiかwebrickかmongrelという選択肢に
      なるのですが、これらはプロセス常駐型なのでサーバー貸し切り型の
      プランでないと稼働させることができないんですね。

      rails自体の性能は、実行速度面でも開発速度面でも十分実用的なのですが、
      こうも導入障壁が高いと、そのうち新しく出た物に負けてしまいそうです。
      なんかいいアイデア無いものでしょうかね。
      --
      Lv5以下の社員全員にデスマーチ!
      親コメント
      • by Anonymous Coward on 2007年09月24日 14時12分 (#1223998)
        もともとCGIの起動コストが大きいのが難点なんだよね。
        それにデータも、いちいち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は許すって点です。
        要するに「常駐型は危険」という切り分けは迷信でしかないということ。
        親コメント
        • by mojalor (16164) on 2007年09月24日 19時06分 (#1224132)
          それよか不思議なのは、
          mod_hogeとかの常駐型を許さないレンタルサーバが、
          同じ常駐型であるPHPは許すって点です。


          mod_phpはインタプリタが常駐するだけで、各種シンボルテーブル等は
          リクエストの度に初期化される(リクエスト終了時に必ず開放される)ので
          mod_xxx経由でスクリプト自体が常駐する他言語のApacheモジュールとはまた勝手が異なります。

          また、PHPのアドバンテージとしてCGI/FastCGI、Apache他のサーバモジュール、
          どの環境でも同じように動くという点もあります。
          CGIの場合、httpdの設定によっては正しいPATH_INFOを取得するためにphp.iniの設定を
          変えないといけないこともありますが、スクリプトは全く同じものが利用できます。

          言語自体の良し悪しとか速い遅いではなく、開発環境と実行環境の差違を
          あまり気にしなくてよいのがPHPが広く使われている理由ではないかなと。
          親コメント
      • そうすると、AmazonのEC2 [amazon.com]は結構いい選択肢かもしれないですね。 サーバは貸し切りで値段もそんなに高くないし。
        親コメント
  • Ruby on Rails が支持された大きな理由は、 Ruby という言語にあるわけではなくて
    「設定より規約」という考え方にあるのではないでしょうか?

    もちろん大昔からプロジェクトごとのコーディングルールという考え方はあったわけですが、
    「ただなんとなく、みんながそうしているから、プロマネに怒られるから」というあまり
    積極的な理由ではなく、その規約に従うことでコードの大規模な自動生成という見返りが
    得られるということがミソだったとおもいます。

    これはプログラミング言語によらず適用できる考え方なわけで、今後は他の言語でも
    on Rails 的なアプリケーションフレームワークが出てくるかもしれませんね。
    --
    屍体メモ [windy.cx]
    • by Anonymous Coward on 2007年09月24日 12時14分 (#1223917)
      >自動生成という見返りが得られるということがミソ

      自動生成に限らず、手書きコードもその規約に従うとご利益が色々と…ですね。

      で、規約によるDRYってのは、逆に
      「テーブルの存在なんかプログラマからは完全に隠蔽してしまえ」
      (ましてテーブル名前なんか知らなくてもいい)
      という隠蔽というか階層型のシステム構成/開発体制とは、
      実はあまり噛み合ってないってのは味噌。

      ほら。Railsは「アジャイル」開発ツールですから。
      各開発者がシステムの隅から隅まで一通り知ってるっていう体制が前提。

      分業体制においては、テーブル名にコードをあわせるという規約は、
      DB担当者以外にとっては「意味不明の暗号に合わせる」ことにしかならない。

      Railsが出たときの解説の1つとして「疎結合より密結合」ってのがあったけど、
      それは実装だけじゃなく、開発(者)の体制のことも意味するのよね。

      >他の言語でもon Rails 的なアプリケーションフレームワークが出てくるかもしれませんね。

      既にいっぱいあります。

      GroovyによるGrailsとか。
      知らないけどPythonにもきっとあるよね。

      あと出所とかは違うけど結果的に似てるのがSeasar2とか。

      ところで誰も気づいてないみたいだけど、
      VisualuRuby (WindowsGUIバインディング)も実は名前規約ベースだよな。
      イベントプロシジャのバインディングに名前を使っている。

      というか、VRが手本にしたというVisualBasicに、起源を問うことも出来そうです。
      あれも、中身がどうなってるかはよく判らないけど、見かけ上は名前ベースですよね。

      なんだ、MSは20年も前から規約によるDRYを実現してたわけか…。
      実際VBでも、GUIとコードのバインディングに、設定ファイルなんて書かされないもんね。

      待てよ?そもそもRailsの他の売りである「フルスタック」も、
      MSの商売戦略と同じですよね。
      「同じブランドで出してるツール郡だからまとまりがある」っていう奴。
      親コメント
    • by Anonymous Coward on 2007年09月24日 16時50分 (#1224078)
      「設定より規約」もバランスだよね。
      その辺、かけてるのが多いんじゃない。
      規約っつーか、もう暗黙の塊みたいな・・・

      末端プログラマはそれでいいのかもしらんが、
      まとめるほうは逆に覚えること多すぎでやってられん。
      シンプルに保つという見方からは、逆行してるとも思う。
      Seasarとかもうついていけないね。
      親コメント
  • by Anonymous Coward on 2007年09月24日 21時44分 (#1224184)
    Struts みたいに(主にスーツ組に多い気が)信者(??)が沸いて何でも Rails 状態にならないようにと。
    # Java と Ruby って最近縁近いしなあ・・・
  • by Anonymous Coward on 2007年09月24日 23時14分 (#1224208)
    2年間もコネて一から作り直しで上手く行くのは当然だろ

    要するに2年間プロト版を開発・設計した成果なんじゃね?
typodupeerror

計算機科学者とは、壊れていないものを修理する人々のことである

読み込み中...