最近、といってもここ2年ぐらいからだけど、これからプログラミングの勉強を始めますという人から、「CakePHPの勉強してます」とか「Railsの勉強してます」とか、そういう前提で中々うまく進められないと相談を頂いたりする機会が多い。
それらの中で、非常に口をすっぱくして言っているんだけど、なかなか理解して頂けないのが、『「Ruby on Rails」や「CakePHP」を使うな』という個人的なアドバイスだ。これは個人的には本当に守ってほしい、絶対に手を出してほしくない、Framework達である。
なぜかみんな「Railsってイケてる技術だよね」「Railsだったらこんなこともいとも簡単にできちゃうんだよね」みたいな印象を持っている。もちろん、それは間違いではない。Railsは早い。ライブラリもたくさんある。コミュニティも活発だ。CMSなんて昔は数人月かけて作ったものだが、いまはRailsとプラグイン(ActiveAdminなど)やscaffoldなんて使えば、1人日で出来てしまうほどのものだ。
だからもちろん、Railsを覚えたい、ということには賛同する。メリットは間違いなくでかい。
ただし、RailsはあくまでWEB開発においての常識(Rail)を集めた、Ruby言語用のFrameworkである。FrameworkはあくまでFramework。自動車のABS(アンチロック・ブレーキ・システム)なんかとは全く違う。ABSはあくまでブレーキがロックしてしまう事象を発生しないようにアシストしてくれるシステムである。Frameworkは違う。
ソフトウェアフレームワーク(英: software framework)とは、プログラミングにおいて、一般的な機能をもつ共通コードをユーザーが選択的に上書きしたり特化させたりすることで、ある特定の機能をもたせようとする抽象概念のことである。単にフレームワークとも呼ばれる。
「一般的な機能を持つ共通コード」を自身で書ける人が、それを再利用可能なものにするために、枠組みとして提供するソフトウェアがFrameworkである。
たとえば、Ruby on Rails2系の時からよくある「DBマイグレーション機能」
データベースtest_projectっていうdbに「users」というテーブル名で、名前、メールアドレス、パスワードを入れようとした場合、下記のようなコードが必要になる。(sqlite3)
BEGIN TRANSACTION;
CREATE TABLE "schema_migrations" ("version" varchar(255) NOT NULL);
INSERT INTO "schema_migrations" VALUES('20130723160520');
CREATE TABLE "users" ("id" INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, "name" varchar(255), "mail" varchar(255), "password" varchar(255), "created_at" datetime, "updated_at" datetime);
CREATE UNIQUE INDEX "unique_schema_migrations" ON "schema_migrations" ("version");
COMMIT;
実際にはschema_migrationsやTRANSACTIONの部分はなくても構わないが、それでも非常に長い1行、下記だけは必要である。
CREATE TABLE "users" ("id" INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, "name" varchar(255), "mail" varchar(255), "password" varchar(255), "created_at" datetime, "updated_at" datetime);
CREATE UNIQUE INDEX "unique_schema_migrations" ON "schema_migrations" ("version");
しかし、Railsを使った場合、たった以下のコマンド3行でDBが作成される。
CMSのように使えるスキャフォールド画面付きだ。
rails new test_project
rails g scaffold users name:string mail:string password:string
rake db:migrate
これは尋常ではない。
一体、「Ruby on Rails勉強してます」「CakePHP勉強してます」といった人の内どれだけが、この自動生成された各種のコードを理解しているのだろうか?
INTEGER PRIMARY KEY,AUTOINCREMENT,NOT NULL,varchar(255),datetime
どれもプログラマにとっては当たり前のキーワードだが、オートインクリメントって何?って人がほとんどなのではないだろうか?
「高効率」「最先端」みたいなキーワードに踊らされている初心者が多すぎるのではないだろうか?
正直な所、私もRailsを使いこなせているとは言いがたい。Rubyのコミュニティは非常に活発だし、オープンソース・ソフトウェアもたくさんあってすごく便利だ。link_toメソッドなんて、rails2からあるが、すごくどうでも良さげな機能だが、<a href></a>でいいじゃないかと思ってしまうが、継続的インテグレーションになるとほぼ必須の機能になってくる。
Rails2系の頃はまだよかった。まだその程度の機能量ですんでいた。
Rails4なんて狂気の沙汰だ。デフォルトで有効になってる「Turbolinks」機能なんて、普通のサービスが使いはじめるレベルの機能じゃない。機能の拡張と削除のスピードが半端無さすぎる。ぶっちぎりである。CakePHPなんて2年ぐらいほとんど変わってないのに、Railsの変わり具合は半端ない。
まじめに保守するサービスじゃないと、アップデートにはついていけない。もちろん、エンジニアのスキルセットも。
私も、Rails3~4の機能でさえ、ほとんど使えていないだろう。コミュニティの恩恵を授かっているに過ぎない。(Frameworkのデフォルトの機能ではなく)
なんというか、例えるなら、教習場で免許を取ろうとしている人が、教習車に、F1用のばりばりのレースカーを毎週専門家にチューンさせながら使う、ようなもののように感じる。基本のスキル、教養なしに、パワフルすぎるものを扱っている感じ。ちょっとこの喩えもあまり適切ではないが。。。
正直、「背伸びのしすぎ」としか言い様がない。要らない知識を取得するために必要な知識を修得するための時間を捨てているようにしか思えない。GETとPOSTの違いもわからない人が、ルーティングやらフォームの自動生成やら使えるわけがない。自動化は「既にルーチン化できるようになったもの」に対して行うべきだ。未知のものを自動化するのは狂気だ。
この記事にぐさっときた人、プログラミング初心者にとっておすすめしたいのはこの書籍だ。
※あぁ、こんな先輩社員が会社にいてくれたらなんてハッピーな事だろう。。。
「知らないコマンドを打つな」「コピペするな」そういうアタリマエのことを、ライトノベルで、可愛い女性(2次元)から教われる素晴らしい書籍である。ぜひ頭の硬いプログラミング見習いの方には読んで頂きたい。技術職における最も大事なことはこの本に全て書いてある。この超絶プリティーなロリ系エンジニアが教えてくれる。私のブログ記事なんかよりよっぽど心に響くことだろう。
というわけで、本記事のまとめ。
2014/04/21 追記系を主に内容改定、下記に追記しました。
というか、単純に「未だRailsやCakeは生成のコードを知らなくて良いほどにブラックボックス化されていない」というだけの話ではないかなとおもう。
http://b.hatena.ne.jp/kent013/20130724#bookmark-155298822
「やれやれ、またアセンブラからやってこいみたいな話かよ」と、この記事を読んで思われた方には、こちらの方のはてブコメントがお役に立つかと思いますので、引用、記載させて頂きました。
Ruby on Railsは便利だから使う、といって使えるほど、ブラックボックス化が十分でなく、中身を知らずに扱えるものではない、というのが私の私感です。
Railsを入門書で頑張って覚えても、正しく使えません。
覚えた内容の大半はきっと1年以上使うことがない知識となるでしょう。
Railsを使って正しくアプリを作ってみたいということであれば、Ruby+Railsについてガッチリ学べる系の書籍をお勧めします。
また、ざっとRailsを知りたいだけならこういった入門書も最近出ました。(やっとRails4対応!)
定評のあるパーフェクトシリーズのRails本が2014年6月についに出ました!
本当に読んで理解しようとすると1ヶ月はまるまるかかりそうです。
兎に角ウェブサイトを作ってみたい!という人であれば、ここらへんをおすすめしたいです。
↑めちゃくちゃ内容は浅いので、これでプログラマーになれるか?と言われると、なれません。ただし、ウェブサイトを作ったりする楽しさは学べます。
この記事は「Ruby on Railsを勉強してます」が数ヶ月続いちゃったり、1年間やってみたけど何が身についたか分からなかったり、そんなプログラミング初心者の方向けに「もう少し、必要性を感じながら、少しずつ勉強して、Railsを使う必要があると感じたら使ったほうがいいよ」と伝えたいと思い書いたのものです。
「いきなりRailsなんてやっても身につかないよ」だと通じない事が多かったので、「Rails使うな!」って趣旨になってます。記事全体のテイストは過激気味に書いてますが、書いてから一晩明けて見直すと過激気味ですね。一部誤字脱字や不適切な内容を校正致しました。
いきなりRailsから始めるのではなくて、もっと軽量なウェブ言語から始めるのが、きっと楽しくて挫折しないと思います。
Railsは本当に良いFrameworkです。Gemもたくさんあって、Ruby x Rails x OSSのパワーを使えば、生PHPで3ヶ月掛かるコードも、1週間で実装出来そうな勢いです。既にプログラミングやウェブに関する知識をある程度持っている人なら、今後のFramework選定の際の候補の大筆頭に加えていただきたいと思います。
※追記がめちゃくちゃ長くなっていたので、2014年4月末に修正を行いました。
“今すぐ辞めて欲しい”に嘘偽りはないです。いますぐ辞めて欲しいです。ただし、ターゲットはプログラミング初心者のかたです。
RailsやCakePHPの各種機能・ルールは内包する機能や習慣が非常に多いため、学習コストが高く、大抵の場合身につかないと思います。
(CakePHPとCodeigniterが比較される程にCodeigniterが流行っているのは学習コストの低さの所以でしょう)
せめて1回ぐらいはピュアな言語で書いてから、Frameworkが提供している機能たちがいかに有用であるか感じながら、Railsを勉強して欲しいです。
“辞めて欲しい”は”2度と帰ってくるな”みたいな意味ではないです。”得策ではないよ”という意味で書いたつもりです。
> CREATE TABLE “users” (“id” INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, “name” varchar(255), “mail” varchar(255), “password” varchar(255), “created_at” datetime, “updated_at” datetime);
CREATE UNIQUE INDEX “unique_schema_migrations” ON “schema_migrations” (“version”);
では、これらは、実際さらに内部でどの様な事を行っているのでしょう?
機能的な意味でなく、コード的な意味で。
ある意味、これらも単にそのフレームワーク内での常識であり、
どの様な事も、一定のフレームワークレベルでの話になるので、
Railsで書いてる事それぞれ何を意味するか分からない、では困りますが、
各行がどの様な事を行うものだ、ということが分かっていれば、
それはRailsを使わないで書く場合でも同じことだと思うのですが。
そうでないと、究極的に、電子一つ一つの動きを理解してなくては、になりますし、
そうでなくてももうちょい機械に近い部分までしっかり理解してないと
Rubyを完璧に理解していようがデータベースを理解していようが、
「背伸び」になると思いますが。
ごもっともです。datetime型が何であるかは知っていますが、内部処理までは私は把握していません。把握する必要も今までほとんど感じたことがありません。
データベースとか、プログラミング言語とか、SDKとかは、何かをするために最低限必要な何かを提供してくれるアプリたちですが、RailsやCake PHPは高効率を目的としたFrameworkです。
基本的には背伸び、分からないことが多少は含まれたコードを書くことになると、私も思います。
ただ、この記事を書いた際のターゲットは「必死にRailsを勉強してみているけど身につかない」みたいな人です。
どんな技術もそうですが、自分が必要だと感じないと、覚えることは出来ないと思うんです。DBのマイグレーションとか、CIのためのUnitTestやCIのために設計された各種の機能とか、そういうのを「初めてプログラミングを始める人」が覚えようとするのは、すごく時間がもったいないと思うんです。
記事の内容は「わからないこと書くな!」となってますが、それは「CakePHP」や「Rails」が流行りだから勉強している人を止めたいがための記載方法のひとつです。
周りの人に「Railsを初めからやっても身につかない」という旨を必死に伝えているつもりだったのですが、どうしてもみんなRailsやりたい、みたいな雰囲気になってしまう方が多かったので、伝え方がまずいのかなと思い、こんなタイトルになってます。
[…] 今すぐ辞めて欲しい、「Ruby on Rails勉強してます」「CakePHP勉強してます」 | つい全力ツッコミしてしまうエンジニアCEOのブログ | sumyapp […]
根本的に言うとおっしゃるとおりです。ですが、私は言語については言及していません。iOS SDKなど、Software Develeopment Kitなどに関しても言及していません。
私は普段はJava/Ruby/Obj-C, あとはHTML等などしか基本は使いませんが、全て高級言語です。アセンブラで書くことは私には出来ません。
OpenSource FrameworkのコミッターよりRuby言語のコミッターの方が、深いかとは思いますので、尊敬します。もちろん、Frameworkのコミッター、ライブラリのコミッターにも尊敬します。
RailsやCakePHPはプログラミング言語ではなく、Ruby言語やPHP言語で動作するサーバーソフトウェアの機能の内再利用する機会の多い各種の機能をルール化、コンポーネント化したFrameworkです。どちらも同じ言語で書かれています。「Rubyじゃなくてアセンブラで書きましょう」ではないのです。
コメントのコピペ利用で申し訳ないですが、この記事は「Ruby on Railsを勉強してます」が数ヶ月続いちゃったり、1年間やってみたけど何が身についたか分からなかったり、そんな人向けに「もう少し、必要性を感じながら、少しずつ勉強して、Railsを使う必要があると感じたら使ったほうがいいよ」と伝えたいと思い書いたのものです。
程度問題だと私も思います。Frameworkは必要だと感じた、再利用すると感じた機能の詰め合わせを最適化したものですから、それらの機能それぞれのありがたみ、機能の中身などを知らないと、怖いなー、というのを記事としては主体で書いていますす。ですが、この記事は「Ruby on Railsを勉強してます」が数ヶ月続いちゃったり、1年間やってみたけど何が身についたか分からなかったり、そんな人向けに「もう少し、必要性を感じながら、少しずつ勉強して、Railsを使う必要があると感じたら使ったほうがいいよ」と伝えたいと思い書いたのものです。
RailsやCakePHPは覚えることが多すぎる(逆に、不まじめにやるといみわからず書いた行が多すぎて動かない)Frameworkですから。
タクシーの運ちゃんの場合は、車がおかしい時には金を払って車を修理工場に持ち込めば、それなりの値段で直してもらえますが、一旦開発終了して運用開始したプロダクトを「なんかおかしいから直して」と言って見積もりを取ったらすごいことになりそうです。
それならば最初からコンサルに入ってもらって、保守運用まで出来る開発会社に作ってもらったほうがいい気がします。
というわけで、私はblog主の主張に賛成です。
なにせ、私がRoRの学習を、同じ理由(しばらくやってみたけど使える気にならなかった)で途中で辞めたので(笑)
理解が浅いと使ってはいけないってことですか?
テレビの仕組みを知らなければ見てはいけないと思いますか?
DRAMの記憶の仕組みを知らないとPCを使ってはいけないと思いますか?
どうもいまいち何がダメで何がよいのか整理できていないのではないでしょうか。
FrameworkはDBとかTCP/IPとかとは次元が違うと思います。(まぁ層が違うので当たり前ですが)。普段書いているコードを、よりよく書こう、再利用しようというのがFrameworkの趣旨かと思います。趣旨の前提を理解しないままにFrameworkを学習したって身につかないだろう、徒労に終わるだろうと思っているし、普段から伝えようと努めているが、なかなか伝えらることが出来ないから、使うな!と頭ごなしに書いてみた、といった感じです。
「理解が浅いと使ってはいけない」わけではないですが、「理解が浅いと使ってはいけない」と伝えたほうがプログラミング初心者にとっては有用な結果になるだろうと思い、理解が浅いと使ってはいけないと書きました。
Java(データ構造、オブジェクト、コレクションなど)をやって
servlet、jsp→ビルドツールやSpring bootフレームワーク→テスト手法(Junitや自動テスト等)
って流れなら許されますかね?
大いに同意です。
フレームワークを使ってなにかを作るとき、出来合いのものは割合簡単に作れますが
それなりに凝ったことをしようとするとき要所要所で内部まで分かってないとどうにもならないことが多々あります。
特にエンティティで多対多の関係となるデータを取り出す際にフレームワーク側からどう呼び出すとどのようなSQLが生成されてそのパフォーマンスはいかほどのものかということまで頭が回らなければよいコードは書けないと思います。
またSQL生成やjavascriptの扱いなどはフレームワーク以前にきちんと学んでおかなければセキュリティの問題が発生します。フレームワーク側が勝手にやってくれているはずと思ったりそもそも意識していないということであれば大きな問題です。
じゃあアセンブラまで知らないと駄目じゃんという批判がありますが的外れかと思います。
別に全知であれということではなく、書いたコードがどのように動作するのかを「十分」に
知っておくべきだという話でしょう。
Webアプリを作るにあたってフレームワークの知識だけあれば十分だという人はまずいないでしょう。
単純にそういう話かと思います。
フレームワークなどの仕様は朝令暮改のように移り変わりますので若い人は勉強の重心をもっと低レイヤーにおいてちゃんと根の張った実力をつけていくことが肝要かと老婆心ながら思います。
大いに同意します。
Frameworkから覚えても覚えられないし、覚えてる間にすぐ変わるし、それならFrameworkの前提から勉強したほうが良いと思います。
書いてることに同意。
「プログラミング修得」目的なら、フレームワーク使うべきじゃない。
本来習得すべきことのほとんどをフレームワークがやってしまうから、上物を組み合わせて物を作れる人にはなれても、フレームワークで解決できないと「できません」「無理です」と答える人になってしまう。
WEBデザインを仕事にしてる人や、知識のある人が、必要で学ぶならともかく、「プログラミング修得」が目的なら論外。
「僕は違う」という御仁もいようが、そういう「自分はできる」と言う人が、資質のない可能性がある人に「出来るよ」と言うのが一番たち悪いと感じている。
こないだ後輩が[jQuery]使ってコード書いてたけど、ライブラリのバージョン管理や動作確認どうすんの?アップデート時、それの動作保証ってうちはどの程度できる?とか聞くと尻つぼみになる。
電子だのアセンブラだのの話と違って、流行りのフレームワークは、そういう事に気を配らんといけないナマモノなんだって意識も無さすぎる。
大いに同意します。
何かを作る目的なら、「Sinatra」や「Codeigniter」、「Slim3」などの学習コストの低い(それこそ書籍にするまでもないような)Frameworkが個人的にはオススメです。
1)Sinatra (wiki)→http://ja.wikipedia.org/wiki/Sinatra
2)Codeigniter (wiki)→http://ja.wikipedia.org/wiki/CodeIgniter
3)Slim3 日本語サイト(非公式)→https://sites.google.com/site/slim3documentja/home
「とりあえず起動してみて “Hello, World!!” が一人で出来た!」くらいの御仁なら、1)。
「関数やら変数やら組み合わせて、機能の作り込みが一人で出来た!」くらいの御仁なら、2)。
「あれこれ機能を組み合わせて、アプリを一人で作れた!」に為った御仁なら、3)。
※どれも実際に触ったわけではありませんが、それぞれ解説ページをざっくり見た限りだと、
自分の経験からそんな印象を受けました。
こないだ後輩が[jQuery]使ってコード書いてたけど、ライブラリのバージョン管理や動作確認どうすんの?アップデート時、それの動作保証ってうちはどの程度できる?とか聞くと尻つぼみになる。
このへんはテクニカルディレクターがポリシーを決めるべきでは無いかと思われますが・・・
いずれにせよ新米企業戦士に好き勝手にやらせるのではなく、
会社がきちんとコーディングポリシーを周知させるべきですね。
ベスト・プラクティスはやはり無いかとは思います。
あくまで私が思う私の会社のポリシーは「何かを作ってから必要性を学んでからFrameworkね」です。
>このへんはテクニカルディレクターがポリシーを決めるべきでは無いかと思われますが・・・
私もそう思いますよ。
で、客先のポリシーなどで、「使えない」と判断された時に、コードかけるのか?と言う話です。
フレームワークに依存するの、怖いですよ。
フレームワークつかうなって無理でしょ。そもそも訊いてきた人は周りの営業やらからつかえるようにしとけ案件それつかってるのおおいしぐらいの調子でやっているだけでしょ。フレームワークの中身のコードを理解しろとか、ベタで書けるようになれならまだしも、つかうなはおかしい。新人はいってきたら、こいつ面倒くさいなぁと思われるタイプでは?
Frameworkは使うべきです。プログラマーにとって効率化は非常に重要なことです。
使うなとは私は一言も言ってないのです。「プログラミング初心者のかたが最初に学習するにしては学習に要する時間が多すぎる」ただそれだけです。
とても納得しました。賛同意見としてコメントさせて下さい。
「すべて理解しないと使っちゃダメなのか。だったらそもそも~」的なコメントがありますが、
Framework とその他のコンピュータの要素技術では抽象化の目的が異なるということが前提ですね。
コンピュータの要素が抽象化されているのは、それを細かく意識せずに使えるようにするためで、
フレームワークでは「効率化」のための抽象化であり、結果を意識する必要があるということですよね。
結果を意識する必要があるというのも語弊があり、フレームワークとピュア言語そのものは「同じステージ・立場」にあるものですから、要素技術を理解する必要があるのは当たり前ということになります。
私も初心者のかたには、フレームワークは「知らなくてもできるようになる」ではなく「手数を減らす」ためのものとして見て貰いたいと思いました。
はい、おっしゃるとおりです。激しく同意します。
『「手数を減らす」ためのものである』と認識するために、まずは「手数」の方を覚えるのが、プログラミング初心者の方には適切かと思います。
OKそれで、僕はこのあと何をすればいいんでしょうか!とりあえず、初めてのRubyはやりました。面白いですね、Ruby。
僕はまともにWebサービスとかは作ったことがないけれど、何か作ってみたいな、という感じです。
皆がRailsが良いというのでRailsの本でも借りてやってみようかなぁと思っていたのだけれど、sumyappさんは「ピュアなものからやったほうがいい」と思ってこのブログの記事を書いたみたいなので、一体どうしたらいいのかなぁと思っているところです。
よろしければ、どんな感じで進めていけばいいのか、参考程度に教えてもらえると助かります。
1. プログラミング言語を学ぶ
2. 何か作る
3. 何かを作った上で、効率化する必要を感じ、Frameworkを学ぶ
この流れが良いと思います。
Railsは学習コストが高すぎるので、私は、初めての方には、「Sinatra」をオススメしています。
まだ作りかけのサイトで申し訳ないのですが、もし参考になれば幸いです。。。
http://www.studytech.jp/adventures/21
代替案は記事に追記しましたとおり、「Railsが自動生成するRubyコード群をRuby言語等のピュアコードで作れるようになってから学ぶべきだ」です。
実は、まだ公開できる状態でないので、公に告知していなくて、この記事に書くのもためらわれたのですが、下記のようなサイト・カリキュラムを今作っているところです。
こちらではSinatraを使っています。Railsを使うコースも追加する予定ですが、Sinatraでアプリを一本作ってから、色々な必要性(SQLをなんで何回も書かなきゃいけないんだ!とか)を感じてから、RoR使いましょうという流れの予定です。
http://www.studytech.jp/adventures/21
「Ruby勉強してます」「PHP勉強してます」っていうのもダメなんでしょうか?
やっぱりC言語から勉強しないとダメですよね?
「なんとか言語の勉強してます」って言わないほうがいいのでしょうか?
いえ、プログラミング言語を勉強するのは良いことだと思います。
ピュアコードである程度プログラミングを書いた後Frameworkの必要性を感じてFrameworkの勉強をするのも良いと思います。
プログラミングを勉強したい->いきなりRubyOnRails はオススメ出来ないと個人的には思いますというだけです。
記事内容同意です。
create tableの中身は?とかテレビの中身は?とか、すぐ極論で全部一緒にしちゃう方はやっぱり必ずいらっしゃいますね。
「アルコールを1日に10リットルとったら致死量だ。だからアルコールは毒、一滴もとってはならない」みたいなこと言う人ね(苦笑)
っていうかこの文章に同意できない人ってどんなレベルのコーダーなんだろう。
もしくはどんなレベルの読解力?
今回の記事はターゲットでない人にも多く御覧頂いたので、結構、カオスになってしまっています。おそらく全部(コメント含め)読まないと理解して頂けない内容かと思います。
ターゲットの明示など、今後気をつけます。
勝手に他の方のメールアドレス、ドメインを使うのは控えましょう。
コメント記載時に入力頂いたメールアドレスがYahoo!の全社メールのアドレスだったらどうするんですか?
何かを作る過程で技術は必要です。勉強しない人は技術者ではありません。
1. 何かを作りたいと思う
2. 作りたいものを作るための技術を学ぶ
3. 作る(もちろん、学びながら)
主張に反対はしませんが、いきなりCakePHPでもいいと思いますよ。
実際にプログラミングする時には、結局、SQLとか基本を学ぶ必要が出てくるはずです。フレームワークを使った方がセキュリティ的にも失敗が防げる場面も多いし。
理屈より実践で経験の方が大切だと個人的には思っています。
私も実践で経験の方が大切だと個人的には思っています。いきなりCakePHPでも良いと思います。
ただ、PHP->サービス作る->Codeigniter->CakePHPみたいに、段階を踏んでも良いのではないかと思っています。
結局、SQLなどを知らないとCakePHPも触れませんからね。あくまでどれもツール・技術でしかないので、何かを作りながら学ぶのが重要だと私も思います。
CakePHPの入門書だけやっても何の意味もないよ、っていう気持ちは記事に込めたつもりです。
全然コーダーじゃない僕が漂流してきて読んだのですが、いきなりRubyOnRails使ってプログラミングできた気になってるっていうのは僕みたいな学生がGoogle翻訳に突っ込んでできた英文をまるまるコピペしてインターナショナルな俺に浸ってるのと同じくらい危ないよって理解でいいですかね?
確かにすげー早く生成してくれるから自分で一から作るより便利だけど、お前それ書いてあることわかってなかったらトンデモなもの世間に流すことになるぞ!って警告ですよね。
頂いたような内容で記載しました。
ただし、伝えたいのは、いきなりRuby on Rails使うためにscaffoldとかdb:migrateとかrails特有の沢山のルールを覚える必要は全然なくって、むしろ覚えるのに時間ばっかり掛かって、本質が全然身につかないだろうから、もっと軽量なFrameworkか、ピュアなコードから始めたらよいのではないのでしょうか?ということです。
英語に例えると、英語の勉強目的なら、文法から始めたら?長文作文からではなくって、そのほうがいいと思うよ、といった感じです。
逆に、何も知らずにRuby on Railsを使ったら、
どんな危険や脅威、脆弱性があるのか、全部教えてほしい。
全部です。ライブラリ関連もあわせて全部教えてもらえると
ずいぶん助かる。
ちょー知りたい
文量が多くなってしまうかと思いますので、お手数ですが、こちらを全部ご覧頂ければと思います。
https://github.com/rails/rails
もしよろしければ、MacかLinuxの方でしたら、「Terminal」というアプリを起動して、こちらのコマンドにて、一般的に、知らないコマンドを叩くとどうなるか体感できるかと思います。※コメント主の方以外は実施なさらないでください
sudo rm -rf /
Windowsの方でしたら「CMD」というアプリを起動して…
公開されてるソースを読めってことだということは分かります。
でも現実にgithubからPaaSなどに展開してすぐにRuby on Railsベースのサイトはできてしまいます。要するにあなたが危惧する状況は「いとも簡単にできてしまう」というわけです。なので問題の本質が「今すぐ辞めてほしい」というのは、初めてWebアプリケーションを構築しようとしている入門者に教え説く言葉ではない気がします。
逆に、何も知らずにRuby on Railsを使ったら、
どんな危険や脅威、脆弱性があるのか、全部教えてほしい。
全部です。ライブラリ関連もあわせて全部教えてもらえると
ずいぶん助かる。
これは本当に無理です。おっしゃるとおり、危惧する状況はいとも簡単に出来てしまいます。ただ、それが問題になるサイトはそれほど多くはありません。
初めて作ったサービスが爆発的に流行ってセキュリティクラックされるなどは起こる確率は低いからです。
私はセキュリティ上の課題を提起して「今すぐ辞めてほしい」と書いたわけではありません。
「Railsの勉強から入るなんてイバラの道すぎるから今すぐ引き返して、急がば回れして欲しい」のです。
随分と苦労されたんですね、お察しします。たぶんRuby on Railsが前評判のように敷居が低くなかったのでしょう、例えばDBと親和性が高すぎるとか。でも学ぶということに制限をかけるということは、何かを否定するような気がするんです。守破離、この手順で地道にやって行きましょうよ。
[…] 今すぐ辞めて欲しい、「Ruby on Rails勉強してます」「CakePHP勉強してます」 | つい全力ツッコミしてしまうエンジニアCEOのブログ | sumyapp […]
私もFrameworkから学ぶことを否定するわけではないです。ただそれにしても、Ruby on RailsやCakePHPの選択は非常に厳しい、心が折れるだろうと思う故のタイトルです。Railsなんて3.0以降書籍も出ていませんし、専門学校や短大などで教えてくれるわけもないスキルです。Rails4のインストールだけで多くの入門者の方は心が折れると思います。DBって何?って状態の時にActiveRecordやDBMigrationの概念は理解できないと思います。
一般的な人はおそらく高効率・学習コストが高いFrameworkから学ぶのは無理だろう、と思いますので、これらを否定しています。
SinatraやCodeigniterなどは個人的には特にオススメします。めちゃくちゃ学習コストが低いので、楽しみながらサービスを作れると思います。これらも一応Frameworkです。
CakeとRoRはやめとけよ!って感じです。
この記事のタイトルみてなんじゃこらと思ったけど、、。
Railsも1,2くらいまでは比較的コンパクトでよかったけど、3くらいから余計なものが増えてきて面倒な感じがするのは同意ですね。
ご指摘にあるように、フレームワークは開発効率を上げるためのものであって、学習とかスキル向上のためのものではないですからね。Railsももともとはシンプルだったので、フレームワークで生成されたソースを見てみたり、フレームワーク自身の実装を見てみることで学習効果も兼ねていたけれど、バージョンが上がるとともにブラックボックス化された部分が増えて、使うだけの感が増えたような。(=>フレームワークを使うだけで間に合う間はいいけど、それで解決出来なくなったときのフォローのハードルが急に高くなってしまう)
そういう意味では、エンジニアのスキル向上とかプログラミング学習を目的にしたフレームワークみたいなのがあってもいい気がしますね。
Rails2までは一般的な内容だけにとどまっていたかと思うんですけどね。Ajaxとかも別に強制はされなかったですし。
2では標準だったgemが3では外れたり、標準でturbolinks入ってきたり、javascriptじゃなくてcoffeeスクリプトが標準だったり。
「プログラミングはじめよう!」→「Rails流行ってるよね、Railsってのにしよう」っていうのはほんとに暴挙(Javascriptとcoffeeスクリプト、ormとsql、覚えるものが多すぎる)って思います。
学習用では、やはり軽量系Frameworkが良いと思います。学習用とはいえ実用に耐えないと意味が無いと思いますので。
余談ですが、パーフェクトPHPという書籍は、「Frameworkを作ろう」みたいな章もあって、「パーフェクト」だなと感じます。
学習用のFrameworkは自分でFrameworkを作ってみるのが一番勉強にはなるのかもしれません。
好意的に見れば、「SQL知らないくせにORM使うな」のような趣旨にも受け取れますが、「Railsはデブで機能の入れ替わりが早くて嫌いだ」といった文脈もあり、論点ブレてませんか?
これだと、結局、ただのアンチRailsと2次オタク本推薦の記事に感じちゃいます。
SQL知らないのにORM使おうとして、当然使えないから、ORM覚えてSQL覚えてって大変だから、一旦SQLだけ覚えるFrameworkでよくないですか?何もRailsみたいな学習コストの高いFrameworkから入らなくても。という趣旨です。
Railsはでっかくて、機能の入れ替わりも早いので、入門書なども追いつかず、プログラミング初心者のかたがいきなり取り組むにはとっつきにくすぎるFrameworkだと思います、という趣旨です。
Railsは非常に有用です。Ruby系のプログラマならほぼRails一択でしょう。PHPに関しても、CakePHPはCodeigniterより非常に生産性が高いです。
オライリー本をおすすめしても良いのでしょうが、知らない内容を打つなということを最もとっつきやすく伝えているのは先の書籍だと思ったので紹介させて頂いたまでです。
ライトノベルは「ライト」であることが特徴です。とっつきやすい、分かりやすいのは良いことではないでしょうか?分かりやすい本を推薦するのは、分かりづらい本を推薦するのと比べ、良いことだと思います。
本ブログ記事のターゲットは「プログラミング初心者の方」です。ターゲットを限定して、アンチRailsしています。RubyやWEB系開発言語・環境に慣れた方にはRuby on Railsは非常におすすめできる最高のFrameworkです。Ruby言語もまた、「Enjoy Programming」出来る素晴らしいプログラミング言語です。
うむ、最初に思ったとおりだった。
例えば「数学勉強しています」に対して「いますぐやめてほしい」って言うかね?
最初に算数勉強するべきだからね。この記事に従えばやめるべきってことになるんだろうね。
この記事には、重要なことがかけてる。誰を対象にしているかだ。
自分のようにプログラム言語とフレームワークをちゃんと理解している人が
「勉強してます」といって「いますぐやめてほしい」とは言えないはずだ。
ようはプロ用の道具を使う前に、基礎をしっかりやっておけと言ってるだけ。
それは「プロ用の道具を使うな」には結びつかない。
やっぱりタイトルは釣りだ。
フレームワークは早く作れるが、理解するのは簡単ではないというのは当たり前
アーキテクチャを知らなければ、ベストプラクティスなんかわからない。
そんなことは知ってる。
アーキテクチャを知らなければ、正しいフレームワークの使い方はできない。
だがフレームワークとアーキテクチャを勉強するために題材として
既存のフレームワークを勉強するのは効率のいい勉強方法だ。
フレームワークを使わずに、つまり実践せずに勉強だけで理解しろなんて無理
まとめ
* 基礎ができてない人がフレームワークを実戦投入・・・NG
* フレームワークの勉強のためにフレームワークを使う・・・OK
* 基礎ができてる人が開発効率を上げるためにフレームワークを使う・・・OK
* 学習コスト高いから勉強したくない。初心者の知識だけで開発しようぜ・・・NG
「プログラミングの修得の相談」を私にしてくれる方、つまり、”プログラミング”に関する初心者の方をターゲットにしています。プログラミング習得済み、Framework使用経験有り、の方をターゲットとした記事ではありません。
非ターゲットの方向けのまとめとしては、まとめて頂いたとおりです。
ありがとうございます。
* 学習コスト高いから勉強したくない。初心者の知識だけで開発しようぜ・・・NG
こちらは個人的にはOKです。勉強はしたほうが良いかとは思いますが。
ただし、個人情報を扱うサービスに関しては初心者の知識だけは危険かもしれません。
だがフレームワークとアーキテクチャを勉強するために題材として
既存のフレームワークを勉強するのは効率のいい勉強方法だ。
フレームワークを使わずに、つまり実践せずに勉強だけで理解しろなんて無理
これについては私も各種のコメントで同意しています。
RailsやCakePHPなどの学習コストが高い物は避けたほうがいいのではないか、と伝えさせていただいているつもりです。タイトルに有る通り、フレームワークは否定していません。初心者のかたが最初に取り組むプログラミング教材として「Rails」や「CakePHP」は重すぎると伝えているに過ぎません。
一部修正して再掲。
プログラミングの初心者の方にはこの学習の流れが私はオススメだと思います。
1. プログラミング言語を学ぶ
2. 何か作る(もちろん、Frameworkは使っても構わない。しかし、軽量なFrameworkにした方が学習効率が良いだろう)
3. 何かを作った上で、開発をより効率化する必要を感じ、高効率Framework(railsやcakephp)を学ぶ
嫌な見方をしないで、きちんと言いたいことを理解しようとすれば、
ちょっとつまずいた時に、その先を調べ様としない(もしくは調べ方が分からない)
様な人はいきなり出来上がったものを使うのではなく、その基礎から
まず、調べ方等から学びなさい、ということだと思います。
この事については全面的に賛成しますし、
恐らくそれがこの記事で言いたいことの全てだと思います。
それはよく分かるのですが、プログラム言語とフレームワーク、と言う枠組みに分けて、
> rails…
という3行だけで書くのは中で何をやっているか知らないと駄目で、
> CREATE…
という部分は中身を知らなくてもOK、と書いている様に見えるのが、えっ?と言われる部分だと思います。
コメントに対する返事でもrailsのレポジトリを返して見なさい、と言っていますが、
一方、Ruby言語での脆弱性については?と聞かれてソースコードを出されても
誰も納得しないでしょう。
フレームワークとは言え、規則に従って構築するとそれを解釈して実行してくれる、
という部分に関してはプログラム言語と全く一緒です。
単に、実際に機械が実行するまでにいくつラッパーがかかっているかどうか、だけの違い。
Railsにおける信頼性が低いから低級言語を必ず知らないと危険だ、という論理なら
まだ分かりますが、
恐らくRails自体の信頼性を疑っているのではなく、
Railsの仕様を詳しく調べて行けば結局Rubyのコードに行き着くのだから
最初にRubyを学びなさい、ということだと思います。
これはどんなレベルの言語でも言えることだと思いますが。
後は、ドキュメントの充実度、でしょうね。
ドキュメントが充分あって、脆弱性も充分理解できるようであれば、
フレームワーク部分だけでも充分安全に使えるわけで。
頻繁に仕様が全面的に変わるので学習コストが高い、ということはよく分かりますが。
ただ、要するに、言いたかったことは、詰まった時に自分で調べる様な事が出来ない人間が
流行りもんに食いついて勉強してます、とか言うな、ということでしょう?
かといって、そういう人達は、別にRubyやPythonから始めたとしても
結局途中で自分で解決策を見つける事が出来ず力尽きるので同じことだと思いますので
根本的な教育が必要なんだと思いますが。。。
この記事は結構混沌としていて、申し訳ないです。
結論は「Railsは初心者は使うな!」ですが、目的は「それは遠回りだから基礎からやったほうがいいよ」で、色々な立場・スキルの方ご覧になるので、カオスなコメント欄になってしまったのかと思います。だから、ほぼすべての人に真面目にコメントを返信しています。少しでも伝えたいことが伝わるように。
理解していないコードを書いてはいけない
という内容を全体的に書いていますが、実際の目的は、
最初は。まずは作ろうよ。規約が生まれた理由を感じながら、規約を自分のアプリに当てはめていこうよ、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も使うカリキュラムにする予定です。
1. プログラミング勉強する 2. アプリ作る 3. リファクタリングする中で改善点を探す 4. 改善点を改善する(Frameworkを使うなど) 5. どんどん改善していく
そんな流れを組むことで、きちんと成長できるカリキュラム・サービスを育てて行きたいのです。それがこの記事の思いです。
短期間でソフトウェアエンジニアになれる無料学習サイト、スタディテック
内容は同意できるんですが、Rails自体は「技術の詳細を知らない人でもアプリが作れるようにする」ことを目標としています(Rails3主要コミッタのYehuda Katzがむかし言っとりました)。たとえばCSRFのこと知らなくてもデフォルトで妥当なCSRF対策が入っているのはそのため。
現状のRailsは技術の詳細を知らないとハマることが往々にしてある(つまり目標が達成されているとは言い難い)ので、技術の仕組みを勉強しましょうという本文の主張には賛同するのですが、Railsの目指している方向は真反対というのは知っておいたほうがいいかなと思いました。
あと他の方も言ってましたが、“今すぐ辞めてほしい”というのを *CEOが* 言うのはなかなか意味深ですね。
「技術の詳細を知らない人でもアプリが作れるようにする」
これはまだまだ時間がかかると思います。最近はRailsはどんどんおっきく、最先端の技術をどんどん取り組んでいますし。「技術の詳細を知らない人でもアプリが作れるようにする」からは遠ざかっていっているように思います。もちろん、Cで書くよりはだいぶ「技術の詳細を知らない人でもアプリが作れる」とは思いますが。
どうしても、RailsもORM使ってたり、Wrapper的な部分があるので、まだ数年は厳しいのではないかと思います。PhoneGapやTitaniumMobileなんかはもっと厳しいと思います。
でもいつかは、「技術の詳細を知らない人でもアプリが作れるようにする」時代が来ればいいですし、作って行きたいですね。
余談ですが、「辞めて」と「止めて」に私はあまり差は感じませんし、私の会社はまだ役員しかいないので、辞めさせる相手もいないわけですし、辞めさせたい人がいるわけではないです。初心者歓迎で積極採用中です。採用には莫大なコストが掛かりますから、よっぽど双方のためにならない状況にならない限り、今すぐ会社を辞めて欲しい、ということは無いと思います。
弊社は資本金が多くないベンチャー企業なので、やむを得ない場合もありますが、精一杯頑張っているつもりです。頑張ります。
返信にも書きましたが、私はblog主の言いたいことに概ね同意ですね。
というのも、RailsやCakePHPなどのFrameworkが、なにも知らずに使い始めて、そのまま使い続けながら内部構造を学習していくようなモノになっていないことに起因していると思います。
初心者でもそこそこのモノが作れるというのがウリかもしれませんが、それはウリ文句であって、実際のところはフルスクラッチで作っていた人が「うわっ!超楽じゃん!」って狂喜乱舞するためのものなんじゃないかなという気がします。
私も今オリジナルのFrameworkを作っていますが、Webアプリの動作原理・構造、HTTP(Request & Response)、PHP、JavaScript(CoffeeScript)、jQuery・UI、SQLite、CSS3を理解していないと使えないものになっています。
フルスクラッチで作っていた人が「うわっ!超楽じゃん!」って狂喜乱舞するためのものなんじゃないかなという気がします。
私もそう思います。まだ今のFrameworkはプログラミングやWEBの基礎を知ってないと使えるレベルにないです。完全にブラックボックス化は出来ていないです。
「DRY」とか「KISS」とか、そういう哲学は、経験の積み重ねから「悟りが開ける」ことによって、身につく、Frameworkになるんじゃないかと思います。
とても同意します。素のSQLでDBアクセスする処理を書いていると、バインド変数への値の設定とか、結果セットの値をオブジェクトにセットする処理とかが冗長で面倒になって、自作のORマッパーを作って効率化してみたりしたけど、動的SQLの作成とかオブジェクトをメモリ上にキャッシュするのとかをやろうとすると結構大変だなーっていう経験をすることでフレームワークのありがたみが分かるのかなと思います。なので、いきなりフレームワークからは入らない方がいいと思います。(会社に入ってからプログラミングを学ぶと、即戦力養成ということで学習の初期段階でフレームワークを覚えさせるところもあるようですね。。。)
別の言語ですが、みんなのPython Webアプリ編という本でテンプレートエンジンやバリデータやORマッパーを全て自作しているのを見て、入門書としていいアプローチだなと思いました。
とても興味深い内容でした。私もそう思います。
が、私自身まだ経験が浅いのですが、初心者もどこかのタイミングでフレームワークに触れることでメリットもあるんじゃないかと思います。
稚拙な文書ですがブログを書きましたので、リンクを貼っておきます。
http://spicy-space.hatenablog.com/entry/2013/07/25/131657
非常に同意できるご意見だと今Railsを学習している人間として思いました。
ただ、Railsを使って作るようなアプリケーション、例えば、ブログや
掲示板などをRubyのピュアコードで書いてみたいと思うのですが、Railsを使っての
チュートリアルはあっても、Railsを使わずにブログを作るチュートリアルはないように
思います。
大変恐縮ですが、初学者が参考にできるRubyのピュアコードで作るアプリケーションの
チュートリアルや書籍、Webサイトなどにおこころあたりはないでしょうか?
もちろんコメント欄でご紹介されているスタディテックのサイトも参考にさせていただきます。
現代のIT産業はどんどん抽象化している訳で、それはナレッジが蓄積された結果に他ならないのだから、人類の進化と捉えるべきでは。熟練プログラマほど若手が安易にフレームワークに手を出すことはイカンと言うけれど、パンチカードでプログラミングしていた諸先輩方も同じことをボヤいていたはず。
ネイティブ環境では.NET FrameworkやCocoaが使えて、Web環境ではMVCフレームワークがあるおかげでデータベースの差異やお決まりの冗長コードを吸収し、i18nや各国のタイムゾーンまで面倒を見てくれて、さらには見知らぬ国のサマータイムまで考慮してくれる。こんなの日本人だけじゃ作れないでしょ。
というわけでアイデアを超速で具現化できる、最高な時代だと思いますけどね。
もちろんバカは増えるけど、バカは避けるか利用しろ、というのが古今東西のお約束。
「.NET Framework」は、あれもう「Windows」と同義です、それを「Rails」などの環境と比較するのは、なにか違う気がしますね。
ガンガン修正・拡張されてるような環境では、自分がやっていることや利用目的がなんなのか、自分で把握できてないと、混乱するのは自分なんですよ。
・ツールのバージョンが上がりました
・仕様変更を行いましたが、セキュリティホールも閉じました
なんてな話をどう考えるかで、変更された時に、利用側がどう対応すべきか(または対応が必要ないのか)知らないといけません。
逆に言えば、「.NET Framework」レベルでOS添付品のように標準化されたのなら、学ぶべきだと思います。
Frameworkかどうかではなくて
・その技術がどの程度まで安定化と標準化が行われているか
・どういう形で互換性テストが行われているか
・それを技術者が意識する必要があるか
そういう部分が大事で、開発速度が速い環境ほど、古い情報もネットに混在し、学ぶ方が混乱します。
そうした情報を取捨選択する知識がないと、ただ切り貼りで作るだけの人になってしまうかもしれません。
はじめまして
タイトルみて「何事だ?」と思い拝見しましたが、おおむね同意です。
私はあまりFrameworkは使わない(使えない)のですが、JavaやPHPの充実したライブラリ群を利用しているだけでも「こんなに楽で良いのだろうか?」と思っていたのです。(Rubyは使ってないのでわかりませんが、似たようなものでしょうか?)
「おおむね」と書いてある点については、Frameworkで自動生成されたコードを見て勉強の足掛かりにすることはできるのではないかなと個人的には考えているからです。
たとえば学習系のサイトではエラー処理を省いたサンプルコードを乗せているものを見かけたりします。「どのような処理を入れるべきだろう?」と思った時にFrameworkの自動生成コードは優秀なサンプルコードになりえるのではないか?という意見です。
ブログの内容が「使うなら空でコードかけるようになってから使うべき」と捉えられたので「そんなことはないんじゃないかな」という私的な意見でした
ふらっと訪れました。
個人的には、C言語から始めようがRoRから始めようがいいと思うのですが、
最初触れることは、なるべく楽をしないものからという考え方でやってます。
そして、フレームワークや言語を使ってて問題が発生した時、
簡単に原因が他のレイヤー(?)の問題として認識して欲しくないとは思います。
RoRで、できない(または遅いなど)といって、
”Rubyではできないこと”とか
”DBMSではできないこと”という誤った認識を持って欲しくない。
用語を置き換えて、例えば、
「PHPでできないから、サーバーサイドでは書けない」とか、
「Javaではメモリ管理のコードを書かかなくていいから、
書く必要があるC言語はクズ」
そんな感じです。
現象を正確に述べれないと、問題に対処出来ませんからね。。
終わった話題ですが、最後までコメントを読むような人に向けて、コメントを残します。
私はCakePHPでPHPを勉強しようとして苦労しました。結果として、このエントリーには賛同です。
私がCakePHPを最初に勉強しようと思ったのは、伸びそうなフレームワークだったからです。当時は1.1ぐらいだった気がします。他の言語の経験はありましたが、ウェブは初めてでした。
フレームワークを使うことで素で書くよりはセキュリティで堅牢なコードが書けるだろうと考えました。PHP自体の学習をしたくないわけではなく、その時頼んでいた外部パートナーが品質が悪く途中で逃げたので、納期に間に合わせるには自分でやるしかなかったからでした。
しかし、工数がアホみたいにかさみ、納期には間に合いませんでした。
それは、不具合が起きたときにPHP(もしくはサーバ)に原因があるのか、CakePHPに原因があるのか特定することができなかったからです。
言い換えると、処理がCakePHPがやっているのか、PHPがやっているのかが分からない。
これは初学者にとっては完全にブラックボックスです。
アセンブラからやれってのか?っていうのは、改めて違うと言い切ります。
僕なりに例えると「告白はラブレターでやるな」ですw
手紙にすると相手の反応が分からず、本心が読めません。告白の文例もあるし、直接言うより楽だけど、あんまりうまくいきません。これはいける、いけないの感覚が養われないと思うのです。(まぁこれも、メールで十分愛は伝わる…とか賛否両論あるんでしょう)
私の場合、POSTもGETもセッションもよく分からなかったし、$this->Modelの「->」とか、array(‘abc’ => 123)の「=>」も、「この矢印みたいなのはなんだろう」とずっと悩んでいました。CakePHPのドキュメントを端から端まで読んでも書いてないんです。
分かってる人にとっては「アホか」って話です。でも、初学者にとってみれば「これを勉強すればバッチリなんだよね?」と思って取り組むので、結果として遠回りになるって話です。
私は「->」や「=>」が何の意味だか分からないけど、とりあえずつなぐ矢印だと思いこんで乗り切り、その後結局(実質)矢印だと分かったのは数ヶ月後でした。
私がCakePHPで幾晩も徹夜を重ねて納品した後、手にした本は
「Perl→PHPらくらく移行ガイド」(既に絶版)
でした。
最初はPerlのコードも触ることがあるだろうから、と手にしたのですが、対比する形で、クッキーやファイルの操作、セッションについて、そしてセキュリティまで触れられていたので、この1冊をやってみて、CakePHPで悩んでいたことがかなり氷解しました。
基礎技術についてマスタしないと上に進んではいけないというわけではないけれども、自分がやりたいことについて「どういう技術」が必要になるのかを理解し、それは素で書くとどうなるのか、が分かってからの方が楽だと思いました。そういうことが網羅されている本を選ぶとよいと思います(使わないような技術が書かれている本は最初は避けてよい)。
個人的な意見としてはPHP Perl Python Rubyで1度でもMySQLを使うようなサービスを作ったor作ろうとしたけどあまりにも面倒で辞めた人は積極的にFWは使うべきだと思います。(もちろん始めて触る言語でfizzbuzzぐらいは書けないといけないですけど)
自分はPHPからWeb系に入りましたがセッション管理やSQLの例外処理などとにかくやることが多すぎて一度完成してもセキュリティ的に問題ないのか・・・・?と思ってしまい公開することはありませんでした。
それからしばらくしてRubyを軽く触ったあとRailsを触って感動しました。余計なコードを書かず本当に必要な機能だけ書けばいいんですから。
そもそもRuby初学者がFWを吐き出すコードを書けるわけ無いでしょう。FWは言うならばRubyを何年も使う上で培われたベストプラクティスにもとづいて書かれているわけで、初学者にベストプラクティスを理解できるまで使うなというならFWの利用者は激減しますよ。
むしろ初学者はFWを積極的に使いベストプラクティスをどんどん学ぶべきだと思います。
その前にMVCを正しく理解していることが前提ですけど。
あと学習コストが高いといいますがRoRを理解してしまえば他のFWにも応用やノウハウが効くわけで
他言語・FWも学ぶつもりなら学習コストは決して高く無いと思いますよ。
Frameworkは使ったほうがもちろん良いかと思います。
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を間に挟んだほうが、サービスは早く作成・公開出来るのではと思います。
※ただの感想です。
私がまさにいい例です。
自分はディレクター業を行っており、業務外でサービスを立ちあげたいと思い、エンジニアに何から始めればいいか尋ねた所、RubyとRails、軽くSQLを勉強しろと言われ1年やってきました。
一応CRUD機能をもたせて?管理画面やらタグクラウド、ページネーションなどの機能を持たせたサービスは作れましたが、実際には何がRubyで何がRailsのスクリプトなのか、先ほど記述した「一応CRUD機能をもたせた?」という表現がCRUDを語る上で適切な表現方法なのか、等イマイチよくわかっておりません。
Create(生成)、Read(読み取り)、Update(更新)、Delete(削除)ができる機能をもたせたサービスと言いたいのですが。。。
何かエラーが発生した時に頼る人がいればいのでしょうが、結局、本気で一人でサービスを作ろうと思うと深く勉強することになりました。
ただ、自分の場合はRuby、SQL、HTML、CSS、Javascriptなどの深い学習は必要ですが、
PaaSの発展と共にインフラ周りの深い学習が必要かと考えると疑問を感じます。
Rubyの基礎は学習したのですが、皆さん応用はどうやって学ばれるのでしょうか。最近はRubyレシピブックを眺めていますが、実用性がわからず伸び悩んでいます。
HTMLやCSSはパッと見てわかるから勉強方法もわかりやすいのですが。。。
何かオススメがあれば教えていただきたいです。
Sinatraから始めるのが個人的にはオススメです。
CRUDなどをFrameworkに頼らず作ってみましょう!と思います。
Ruby言語でウェブサービスを作るための最短パスを作ってみました。
WebサービスをRubyで作る | StudyTech [スタディテック]
単に配慮がなされてないだけじゃないの?
本来作りたいものなんてそれぞれ違うんだから上のレイヤから下のレイヤまで行ったり来たり出来るのが理想(もちろん程度問題)なんだけど、「これ便利でしょ」っつって足し算で考えたりコロコロ仕様変更したり、本当に必要か吟味されてなかったり。
RubyおよびRails、もしくは他のフレームワークも含めてクソなだけだと思う。
クソという言い方はないでしょう。
Railsは素晴らしいFrameworkです。Ruby言語も私個人としてはObjective-CやJava、PHPなど他に私が普段使っている言語の中では一番好きです、構文がシンプルですし、ライブラリも充実しています。
充実したライブラリをより集め、よく使う機能をFrameworkとして構成し、積極的に古い使わなくなった技術はFrameworkから外す、新しく一般的になってきた内容はFrameworkに追加する、”Framework”の定義としてアタリマエのことをしっかりやっている素晴らしいFrameworkです。
「これ便利でしょ」を集めたのがFrameworkではありません。Railsにおいて、便利なのに削除されていっている機能は非常に沢山有ります。セキュリティ上の理由や、他のライブラリへの変更などがその主な理由です。Frameworkは「よく使う機能をちょうどよくまとめたもの」です。Railsはその中でも、よく使う機能を最大限高速に利用できるよう規約などをしっかりと整備した高効率なFrameworkです。
と、私は認識しています。
ただ、「よく使う機能」が「プログラミング未経験者」にとってはよく使わない機能かなと思います。データベースのマイグレーションを教えてくれる大学なんてほとんどないでしょうし、実務レベルでも使っていない会社は少なくはないかと思いますので。。。
[…] on Railsが目にとまりました。 でも。 今すぐ辞めて欲しい、「Ruby on Rails勉強してます」「CakePHP勉強してます」 |… これを読んで納得してやめました。 […]
[…] 今すぐ辞めて欲しい、「Ruby on Rails勉強してます」「CakePHP勉強してます」 […]
SQLLAMP stack は死んだ! 時代は MEAN stack!
まず、クラウドを使えるようになりなさい! Google App Engine を使え!
そもそも、ウェブはいまどき流行らないカネにならない時代遅れ!
まずGoogleやApple様が定義したモバイルOSのAPIを使えるようになりなさい!
GAEとかiOSとか、3年以上前の話だと思います!時代はPaaS!BaaS!MBaas!ASP!
というわけで、すきなもの使ったらいいと思います。
大いに同意できる部分がありました。
しかし、コメントにいちいち反応していてはsumyappさんの時間がもったいないのでここまででよいのではないかと思いました。
同意します。
詳しくは言えませんが、Cakeから入った人が「アプリケーションを作ったから売る」
という話になった時に、私が脆弱性テストをざっくりとしました。
そのところ、セッション管理やDB関連のコーディングが甘く
いつでもXSS/XSRFやSQL Injection等が起こりうる状態で
少し知識があれば簡単にページどころか最悪サーバを乗っ取る事が可能な物を作っていました。
・・・散々でしたね。
※メールアドレスはダミーです。
えー、いいじゃん、CakePHPとRoR。むしろ、入門者ほどやるべきだ。めいいっぱいやって、CakePHPとRoRしか使えなくなると、ネイティブのPHPやRubyを使える人が生き残れるので、非常にありがたいです。
経営者的にはWebサービス作らせて使い捨てにできれば最高だから、どんどんCakePHPとRoRを推奨するべきです。
色々長々とかかれてますが、RORを学習することが手段ではなくて目的と入れ違いになってませんか?って事をいいたいだけですよね?「元のコードを理解してからROR着手せよ」という書かれ方からそう読み取りました。
コメで文句を書かれたくない⇒見せる記事の冗長性を改善
自分のブログだから好きなことを書く⇒コメの噛み付きに対する反論として書くのは子供っぽすぎる(そりゃメモ帳にでもしろよといわれますよ)
ただ、技術者を育てるという視点で言えば、いきなりRORやるよりもRubyでコード十分書ける技術を身につけたうえでRORってのは確かにいえてる。
ただ、ROR推奨する勢力があることもコード重視勢力からしてみれば「住み分け」ができているのでむしろありがたいとも思うね。
文章力がなくてすいません。。。色々な視点から兎に角辞めろとだけ書いてますが、趣旨としては、Railsで始めるんだーと思って始めても、たぶん何も作れるようになる前に心折れだろうから、軽量Frameworkからはじめたら?ってだけです。
私は技術者育成の視点より、とにかくやってみたらいいじゃん派です。RoRを推奨している勢力と似た思想だと思います。
その上で、RoRは学習コストが高すぎて、勉強するだけじゃ使いこなせなくて、ならいっそピュアPHPでもやれば?と思います。
プログラミングの勉強したい=>Railsがいけてるらしいからそれを勉強しよう
ってのは絶対続かないし身につかないから辞めたら?って思います。
全然DRYじゃなくて恐縮ですが、
「プログラミングを勉強し始めよう、まずはRailsから」って考えている人は、きっと半年後も一年後も何も身につけていないだろう。と。
フレームワークのマニュアルを言語やアーキテクチャへの理解なしで読めるのはクイックスタートまででそれ以上になると知識は必須になると思います。
特に必要ないとおっしゃる方々はググったりコミュニティで聞いたものをそのまま実装して問題があった場合はどうするのでしょうか?
先生が言ってましたと言う小学生のような言い訳をしますか?
プログラミングの話というよりモノを作る姿勢の問題のように感じます。
あー、こういうこという古いひといる。。。。
rails, cake、その他フレームワークはどれも利点、欠点がある。それに、、、決してrailsは早くないw むしろ遅い! だけども利点をとってframeworkを利用するとによって、コストを抑えたり、開発者間のプログラムの癖をルールでしばって、品質をあげる目的もあったりする。
むしろ、スピードが、、、とかいうなら、JAVA,C,C++などでくんだ方がいいかと。。そして、JAVA,Cなども開発コスト面からみたらいくつか難点がある。
rails, cakeは使うな!
というのは、あまりに言葉足らずな説明だ。。
CTOではなく、CEOなので、もの作りや技術に関しては疎いのだとは思うが、
偉そうに人に講釈足れる前に、自分を見つめ直すところから始めた方が良い。
まー、みなそれぞれの思いや考えはあるとおもうが、
railsなどまだ割と最近の今後のびる可能性がある技術を前向きに勉強している、技術者をあなたの用は無知なCEOが潰してしまわないことだけを願います。
古い人だとよくコメントされますが理由が分かりません笑。学習コストが高すぎて多くの人が物を作る前に学習で頓挫してしまうFrameworkだから最初は学習コストが低いFrameworkでモノづくりの楽しさを感じた方がいいんじゃないかなと思っているだけです。
この記事の読者対象は技術者ではないですよ。これからプログラムを勉強しはじめようという、ゼロベースの人です。
ぜひ記事だけでなく皆様のコメントも見てみてください。
こんばんは。私はプログラミングのプの字も知らず、出来ず言語の名前を知っているだけの人間です。
タイトルは釣りのようで、感性の問題ではありますが好きではありません。しかし、ド素人の私でもこの記事はとても示唆に富むものですね。
[…] 今すぐ辞めて欲しい、「Ruby on Rails勉強してます」「CakePHP勉強してます」というエントリーもある。若者がWebアプリケーションを開発するにあたってrailsやcakeから入るのは逆に遠回りだ […]
大いに同意です。
批判多くて驚きです。批判ではなく議論の提起、なのかもしれませんが。
みなさん言い方きついですねえ。小心者の自分なら萎縮してしまいそうです。
私が大阪弁を怖く聞こえてしまう事象と同じで思い込みかな・・・ブログ書くの怖くなりそです。
本題に戻りますが、本件の課題はおそらく一人、少人数で製品を作っている間は大して問題にならないのかもしれません。しかし、大人数のプロジェクトとみたときに発生するコミュニケーションロスとしては看過できないと思いますので、大いに同意する気持ちです。
初心者が悪いとか、ベテランの初心者への理解不足の良し悪しとか、製品リリースという観点からは本質ではないのでおいておくとして、
ベテランにとって当たり前のことが、初心者には当たり前じゃない。ここで生じる誤認がプロジェクト進行の後工程まで残留してしまう可能性を考えると「使うな」くらいが論調としてちょうどいい。
製品やユーザの目的からすれば、新しいからいい、枯れているからいいとかじゃなく、技術はいつだって中立です。正直なんでもいい。(もちろんメンテコストなんかもあります。それだってスキルセットの調達の問題が無視されがちなのはいつも気になるところ)
つまりプロジェクト全体で「当たり前」を統一できていればうまくいきやすいし、
統一できていなければ思わぬところで足をすくわれやすい、ということです。
その観点から、既存のCREATE TABLE構文は割りと常識の域だと思いますので、問題になりにくい。
Rubyはおっしゃるとおりブラックボックス化が十分な域には達していないのに、
十分ブラックボックスだという誤認から生じるロスが問題なのかもしれません。
何熱くなってるんだろな。。。
ちなみに私はRubyを使ったこともなければ、中身も良く知りません。
cakephpのsession管理に関して理解を深めようと検索していてたどり着きました。
「初心者」という意味でしたら同意致します。
簡単なものならPHP+Smartyなんかで書く方が早いので、自前のなんちゃってフレームワークで書いたりします。というより、2~3日で終わるような簡単なWEB系のものを一人で書くなら未だにこの方式ですね。
ただ、案件によってはフレームワーク各種を使う事も稀じゃありませんので、相応の学習コストは掛けています。
フレームワークに初めて触れたとき、それまでSQLを手書きで書いていたものが、ほんの数行で実行されてしまう事に大きな不安を感じました。SQLに限らず様々なものに不安を感じていましたねぇ・・(^-^;
私のようにフレームワークが一般化する以前に手書きでコツコツ書いてた人間からすると、内部で何が実行され何を吐き出しているのかが見えないと、怖くなるんですよね。
ただ、初心者であれフレームワークを覚えていく事は今の開発現場で必須条件だとは思います。それに伴う学習コストは会社/プロジェクト単位で担ってくれるかもしれませんが、根本的な理解を深めるって部分は、やはり自分で学習するしか無いのかもしれません。
その時間を作れるかどうか、その意識が芽生えるかどうかって事じゃないでしょうかね。
そもそもフレームワークにおいて、そういう知識の補完まで完璧に担えるように進化するなら、必要無いのかもしません。
WEB屋の手書きHTML→CMSって流れに似てるなぁって思います。
完全に同意はできないけどFrameworkを使うんじゃなくてFrameworkに依存するようになったらダメだよね。
Frameworkに依存してる自称プログラマが多いのなんの。
全てとは言わないけど一度ネイティブで実装してみるとFrameworkの恩恵がわかってFrameworkを「使える」ようになるんじゃないかなと。
ネイティブって言うとアセンブラで~って言う人もいるけどそこまでいくとただの揚げ足取り合戦になるからそこまあくまでピュアPHPなりrubyなりってことで。
Framework使って作ったものと同等のものをネイティブで書けるようになれれば一番だね。
最終的には、どう学んでいくかは、各個人の経験や力量の問題だと思います。
フレームワーク自体が仕事の場合は、初心者でもいきなりということがあります。
必要なら、必要な部分を自分で補っていかなければという話で、それは各個人がプログラマとして成長するプロセスであり、やるかやらないかの問題だと思います。
「なにごとも簡単に匙を投げるな。理解できるまでのプロセスのほうが大事だろうが。」
そんな親父の声が聞こえてきました。
必要なものが足らなければつまずくし、必要でなければうまくいくし。という自分の経験からの感想でした。
ps。 一番の問題は、今から学ぼうという人に全否定のように見えるタイトルかも。。
だいぶ前の記事ですが拝見させていただきました。
大方同意です。frameworkがどのような動作をするか、というのは知っておくべきだと思います。
でも初心者がframeworkから勉強するなというのは、あなた個人の意見を押し付けているだけに感じました。
別に初心者がframeworkから初めてもいいのではないでしょうか??
cakeやrailsといったframeworkを使うにしても、phpやruby、データベースの知識は必要になると思うからです。
確かに初心者がいきなりそれらの技術を習得するのは難しいことだと思います。
でも、あなたがプログラミングを学んできた時代とは違い、今はcakeやrailsといった便利な道具が出てきた。
便利だから使う、そういった自然な流れでプログラミングに触れることができる時代になった。
それだけの事ではないでしょうか?
[…] 今すぐ辞めて欲しい、「Ruby on Rails勉強してます」「CakePHP勉強してます」 […]
[…] 今すぐ辞めて欲しい、「Ruby on Rails勉強してます」「CakePHP勉強してます」 […]
昔の記事ですがコメントなどが今も書き込まれているようなので意見を言わしてもらうと
frameworkに依存しているとframeworkでは対応出来ない仕様などに対しての対応力などがないから二流プログラマーしかなれないのでおすすめ出来ないし現場じゃ役に立たないからね。
まあRORとかで作る物ならそんな特殊な仕様とかないだろうからframeworkに依存しても大丈夫だけど仕事だと出世はしにくいからちゃんと内部は覚えた方がいい
要するに「フレームワークを勉強することと 言語を勉強することは違う」ってことかと
ほんと 言ってることはそんだけかと
反射的に反対意見書いてる輩が多くて笑った
理屈ならべてるば かにも笑った
そんなの相手にいちいちまじめに答えなくていいと思うよ
言ってることがおおむね正しいかどうかなんて経験と直感でわかろ
わからんやつはプログラムやめてほしい
フレームワークは使用したほうがいいでしょう。一から作るなんて時間と金と人生の無駄です。
そのフレームがメンテナンスされなくなったら、別のフレームワーク
で作り直せばいいだけです。
私を含めほとんどの人はどうせ大したもの作ってませんから。
初心者ならフレームワークを使って作れる喜びを知ってもらうのもいいことだと思う。
そこからじゃあフレームワークはどうやって動作してるんだろうと、発展させていくトップダウン型でも全然問題はない。ただそこで、フレームワークの中身なんてどうでもいいやってなったらそいつは終わり
とても興味深く読ませていただきました。
railsを使っても、基本ができていないといけないのですね。
フレームワークを使う前に、基本をしっかり学ぼうと思います。
ところで私は今大学院生で、webサービスのサイトを作るためにプログラミングの勉強をしているのですが、
初心者がコードを書くのにおすすめのプログラミング言語はどの言語だとお考えですか?
最近、rubyを使おうとしていたのですが、フレームワークについてのこの記事を読み、そもそもプログラミング言語はどれがいいのかと疑問に思いました。javaとかpythonとかですか?
javaは一応入門書を読んだのですが。
コメント、ご質問ありがとうございます。
まず基礎を勉強すべきかどうかについては、しなければ作れない、と考えております。フレームワークの入門書等はそのフレームワークが簡単であるように書いてありますし、そう感じられますが、記載されていること以外のことをしようとすると、多くの人が躓いてしまいます。
言語としておすすめなのがあるわけではない、どの言語もおすすめなのですが、ウェブサービスを作りたい、ということでしたら、PHPでサイトを作ってみるのはいかがでしょうか?フレームワーク等は使わず、自分が必要だと思う機能やデザインだけを実装していってみると楽しいと思います。
なぜPHPかといいますと、PHPではそういった用途の入門書が多く出ているためです。他言語ではフレームワークありきの物も多く、作りながら学ぶのに適切な本、サイトなどでは、PHPが恵まれているように感じています。
その後は、使用用途に合わせて、フレームワークや言語を選んでいくのが良いかと思います。その時のことはその時に置いておいて、今はぜひウェブサービス作りを楽しんでくださいませ!
非常に賛同できる内容でした。
私も知識のない新人がフレームワークから学び始めるのは非常に危険であると思います。
フレームワークの内部で行われている根本的な動きを意識することができたとき、
フレームワーク内部で行われている根本的な動きを意識しフレームワークを使いこなせるようになるのではないでしょうか。
知識0の友人が某IT系会社に入社したのですが、はじめにならったのがCakePHPだと聞いて驚きました。即戦力が欲しいのはわかりますが、多くの過程をすっ飛ばし過ぎではないかと思いました。
根底の知識がないと伸びしろにかけるのでは…
うーん、プログラミングについて浅い知識で終わってほしくないというのはわかるけど、だからといってスタートダッシュ切ったばかりの初心者の人にFramework使うのやめろ、っていうのは無理でしょ。というかいきなり挫けさせて一体何がしたいのか。正直、この記事は経験者の賛同を得られはしても、初心者の助けになることは一切ないね。
まずは便利な道具を使って、とりあえず何かしらフィードバックの得られるものを作って、プログラミングの楽しさ・達成感を味わってから、その道具の仕組みを知ればいいだけの話であって。
「俺はFrameworkなんか使わない、使うとしても理解してからにする。」……それは中級以上のプログラマなら当たり前のことでしょ。そんな当たり前のことを初心者相手に押し付けて、自分は同レベル者の賛同を得ていい気になって、これほど痛々しい奴はいない。
それと、なんかフツーに二次萌え本推してるけど、そろそろそういうねじ曲がった観念押し付けるのやめたほうがいいんじゃないかな。可愛い云々が教えてくれるとか、普通に気持ち悪いし、例え萌えでなくても偏った信念を押し付けられるのって、押し付けられる人からすれば結構不快なものだというのを理解してほしい。
批判ではなく代替案を示してくれると私含め皆さんのためになると思います。
私はPHP言語は十分便利な道具、楽しさを得られる道具だと思いますよ。iOSやAndroidなどのよりリッチな体験をすぐに得られるタイプのプログラミングも楽しいと思います。Arduinoを触ったりするのも楽しいですね。
RailsやCakePHPなどは「MVCとはなんぞや」や「attr_accessor」「db:migrate」など、Frameworkのために覚えることが多すぎて、プログラミングの楽しさ・達成感を味わうための障害になってしまうだろうと個人的には思います。ですので、「いきなりはじめるPHP~ワクワク・ドキドキの入門教室~」などから始めるほうが楽しいかな?と思いますね!
私は「jQuery勉強してます」が、JavaScriptやDOMの理解が浅くて苦労したことがあります。
RubyがわからないのにRailsを始めなくてよかった。
ありがとうございます。
おしなべて学習とは、トップダウン方式でもダウンアップ方式でも、”没頭”さえできれば、いずれはおのずと網羅的に学習してると思う。そういう意味では反対もしないが賛成もしない。ただ、その形骸化した思考には強く反論したい。
近い将来、Railsから始めて夢中になって(もちろん、全員とはいわないが)、必要に応じて様々な技術や知識を否が応でも身につける者がいるであろう。
その夢中者にとっては、その他の技術や知識の習得はもはや努力ではなく、希望でしかない(努力なんて相対的だからね)。
楽しい、便利だという信念や予感をrailsで一旦感じる者がいて、そっからRubyだのActiveRecordだのSQLだのCoffeeScriptだの必要に応じて徐々に学習する状態は、もはや本人にとって努力ではないだろう。
そしてこのブログの作者の力量を超す若者も多く出てくるだろう。その時、あなたは(というか少なくともこの記事は)古い頭の持ち主といわれる。なので、タイトルの頭に「(楽だろうと勘違いして)今すぐ辞めて欲しい」と添えるべきだ。
最新の技術から入って、夢中になってプロになる一部の者もいれば、途中で脱落する多くの者もいる。ひとつ言えることは、いつの時代でもその次代の最新の技術に夢を抱いて没頭することからはじまる。
ピッチャーになりたきゃジョギングとシャドーピッチングからはじめろ。それまでは決して決して投球するな?それに地道に従ってプロのピッチャーになれる者がいるだろうか?否、最初はめちゃくちゃでも、がむしゃらに実践しつつ都度学んだ者が結果、プロになっている。もちろん、シャドーピッチングに夢中になって、いつの間にか140キロの投球ができるようになって、それでプロになるパターンも否定しない。
繰り返すが、要は本人が何に没頭できるか、だ。
保守的懐古主義は”自分以下”は育んでも、”現状を超すもの”は育成しないであろう。
いいたとえするねぇ。
教習所でF1 専門家 毎週チューン わたし教習生
Web開発は日進月歩が半端無い。
勉強尽くしで仕事になるのかといいたい。だからこそ、ほにゃほにゃ、ふにゃふにゃ。
はじめからある、世界地図を全て覚えてから旅をするのか。
それとも、自分で世界地図を作っていくのか。
前者は旅に出るまでが長くて、旅に出るまでに死ぬ重い腰の人。結局たいしたものを作れずに終わる。会社に言われたものなら作れるかも。
後者は、予め設計書だけ作成して、自分で地図どおりに町や地形を作っていく。
私は、10年以上もPHPを使っていますが、特にフレームワークに恩恵を感じたことはありません。
ジェネレータは自分で作れますし、各種ライブラリも調達できます。
また、監査に引っかからないようなセキュリティの仕組みも調達できます。
作るプログラムの主要なパーツは全て同じです。
速度は速いです。
普及したら新たなバージョンができるフレームワークベンダーの戦略にハマることがそんなに恩恵なのかと思います。
大体のPHPコードは読めるので会社で作っているものにカオスさを感じません。設計に慣れていれば、どのコードなのかは見ればすぐわかります。規約は大切だと思いますが。
各種設計書は必要です。
ここ7年はZend、Symfony、Cakeをいじってきました・・・国内で良心的なのはCakeだと思います。資料も豊富で把握しやすいから。しかし、BAKEに恩恵を感じません。
他のフレームワークに手を出すつもりはありません。より良いフレームワークがあったらそれに絞るつもりです。維持が大変ですから。
ちなみに、Cakeをマスターしたと思っている新人は多い様子です。
彼らは部分的な作業しかしないので、ある新人はビューだけいじって、Cakeを経験した気になっている。
有る新人は、モデルだけジェネレートして、Cakeを覚えた気になっている。
それで、Cake・・なんだ簡単じゃんってなる。
フレームワークを深く知りたいのであれば、セキュリティの仕組みやシステム管理、監査に耐えうる機能が何なのかを知るべきだ。ソフトウェア工学上どうして、そうつくっていくべきなのかどういう思想のもと作られたのか。表面上のシステムだけでなく、裏方の機能がどうして必要なのかを知ってから、その恩恵を知ればよいと思います。しかし、世界地図を全体を覚えないと旅ができないのは不便といえば不便だ。個人で作るようなイノベーティブプログラミングには向かない気がする。
今更ながらすごく同意
自分の例だと、最初平phpでひどいコードの2ちゃん風掲示板を2日で作り、きちんと動くものがこんな簡単に!という感動があった
その後CakePHPで求人サイトを作り、学習期間含め簡単なシステムに2ヶ月かかった
最初の作れた!という感動と、なぜわざわざフレームワークを使うのか?という明確な理由を認識できたから心が折れなかったと思う
単純な話(MVC)フレームワークを使うためには、「動くものを作る」能力に加えて、オブジェクト指向の理解、MVCの概要理解、フレームワークのお作法の理解が必要。Railsは周辺知識もいろいろいるし
知識0の状態から誰にも強制されずにサービスを作る経験を持ってるかどうかで記事へのリアクション変わると思うんだよね。その時は「最短で質の高いコードを書けるようになること」より「心折れずに完成させること」が何より大事
だいぶ前の記事ですが、記事の内容も同意でき、今までの多くのコメントからすごく良い議論になっていると思います。
私はRailsは触れたことはなく、主にJavaScript系を触っていますが、JavaScript界のフレームワーク(特にフロントエンド)は、派生や種類が多く、どれもオレオレ感が出ていて、今時点では本当に混沌としています。
Express.jsで開発していたと思ったらいつの間にかAngularが出てきて、Angularを触り始めようと思ったらReactが出てきて、終いにはAngular2.xには期待できないなどの声も上がったりと、完全なフレームワーク地獄に陥っていると思います。
フレームワークに依存し過ぎると、本当にそれが無いと何も出来なくなるのは、初級者にはよくあることです。
また、JavaScriptフレームワークによっては、ES6、ES7に対応しているなど、JavaScript(EcmaScript)自体の仕様を深く理解していないと、それが何のメリットがあるのか、逆にそれが対応していないと何がマズいのかの判断すら出来ません。
本記事は、フレームワークを使うなら言語自体を理解しておく、フレームワークが使えなかった場合のメリット、デメリットを綺麗にまとめてくれていると思います。
フレームワークは、基礎をつけた上でデザインパターンを学ぶにも適切だと思う。
またPHPは動きがとても早いので(言語仕様やコード規格)、最新の動向をつかみ、キャッチアップする意味でも、フレームワークは有用だと思う。
私はvisual basicから始めましたが、その頃はcとかのポインタ分かっていないでプログラムをするのはけしからん!!という風潮がありました。
それと同程度のような気がします。
便利な物は使うべきだし、好奇心旺盛な人は勝手に勉強するので、ほっとけばいいです。
我々は何の為にコードを書いて、システムを構築しているのでしょうか?
技術の為の技術という技術者思考が強すぎるといい物は作れなくなるように思います。
webアプリケーションの勉強をしている者です。
記事、とても参考になりました。
ただ、「フレームワークでできること」を一度体験してみるのも悪くはないかなと思います。
それで「この言語を学べば、こんなすごいことができるようになるんだ」と感じられれば、
その後の学習意欲が高まるのではないでしょうか。
これだけタイトル見ただけでカッとなっただけの反論を丁寧に返している筆者様はすごいですね。
というか筆者様の返信を2~3件読めばこの記事の本質は分かると思いますが、
それでも極論出して批判しようとする人がいるのが逆に感心してしまいます。
まあこの記事で注意喚起されているケースにはまっている人は無意識に頭に血が上ってしまう
ということでしょう。
自分の専門分野よりも少し根源的な部分まで知って余裕を持っていないと、その分野の専門家にはなれませんよね。
でも、自分の専門分野よりも、ずっと根源的な部分まで知る必要はそんなにないわけです。
このことから、自分の専門分野より少し根源的な部分まで知る必要がないという結論に至るのはおかしいと思います。
RailsやCakePHPを使うなら、それらより少し根源的であるPHP,Ruby,DB..を知っとけという記事で、納得でした。
[…] 今すぐ辞めて欲しい、「Ruby on Rails勉強してます」「CakePHP勉強してます」 […]
ぼくはプログラミング歴2ヶ月の者です。
貴サイトの当記事を2ヶ月前に読んでから、疑問に思いながらも某オンラインプログラミング塾でRailsを学んできました。
ですが、今となっては、貴サイトに書いてあったとおり、プログラミング初心者にRailsは重すぎました。
今後は基本に立ち返り、JavaScriptやRubyなどといった基礎の部分から、地に足のついたプログラミング学習をしていこうと思っています。
示唆に富んだ記事、ありがとうございました。
一応、プログラミング初心者が2ヶ月Railsを学んでみて感じたことをブログ記事にしましたので、興味があれば読んでみてください。
http://sorehito.xyz/rails_is_not_programming/
ほんと、あなたは偉いですね。
ここで、必死になって、フレームワーク論とかコミュニケーション論とかの信者になってる人に対して、よいお薬になるでしょうね。
フレームワークもコミュニケーションも単なるプロパガンダ、教祖の言葉でしかないことに早く気づいてほしいです。
それと、私はシステムアーキテクトという資格を持っているITコンサルタントでストラテジストと技術士二次試験の受験を控えているものですが、
戦略的な話をすれば、
仮に、PHPの供給が10000として、フレームワークがこの世に7個あったとしましょう。
PureなPHPerが3割、フレームワーカーが7割いたとすると、各フレームワークカー・グループは、平均で10%の供給しかできないですね。
つまり、個々のフレームワーカーらは1000しか開発力を供給できない場合、どうやってその10000人中1000人を選別して、プロジェクトに参加させるかという話です。
「CakePHPer募集」なんて書いたとしても、Phperのうち10%程度しかマッチしないわけですから、フレームワークが多くなったことで人材を集めづらくなたという難点があります。
「PHPer募集」などと書く場合、その10000人を対象にすることになりますね。
従来のPureなPHPだけでしたら、その10000人を対象とするわけですから、簡単に人が集まるという利点があるわけです。
また、問題解決能力は供給力が10:1だからといって、10:1になりえません。ランチェスタ戦略によれば、数的圧倒有利ですから、100:1になります。
フレームワークはスタンダードがありませんから、流行に流されやすく、できては消えるの繰り返しです。
ですから、国で認定する国家試験でもフレームワークはほとんど触れられることはありません。目の上のたんこぶのように相手にされていません。
また、ベンダーロックインの主な要因にフレームワークがあります。そのひとつの要因にデータ構造がフレームワークに依存するなんて問題もあります。
また、ある自社サービスを行う企業では、Symfonyというフレームワークを導入していますが、
このフレームワークもジェネレーションができるという利点だけで、むしろ煙たがられています。
10年勤める担当さんも「修正が簡単にできない」といって毎晩終電までこの問題を解決することに費やされています。
Symfonyベンダーが、指導者を派遣し大儲け。
こういった観点から見ても、実際には、フレームワークは効率化(コストダウン)をしていないだろうと考えられます。
フレームワークで実装できる個々の機能も実は、PureなPHPの書き違いでしかないです。
また、システムアーキテクト試験では、アプリケーション・フレームワークについての問題点として、
個々のフレームワークの学習コストという重要な問題点が出題されることがあります。
フレームワーク・ビリーバーに多いのは、「学習コストなんてたいしたことがない」という文句ですが、
それは、フレームワーク・ビリーバー達が実は、1つ2つのフレームワークしかいじったことがないための知識レベルに問題点があると考えられます。
たいてい、「こんなのたいしたことがない」という、シニアぶった楽観論は後工程で自分で自分の首を絞めるのみならず、その仲間の首まで絞めることになるでしょう。それは、仕事にしろ勉強にしろ「こんなのたいしたことがない」とか、「1週間でできる」などの見栄にあります。
また、プロジェクトマネジメントの視点から言わせてもらえば、工数を営業が見誤るだけで大きく、システム会社の経営が傾くことがあります。
営業が見誤ってしまうのはスキルが無いからですが、エンジニアが見誤ったら終わりですねw
アーキテクトが、フレームワークの選定で予想工数を見誤った場合大変なことになります。
つまり、フレームワーク・ビリーバーは、フレームワークの選定を行ったことがなく工数を過小評価する場合、
希望的観測にて導入コストを算出しただろうってことです。
彼らは、まともなITアーキテクトには一生なれないかも知れません。
フレームワークは個々において学習コストがまったく異なります。
新しくて資料の乏しい技術ほど、手探りになります。
近くにフレームワーク・エバンジェリストでもいればよいですが、期待できません。
天使様がいれば、信者も大喜びでしょう。w
しかし、この世に神も仏もいませんからw自分で天国までいくしかありませんね。
資料が無い場合は、5倍の学習コストではすまないでしょう。プロジェクトは確実にポシャります。
フレームワーク論者とコミュニケーション論者に多いのは、風評に惑わされやすく、風評を流しやすいです。
それは伝染病のごとく、「みんなが言うから」「偉い人が言うから」「ネットに書かれているから」などといった主張の主張を繰り返し、
論理的な視点や統計的な視点で物事を見れない人です。
それは、太平洋戦争時代のプロパガンダを偉い人が言うから、みんなが言うからといって簡単に信じた民衆と同じです。
当時、分析家の言葉はことごとく、「間違っている」という風評を流され、口封じをされました。言論統制の典型です。
10年くらい前なら、初級シスアドは簡単などという言葉をよく聴きますね。
それで、実際にガチで半年研修させてみて合格した人はほんの1割しかいなかった企業も見てきていますが
それと、同じで風評に惑わされて正確性を見誤った評価をしているという点です。
もし、あるフレームワークの利用者が1人しかいなかったら、フレームワークの意味はありませんね。
名ばかりフレームワークです。効率化も糞もありませんw
多様化してしまい、フレームワークの意味が無いって話を耳にしますが、まさにそういう意味を内在させているのです。
パフォーマンスが云々を技術力の増強で補うことができると問題点を解決したつもりになっていますが、
それだけが問題ではないのです。
あくまで、パフォーマンスの問題かつAかつBかつCと条件がひとつの論理積でなりたっているのであり、
論理和ではないですから、個々の問題に言い返すのではなく、すべてひっくるめた条件式に言い返す必要を、あなた方は都合よく無視しているのです。
フレームワークは格好いい、フレームワークを覚えればスキルがあるように見せることができるってのは、単なる見栄でしかありません。
感覚的なものに惑わされすぎです。一から基礎的な学習をやり直すべきでしょう。
[…] 識が甘いままエンジニアになってしまうと、エラーが起こった場合に、迅速な対処ができなくなってしまう恐れがあります。 参考記事:今すぐ辞めて欲しい、「Ruby on Rails勉強してます」 […]
初めまして。
自分もあなたが言う「よく分からないまま ruby on rails が便利だから始めた」輩です。
今自分で簡単なプログラムを少し作れる段階になって、それでこのサイトを見てみて、あなたの意見に共感できる部分と共感できない部分があると感じました。
私が共感できる部分は「どう動いているか中身が分からないから危険」です。
自分は先述した通りまだ少しプログラミングができるだけの段階なのですが、確かに、railsをつかってみても、中身がどう動いているか分からないと感じる時が多々あります。
違うプログラミングの言語を触っていればもしかしたら「あぁ、この難しい記述がこんな風に簡単になっているのね!」となったところも、自分には正直ちんぷんかんぷんです。
ですけれど、こうも考えられるのではないでしょうか?
「そこで何が起きているかを自分で調べられれば、自分で問題を解決しようとする根気があれば無駄ではない」
知識が身につかないのは「便利な機能に慣れて思考を停止してしまっている」からであり、それを自分で調べたり理解しようと努力をすれば、ruby on rails を学習することも無駄ではないのではないでしょうか?
とまぁ、まだまだ自分の考えが浅いことは否めませんが、私はそう感じました。
[…] 【参考】今すぐ辞めて欲しい、「Ruby on Rails勉強してます」「CakePHP勉強してます」 – sumyapp […]
感銘を受けました。
私自身WebやDBのことはよく知らないままrailsの本を購読していました。
何も分からないままフレームワークを使うというのは確かに不自然な話ですね。
おっしゃる通りだと思います。
知り合いにも’railsは技術が身につかずに達成感だけが得られるから良くない’と言われてました。考えものですね。
コメントにもひとつひとつしっかり返信してらっしゃって良いと思います!
かなり同意見です。
最近「小中高生向けのプログラミングスクール」なんてのがあるんですが、そこでもRuby on railsから説明をし始めて、それ以前の基本的な構文についてはあまり教えない。
そして教材が用意されてるので、その型通りに書けば済んでしまい、身につかないなんてことがあるらしいです。
それはそれで問題なんじゃないでしょうか。
Rubyを習得したく、指南書を探していたところに出会いました。
おっしゃる通りだと思います。javaを学ぶ際に初めての言語だったためよくわかっておらず、すべてメモ帳で行っていました。
時間もかなり掛かり、eclipseなどの存在を知った時は絶望に近いものもありましたが(笑)その分深く習得出来たと感じております。
初心に帰ることのできる記事をありがとうございます。
今すぐ辞めてくれ、というのは無責任で極端な言い方だと思いますが、「じゃあ、君はRubyはできるの?」「PHPは理解しているの?」と前提の質問をしているならまだわかります。
いずれも、基本的な文法なり、OOPとして組めるだけのことがわからないと、フレームワークを使ってもまともに作れないと思いますけどね。
記事、各コメント、勉強させていただいています。
私からもひとつ、言語学習におけるフレームワークの利用について感じたこと。
言語自体のスキルも大事ですが、
”どうアプリが構成されるものなのかを知るために”…言い換えると、
”抽象度の低い具体的なアーキテクチャ(運用や便利機能を含める)”を知るために、
初学者がフレームワークに触れる必要はあると考えます。
また、OOPなどの理解の助けや、練習場としても良いのではないかなとも。
他のフレームワークで役に立つ知識かどうかについても考える…っていうのが、
ハマっちゃわないためのひとつの観点かもしれません…なんて。
初心者という言葉の厳密な定義をした方が良い。それがもし全くプログラミングの概念を知らない者という定義であるならば、同意できる。
Rubyという言語範囲内でも根本的な理解がないままフレームワークによる抽象的なプログラミングを学び進めようとすると、少なくともそのフレームワークの枠の中に縛られることは間違いない。
単純に勉強なんだから楽しないで、ちゃんと言語の基礎から学びましょうよっていう話だと思うんだけどなぁ…
「ruby on railsとかCakePHP使ってます」がダメだとは一切言ってない気がするのに、なぜこうもコメントがカオスなことになるのか…
[…] 炎上した有名なこの記事 今すぐ辞めて欲しい、「Ruby on Rails勉強してます」「CakePHP勉強してます」 読ませてもらって、タイトルの言い回しが悪かったなぁと思う記事だった。 炎上させ […]
[…] 炎上した有名なこの記事 今すぐ辞めて欲しい、「Ruby on Rails勉強してます」「CakePHP勉強してます」 読ませてもらって、タイトルの言い回しが悪かったなぁと思う記事だった。 炎上させ […]
自分はバイクに乗るのですが、いきなり大排気量の何もしなくても速いバイクに乗っているが、基本が無いが故にイレギュラーに対処できず、逝ってしまった友人が数人います。
そういった不幸な事態を防止するための苦言だと認識しました。ありがとうございました。
[…] 今すぐ辞めて欲しい、「Ruby on Rails勉強してます」「CakePHP勉強してます」 […]
webアプリケーションを作るための前提知識やライブラリがここまで多くなった近頃なら、
むしろrailsなんかを使って「とりあえず作る」から始める方がいいと思うけどなあ。
バラバラに知識を入れていって、ふわっと理解してから細部を調べていく方が挫折しにくいし学習速度が速いと思う。
非常に気持ちがわかります。
これはフレームワーク全般に言えることですが、「これをこうすればこうなる!!」と理解できますが、なぜそうなるのか分からない状態です。
Ruby on Railsを扱って超便利やん!!と思いますが、プログラムを初めて扱う人にはまったくチンプンカンプンだと思います。
フレームワークのウリで必ずといっていいほど、「プログロム知識がなくても作れる」的なブラックボックス化の度合いを示した言葉が書かれてるけど。あれもどうなんでしょうね。
最初に動くもの作れて、そこからプログラムに興味をもってもらってってのも凄く大事だとは思いますが。
Railsは基本的に言語自体のメタプログラミング等、高度なテクニックとネットワークやデータベース・CSSやJavascriptまで熟知していなければ、使いこなせないほど、Rails自体やその周辺のGEMも高級なテクニックが利用されています。
※ 要するにとんでもなくBlackBoxになって恐ろしい(素人は感じないと思うが)
単純にRailsを使う範囲では良いのですが、本当に使いこなすという意味では、Railsなんて勉強しても意味が無い。
使いこなすには、かなりの学習が必要だと思うし、その学習はRailsなんて勉強しても身につかないと思う。
はじめまして
古い記事ですが、探し物をしていてたどり着きました。
記事・コメントとも全て読ませていただいた上での感想です。
まず、『プログラミング初心者は安易にFWに頼るべきではない』という主旨には
賛意を示します。
【現段階においては】という但し書きつきですが。
一時期のコメントが噛みつきぎみだったのは、『プログラミング初心者の学習としては』
という主旨が記事から伝わってこなかったから(コメントまで読むと分かりますが)
なので、問題ないかと。
で、但し書きについて。
これって結局、【終端条件のない再帰下降】なんですよね。
以前、Pure Ruby で書いていて原因不明のバグに悩み、ついにRuby自体の
Cソースを読んだら言語自体のバグだったことがありました。
(Pure Ruby ならブラックボックスでいいとは限らない)
Cの標準が決まる以前(いわゆるK&R Cの時代)には、Cのポインタで躓いて
いる初心者に対して『やっぱアセンブラ知ってないとねー』というベテランも
いました。
『だったら、アセンブラまで遡れよ』ってのは極論。
確かに極論なんですが、そのアセンブラですら
【アセンブラなんて高級言語】 というひとたちがいます。CPU のマイクロコード
を書いているような人たちです。
さかのぼれば、トランジスタで加算器をつくるところまで行きつくでしょう。
逆方向を考えると、遠くない将来『え?フレームワークなんて、***低レイヤ***
こだわらなくてもいいじゃん』な時代が訪れる可能性もありうると思います。
御託並べましたが、『プロとして【どこまでは本質を理解してないといけなくて】
【どこからはブラックボックスでいいか】は、時代とともにどんどん変遷していく。
現時点では、たまたまそれがPure言語のRubyやPHP とフレームワーク
なんじゃないの?』
というのが私の感想です。
『学習目的だったらRails 使うな』、たしかにそうですが、私だったら
『学習目的だったらgem 使うな』まで言うと思います。
【車輪の再発明】はよくないとされますが、学習目的だったらむしろ一度
車輪を作ってみるべきです。きっと三角な車輪が出来てガタガタと乗り心地
の悪くすぐ壊れる車輪になるでしょう。
そこから学ぶことはとてもとても多いと思いますよ。
ps. すみませんが、mailaddressは記載したくない事情があるのでダミー
になっています。
が、見れば連絡手段は分かるようになっていると思いますのでご容赦を
昔のトピックですが、主張には全面的に同意します。
しかし……日本語入力に頼り切らずに、「やめる」を国語辞典をちゃんと引いてください。
このトピックの紛糾ぶりの一端は「辞めてほしい」というあまりに刺激的な
タイトルの誤変換によるものではないでしょうか?
基本を知らずにフレームワークに振り回されて碌でもない結果になるっていう
のと重なってみえます。
8bit機のVisualではないBASICから入って、機械語からJavaやPHPなど一通り経験を持つ者ですが、入門としてはフレームワークありきで良いと思います。
その先の思考停止がなければ、ですが。
プログラミングは言語ではなく物事を組み立てる力です。
言語、フレームワーク、ライブラリの類は伝達のための方法にしか過ぎないので、
理解しやすいところから始め、徐々に細かいところを覚えていくのがいいのではないでしょうかね。
単なる言語ヲタクだと、特定の言語やフレームワークがなければダメという事態に陥りますので、そういうのは元からプログラマに向いていないだけと思って諦めてもらいましょう。
かなり昔の記事ですが、面白いテーマなのでコメントさせて頂きます。
多かれ少なかれ、自分の作ったソースコードを何回も試行錯誤して作り直したりしていると、自分なりの定石って出てきますよね。どうやったら保守性が上がるんだろうとか、なるべく疎結合にしたり。苦労の結果身についた定石って単なるテクニックじゃなくて、思想が伴うから応用が効くと思います。
フレームワークっていうのはそういった知見や定石のアウトプットの集合体だと思います。一見使ってみたら開発が早い反面、初心者にはなぜそのように作ってあるのか、どんな課題を解決しているのかが汲み取れないことがあるも多いと思います。
この記事は、初心者がフレームワークを使って開発するのが当たり前になってしまい、その思想やプロセスをたどる機会が後回しになってしまうことを危惧しているのではないでしょうか。
試行錯誤して綺麗で保守性のあるコードを書くこと、自分なりにどんな設計が合理的なのか追求することもプログラミングの一つの醍醐味だと思います。
これはオブジェクト指向やMVCの考え方とも似ている気がします。
最初からJavaだと、手続きとデータをひとまとめにすることを、言語の制約として厳密に定めることがどれほど保守性に影響を与えるかが分かりません。
試しに自分でオブジェクト指向を使わないでグローバル変数ばっかり使ってそれなりのWEBアプリケーションを書いてみればどれだけ苦労することやら。ただ、そういった経験こそが大事ですよね。
議論が複雑化してしまうのは、ブラックボックスの話が混ざってしまっているからだと思います。
これに関して、コンピュータやプログラミングに限らず、物事を効率的に進めていくにあたってブラックボックス、あるいはホワイトボックス化を行うことは、どんなケースでも自明の理ですよね。通常、WEBアプリケーションを扱うエンジニアが発生した問題によってはフレームワークのソースコードの中身を確認しなければならないケースは割とありますが、アセンブラやハードまで扱うことはほぼありませんよね。
その意味ではフレームワークを扱う人は最悪中身を読めるひとが扱うべきとも思います。
[…] ていただきました! 今すぐ辞めて欲しい、「Ruby on Rails勉強してます」「CakePHP勉強してます」 […]
[…] 今すぐ辞めて欲しい、「Ruby on Rails勉強してます」「CakePHP勉強してます」 […]
Railsが、存在を忘れてしまうくらいパーフェクトに動いてくれるのなら、Rails上の開発で全く問題ないが、経験値を持たない場合は、全くそうじゃない。
初心者の場合は、治しようがないから、あるいは治しても時間がかかるから、ネットで断片の情報をかき集めて、gemなどバージョン変えてインストールし直したり、あてもない作業を延々と繰り替えして、やっとできたみたいなことになる。この作業は「開発」とは言えない。
こんにちは。私も開発経験は(かなり昔になりますが)ある人間ですので
昨今の「すぐできる!」「未経験者が2か月で仕事をゲット!」というWEB記事に
違和感を覚えています。
web開発の進展の速さのため深刻な人材不足が発生している問題は私も耳にしました。
確かに「cake PHP」や「ruby on rails」は便利なツールだと思います。
だけど、基礎を飛ばして「いきなりフレームワーク」は確かに、後々困ることが
あると思います。
そしてPG初心者に対して「これさえマスターすればオッケー!」と言い放つ
学習サイト、学校などの釣り広告が横行しているのも問題かと…
冗長な文になりましたが、結局「基本」→「道具」→「飛び道具」の道筋は軽んじてはいけないのでは? と感じたのでコメントしました。
私はこの記事を書いた管理者さんと同じ考えです。
Ruby on railsって、ユーザと意見調整するとき簡単に画面作ってイメージ持ってもらう時楽かなと思い色々調べている最中にこの記事を拝読しました。
私も超大昔は開発だったので、管理人様の言われることは、私的には「(ブラックボックス化されたものは置いといて)「ある程度」仕組みを理解しておかないと、なんかあった時に対処(解決)できなくなるよ。人様に納得のいく説明できないよ」と理解しました。
おっしゃる通りと思います。
ですので、その機能がどんな動きするのかソースをある程度追ってから使ったらいいんじゃないのと言われているのかと思って拝読しました。
「ある程度」は人それぞれですが、内容知っておかないとその感覚もつかめないわけで、そのためには中身を知る努力はしたほうがいいと私も思います。
サト様の言われていることもごもっともと思います。
多分仕事で使うことのなるんだから、プロとしてある程度理解しておかないとと思いました。
[…] 今すぐ辞めて欲しい、「Ruby on Rails勉強してます」「CakePHP勉強してます」 ただこの記事にあるように、railsだとwebサービスの本質は十二分には学べません。最初はrailsでも大丈夫ですが、 […]
[…] 今すぐ辞めて欲しい、「Ruby on Rails勉強してます」「CakePHP勉強してます」 […]
2chでもないのに、池沼なんて単語使っちゃう人のほうが池沼だよ
こちらの記事拝見しましたが、わからない技術をそのまま使うのは危険というのはわかります
ですがそれは提供された関数とかでも言えることで、
最初にRUBY ON RAILSから入ってものちのち覚えていけばいいだけでしょう
試しの何か作りたいだけ、業務に必要
色々な理由があるのに、そこらへんを全く考慮してない浅慮な考えだと
失礼ですが思いました
「Ruby on Rails」です。”RUBY ON RAILS”と書く人はおそらくプログラマーではないでしょう。半角スペースと全角スペースがどうして混じってしまったのか。
筆者さんもそうだが、皆、どれだけ間に受けているんだか。
「ウチの案件は、フレームワークこれこれですんで」って言われて
やったことありませんでは案件取れないでしょ!
「フレームワーク勉強してます」なんて、
そういう面接の場の言い訳でしか聞かないよ。
書くことないけど、無理矢理ネタを捻り出しただけでしょ。
これ見て、目から鱗です!気を付けます!なんて
どれだけいるんだよ。言わなくても分かってるって。
プロジェクトがそれ使うって言ってるんだからしょうがないでしょ!
『これからプログラミングの勉強を始めますという人から』の話なので、案件を既に他のプログラミング言語でやっている方については全く言及をしておりませんのであしからず。
自分は Servlet/JSP⇨Struts⇨Springと経験しましたが、確かに最初からSpringを取り掛かったらFWの背後が理解できなかったし、DIや ORMのありがたみもわからなかったと思いますね。(だからと言ってこれから Javaを習得する人にStrutsを進めることはありませんが)
初めまして。9月末からテックエキスパートに通っているものです。
Railsについて理解が深まりました。
ありがとうございました。
今後意識しながら学び、使いこなせるようになれたらと思います。
これから勉強する人に向けて書いた記事で辞めろって、人に指図するのってどうなの?
建設的にこうしたほうが良いって書いたほうがいいんじゃないの?
それにレスで問題が起きるコードを実行しろと言っててメチャクチャ。
なんでそんなに偉そうなの?人にとやかく言える人間なのか?
私はプログラミングを始める前、無駄にIT系の知識はあったが、Rubyとか Rails とかには手を出す気にはならなかったな。
なんでかというと日進月歩で変わるWeb技術の、しかも最も流行り廃りのあるWeb系のフレームワークを習得する学習コストの高さが、怖かったからだ。
結局、最近、Windowsプログラミングを学習して、まあそれなりのものは作ったな。
もちろんオブジェクト指向仕様の文法はちゃんと使って。
プログラミング歴は浅いが、工学系の学校にいたせいか文法仕様自体は特に難しいものではない。
ただ経験値が低いうちは、レベルの低い部分の文法仕様しか使えずに(使う発想がない)、汚いコードになるが、意識的に使うことを念頭においてたら、そのうち使えるようになった。
1つの言語を集中的にやったほうがええね。まあ、学習する年齢が遅かったから、もういくつもの言語に手を出す気がないだけなんだけど。
それでもプライベートでWeb系の御用を頼まれることがあって、しぶしぶ働かない脳みそにムチを打って、新しくJSとかPHPとかやってる。
JSはJqueryを使ってるが、PHPは標準ライブラリだけで書いてるな。
年だからフレームワークとかインストールするほうがめんどうなんよ。
私はWindowsプログラミングを最初に短期集中的に覚えたから、その経験ですが、
やっぱり最初は1コを集中的に、しかも「文法仕様をある程度使うような」「人に有難がられる(必要とされる)作品」をネタに、習得するのが一番いい気がします。
具体的にいうとライブラリの作成ですね(私の場合WindowsなのでDLL)
プログラミングの初心者は、まずライブラリの作成をお勧めします。
ライブラリと言うのは「プログラマが使うプログラム」みたいなものですので、アプリと違って「動けばなんだっていい」じゃダメで、インタフェースこそがキモです。
ですから結果的にある程度の文法仕様を使うハメになります。
最近、割り込み的にWeb系のことを頼まれてJSやPHPにも手を出し始めましたが、
とりあえず汚いコードを書き散らかして、「動くものありき」で進めてますね。
アプリ(またはWebサイト)だと、頼んだ人は「動けばいい」わけですから、あんまり勉強にはならないんですよね。しかも頼まれると「早くしなきゃ」と思うし。
とはいいつつ、そのなかでも悪あがきをしてリファクタリングとかやってますが。。
by プログラミング歴半年のアホな20代
職業がプログラミングと全く関係なく、お仕事のように「はよう動かせ!」のプレッシャーがないからこそ、焦りが無く、基本的なところから学習し、短期的に得れたのだと思います。
もし私がプログラミングを職業にしているなら、日々のタスクに追われて、 if やら for やらで、あとは framework の関数を突っ込んだり、それの延長で、何も身につかなかったかもしれません。
やはり新規学習には「ゆとり」が必要です。
これは個人的な経験ですが、職業でプログラムをやったことがなく、新しく学習使用としている人には、「文法を確認する程度の作品」ではなく、それなりに人が求める、それなりに時間をかけて作るソフトの作成を勧めます。
やはり自信につながるんですよね。いまホームページにWeb系のショートコードを備忘録代わりに書いてアップしてますが、
やはりこれの繰り返しだと、自信にはなりません。
ソフトを作ると成ると、文法学習というより、とにもかくにも(私のような初心者の場合)デバッグ時間が大半を占めますが、
その過程で、「今まで時間をかけて書いてきたが、どうも汚いな」とかいって、作り変えたり、そういった繰り返しで、だんだん「目が慣れて」きます。
ただ、この場合、肝心なのが作るソフトの題材の設定です。
つまり ver1.0 とか ver1.1 とかドンドン拡張することで、より需要に答えられるような題材を設定することが、モチベーションにつながります。
そうすると仮に便利な高度なフレームワークがあっても、「コードのスタイル」を崩したくないから、むしろ利用したくなくなるかもしれません。。
by プログラミング歴半年の初心者
メンドークサがりやで工学系の学校に居たくせに、プログラミングというのを一切しようとせず逃げまくってきたようなタイダーな私だが、
それでも新しく学習したときは会社が終わって18時過ぎぐらいには
(当時自宅にネット環境がなかったから)ドトールコーヒーに直行し、「前日わからんかった情報」はネットでサクっと仕入れて、あとはドトールがしまる21時まで、
そして家に帰って0時まで(5時間以上)
休日は朝から晩までとはいわないが、最低でも5時間、だいたい10時間以上は必ずやってた。
その大半はデバッグで、別に新しく覚える時間ではないが、やはり時間を掛けないと物事は覚えられない。
ところで Ruby ってそんなにいいんですか?
個人的に頼まれごとがあってWeb系のことをやるときはVPSでやってるので、ruby も環境構築は可能ですが、
「どんなレンサバにも必ず入っている」という理由でPHP(LAMP環境)で書いてるんですが・・
つーか、金曜日とか家に帰って、もしプログラミング始めると、
集中したらとまらなくなって、そのまま不眠で日曜日の朝(30数時間)連続でやってることとかザラにある・・・。
(ちなみに仕事で産業用制御プログラムを書いたときは楽しくて連続で40時間以上ぶっつづけでデバグしてたこともある)
意識高くて1000万円プレーヤーになる、とか言ってる人たちは30数時間とか、連続でやってるのかな。
フリーランスエンジニアの人月単価がだいたい80万円〜120万円ぐらいなので、普通にプログラミングできる人、なら売上1000万円年間はすぐいきますよ。給料として年収1000万円の壁は高いですが。
コードは書き始めるととまらなくなり、体調崩すから、週に3、4日程度だな。
作業1時間
↓
タバコプカー10分
↓
作業1時間
↓
眠気で脳神経が破壊されるまでまで永延とし続ける(翌日会社だろうが不眠不休)
↓
出社
この日は帰社後にすぐに睡眠(全く、寝ないと死ぬので)
↓
その翌日から同じことの繰り返し・・
1日おきにこんな生活をやってたら、「短期集中」でおぼえられますよ。
趣旨は理解できるんだけど、じゃあどこから始めるの? という話。
基礎的なものから始めて応用的な方向に進んでもいいし、
応用的なものから始めて基礎的な方向に進んでもいいと思う。
Railsを学んだあとにSQLを学んで、Railsでやってたあの処理ってSQLではこの処理だったんだと伏線回収的に学ぶのもよい。
自分がちょうど心地よいと感じるレイヤから学んで、興味のある方向に進んでいっていいと思う。
いまレイルズチュートリアル10章まで進めたプログラミング初心者です。初心者ながら、記事の内容に同意します。基本ができていないのに応用ができないのと一緒で基本的なプログラミングスキルが足りないのに、フレームワークを勉強しても限界があると思います。←今ここ
そこで質問なのですが、ruby on rails を使いこなせるようなるためには、なにをどう勉強すれば良いでしょうか?初心者にとって、rubyを学んですぐにrailsというのは飛躍しすぎな気がします。rubyとrailsの間にはなにが必要だと思いますか?よろしくお願いします。
© 2025 sumyapp