PHPでRuby on Railsと同じものを作ることは可能でしょうか?


言語が違うので100%同じは無理だと思いますが、どこまで近づけられるのでしょうか?
(あるいは、どこが無理でしょうか?)

回答の条件
  • 1人5回まで
  • 登録:
  • 終了:2012/02/16 08:00:04
※ 有料アンケート・ポイント付き質問機能は2023年2月28日に終了しました。

回答2件)

id:language_and_engineering No.1

回答回数170ベストアンサー獲得回数63

ポイント50pt

それはCakePHPのことでしょうか

他1件のコメントを見る
id:language_and_engineering

こんにちは。

何%とは,難しい定量化ですね…。 でも,知りたいポイントだと思います。

申し訳ありませんが,下記の2つの文章に対して,脳内でいわば intval() する事で%を想像してみて頂けないでしょうか。
イメージはつかんで頂けるかと。

  • PHPとRuby on Railsの経験者を,入門書を片手に,CakePHPを使った開発に即投入できるぐらいの類似です。

  • RubyとCakePHPの経験者を,入門書を片手に,Ruby on Railsを使った開発に即投入できるぐらいの類似です。
2012/02/09 12:30:48
id:DQNEO

なるほど。設計方法とか考え方が似ているから、即投入が可能ということですね。
参考になりました。
ありがとうございます!

2012/02/11 12:37:34
id:taroe No.2

回答回数1099ベストアンサー獲得回数132

ポイント50pt

>言語が違うので100%同じは無理だと思いますが、どこまで近づけられるのでしょうか?
>(あるいは、どこが無理でしょうか?)

質問の真意からみると、無理。

感覚的には、70%から80%程度が限界。

真似できない部分が、Ruby on Railsのよさだとかいわれだすと
この%はずーっと下がるわけです。


Rubyの言語特性に依存している部分が無理。
特性であって機能でないことに注意が必要。

id:DQNEO

・70%から80%程度
・真似できない部分をどの程度重要視するかによって変わってくる
railsはRubyの言語特性に依存してる部分が少なからずあるということですね。
この部分が、"Rubyだからこそ作れた"ということになるわけですね。
なるほど。

2012/02/11 12:39:02
  • id:tdoi
    CakePHPがRuby on Railsを非常に意識して作られたPHPフレームワークです。
    とはいうものの、開発者が異なれば、思想も少し変わるのはありますね。できる、できないではなく、やる、やらないの問題として。

    http://blog.katsuma.tv/2009/05/cakephp_and_rails.html
    ここによると、クラスやブロックのフィルタが使えないというのがCakePHPにない機能ですかね。
    この機能がどんな機能かちょっと知らないのですが・・・。

    あとは、次のサイトも比較としてはまとまってていいですね。
    http://www.slideshare.net/gautamrege/rails-vs-cakephp
    http://blog.endpoint.com/2010/11/ruby-on-rails-cakephp-syntax-comparison.html

    個人的に思っていたのは、MigrationのサポートがCakePHPにはないなぁと思ってたんですが、ちょっと調べて見ると、MigrationをサポートするPluginとかはあったりするみたいなんですよね。

    Railsの機能を全て押さえている訳じゃないので、コメントで。
  • id:language_and_engineering
    確かに。
    というかフレームワーク以前に言語レベルで,PHPとRubyで発想法が違いすぎます。
    そこを各種プラグインでカバーしようと試みているのが現状でしょう。

    さいきん(PHP5.3~)ようやくクロージャが導入されたので,PHP側のフレームワークの発想法が根底から改善されてくれるかもしれません。
    が,この「ブロック」っぽい概念を皆が自然に使いこなすほど浸透するまでには,結構な時間がかかりそうですね。


    とはいえ,
    「PHPでのRails系フレームワークとしては,CakePHPが存在する。」
    というのは,SI業界内では間違った発言ではないと思いますよ。

    個人的には,Rails系FWとして上記の両方を業務で使用した結果の感想として,
    Cakeは「PHP on Rails」という名前にでもすればもっと認知されただろうに
    と感じています。

  • id:tdoi
    賛否両論あるとは思いますが、個人的に「PHP on Rails」はいまいちな感じですね。
    Ruby on Railsの完全継承を目指していたりすれば別ですが、CakePHPはRuby on Railsをお手本とはしつつも、やはり少し違うところを見てるんじゃないかなぁと。

    個人的にはCakePHPも十分認知されているとは思ってます。
    RubyにはRuby on Railsしかない半面、PHPには、Zend Framework、Symphonyなどのフレームワークも存在し、デファクトと言える位置に立てなかったために認知度が低く感じのかなと。あとは、ごりごり書くPHPerが多くフレームワークを使うという文化がまだ浸透していないこともあるかもですね。

    また、本来ならば適材適所だと思いますが、それを判断できるエンジニアがPHPerに少ないというのも問題の1つかもしれませんね。
    多分、

    RubyでWebシステムを作る = Ruby on Railsを使う

    という認識があると思ってますが、

    PHPでWebシステムを作る = 選択肢がいっぱい

    ということなのかなと。
    実際、規模が小さければ、Smartyだけ使っちゃった方が早いとか、レガシーな遺産の流用するなど色々ありますからね。
    良くも悪くもRubyにはない歴史がPHPにはあるということでしょうか。
  • id:language_and_engineering
    id:tdoi氏

    上記で述べて下さった内容に同意致します。


    PHPは,とにかく人が集めやすい。Rubyはまだ今は厳しい。
    その原因は,歴史の差も一つの大きな要素だと思います。

    なので,PHPもRubyも使い分けになりますよね。
    どちらか片方を完全視してしまうと,よくある不毛な論争を生む事になりますし…。
    そういった議論は避けたいものです。


    >「PHP on Rails」
    すみません,これは私見です。どうかお気になさらずに。


    ※P.S.

    >RubyにはRuby on Railsしかない

    まあ実際にはSinatraとかMerbもあるんですが,
    Railsの存在比が大きすぎるのは確かです。

    ですので,「Railsしかない」と表現なさるのもごもっともで,
    これは否定・反論できないな。と思います。


    あと,「歴史差」に関連して
    面白いグラフを2つ出してみました。

    -(1)「PHPとRubyの歴史差を感じるグラフ」
    --http://www.google.co.jp/trends/?q=PHP,+Ruby

    -(2)「CakePHPとRuby on Railsの歴史差を感じるグラフ」
    --http://www.google.co.jp/trends/?q=CakePHP,+Ruby+on+Rails

    これは何かしら示唆が得られるかもしれません。
    とはいっても,実際にググる際は大概,省略して「Rails」としか打ち込みませんので,一つの参考情報に過ぎませんが…。


    では,質問者であるDQNEO氏のご参考までに。
  • id:tdoi
    language_and_engineeringさん

    >「Railsしかない」と表現なさるのもごもっともで,
    いえいえ。僕もろくに調べずにコメントしてしまいすみません。
    SinatraとかMerbとか知りませんでした。というより、Rubyで仕事するときって、Rails前提のことばかりで、フレームワークから探してみようってことがなかったですね。

    勉強になりました。
  • id:DQNEO
    language_and_engineeringsさん、tdoiさん、ありがとうございました。
    ご紹介いただいたURLは全部見ました。
    大変勉強になりました。

    とりあえず Ruby on Railsを自分でやってみて、感触を確かめてみたいと思います。
  • id:DQNEO
    実装・仕様と関係ないところで言うと、
    ・インストールのしやすさ
    ・プログラマの集めやすさ

    がだいぶ違いますね。
    この2点ではPHPの方に軍配があがりそうですね。
  • id:language_and_engineering
    DQNEOさん

    >・インストールのしやすさ


    もし「開発環境」という意味であれば,「Instant Rails」というパッケージをお試しください。
    ただ,パッケージなので,最新版のRailsを同梱するまでにタイムラグがありますが。
    http://mnb747.blogspot.com/2010/01/instant-rails-20.html



    もし「デプロイ環境」という意味であれば,今はクラウド時代になりました。

    下記エントリの(1)だけお読みください。興味深いと思います。
    手前味噌で申し訳ないですが…:

    Heroku(ヘロク)で,Ruby on Railsアプリを簡単に公開する方法の入門 (無料のRuby向けPaaS環境の使い方)
    http://d.hatena.ne.jp/language_and_engineering/20110914/p1
    >「Rubyのコードをレンサバにポイっと置いただけでWEBページ閲覧できるようになればPHPに大勝利できると思うんだよなー」というtweet→「それ、なんてHeroku?」(“Matz” こと、まつもとゆきひろ氏のtweet)



    >・プログラマの集めやすさ

    それも現実的に重要なポイントですよね。
    (2012/02/09 13:54:07のコメントでも申し上げました。)


    しかし「学びやすさ,習得しやすさ」で言うと,また違ってくるかもしれませんね。

    Rubyは言語仕様がシンプルなため,
    覚えることや余計なコードを書く手間が極めて少なく,
    「考えた通りにコーディングすればその通り動いてくれる」言語と言われる事があります。

    下記を参考に:


    #8 達人プログラマー Dave Thomas(後編)
    http://gihyo.jp/dev/serial/01/alpha-geek/0024
    名著「達人プログラマー」の筆者Daveが,プログラミング言語としてRubyを好む理由:
    >頭の中で考えたプログラムをそのままコードに転写するのに非常に向いています。考えたままに書けばたいてい動く



     
  • id:Artisan
    私はRailsとCakePHPしか触ったこと有りませんが、Akelosの方がRailsっぽいらしいようですよ。まだ話題に出ていないようなので紹介しておきます。

    > CakePHPはRailsインスパイアードであるのに対して、AkelosはPHPポート・オブ・Rails。完コピを目指してるようです。
    http://blog.takeda-soft.jp/blog/show/204

    私は未熟な引きこもりプログラマなので、断言はできませんが、Railsの一番の特徴は、その開発者の持つマインドや文化だと思います。彼らの多くは、コードの美しさや簡素さに特にこだわりがあり、その中で技術的な合理性を求めているような印象を持ちます。批判覚悟で例えるならば、Rails開発者の一級市民は、MacOSXでTextmateというエディタを使ってRailsを開発する人たちです。え? よく分からないって? オシャレな黒縁メガネに無印良品の洋服や雑貨に囲まれているというような印象です(すごい偏見だ)。シンプルで美しいものを好み、その中で技術的な合理性を追求していくというこだわりのある職人的文化なのです。その中でもカリスマ的読者モが集うのが37signalsという企業で…これ以上は止めておきましょう。

    PHP開発者の多くは、Rails的価値観とは対極にいる人達が集っている印象を受けるのですが、CakePHPはその中で誕生しました。もちろん、PHPは大変素晴らしい文化があることは承知してます。CakePHPはアーキテクチャレベルではRailsをかなり模倣した印象を受けますが、細かい部分、特にコードの見た目というRails開発者が最もこだわっている部分までは模倣できていません。それがPHPの持つ限界なのか、それともPHP開発者の思想なのかは私には分かりませんが、私のようなよく教育されたRails開発者にとってはCakePHPは煩雑で耐えられません。

    ということで、PHPでRailsの機能の完コピは十分可能かもしれません。でもそれはRails開発者にとっては意味のないことだということを知って頂ければと思います。
  • id:language_and_engineering
    Artisanさん

    質問者ではありませんが,横やりですみません。
    貴重な情報のコメントに感謝いたします。


    >CakePHPはRailsインスパイアードであるのに対して、AkelosはPHPポート・オブ・Rails。完コピを目指してる
    >よく教育されたRails開発者にとってはCakePHPは煩雑で耐えられません

    後発のフレームワークは,Cakeから良くも悪くも教訓を得,より一層良い物になっていくといいですね。


    Cakeってディープに使わないうちは便利なんですが,ディープに使いだすと,「配列地獄」に落ちて炎上するんですよね。
    (もちろん,そんなのあてはまらないよという方もいるのかもしれません。その場合はお許しを。Railsだって,うまく使わなければいくらでも炎上します。)


    そのように低レイヤの基本型(=配列やハッシュ)に頼る羽目になってしまう原因は,
    ・PHPではシステムの一番奥の肝心なモデル層のレイヤで「オブジェクト」を表現しきれなくなるから。
    なのかな,と考えています。


    PHPは,2004年7月にPHP5にバージョンアップする時点で,思い切ってオブジェクト指向を本格的に取り入れ,よく頑張りましたよね。

    (ちょうど,Railsの初代バージョンが発表されたのと同じ年の同じ月ですね。)

    他のプログラミング言語と同じく,もともとの言語の用途は違うものだったのに,後付けの文法を付け足す事によってちゃんとした「クラス」が作れるようになり,頑張って進歩を重ねた。


    そして次の年の2005年に,CakePHPプロジェクトが開始しましたね。

    またなぜか同じ年,Zend FrameworkとSimfonyのプロジェクトもスタートしました。(いずれもリリースは次年以降でしたが。)

    そのように2005年に急にムクムクと色々立ち上がり始めた様子を冷静に観察すると,PHP4までは,だいぶ厳しかった。って事ですかね。
    (はっきり言うと,MVCフレームワークを実現できるプラットフォームとしての成熟度が不足していた,という事になるでしょうか。)


    そういう経緯もあってCakeは,PHPのMVCフレームワークの黎明期を,今までよくリードしてくれました。
    当時,普及のためにPHP4との互換性を意識せざるを得なかった状況の下で,フレームワーク開発は大変だったでしょうね。


    PHPというプラットフォーム自体が修繕を重ね,その修繕が認知されてゆくにつれて,
    PHP製のフレームワークもベターな物がどんどん現れていってほしいですね。
    Cakeも2系のリリースを継続していますし。

    前の方がコメントして下さったとおり,PHP文化はRuby文化よりも,良い面でも悪い面でも遺産が多いため大きな土台があるので,まだまだこの言語は伸びる見込みがありますよね。


    >(Rails開発者)の多くは、コードの美しさや簡素さに特にこだわりがあり、その中で技術的な合理性を求めている
    技術者の自己満足に陥ってしまわないよう,注意が必要ですよね。
    フレームワークや言語はツールに過ぎないので,本来のさまざまな目的を見失って本末転倒になってはいけないなと改めて気付かされます。


    >MacOSXでTextmateというエディタを使ってRailsを開発
    >オシャレな黒縁メガネに無印良品の洋服や雑貨に囲まれている

    あてはまる要素が一つもなかった私は負(以下略)



     
  • id:Artisan
    language_and_engineeringさん

    ご返信ありがとうございました。私もPHP製のフレームワークも進化して欲しいと願っています。Cake2を利用していますが、同じくarray地獄でげんなりしてます(噂だとset使えばarray地獄に陥らないという話も聞きますが)。でも、CakePHPは簡単にセットアップできるとか、ユーザーが多いとか、ワンコインレンタルサーバーで簡単に設定できるというのがメリットだと思っているので無くなると大変困ります。これらの特徴は、Pythonのdjangoフレームワークにはないのではないかと思います。

    > 技術者の自己満足に陥ってしまわないよう,注意が必要ですよね。
    > フレームワークや言語はツールに過ぎないので,本来のさまざまな目的を見失って本末転倒になってはいけないなと改めて気付かされます。

    構文の見た目だけが技術的な利点ではないので、それぞれの技術の長所・短所を比較して採用したいものですね。おっしゃるとおりだと思います。

この質問への反応(ブックマークコメント)

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

回答リクエストを送信したユーザーはいません