Laravel、たのしい拡散の仕方
タグ： Laravel
よし！自分でも完全にできない、偉そうなことを言おう。なので、参考程度に読んで下さい。
フレームワーク・ウォーはごめんだ
フレームワーク・ウォーが明確に定義づけられるものではありませんが、一般的には利用率というマーケットで、シェアを健全に奪い合うという意味では使われません。「こっちが素晴らしい、あっちはダメだ」という賞賛と批判を互いに繰り返し、争い事になることです。
フレームワーク・ウォーに限らなくても、言語や開発手法、その他考えつくことなら何でも、「こっちが素晴らしくて、あっちはダメ」という主張は、どこででもあるものです。リアルでもありますね。けど、リアルであれば、「押し付けがましい」、「批判的」という世間の目というストッパーがかかり、そうそうできるものではありません。あるスーパの店長が「あそこのスーパーは品揃えが悪い、うちは商品が豊富で、品物が良い。」なんて、コミュニケーションばかりを取っていれば、お客さんは段々と足が遠のくでしょう。
ネット上では、こうした他人の目に気づきづらいため、容易に発言しがちです。ですが、この状況をお互いに繰り返せば、簡単にこの手の現象は発生します。
フレームワーク・ウォーは議論の一つではないかと思う人もいるでしょうが、一般的には批判合戦になります。そうでなければ、戦争なんて単語は使いません。そして、何かを議論するのであれば、反論する場合でも、相手とその主張に敬意は払わなくてはなりません。まさか、日曜の朝の著名人や政治家の言い合いを議論だと思っている人はいないでしょう。
そうした言い争いを見ていればわかるでしょうが、当人たちも見ている視聴者も心が乱され、余計なエネルギーを消耗します。フレームワーク・ウォーも同じです。消耗戦です。関われば、疲れて、コーディングやらデザインやらに費やすエネルギーが少なくなります。
Laravel（そして、他のフレームワークでも好ましいと思えば）が気に入っている方も多くいます。ですから、「Laravelがいい、こんな所は良い。」という発言は、とても良いことです。ですが、その素晴らしさを強調する余り、「他のフレームワークのここはダメ」という発言は控えましょう。これそこ、フレームワーク・ウォーを仕掛ける行為です。
批判というのは直接的で、それを行うことで自分の正当性や頭脳の明晰さをお手軽に主張できますが、反動のほうが通常大きいものです。大抵の人は、冷たい目であなたを見るようになります。
そして、多くの経験を積んだコンピューターユーザーはフレームワーク・ウォーを経験済みで、そのような行為をみると「ああ、また不慣れな奴が、騒動起こそうとしているな」と考えるでしょう。多分、自分の過去を顧みて… ;)
ですから、あなたが自分のお気に入りのフレームワークを見つけたなら、良い所を大いに宣伝して下さい。でも、他のフレームワークの悪いところを引き合いに出さないようにしましょう。
せめて、批判はオブラートに包んだり、やんわりと使ったり、スパイス程度に効かせたりする程度にしましょう。ただし、これは高等なコミュニケーション能力が必要になります。そして、相手に対するリスペクトも含めなければなりません。難しいです。ですから、シンプルに批判は止めておきましょう。
そして、批判先には人々がいることをお忘れなく。あなたはたかがフレームワークや言語について悪口を行ったつもりでしょうが、そこにはユーザーが存在し、あなたはそのユーザー達から恨みを買うことをしています。
でも、あり得るのが、逆にフレームワーク・ウォーを引き起こす発言に出会ってしまうことです。あなたのお気に入りのフレームワークが攻撃されています。さあ、たいへん。どうにかしなくちゃ！
ここで、一息つきましょう。その発言の、影響範囲を考えましょう。
もし、小さいようなら、無視しましょう。どこかの初心者が自分の知識をひけらかすため、あなたのお気に入りを批判しているだけです。あなたのエネルギーを削がれないで下さい。
もし、大きいように思えるのであれば、直接的に反論するのではなく、間接的な情報を流しましょう。もし、重鎮が「オレンジが気に入らない」と発言したら、いかにオレンジが綺麗な色かという情報をネットに流しましょう。重鎮の発言は検索で上位を取るかもしれませんが、それ以降にオレンジがいかに素晴らしいかという検索結果が、多くの人たちから発せられた情報として、続けてリストされたら、オレンジが素晴らしいかどうか見分けようとしている、新しいユーザーの判断を偏らせることなく、中和することができます。
シンプルで健全で安全な方法として、他がどうであれ、自分のお気に入りのフレームワークの宣伝をすることです。使用記事、解説記事などで情報を流すことです。あなたが、自分のお気に入りの良さを自分の言葉で強調すれば、それに共感する人も増えていくでしょう。
あなたは自由です。どのフレームワークや言語、マシンも使用できます。でも、それらは道具です。道具を使いこなすのではなく、道具に使われないで下さい。
そして、「弘法、筆を選ばず」はたいてい、コンピューターでも事実です。私の過去の経験から言えば、本当に優秀な技術者は、ある程度のこだわりがあって、「こんなの使わなくちゃ、ダメなの」なんて言いながらも、そのすぐ後には、見事に使いこなして見せてくれたものです。「これでなきゃできません。」は、ちょっとスキルを覚えたくらいの未熟な人たちがよく使う言葉です。最近良く書いていますが、ヘビーで高機能なフレームワーク熟練者から言わせると、「大きなフレームワークは遅い」という主張は、高速化するための技術まで到達できず、ちょっとかじった程度の人が言っている言葉だそうです。したり顔で、「ヘビーなフレームワークは遅い」なんてうっかり書いちゃうと、よく知らないのがバレバレになります。（Laravelでは、最適化はartisan optimizeで簡単にできちゃいます。よかったですね。）
コミュニティー
多分、１９８０年代だと思いますが、コミュニティー学という学問が広まり始めました。もちろん、ネットとは無関係です。要は似たような特性を持つ人たちが、グループを構成するという主張です。皆さんの経験とも一致しているでしょう。まあ、当たり前のことが学問として成り立っていたわけです。
コンピューター上のコミュニティーは、時々派閥になってしまいます。特に、日本のコミュニティーはその傾向が強いようです。多分、あなたが他のフレームワークのコミュニティーでバリバリ活躍していれば、間違ってもLaravelは良いねなんて言えません。言ってご覧なさい。直接的に反論は受けなくても、他のことでメンバー（いつもはほとんど発言しない人たち）から、噛み付かれるでしょう。（裏切り者に、血の制裁を！）
取り敢えず、フレームワークに絞れば、ただの開発環境ですよ。道具です。あなたが自分の意志で使えばよいもので、それに縛られるものではありません。自由に使い分ければ良いだけです。縛られてはいけません。あなたは自由です。
フレームワークなどのコミュニティーは把握しやすいですが、もうちょっと厄介なのが「顔見知り」というコミュニティーです。なにせ表立っていません。フォーラムに参加していたり、Facebookのグループに参加しているのであれば、発言をちょっと見てみれば関係が分かります。しかし、リアルやネット上の友達、顔なじみは簡単に把握できません。
私一人と、その他大勢の人が、Laravelの機能についていかにも議論しているようなまとめを見たことがある方もいるでしょう。実際は、私はいつものようにLaravelで検索し、アンチな意見には、その逆の好ましい意見を自分の発言として流していただけです。もちろん、アンチな意見を「中和」するためにです。
私は返信していません。私が返信するのはいつも、発言がLaravelに対する質問に思えた時だけです。
どうも、そうした意見が主張にズレがあるにせよ、発言している人が顔見知りなのではないかと数人をスポットし調べました。はっきりとは分かりませんが、そうらしいと感じられました。
先日、他のことである検索をしたら、その時にごそっとその時否定的な意見を発言していた人たちがまとめて引っかかりました。そこで、「ああやっぱり、顔見知りじゃん」とわかったわけです。
もちろん、顔見知りですから「味方をしなくては」という考えが強く出たのでしょう。Laravelなんて、この先どうなるかわからないものより、絆を大切にしたというわけです。感動的ですね。そのため、多少強引な意見もでたのでしょう。いつもなら、冷静な人たちも、知り合いのため多少行き過ぎたわけです。
ところが、時間が立ち、こうしたグループの中でもLaravelを使ってくれる人が出たようです。そのため、ある人たちは（血の制裁を取らずに）Laravelをより攻撃し、多くの人たちは両方との絆を大切にするため、今度は口を出さないという賢い方法をとっているようです。（これが一番賢い方法です。たかが道具ですよ。道具。）
Laravelの日本のコミュニティーは、できれば自由なまま、縛り無しで行きたいですね。Facebookの英語のグループは、なにか規則っぽいものを作ったらしいですが、必要なのでしょうかね。Facebook自体の利用規約が存在するから、それだけで良いと思います。Facebookであれ、何であれ、自由に参加し、自由に抜け、参加しながら、他に首を突っ込むのもOKでなくちゃ。自然に集まり、自然に解散というふうに、力み無しで行きますように。（まあ、違っていても参加しなけりゃ良いだけですね。:D ）
好き嫌いと善悪
多くの人が本当は違うことを言っているのに、その中に共通点があると、人間の脳は素晴らしく、その共通点を見つけ出します。そして、大抵の場合、「数が多ければ真実だろう」という固定観念で共通項を真実だと思い込みます。なにせ、自由世界に生きている私達は、多数決が正しい選択方法だと思っています。（北朝鮮なら、「将軍様の言う通り」が、正しい選択方法です。戦時中の日本は、天皇の勅令でした。）
また、人間は権威に弱いものです。医学博士が書けば、どんなトンデモ本でも真実だと思います。ちょっと有名な人が何かを言えば、それも信じちゃいます。ですから有名人が詐欺の加害者側の近くにいることが多く、多くの芸能人はそれが元で消えていきましたね。
さて、Laravelのファサードは、反対派のターゲットになります。アメリカの場合、「Laravelは静的メソッドが多い」という批判でした。Laravel３の時、これは真実でした。ただ、このときは「Laravel３は静的メソッドが多い、だからテストがされていない」という批判であり、実際のところ、コアクラスのテストは十分に行われていたため、この批判は当たらないと反論されていました。実際、Laravel４になってからも、静的メソッドが多いという批判はまだあり、その本来の批判点は、「だから、テストが十分に行われていない」というものです。
ですが実際、ハックしてテストすることもできますし、便利なテストのフレームワークもありますから、手間をかければ静的メソッドでもできないことはないのです。この手間を書けても、多分今度はテスト方法について、一部から批判が出るでしょう。
さて、Laravel４になり、ファサードクラス経由で静的メソッドのように書きながら、実際はインスタンスを生成する通常クラスメソッドであるという仕組みが導入されました。これは、アルファバージョンからありましたし、事前にも説明されていましたし、正式版リリース時にはドキュメントにも書かれていました。それでも、Laravel４は静的メソッドを使っているという、ステレオタイプの批判は引き続きありました。でも、最近は宣伝が行き届き、この勘違いによる批判はずっと減りました。
このファサードにより通常のメソッドを静的なメソッドのように見せているという事実が英語圏のコミュニティで十分に行き渡った頃、誰かがそれをわざわざブログ記事にまとめました。この時、「わざわざドキュメントに書かれていることを書くなよ」と思ったので、よく覚えています。
その後、日本でも誰かが概要を紹介し、それを見つけたLaravel未使用者（アンチとは言いません。多分、何人かは現在使用しているでしょうから。）が、否定的な意見を述べたわけです。
ちょっと読めば「そうかな」と思いますが、実際は、そうでもないようです。もし、そのとおりであれば、英語圏でLaravelのファサードを活用している人たちは、全部間違っていることになります。
本来、フレームワークの機能というものは選択的です。利用者が使うか、使わないかを選べます。もし、Laravelがファサード固定であれば、回避策はありません。しかし、名前空間でクラスを指定することで、生のPHPで書くように、パッケージを使用することもできます。つまり、回避策はあります。
ですから、ファサードの使用・未使用は選択肢の一つにしか過ぎません。
私が個人的に、Laravelのファサードに改良を求めたいのは一点だけで、モックフレームワークがMockery固定であることです。私自信は、Mockeryしか使用していないため、不自由はありませんが、他のパッケージを使いたい人もいるでしょう。これを交換可能、もしくは追加可能にしてもらえれば、もっと利用しやすくなるでしょう。（もちろん、モックフレームワークは簡単に使用できるように設計してあるため、ファサードが取り込まなくても、大した手間がかかるわけではありません。）
ファサードを使わなくてもLaravelは活用できるので、あくまでもこれは選択肢です。もちろん、使ったほうが便利です。コードをシンプルに見せかけてくれます。
「読み書き」の「読み」の方ですね。「書き」の方は良い面と悪い面の２つがあります。良い面とはもちろん、記述が短く素早く記述できることです。私はFeulが日本で流行り出した頃、使っていましたが、その時の宣伝文句を覚えています。名前空間をずらずら書かなくて済むというものでした。
エディターでは、名前空間の補完はさほど行ってくれるものはあまりなかったようです。しかし、Fuelのコアの開発者はPHPStormを使う人ばかりでした。当時でもPHPStromは名前空間の補完をやってくれていました。ということは、推測ですが、Fuelの開発前は別のエディターかIDEを使っていたということでしょう。初めから、PHPStormを使用していたら、Fuelは生まれていなかったかもしれませんね。ちなみに当時、NetBeansでも既に名前空間の補完をしてくれていましたよ。
記述は短くて済むのですが、素直にメソッドの補完ができないという欠点はあります。もちろん、解決策はあります。Laravelでは、有志の手により、補完のためのパッケージが開発され、各自の環境に合わせたものをComposerでインストールすれば利用できます。
ファサードへの批判自身に戻りましょう。批判ですから、「間違っている」、「すべきである」という主張になります。何も考えなければ、その主張をそのまま考えがちです。
しかし、こうした主張には元になる開発手法や使用しているフレームワークの考え方が元にあります。それは批判者一人ひとりが異なるため、別の角度からの批判となります。
でも、よく考えれば、そうした主張の元になる考え方をするならば、初めからLaravelを使うはずもなく、そうした考えをしている人たちにはLaravelは創りだせません。
そして、基本的な考えは自分で選択して身につけたものです。（たとえ、業務で使用するからという理由にせよ。）ですから、それはその人の好みの問題です。善悪のはずがありません。
批判は善悪のうち、悪へ行うものです。ですが、絶対的な悪は存在しておらず、良し悪しというものはコンテキスト（コンピューター屋さんが好む表現です）、平たく言えば状況に依ります。その国々により、国内法が違うようにです。
もし、韓国が日本の交通法は車両が左側通行でおかしいと言われたら？もちろん、余計なお世話です。国＝状況がちがうのですもの。しかも、それを言っている人が謙日で、日本に来ることがなければ？更に、余計なお世話でしょう。もし、「おまえの国が左で通行しているから、お前の国で運転を覚えたドライバーが、うちの国で事故起こしたらどうしてくれる？」…まあ、鼻くそでもほじり、聞き流しましょう。
批判されても、それを言っている人とLaravel使用者のバックボーンは異なり、状況も異なります。批判している人は、Laravelを使うことはないでしょう。（最近、この状況は変わりつつあるようです。）Laravelでフレームワークを覚えた人が、ファサードを当たり前だと考え、他のフレームワークで間違えるという批判は？馬鹿げている？でも、あるんですよ。アメリカでも、日本でも。（私、直接、返信されましたもの。）どのフレームワークでも、言語でも、最初に覚えたものは印象が強いため、その考え方を別の言語やフレームワークで適用し、間違えてしまうというのは、誰でも経験することです。複数言語やフレームワークを扱えるようになるには、誰でも通る道でしょう。取り立てて、Laravelだけの問題では無いことは明白ですね。
つまるところ、元になる考えは個人の好みなのです。善悪ではありません。もし、「私はこちらのほうが好きだ」というのであれば、それは個人の考えです。でも、「〜は間違っている」、「〜すべきだ」という表現は、否定を表しています。相手に反感を抱かせます。そのため、使うのは間違っています。はっきりと好みだというべきでしょう。（:D 分かりました？この矛盾に満ちた表現が。しばらく、すべきが続きます。;P）
正確に言えば、ツイートなど文字数が限られた状況で、自分の背景にある考えを前提として話し、それに対し反していると書くのはまあ無理な話です。受け手がいることを考え、センスティブな問題とし、文字数制限のないブログやらで背景を含め書くべきでしょう。
また、自分が使う予定がないものを、誰かからの賞賛を得るために、わざわざ批判しないことです。ほんの少しの知り合いから賞賛されるでしょうが、より多くの反感を得るでしょう。その中には、別の友達、上司、取引先、同僚も入っている可能性があることをお忘れなく。
長いですね。短く言い直しましょうか？「好き嫌いを、善悪として書かないでちょーだい。荒れるから。」
本場の状況
さて、Laravelの本場、米英（英語圏と言い直したほうが正確です）では、どうなっているのでしょう。
既に述べました通り、LaravelやFuelは「静的メソッドを多用している、だからテストされていない」といういわれの無い非難を受けています。実際はよくテストされています。これを言っているのは、ちょっとテストを習ったばかりで、「静的メソッド＝テストできない」と教えられた初心者です。もしくは、工夫ができないオールドタイマーです。
そして、Laravel4ではファサードが取り入れられ、実際はテストしやすいオブジェクトの通常のメソッドだけれども、静的メソッドとしてアクセス可能になりました。ドキュメントも読まず、ちょっとサンプルコードを除いただけで、「静的メソッドだ」と相変わらず、非難する人はいます。まあ、Laravelが人々の関心を惹きつけ、初心者が次々やってくるかぎり、この状況は繰り返されるでしょう。
定期的に、この話題が上がり、そのたびごとにファサードだという説明が成されます。既に、多くの解説記事が存在していますが、そのたびごとに新しいブログ記事が書かれます。
ある時、この状況が再現し、その時にLaravel開発者のTaylor Otwell氏と、頑固プログラマーがツイートしていました。頑固プログラマーとは自分のことを頑固と言っているテスト推進派のおじさんですが、こだわりが強く、あちこちのコミュニティで嫌われている人です。:D
要は、頑固プログラマーがファサードについてなにか発言したことに、Taylorさんが「Facadeはサービスローティター・パターン」だとにこやかに返し、「それはいいんだが、初心者が静的メソッドを良いものだと勘違いする」と食いついていました。まあ、それだけです。切り返されたので、何か言わないと気がすまなかったのでしょう。
これが、前述の「米にも勘違いすることを批判する人はいる」というもので、私が知っているのは、これだけです。PHPが静的メソッドを用意している限り、初心者は使うでしょう。そうした初心者がテスト云々を学び、静的メソッドを通常は避けたほうが良いことを体得するには、まだまだ道は長いものであり、その頃には初心者では無くなっているでしょう。また、テスト道には足を踏み入れずに、進む人たちもいるでしょう。そうした人たちには、静的も動的も関係ありません。ですから、誰もこの意見にかまいませんでした。スルーされました。
これが、日本で同様の批判ツイートが行われる前日にあったことです。
では、頑固プログラマーはLaravelを嫌っているのでしょうか。よく分かりません。彼はフレームワーク否定派ですから。でも、その彼が２日前「フレームワークは気に入らないが、Laravelだけは認めている」と発言していましたよ。
一週間程度前の話ですが、PyroCMSの開発者で、CIにたくさん貢献しており、PHP-FIGのメンバーでPSRの情報をよく流していることで、PHP界では有名なPhil Sturgeonが、何やらLaravelに対して批判的なことを言っているようなことを匂わすツイートがされていました。
実際は、Philがブログで「Laravelが急速にコミュニティーを伸ばし、Laravel専用のパッケージが増えているが、フレームワークに依存しないパッケージとして開発してくれたほうがPHPのためになる」という旨の記事を書きました。ところが、後ほど本人曰く、「言葉を使い間違えた」ため、批判的な内容と捉えられ、炎上しました。
そこで、Laravelの開発しを支援するためTaylorさんを雇っている（一ヶ月のうち、一週間分の勤務時間をLaravelに費やしてもよいのです）Ian（Iwanだったか？）さんが、それに反応した記事を書き、Philがコメントで反論していたのです。
その反論と元記事だけがツイートされたため、それだけを読んだ人はあたかも有名人のPhilがLaravelを非難しているように思えたでしょう。
実際は、ココらへんの人たちは、「顔なじみ」です。日本と違い、顔なじみでも「議論」はしているのです。常に「同意」が求められる、日本のコミュニティーとは違います。国民性、言語圏の違いによる習慣でしょうから、いかんともしがたいですね。（実際、この上層部の部分の人が固まってしまっている感じが強いのがLaravelコミュニティーです。たぶん、コミュニティーが急速に成長したせいか、コミュニティーピラミッドの上層にいる人たちは、中間層や下部の人たちとはネット上のコミュニケーションを取りません。PhilはLaravelコミュニティーでも、間違いなく上層部にいる人ですが、珍しく中間、下部層の人たちともコミュニケーションを取ります。）
そもそも、PhilはLaravelの初期から、Laravelとコミュニティーを支援しています。TaylorをPHP-FIGのメンバーに推薦したのも彼です。
今回の議論の後、ではPhilはLaravelから遠ざかったのかと言えば、そんなことはありません。PSR-4をLaravelでどのように使用するかというビデオをYoutubeへアップし、記事を書いています。
そして、日本時間で言えば一昨日、「Laravelでファサードを使うな」という記事http://programmingarehard.com/2014/01/11/stop-using-facades.html#comment-1197189841に昨日コメントし、ファサードの利点をポイントアウトしています。また、アンチが書いたのかって？
いいえ。この記事はLaravelユーザーにより書かれたものです。この記事を書いた人は、Laravelを通常のPHPのように使いたかったらしいです。ただ、タイトルが強すぎたため、Laravelユーザーからは反感を買ったようです。紹介されている方法も、ちょっとせわしないようでした。
そして、数時間前、Laravel開発者のTaylorがわざわざ、この記事に対して反応記事を書きました。http://taylorotwell.com/response-dont-use-facades/ IoCコンテナを使って、CIのように書けるよということです。余り興味ないので、真面目に読んでいません。
ねえ。言ったでしょう。ファサードは強制でないって。開発者自ら、回避策を示していますよ。この記事は３日間に渡って少しずつ書いています。前半部分を書いているときはTaylorの記事はありませんでした。すごいタイミングですね。
ファサードの使用は選択肢の一つです。簡単に使用でき、読み書きしやすいため、使用する人が多いですが、使わないくてもコーディングできます。要は好き嫌いです。Laravelユーザーだから、ファサード使用するのが正ではありません。
よし。自分で実行するのが難しいことを書ききったぞ。（ところで、批判はうまいこと、やんわり伝わっているでしょうか？）
追伸：書き忘れたので一言。
多分、ファサードのことを批判している人たちは、LaravelがSymfonyの上を行くという、正にフレームワーク・ウォーを引き起こす日本語の記事に反応した人たちと重なります。ですが、この記事を書いた人は当時Laravelユーザーでなく、既にSymfonyユーザーから発言で目をつけられていたようです。私は正直、記事の内容を読み、これは反感を呼ぶから迷惑だと思いました。Symfonyコミュニティーで認められず、Laravelを引き合いに出し、もっと良い物があるぞと煽ったようです。そして、悪い予感が当たりました。強調しておきますが、この記事を書いた人は当時Laravelユーザーでは無かったのです。