ほぼLinuxの専用です。しかもカーネルデバッグにかなりのページを割いてます。
それを期待して読む人は他にないよい本ですが、そうでない人は使えるところが少ないです。
アプリケーションのみ作ってる人は読むところすくない。
無料のKindleアプリをダウンロードして、スマートフォン、タブレット、またはコンピューターで今すぐKindle本を読むことができます。Kindleデバイスは必要ありません。
ウェブ版Kindleなら、お使いのブラウザですぐにお読みいただけます。
携帯電話のカメラを使用する - 以下のコードをスキャンし、Kindleアプリをダウンロードしてください。
Debug Hacks -デバッグを極めるテクニック&ツール 単行本(ソフトカバー) – 2009/4/27
ミラクル・リナックス株式会社の精鋭エンジニアたちが、長年のLinuxカーネル開発の経験で培ったデバッグテクニックを詳解。
こころがまえから、準備、必要な知識、バグの原因をすばやく特定し修正するために便利なテクニックとツール、高度なデバッグ技まで惜しみなく披露します。
多くの事例に基づいた実際的実用的な技が満載です。効率良くかつクオリティーの高い開発のために必須の一冊です。
こころがまえから、準備、必要な知識、バグの原因をすばやく特定し修正するために便利なテクニックとツール、高度なデバッグ技まで惜しみなく披露します。
多くの事例に基づいた実際的実用的な技が満載です。効率良くかつクオリティーの高い開発のために必須の一冊です。
- 本の長さ424ページ
- 言語日本語
- 出版社オライリージャパン
- 発売日2009/4/27
- ISBN-104873114047
- ISBN-13978-4873114040
この商品をチェックした人はこんな商品もチェックしています
ページ 1 以下のうち 1 最初から観るページ 1 以下のうち 1
商品の説明
レビュー
Debug Hacks推薦の言葉
プログラムにはバグが付き物です。バグは人間の予想を超えたところからやってきます。世界最初のバグは、リレー式計算機の中にまぎれこんだ蛾だったそうです。あわれリレーの間に挟まれた蛾によってコンピュータの誤動作が引き起こされました。このエピソードがきっかけとなり、プログラムの間違いのことがバグと呼ばれるようになったのだそうです。この蛾は後にCOBOLの開発者となるグレース・ホッパー女史の日記に記念として張りつけられていたと聞きます。
それから半世紀以上が過ぎ、あいかわらずバグは生み出され続けています。「プログラムは思った通りではなく、書いた通りに動く」というのはプログラマの中に伝わる「ことわざ」のひとつです。そして人間は間違えるものなので、プログラムの中にはバグが入り込みます。ある意味、バグとは人間の限界を見せつけてくれるものなのかもしれません。ほとんどのバグはちょっとプログラマを悩ませるくらいのかわいいものですが、最近はバグによって引き起こされた「事件」によって新聞をにぎわすようなこともたびたび起きています。
プログラマの仕事はプログラムを作ることですが、コンピュータが社会に浸透し、プログラムが複雑化するに従って、完全なプログラムを書くことは非常に困難になってきています。その結果、すべてのプログラマは必然的にバグに対処する必要があります。個人的にはプログラマの時間の大半が、バグを見つけることと、それらを直すことに費やされているのではないかと感じます。
しかし、ただやみくもにバグを探してもうまくいくわけはありません。バグにはバグの見つけ方があり、直し方があるのです。特にバグを見つけだし、特定するにはさまざまなテクニックが存在します。「デバッグ」という言葉は「バグを直すこと」のような印象がありますが、実際にはどこにあるのか特定されたバグはまったく恐ろしいものではなく、たいていはすぐに直すことができるものです。デバッグの神髄はバグの発見と特定にあるのです。本書は歴戦のプログラマが経験から獲得したバグの見つけ方・直し方が満載されています。特に普段はお目にかからないようなLinuxそのもののバグについてのHackは、貴重な情報ではないかと思います。いくつかのHackは多くのプログラマが日常的に使うものではないかもしれませんが、それでもなおその発想は参考になります。特にgdbやvalgrindやoprofileのような便利なツールについてきちんと解説してあるのがありがたいところです。また、2つほど Rubyの「バグ」についても扱っていただいてます。ありがたいことです。
本書がプログラマの皆さんのバグへの戦いの日々が少しでも楽になるための「道標」となることを期待しています。
2009年3月 羽田空港にて
まつもとゆきひろ --『Debug Hacks』刊行に寄せて
プログラムにはバグが付き物です。バグは人間の予想を超えたところからやってきます。世界最初のバグは、リレー式計算機の中にまぎれこんだ蛾だったそうです。あわれリレーの間に挟まれた蛾によってコンピュータの誤動作が引き起こされました。このエピソードがきっかけとなり、プログラムの間違いのことがバグと呼ばれるようになったのだそうです。この蛾は後にCOBOLの開発者となるグレース・ホッパー女史の日記に記念として張りつけられていたと聞きます。
それから半世紀以上が過ぎ、あいかわらずバグは生み出され続けています。「プログラムは思った通りではなく、書いた通りに動く」というのはプログラマの中に伝わる「ことわざ」のひとつです。そして人間は間違えるものなので、プログラムの中にはバグが入り込みます。ある意味、バグとは人間の限界を見せつけてくれるものなのかもしれません。ほとんどのバグはちょっとプログラマを悩ませるくらいのかわいいものですが、最近はバグによって引き起こされた「事件」によって新聞をにぎわすようなこともたびたび起きています。
プログラマの仕事はプログラムを作ることですが、コンピュータが社会に浸透し、プログラムが複雑化するに従って、完全なプログラムを書くことは非常に困難になってきています。その結果、すべてのプログラマは必然的にバグに対処する必要があります。個人的にはプログラマの時間の大半が、バグを見つけることと、それらを直すことに費やされているのではないかと感じます。
しかし、ただやみくもにバグを探してもうまくいくわけはありません。バグにはバグの見つけ方があり、直し方があるのです。特にバグを見つけだし、特定するにはさまざまなテクニックが存在します。「デバッグ」という言葉は「バグを直すこと」のような印象がありますが、実際にはどこにあるのか特定されたバグはまったく恐ろしいものではなく、たいていはすぐに直すことができるものです。デバッグの神髄はバグの発見と特定にあるのです。本書は歴戦のプログラマが経験から獲得したバグの見つけ方・直し方が満載されています。特に普段はお目にかからないようなLinuxそのもののバグについてのHackは、貴重な情報ではないかと思います。いくつかのHackは多くのプログラマが日常的に使うものではないかもしれませんが、それでもなおその発想は参考になります。特にgdbやvalgrindやoprofileのような便利なツールについてきちんと解説してあるのがありがたいところです。また、2つほど Rubyの「バグ」についても扱っていただいてます。ありがたいことです。
本書がプログラマの皆さんのバグへの戦いの日々が少しでも楽になるための「道標」となることを期待しています。
2009年3月 羽田空港にて
まつもとゆきひろ --『Debug Hacks』刊行に寄せて
著者について
吉岡弘隆(Hiro Yoshioka):
ミラクル・リナックス所属のプログラマ。カーネル読書会というLinuxの技術系勉強会を1999年から主宰している。慶応義塾大学大学院修了。日本ディジタルイクイップメント(DEC)研究開発センタ、日本オラクルを経てミラクル・リナックスを創業。大学を卒業以来、数々のソフトウェア製品(日本語COBOL、DEC Rdb、Oracle 8、MIRACLE LINUX、Asianux等)の開発を行ってきた。
JIS X0208:1990/X0212:1990の標準化。U-20プログラミングコンテスト審査委員、セキュリティ&プログラミングキャンプ、プログラミング部門主査。
大和一洋(Kazuhiro Yamato):
ミラクル・リナックスで働くソフトウェアエンジニア。これまでは、LinuxカーネルやGLIBCまわりの仕事が中心であったが、最近では、gstreamerなどのメディア関連のハックにも精を出す。GUIツールは苦手で、開発環境はもっぱら、vim + gcc + gdb。
大岩尚宏(Naohiro Ooiwa):
ミラクル・リナックス株式会社勤務のソフトウェアエンジニア。携わった業務は開発よりもカーネルの調査・解析が多く、ドライバ・ネットワーク・ファイルシステムなど数多くの幅広いバグを担当。バグであればのなんでも引き受ける。最近ではLinuxにおける省電力を検証している。絵は得意だが、日本語・英語が苦手。上司にはコミュニティにパッチを出すよう急かされる。日本を代表するLinux開発者に会う機会が多い。
安部東洋(Toyo Abe):
ミラクル・リナックス所属のソフトウェアエンジニア。Hello Worldプログラムもロクに書けない状態からLinuxカーネルの世界に入ってしまい、泣きそうになった経験を持つ。今までx86アーキテクチャだけだったので、執筆が一段落したらARMに挑戦しようと企てている。
吉田俊輔(Shunsuke Yoshida):
ミラクル・リナックス所属のシステムエンジニア。どこにでもいる自称、一般人。地方ソフトウェア企業からメーカー系SI企業を経てミラクル・リナックスに入社。OS/DataBase/Network/仮想化等のインフラ系SE。小江戸らぐ/YLUG(横浜LinuxUsersGroup)/USAGI補完計画等、関東近郊のOSSコミュニティに参加。イベント参加/出展や原稿執筆を行っている。
ミラクル・リナックス所属のプログラマ。カーネル読書会というLinuxの技術系勉強会を1999年から主宰している。慶応義塾大学大学院修了。日本ディジタルイクイップメント(DEC)研究開発センタ、日本オラクルを経てミラクル・リナックスを創業。大学を卒業以来、数々のソフトウェア製品(日本語COBOL、DEC Rdb、Oracle 8、MIRACLE LINUX、Asianux等)の開発を行ってきた。
JIS X0208:1990/X0212:1990の標準化。U-20プログラミングコンテスト審査委員、セキュリティ&プログラミングキャンプ、プログラミング部門主査。
大和一洋(Kazuhiro Yamato):
ミラクル・リナックスで働くソフトウェアエンジニア。これまでは、LinuxカーネルやGLIBCまわりの仕事が中心であったが、最近では、gstreamerなどのメディア関連のハックにも精を出す。GUIツールは苦手で、開発環境はもっぱら、vim + gcc + gdb。
大岩尚宏(Naohiro Ooiwa):
ミラクル・リナックス株式会社勤務のソフトウェアエンジニア。携わった業務は開発よりもカーネルの調査・解析が多く、ドライバ・ネットワーク・ファイルシステムなど数多くの幅広いバグを担当。バグであればのなんでも引き受ける。最近ではLinuxにおける省電力を検証している。絵は得意だが、日本語・英語が苦手。上司にはコミュニティにパッチを出すよう急かされる。日本を代表するLinux開発者に会う機会が多い。
安部東洋(Toyo Abe):
ミラクル・リナックス所属のソフトウェアエンジニア。Hello Worldプログラムもロクに書けない状態からLinuxカーネルの世界に入ってしまい、泣きそうになった経験を持つ。今までx86アーキテクチャだけだったので、執筆が一段落したらARMに挑戦しようと企てている。
吉田俊輔(Shunsuke Yoshida):
ミラクル・リナックス所属のシステムエンジニア。どこにでもいる自称、一般人。地方ソフトウェア企業からメーカー系SI企業を経てミラクル・リナックスに入社。OS/DataBase/Network/仮想化等のインフラ系SE。小江戸らぐ/YLUG(横浜LinuxUsersGroup)/USAGI補完計画等、関東近郊のOSSコミュニティに参加。イベント参加/出展や原稿執筆を行っている。
登録情報
- 出版社 : オライリージャパン (2009/4/27)
- 発売日 : 2009/4/27
- 言語 : 日本語
- 単行本(ソフトカバー) : 424ページ
- ISBN-10 : 4873114047
- ISBN-13 : 978-4873114040
- Amazon 売れ筋ランキング: - 558,738位本 (本の売れ筋ランキングを見る)
- - 11,968位電気・通信 (本)
- カスタマーレビュー:
著者について
著者をフォローして、新作のアップデートや改善されたおすすめを入手してください。
著者の本をもっと発見したり、よく似た著者を見つけたり、著者のブログを読んだりしましょう
著者の本をもっと発見したり、よく似た著者を見つけたり、著者のブログを読んだりしましょう
著者の本をもっと発見したり、よく似た著者を見つけたり、著者のブログを読んだりしましょう
カスタマーレビュー
星5つ中4.2つ
5つのうち4.2つ
全体的な星の数と星別のパーセンテージの内訳を計算するにあたり、単純平均は使用されていません。当システムでは、レビューがどの程度新しいか、レビュー担当者がAmazonで購入したかどうかなど、特定の要素をより重視しています。 詳細はこちら
9グローバルレーティング
虚偽のレビューは一切容認しません
私たちの目標は、すべてのレビューを信頼性の高い、有益なものにすることです。だからこそ、私たちはテクノロジーと人間の調査員の両方を活用して、お客様が偽のレビューを見る前にブロックしています。 詳細はこちら
コミュニティガイドラインに違反するAmazonアカウントはブロックされます。また、レビューを購入した出品者をブロックし、そのようなレビューを投稿した当事者に対して法的措置を取ります。 報告方法について学ぶ
-
トップレビュー
上位レビュー、対象国: 日本
レビューのフィルタリング中に問題が発生しました。後でもう一度試してください。
2009年4月29日に日本でレビュー済み
まず記載されている技術的内容に関しては素晴らしいの一言に尽きる。確かにDebugに関する情報がきちんと網羅されている本は今まで無かった。弱点はICEなどの専用ハードウェアを使ってのデバッグに関する情報が全く無いこと、ぐらいなもの。この段階で☆は8つ。
しかし、推敲・校正の段になるとぼろぼろ。これでは初心者が読んでいて混乱・誤解をする。
例1) Hack#5 p27 3段落目「Fは先に示した表示のフォーマット(.... i)、(以下略)」とあるが、「先に示した表示」にiは無い(表にiが抜けている)。
例2) p28-29「ステップ実行」2段落目「実行するものが関数などの場合、その関数の中も実行したい場合があります。そのときは、stepコマンドで行います」。おそらくここでいう「実行」は「ステップ実行」の事なのだろう。nextは「次の行に到達するまで、実行がbreakされない」が、stepは「ソースコード上の別の行に到達するまで命令レベルの実行を1つづつ実施する」。
しかしこの本の表現では「関数内部は実行されない」と読めてしまう。これでは意味が全く違なってしまう。
「はじめに」に『想定している読者は、(中略)初級から中級プログラマです』とある以上、これら初心者にとって致命的な誤記は大幅な減点対象になる。私は☆5つ減じることにした。故にこの本の評価は☆3つだ。
是非次に印刷するときは「第2刷」ではなく「第2版」として大幅に内容の治ったものを出していただきたい。
しかし、推敲・校正の段になるとぼろぼろ。これでは初心者が読んでいて混乱・誤解をする。
例1) Hack#5 p27 3段落目「Fは先に示した表示のフォーマット(.... i)、(以下略)」とあるが、「先に示した表示」にiは無い(表にiが抜けている)。
例2) p28-29「ステップ実行」2段落目「実行するものが関数などの場合、その関数の中も実行したい場合があります。そのときは、stepコマンドで行います」。おそらくここでいう「実行」は「ステップ実行」の事なのだろう。nextは「次の行に到達するまで、実行がbreakされない」が、stepは「ソースコード上の別の行に到達するまで命令レベルの実行を1つづつ実施する」。
しかしこの本の表現では「関数内部は実行されない」と読めてしまう。これでは意味が全く違なってしまう。
「はじめに」に『想定している読者は、(中略)初級から中級プログラマです』とある以上、これら初心者にとって致命的な誤記は大幅な減点対象になる。私は☆5つ減じることにした。故にこの本の評価は☆3つだ。
是非次に印刷するときは「第2刷」ではなく「第2版」として大幅に内容の治ったものを出していただきたい。