Web技術勉強会 2011/06/11 Ryuichi TANAKA/@mapserver2007/summer-lights.jp 初学者向けプログラミング勉強法
Web技術勉強会2011/06/11
Ryuichi TANAKA/@mapserver2007/summer-lights.jp
初学者向けプログラミング勉強法
ターゲット
� プログラミングの勉強がわからない人
� プログラミングが上達したい人
� 卒業研究を余裕をもって終わりたい人
なぜプログラミングがなぜプログラミングが
できないのか
なぜプログラミングができないか
� 第一印象が悪い
� 授業のC、C++、Javaで嫌気がさした人いるでしょう。はい、私です。
� 受身である
� プログラミングは主体的に能動的に学ばないと身につかないない
� 書かない
� 本だけ読んでも身につかない
� 作らない
� サンプルだけ書いても身につかない
どうすれば身につくのか
� その方法についてプログラミング歴9年くらいの私が軽くアドバイスします。
参考までに個人的経験を
� 私は大学のプログラミングの授業でほとんどなにもスキルをつけられませんでした。� 1年のC → わけわからん。つまらん。
� 2年のC++、Java → \(^o^)/ レポートは丸パクリ
� 3年前半 → プログラミング完全拒否。
� ====== ↑受身の時代↑ ======� ====== ↑受身の時代↑ ======
� ====== ↓独学の時代↓ ======
� 3年後半 → 独学でPHP+MySQLでシステムを作る� 初めはHTMLだけ、次にCSSを追加。その次にPHP。
� 本のサンプルをほぼ写して、ちょっとアレンジ
� Windowsでサーバをたてる(デスクトップPC)
� 4年 → PHP+JavaScriptで地図、自作システム。サーバはLinux化。OOPもとりいれつつ。
どうやって独学すればいいのか
� ここがわからないから困っているわけで。
� 今はいい時代であると。
� ぐぐれば大抵分かる。
� ソフトがほとんどタダで手に入る。
� ハードが安い。� ハードが安い。
独学するにしても、星の数ほどある技術のどれを勉強したらいいのか
� 技術と言ってもあまりに多いので絞り込む
� 絞り込みのキーは「作りたい物」� 作りたい物をまず決める
� 作りたい物に必要な技術はなにか。実はそんなに多くない。� 例:PHP言語の基本構文、関数、GET/POST� 例:PHP言語の基本構文、関数、GET/POST
� 「勉強のための勉強」は身につかない� このやり方はつらい。勉強してもすぐに発揮する場所がない。どうせ忘れる。受験勉強と同じ。
� 「ゴール」を決めることが最重要� 「○○なシステム」を作る!
� それに必要なことは☓☓だ!� じゃあ、☓☓を勉強すればいいじゃない。 → シンプル。
なぜプログラミングがおすすめか
� 無から有が生み出せる
� 自分一人でも生み出せる
独学が命
� 大学時代だけならなんとでもなるが、仕事でプログラマとして食っていくなら独学しないと生き残れない。
� 周囲のプログラムバリバリ書く人は100%独学でも勉強している。
� 私の仕事で使うスキルの90%は独学によるもの。� 私の仕事で使うスキルの90%は独学によるもの。
� 趣味化すれば最強
� 趣味なら独学という概念すらなくなる
� ついでに研究も趣味かするとあら不思議楽しくなる
� 書いてて、動いたら嬉しいと感じたことがあれば趣味化も遠くない?
どうやって独学すればいいのか
� 本気でプログラミングやるならこれは使うべし
� RSSリーダ
� ソーシャルブックマーク
� 本
� PC(開発環境)
� サーバ(運用環境)
� 手に入れていない、使っていないなら今日からすぐに使おう(手配しよう)
� 金はかかっても目をつぶる(安いし)
� 自己投資しない奴は生き残れない
学習のプロセス
� RSSで情報を「受動的に」取得
� 能動的に情報を手に入れる時代はとっくに終わってる
� 気に入った情報=ネタを溜める
� ソーシャルブックマークなのは世界中の人達と共有できる、どこでも見られるから。
� ネタをもとにアイディアを出す。そして作る。� ネタをもとにアイディアを出す。そして作る。
� 手を動かして、「モノ」を作る。
� 作ったものを「動かす」
� サーバで動かさないと意味が無い。
� 本を読んで深堀り、反省する
� 作った物を技術的観点で振り返る。もっとこうしたほうがいい、新しい技術を導入するなど、目的をはっきり持って本を読む。
脱プログラミング初心者へのプロセス
� 作る
� 最も需要なのは「手を動かして書くこと」
� まずは汚くても動けばいい。
� コピペはしない。いちいち手で書く。
� 覚える意味で。
あえて車輪の再発明� あえて車輪の再発明
� プラグインがあるからそのままつかう、よりはあえて書いてみるのもいい。劣化したものでもいい。「書くこと」が重要。
脱プログラミング初心者へのプロセス
� 動かす
� 作ったものをサーバで動かす
� 初めはWindowsでOK
� 開発環境兼サーバとしてでOK
� 重要なのは「外部から見れる」こと
� 研究室から自宅のPCへアクセスしてみよう� 研究室から自宅のPCへアクセスしてみよう
� 正常に動けばいい
� 正常系だけ動けばいい。異常系はひとまず気にしない。
脱プログラミング初心者へのプロセス
� 振り返る
� 作ったもののソースを暇なときに眺めてみる
� どこかに改善の余地はないか考える
� 漠然とでいい。
� なんか無駄に長い
� コードは短いほどいい� コードは短いほどいい
� 変数名とかが分かりにくい
� $hennsuuとか意味不明な変数名になっていないか
� 処理をまとめられないか
� 関数を使って切り出せないか
� というか、全部汚い
� これに気づいた=成長の証。おめでとう。
� いっそ全部書きなおす。
だめな思考
� 「すでにあるから作る意味が無い」
� これはそれなりに熟達したプログラマが言う事
� あるいは納期が決まっており、工数がかけられないとき
� または品質を担保する必要がある場合 など
� 初心者が上達するという目的の上でこんなことを考える必要はない
� そんな事いったら、なにもできない。
だめな思考
� 「既存のソフトウェアを改造する」
� そもそも改造できるだけの実力があるのか
� 他人のコードを改造するのは面白くない(個人的には)
� 主役はだれなのか
� 主役は「自分のコード」。他人のコードやソフト、APIを組み込むのはあり。だが、その逆はなし。を組み込むのはあり。だが、その逆はなし。
だめな思考
� 「他人が使いたいものを作る」
� そもそも初心者が他人に使って欲しいものを作るのはおこがましい
� 他人は容赦なく要求してくる
� まずは「自分」のために作る
他人のために作るのはまずは自分を満足させられる程度� 他人のために作るのはまずは自分を満足させられる程度の実力をつけてからにしよう
ちなみに中級者以上は
� 「動けばいい」はNG。動くのは当たり前。
� テーマをもって作る� 新技術の投入、開発プロセス改善など
� フレームワークを使う� 生産性向上
� テストを書く� テストを書く� 品質向上
� テスティングフレームワーク(xUnitなど)を使う。動作確認コードはテストではない。
� コード管理する� バージョン管理は常識
� RSEは使わない
ちなみに中級者以上は
� TODO管理する� チケットで管理。コードとTODOをひもづける。
� 環境を分ける(開発環境・本番環境)� 物理マシンを最低2台用意する
� 本番環境のコードはいじらない
� デプロイは自動化する� デプロイは自動化する
� コードを美しく書く� MVC、DRY、OOP、デザインパターン、命名規約、疎結合、再利用性、言語のポリシー遵守
� 例� http://d.hatena.ne.jp/tagomoris/20110608/1307502071
研究とスキルアップ研究とスキルアップ
家と学校を循環させる
� 家で蓄積したことは学校で活かせる
� 学校で蓄積したことは家で活かせる
� 学校でコードを書く
� 完成したら見直す。改善の余地がある。
� それをもとに家でコードを書く
完成したら見直す。改善の余地(ry� 完成したら見直す。改善の余地(ry
� それをもとに学校でコードを書く
� 完成したら(ry
� それをもとに家(ry
� 完成し(ry
� それ(ry
家と学校を循環させる
� 家では「技術力」向上がメイン
� 学校では「研究」の成果を出すことがメイン
家でコードを書く必要性
� 学校では「アイディア出し」「論文読み」「調査」をメインでやる
� 当然コードも書いてもいい
� 家では「コードを書く」ことをメインでやる
� コードを書く力は学校でなくてもできる
� 研究において、概念やアイディアを形にしたほうが説得力が増す
� アイディアがいくらあっても形にする力がなければ…
すぐに形にできる実力をつけておく� アイディアがあっても形にできなければ結局焦りを生む� 想定パターン(コードが書ける)
� アイディアが11月になってようやく出た� あと2ヶ月で作るのか…余裕だな(・∀・)
� 想定パターン(コード書けない)� アイディアが9月でもう固まった。研究余裕すぎww� あと4ヶ月で作ればいい。さてprintfから始めるか。� あと4ヶ月で作ればいい。さてprintfから始めるか。
� 参考までに� 私は4年の12月3週目くらいまで迷走していて、そこから2週間で一気に地図アプリ(TMAP)を作りました。コードを書く力をつけてなかったら詰んでた。
� 逆に院生時代は11月頭とかでとっくにできてたので論文は箱根駅伝見ながら余裕の完成でした。
� そして論文提出後にさらに研究成果に機能追加するくらい余裕でした。
� コードを書く力をつけておくとこのくらい精神的に余裕が出ます。
なぜコードが書けると得をするか
� 第一に研究のラストスパートが余裕で効く
� アイディアさえでればもう終わったも同然という余裕
� 第二に社会でそのまま使える
� ぶっちゃけると、研究なんてなんの役にも立たないから。
� 重要なのはそのプロセス=コードを書く力。
� 逆に言えば、研究内容がクソでもコードがかければ学生時代の立場逆転、即戦力になる。これが現実。
こんなことを言っていいのかという気はするが…(こういう考え方もあるよという程度で)
� 研究は「踏み台」にすぎない� すみません。私はそう考えてました。
� 研究者にならないなら利用するだけ
� 社会に出たときに即役に立つスキルを身につけることを最優先。
� その過程で研究が進めばいいじゃない。� その過程で研究が進めばいいじゃない。
� またまた参考として� それを実践したら、まじでそうなったから。
� 社会人1年目にJavaScript詳しいヤツということでプロジェクトにアサイン。コード書きまくり。
� 社会人3年目に事業部全体でRails使える奴を探して、俺が指名された。で、バグ直してきた。
� つまらない、だれでもできる仕事をやるより楽しい。
まとめ� プログラミングはやり方が分かれば上達する
� プログラミングができれば卒研とか余裕
� プログラミングができれば社会でも即通用