ダメな技術書の見定め方 - Qiita

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 技術書を自分のお金で買うようになってから、かれこれ十数年。 ダメな技術書が放つ独特のニオイがやっとわかるようになってきたので、書いてみました。 以下、主観を多分に含みます。「あー、あるある」と思いながら軽く読んでくださいね。 (逆バージョンの「良書のみつけかた」は、近日公開予定でございます。) ダメな技術書の「あるある」 誤字・脱字が多い 推敲に時間を割いてないことの証拠である。よって誤字・脱字が多い本は技術書としてもクソ本である確率が高い。 正誤表・サポートページがない 多少の誤字・脱字は仕方がないとしても、それを Web で補う気す

[pmakino]

大半が特定の1冊のことを指しているような気がしたが気のせいかもしれない。あと「Amazonの評価が低い」「Amazonで古本を破格で買える」あたりもありそう。

[longroof]

印刷された瞬間に時間が止まるんだよねぇ(；´Д｀)

[bitgleams]

こういうのって著者がアレな場合と編集（者 or 社）がアレな場合とがあって、後者の方がより一層注意が必要なのかもと思う。

[wkoichi]

id:shigeo-t SQLクックブック http://www.oreilly.co.jp/books/9784873113159/ などの、xxクックブック のことかと

[HIN]

http://www.google.co.jp/search?q=%E3%82%AB%E3%82%B9%E3%82%BF%E3%83%9E%E3%83%BC%E3%83%AC%E3%83%93%E3%83%A5%E3%83%BC+%E8%AA%A4%E5%AD%97+%E8%84%B1%E5%AD%97+site%3Aamazon.co.jp

[mizchi]

サンプルが動かないのは事前に見極めるの難しい。誤字脱字はそこまで問題になったことはない。アカデミック寄りな著者だと参考文献が多くなる。良い本かどうかはだいたい著者に依存する。ぐぐれ。

[fumisan]

参考文献は求められるんだよ。レビューアの賛辞ってどうかなぁ。どっちにしても書籍を出す側がいい。

[theatrical]

ぶっちゃけこんな事考えなくてもAmazonレビュー見ればおｋ

[knjname]

初心者向けのクソ本、翻訳がクソな本がほとんどな気がする。あとひたすらソースコード貼っている本はクソ。記述が簡潔すぎるのもクソ。

[toshikaz55]

ダメな技術書の見定め方 by @nappa on @Qiita

[gogatsu26]

"2005年以前のJavaの本、2009年以前の Ruby・Ruby on Rails の本、2006年以前の JavaScript の本、2005年以前の MySQL の本は概ね使えない"

[natsutan]

あとで

[gokichan]

個人的にはクックブックはありだけど、ＷＥＢで調べた方が早かったりするから、そのそもあまり技術書は買ってない。それこそ公式リファレンスくらいか。

[tak4hir0]

ダメな技術書の見定め方 - Qiita

[yujiorama]

翻訳と自著は分けて考えたい

[uasi]

こういうの誰の本のどこに間違いがあるか明示してったほうがよさそう

[taka222]

”ダメな技術書の見定め方 - Qiita [キータ]”

[rishida]

技術書を自分のお金で買うようになってから、かれこれ十数年。 ダメな技術書が放つ独特のニオイがやっとわかるようになってきたので、書いてみました。 以下、主観を多分に含みます。「あー、あるある」と思いながら

[shigeo-t]

「クックブック」って誤字脱字？料理の技術書なら間違いじゃないけど。

[i2key]

誤字脱字はエンジニアを面談するときに経歴書で結構きにするなぁ。それをコードでやったらコンパイル通らないし、CoC効かないし。

[nekoruri]

ニフクラ本も誤字脱字は頑張って減らしたつもりだけど、開き直るとかは信じがたい。執筆ってコミュニケーションの一種じゃ無いの？読んで欲しいから本書くんだよね？