以前に書いた( http://d.hatena.ne.jp/gallu/20140429/p2 )
http://blog.sumyapp.com/2014/04/rubyist-is-better-than-phper/
なのですが。
記事を全面的に改訂致しました
との事で拝見したのですが…相変わらず駄目過ぎるので、まぁこれも何かの縁かなぁと思ったので、軽く突っ込み。
先に魚拓を取っておきます。
http://megalodon.jp/2014-0506-2033-00/blog.sumyapp.com/2014/04/rubyist-is-better-than-phper/
＆
先に。
https://twitter.com/sumyapp/status/462628327149166592
@uzulla 炎上元記事も全面書き直ししました。毎日バッシングが飛んでくるのが辛くて。。PHP言語を使う権利はお前にはない！とか、諸々、卵アイコンな方々に。私もPHP使うんですけどね。。
うん「毎日バッシングが飛んでくるのが辛くて」っていうくらいなら
PHPおよびPHPerはコードを書くのが嫌い
PHPerは実はHTMLに毛が生えた程度しか使えない人が多い
PHPは低級プログラマと過去の負債に引きずられる
なんていう発言を、根拠もエビデンスもなくするのをまず辞めた方が良いと思うんだけどなぁ。
さて。
フレームワークとは
うんここですでに色々オカシイ。
フレームワークが開発速度を向上させるからです。
ダウト。
「結果としてそうなることは多い」けど、それが目的では無いことも多いし、その辺を見誤るとヒドイ目にあうんだけどまぁ以下略。
開発者が日常的に使うソースコードを再度自身で書き直す必要性がないよう(DRY思想)
これもダウト。
DRYはまぁ自分も勘違いをしていたからってのがあるけど、それにしても、記事に書くんならまず調べてから書かなきゃ。
ここも「結果的にそうなりやすいけど、本質が見えてないから表面の上っ面しか見て取れない」のがよく見える感じ。
フレームワークは、同じ言語を用いるエンジニアがそれぞれ議論しながら作り上げた素晴らしいツールボックス、プロダクト、技術です。
………涙を流しつつ、ダウト。
苦労したことないんだろうなぁ…
フレームワークによる恩恵
これも酷い…というか、ものを知らない。
フレームワークがない世界では、「index.php」や「about.php」など、各ページごとにファイルを作成していました。
ダウト。
それを、MVC構造という概念が変革しました。データはModelが扱う。ロジックはControllerが扱う。ビューのレンダリングはViewが扱うというものです。
ダウト。
直後のwiki引用でちゃんと書いてあるのに orz
読んでないんだろうなぁ。
MVCに分割されたことによって、URLとファイルが1対1の関連性を失いました。
故に、これもダウト。
ファイル名を指定する必要などもなくなりました。
ダウト。それは「フレームワークが"ファイル名を指定しなくてもファイル名が解決できる、というルールを採用した"」結果に過ぎない。
URLと出力結果を記載するルールを定めるという制限により、記載する必要があるコード量が圧倒的に削減、開発速度が向上しました。
これもダウト。
Command Your Data
…なんだかなぁ。
ORMの否定については…一席ぶってもいいんだけど、とりあえず一端引用で。
http://d.hatena.ne.jp/e_p_i/20121208/1354924355
とか
http://tech.a-listers.jp/2011/06/16/orm_is_an_antipattern/
とかあたりを一度読んで、そこから深く考察を練るとよいと思う。
「全面的に否定」はしないけど、それが「SQLを知らなくてもイイ」とかいう寝言に起因するなら、速やかに滅ぼしたい感じだ。
モデルクラスのコードが変更された場合、データベースのカラムの変更が行われることは少なくありません。
これも色々と思うところがある発言だなぁ。
Composer Powered
ダウト。理由は以前にも書いたんで省略。
それ以外にも、ほかのエンジニアが書いたライブラリが使える、というメリットもあります。ライブラリの依存関係が管理されていなかった時代や、ライブラリの書き方などが統一されていなかった時代、ライブラリの置き場所が定まっていなかった時代では、ライブラリを検索し、導入し、用いることは簡単ではありませんでした。
それは貴方が無能なだけ。
じゃぁ「ライブラリの依存関係が管理されていなかった時代」は…そこそこ長いんだけど「何も手を打たず、考えもせず、ただひたすらにマンパワーに頼っていた」とか思ってるんだろうか？
Ruby on Railsは「設定より規約」による開発速度向上のフレームワークの先駆けであり
微妙だねぇ。まぁ「先駆け」にさほどの重きを置いてないからさほど大きくは突っ込まないけどさ。
毎年のようにメジャーアップデートが行われ、開発速度が向上していきました
ダウト。
PHP言語とRuby言語のそれぞれのエンジニアの比較を行ったわけではありません。ウェブサービスの開発におけるフレームワーク利用のための学習コスト（アップデートへの追従など）への投資がRuby on RailsがPHP言語のフレームワークりも多い、というところに起因します。
「学習コスト（アップデートへの追従など）への投資がRuby on RailsがPHP言語のフレームワークりも多い」は、エビデンスがあるのかね？
相変わらず「ぼくがそうおもった」を書くのがお好きなようで。
ダウト。
「PHPがメジャーであること」と「「とりあえず」でのフレームワーク選定」にはなんのつながりもない。
ついでに書くとそれが「PHPに固有の現象かどうか」も分からないし、そこから「PHPerのみが劣っている」とか言うために繋がる糸口もない。
「Rubyist is better than PHPer」については、Ruby on Railsを利用するエンジニアがPHP言語の軽量フレームワークを利用するエンジニアよりも多くの学習コストを支払っている可能性は高いと考えての記載です。実際のところ、優れたPHPプログラマはRuby言語もPerl言語も書けるでしょうし、Rubyプログラマも同様にPHPも書ける。学習コストを支払っているかどうかのみが争点です。
もはやまともな論理構造さえ有していない文章。
言い訳をしようとしてとりあえず単語を並べて「日本語っぽい、文章っぽい何か」を書き殴った感がぬぐえない感じ。
全体的に「結論ありきで文章を書いている」あたりから推測するに。
恐らく「PHPでイヤな事があった」または「Rubyを使っている事に優越感があった」のどちらか、または双方に起因してとりあえず「PHP及びそれを使ってる人を、とにかくdisりたい」っていう「結論」があったんだろうなぁ、と。
で、とりあえず「自分の目の届く範囲にある問題点」をあげつらって「だからPHPerは駄目なんだ」と言いたいんだろうなぁっていうか言ってたんだろうなぁ、と推測されます。
まぁとりあえず正直「彼自身の評判や、そこに起因する、会社の風評とか、そこに起因するサービスの風評」とかどうでもよいのですが。
フレームワーク…に限らないのですが。「道具に振り回された人」が考える「道具について」という観点から、少し興味深いなぁ、と思ったので、軽く、自分の中の整理を兼ねて突っ込み。
うんとりあえず「依存関係を自動的にどうにかしてくれる」とか「ORMやスキーマのバージョン管理やDBマイグレーション」とか。
「ぱっと見"すげぇ"」な機能って、経験の浅い半可通の目をくらませるには便利な機能なんだなぁ、と思いました。
別に「不要な機能」ではないんだけどね。ンなもんは多くの技術者が「一度は通っている道」で、それに対する対処も「色々」あって、その先もまた「色々」あるのよ…っていう「先」が見えていないあたりがなんていうか「この道はいつか来た道」だなぁ、とか思うわけです。
突っ込んでない箇所には多少「ちゃんとした」事が書いてある部分もあったので(それがちゃんとかみ砕けているのかどうかはともかく)。
どこかで何かに気づいて適切に自分をアップデート出来ると、本人も周囲もシアワセなんだろうなぁ、と思いました。
