定期的に「CakePHP VS Rails」のような比較だったり、「CakePHPからRailsに移行しました！」みたいな話題がネットに上がっていると思いますが、今回はCakePHPを今使っているけど、「Ruby on Railsってよく聞くフレームワークはどうなんだろう？」と気になっている方に向けて書いてみます。
CakePHPしか使っていなかったころ、よくRailsエンジニアの方に「CakePHPはRailsの劣化コピーだ。」みたいな言われ方をしてへこみました。で、Railsに移行するか悩みましたが、なかなか両方を使った経験のある人が少なく、あまり参考になる意見は聞けないんですよね。
自分はCakePHPを１年半、その後Railsを1年半使ったので、今悩んでいる人の参考になる記事が書ければと思います。
結論からいうと、もう私が個人的にCakePHPに戻ることはないです。ただ、全員がRailsに移行するべきかというとそれも違うと思います。この記事では、
- 具体的にどのような点がRailsの方が良いと思ったか、悪いと思ったか
- どういう人が移行したほうが良くて、どういう人が移行しなくてよいか
というのをCakePHPエンジニア目線で説明できたらと思います。
（なお、CakePHPは2.4までしか使っていないので、それ以降はもしかしたら状況は違うかもしれません。）
もくじ
Railsのよい点
スポンサーリンク
テクニカルな面
ライブラリー管理がスマート
PHP界も最近はComposerができましたが、RailsにもBundlerというのがありもっと歴史が古く洗練されています。ComposerはまだCakePHPに統合しきれていないので、設定が面倒です。Composer自体へのPATHの設定、ライブラリーがインストールされるディレクトリーの設定、ApacheのDocumentRootの設定まで気にしなくてはいけません。Bundlerの場合、プロジェクト作成後に bundle installというコマンドを実行するだけで、すぐに使うことができます。また、プラグインを追加したい場合はGemfileというファイルに追記して bundle installを実行するだけでOKです。
ルーティングがスマート
RailsではRESTfulなルーティングがデフォルトになっています。GET、PUT、DELETE、PATCHなどのHTTPメソッドまで含めてルーティングに使われるため、シンプルなURLで多くのアクションにルーティングすることができます。
ちょっとわかりずらかったですが、例えばCakePHPの
/posts/view/25へのリクエストはPostsControllerのviewアクションに引数25を渡して呼び出します。
Railsだと
/posts/25にHTTPメソッドのGETをすることでPostsControllerのshowアクションに25を渡して呼び出します。
また、CakePHPだと削除は /posts/delete/25というようなURLになりますが、Railsだと先ほどと同じ /posts/25にHTTPメソッドのDELETEをすることで、PostsControllerのdestroyアクションを呼び出せます。
つまり、HTTPメソッドを使うことで、URLがシンプルになっているということです。CakePHPだと全てHTTPメソッドのGETで行うため、URLにアクション名が入ってきてしまいます。mapResource()を使うことでRailsと同じようなことをできますが、Railsはデフォルトになっているため、このあたりのルーティングが非常に気が利いています。
また、RESTfulなURLを縛りに感じる人も多いですが、実はモデルに対してCRUDの処理をコントローラーの決まったアクションでさばくというのは、悩むことが少なくて非常に楽です。CakePHPだとそのような縛りは文化として弱いので、自由にアクションを増やしたり名前をつけてしまいがちです。でも、このRailsの縛りになれると、決まり切ったアクションだけでだいたいのアプリケーションは実現できることがわかると思います。設計上の余計な迷いが少なくて済みます。
RESTfulなURLは、最近のスマホのバックエンドのAPIとしてもわかりやすいです。このURLにどのHTTPメソッドで送ればどのアクションが動くというのがきちんと共通言語となりスマホの開発者にとってもわかりやすいものになります。
マイグレーションがスマート
CakePHPではマイグレーションはプラグインとしては提供されていますが、あまり使いやすいものではりませんし、ドキュメントも貧弱です。なので、多くの方が直接phpmyadminなどからテーブルの操作を行っているのではないでしょうか。
Railsでは、マイグレーションがデフォルトとなっており、 ドキュメントでもしっかり説明されています。なので、phpmyadminを使うことはほとんどありません。コマンドラインから差分のマイグレーションファイルを作成し、テーブルへの変更を行っていきます。例えばコマンドラインで、
|
1 |
rails generate migration CreateProducts name:string part_number:string |
を実行すると、
|
1 2 3 4 5 6 7 8 |
class CreateProducts < ActiveRecord::Migration def change create_table :products do |t| t.string :name t.string :part_number end end end |
というマイグレーションファイルが生成され、コマンドラインで
|
1 |
rake db:migrate |
と実行するとproductsテーブルが作成されます。コマンドラインだけでテーブルへの変更作業が完結できます。
このファイルをgithubで管理することで共同作業も楽になります。差分で変更していけるので、データを削除することなく反映できます。
CoffeeScript、Sass、Hamlなどのメタ言語の導入が楽
JavaScript、CSS、HTMLをよりシンプルに書くためのメタ言語である、CoffeeScript、Sass、Hamlなどの導入が非常に簡単です。先ほど紹介したGemfileにプラグインを追加して bundle installを実行するだけで使えます。
CakePHPだとこれらのメタ言語を使いたい場合は、Node.jsとGruntやGulpなどといった環境を用意しなくてはなりません。
アセットの管理がスマート
CSSやJavaScriptはロード時間を考慮すると、複数ファイルあってもプロダクションでは一つにまとめて、minify（スペースや改行を削除）したいところです。また、ブラウザにキャッシュされて更新が反映されないことを防止するために、ファイル名にハッシュ値などをいれるのがよいとされています。CakePHPだと、これらに対してなんら方策は準備されていませんが、RailsにはSprocketsというプラグインがデフォルトで採用されており、これらを全て自動的にやってくれます。
最近では、React.jsなどのJavaScriptフレームワークが出てきて、Sprocketsとは相性がよくないとされていて、使わなくなっている人もいるようですが、jQueryなどを使う程度であれば、Sprocketsは非常に便利なツールです。
ORMが直感的
データベースにSQLをかける処理はCakePHPでもRailsでもORMを使いますが、CakePHPのそれは非常に非直感的です。例えば、inner joinで複数のテーブルを連結する場合、以下のように書いていました。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
<?php $this->Entry->unbindAllModels(); $this->Entry->bindModel(array('hasOne' => array( 'Theme' => array( 'foreignKey' => false, 'conditions' => array('Theme.id = Entry.theme_id') ), 'User' => array( 'foreignKey' => false, 'conditions' => array('User.id = Theme.user_id') ), ))); $this->Entry->contain('Theme', 'User'); $theme = $this->Entry->findById($this->passedArgs['entry_id']); |
Railsだと
|
1 |
Entry.joins(:theme, :user) |
みたいな感じで書けます。ちょっとCakePHPは忘れかけているので、一対一で対応していないかもしれませんが、イメージとしてはこのくらい直感的に書けます。
CakePHPだと生SQLで書いちゃったほうが楽なのにー、と思うことしばしばだったのですが、Railsだとぐっとそういう機会は減りました。（それでも時々あります）
バックグラウンドの処理が楽
時間がかかるような処理はユーザーを待たせてからレスポンスを返すのではなく、バックグラウンドのキューにタスクをいれてユーザーには次の画面を早めに見せてあげたいというのがサービス運営者だと思います。CakePHPだとCakeResqueというのがありますが、まだまだ統合が進んでいないし、ノウハウも少ないです。
RailsだとAcitiveJobというのがデフォルトで簡単に使えるようになっていますし、ネット上にも事例が多くあります。
テクニカルの面は多すぎてきりがないのでこの辺にしておきます。
文化の面
コミュニティの強さ
Railsはリアルでもオンラインでもコミュニティに勢いがあります。本日時点で、勉強会サイトconnpassで「CakePHP」と「Rails」でそれぞれ検索してみました。すると、
- CakePHP : 41件
- Rails : 357件
という結果になります。私もCakePHPを使っている時期は、なかなか勉強会をみつけることができませんでした。なので、難しい問題にぶつかっても、なかなか誰かにきくということはできず、孤独に調べたり実験をしていました。ところが、Railsに移行したところ、勉強会は毎日のように開かれています。そういうところに顔を出していれば、何かわからない問題があっても、人に聞けるチャンスが非常に多いです。テクニカルな面ではないですが、このコミュニティの強さがRailsの大きな魅力です。
スタートアップ段階での人材の採用のしやすさ
採用に関しては色々意見があります。PHPエンジニアのほうが絶対数は多いのだから、採用もしやすいはずだ、という意見は多いです。ただ、スタートアップ段階の会社だとRailsの方が人材を集めやすいです。というのは、PHPプログラマーとRubyプログラマーの気質によるものかもしれませんが、私がスタートアップで採用担当をしていた時の感触でいうと、スタートアップでの開発をやってみたいというRailsのエンジニアが多かったです。PHPのエンジニアは全然応募してくれませんでした。PHPのエンジニアはそれなりのお金をもらって大きな会社に雇われている方が多いように感じます。逆にRailsエンジニアは少々リスクがあっても、面白そうな開発に挑戦したいという方が多いように感じます。CakePHPのスタートアップをやっていた時に、「Railsだったら手伝うのに。」と何度言われたことか。
最近の日本のスタートアップでもCakePHPからRailsに移行している会社が目立っていますが、やはりエンジニアの採用面への効果を狙っていると思われます。自分の認識だと下の会社などです。
スポンサーリンク
Railsのわるい点
こんなにRails万歳な記事を書いてきていうのもなんですが、一つだけちょっとなと思うことがあります。
Railsエンジニアは技術にこだわりすぎる
Railsエンジニアの方は貪欲に新しいものを取り込もうとする方が多いです。なかにはそれを導入してユーザーは喜ぶの？と疑問に思うことも結構あります。最近のバズワードとして「技術的負債」という言葉がありますが、Railsエンジニアは技術的負債を返済することにこだわりすぎている傾向があると思います。ユーザーも全然いない、売上もあがっていないようなサービスであれば、技術的負債を返すよりも、まずビジネスとしてどう成り立たせるかに注力しなければなりません。が、そのような視点をもったRailsエンジニアはそんなにいないのではないでしょうか。
Twitterは最初Railsで作られていましたが、ScalaやJavaに移行しました。Parse.comもRailsでしたがGoに移行しました。Twitterの場合はもしかしたらトラッフィックの都合上仕方なかったのかもしれません。でも、Parse.comの場合はあの時点で本当にGoに移行すべきだったのでしょうか。もっとユーザーの意見を取り込んで使いやすくする方を優先すべきだったのではないでしょうか。
逆にPHP周りの人達は、「動けばなんでもいい」というような感じで現実的な気質の人が多い気がします。
FacebookはPHPにこだわり続けていると言えます。Runtimeこそ通常のPHPではなく独自のHipHop Virtual Machineというものを使っていますが、言語はPHPです。そのような、「無駄に移行しないで今使っているものでいかにユーザーを喜ばせるか」という姿勢がTwitterに差をつける要因になったのではないでしょうか。
こんな人はRailsに移行するべき
CakePHPを使っていてなんか直感的じゃないなーと苦痛を感じる人
今思い起こすと、CakePHPしか知らなかった時も、どこか言い知れぬ苦痛を感じていました。ライブラリー周りだったりアセットの管理だったりマイグレーションだったり、ORMだったり。どうもややこしいと感じる方は、CakePHPの想定以上の規模のシステムを作ろうとしている人だと思います。そんな人はRailsに今すぐ移行してください。大抵の苦痛は緩和されます。
CakePHPのRailsの後追いをする感じが嫌な人
CakePHPにそこそこ慣れてくると、欲しい機能はRailsにあるって情報がはいってきたりします。少し経つと「次のバージョンでCakePHPでもそういう機能がつく!」みたいな情報が流れてみんな喜んだりしているのですが、これってなんか変ですよね。
だったら、Rails使っちゃったほうがいいなと思うんですよ。もともとCakePHPはRailsをPHPでもやってみるというコンセプトのもとに始まったようなので、どうしてもRailsの後追いになってしまうんですよね。なので、CakePHPの思想を追求していこうとすると、結局Railsをやったほうがいいという結論になるんです。
スポンサーリンク
こんな人はRailsに移行しなくてもいい
非常にシンプルなサイトを作りたい人
例えば、シンプルな掲示板程度のサイトであったらRailsをわざわざ学習する必要はないです。ただ、ユーザー管理などを導入して行って、テーブルが5個以上になるレベルのシステムになるなら、Railsの学習コストをペイしてくると思います。
資本のある大きめのプロジェクト
先ほどPHPプログラマーのほうが絶対数が多い、といいました。なので、資本があって人を大量に投入できるようなプロジェクトならCakePHPの方が強いと思います。例えば、「CakePHPプログラマー20人」必要みたいな状況はお金で解決できると思いますが、「Railsプログラマー20人」必要という状況だと、絶対数がPHPプログラマーほどではないのでお金があってもなかなか集められないからです。
CakePHPエンジニアがRailsを学ぶには？
CakePHPエンジニアがRailsを学ぶのは、正直シンドイです。
おそらく、RailsエンジニアがCakePHPを学ぶほうが10倍簡単です。
というのは、Rubyの世界のほうがPHPの世界よりも、概念が多いからです。
オブジェクト指向だったり、コマンドラインだったり、いろいろな概念が登場します。
PHPの世界はそのような概念は少ないのでかなり自由ですが、その分各人が勝手に開発スタイルを編み出していくので、混沌としていて、洗練された手法が産まれにくいです。
Rubyのそのような概念は確かに学習コストはかかりますが、あとで100倍の生産性になって戻ってくるという感覚です。
自分も数年前、CakePHPエンジニアのとき、Railsを学ぶのは非常に苦労しました。
ですが、今は当時よりも学ぶための良い手段がたくさんありますし、教えられるRailsエンジニアの数も増えています。（自分の時は教えられるレベルの人は非常に少なかったです）
Railsのおすすめ入門教材についてまとめたので、よろしければご覧ください。
手っ取り早く短期間でマスターしたい方は、スクールでプロから学んでしまうのもアリかもしれません。次の記事がまとまっています。
個人的には、オンラインで質問し放題で現役のエンジニアが教えてくれるテックアカデミーがいいと思います。他のスクールは結構学生とかが講師やってます。。。
どのようにレッスンが進むか、無料説明会動画を視聴するとよくわかるので、興味がある方はそれだけでも見てみるといいかもしれません。
テックアカデミーの詳細な体験記事は以下がよくまとまっていますね。
テックアカデミー評判口コミ｜30代OL初心者が真剣受講した結果。。。
