読者です 読者をやめる 読者になる 読者になる

(define -ayalog '())

括弧に魅せられて道を外した名前のないプログラマ

積読タワーを晒そう。-技術書を選ぶ基準とか-

誰得な感じですけど、「僕の積読タワー」と「技術書をどうやって選ぶのか」が気になるという人がちょいちょいいるみたいなので、書いてみることにする。

あやぴーの積読タワーが成長する理由。

つい先日もこんな事がありました。

…あやぴーよ、積読タワーが成長してしまうとは情けない…。


たまに「読み切らないうちに、何故本ばっかり買うのか」聞かれるので、先に僕なりの積読の理由を書いてみる。

@さんとちょっと前に話をしていたときのこと。

「絶版になったら買えないじゃん」*1

と言われたのが、印象に残ってて「そりゃそうだ」という感じなので、毎月の如く積読タワーが維持されるor少しずつ成長します。
この世から"絶版"という概念が消えて、いつの時代の本も電子書籍とかで読めるようになったら買うのをきっとやめると思います。分かんないけど。この辺はGoogleさんとかAmazonさんにちょっと期待してます。買ってしまえばとりあえず、いつ読んでも良くて焦る必要もなくなりますしね!手元にあったらいつでも手にとれるし。買って後で一生読むことがなかった…というのは避けたいところですが。ドラクエ7クリアしたら本気だs*2

それから、@センセーもこう書いています。

技術者たるもの、毎月積読タワーを成長させる義務があります。嘘です。成長させちゃいけません。
私の技術書の選び方 - 日々常々

…良い子のみんなは成長させたらダメですよ。

積読タワーを晒してみる。

ブクログのほうに入ってるのは、だいたい所持している本で持ってない本も混ざってます。整理した結果、「読みたい」は持ってすらいない本で、「積読」or「読んでる」は持ってます。(たぶん登録してない本もぼちぼちある)
Amazonのほしい物リストは「欲しいけど持ってない」積んでないのに積んでる"エア"積読本です。僕の欲しいモノのほとんど(9割くらい)が技術書なのをみて、自分で自分にドン引きしているところ。

今回の主旨は積読タワー晒しということで、積読タワーに入ってて、読みたいのに読めていない本を紹介しますよ。

Structure and Interpretation of Computer Programs (MIT Electrical Engineering and Computer Science)

Structure and Interpretation of Computer Programs (MIT Electrical Engineering and Computer Science)

まず積読の頂点にある本というか、こいつ読んでるせいで他にあまり力が割けてない感パないの。
まぁ焦らずにゆっくり読んでいきます。

アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技

アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技

これはいつか読みたい積読。これは貰い受けた本なので、アレですけど読みたいですね。

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

DDD!!どうしても優先度下げがちだけど、読んでしまいたい…。

珠玉のプログラミング―本質を見抜いたアルゴリズムとデータ構造

珠玉のプログラミング―本質を見抜いたアルゴリズムとデータ構造

貰った系+途中まで読んで積んじゃった系。

Scalaスケーラブルプログラミング[コンセプト&コーディング] (Programming in Scala)

Scalaスケーラブルプログラミング[コンセプト&コーディング] (Programming in Scala)

これも貰った系。Scalaいつかやりたいですね(いつになるだろう…

プログラミング言語理論への招待―正しいソフトウェアを書くために (ASCII SOFTWARE SCIENCE Language)

プログラミング言語理論への招待―正しいソフトウェアを書くために (ASCII SOFTWARE SCIENCE Language)

これはつい買っちゃったやつですね。メイヤー本。
紹介文で釣られた(´(ェ)`)=>もうひとつのメイヤー本『プログラミング言語理論への招待』

プログラミングコンテストチャレンジブック

プログラミングコンテストチャレンジブック

蟻本。(買ってから随分と経つ気がする)

Joel on Software

Joel on Software

半分くらい読んでるんだけど、、、

SCRUM BOOT CAMP THE BOOK

SCRUM BOOT CAMP THE BOOK

最近の積読本。この前、@さんに課されました。

ソフトウェアテストHAYST法入門 品質と生産性がアップする直交表の使い方

ソフトウェアテストHAYST法入門 品質と生産性がアップする直交表の使い方

最近の積読本。テスト技法ドリル読んでて、HAYST法ってなんぞということで買った系。

1+2=3―足し算に潜む迷宮

1+2=3―足し算に潜む迷宮

最近の積読本。読み始めてはいますけど、ラムダ計算が知りたくて買いました!

Scheme手習い

Scheme手習い

7割読んで詰んだので積んだ積読本。たぶん今なら読みきれる。

Scheme修行

Scheme修行

続きですね。これも読んでしまいたい。

プログラミングGauche

プログラミングGauche

買った意味あるのかってくらい、最近ユーザーリファレンスと立ち読み版で済ませてることがある積読本。

LET OVER LAMBDA Edition 1.0

LET OVER LAMBDA Edition 1.0

  • 作者: ダグホイト,Doug Hoyte,タイムインターメディアHOPプロジェクト
  • 出版社/メーカー: エスアイビーアクセス
  • 発売日: 2009/07
  • メディア: 単行本
  • 購入: 9人 クリック: 73回
  • この商品を含むブログ (27件) を見る
もうひとつのLOL(ぇ
Land of Lisp読んだら読んでみたい。

初めての人のためのLISP[増補改訂版]

初めての人のためのLISP[増補改訂版]

この前つい追加しちゃった積読本(マテ

Land of Lisp

Land of Lisp

これぞLispの国の為の本!読み始めたけど結構面白いw

なんだかんだでつまみ食いしすぎ…。上に書いた分だけでも今年中に読んでしまいたいですね。

技術書を選ぶ基準。

僕の持ってる技術書は大きくわけて2種類に分けられます。

Lispに関係するか、それ以外か

Lispに関係する*3本は興味本位、面白そう!っていうレベルで購入します。つまり直感を信じよ。
それ以外は何かというと(むしろそれ以外の方が大きいわけですが)、仕事に必要な知識や綺麗なコードを書くためにはとか、どちらかというと実用的*4な知識を身に付けたいので、人に勧められたりした本を優先的に購入します。オブジェクト指向とは何か、とか。

言い換えるなら、学問的実用的か、と言ったところでしょうか。

ここでは実用的な本を選ぶ基準というか、選ぶ上で自分が重視しているなと思うポイントを列挙してみます。*5

  • 本屋で立ち読みをしたことがある
    • 目次を読んだことがある
    • 頭の方はなんとなく読んだことがある
  • Twitterなどで他のプログラマに勧められたことがある
    • 直截的に勧められたことがある
    • ブログ記事で紹介されてるのを読んだことがある
  • Amazonでレビューを読んだことがある
  • 比較的古い書籍である
  • 言語などのバージョンに依存している
  • タイトルに「やさしい」とか「XX日で分かる」とか入っている

僕は本屋によく行くのでプログラミング関連書籍がある本棚に、どういった本があるかはだいたい覚えていて、気になった本は脳内やAmazonの欲しいモノリストに蓄積されていきます。*6本屋で初めて見かけた本を直接そのまま購入することは稀です。気になったら一先ず、欲しいモノリストに入れて、後でレビューとか読んでみます。逆にAmazonレビューまで読んでいるくらいに、気になっていれば本屋で買うこともあります。
新しい本などは本屋にあれば本屋でチェックしていることもあります。目次を読めばなんとなく雰囲気が掴めますし、頭だけでも読めば、ある程度読めば面白いか面白く無いかはなんとなく分かります。あくまでも、「なんとなく」ですが、これが大事。たぶん。気分がいいときは財布の紐が緩いのでなんとなく買っちゃうこともあります。
あと、比較的古くて入手が困難になってそうなものは、サクッと購入するようにしています。コレとかコレとか。
逆に言語/ツールのバージョンに依存しそうな本は避けるようにしてます。「Eclixxx3.x完全攻略!」みたいな本とかはほぼ間違いなく買わないです(いつか買ってみてもいいのかなーとは思いますけど、バージョンに依存するような本は後で使えない気がするので)。それから「簡単」とか「やさしい」とか「XX日間で分かる」といったタイトルの本は避けてます。これは以下に引用する通り。*7

研究者 (Hayes, Bloom) によると、チェス、作曲、絵画、ピアノ演奏、水泳、テニス、そして神経心理学位相幾何学の研究を含む、広範な分野のいずれについても、専門技術を身につけるにはおよそ10年かかるそうだ。近道など実在しないようなのだ。4歳にして音楽の神童だったモーツァルトでさえ、超一流の楽曲を作り出すまでに13年以上を要している。
プログラミングを独習するには10年かかる

最近は自分が読みたい本の情報が勝手に入ってくる状態なので、読みたい本は尽きることはないです。
あとは、一昔前の僕なら「オブジェクト指向入門」を本屋でみても「分厚いなー」くらいの印象で終わってて、読む事はたぶんなかったでしょう。ですが、最近は分厚いとかそういうの関係なしで、「読んだら力になりそう」と思うようになっています。この辺の心境の変化はTwitterや勉強会のお陰でしょうね。たぶん。

まとめ

実家暮らしで、僕の部屋は2階にあるんだけど、本が届くたびに親から「床が抜ける!」と言われるのでそろそろ自炊とかして物理的に減らしたほうがいいんじゃないだろうか…と思い始めた今日この頃です。できるだけ積読は減らしましょう。。。(積読じゃなくても本を読んでいけば、必然的に増えるんでどうしようもないんですけどね!!)

追記

ゴールデンサークルの話もあるけど、「"何故"、この技術を学んだほうがいい」とか本に書いてあると、ついつい買っちゃうかもね。

*1:持ってる人に借りるのも手ですけど、Lispの国で持ってる人探すの大変ですし。プログラマ人口的に。

*2:今、マール・デ・ドラゴーンと合流したとこ

*3:例えばラムダ計算に関する本とかは比較的Lispに近いカテゴリ

*4:Lispが実用的でないというわけではないです

*5:学問的な本は興味があれば買うので、書きようがない…

*6:これ普通ですよね??

*7:違う言語に手を出すときは手に取るかもですけど