参考書選びと迷った時の勉強法。

入門したは良いけれど、これからどう歩けば良いのか分からないという方のために。

まとめてみました。

吉村 孝広 ! ねこすけさん @alterakey @nekosukesan55

自己紹介! こんな人

! 埼玉で活動しているアーキテクト (29)です。! コードは自分でもガンガン書きます。考えます。! Twitterやってます → @alterakey

! こんなことやってます! Flashゲームのコアロジック! 小～中規模Webアプリ! iOSアプリ! 構成評価、チューニング、セキュリティ監査 …など

参考書選びで迷った！

本を買ってみたは良いけどイマイチ！…こんなはずでは T-T

技術書を選ぶのは大変です。例えば…

! a) 扱っているトピックが基本的すぎる。→入門系によくあります。

! b) 専門用語ばかりで堅い。→試験対策や邦訳、逆引き系によくあります。

! c) サンプルが天下り的でわけがわからない。→概観系、逆引き系などでたまにあります。

! d) 例えがしっくりこない。→邦訳でたまにあります。

どういう本が良いんだろう？

はっきり言うと、人によりにけりです。

でも… オライリージャパンの、Head First系列の参考書をお薦めします。

なぜ？関係者？

文章よりも絵による表現。

! 百聞は一見にしかず。軽く読み流しても良い。

! パッと見はやさしく見えるかもしれないけど、実はかなりディープなところまで扱っている。→後で読み返しても役に立つ。

! 読んでいて飽きない。

Androidアプリ開発だけなら…! Javaの知識は基本的なことだけで十分です。

servletとかEEとかの知識はまずいりません。Apache Commonsにしても普通はいりません。

! Eclipseはコード入力支援が効いている環境なので、構文を暗記する必要はほとんどありません。

Eclipse、せっかくやるなら。補完機能をFlashDevelop並みに強化できます。

Preference"Java"Editor"Contents Assistで! Auto activation delayを「0」に。! Auto activation triggers for Javaを「ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789._」に。

その分、誤爆も増えるので「Organize Imports」(Shift-Ctrl-o)を適宜活用しましょう。

読んだけど迷った！

とりあえず、本を読んでみて分かった。

でも、いざ白紙を前にすると萎える。

…こんなはずでは T-T

とにかく、足がかりが重要です。! まず、やりたい目標を明確に決める。大事。

大きすぎて手にあまるようなら、分解して小さくすることを考えましょう。

! 例: 「目覚まし時計」 → 「時計」＋「アラーム」 → 「文字盤を書く」＋「針を書く」＋ 「時間待ちをする」＋「アラーム音を出す」

… など。

もくもくしましょう。

! それに近い分野を扱っている本やサンプルコードを手に入れましょう。

! 地道に写経なり研究なりを重ねましょう。→ちゃんと説明しますよ！

! 分かったことをどこかにまとめましょう。コピペでもＯＫです。

軌道修正しましょう。(1)! もくもくまとめたものを組み合わせて、次の手を考えましょう。

ここで、目指している目標が小さすぎることが分かったら、まとめて大きくしましょう。

! 例: 「時間待ち」＋「音を鳴らす」 → いわゆる「アラーム」 → AlarmClockで普通のアラームを設定できそうだ！ → 使い方を研究だ！

…など。

軌道修正しましょう。(2)! 調べたものが目指しているものと違うようなときは躊躇せずに手を止めて、目先を変えてみましょう。

! 例: なんとなくダサい。3D的な表現を使いたい → 3Dはやれないのか？ → OpenGLが使えるらしいぞ → AndroidでOpenGL本から写経してみよう。

…など。

写経とは…修行僧がお経を書き写すこと。

転じて、俗に我々のような修行中の開発者が、「あるコードなり文献なりを、コメント含め一字一句丁寧に全てを書き写すこと」

を言います。

写経するとどうなるの？パターンに注目して行なうと…

! コードがだんだんと書けるようになります。

これはどういうことをしているんだろう？などと自問しながら行なうと…

! コードがだんだんと読めるようになります。

写経するときの注意! コピペは封印しましょう。リズムのような感覚を読み取るのに重要です。

! どんなにひどいコードであっても、写経中は絶対に文句を言わないこと。なげやりになって、分かるものも分からなくなってしまいます。せっかくの文献が勿体無いです。

勉強が済めばいくらでも非難できるのでせめて勉強中は我慢しましょう。

研究といってもその方法は…! 説明をなんとなく読む。! まず実行。期待どおりか？! なんとなく気になる部分を探す。! なんとなく変更・削除なりする（いじる）。! 実行。! どうなるかを記録・反芻。説明や仮説や期待していたことと比べてどうか？

! 心行くまで繰り返し。

研究を進めると…

! コードが読めるようになります。

! デバッグスキルが向上します。

まとめ(1)! 読めるということは、先人の知恵を使えるということ。これができるようになれば速いです。

! 書けるということは、表現ができること。これができると自分で作り出すことができます。

職業にしている人でも、書ける人が他人のコードを読めるとは限りません。できれば読めるようになりましょう。

まとめ(2)

! 地道にやりましょう。! いきなり完璧を目指したり、むやみに速度や技術にこだわったりするのはやめましょう。

まず何かを「実現すること」が大事です。

“Make it work, make it correct, make it fast, make it cheap.” -- Alan Kay

もっと勉強したいけど迷った！

検索しても良い情報が見つからない

…こんなはずでは T-T

言語を変えましょう。日本語だけでは見えない世界があります。

! できるだけ短文、できれば単語ごとに英訳してみる。

! 日本ではなくUSのGoogleを使うと良いです。http://www.google.com/intl/en/

Cookbook (1)! 「Android NDKでゲームアプリを書きたい。」

→ 「Android」「NDK」「ゲーム」 「アプリ」「どうやって？」

→「android ndk game tutorial」…など

Cookbook (2)! 「Eclipseのレイアウトエディタで

RelativeLayoutがうまくできないなあ。ドラッグしてもボタンが動かない」→「eclipse」「レイアウト」「エディタ」 「RelativeLayout」「うまくできない」 「ドラッグ」「ボタン」「動かない」→「eclipse layout editor RelativeLayout button move」

…など

質問してみましょう。自分一人では解決しづらいこともあります。

! Googleグループ／メーリングリスト! Twitter! 勉強会! 人力検索・知恵袋など! Stack Overflowなどの国外リソース（難関）

具体的に聞きます。相手も人間です。違う感性を持っています。

! エラーなどは具体的に。できればコピペで。! 動きません、困ってます、助けて下さい…よりも具体的に説明してあげましょう。! なにで困っているのか。（説明）! なにをしたら起きるのか。（再現方法）! どうなって欲しかったのか。（期待される動作）! 実際には何が起きたのか。（実際の動作）! できれば環境も添えてあげましょう。

まとめ (1)! 質問するときは具体的に聞きましょう。相手も人間なので、こちらの状況が読めるとは限りません。苦境を説明してあげましょう。

! 感謝の姿勢を忘れないようにしましょう。どんなささいな答えでも、すぐに役に立たなくても、例えググレカスでも、まず目を止めて関心を向けてくれたこと自体が貴重です。

→質問する側から見て最悪なのはスルー。

まとめ (2)

! Stack Overflowなどは特に優秀な情報源なので、機械翻訳でも良いので読んでみることをおすすめします。

! でも時間が許す限り、辞書と首っ引きすることをお薦めします。

参考書選びと迷った時の勉強法。

ご静聴ありがとうございました。m(__)m