起業・スタートアップ・ベンチャーTweetPocket最近、といってもここ2年ぐらいからだけど、これからプログラミングの勉強を始めますという人から、「CakePHPの勉強してます」とか「Railsの勉強してます」とか、そういう前提で中々うまく進められないと相談を頂いたりする機会が多い。Rails」や「CakePHP」を使うな』という個人的なアドバイスだ。これは個人的には本当に守ってほしい、絶対に手を出してほしくない、Framework達である。みんな「Railsってイケてる技術だよね」「Railsだったらこんなこともいとも簡単にできちゃうんだよね」みたいな印象を持っている。それは間違いではない。ライブラリもたくさんある。コミュニティも活発だ。CMSなんて昔は数人月かけて作ったものだが、いまはRailsとプラグイン(ActiveAdminなど)やscaffoldなんて使えば、1人日で出来てしまうほどのものだ。Railsを覚えたい、ということには賛同する。メリットは間違いなくでかい。RailsはあくまでWEB開発においての常識(Rail)を集めた、Ruby言語用のFrameworkである。FrameworkはあくまでFramework。自動車のABS(アンチロック・ブレーキ・システム)なんかとは全く違う。ABSはあくまでブレーキがロックしてしまう事象を発生しないようにアシストしてくれるシステムである。Frameworkは違う。framework)とは、プログラミングにおいて、一般的な機能をもつ共通コードをユーザーが選択的に上書きしたり特化させたりすることで、ある特定の機能をもたせようとする抽象概念のことである。フレームワークとも呼ばれる。「一般的な機能を持つ共通コード」を自身で書ける人が、それを再利用可能なものにするために、枠組みとして提供するソフトウェアがFrameworkである。Rails2系の時からよくある「DBマイグレーション機能」データベースtest_projectっていうdbに「users」というテーブル名で、名前、メールアドレス、パスワードを入れようとした場合、下記のようなコードが必要になる。("version");COMMIT;実際にはschema_migrationsやTRANSACTIONの部分はなくても構わないが、それでも非常に長い1行、下記だけは必要である。("version");しかし、Railsを使った場合、たった以下のコマンド3行でDBが作成される。CMSのように使えるスキャフォールド画面付きだ。db:migrateこれは尋常ではない。みたいなキーワードに踊らされている初心者が多すぎるのではないだろうか?正直な所、私もRailsを使いこなせているとは言いがたい。Rubyのコミュニティは非常に活発だし、オープンソース・ソフトウェアもたくさんあってすごく便利だ。href></a>でいいじゃないかと思ってしまうが、継続的インテグレーションになるとほぼ必須の機能になってくる。Rails2系の頃はまだよかった。その程度の機能量ですんでいた。Rails4なんて狂気の沙汰だ。デフォルトで有効になってる「Turbolinks」機能なんて、普通のサービスが使いはじめるレベルの機能じゃない。機能の拡張と削除のスピードが半端無さすぎる。CakePHPなんて2年ぐらいほとんど変わってないのに、Railsの変わり具合は半端ない。まじめに保守するサービスじゃないと、アップデートにはついていけない。エンジニアのスキルセットも。私も、Rails3~4の機能でさえ、ほとんど使えていないだろう。コミュニティの恩恵を授かっているに過ぎない。(Frameworkのデフォルトの機能ではなく)なんというか、例えるなら、教習場で免許を取ろうとしている人が、教習車に、F1用のばりばりのレースカーを毎週専門家にチューンさせながら使う、ようなもののように感じる。基本のスキル、教養なしに、パワフルすぎるものを扱っている感じ。のしすぎ」としか言い様がない。要らない知識を取得するために必要な知識を修得するための時間を捨てているようにしか思えない。GETとPOSTの違いもわからない人が、ルーティングやらフォームの自動生成やら使えるわけがない。自動化は「既にルーチン化できるようになったもの」に対して行うべきだ。未知のものを自動化するのは狂気だ。この記事にぐさっときた人、プログラミング初心者にとっておすすめしたいのはこの書籍だ。(電撃文庫)※あぁ、こんな先輩社員が会社にいてくれたらなんてハッピーな事だろう。「知らないコマンドを打つな」「コピペするな」そういうアタリマエのことを、ライトノベルで、可愛い女性(2次元)から教われる素晴らしい書籍である。頭の硬いプログラミング見習いの方には読んで頂きたい。技術職における最も大事なことはこの本に全て書いてある。この超絶プリティーなロリ系エンジニアが教えてくれる。私のブログ記事なんかよりよっぽど心に響くことだろう。いうわけで、本記事のまとめ。追記系を主に内容改定、下記に追記しました。便利な物は使えばいいじゃん!という方へというか、単純に「未だRailsやCakeは生成のコードを知らなくて良いほどにブラックボックス化されていない」というだけの話ではないかなとおもう。http://b.hatena.ne.jp/kent013/20130724#bookmark-155298822「やれやれ、またアセンブラからやってこいみたいな話かよ」と、この記事を読んで思われた方には、こちらの方のはてブコメントがお役に立つかと思いますので、引用、記載させて頂きました。Railsは便利だから使う、といって使えるほど、ブラックボックス化が十分でなく、中身を知らずに扱えるものではない、というのが私の私感です。Railsを入門書で頑張って覚えても、正しく使えません。覚えた内容の大半はきっと1年以上使うことがない知識となるでしょう。Railsを始めたいという方へRailsを使って正しくアプリを作ってみたいということであれば、Ruby+Railsについてガッチリ学べる系の書籍をお勧めします。6)また、ざっとRailsを知りたいだけならこういった入門書も最近出ました。Rails本当に読んで理解しようとすると1ヶ月はまるまるかかりそうです。ウェブサービスを作ってみたいという方へ兎に角ウェブサイトを作ってみたい!という人であれば、ここらへんをおすすめしたいです。はじめるPHP~ワクワク・ドキドキの入門教室~↑めちゃくちゃ内容は浅いので、これでプログラマーになれるか?と言われると、なれません。ウェブサイトを作ったりする楽しさは学べます。Railsを勉強してます」が数ヶ月続いちゃったり、1年間やってみたけど何が身についたか分からなかったり、そんなプログラミング初心者の方向けに「もう少し、必要性を感じながら、少しずつ勉強して、Railsを使う必要があると感じたら使ったほうがいいよ」と伝えたいと思い書いたのものです。「いきなりRailsなんてやっても身につかないよ」だと通じない事が多かったので、「Rails使うな!」って趣旨になってます。記事全体のテイストは過激気味に書いてますが、書いてから一晩明けて見直すと過激気味ですね。一部誤字脱字や不適切な内容を校正致しました。Railsから始めるのではなくて、もっと軽量なウェブ言語から始めるのが、きっと楽しくて挫折しないと思います。Railsに関する私感Railsは本当に良いFrameworkです。OSSのパワーを使えば、生PHPで3ヶ月掛かるコードも、1週間で実装出来そうな勢いです。プログラミングやウェブに関する知識をある程度持っている人なら、今後のFramework選定の際の候補の大筆頭に加えていただきたいと思います。※追記がめちゃくちゃ長くなっていたので、2014年4月末に修正を行いました。AM“今すぐ辞めて欲しい”に嘘偽りはないです。いますぐ辞めて欲しいです。ターゲットはプログラミング初心者のかたです。RailsやCakePHPの各種機能・ルールは内包する機能や習慣が非常に多いため、学習コストが高く、大抵の場合身につかないと思います。(CakePHPとCodeigniterが比較される程にCodeigniterが流行っているのは学習コストの低さの所以でしょう)せめて1回ぐらいはピュアな言語で書いてから、Frameworkが提供している機能たちがいかに有用であるか感じながら、Railsを勉強して欲しいです。“辞めて欲しい”は”2度と帰ってくるな”みたいな意味ではないです。”得策ではないよ”という意味で書いたつもりです。PM読者のために書いた文章ではなく、自分のために書いた文章のように感じます。メモ帳に書いてみてはどうでしょうか。PM私が書きたいことを書くのが私のブログです。(“version”);では、これらは、実際さらに内部でどの様な事を行っているのでしょう?機能的な意味でなく、コード的な意味で。各行がどの様な事を行うものだ、ということが分かっていれば、それはRailsを使わないで書く場合でも同じことだと思うのですが。「背伸び」になると思いますが。datetime型が何であるかは知っていますが、内部処理までは私は把握していません。把握する必要も今までほとんど感じたことがありません。PHPは高効率を目的としたFrameworkです。基本的には背伸び、分からないことが多少は含まれたコードを書くことになると、私も思います。この記事を書いた際のターゲットは「必死にRailsを勉強してみているけど身につかない」みたいな人です。どんな技術もそうですが、自分が必要だと感じないと、覚えることは出来ないと思うんです。DBのマイグレーションとか、CIのためのUnitTestやCIのために設計された各種の機能とか、そういうのを「初めてプログラミングを始める人」が覚えようとするのは、すごく時間がもったいないと思うんです。記事の内容は「わからないこと書くな!」となってますが、それは「CakePHP」や「Rails」が流行りだから勉強している人を止めたいがための記載方法のひとつです。周りの人に「Railsを初めからやっても身につかない」という旨を必死に伝えているつもりだったのですが、どうしてもみんなRailsやりたい、みたいな雰囲気になってしまう方が多かったので、伝え方がまずいのかなと思い、こんなタイトルになってます。高級言語全般そうでんがな。いい始めるなら、全部アセンブラで書いてつかあさい。AM根本的に言うとおっしゃるとおりです。私は言語については言及していません。Kitなどに関しても言及していません。あとはHTML等などしか基本は使いませんが、全て高級言語です。アセンブラで書くことは私には出来ません。FrameworkのコミッターよりRuby言語のコミッターの方が、深いかとは思いますので、尊敬します。Frameworkのコミッター、ライブラリのコミッターにも尊敬します。RailsやCakePHPはプログラミング言語ではなく、Ruby言語やPHP言語で動作するサーバーソフトウェアの機能の内再利用する機会の多い各種の機能をルール化、コンポーネント化したFrameworkです。どちらも同じ言語で書かれています。「Rubyじゃなくてアセンブラで書きましょう」ではないのです。Railsを勉強してます」が数ヶ月続いちゃったり、1年間やってみたけど何が身についたか分からなかったり、そんな人向けに「もう少し、必要性を感じながら、少しずつ勉強して、Railsを使う必要があると感じたら使ったほうがいいよ」と伝えたいと思い書いたのものです。AM言いたいことはわかるけど、このブログ、誤字脱字が多すぎる。いう所をきちんとしないと何においても説得力にかけてくるかと。AM夜中のぼけーっとした頭で書いたので、申し訳ないです。AM程度問題でしょう。タクシーの運転手が自動車をつくるのに必要な機械工学や高等数学を勉強する必要があるかというとそんなことはないですし。AM程度問題だと私も思います。Frameworkは必要だと感じた、再利用すると感じた機能の詰め合わせを最適化したものですから、それらの機能それぞれのありがたみ、機能の中身などを知らないと、怖いなー、というのを記事としては主体で書いていますす。Railsを勉強してます」が数ヶ月続いちゃったり、1年間やってみたけど何が身についたか分からなかったり、そんな人向けに「もう少し、必要性を感じながら、少しずつ勉強して、Railsを使う必要があると感じたら使ったほうがいいよ」と伝えたいと思い書いたのものです。RailsやCakePHPは覚えることが多すぎる(逆に、不まじめにやるといみわからず書いた行が多すぎて動かない)Frameworkですから。PMタクシーの運ちゃんの場合は、車がおかしい時には金を払って車を修理工場に持ち込めば、それなりの値段で直してもらえますが、一旦開発終了して運用開始したプロダクトを「なんかおかしいから直して」と言って見積もりを取ったらすごいことになりそうです。それならば最初からコンサルに入ってもらって、保守運用まで出来る開発会社に作ってもらったほうがいい気がします。いうわけで、私はblog主の主張に賛成です。AM理解が浅いと使ってはいけないってことですか?テレビの仕組みを知らなければ見てはいけないと思いますか?DRAMの記憶の仕組みを知らないとPCを使ってはいけないと思いますか?どうもいまいち何がダメで何がよいのか整理できていないのではないでしょうか。AMFrameworkはDBとかTCP/IPとかとは次元が違うと思います。(まぁ層が違うので当たり前ですが)。普段書いているコードを、よりよく書こう、再利用しようというのがFrameworkの趣旨かと思います。趣旨の前提を理解しないままにFrameworkを学習したって身につかないだろう、徒労に終わるだろうと思っているし、普段から伝えようと努めているが、なかなか伝えらることが出来ないから、使うな!と頭ごなしに書いてみた、といった感じです。「理解が浅いと使ってはいけない」わけではないですが、「理解が浅いと使ってはいけない」と伝えたほうがプログラミング初心者にとっては有用な結果になるだろうと思い、理解が浅いと使ってはいけないと書きました。フレームワークを使ってなにかを作るとき、出来合いのものは割合簡単に作れますがそれなりに凝ったことをしようとするとき要所要所で内部まで分かってないとどうにもならないことが多々あります。エンティティで多対多の関係となるデータを取り出す際にフレームワーク側からどう呼び出すとどのようなSQLが生成されてそのパフォーマンスはいかほどのものかということまで頭が回らなければよいコードは書けないと思います。SQL生成やjavascriptの扱いなどはフレームワーク以前にきちんと学んでおかなければセキュリティの問題が発生します。フレームワーク側が勝手にやってくれているはずと思ったりそもそも意識していないということであれば大きな問題です。アセンブラまで知らないと駄目じゃんという批判がありますが的外れかと思います。別に全知であれということではなく、書いたコードがどのように動作するのかを「十分」に知っておくべきだという話でしょう。Webアプリを作るにあたってフレームワークの知識だけあれば十分だという人はまずいないでしょう。単純にそういう話かと思います。フレームワークなどの仕様は朝令暮改のように移り変わりますので若い人は勉強の重心をもっと低レイヤーにおいてちゃんと根の張った実力をつけていくことが肝要かと老婆心ながら思います。AM大いに同意します。Frameworkから覚えても覚えられないし、覚えてる間にすぐ変わるし、それならFrameworkの前提から勉強したほうが良いと思います。AM書いてることに同意。「プログラミング修得」目的なら、フレームワーク使うべきじゃない。本来習得すべきことのほとんどをフレームワークがやってしまうから、上物を組み合わせて物を作れる人にはなれても、フレームワークで解決できないと「できません」「無理です」と答える人になってしまう。WEBデザインを仕事にしてる人や、知識のある人が、必要で学ぶならともかく、「プログラミング修得」が目的なら論外。「僕は違う」という御仁もいようが、そういう「自分はできる」と言う人が、資質のない可能性がある人に「出来るよ」と言うのが一番たち悪いと感じている。こないだ後輩が[jQuery]使ってコード書いてたけど、ライブラリのバージョン管理や動作確認どうすんの?アップデート時、それの動作保証ってうちはどの程度できる?とか聞くと尻つぼみになる。電子だのアセンブラだのの話と違って、流行りのフレームワークは、そういう事に気を配らんといけないナマモノなんだって意識も無さすぎる。AM大いに同意します。何かを作る目的なら、「Sinatra」や「Codeigniter」、「Slim3」などの学習コストの低い(それこそ書籍にするまでもないような)Frameworkが個人的にはオススメです。一人で出来た!」くらいの御仁なら、1)。「関数やら変数やら組み合わせて、機能の作り込みが一人で出来た!」くらいの御仁なら、2)。「あれこれ機能を組み合わせて、アプリを一人で作れた!」に為った御仁なら、3)。自分の経験からそんな印象を受けました。PMこないだ後輩が[jQuery]使ってコード書いてたけど、ライブラリのバージョン管理や動作確認どうすんの?アップデート時、それの動作保証ってうちはどの程度できる?とか聞くと尻つぼみになる。会社がきちんとコーディングポリシーを周知させるべきですね。PMベスト・プラクティスはやはり無いかとは思います。私が思う私の会社のポリシーは「何かを作ってから必要性を学んでからFrameworkね」です。客先のポリシーなどで、「使えない」と判断された時に、コードかけるのか?と言う話です。フレームワークに依存するの、怖いですよ。AMフレームワークつかうなって無理でしょ。そもそも訊いてきた人は周りの営業やらからつかえるようにしとけ案件それつかってるのおおいしぐらいの調子でやっているだけでしょ。フレームワークの中身のコードを理解しろとか、ベタで書けるようになれならまだしも、つかうなはおかしい。AMFrameworkは使うべきです。プログラマーにとって効率化は非常に重要なことです。使うなとは私は一言も言ってないのです。「プログラミング初心者のかたが最初に学習するにしては学習に要する時間が多すぎる」ただそれだけです。AMとても納得しました。賛同意見としてコメントさせて下さい。「すべて理解しないと使っちゃダメなのか。その他のコンピュータの要素技術では抽象化の目的が異なるということが前提ですね。コンピュータの要素が抽象化されているのは、それを細かく意識せずに使えるようにするためで、フレームワークでは「効率化」のための抽象化であり、結果を意識する必要があるということですよね。結果を意識する必要があるというのも語弊があり、フレームワークとピュア言語そのものは「同じステージ・立場」にあるものですから、要素技術を理解する必要があるのは当たり前ということになります。私も初心者のかたには、フレームワークは「知らなくてもできるようになる」ではなく「手数を減らす」ためのものとして見て貰いたいと思いました。AMはい、おっしゃるとおりです。『「手数を減らす」ためのものである』と認識するために、まずは「手数」の方を覚えるのが、プログラミング初心者の方には適切かと思います。AMOKそれで、僕はこのあと何をすればいいんでしょうか!とりあえず、初めてのRubyはやりました。面白いですね、Ruby。僕はまともにWebサービスとかは作ったことがないけれど、何か作ってみたいな、という感じです。皆がRailsが良いというのでRailsの本でも借りてやってみようかなぁと思っていたのだけれど、sumyappさんは「ピュアなものからやったほうがいい」と思ってこのブログの記事を書いたみたいなので、一体どうしたらいいのかなぁと思っているところです。よろしければ、どんな感じで進めていけばいいのか、参考程度に教えてもらえると助かります。何かを作った上で、効率化する必要を感じ、Frameworkを学ぶこの流れが良いと思います。Railsは学習コストが高すぎるので、私は、初めての方には、「Sinatra」をオススメしています。作りかけのサイトで申し訳ないのですが、もし参考になれば幸いです。肝心の代替案が電撃文庫に丸投げというのはいかがなものか。AM代替案は記事に追記しましたとおり、「Railsが自動生成するRubyコード群をRuby言語等のピュアコードで作れるようになってから学ぶべきだ」です。実は、まだ公開できる状態でないので、公に告知していなくて、この記事に書くのもためらわれたのですが、下記のようなサイト・カリキュラムを今作っているところです。こちらではSinatraを使っています。Railsを使うコースも追加する予定ですが、Sinatraでアプリを一本作ってから、色々な必要性(SQLをなんで何回も書かなきゃいけないんだ!とか)を感じてから、RoR使いましょうという流れの予定です。AMいえ、プログラミング言語を勉強するのは良いことだと思います。ピュアコードである程度プログラミングを書いた後Frameworkの必要性を感じてFrameworkの勉強をするのも良いと思います。はオススメ出来ないと個人的には思いますというだけです。AM記事内容同意です。tableの中身は?とかテレビの中身は?とか、すぐ極論で全部一緒にしちゃう方はやっぱり必ずいらっしゃいますね。「アルコールを1日に10リットルとったら致死量だ。アルコールは毒、一滴もとってはならない」みたいなこと言う人ね(苦笑)っていうかこの文章に同意できない人ってどんなレベルのコーダーなんだろう。AM今回の記事はターゲットでない人にも多く御覧頂いたので、結構、カオスになってしまっています。全部(コメント含め)読まないと理解して頂けない内容かと思います。ターゲットの明示など、今後気をつけます。AM記事内容、ebdさんのコメントに完全に同意です。耳に痛くて必死に反論してるような人が多すぎて...。結果プログラミング言語を学ぶ出来る人はこっちです。勉強が必要なのであれば、あなたは凡才で今後も何も生み出さない工場のラインです。PM勝手に他の方のメールアドレス、ドメインを使うのは控えましょう。コメント記載時に入力頂いたメールアドレスがYahoo!の全社メールのアドレスだったらどうするんですか?何かを作る過程で技術は必要です。勉強しない人は技術者ではありません。PM主張に反対はしませんが、いきなりCakePHPでもいいと思いますよ。実際にプログラミングする時には、結局、SQLとか基本を学ぶ必要が出てくるはずです。フレームワークを使った方がセキュリティ的にも失敗が防げる場面も多いし。理屈より実践で経験の方が大切だと個人的には思っています。PM私も実践で経験の方が大切だと個人的には思っています。CakePHPでも良いと思います。PHP->サービス作る->Codeigniter->CakePHPみたいに、段階を踏んでも良いのではないかと思っています。結局、SQLなどを知らないとCakePHPも触れませんからね。どれもツール・技術でしかないので、何かを作りながら学ぶのが重要だと私も思います。CakePHPの入門書だけやっても何の意味もないよ、っていう気持ちは記事に込めたつもりです。PM全然コーダーじゃない僕が漂流してきて読んだのですが、いきなりRubyOnRails使ってプログラミングできた気になってるっていうのは僕みたいな学生がGoogle翻訳に突っ込んでできた英文をまるまるコピペしてインターナショナルな俺に浸ってるのと同じくらい危ないよって理解でいいですかね?確かにすげー早く生成してくれるから自分で一から作るより便利だけど、お前それ書いてあることわかってなかったらトンデモなもの世間に流すことになるぞ!って警告ですよね。PM頂いたような内容で記載しました。Rails使うためにscaffoldとかdb:migrateとかrails特有の沢山のルールを覚える必要は全然なくって、むしろ覚えるのに時間ばっかり掛かって、本質が全然身につかないだろうから、もっと軽量なFrameworkか、ピュアなコードから始めたらよいのではないのでしょうか?ということです。英語に例えると、英語の勉強目的なら、文法から始めたら?長文作文からではなくって、そのほうがいいと思うよ、といった感じです。Railsを使ったら、どんな危険や脅威、脆弱性があるのか、全部教えてほしい。ライブラリ関連もあわせて全部教えてもらえるとずいぶん助かる。PM文量が多くなってしまうかと思いますので、お手数ですが、こちらを全部ご覧頂ければと思います。https://github.com/rails/railsもしよろしければ、MacかLinuxの方でしたら、「Terminal」というアプリを起動して、こちらのコマンドにて、一般的に、知らないコマンドを叩くとどうなるか体感できるかと思います。PM公開されてるソースを読めってことだということは分かります。Railsベースのサイトはできてしまいます。要するにあなたが危惧する状況は「いとも簡単にできてしまう」というわけです。問題の本質が「今すぐ辞めてほしい」というのは、初めてWebアプリケーションを構築しようとしている入門者に教え説く言葉ではない気がします。Railsを使ったら、どんな危険や脅威、脆弱性があるのか、全部教えてほしい。ライブラリ関連もあわせて全部教えてもらえるとずいぶん助かる。これは本当に無理です。おっしゃるとおり、危惧する状況はいとも簡単に出来てしまいます。それが問題になるサイトはそれほど多くはありません。作ったサービスが爆発的に流行ってセキュリティクラックされるなどは起こる確率は低いからです。私はセキュリティ上の課題を提起して「今すぐ辞めてほしい」と書いたわけではありません。「Railsの勉強から入るなんてイバラの道すぎるから今すぐ引き返して、急がば回れして欲しい」のです。PM随分と苦労されたんですね、お察しします。Railsが前評判のように敷居が低くなかったのでしょう、例えばDBと親和性が高すぎるとか。学ぶということに制限をかけるということは、何かを否定するような気がするんです。守破離、この手順で地道にやって行きましょうよ。PM私もFrameworkから学ぶことを否定するわけではないです。RailsやCakePHPの選択は非常に厳しい、心が折れるだろうと思う故のタイトルです。Railsなんて3.0以降書籍も出ていませんし、専門学校や短大などで教えてくれるわけもないスキルです。Rails4のインストールだけで多くの入門者の方は心が折れると思います。DBって何?って状態の時にActiveRecordやDBMigrationの概念は理解できないと思います。一般的な人はおそらく高効率・学習コストが高いFrameworkから学ぶのは無理だろう、と思いますので、これらを否定しています。SinatraやCodeigniterなどは個人的には特にオススメします。学習コストが低いので、楽しみながらサービスを作れると思います。これらも一応Frameworkです。CakeとRoRはやめとけよ!って感じです。PMこの記事のタイトルみてなんじゃこらと思ったけど、、。Railsも1,2くらいまでは比較的コンパクトでよかったけど、3くらいから余計なものが増えてきて面倒な感じがするのは同意ですね。ご指摘にあるように、フレームワークは開発効率を上げるためのものであって、学習とかスキル向上のためのものではないですからね。Railsももともとはシンプルだったので、フレームワークで生成されたソースを見てみたり、フレームワーク自身の実装を見てみることで学習効果も兼ねていたけれど、バージョンが上がるとともにブラックボックス化された部分が増えて、使うだけの感が増えたような。(=>フレームワークを使うだけで間に合う間はいいけど、それで解決出来なくなったときのフォローのハードルが急に高くなってしまう)そういう意味では、エンジニアのスキル向上とかプログラミング学習を目的にしたフレームワークみたいなのがあってもいい気がしますね。PMRails2までは一般的な内容だけにとどまっていたかと思うんですけどね。Ajaxとかも別に強制はされなかったですし。2では標準だったgemが3では外れたり、標準でturbolinks入ってきたり、javascriptじゃなくてcoffeeスクリプトが標準だったり。「プログラミングはじめよう!」→「Rails流行ってるよね、Railsってのにしよう」っていうのはほんとに暴挙(Javascriptとcoffeeスクリプト、ormとsql、覚えるものが多すぎる)って思います。学習用では、やはり軽量系Frameworkが良いと思います。学習用とはいえ実用に耐えないと意味が無いと思いますので。余談ですが、パーフェクトPHPという書籍は、「Frameworkを作ろう」みたいな章もあって、「パーフェクト」だなと感じます。学習用のFrameworkは自分でFrameworkを作ってみるのが一番勉強にはなるのかもしれません。PM好意的に見れば、「SQL知らないくせにORM使うな」のような趣旨にも受け取れますが、「Railsはデブで機能の入れ替わりが早くて嫌いだ」といった文脈もあり、論点ブレてませんか?これだと、結局、ただのアンチRailsと2次オタク本推薦の記事に感じちゃいます。PMSQL知らないのにORM使おうとして、当然使えないから、ORM覚えてSQL覚えてって大変だから、一旦SQLだけ覚えるFrameworkでよくないですか?何もRailsみたいな学習コストの高いFrameworkから入らなくても。PMRailsはでっかくて、機能の入れ替わりも早いので、入門書なども追いつかず、プログラミング初心者のかたがいきなり取り組むにはとっつきにくすぎるFrameworkだと思います、という趣旨です。Railsは非常に有用です。Ruby系のプログラマならほぼRails一択でしょう。PHPに関しても、CakePHPはCodeigniterより非常に生産性が高いです。オライリー本をおすすめしても良いのでしょうが、知らない内容を打つなということを最もとっつきやすく伝えているのは先の書籍だと思ったので紹介させて頂いたまでです。ライトノベルは「ライト」であることが特徴です。とっつきやすい、分かりやすいのは良いことではないでしょうか?分かりやすい本を推薦するのは、分かりづらい本を推薦するのと比べ、良いことだと思います。本ブログ記事のターゲットは「プログラミング初心者の方」です。ターゲットを限定して、アンチRailsしています。Railsは非常におすすめできる最高のFrameworkです。Programming」出来る素晴らしいプログラミング言語です。PMうむ、最初に思ったとおりだった。「数学勉強しています」に対して「いますぐやめてほしい」って言うかね?最初に算数勉強するべきだからね。この記事に従えばやめるべきってことになるんだろうね。この記事には、重要なことがかけてる。誰を対象にしているかだ。自分のようにプログラム言語とフレームワークをちゃんと理解している人が「勉強してます」といって「いますぐやめてほしい」とは言えないはずだ。ようはプロ用の道具を使う前に、基礎をしっかりやっておけと言ってるだけ。それは「プロ用の道具を使うな」には結びつかない。フレームワークは早く作れるが、理解するのは簡単ではないというのは当たり前アーキテクチャを知らなければ、ベストプラクティスなんかわからない。そんなことは知ってる。アーキテクチャを知らなければ、正しいフレームワークの使い方はできない。フレームワークとアーキテクチャを勉強するために題材として既存のフレームワークを勉強するのは効率のいい勉強方法だ。学習コスト高いから勉強したくない。PM「プログラミングの修得の相談」を私にしてくれる方、つまり、”プログラミング”に関する初心者の方をターゲットにしています。プログラミング習得済み、Framework使用経験有り、の方をターゲットとした記事ではありません。非ターゲットの方向けのまとめとしては、まとめて頂いたとおりです。ありがとうございます。学習コスト高いから勉強したくない。初心者の知識だけで開発しようぜ・・・NGこちらは個人的にはOKです。勉強はしたほうが良いかとは思いますが。個人情報を扱うサービスに関しては初心者の知識だけは危険かもしれません。フレームワークとアーキテクチャを勉強するために題材として既存のフレームワークを勉強するのは効率のいい勉強方法だ。フレームワークを使わずに、つまり実践せずに勉強だけで理解しろなんて無理これについては私も各種のコメントで同意しています。RailsやCakePHPなどの学習コストが高い物は避けたほうがいいのではないか、と伝えさせていただいているつもりです。タイトルに有る通り、フレームワークは否定していません。初心者のかたが最初に取り組むプログラミング教材として「Rails」や「CakePHP」は重すぎると伝えているに過ぎません。プログラミングの初心者の方にはこの学習の流れが私はオススメだと思います。何か作る(もちろん、Frameworkは使っても構わない。PM嫌な見方をしないで、きちんと言いたいことを理解しようとすれば、ちょっとつまずいた時に、その先を調べ様としない(もしくは調べ方が分からない)様な人はいきなり出来上がったものを使うのではなく、その基礎からまず、調べ方等から学びなさい、ということだと思います。それがこの記事で言いたいことの全てだと思います。CREATE...という部分は中身を知らなくてもOK、と書いている様に見えるのが、えっ?と言われる部分だと思います。Ruby言語での脆弱性については?と聞かれてソースコードを出されても誰も納得しないでしょう。フレームワークとは言え、規則に従って構築するとそれを解釈して実行してくれる、という部分に関してはプログラム言語と全く一緒です。実際に機械が実行するまでにいくつラッパーがかかっているかどうか、だけの違い。Rails自体の信頼性を疑っているのではなく、Railsの仕様を詳しく調べて行けば結局Rubyのコードに行き着くのだから最初にRubyを学びなさい、ということだと思います。これはどんなレベルの言語でも言えることだと思いますが。後は、ドキュメントの充実度、でしょうね。ドキュメントが充分あって、脆弱性も充分理解できるようであれば、フレームワーク部分だけでも充分安全に使えるわけで。頻繁に仕様が全面的に変わるので学習コストが高い、ということはよく分かりますが。要するに、言いたかったことは、詰まった時に自分で調べる様な事が出来ない人間が流行りもんに食いついて勉強してます、とか言うな、ということでしょう?かといって、そういう人達は、別にRubyやPythonから始めたとしても結局途中で自分で解決策を見つける事が出来ず力尽きるので同じことだと思いますので根本的な教育が必要なんだと思いますが。AMこの記事は結構混沌としていて、申し訳ないです。結論は「Railsは初心者は使うな!」ですが、目的は「それは遠回りだから基礎からやったほうがいいよ」で、色々な立場・スキルの方ご覧になるので、カオスなコメント欄になってしまったのかと思います。すべての人に真面目にコメントを返信しています。伝えたいことが伝わるように。