システムを作る時に、どういう考え方で作るか？は重要です。
私はPHPもRubyも、よく知っているとは言えないのでネットでいろんな意見を見ます。
しかし、システムインテグレーションでプロジェクトマネージャなどを経験していると「新しい技術」よりも、「確実に動くのか？」のほうが重要です。
言語よりも生産しやすいフレームワークのほうが重要です。
このふたつからすると、PHPフレームワークのLaravelよりもRubyのRuby On Railsのほうが条件を満たします。
理由を書きます。
Railsは2004年からの歴史に耐えてきていおり、Laravelは2011年に作られ10年の歴史があります。
どちらもいいフレームワークだと思います。
ただプログラミング言語としてのRubyはオススメできません。
Rubyが日本のまつもとゆきひろさんが作ったプログラミング言語です。
コンセプトは「プログラミングが楽しくなる」ということで、すでに学びましたが、中級プログラマー以上にウケる機能満載。
しかし他のプログラミング言語と違い、相当にクセがあります。特有の書き方ができるということは、Pythonとはまったく反対の思想ですね。
また動的なオブジェクト指向をとっているので、データの型がわかりづらい。
私がプログラミング言語を始めた時は、BASICインタープリターのような変数の型がはっきりしないものより、Pascalのような変数の型が厳格なもののほうが最初に学ぶにはいいし、応用が効くとよく言われたものです。
三番目に「すべての式が返り値をもつ」特性を利用していると、メソッドの返り値を知るために、全部を読まなきゃならない。
これはめんどくさい。
他にも独特の表現があり、かなりユニークなプログラミング言語といえます。
まとめるとRubyは仕事のプログラムを書きやすいかもしれないが、可読性の悪いプログラミング言語です。
最初に学ぶ言語としてはオススメできません。
Pythonと正反対。
さて、
PHPは文句を言われている言語です。私もよくないな、と思う点は変数の命名規則がないこと(スネーク？キャメル?)と、変数名をタイポすると発見が難しいことです。先にも書きましたが、変数を定義できるプログラミング言語はタイポするとたちどころにわかります。
まぁ、フレームワークとして機能がそろっているということ以外に、好きでないRubyで書かれたフレームワークのRuby On Railsを選ぶ大きな別の理由があります。
それは現実の学習コストです。
おそらくフレームワークの機能としては、LaravelよりRuby On Railsのほうが多く複雑です。
それでもあえてRuby On Railsのほうが学習コストが低いと、私は言いたいです。
実際に「個人開発をはじめよう」という本を見てもRailsで作っている人が圧倒的に多いのです。
これが現実です。
理由は「Ruby On Railsチュートリアル」の存在だと思います。
Railsを学ぶ王道と言われ、ウェブサービスをやっている人々の中で少なからない人が「これで勉強した」と言い切っているのです。
日本語版はこういうサイトにありますが、動画によるオンラインセミナーが29,800円＋税です。36時間ほどあります。
このチュートリアルは更新され続けていて、意味がなくなるということはないようです。
このチュートリアルが抜群に優れているのは、Ruby On Railsに使われているCSS, BootStrap, bundle, Githubなどの諸技術も統合して教えてくれることです。まるでWeb開発の現場を体験するような構成です。
この点を誰も言及しないのは不思議だ。
逆にちょっと勉強のためにという目的でRuby On Railsは向きません。ウェブサイトを開発するという目的がないと挫折すると思います。
一方、Laravelのオンラインコースは日本語だとSchooで月額980円のようです。
そこでLaravelの使い方だけのようです。言い換えると学習の決め手にかけるのです。
いろんな本読んで、いろんなオンラインコースを受けていると時間がかかります。
自分が実際に費やす時間を考えるとLaravelは学習コストがRailsよりも高い、と私は判断しました。
いつも書くことですが、優れたフレームワークは日本で作られることはありません。
すべて海外製です。
言い換えると日本のプログラマーの技術力は私もふくめ、高くはありません。
すぐれたプログラマーの作品を安易に非難する風潮が日本にはありますが、自分じゃ作れないのだから敬意をもつべきだと思います。
最後ですが、いずれのフレームワークも古いという人もいます。Javascriptベースが最新だ、と。
理由は理解します。イマドキのウェブアプリケーションはひとつの画面でデータはJSONなどでやり取りをし、サーバー側からHTML+CSSを送るというパターンは古いと言われているからです。どれもJavascriptでいい、と。
しかしですね、その傾向って最終的にはブラウザーを否定するということになると思います。
なぜならばAndroid, IOSアプリをダウンロードさせ、サーバーとはデータのやり取りのみということを理想だと言っていることになるじゃないですか。
HTMLもCSSもメンドクサイから独自のプロトコルでアプリ作ろうぜ、となります。
ブラウザーにHTML,CSSを送り、RESTfulが好ましいと言われていることはブラウザーのルールに従うということです。
ブラウザーのルールに従うからこそ、あらゆるマシンのブラウザーで同様に動くということが保証されます。
結局、なにをしたいか、どうやって高い生産性を維持したいのか、でサーバーサイドのフレームワークは決まる、ということですね。
