人の心を動かすインタビュー RSSフィード

2009-09-19

voicetrek2009-09-19

コンピュータサイエンスはこう学べ (1) 14:26  コンピュータサイエンスはこう学べ (1)を含むブックマーク

コンピュータサイエンスの勉強法について、情熱を持って取り組まれている方々にお話を伺ってきました。

---- 最近はどんな本を読んでいますか?

ひげぽん: Aさんに薦められた "Domain-Driven Design" (DDD) (ASIN:0321125215) という本と、"Programming Pearls" (ASIN:0201657880)」ですね。

---- DDDを薦めた理由は?

A: コーディングに関する新しい本ってあんまり無かったので、最近あまりコーディングに関する本をひげぽん氏が読んでない気がして。あとは、割と良い本なので、みんな読んでおいた方がいい「必読系の本かな」と思っているところがあって。

---- 読んでいてどうですか?

ひげぽん: 日記にも書きましたけど、「ハートオブソフトウェアは何か?」という話に割と感動しましたね。

A: 「ハートオブソフトウェア」ってどんな話でしたっけ?

ひげぽん: ユーザーの生活するドメインの中で叶えたいことを実現するのがソフトウェアのハートの部分であって、テクノロジというのはそれを実現する手段だよ、ハートオブソフトウェアを作るために DDD をやっていきましょう、みたいな導入があって。

---- Domain-Driven とはどういうことですか?

A: DDDというのは、顧客の方の世界を中心としたデザインの事で、例えば、銀行の勘定系だとか、電子回路のシミュレーションをするものだとか「現実の世界の何かを達成するのに作るソフトウェア」で、その時に現実の世界を中心にしてデザインをする、というものですね。

ひげぽん: 自分がSE時代はそういうことをやっていたなぁ、と思いました。ものすごく稚拙でしたが。つまり、お客さん側の世界から考えて、それをソフトウェア側にマッピングする。逆じゃなくて。

A: まぁ、あんまりソフトウェアサイエンスの本じゃないけどね(笑)。こういう展開としては適切かは分からないけど……DDDというのは「話し合いとかコーディングを重視する」っていう方法論で、これは結構、好みなところがあるんですよね。UMLのダイアグラムだとか仕様書だとか、そういうものではなくて、「コードを重視する」というのは好きな方なんで。で、どういうコードを書くか、というのがずっと語られているので、あの本は好きだな。「実例」みたいなものが沢山載っていてですね。「対話をしながらちょっとずつコードを書いていく」というスタイルなんですね。

コードを書くんだけど、話をしているとどうも話の内容とコーディングのモデルが違うと。モデルというのは、クラス名とメソッド名ですね。なんか違う、と。クラスの切り方が話してる内容と合わない、と気付いてちょっとずつ変えていくというのが、物語風に延々と続くという本なんですけど、これが非常に最近の自分の仕事のスタイルに似ていた、と読んでいて感銘を受けてですね、「おー、こうだよ、こう!」と思ったんですね。最近といっても、2,3年前の話ですけどね。「みんなこういう風に仕事したらいいのに」と一人盛り上がって薦めてたんだけど、誰も周りで読む人はいなかったと……。

---- 洋書しかないですよね

A: 洋書しかないですね。これがあんまり内容を読んで話をしている人がいなくてですね。「はし書きしか読んでないだろ!」みたいな人が偉そうに語っていたり、「これはデザインパターンの本である」とか言っていたりと、凄く不満なんだよね。「違うよ!」って思うんだけど。「対話をしてコーディングの質を上げていく」というところが中心なのに、それについで誰も話をしていない。

---- レビューの話ではないんですよね

A: レビューの話ではないけど、似てるね。「ペアプログラミング」をレビューの一種として考えるとすると、あれも広い意味でのレビューに近くて、ドメインスペシャリストと対話をしながらコーディングしていくということで、プログラマと話しながらではないんだけど。ドメインスペシャリストというのはコードを読めるわけじゃないので、コードの中心的な部分を抜き出して、自然言語にしなくちゃいけない、という所が違うところで、自然言語を使って話をして、自然言語を洗練させていく。それをコーディングに反映していくというのが、DDDの肝ですね。いい話だとは思うんだけど、ドメインスペシャリストと仕事をすることは多くなかったので、自分の仕事とはちょっと違うなぁ、とは思うけど。

omo: XPが前提なんですか?

A: XPは前提だし、ある程度リファクタリングベースで開発するという……つまり、発展的デリバティブじゃないけど、ちょっとずつ変更してリリースして変更してリリースして、というサイクルを繰り返していってソフトウェアを成長させていく、ってのが前提になってるね。2003年に書かれた本なんだけど、2003年を感じさせない本だね。2005年ぐらいにIDEのリファクタリングブラウザとかが普及してきて、プログラミングの世界が変わったなぁ、と思うんだけど、2005年より後に書かれたような本が2003年に書かれているので、あの本はいつ読んでも違和感があるんだよね(笑)。「なんで2003年なんだろう……こいつ本当に手でやってたのか?」みたいな。

omo: smalltalkerだったとか。

A: いやー、Java使いっぽいけどねぇ、エヴァンズ (Eric Evans) は。

---- 著者は何の専門家なんですか?

A: Javaの普通の受託の専門家っぽいですねぇ。マーティン・ファウラー (Martin Fowler) が前書きを書いてるんだけど、何処でも「マーティン・ファウラーが書いた本」って書いてあって「書いたのはエヴァンズだ!」っていつも思うんだけどw

omo: それは酷いw

A: 本当に内容を見てないよなぁ、みんな。

omo: マーティン・ファウラーのキャラじゃないしね。もっと情熱的なんですよ。

A: エヴァンズの方が、そこはいいよね。マーティン・ファウラーは人の話を聞かないよね、基本的に(笑)。そういう感じではない。「コンピューターの勉強」的な話に戻ると……私は最近そういう本を全然読んでないけどね。

ひげぽん: 前提として、Aさんはこれまで凄い量の本を読んでるんですよ、と読者の人に伝えないと。

---- 凄いんですよ、Aさんは

omo: (笑)

A: そんなことはないですが。何故そういう本を……そういう本って区切りも難しいですが、なぜ「教科書的な本」を読んだ方がいいと思ったかというと、そこには、過去に色々と経験をした結果、良さそうだと思ったひとつの答えが書いてあるからで。「体験をすると経験は得られる」んだけど、それが正しいか間違ってるかは、それだけじゃ分からない、という欠点がある。本になっているのは、もう少し多くの例を見た上で、良さそうなモノをピックアップしているので、「経験よりは少し正解に近いもの」が載っている。それを知らずに自己流にやっていると、沢山の例の中からピックアップされたものに比べると、やっぱり劣っている事が多い。

だから、正解を知っていた上で……まぁ自分の場合上手く当てはまらない事が多いので、合うようにアレンジして、それに近い、でもちょっと違うものとして開発していく方が、正解を何も知らずにランダムに当たっていって「良さそうになれ!」と祈るよりは、随分効率が良いと。そう思っていたので、「正解集め」のような事をしていたのが理由ですかね。

---- 実際活かしていけました?

A: そういうのを活かすのは上手い方じゃないかなぁ、とは自分では思うね。「そういうのを読んだらみんな活かせるか」と言ったらそうではないと思うけど、そういうのをちょっとアレンジして適用するのが上手い人はいると思うし、自分はまぁまぁ上手い方だと思う。例えば、OSの本とかコンパイラの本を読むってのは、「色々作ってきた結果、これが良い設計なんだ」ってことなので、OS以外のモノを作る時にも、そういうのを真似して何となく作る方が割と良いものが出来やすい。そういうひとつの正解例を知れるわけで。OSは作らないけど、OSの本は読むという。

ひげぽん: でもそれって、ヒット率が高くないと意味がないですよね、さっきの話からいくと。ヒット率を上げるためにしている事ってあるんですか? つまり「当たりの本を引く」とか「当たりの分野を引く」とか。

A: 本の選び方でいえば「有名な原典に当たる」ってのを重視してますね。そいつを読んだ後にそれに影響を受けて書いた本よりは、最初に書かれたような本をなるべく読むようにはしてます。そうするとやっぱり分厚い本に当たりやすくて、洋書だったりする事も多いけど、遠回りのようで早いと思う。

omo: ハズレは引いてるんですか?

A: ハズレは結構引いてるねw

一同: (笑)

A: そこはやっぱり数を読む事でカバーしている、って所はあると思う。

ひげぽん: 「ハズレを引いた」ってのは読み終わった後に気付くんですか? それとも途中で気付いてやめるんですか?

A: 途中で気付くけど、やめずに最後まで読む事が多いですね。途中でやめてもいいんだけど。

ひげぽん: おー、それは熱いな。今、さらっと流れたんですけど、「洋書を読む」という壁がいまここに出てきたんですよ。そこは越えておくと楽ですよね。

omo: そこは洋書ブームが来ている人に聞くのが生々しい声が聴けていいんじゃない?

ひげぽん: 仕事とかで論文を読まなきゃいけない、論文は英語で書かれていて、しかも数式も難しい、ダブルで難しい……みたいな事で苦しんだ時に「まずは洋書の技術書から」みたいな事をやってみて。もう翻訳出ちゃいましたけど、"Working Effectively With Legacy Code" (ASIN:4798116831) を英語で読み始めたら、意外と読めるし、翻訳と違う雰囲気を感じ取れますよね。「翻訳待ち」ってステータスがなくなるのも大きい。

A: 最近は良い本の翻訳が出てないって印象があったので、プログラマは洋書を読まなきゃいけなくなりつつあるんじゃないですかね。"Working Effectively With Legacy Code" (ASIN:0131177052) なんてずっと出てなかったしね。最近日本語版が出た (ASIN:4798116831) けど。あんなもん、それこそ2005年に読むから色々と学ぶ事があるんであって、今あれを読むと……別に学ぶことはあるけど、ちょっとまたあの時代とは事情が変わっているので、コーディングも変わっているし、プロセスも変わっているので。

omo: 人によると思うけどねぇ。

A: そうだけどね。ちゃんと先端を追っていれば、あれは時期を逸している感があって。

omo: いやでも、あれねぇ……読んでると当たり前になってる事が色々あって、「あれ? なんでコレできないの?」って事もあるわけですよ。サブクラス化してエクストラクトすればすれば終わりじゃん、ってところが分かって貰えなかったりすると「おっ」ってのがあるわけですよ。

A: リファクタリングブラウザを使い始めの頃は凄く良い本だと思うんだけど、散々それを使うようになって、それを前提としてその次に進んでいる人には、「まだここにいるのかお前は!」っていうところがあって、やっと日本語訳で出たって言われると、日本語で技術書を読んで一線で働くのは無理じゃないかな、って。

ひげぽん: 一線の定義がなかなか厳しそうだ(笑)。

一同: (笑)

A: 「自分は一線だったか?」と言われると、一線ではなかったと思うけどね。DDDなんて未だに和訳出ないしねぇ。2003年に出て必読書だと思うけど。

omo: あれは多分、翻訳者がつかえてると思うんですよね。

A: 一方でまぁ「読みたい」って本当に思ってる人は少ないのかもしれないね。

omo: いやー、割と引用されてるしさ。"Art of Agile Development" (ASIN:0596527675) って本が日本語になってます (ASIN:4873113954) けど、あれって普通にXPのプラクティスにユビキタスランゲージが入っていて、ユビキタスランゲージって。

A: あの本に出てくるからね。ユビキタスランゲージっていうのは、自然言語に翻訳して専門家と話すという、自然言語がユビキタスランゲージって言われてるものだね。なんか……自分が進歩しただけかもしれないけど、95年とか96年ぐらいは、必読書はもっと翻訳されていた気がするんだけどね。最近は堅い本は翻訳されにくくなって。どんどんと、「英語を読まざるをえない」という度は上がってるかなという気はするね。

ひげぽん: どうせエンジニアって英語のリファレンスを読まなきゃいけなかったりするじゃないですか。その延長で本も気楽に読めるようになったら幅が広がりますよね。

---- 英語に抵抗がある人が慣れていくにはどうすれば良いんでしょうね?

A: 分かんないねぇ。最初に読んだ時は辛かったけどね。最初に読んだ洋書は何だっけ…… "SICP" (ASIN:0262692201) でしたっけ(笑)。あれは最初読んだ時辛かったねぇ、何だこの本、って(笑)。

一同: (笑)

omo: スパルタ系ですねぇ。

A: 「英語版はタダだ」って言うからさぁ。しょうがねぇ、じゃあ英語版読むか、ってプリントアウトして大学時代に読んでてさぁ。何セントかを分けるプログラムとかを、英語が分からないんだかプログラムが分からないんだかよく分かんないなぁ、とかw

omo: 学生の頃は、金銭的動機で英語を読む事はあるよね。OpenGLのRedBook (ASIN:0321552628) 日本語は12000円だけど洋書は5000円だよと。じゃあ読むかと。

A: あー、そういうのはあるよねぇ。英語はタダで配られてるのも多いし、安いってのも多いから。

---- 読みやすい洋書と、読みにくい洋書ってありますよね?

A: すごいキツい類のってのはあるよね。

omo: 技術書ってのは、日本語になるから簡単になる、ってことはないと思うんですよ。

A: 今まで読んだ中で一番難しいのは、"Software Factories" (ASIN:0471202843) だね。

omo: (爆笑)

A: 日本語 (ASIN:489100472X) で読むとどうなのかね。俺、読んだことないけど。

omo: いやー、しんどいですよ日本語でも(笑)。

A: あれは何か「しんどいなぁ」って思った本ナンバーワンだけど。でも、ああいう本は必須の本のひとつだと思うんだけどさぁ。

omo: Software Factories?

A: そう。あれは全部読まなきゃダメでしょう、エンジニアは。何の役にも立たないけどねぇ。

一同: (爆笑)

A: 物事をちゃんと理解することは出来るけれど、ちゃんと理解しても書くコードは変わらないという。そういう類の本なんじゃないかな。

一同: (爆笑)

omo: ホントそうだけどさぁ。

A: 「SICPが役に立つか?」って言われた時の一瞬の間と同じだよね。

ひげぽん: 悟りは開けますけどね。

A: 役に立つと言いたいが……みたいなw

omo: コンフィデンスを得るんですかね。

A: 例えば "Software Factories" (ASIN:0471202843) をちゃんと読めば、「抽象化」ってものの正体をちゃんと突き詰められるわけで。そこからちゃんと理解している人と、そうじゃない人っていうのは、やっぱりソフトウェアの話をしたり、抽象化の話をしても全然別な事を本当は言っていて、それは本当は大切なことだと思うけど、コードにあまり違いが出ないので。

"SICP" もそういう所はあると思うんだよね。普通にコードを書く時に、C言語でも常識的に綺麗に書くってことが、ただSchemeで綺麗に書かれているだけ、って部分はあるけど、順を追って抽象化の思考みたいなものが書かれていて、そういうのをちゃんと理解していると、C言語でも心の底でそういうのがあって、それがそういう表現になってるのか、ただそういうコードになっているのか、ちょっと違う所があるような気がするので、読んだ方がいい、というけど、新人が今ここにいたとして、全然コードが書けなくて最初に読む本がこれか、と言われると違うなぁと。

ひげぽん: それは違うな(笑)。

omo: どうですか、SICPを読んだ身としては。

ひげぽん: どうですかねぇ。自分は直接の利益としてインタプリタとかコンパイラが書けるようになった、という利益があるんで。

A: あれを見るとSchemeのインタプリタとか書くよね。

omo: 恩恵を得ているレアな例なのかもしれない(笑)。

ひげぽん: コンピュータサイエンスの本ですよね、Schemeの本というよりも。

A: そうだね。

---- 海外の大学では最初にあの本を読むという話ですが

A: そういう噂だよねぇ。

ひげぽん: 最近は読まなくなった、って話もありますよね。無駄に難解なんですよ。

---- 読書会をやってる人が多いですよね

A: 読書会はよく見るよね。「SICP読んだぜ!」ってのがいいんですかねぇ。

---- 三人とも読んでますよね

omo: 僕は途中まで。

A: 俺読んだよ。わーい(笑)。

---- 何をもって「読んだ」なんですかね

A: 最後まで読めばいいんじゃない?w

ひげぽん: いや、「ここの章のアレが」って語れないと(笑)。

A: ダメですかw

---- 例題とかやってます?

A: 例題は俺あんまりやってないねぇ。それはひげぽん先生の方が偉いですね。

---- 例題やると違います?

ひげぽん: 違いますね。読み飛ばしたのがもろバレますからね(笑)。

一同: (笑)

ひげぽん: 「全然分かってなかった俺!」みたいな。でも、基本、コンピュータ本の例題はやりませんけどね。

A: アルゴリズムの本だと例題とかやったけどね。

omo: 本の中身を忘れないために、マインドマップを書いてるじゃないですか。あれと例題やるの、どっちが良いと思います?

ひげぽん: それはマインドマップの方が僕は好きですね。見返すとマインドマップを書いて時の感情が思い出せるんですよ。……宗教的になってきましたけど。

一同: (笑)

A: マインドマップの話は宗教的になるんだよね。

ひげぽん: 「マインド」って付くからいけないんですよ。

A: いつもこの話をするとねー、痛い信者みたいになるので俺は最近しなくなったんだけど。

一同: (笑)

---- 痛いところを見せて欲しいですw

A: マインドマップの歴史は長いからね、俺は。大学一年の頃とか。コンピュータ触る前から描いてるので。

---- マインドマップを知る前から、それらしいものを描いてた?

A: いや、トニー・ブザンの "頭がよくなる本" (ASIN:4489005261) は受験生必読の本ですよ(笑)。

ひげぽん: 「マインドマップ」じゃなくて「頭脳地図」ってことにすると、印象が変わりますね(笑)。

A: マインドマップは良いけど、この会話の趣旨とは外れる気もする。最近コンピュータの本を読んで描いてないけどね。

omo: 本の中身を忘れるんで、忘れないようにしたいなと思って、マインドマップを描いてる人を見ても、なかなか真似できないんですよね、面倒くさくて。

ひげぽん: でも、ある本を読んでマインドマップを描くとすると、本を読んでる時間の方が明らかに長いんで。

omo: そうなの!?

ひげぽん: 最後の何分の一かの工程をマインドマップに注いで。

omo: どういう粒度で描いてるの?

ひげぽん: 章かセクションぐらいですかねぇ。

omo: 章かぁ。やっぱり章ぐらいだよねぇ。なんかマインドマップってレイアウトとかが上手く行かなかったりするじゃないですか。「あれ、こっちに寄っちゃったよ!」とか。

ひげぽん: それは、慣れないうちは下書きマップを描いて、本ちゃんマップに清書するんですよ。

omo: 最近はもうやらないんですか?

ひげぽん: 「頭の中に書いておいて、最後に」みたいな。

omo: (感嘆)

A: 同じ方向に広げるってのは、慣れが必要だよね。同じ方向に広がられるようになるというのは、マインドマップを使いこなしている事になるという。

omo: 持って来てます?

ひげぽん: ありますよ。最近は手抜きが多いですからね。段々自己流になるんですよ。

omo: お、PCだ。写真に撮ってるんですか?

ひげぽん: 写真に撮ってます。最初は気合入れて書くんですけどね。段々適当に。

A: 俺はあんまり時間掛けないねー。

omo: カラー?

ひげぽん: カラーですねぇ。例えばコレですね。これはDDDのServicesのマインドマップ。これぐらいの粒度ですね。あんまり細かく描いても覚えられないんで。

f:id:voicetrek:20100301142513p:image

omo: 覚えるの前提なんだ。

A: マインドマップは、描けば割と覚えるけどね。

ひげぽん: それはAさん記憶力がいいんですよw

A: そういう問題じゃないとも思うけど。

ひげぽん: この一番太い枝は覚えますね。細かい部分は、ここを思い出してから何となく「うんうん」唸って思い出すみたいな。

omo: 「何%」とか書いてるじゃないですか、日記に。

ひげぽん: あれは、復習用の単語帳みたいな紙を引いてくると「これを復習しろ」って書いてあるんですよ。その復習しろと書いてあるマインドマップをこれを見ずに書いて、どれくらい一致しているかと。

omo: へぇーっ。ここが復習ワードなんですね。

ひげぽん: 「Servicesって何だっけ?」みたいになって。「どのオブジェクトにも所属しないアレだよ」みたいな所から始まって、「背景はこんな感じ」っていうのを思い出すみたいな。でももうルールを守ってないんです。例えば、絵をもっと描きなさいとか。中心では三色使いなさいとか。色々ルールがあるんですが、段々守らなくなる(笑)。でも色は重要ですね。

omo: 色は重要なんだ。色で覚えてるの?

ひげぽん: 一番重要そうな所は赤くしたりとかするんで。

---- 全部の本でやってるんですか?

ひげぽん: 「マインドマップを描く」と決めてる本だけやってます。

omo: 描かない本もあるんだ。

ひげぽん: あります、あります。軽く読むような本は描かないですね。"Realtime Rendering" (ASIN:1568814240) とかはやってますね。100円ショップで色ペンを買っておいて。会社と家に置いておいて。理解度を試すのに良いですよね、マインドマップは。「見て思い出せるものは描かない」って基本ですね。

omo: 僕は目次が木になってるだけだからダメなんだろうな。

---- 最初に始めた時は、どんな失敗をしてました?

ひげぽん: 最初は、本の作者の思考の流れに沿って描いてたんですけど……つまり、作者が言いたいことがあって、結論が先に書いてある場合もあるんですよ。「こういう部品がある」とか。「これにはこういう背景があって、こういう失敗があって、こうなりました」みたいな流れがあるんですけど、作者の心の流れは自分では思い出せないので、自分の心の流れに変えて描くと。

omo: へぇー。

ひげぽん: 自分だったら、背景がこうあって、困っている事がコレだったからコレが出てきました、みたいな順番の方が分かりやすいんですよ。

omo: そうやってリレイアウトするんだ。

A: マインドマップを描く本は「ちゃんと復習したいなぁ」って本だよね。さらっと読んで終わり、って本ではあまり描かないな。

omo: (自作マインドマップを見せつつ)これは "詳解TCP/IP" (ASIN:4894713209) かな。

ひげぽん: こんな感じですよね。

A: うん。

omo: 描くと凄く疲れるんだよね。あと、これって出てくる順番なんですよ。出てくる順番に、見ながら描いてるから、多分違うんだよね。見終わった後にバンと描いてます?

ひげぽん: どっちもですね。頭の中に入りきらない量だったら、読みながら描きますし。

A: 大学の講義とかはマインドマップでノート取ってたけど、その時は聞きながら描いてたけどね。終わりまでにどういう形になるのか分からないけど、均衡になるには色々と推測しなきゃいけないんで、理解して先を読みつつ描かなきゃいけないという効果はあるね。

ひげぽん: 一発で書けるのが理想ですよね、手間も考えると。

omo: 復習ってフェーズがないからね……。

---- 復習をするようになった理由は?

ひげぽん: 自分が「記憶力が悪い」と分かっている前提で、せっかく本を読んで自分の引き出しが増えたのに、とある会話で聞き覚えのある言葉が出てきた時に「あれ、なんだっけ?」って事がよくあるので、だったら本当に重要な事は覚えよう、って事で復習フェーズを入れました。

---- 復習方法もマインドマップの本に書いてあるんですか?

ひげぽん: 「いつ復習すべきか」とは書いてありますね。翌日、一週間後、二週間後、一ヵ月後かな。「これは何月何日に復習した、次は何月何日」みたいな感じで紙に書いておいて、箱に放り込んでおきますね。

omo: ちゃんと守られてるんですね。

A: それは偉い。俺はそこまで守ってないねぇ。次の日の復習はやるけど、何となく忘れてくる一週間後にもう一度やるぐらいかな。ぴったりじゃないけど、一ヵ月後ぐらいにも復習はしてる。

omo: 復習するんだ、やっぱり。

A: コンピュータの本は最近は復習しないねぇ。語学とかの方が多いかな。

ひげぽん: 語学は効きそうですね。

A: コンピュータの本は、読めば読むほど自分の知らない量ってのが一冊の中で減っていくんで、「殆ど知っていて、ちょっとだけ知らない」ってなっちゃうので、頑張って復習、って感じじゃなくなってくるんだよね。

ひげぽん: 僕は貯金がないんで覚える時期だと思うんですよ。読むと殆ど知らないことばかりなんで。

A: それは「良い本を読んでいる」ってことだと思うけどね。私も知らない事はいっぱいあるはずだけど、知っているような本を引いてしまってる、という事があるからそうなるのかも。

---- トニー・ブザン著の本から入るのが良いですか?

ひげぽん: 原典なので良いとは思いますけど、最近は商売っ気があるんで(笑)、全部まともに読むのはどうかなぁ、って気がします。

A: いっぱい出してるよね。「頭がよくなる本」(ASIN:448900740X) だけでいいと思うけどねぇ。

ひげぽん: 僕もそう思います。

---- 大学の頃というと、だいぶ昔の本ですよね

A: 新しいのが出てるよ。

ひげぽん: マインドマップは宗教っぽいんで、あんまり広げるのは良くないと思います。「あー、こいつらキモいよ」で終わりますよ。

---- 実際そう言われる事は多いですか?

ひげぽん: 「誤解してた」って言われることはありますね。熱く語ると「あー、そうなんだ」って分かってくれますけど、分かってくれたのか、そろそろ切り上げよう、ってことなのかは(笑)。

omo: カードを使う復習の仕方って、オリジナルですか?

ひげぽん: だと思いますが……どうだろ(笑)。

omo: そろそろ本が書けると思うんですよね。「スーパープログラマのための」……じゃない(笑)、「スーパープログラマによる勉強法」。

ひげぽん: そういうのはちゃんと成果を上げてる人じゃないと (笑)。

A: 成果を上げてない人も書いてるよw 勉強の本ってのは結構あって、どれも似たような結論が出てるよね。

ひげぽん: それは僕も思いました。僕はある時期Aさんに「ひげぽんは勉強の効率が悪いよね」って言われて、「それはもっともだ」と思って、図書館で「勉強の仕方本」をいっぱい借りて読んだんですよ。そうするとやっぱり共通部分が見えてきて。マインドマップも復習もそうですけど。

---- 勉強の仕方を変える前と後で、違うと感じたことは?

ひげぽん: 復習が足りなかったですね。インプットは足掻いてたんでしょうけど。どんどん頭から抜けていって、何も残らず「あの本は読んだよ」って言えるだけ(笑)。

A: 本のチョイスが気になったね。CPUの勉強をしようと思ったら、ヘネパタを最初に読むものだろうと常識的には思うんだけど、違う本をいっぱい読んでたりしてたじゃん。そういうのが何か違ってたのかなぁ、と思ったんだけど。

ひげぽん: いや、純粋に自分は知らなかったし、周りにそういう人もいなかったという。"はじめて読む486" (ASIN:4756102131) とか読んでましたね。あれも良い本ですけどね。でもあれにはパイプラインストールとかは書いてないんで。

A: 初期の「OSを作ろう」スレでは、"Intel Developer's Manual" を読めよ、って言われてスルーしてた記憶があるけどw

ひげぽん: あれはダウンロードして「無理だ」と思ってw

A: "Intel Developer's Manual" って分かりやすくない? 必要最小限のことだけで。

ひげぽん: 今でも厳しいかなw

A: ヘネパタってそんな難しいわけじゃないよね、そんなに。

ひげぽん: そうですね。

A: そういう本もあるんだよね。「分厚いけれど難しくなくて定番な本」と「厳しい本」があるんだよな。

ひげぽん: そういう良い本を選ぶ方法を知りたいですね。今はAさんチョイスをパクってるだけなので。

トニー・ブザン 頭がよくなる本

トニー・ブザン 頭がよくなる本

http://d.hatena.ne.jp/ryocotan/20091231/p3 続きの(2)です

補足

http://b.hatena.ne.jp/entry/d.hatena.ne.jp/ryocotan/20090919/p1

id:natsutan ヘネパタとパタヘネは違うと何度言えば

ご指摘ありがとうございます。申し訳ありません、「これかな?」と適当にASINを貼ってしまいました。念のためリンクは外されて頂きました。ヘネパタとパタヘネがあるんですね。

Connection: close