規約が生まれた理由を感じながら、規約を自分のアプリに当てはめていこうよ、Frameworkに乗り換えていこうよ、Frameworkを作っていこうよ、それがきっと近道だよって事が私は伝えたいのだと思います。基礎からやらせようとすると、みんな「高効率で最新!」の方に行っちゃうので、どうして求められなくて。「高効率で最新を使うな!」という以外に方法が思い浮かばなかったのです。DBはPaaSなども出てきていますし、結構十分枯れていますし、sqlite3がどういったものなのかなど理解していなくても使える機会が多いです。Railsはまだそうじゃないよねってだけです。MySQLを根本的に理解しようと思えばすごく深い知識が必要ですが、RailsはRubyで書かれていますから、Railsエンジニアなら読めるし、Rubyエンジニアなら書けると思うんです。DBについては中身を(少なくても初心者のうちは)知らなくても大丈夫だろうと。Railsは中身を知れるし、知る必要があるだろうと。RailsのgithubレポジトリのURLを貼ったのは、「ちょー知りたい」とコメントされていたので、ただの冷やかしコメントかと思ったため、その上で「超知りたいならコード読んでみたら?」っていう雑なコメントをしただけです。役に立たないコメントで申し訳ございません。Rubyでも、PHPでも、Obj-Cでも、Javaでも、言語は何でもいいんです。Frameworkもなんでもいいんです。「まずは動くところから」「動いたらわからない所・改善したいところが見えてくる」「改善する」「改善していく上で、Frameworkの有用性がわかってくる、使いたくなってくる、選定する」「使う」そういう流れが正しい、楽しいと思うんです。「高効率なFramework勉強するぜ!プロのエンジニア目指すぜ!」のノリだとモチベーションが普通の人は続かないと思うんです。「Rails覚えとけ、それができなきゃPGは向いてない」とかそんなことを言いたいわけではなくて、むしろ、みんなには言ってほしくなくて。「基礎を分かってからじゃないとFrameworkなんて使うな」と言いたいわけでもなくて、Railsみたいな高効率なFrameworkの勉強から始めてうまくいく人なんてほとんどいない、みんな挫折する、だからステップ・バイ・ステップでやりましょう、楽しく作りながら、ちょっとずつ基礎を覚えていきつつ、効率化していきましょうと。記事・コメントを読んでくれていない人がほとんどなので、その点はプログラマーとしてはとても残念です。プログラマーじゃないかたの時間を大いに奪ってしまったことでしょう。スタートアップ界隈だと「Rails流行ってるからうちはRailsね、覚えてね」みたいなノリのところも多く、そういうのは将来のエンジニアになれる可能性を摘み取るような行為に私は思うから辞めてほしいなって、もっと親切にしてもいいんじゃないかなって思うんです。出来上がってないんですが、私の会社では今は下記のサイトをコア事業にしています。SinatraやCodeigniterを使ったカリキュラムです。RailsやCakePHPも使うカリキュラムにする予定です。改善していくそんな流れを組むことで、きちんと成長できるカリキュラム・サービスを育てて行きたいのです。それがこの記事の思いです。Katzがむかし言っとりました)。CSRFのこと知らなくてもデフォルトで妥当なCSRF対策が入っているのはそのため。現状のRailsは技術の詳細を知らないとハマることが往々にしてある(つまり目標が達成されているとは言い難い)ので、技術の仕組みを勉強しましょうという本文の主張には賛同するのですが、Railsの目指している方向は真反対というのは知っておいたほうがいいかなと思いました。言うのはなかなか意味深ですね。AM「技術の詳細を知らない人でもアプリが作れるようにする」これはまだまだ時間がかかると思います。最近はRailsはどんどんおっきく、最先端の技術をどんどん取り組んでいますし。「技術の詳細を知らない人でもアプリが作れるようにする」からは遠ざかっていっているように思います。Cで書くよりはだいぶ「技術の詳細を知らない人でもアプリが作れる」とは思いますが。しても、RailsもORM使ってたり、Wrapper的な部分があるので、まだ数年は厳しいのではないかと思います。PhoneGapやTitaniumMobileなんかはもっと厳しいと思います。いつかは、「技術の詳細を知らない人でもアプリが作れるようにする」時代が来ればいいですし、作って行きたいですね。余談ですが、「辞めて」と「止めて」に私はあまり差は感じませんし、私の会社はまだ役員しかいないので、辞めさせる相手もいないわけですし、辞めさせたい人がいるわけではないです。初心者歓迎で積極採用中です。採用には莫大なコストが掛かりますから、よっぽど双方のためにならない状況にならない限り、今すぐ会社を辞めて欲しい、ということは無いと思います。弊社は資本金が多くないベンチャー企業なので、やむを得ない場合もありますが、精一杯頑張っているつもりです。AM返信にも書きましたが、私はblog主の言いたいことに概ね同意ですね。いうのも、RailsやCakePHPなどのFrameworkが、なにも知らずに使い始めて、そのまま使い続けながら内部構造を学習していくようなモノになっていないことに起因していると思います。初心者でもそこそこのモノが作れるというのがウリかもしれませんが、それはウリ文句であって、実際のところはフルスクラッチで作っていた人が「うわっ!超楽じゃん!」って狂喜乱舞するためのものなんじゃないかなという気がします。Response)、PHP、JavaScript(CoffeeScript)、jQuery・UI、SQLite、CSS3を理解していないと使えないものになっています。AMフルスクラッチで作っていた人が「うわっ!超楽じゃん!」って狂喜乱舞するためのものなんじゃないかなという気がします。今のFrameworkはプログラミングやWEBの基礎を知ってないと使えるレベルにないです。完全にブラックボックス化は出来ていないです。「DRY」とか「KISS」とか、そういう哲学は、経験の積み重ねから「悟りが開ける」ことによって、身につく、Frameworkになるんじゃないかと思います。AMとても同意します。素のSQLでDBアクセスする処理を書いていると、バインド変数への値の設定とか、結果セットの値をオブジェクトにセットする処理とかが冗長で面倒になって、自作のORマッパーを作って効率化してみたりしたけど、動的SQLの作成とかオブジェクトをメモリ上にキャッシュするのとかをやろうとすると結構大変だなーっていう経験をすることでフレームワークのありがたみが分かるのかなと思います。フレームワークからは入らない方がいいと思います。(会社に入ってからプログラミングを学ぶと、即戦力養成ということで学習の初期段階でフレームワークを覚えさせるところもあるようですね。Webアプリ編という本でテンプレートエンジンやバリデータやORマッパーを全て自作しているのを見て、入門書としていいアプローチだなと思いました。PMとても興味深い内容でした。私自身まだ経験が浅いのですが、初心者もどこかのタイミングでフレームワークに触れることでメリットもあるんじゃないかと思います。稚拙な文書ですがブログを書きましたので、リンクを貼っておきます。PM非常に同意できるご意見だと今Railsを学習している人間として思いました。Railsを使って作るようなアプリケーション、例えば、ブログや掲示板などをRubyのピュアコードで書いてみたいと思うのですが、Railsを使ってのチュートリアルはあっても、Railsを使わずにブログを作るチュートリアルはないように思います。恐縮ですが、初学者が参考にできるRubyのピュアコードで作るアプリケーションのチュートリアルや書籍、Webサイトなどにおこころあたりはないでしょうか?もちろんコメント欄でご紹介されているスタディテックのサイトも参考にさせていただきます。AMこちらが参考になれば幸いです。AM現代のIT産業はどんどん抽象化している訳で、それはナレッジが蓄積された結果に他ならないのだから、人類の進化と捉えるべきでは。熟練プログラマほど若手が安易にフレームワークに手を出すことはイカンと言うけれど、パンチカードでプログラミングしていた諸先輩方も同じことをボヤいていたはず。FrameworkやCocoaが使えて、Web環境ではMVCフレームワークがあるおかげでデータベースの差異やお決まりの冗長コードを吸収し、i18nや各国のタイムゾーンまで面倒を見てくれて、さらには見知らぬ国のサマータイムまで考慮してくれる。こんなの日本人だけじゃ作れないでしょ。いうわけでアイデアを超速で具現化できる、最高な時代だと思いますけどね。バカは増えるけど、バカは避けるか利用しろ、というのが古今東西のお約束。Framework」は、あれもう「Windows」と同義です、それを「Rails」などの環境と比較するのは、なにか違う気がしますね。修正・拡張されてるような環境では、自分がやっていることや利用目的がなんなのか、自分で把握できてないと、混乱するのは自分なんですよ。・ツールのバージョンが上がりました・仕様変更を行いましたが、セキュリティホールも閉じましたなんてな話をどう考えるかで、変更された時に、利用側がどう対応すべきか(または対応が必要ないのか)知らないといけません。Framework」レベルでOS添付品のように標準化されたのなら、学ぶべきだと思います。Frameworkかどうかではなくて・その技術がどの程度まで安定化と標準化が行われているか・どういう形で互換性テストが行われているか・それを技術者が意識する必要があるかそういう部分が大事で、開発速度が速い環境ほど、古い情報もネットに混在し、学ぶ方が混乱します。した情報を取捨選択する知識がないと、ただ切り貼りで作るだけの人になってしまうかもしれません。PMはじめましてタイトルみて「何事だ?」と思い拝見しましたが、おおむね同意です。私はあまりFrameworkは使わない(使えない)のですが、JavaやPHPの充実したライブラリ群を利用しているだけでも「こんなに楽で良いのだろうか?」と思っていたのです。(Rubyは使ってないのでわかりませんが、似たようなものでしょうか?)「おおむね」と書いてある点については、Frameworkで自動生成されたコードを見て勉強の足掛かりにすることはできるのではないかなと個人的には考えているからです。学習系のサイトではエラー処理を省いたサンプルコードを乗せているものを見かけたりします。「どのような処理を入れるべきだろう?」と思った時にFrameworkの自動生成コードは優秀なサンプルコードになりえるのではないか?という意見です。AMふらっと訪れました。最初触れることは、なるべく楽をしないものからという考え方でやってます。簡単に原因が他のレイヤー(?)の問題として認識して欲しくないとは思います。RoRで、できない(または遅いなど)といって、”Rubyではできないこと”とか”DBMSではできないこと”という誤った認識を持って欲しくない。書く必要があるC言語はクズ」そんな感じです。現象を正確に述べれないと、問題に対処出来ませんからね。PM終わった話題ですが、最後までコメントを読むような人に向けて、コメントを残します。私はCakePHPでPHPを勉強しようとして苦労しました。結果として、このエントリーには賛同です。私がCakePHPを最初に勉強しようと思ったのは、伸びそうなフレームワークだったからです。当時は1.1ぐらいだった気がします。他の言語の経験はありましたが、ウェブは初めてでした。フレームワークを使うことで素で書くよりはセキュリティで堅牢なコードが書けるだろうと考えました。PHP自体の学習をしたくないわけではなく、その時頼んでいた外部パートナーが品質が悪く途中で逃げたので、納期に間に合わせるには自分でやるしかなかったからでした。工数がアホみたいにかさみ、納期には間に合いませんでした。それは、不具合が起きたときにPHP(もしくはサーバ)に原因があるのか、CakePHPに原因があるのか特定することができなかったからです。言い換えると、処理がCakePHPがやっているのか、PHPがやっているのかが分からない。これは初学者にとっては完全にブラックボックスです。アセンブラからやれってのか?っていうのは、改めて違うと言い切ります。僕なりに例えると「告白はラブレターでやるな」ですw手紙にすると相手の反応が分からず、本心が読めません。告白の文例もあるし、直接言うより楽だけど、あんまりうまくいきません。これはいける、いけないの感覚が養われないと思うのです。123)の「=>」も、「この矢印みたいなのはなんだろう」とずっと悩んでいました。CakePHPのドキュメントを端から端まで読んでも書いてないんです。分かってる人にとっては「アホか」って話です。初学者にとってみれば「これを勉強すればバッチリなんだよね?」と思って取り組むので、結果として遠回りになるって話です。私は「->」や「=>」が何の意味だか分からないけど、とりあえずつなぐ矢印だと思いこんで乗り切り、その後結局(実質)矢印だと分かったのは数ヶ月後でした。私がCakePHPで幾晩も徹夜を重ねて納品した後、手にした本は「Perl→PHPらくらく移行ガイド」(既に絶版)でした。最初はPerlのコードも触ることがあるだろうから、と手にしたのですが、対比する形で、クッキーやファイルの操作、セッションについて、そしてセキュリティまで触れられていたので、この1冊をやってみて、CakePHPで悩んでいたことがかなり氷解しました。基礎技術についてマスタしないと上に進んではいけないというわけではないけれども、自分がやりたいことについて「どういう技術」が必要になるのかを理解し、それは素で書くとどうなるのか、が分かってからの方が楽だと思いました。いうことが網羅されている本を選ぶとよいと思います(使わないような技術が書かれている本は最初は避けてよい)。Rubyで1度でもMySQLを使うようなサービスを作ったor作ろうとしたけどあまりにも面倒で辞めた人は積極的にFWは使うべきだと思います。(もちろん始めて触る言語でfizzbuzzぐらいは書けないといけないですけど)自分はPHPからWeb系に入りましたがセッション管理やSQLの例外処理などとにかくやることが多すぎて一度完成してもセキュリティ的に問題ないのか・・・・?と思ってしまい公開することはありませんでした。それからしばらくしてRubyを軽く触ったあとRailsを触って感動しました。余計なコードを書かず本当に必要な機能だけ書けばいいんですから。そもそもRuby初学者がFWを吐き出すコードを書けるわけ無いでしょう。FWは言うならばRubyを何年も使う上で培われたベストプラクティスにもとづいて書かれているわけで、初学者にベストプラクティスを理解できるまで使うなというならFWの利用者は激減しますよ。初学者はFWを積極的に使いベストプラクティスをどんどん学ぶべきだと思います。その前にMVCを正しく理解していることが前提ですけど。あと学習コストが高いといいますがRoRを理解してしまえば他のFWにも応用やノウハウが効くわけで他言語・FWも学ぶつもりなら学習コストは決して高く無いと思いますよ。PMFrameworkは使ったほうがもちろん良いかと思います。RoRを覚えて他のFrameworkも使えるようになって、というのがいいと思いますし、私もRubyで初めて使って覚えたのはRoRです。そのときは「Ruby言語(言語のみ)」「Objective-C(iPhone)」「PHP言語(NoFramework)」は使用経験がある状態でした。最近はMySQLもRubyもHTMLもCSSもLinuxも知らずに、「Rails流行ってるからRails」って学び始める方を多く見かけます。いった方向けに、「それはダメだよ!!」書いた記事です。ターゲットが明確に記載されていなくて申し訳ないです。HTML,CSS,Ruby,MySQL,Linux(Unix),Railsってやっていくととても学習コストが高いので、HTML,CSS,Ruby,Linux(Unix),Sinatra(軽量Framework),MySQL->Rails、ぐらいでもいいのではないかなと思っている次第です。例で出したActiveRecord(MySQL)などはまだまだブラックボックス化されていないので、結局MySQLも覚えないといけないです。ブラックボックス化されていない部分が多く含まれるRailsよりは、軽量Frameworkがいいんじゃないか?と思っています。MVCを理解していて、LAMP(PHPじゃなくても可)を理解していて、ぐらいであれば、Frameworkを始める良いタイミングかと思います。いえば、軽量Frameworkを間に挟んだほうが、サービスは早く作成・公開出来るのではと思います。PM※ただの感想です。私がまさにいい例です。自分はディレクター業を行っており、業務外でサービスを立ちあげたいと思い、エンジニアに何から始めればいいか尋ねた所、RubyとRails、軽くSQLを勉強しろと言われ1年やってきました。一応CRUD機能をもたせて?管理画面やらタグクラウド、ページネーションなどの機能を持たせたサービスは作れましたが、実際には何がRubyで何がRailsのスクリプトなのか、先ほど記述した「一応CRUD機能をもたせた?」という表現がCRUDを語る上で適切な表現方法なのか、等イマイチよくわかっておりません。Create(生成)、Read(読み取り)、Update(更新)、Delete(削除)ができる機能をもたせたサービスと言いたいのですが。何かエラーが発生した時に頼る人がいればいのでしょうが、結局、本気で一人でサービスを作ろうと思うと深く勉強することになりました。自分の場合はRuby、SQL、HTML、CSS、Javascriptなどの深い学習は必要ですが、PaaSの発展と共にインフラ周りの深い学習が必要かと考えると疑問を感じます。Rubyの基礎は学習したのですが、皆さん応用はどうやって学ばれるのでしょうか。最近はRubyレシピブックを眺めていますが、実用性がわからず伸び悩んでいます。HTMLやCSSはパッと見てわかるから勉強方法もわかりやすいのですが。何かオススメがあれば教えていただきたいです。AMSinatraから始めるのが個人的にはオススメです。CRUDなどをFrameworkに頼らず作ってみましょう!と思います。Ruby言語でウェブサービスを作るための最短パスを作ってみました。PM単に配慮がなされてないだけじゃないの?本来作りたいものなんてそれぞれ違うんだから上のレイヤから下のレイヤまで行ったり来たり出来るのが理想(もちろん程度問題)なんだけど、「これ便利でしょ」っつって足し算で考えたりコロコロ仕様変更したり、本当に必要か吟味されてなかったり。RubyおよびRails、もしくは他のフレームワークも含めてクソなだけだと思う。AMクソという言い方はないでしょう。Railsは素晴らしいFrameworkです。Ruby言語も私個人としてはObjective-CやJava、PHPなど他に私が普段使っている言語の中では一番好きです、構文がシンプルですし、ライブラリも充実しています。充実したライブラリをより集め、よく使う機能をFrameworkとして構成し、積極的に古い使わなくなった技術はFrameworkから外す、新しく一般的になってきた内容はFrameworkに追加する、”Framework”の定義としてアタリマエのことをしっかりやっている素晴らしいFrameworkです。「これ便利でしょ」を集めたのがFrameworkではありません。Railsにおいて、便利なのに削除されていっている機能は非常に沢山有ります。セキュリティ上の理由や、他のライブラリへの変更などがその主な理由です。Frameworkは「よく使う機能をちょうどよくまとめたもの」です。Railsはその中でも、よく使う機能を最大限高速に利用できるよう規約などをしっかりと整備した高効率なFrameworkです。「よく使う機能」が「プログラミング未経験者」にとってはよく使わない機能かなと思います。データベースのマイグレーションを教えてくれる大学なんてほとんどないでしょうし、実務レベルでも使っていない会社は少なくはないかと思いますので。Railsが目にとまりました。これを読んで納得してやめました。AMやめるだけでなく、ぜひシナトラなどの軽量フレームワークをお試しください!返信Webのフレームワークの価値ってなんだろなって改めて思う。AMGAEとかiOSとか、3年以上前の話だと思います!時代はPaaS!BaaS!MBaas!ASP!というわけで、すきなもの使ったらいいと思います。AM大いに同意できる部分がありました。コメントにいちいち反応していてはsumyappさんの時間がもったいないのでここまででよいのではないかと思いました。詳しくは言えませんが、Cakeから入った人が「アプリケーションを作ったから売る」という話になった時に、私が脆弱性テストをざっくりとしました。Injection等が起こりうる状態で少し知識があれば簡単にページどころか最悪サーバを乗っ取る事が可能な物を作っていました。※メールアドレスはダミーです。AMえー、いいじゃん、CakePHPとRoR。入門者ほどやるべきだ。めいいっぱいやって、CakePHPとRoRしか使えなくなると、ネイティブのPHPやRubyを使える人が生き残れるので、非常にありがたいです。経営者的にはWebサービス作らせて使い捨てにできれば最高だから、どんどんCakePHPとRoRを推奨するべきです。AMCakePHPはRoRと比べればまだましですが。AM色々長々とかかれてますが、RORを学習することが手段ではなくて目的と入れ違いになってませんか?って事をいいたいだけですよね?「元のコードを理解してからROR着手せよ」という書かれ方からそう読み取りました。自分のブログだから好きなことを書く⇒コメの噛み付きに対する反論として書くのは子供っぽすぎる(そりゃメモ帳にでもしろよといわれますよ)ただ、技術者を育てるという視点で言えば、いきなりRORやるよりもRubyでコード十分書ける技術を身につけたうえでRORってのは確かにいえてる。ROR推奨する勢力があることもコード重視勢力からしてみれば「住み分け」ができているのでむしろありがたいとも思うね。AM文章力がなくてすいません。色々な視点から兎に角辞めろとだけ書いてますが、趣旨としては、Railsで始めるんだーと思って始めても、たぶん何も作れるようになる前に心折れだろうから、軽量Frameworkからはじめたら?ってだけです。私は技術者育成の視点より、とにかくやってみたらいいじゃん派です。RoRを推奨している勢力と似た思想だと思います。その上で、RoRは学習コストが高すぎて、勉強するだけじゃ使いこなせなくて、ならいっそピュアPHPでもやれば?と思います。プログラミングの勉強したい=>Railsがいけてるらしいからそれを勉強しようってのは絶対続かないし身につかないから辞めたら?って思います。「プログラミングを勉強し始めよう、まずはRailsから」って考えている人は、きっと半年後も一年後も何も身につけていないだろう。PMフレームワークのマニュアルを言語やアーキテクチャへの理解なしで読めるのはクイックスタートまででそれ以上になると知識は必須になると思います。必要ないとおっしゃる方々はググったりコミュニティで聞いたものをそのまま実装して問題があった場合はどうするのでしょうか?先生が言ってましたと言う小学生のような言い訳をしますか?プログラミングの話というよりモノを作る姿勢の問題のように感じます。PMあー、こういうこという古いひといる。cake、その他フレームワークはどれも利点、欠点がある。利点をとってframeworkを利用するとによって、コストを抑えたり、開発者間のプログラムの癖をルールでしばって、品質をあげる目的もあったりする。スピードが、、、とかいうなら、JAVA,C,C++などでくんだ方がいいかと。JAVA,Cなども開発コスト面からみたらいくつか難点がある。cakeは使うな!というのは、あまりに言葉足らずな説明だ。偉そうに人に講釈足れる前に、自分を見つめ直すところから始めた方が良い。まー、みなそれぞれの思いや考えはあるとおもうが、railsなどまだ割と最近の今後のびる可能性がある技術を前向きに勉強している、技術者をあなたの用は無知なCEOが潰してしまわないことだけを願います。PM古い人だとよくコメントされますが理由が分かりません笑。学習コストが高すぎて多くの人が物を作る前に学習で頓挫してしまうFrameworkだから最初は学習コストが低いFrameworkでモノづくりの楽しさを感じた方がいいんじゃないかなと思っているだけです。この記事の読者対象は技術者ではないですよ。これからプログラムを勉強しはじめようという、ゼロベースの人です。記事だけでなく皆様のコメントも見てみてください。PMプログラミング初心者向けの記事かー。タイトルからはわかんなくて、結局読んでしまった。私はプログラミングのプの字も知らず、出来ず言語の名前を知っているだけの人間です。タイトルは釣りのようで、感性の問題ではありますが好きではありません。ド素人の私でもこの記事はとても示唆に富むものですね。Rails勉強してますし、CakePHP勉強してますし。Rails勉強してます」「CakePHP勉強してます」というエントリーもある。PMどっちから始めてもいい。困難なバグに出会って両方知ることになるんだから。