データベースをつつく5－関係モデル以外のモデルについての補足説明

ボクは関係モデルしか使ったことがないので、他のモデルについて少し調べたピヨ♪やっぱり、好奇心が疼くよね♪幾つかの文献を見てみると、ネットワークモデル、階層モデル、エンティティ関係モデル、エンティティ属性関係モデル、バイナリ関係モデルなどがあったそうだピヨッ。
先ずはネットワークモデルについて囀るピヨ。ネットワークモデルはレコードとポインタで構成されるモデルピヨ。例えば、社員レコードの所属部署データは、部署レコードへのポインタ・・・という風に実現されているピヨ。C言語ぽい構造ピヨね。このモデルは、その特徴から察しが付くと思うけど、現実をモデル化しにくいという弱点があるピヨ。もちろん馴れた人ならばかなり高度な事を出来るだろうけど、モデルは対象となる現実を表すものだから、ちょっとモデルとしては問題あるピヨ。あと、レコードとポインタで実現されているって事は、必要とされているデータが2倍になるという事ピヨ。おまけにSQLのような言語を策定する際に、レコードとポインタを操作する構文が必要になるから問い合わせ言語も作り難いよね。これが廃れた原因だとボクは思うピヨ。
次は階層構造を囀るピヨ。階層構造は一言で言うとツリー構造のモデルピヨ。これはB-Treeなどのアルゴリズムがある事を考えればわかるように、プログラマの思考とマッチしていて結構有効だったんだ。それで結構流行ったらしい。だけど、 現実をツリー構造に無理やり押し込めるから、モデルとしては不十分だったんだ。それらなら、直接プログラミングした方が早いしね。モデルにする意味が無いピヨォ。残念だね。
あと、バイナリ関係モデルなどのマイナーなモデルが数多く発明されたんだけど、はっきりいって普及しなかったピヨ。その中で生き残った発明がオブジェクト指向データベースなんだけど、オブジェクト指向データベースはかなり巨大なトピックなのでこっちでは詳しく説明しないピヨォ。
これらのモデルの歴史を調べて思ったんだけど、昨今搭載可能なメモリ容量がかなり増えているから、メモリ内データベース管理ソフトを考えた場合階層型モデルも結構ありかもしれない♪見方を変えれば、XMLデータベースもDOMとして扱う際にツリー状態だからね♪あと、ネットワークモデルについてもセマンティックWebとか、ニューロンコンピューターとかに適しているモデルと思うピヨ。こんな風に、情報処理技術では滅びた技術が華麗なる復活を遂げる事があるから注意が必要ピヨ♪温故知新ピョッ♪

Adaをつつく6ーcase文。おばあちゃん複数から厳格に選ぶ。

前回if文をつついたから今回は複数条件分岐をつつくピヨ♪Adaでも複数の条件を判定する文があるピヨッ。Adaの場合はcase文で複数条件分岐を行うピヨォッチ。じゃあ早速、つついてみよう♪

with Ada.Text_Io; use Ada.Text_Io;
with Ada.Integer_Text_IO;

procedure CaseSample is

Num : Integer := 0;
Positive : Integer := 0;

begin
  --値を入力
  Put ("好きな数値を入力してEnterキーを押すピヨ♪：" ); 
  Ada.Integer_Text_IO.Get ( Num,  Positive);
  
  --入力値
  Put ( "入力された数値は" );
  Ada.Integer_Text_IO.Put ( Num, Width => 1 );
  Put ( "ピヨ♪" );
  New_Line;
  
  --case文
  case Num is
    when 0 => Put_Line ( "無我の境地だね♪" ); 
    when 3 | 6 | 9 => Put_Line ( "ピヨォーん" );
    when 10 .. 100 => 
      Put_Line ( "結構ありがちな数値だよね♪" );
      Put_Line ( "そうそう複数行ある場合はこう書くんだよ♪" );
    when others => Put_Line ( "予想外の数値だね♪" );
  end case;
  
end CaseSample;

どう？独特でしょ。=>記号を使う所なんか結構ユニークピヨ♪だけどそれは表面的な事で、Adaは厳格な言語なんだ。それこそが本当の特徴ピヨ♪例えば、othresを指定しないとエラーになるところなんか厳格ピヨッ。VBとかだと全ての条件に当てはまらない場合実行されないだけだけど、Adaだとエラーになるんだ。Adaおばあちゃんは本当に厳格だねぇ。あと、必ず＝じゃなくてはならないから・・・

when Num < 0

だとエラーになるピヨォ！エラーメッセージを読むと、どうやらNum < 0の結果とNumの等価性を判定しようとしているらしい。それで、BooleanとIntegerの型が違うからエラーが発生するというわけ。うーん厳しいぃー。そこのところは融通して欲しいけど、そんな厳格さがAdaの売りピヨ。Num < 0の様な事をしたければif文を使おう！

VB.NETをつつく30－部分型1。合体後の属性はどうなる？

今日も朗らかにVB.NETをつつくピヨ♪部分型はまだまだ謎が残っているから、今回も部分型をつつくピヨ♪ ボクが一番最初部分型を知って疑問に思ったのが属性を複数かつバラバラに指定したらどうなるの？だったピヨ♪そんなふうに迷った時は黙って打つべし♪打つべし♪


Public Class AttributeA Inherits Attribute End Class Public Class AttributeB Inherits Attribute End Class <AttributeA()> _ Public Class ClassA End Class '違うファイルで宣言しているピヨ <AttributeB()> _ Partial Public Class ClassA End Class Module Module1 Sub Main() Dim a As Type = Type.GetType("PartialTest.ClassA") For Each result As Object In a.GetCustomAttributes(False) Console.WriteLine(result.GetType().Name) Next End Sub End Module

結果は・・・全ての属性が適用されるようだね♪便利なような気もするけど、これも思わぬバグを生みそうだッピヨ♪万が一、相性が悪い属性が適用されたらやっかいなバグを生むよね。だから部分型の機能を使う時は設計時に注意しよう♪出来ることならば、1人１クラスを担当したら無難だと思うピヨ。でも、デザイナとプログラマが別れている場合もあるから、その時は属性の適用を慎重に行おう。属性はバグが発見し難いから要注意ピヨ♪

VB.NETをつつく29－部分型。コード合体♪

今回は部分型をつつくピヨ♪部分型はVSを使っている人ならばおなじみだと思うピヨ♪VB.NETでWindowsフォームアプリケーションを作ると次の様なコードが作成されるよね？

Public Class Form1

End Class

これだけだと何のことやら分からないピヨ。普通にしか見えないからね。じゃあ他のファイルがどこにあるのかというと、VSのソリューシュンエクスプローラで、左から2つ目にある「全てのファイルを表示」とチップで表示されるボタンをクリックしてから、ソリューシュンエクスプローラ上にあるForm1.csの+をクリックしてみよう。すると、Form1.Designer.vbというファイル名が見つかるピヨね。このファイルを覗いてみよう。


<Global.Microsoft.VisualBasic.CompilerServices.DesignerGenerated()> _ Partial Class Form1 Inherits System.Windows.Forms.Form 'フォームがコンポーネントの一覧をクリーンアップするために 　　’dispose をオーバーライドします。 <System.Diagnostics.DebuggerNonUserCode()> _ Protected Overrides Sub Dispose(ByVal disposing As Boolean) Try If disposing AndAlso components IsNot Nothing Then components.Dispose() End If Finally MyBase.Dispose(disposing) End Try End Sub 'Windows フォーム デザイナで必要です。 Private components As System.ComponentModel.IContainer 'メモ: 以下のプロシージャは Windows フォーム デザイナで必要です。 'Windows フォーム デザイナを使用して変更できます。 'コード エディタを使って変更しないでください。 <System.Diagnostics.DebuggerStepThrough()> _ Private Sub InitializeComponent() components = New System.ComponentModel.Container() Me.AutoScaleMode = System.Windows.Forms.AutoScaleMode.Font Me.Text = "Form1" End Sub End Class

察しがいい人はもう分かったと思うけど一応囀るピヨ。

Partial Class クラス名

と打つと部分型を宣言したことになるピヨ♪

見てのとおりこっち側はPartial Classって宣言されているピヨッ♪こんな具合に複数のファイルで一つの型を記述できるピヨ♪複雑な型を書いている時に便利かもね♪
これは一件単純な機能だけど、よく考えると幾つかの疑問が頭をよぎるピヨね。まず気になるのは1つのファイルで部分型を宣言した場合の事ピヨ。部分型というんだから、一つにしたら不味いのかな？疑問が出たら即実装！実際にやってみたピヨ♪

Partial Class PartialClass

    Shared Sub Main()

    End Sub

End Class

さてどうなるのかな♪エラーもしくは警告が表示されるかな♪わく♪わく♪・・・
結果は、残念ながら何にも起こらなかったピヨォ。何かが起こることをちょっと期待したんだけど、まぁ部分型と宣言しておいて、1ファイルで記述しても問題は無いピヨ。一旦コンパイルしたい時もあるからね。
といっても問題ないのは、直ぐ後で違うファイルへ型を書く場合のみピヨ。ありふれた名前の型を無闇に部分型にしてしまうと偶然に一致してしまう事があるから、原則的にはPartialは書かないほうがいいピヨ。ある程度大きなプロジェクトで、偶然に複数のファイルに同じ型名があった場合の挙動が予測できなくなるから駄目ピヨ。とはいえ、同じ型名がある事自体が設計ミスなんだけど、設計ミスはありふれた事だから無理して書かないほうが無難ピヨ。
ちなみに、構造体とインターフェイスにも使えるピヨ。クラスだけじゃなくて、部分インターフェイス、部分構造体に出来るって事だね♪なるピヨ、だから部分型なんだね♪他にもつつきたいことは沢山あるけど、長くなりすぎるので次回へ続く♪

ネタつつき11－出来ない子はどうすればいいのか？

前回の記事を読んだ人の中には「じゃあ出来ない子はどうすればいいのか」と疑問に思っただろうから今回はそのことについて書きます。最初に断っておきますが、私も元々出来ない子であり、もしかしたら今でもそうかもしれません。世間一般の評価は分かりませんが、少なくとも理想の私からすれば１％ぐらいしか達成しておりませんので、そういった意味では今でも出来ない子です。
前回お話したように、この業界は一件出来ない子に優しいようで、実は物凄く不親切です。育てる気なぞ無いところが多いでしょう。しかし誰しも最初は、よほどの天才以外は全員が出来ない子なので、そのままでは永遠に出来ない子です。では、どうすればよいのでしょうか？私が自身の体験と様々な人から意見を聞いた事を基にして考えるに、最初っから企業を当てにせずに自身で鍛える事を考えるのがベストだと思います。そして、スキルアップにならない会社は見捨ててしまいましょう。冷たいようですが会社は責任を取ってくれません。凄く身勝手なものです。そんな会社に忠誠を誓う必要はありません。会社が技術者個人を利用するのならば、技術者の方も合理的に会社を利用しましょう。これ以降は具体的な方法を述べます。
まずするべき事は理想の自分を考える事です。何事もそうですが目標も無く漫然と生きていては永遠に出来ない子です。具体的な目標を持ちましょう。その際気をつけなければいけないのは、長期的目標と短期的目標の両方を考える事です。情報処理技術の進化は早く、特定の言語や技術の修得だけを目標としてしまうと、その言語や技術が廃れてしまった時に対応できません。長期的な目標は抽象的なものとし、短期的な目標として、長期的目標を実現するための細かいステップを設定しましょう。具体例がないと分かり難いと思いますので、私自身を例としてあげます。

私が理想とする技術者は、OS・コンパイラ・DBMS・ネットワークプロトコルといったシステムソフトウェアを実装する能力を有し、既存の命令型言語・関数型言語・スクリプト言語・論理型言語・タグ系言語をあわせて最低１０個マスターし、既存のOSに関するカーネルレベルの知識やデーベースとネットワーク関する深い知識を有しており、システムソフトからシステム構築までこなせる職人です。
その理想像を叶える為に短期目標として半年に1度目標を立てました。例えば今年は、STLの実装、および、WPF・WF・WCF・LINQの修得を短期目標として設定しています。

以上の様に、まず理想像を考えて、その人物が持つであろう知識とスキルを決定し、その知識やスキルを細分化していき、それを短期目標としております。コツは変更を恐れない事です。知識が増すに従って、技術の細部がみえてきますので、短期目標に変更が生じる事が多々あります。しかしそれを恐れてはなりません。以前の知識が無い自分が立てた計画は間違っているのですから、その過ちを冷静に正さねばなりません。念のために注意しておきますが、かといって、長期計画や理想像はあまり変更してはなりません。この根っこの部分がブレると自分が見えなくなります。くれぐれも注意してください。


ここまで読んだ人の中には「理想像が分からないから困っている」と感じる人が居るかもしれません。でも、自分探しの旅へ行くのはちょっと待ってください。そういった人の為に私がヒントを書きます。私の場合は幸か不幸か、中学生の時にPCを見た瞬間に一目惚れして、それ以降はブレた事がありません。そこから以降私の人生＝情報処理技術の探求です。毎日それだけを考えて生きています。しかし、そうでない人の方が大半らしいですね。そのような場合は、無理して自分探しをせずに、気持ちをリラックスさせて、とにかく好きな事を勉強するのが一番です。そうすれば、自分が見えてくるでしょう。しかしそれは、受身では駄目です。積極的に活動しましょう。自分を知っているのは自分だけなのですから・・・
私のお勧めとしては勉強会へ参加するのがいいと思います。そうすれば、自ずと自分が好きな事が見えてきます。もちろんこの時も受身では駄目です。積極的に勉強しようとする姿勢が大事です。後考えられる手段としてはインターネットを彷徨うか、作りたい物を自分自身に聞いてみましょう。もし、何も作りたいものが無く興味も無ければ違う分野をお勧めします。情報処理技術だけがこの世の全てではありません。仲間が減るのは残念ですが、どうしても情報処理技術が好きになれないのであれば、違う人生を模索するのも一つの手です。

最後に誤解が蔓延していますので明記しておきます。情報処理技術に年齢制限はありません。未だに35歳定年説などを信じている愚かな人が居ますが、どんな技術でも10年は修行が必要なので、あっという間に35歳になってしまいます。ですから、35歳なんて事は馬鹿げた迷信です。それに、何歳であろうとハッカーは居ます。私が聞くところによると、下は5歳、上は70歳ぐらいまでの幅があるようです。年齢を言い訳にせずに今すぐ始めましょう。自分の人生を決めるのは他の誰でもありません貴方自身なのです。

リモートアドバイザーサービス

情報処理技術（IT）の進化は激しく、一社だけではスキルレベルの保持が難しくなってきました。おまけにこの不景気で、教育費と時間をあまり掛けられません。非常に過酷な状態といえるでしょう。 その状態を踏まえ、私は譲歩産業に如何に貢献するかを考えました。その末思いついたのがこのリモートアドバイザーサービスです。
サービス内容はと申しますと、一言で言いますと、メールにて情報処理技術に関するアドバイスを行うサービスです。インターネットには技術者達の掲示板があり、そこで活発に情報がやり取りされております。しかし、セキュリティ上やビジネス上必ずしもそれら技術掲示板が適してるとはいえません。何故ならば、お客様の情報やプロジェクトの詳細を外部に漏らすことは出来ませんので、的確な情報を得られなくなります。ですが、私一人ならばビジネス上必要な機密保持は守られますし、より的確で速い情報を提供出来ます。概要は以上です。これらから詳細なサービスの説明に入ります。


【基本事項】

• 営業時間・・・営業時間は9～18時で、12時～13時は昼休憩となっております。
• 休日・・・当方は土日祭日はお休みさせていただきます。
• 守秘義務・・・本サービスを利用して知りえたお客様に関する情報は一切洩らしません。ただし、情報処理技術などの汎用的な知識は此に該当しません。
• サービス期間・・・サービスを開始する旨の連絡をメールにて行いますので、その時からの開始となります。終了日数は30日です。ただし、当方の営業休止日は除きます。ですから申し込んだ月による優劣はありません。
• 営業時間外の対応・・・24時間質問は受け付けておりますが、営業時間外の返信は致しません。ご注意ください。
• 限界について・・・個人で提供しているサービスなので、あまりにも忙しい場合お断りする事があります。先着順にて対応いたしますのでご注意ください。
• 纏め買いについて・・・1年分（30日＊12）を纏めて買えば1月分値引きします。
• 単価について・・・単価設定は1メールアドレス（1社分）に設定されています。そうしないと、お客様を装う人が出てくるからです。もし複数のメールアドレスを使用したいのならば予め言ってください。

【サービス内容と料金】

• Windowsプログラミングコース（税抜き価格：1月15万円）・・・メールのやり取りにてお客様の質問に答えます。本サービスで質問に答えられる内容はWindows系プログラミングです。より広範囲な内容は別途オプションにて提供します。
• データベース設計コース（税抜き価格：1月30万円）・・・メールのやり取りにてお客様の質問に答えます。本サービスで質問に答えられる内容はデータベースの設計についてです。
• 業務支援コース（税抜き価格：1月5万円）・・・普段の業務でどのように情報処理技術（通称：IT）を使えばいいのかをアドバイスします。このコースはIT系で無い会社用のコースです。コンピューターをどう導入していいのか分からないものの、IT会社に発注する余裕のない会社に最適なコースです。
• 優先レベルオプション（税抜き価格：1月1万円）・・・本サービスは複数のお客様に向けて提供しております。その際、お客様の優先順位を考慮して答える順番を決めます。これは1口の価格で、購入口数により、優先度レベルが１上がります。なるべく早く回答が欲しい場合は、このオプションを購入してください。

【注意事項】

• 品質保証について・・・本サービスはベストエフォート型サービスです。最大限の努力はいたしますが、100％の保障をするものではありません。
• 取り扱わない範囲・・・クラッキング技術などの犯罪に関わる質問には一切お答えできません。
• 質問全般について・・・私が知っているのは業務系なので、ゲーム系や制御系の質問にはお答えできません。また、情報処理技術全般についても私が知らない事がありますので、お答えできない場合がありえます。あらかじめご了承ください。
• 返金について・・・返金はいたしません。本サービスを申し込む前によく検討してください。
• 損害について・・・本サービスはあくまでもアドバイザーサービスですので、最終的な判断をするのはお客様自身です。従って、いかなる業務上の直接損害および間接的損害についても賠償いたしません。
• その他・・・極力丁寧な対応を心がけているものの私は職人型の人間ですので、たまに厳しい発言をします。その点は先にご了承ください。

【ご利用の流れと手続き】

1. 注文・・・本サービスを購入する旨をメール（ ）にてご連絡ください。その際には、注文内容・住所・お名前・使用するメールアドレス・知りたい範囲を必ず明記してください。
2. 確認・・・注文の際に御聞きしたメールアドレスに確認用メールを送ります。注文内容が正しいかよくご確認下さい。
3. お支払い・・・支払い方法は代金引換の前払いになっております。請求する前に予めその旨をメールにて連絡致しますので、当サービスを語った詐欺にご注意ください。
4. サービス開始通知・・・本サービスの準備が整い次第メールにてご連絡します。この日からサービス開始となります。この通知が1週間以上こない場合は当方にご連絡下さい。

※以上の記述はまだ不完全なので随時情報を追加します。本サービスについての質問がある方は、この記事のコメント欄に書き込んでください。

書籍をつつく63－Linkers & Loaders。貴重な一品。

さっき、リンカとローダについて触れたからこの書籍を紹介するピヨ♪
Linkers & Loaders
目次は・・・


【目次】

第1章 リンクとロード
第2章 アーキテクチャに関する問題
第3章 オブジェクトファイル
第4章 記憶領域の割り当て
第5章 シンボルの管理
第6章 ライブラリ
第7章 再配置
第8章 ロードとオーバレイ
第9章 共有ライブラリ
第10章 動的なリンクとロード
第11章 高度なテクニック

この本は題名を見たら分かると思うけどリンカとローダについて書かれた本ピヨ。この本はそれ以上でもないし、それ以下でもないピヨ。リンカとローダについて書かれた本は凄く稀少だからそれだけでも価値があるピヨ♪だけど、一つ残念なことがあるピヨ。それは、この本だけではリンカとローダが実装できない事ピヨ。唯一の情報源なんだから実装法を一から解説して欲しかったピヨ。１万円しても良いからとにかくリンカの実装法を詳細に知りたいピヨォッ！！！

書籍をつつく62－システムソフトウェアプログラミング コンパイラの設計法と並行処理の基礎。隠れた名著。

昨日書籍棚を見ているとまだ紹介していないコンパイラ本がある事に気付いたピヨ♪
それがこの・・・
システムソフトウェアプログラミング―コンパイラの設計法と並行処理の基礎ピヨ
これ知名度は低いけど、結構いいよぉー。


【目次】

第1章 機械語
第2章 アセンブラ言語
第3章 リンカとローダ
第4章 コンパイラ理論の基礎
第5章 コンパイラの実例―Lil’LuxLykコンパイラの設計
第6章 並行処理の基礎と同期
第7章 オペレーティングシステム
第8章 UNIXとWin32 APIの並行処理機能

ボクは当時コンパイラ本を探してインターネットを飛び回っていたんだけど、この本を探すのは苦労したピヨ。だから、そんな仲間の為にこの書籍をコンパイラ本として紹介するピヨッ♪この本の特徴はリンカとローダの事まで書いている点ピヨ。他のコンパイラ本にはない大きな特徴だね♪このページ数をみたら分かると思うけど、残念ながら記述そのものは少ないピヨォ。だけどリンカとローダが書かれた本は稀少だからそれだけでもこの本を買う動機になると思うピヨ。ちなみに、リンカとローダについて書かれた邦書はあと1冊しかしらないピヨ。
それに加えて、構文解析の実装方法が類書には見られないピヨ。なんとC++＆テンプレートで実装しているんだ！そんなコンパイラ本他にはボクは知らないピヨ。さらに、結構凄いコンパイラのソースコード付きピヨ。これはコンパイラマニアにはたまらない一品だね♪
最後にこの本は並列処理について書かれた本だということがボクの知識欲を誘ったピヨッ♪総合すると異彩を放つコンパイラ本 だと思うピヨ。こんな気合の入った本最近あまり見かけないなー。どうせならば、リンカの実装法を紹介する本を誰か書いてほしいピヨ。ボク今かなりリンカについて知りたいんだよね。リンカの実装法を完全に書いた本はボクが知る限り存在しないから絶対売れると思うな。

書籍をつつく61－デバッガの理論と実装。デバッガを知って力64倍♪

先ほどデバッグ本を紹介したから、この古典的名著を詳解しないわけにはいかないピヨ♪
デバッガの理論と実装 (ASCII SOFTWARE SCIENCE Language)
さあ、目次を見てみよう！


【目次】

第1章 はじめに
第2章 デバッガのアーキテクチャ
第3章 ハードウェアによるデバッガ支援
第4章 OSによるデバッガのための基本施設
第5章 実行制御
第6章 ブレークポイントとシングルステップ
第7章 プログラムの文脈を読む
第8章 データと変数の調査
第9章 マルチストレッドのデバッグ
第10章 GUIアプリケーションのデバッグ
第11章 特殊な用途のためのデバッガ
第12章 最適化されたコードのデバッグ
終章 将来のトレンド

芳しい技術臭がプンプンするピヨね♪目次を見ての通りこの本は邦書で唯一のデバッガの実装本ピヨッ♪ボクはこの本を知ると同時に購入したピヨ。そして、前回詳解した本と併読して簡単なデバッガを作ったピヨ♪この本だけでは難しいけど、プラットフォームに特化した違う本と併読すればデバッガが作れるようになるピヨゥッ♪こんなディープで美味しい本はデバッグ系ではないピヨ♪
ここまでの紹介では「デバッガなんて作らない！」と思った人が居ると思う。それは残念なことだけど、まぁいいピヨ。でも、デバッガを使用する全ての開発者はさらっと読むべきだと思うピヨ。何もデバッガを作るまで精読しなくてもかまわないけど、デバッガを自分の手足の様に使うにはこの本が必須ピヨ。デバッガを知って速くうちに帰ろう。ソフトウェア開発の大半の時間は、デバッグと書類だから、デバッグを極めたら凄く仕事が出来る人になるピヨ♪読んで損はしないと思うピヨ♪

書籍をつつく60－.NET&Windowsプログラマのためのデバッグテクニック徹底解説。最強のデバッグ本！

この書籍はWindows開発者ならば絶対買うべきだと思うピヨ♪
.NET&Windowsプログラマのためのデバッグテクニック徹底解説 (マイクロソフト公式解説書)
目次を見たらその凄さが伝わると思うピヨ♪


【目次】

第1部　デバッギングにおけるゲシュタルト
第1章　バグとは
第2章　デバッグ入門
第3章　コーディングとデバッグ

第2部　パワーデバッギング
第4章　OSデバッグサポートとWin32デバッガ
第5章　Visual Studio .NETの高度な使い方
第6章　高度な.NETデバッグ
第7章　Visual Studio .NETを使った高度なネイティブコードデバッギング
第8章　WinDBGと高度なネイティブコードデバッグ技術

第3部　.NETのためのパワーツールとテクニック
第9章　Visual Studio .NETの拡張
第10章　マネージド例外の監視
第11章　フロートレーシング

第4部　ネイティブコードのためのパワーツールとテクニック
第12章　クラッシュアドレスとソース情報
第13章　クラッシュハンドラ
第14章　Windowsサービスと関連DLLのデバッグ作業
第15章　マルチスレッドデッドロック
第16章　テストの自動化
第17章　デバッグ版Cランタイムライブラリ
第18章　サーバーアプリケーショントレースツールの開発
第19章　ワーキングセットの軽量化

付録　参考資料

索引

どう？凄いよね♪ボクは未だにこの書籍のお世話になっているピヨ♪この本は 何回読んでも新しい発見がある本ピヨ♪♪具体的にどのような発見があったのか囀ると、デバッガの作り方、デバッグ全般知識、.NETとWin32のディープな知識の三つが得られるピヨ♪だからボクは一番最初にWindows開発者ならば読むべき本だといったんだ。巷には知られていないけど、デバッグとは物凄く難しい技法なんだ。ソフトウェア開発に潜むバグは厄介な奴で、どれだけ技術を極めようともやってくるんだ。それに、ソフトウェア開発に携わるものとしてデバッグは必須テクニックピヨォ。正直言って、デバッグテクニックを持たない人は開発に参加して欲しくないぐらいだよぉ。
この本は物凄くレベルが高いけど廃刊に備えて買っておこう♪そして何度も読めばいいと思うピヨ。これほどのレベルの本は邦書ではまずないピヨッ♪