Laravelを使うべきか
タグ： Laravel Laravel5.1LTS
Laravelの人気が出始めた初期では（と言っても数年前の話です）、「軽い」、「簡単」なフレームワークでした。現在、人気は世界中で爆発し、人気の秘密は「利便性」に移りました。
未だ進化の途中です。良かれ悪しかれ、基本的にLaravelはTaylor Otwell氏の個人プロジェクトです。GitHubやSlackで意見を受け付けていますが、現状用意されている便利な機能は彼の才能と判断によるものです。
その早い進化が逆にプロダクションにLaravelを投入するのをためらわせることもあったでしょう。RoRで最新版へ追従しなくてはならない悪夢を体感した開発者はデジャブを見ているかのようでしょう。
その悪夢を打ち破るため、Laravel5.1はLTSとなりました。Symfony2のLTSに合わせてのリリースです。バグフィックスは2年間、セキュリティーパッチの提供は3年間です。今の所、LTSには珍しく、機能も追加され続けています。
このサイトは、Laravel初心者向け情報を主に提供しています。と言っても、最近はLaravelの記事を書いてくれるサイトはたくさんありますので、ペースは落ちています。人気を挙げる初段には、どんどん情報を出すことが必要ですが、もう黙っていても情報は日々増えていく段階まで到達しました。
いささか情報過多の気配もありますので、Web開発初心者向けにLaravel、特に5.1を利用すべきか、私なりの考えを残しておこうと思います。
フレームワーク初心者？ No…
PHPであれ、他の言語であれ、Webサービスを作成するフレームワークを使ったことがなく、「フレームワークを学習したい」という方には現在のLaravelはおすすめしません。「便利」で高機能である代わりに、複雑になりました。
また、多くの自由を提供しているフレームワークです。それは開発者の判断に委ねることが多いということです。ある程度経験が必要としています。Laravelの初学者がメインの機能でないElixirやHomesteadで苦労して、利用を諦めるツイートが時々見受けられます。利便性のために用意されているが、本質ではない部分で苦労し諦めてしまうのは本末転倒です。しかし、初心者故にそうした判断も付けられないでしょう。
「フレームワークを学習したい」という思いの方は、まず簡単なフレームワークから始めることをおすすめします。PHPixieがおすすめです。PHP言語の知識だけで利用できますし、シンプルなMVCフレームワークです。Laravelでは利便性の裏に隠されている動作が丸見えです。欠点は日本語の資料が少ないことですが、トップページの"Get Start"ボタンで表示されるチュートリアルのコード（ファイル位置は先頭にコメントで表示されている）を写経するだけでも、MVC+ルーティング+ORMの関連性を学習できます。
将来的にLaravelを使うことを目標としていても、全く初学者であれば、このステップを踏んでおくことをおすすめします。
スピードが必要？
実行スピードだけを考え、フレームワークを選ぶ人がいます。どの程度のスピードが必要でしょうか？
ええ、Laravelは利便性重視のために、他のフレームワークより遅い部分があります。ですから、超シンプルなコードによるベンチマーク比較を見れば、遅いように感じるでしょう。ベンチマークを見てつぶやいている人を定期的に見かけます。
ところで、どの程度のスピードが必要でしょうか？ つまり、一日や一時間にどの程度のトラフィックが捌ければOKなのでしょう？ 同時接続数がどの程度で、レスポンスがどのくらいの速さで返ってくることを期待していますか？
経験の浅い初心者であれば、多分そんなことを考えてもいないでしょう。個人でフレームワークを勉強し始めた人が、「スピード命」の固定観念でとにかく実行スピードが早いフレームワークが良いと思い込んでいないでしょうか。正直な話、そうした方がLaravelで捌き切れないほどの人気サービスを最初からいきなり作成できる可能性は少ないでしょう。
個人がちょっとしたサービスを始める場合、きちんと計算してみれば、たいていどのフレームワークを使っても「十分に早い」という結論が出るでしょう。
レスポンスが検索結果に影響するとGoogleが言っているので、そうした意味でもスピードは大切です。ところが、共有サーバーに乗っけて、キャッシュを利用するなど多少は手を入れてたWordpressのサイトで、そうしたベンチマークでのLaravelよりはるかに遅いレスポンスであっても、Google様の判断によると「スピードは問題ない」とずっと言われます。遅い時には数秒かかります。平均でも１秒弱です。今は更新していないので検索順位は下がりましたが、毎日更新していた時には結構上位に入っていました。よく言われていますが、コンテンツの中身のほうが重要でしょう。
ベンチマークは、本番環境に近い構成のサーバーで、本番環境に近い保存領域へのアクセスが起きるプログラムで取らないと、意味ありません。たとえば同じ程度のスペックを持つVPSでも、各社によりCPU、HD、SSD、メモリの速度、バックボーンの回線スピード、割り当てられている通信量は異なります。同じ会社でもサーバーごとに当たり外れがあるという話もよく耳にします。ローカル環境とも大きく変わるでしょう。こうした影響があるため、各所で出されるベンチマークの内容は、ばらつきがあります。
また、中身のない最低限のコードでスピード的に大きな差が付いていても、実働プログラムレベルでは差が縮まる傾向があります。（実際には、リソースの消費状況により差が開くこともあります。そうした意味を込めても、実働環境でやらないとあまり意味がありません。）
また、通常の状態で比較すると大抵のPHPフレームワークより遅いとされるRailは人気を保っています。遅いのになぜでしょう？遅いのに大型のサービスでも使われています。答えはシンプルで、いろいろと高速化の手法があるからです。
膨大なアクセスがある予定のAPIを提供するという場合もそりゃあるでしょう。それであれば、PHPが適切なのかから考えたほうがよいでしょう。言われなくても、それくらいの仕事をする人であれば考えるでしょう。メンテの都合上、どうしてもPHPフレームワークでということであり、しかも高速化の手段は取れない、手間や予算を掛けたくないというのであれば、Laravel以外の軽いフレームワークを使いましょう。Laravelと同じく、Taylor氏が作成したLumenも選択肢の一つです。Laravelは予め様々な機能を最初から動作するように用意してありますが、Lumenは逆に最低限度しか用意していません。必要なものを付け加えていくフレームワークです。（膨大なアクセスがあるのに、予算も手間もかけないというのは、かなりけち臭い話ではありますが…）
もちろん5.1
簡単なフレームワークを事前に体験したであれ、どうしても直接Laravelにチャレンジしたいのであれ、他のWebフレームワークを経験済みであれ、Laravelを使用することを決めたら、どのバージョンを使用するべきでしょうか？
この記事を書いている時点で5.2が準備中です。5.2まで待つべきでしょうか。
おすすめはPHPのバージョンや拡張の要件を満たせれば、5.1を選択しましょう。LTSでこれからも知見が長期間に渡りWeb上に溜まるため、情報が探しやすいでしょう。そして何しろ、以前のバージョンより、公式ドキュメントが整備されています。概念が整理され、わかりやすくなっています。
5.1の要件を満たせない場合は、4.2のほうが情報量では有利かもしれません。5.0で新しい概念や仕組みが導入されましたが、わかりづらい部分が多く、5.1では機能は残っているもののドキュメントで紹介されていないものがあります。5.1がLTSになるというのは、5.0リリース時点では予定になかった話です。今では5.0は5.1リリースまでのワンポイント中継ぎピッチャーのようになっています。
動作環境をどう作成するか
現在、いわゆるLAMP構成かそれに似た動作環境が用意出来ているなら、それを生かしましょう。
LaravelにはHomesteadという公式Vagrant Boxがあります。これはLaravelの機能が一通り使用できる環境を整えてある仮想Boxです。しかしながら、VagrantやVisualBoxなど動作させる仮想化の仕組みについて、ある程度は知っておく必要があります。知識を持っていれば簡単に使える便利なものですが、一筋縄で動作できない場合に、Vagrantなどを勉強するはめになれば、遠回りになります。（遠回りをしてもいつか役に立つこともあるでしょう。逆に一生役立てる機会が持てない場合もあるでしょう。）
また、Laravelが動作するVagrant BoxはHomestead以外にも存在しています。中にはVagrant Boxより管理がとても簡単なものも存在しています。
必要なPHP拡張がインストールしてあれば、Webサーバーを立てなくてもPHP組み込みWebサーバーでどうにかできます。特に初心者レベルの勉強では十分でしょう。（なにせ、初心者が最初にはまりがちな、ディレクトリーパーミッションのつけ忘れが回避できます。）
インストーラーか、composerか
環境が整い、いざLaravel本体をインストールする場合、Laravelインストーラーを利用する方法と、Composerを利用する方法があります。
Laravelインストーラーは定期的にComposer updateをかけたLaravelのインストールパッケージをそのままZip圧縮したファイルをダウンロードし、ローカルマシンで解凍することで、Laravelプロジェクトディレクトリーを用意します。
Composerによる方法はLaravelに必要な依存を調べ、解決し、必要なパッケージをダウンロードし、Laravelプロジェクトを用意します。
変な宗教戦争にとらわれず、どちらを使っても良いですし、理想は両方でインストールしておけるようになりましょう。基本的にインストーラーのほうが早いのですが、ホストからのダウンロードのため、同時にダウンロードする数が多い場合は遅くなります。Composerの場合はまれにPackagistが不調だったり、依存パッケージが更新中で中途半端な状況で動作しなかったり、異常に時間がかかったりします。両方使えれば、片方が不調の場合にもう一方が利用できます。
最初はプロジェクトを頻繁に作り、試しながら遊ぶためにインストーラーが便利です。しかしパッケージを追加したり、更新するためにはComposerが必要ですから、最終的にはComposerを使う方法を取る人が多いのではないかと推測します。Composer自身もキャッシュの仕組みを持っていますので、何もキャッシュされていない全く初めての場合は時間がかかりますが、２回目以降は多少スピードが更新できます。
将来、Composerの便利さに気がついたら、toranプロキシの採用も考えましょう。（学習段階の初めは手を出さないようにしましょう。学習対象に集中しましょう。）toranプロキシは個人は無料で使用でき、一度アクセスしたパッケージをローカルマシンでキャッシュし、ローカルマシン上のパッケージはcronで定期的にチェックし最新状態に保ってくれます。Composerによるパッケージ取得先をこのプロキシにしておくことで、一度アクセスしたパッケージであれば、わざわざPackagistに行かずにローカルで処理できるため、取得速度が上がります。
もしくは、自分のよく利用するパッケージを定期的にアップデートし、最新版をローカルに作っておく方法も取れます。Laravelに限らずフレームワークを利用し開発していくうちに、使用するパッケージは決まってきます。ならば、それらを取り込むプロジェクトを用意しておき、cronで定期的にcomposer updateをかけておけば、自分専用の最新インストールパッケージがいつも準備されています。必要なときにコピーしてすぐに利用できます。（もちろん、composer.jsonファイルだけあれば、いつでも同じ環境は利用できます。composer installを実行する時間を節約できる方法です。）
Elixirはどうしましょう
Laravelのタスク自動化の機能です。全く知らないなら、忘れてください。全く必須ではありません。
Homesteadと同じ話です。Elixirはタスク自動化のGulpのスクリプトです。Gulp周りの自動化について詳しければ、スムーズに使用できるでしょうが、知識がないのに使用しようとすれば、学習量が増えます。
タスク自動化の方法はいろいろありますので、Elixirにこだわる必要はありません。Elixirが自動化の最善手というわけではありません。フレームワークの本質ではありませんので、好みで選んでもよい部分です。
もともとElixirはTaylor氏ではなく、Jeffry Way氏により作成されました。彼は現在、PHPStormを使用しているようです。PHPStormであればGulpのタスクはプロジェクトから簡単に実行できます。（NetBeansでも次期8.1からデフォルトで簡単にGulpタスクが実行できるようになります。）推測ですが、それでGulpを利用しElixirを作成したのでしょう。
自動化であれば、IDEやエディターの機能でも可能ですし、sassやcompassなどでもファイル監視による起動が利用できます。そうした機能で満足しているのであれば、Elixirは必要ありません。