書籍をつつく74-詳解TCP/IP〈Vol.1〉プロトコル。情報の宝庫♪

ボクが何度も読んでいるお気に入り本を紹介するピヨ♪
詳解TCP/IP〈Vol.1〉プロトコル
これは正しくバイブル、ピヨ♪


【目次】

第1章 イントロダクション
第2章 リンク層
第3章 IP：インターネット・プロトコル
第4章 ARP：アドレス解決プロトコル
第5章 RARP：逆アドレス解決プロトコル
第6章 ICMP：インターネット・コントロール・メッセージ・プロトコル
第7章 Pingプログラム
第8章 Tracerouteプログラム
第9章 IPルーティング
第10章 ダイナミック・ルーティング・プロトコル
第11章 UDP：ユーザー・データグラム・プロトコル
第12章 ブロードキャストとマルチキャスト
第13章 IGMP：インターネット・グループ・マネジメント・プロトコル
第14章 DNS：ドメイン・ネーム・システム
第15章 TFTP：トリビアル・ファイル転送プロトコル
第16章 BOOTP：ブートストラップ・プロトコル
第17章 TCP：トランスミッション・コントロール・プロトコル
第18章 TCPコネクションの確立と終了
第19章 TCPインタラクティブ・データ・フロー
第20章 TCPバルク・データ・フロー
第21章 TCPのタイムアウトと再転送
第22章 TCP持続タイマー
第23章 TCPキープアライブ・タイマー
第24章 TCPのその他の機能と性能
第25章 SNMP：シンプル・ネットワーク・マネジメント・プロトコル
第26章 TelnetとRlogin：リモートログイン
第27章 FTP：ファイル転送プロトコル
第28章 SMTP：単純メール転送プロトコル
第29章 NFS：ネットワーク・ファイル・システム
第30章 その他のTCP/IPアプリケーション

付録A tcpdumpプログラム
付録B コンピュータ・クロック
付録C sockプログラム
付録D 練習問題の解答
付録E コンフィグレーション・オプション
付録F ソースコードの入手先
付録G 参考文献

この本はTCP/IPプロトコルスイーツの解説本ピヨ♪他にも色々プロトコル解説本はあるけど、実装についての歴史的背景が書かれている所が一線を画するピヨッ。例えば、何故有名なポートが奇数なのかについても書かれている。こんな情報は他の本ではお目にかかれないよね？こんな詳しい本が他に無いし、今時のシステムはネットワークが必須なので、全ての開発者お勧めするピヨ♪
この本は大変長くVol3まであるしVol2と3は実装面について書かれているから、ネットワーク管理者に関係ないと思われがちだけど、決してそんなことは無いピヨ。ネットワーク管理者達にはVol1だけでも読んで欲しいな♪きっと役に立つと思う。
この本が名著なのはゆるぎない事実だけど一つだけ注意しておく事があるピヨォ。それは、プロトコルの運用面は範囲外だという事ピヨ。先ほど言ったように運用面でも役に立つけど、だからといって、この本だけでネットワーク管理は残念ながら出来ないピヨ。その点だけ注意してね♪あと、IPｖ6についても範囲外だからそこも注意が必要ピヨ。原著者がお亡くなりにったから無理だと思うけどもIPｖ６を反映した改版も欲しいなー。

ネタつつき26－システム構築屋のお仕事

何か面白いネタは無いかと考えていたところ、自分自身が変ったケースである事を思い出しました。そこで、私がやってきたシステム構築屋（造語）とはどんな事をするのかについて書きます。 変わった事をしているのできっと面白い読み物になると思います。
先ずはシステム構築屋という名前の由来について説明します。この名称は、魚を売る人は魚屋、OSを作る人はOS屋（命名者：川合秀実氏）ならば、システムを一人で作る人はシステム屋さんかな？と考えて命名しました。それで何故わざわざ命名したのかといいますと、自分の職業が分からないからです。一見アーキテクトみたいですが、アーキテクトは全ての工程を自分でする事はありません。ソフトウェア工学的に言えば、一人でシステム構築をするのは好ましいとはいえないのです。それで、便宜上自分で名前をつけることにしたのです。さて、前置きは十分なので本題に入ります。
システム構築屋のお仕事は仕様書を作るところから始まります。具体的いいますと、依頼主とシステムについてのフリートークを行いながら要望を纏めて仕様書を作ります。私が会った大概のお客様は、情報処理技術について何も知らないので、何がシステムで可能なのかも知らない状態なので、エンドユーザーが望んでいる事を聞くしかありません。イメージ的には大体はこんな感じです・・・

私「エンドユーザーの業種は何ですか？」
依頼主「○○だ。」
私「会社の規模は？」
依頼主「大体従業員1000人ぐらいで全国に数点支社がある。」
（省略）
依頼主「どんなシステムを作ったら買うと思う？」
私「そうですね・・・先方は○○業種なので、
　　○○業務に伴う煩雑な作業を減らすとかが望ましいかと・・・
　　一度先方に要望を聞いてみては如何でしょうか？」

こんな具合に、エンドユーザーから要望を間接的に聞きだしつつそれを仕様書として纏めます。文面では伝わり難いと思いますがこれが意外と大変です。エンドユーザーに加えて、依頼主の事も考えつつシステムを提案しなければならないからです。どこが難しいのかといいますと、エンドユーザーと依頼主の利害一致しないからです。依頼主は極力開発コストを上げる事を望み、エンドユーザーは逆にコストを下げる事を望みます。あと、依頼主が情報処理技術について知らないので、エンドユーザーから何をきいたらいいのか分からないから問題を複雑化します。ここまで読んだ人の中にはきっと、「じゃあお前がエンドユーザーから直接聞けばいい」と言うでしょうが、日本では看板が全てなのでエンドユーザーは私個人に発注をしません。例えそれで価格が100倍になろうともです。どうしてそのように考えるのかは私は知りませんが、エンドユーザーは情報処理技術について何も知りませんし、上司を説得する材料が要るのでしょう。その材料で一番簡単なのは看板だから、会社の利益よりも看板を重視するのでしょう。これは日本の企業体質が生んだ悲劇だと思います。
仕様書が出来たら次はシステム分析です。エンドユーザーの業務については私はド素人なので、業務について調べつつシステムを詳細に分析して仕様書の整合性を検討する必要があります。この段階では、何度も依頼主を通じてエンドユーザーから色々訊かねばなりません。これもまた大変な作業です。何故ならば、エンドユーザーはプロの常識を一々説明するのは好まないからです。よく「プロならば知っていて当然だろ？」と言われますが、私は情報処理技術者であってその業務の素人なのです。日本は意外とまだシステムというものの認識が薄く、エンドユーザーは情報処理技術（IT）を魔法だと考えているようです。
次の段階はシステム設計です。前の段階で得た分析結果を元に、情報処理技術を用いてどうやって実現するのかという部分を考えていきます。この段階では大量にドキュメントが作成されます。これが純粋にシステムに関するものだけならばいいのですが、情報処理技術を知らない依頼主がエンドユーザーに説明できるようになる書類を書かねばならないので非常に大変です。2度手間としかいいようがありません。ここで注意して欲しいのは人もシステムの一部だという事です。システム設計といっても機械だけを考えるのではありません。人がどのように動けばいいのかも含めて設計します。
次は実装段階です。私は場面に応じて複数言語を使えばいいと思うのですが、大半は言語を指定されます。何を基準に指定しているのかはよく分かりませんが、私の経験上拘る依頼主が多いです。おそらく確保できる人員と先入観で決めているのでしょう。この段階は意外と他の段階に比べたら簡単です。システム開発の難しさは人間関係にあるといっても過言では無いでしょう。
最後は運用段階です。この段階では、設計段階で作った運用マニュアルなどを用いて、依頼主がエンドユーザーに教育をしてシステムを動かします。よくシステムを実装すればおしまいだと勘違いしている人が居ますがそれは違います。運用段階に入ってからが本番なのです。依頼主が情報処理技術について知らない場合は特にそれが顕著です。エンドユーザーと依頼主との認識の違いが大量噴出して上手くいきません。これは私の実力不足から生じる問題なのでしょうが、運用を一発で成功した事は一度も無く必ずクレームが来ます（笑）その情報を元にシステムの改善を行います。
大まかに書くと以上です。これらの作業を3～6ヶ月で行います。既に察していると思いますが、デスマーチが前提のお仕事です。私はデスマーチ以外のプロジェクトを経験した事がありません（笑）懸命なる皆様はこんな職業は絶対にしないほうがよいでしょう。

中の人の徒然草125

CodeZine新連載に苦戦しているインドリです。一番最初の書き始めが難しいよね♪それで、ここ2，3日新しい記事を投稿していません。申し訳ございません。もう少し、記事が書けたらこっちも積極的に投稿します。
これだけではなんですので、最近思い出した面白い話しを書きます。つい最近知ったのですが、私の世代はどうやら就職氷河期って呼ばれているようで、私も本当に就職活動が大変でした。それで当時は辛いばかりだったのですが、今から思えば笑える話しも沢山あります。例えば、プログラマとして仮採用されたのに、「君はプログラマだから」という理由で採用を取り消された事があります。当時は意味がわかりませんでしたが、今思い出したら凄く笑ってしまいます。プログラマを求めていないのならば、初めからシステムエンジニアを募集にしておけばいいのです。それに自分が何の職種として雇ったのか覚えていないのでしょうか（笑）
あとそれに似た話しで、必要で無い時間帯で採用しておいて、「この時間帯は要らないんだよねー」と言われた事もあります。これも原理は同じことで、考えて人を雇いましょう（笑）要らない時間帯を募集すれば、その要らない時間帯を希望する人が面接に来るのは当然です。何を言っているのでしょうか（笑）
他には、聞いておいて答えると不機嫌になり、それならばと意見を言わないでおくとそれでも怒る先輩とか居ました（笑）どっちがお望みなのでしょうか（笑）
このように自分の要望が分かっていない面接官や社会人が沢山居ます。誰しも不採用になると落ち込みますが、その時はこの私の話しを思い出してください。こっちが悪いケースも多々ありますが、採用する側が馬鹿だからと言う理由もあるのです（笑）ですから、現在就職活動をしている人は落ち込まず、積極的に活動しましょう。落ち込んでも一文の得にもなりません。全力を尽くすのは当然ですが、それでも不採用という結果が出たら悩まず前に進みましょう♪

中の人の徒然草124

今日もニコニコ頑張ります♪インドリです♪みんなもニコニコしていこう♪
私には欲とか負の感情が殆どありません。飲まない・うたない・買わない・吸わないですし、食欲・色欲・物欲もありません。おまけに大概の事は心から怒りませんし、他人を羨ましいと思った事も無りませんが、一つだけどうしようもないものがあります。それは知的好奇心です。今年も欲しい本が多くて嬉しい悲鳴を上げています。最近では「虚数の情緒」がもう欲しくて欲しくて、今月のAmazonポイントが入ったら買おうかと迷っている状態です。長瀬さん有難う♪虚数の情緒はページ数が多いですが、こんなぐらいのページ数では私は気になりません。260冊ぐらいの専門書を読んでいますので、いまさら1000ページなんてたいした事ありません。いえ、それどころか1000ページあるとなれば余計に読みたくなります。数学の考え方と言う魅力的なテーマで1000ページとなると、もう猫くびったけです♪私は基礎からしっかりと学ぶのが好きなのです。逆に日本の学校教育の様に、ただ覚えろとかは大嫌いです。根っからの研究肌なので、自分の考える余地を与えないものは忌避します。
それにしても数学は面白いものなのに、日本の学校教育が何故そこまでつまらないものに出来るのか非常に不思議です。英語の授業もまったく役に立ちませんしね。その様な事から考えて、日本の学校はもう儀式となっており、実務性がまったくないと思えてなりません。ですから私は学歴にも興味を持たず学校では真面目に勉強しませんでした。テストの当日1時間ほど教科書を読むだけで済ましていました。私は学校教育に意味を全く感じないのです。儀式なんかして何の意味があるのでしょうか？本当の使える学問を教え実務能力を鍛えるべきです。虚数の情緒をなどの硬派な専門書を教科書にするとよいでしょう。そして、魅力ある授業をして飛び級制度にすれば私の様な人間も学校に興味を持つでしょうし実践的です。そんなつまらない話しはさておき、皆様もお勧めの一品があったらどんどん書いてね♪

ネタつつき25－アクセス指向プログラミング（AOP）

この記事はネタつつき24－アクセス指向設計（AOD）補完の続きです。今回は予定通りアクセス指向プログラミングについて書きます。これは勿論ジョークなのですが、私が実施していた事も混じっています。どこが実践で使えるのか考えると面白いかと思います。前置きは此れぐらいにして開始します♪
分析と設計が終わりましたのでいよいよ実装段階に入ります。アクセス指向プログラミングでは、アクセスの性質を重視しますので、オブジェクトのインターフェイスを定義し、テストファーストで実装していきます。オブジェクトがどのようにアクセスされるのかと考える時、インターフェイスがなければ考えが纏まりません。そこで、テストファーストでオブジェクトのインタフェースを先ず考えるのです。注意して欲しい事は、ここで言うインターフェイスとはinterfaceクラスでは無いことです。インターフェイスだけでプログラミングするわけではありません。ここで言うインターフェイスとは、オブジェクトの見え方なのです。ではそろそろインドリを観察してみましょう・・・

インドリ「設計出来たピヨ♪じゃあお楽しみのプログラミングを・・・」
ドリィちゃん「早まっては駄目よ。オブジェクトがどのようにアクセスされるのかを考えなきゃ駄目なのよ。だから先ずするべき事は、テストプログラムの作成よ。」
インドリ「えぇー。お預けって事？ボクはもう疼いて疼いてたまらないピヨォッ！早くプログラミングやらしてー！」
ドリィちゃん「じゃあ、クラスの定義とかの部分すればいいじゃないぃ。とにかく落ち着きなさい。私がクラックテクニックを交えた、すばらしく厭らしいぃ～テストプログラムを作ってあげるわ❤」
インドリ「・・・ちょっとドリィちゃん、やり過ぎたら駄目ピョ・・・」

天然ツッコミ体質のドリィちゃんの本領発揮ですね。世間ではテスターは技術力が低い人がするというイメージがありますが事実は全くの逆です。どちらかと言うと、熟練者がテストプログラムを書き、プログラミングをシ新人にさせるといいでしょう。といっても本来はシステムはプロが作るべきものですから（お客様は当然そう考えてます）、現状の様に「○○は技術力が無くていい」なんて発想自体が可笑しいですけどね。どの工程もプロの仕事なのですから本来技術力が無くていい工程なんてありません。何故そんな発想が巷に蔓延しているのか不思議です。システム構築を経験していれば誰でも体験すれば分かる事なので、そういった発想の持ち主は、全工程を経験したりソフトウェア工学を学んだりした事が無いのでしょう。この業界は何故か素人が大量に居ておまけに地位が高いケースが多いのですが、システム開発のバグそのものなので辞めて頂きたいものです。
おっと失礼。話しを戻します。アクセス指向プログラミングでは、その名の通りどのようにアクセスされるのかを考えながら実装していきます。利点は再利用しやすいオブジェクトが得られる事です。オブジェクト指向プログラミングで再利用しやすいオブジェクトを実装する事は非常に困難です。それこそ職人技の領域です。しかし、オブジェクト指向の利点は再利用なのですから、再利用できなければ開発コストをUPさせるだけの代物になってしまいます。それを防ぐためにアクセス指向プログラミングではこのようにします。
この段階でもなるべく多くのプロジェクトからアクセス出来る様にしますが、そうするためには逆にオブジェクトの結合度を低くしなければなりません。その点を特に注意して下さい。多くのプロジェクトからアクセスできるようにすると言う事は、無闇にpublicクラスにするという意味ではありません。必要最低限のアクセスインタフェースを定義する事により、注意深くアクセスの必要性を考えます。そうする事により、考え抜かれた使いやすいオブジェクトが得られます。
以上でアクセス指向シリーズはおしまいです♪皆様も自分ならではの思考技法を考えるとよいでしょう。

中の人の徒然草123

今日も一段と寒いですね。皆様はいかがお過ごしでしょうか？コタツムリのインドリです♪
本日はCodeZineの新しい連載の原稿を書いています。実は「VB.NETで仮想CPUを作ろう」シリーズの機械語駆動式関数電卓の解答記事2本は去年の年末に書き上げ、先週ぐらいに修正も終わっていますので、今月中に完結します。みんな絶対絶対見てね♪新連載の記事は仮想CPUとは全然違いますが、多くの人が興味があるけども意外と無かったものになっています。多分来月に掲載されるからちょっとだけ期待してね♪
話しは変りますが、最近ジョークでアクセス指向について書いていて感じたのですが、○○指向って何とでもなりますね。アクセス指向って名前にすると決めただけで記事がスラスラ書けました（笑）でも念のために書いておきますが、アクセス修飾子が足りないという記述は本気です。製品ジェネレータなどの発明や基幹系業務システムを作っている時ちょっと困りました。
話しをお戻しますが、実用的かどうかはさておき何とか指向って案外簡単に作れるんですね～。皆様も○○指向を作ったらいいと思います♪きっと楽しいですよ♪恋愛指向アプローチ、トランザクション指向アプローチ、時間指向アプローチ、予算指向アプローチ、顧客指向アプローチ、デスマーチ指向アプローチ・・・なーんてね♪単語があれば何でもOKで～す。はっもしかしてオブジェクト指向、データ指向、アスペクト指向などの既存の○○指向はハッカージョークの産物だったりして（笑）
何はともあれ、情報処理技術に限らず、学問って楽しんでなんぼだと私は思います。学問の本質は人間の知的遊戯かもしれません。その真偽は分かりませんが、少なくとも楽しめたほうが修得は早いのは確かです。みんなでどんどん楽しみましょう。よいハックを！

ネタつつき24－アクセス指向設計（AOD）補完

この記事は、ネタつつき22－アクセス指向設計（AOD）の続編です。引き続き楽しく読んでいきましょう♪
前回の最後で次はアクセス指向プログラミングだと書きましたが、重要な事を書くのを忘れているのに気付きました。設計段階でプログラミング上重要となるのはオブジェクト設計です。今回はそのオブジェクト設計について書きます。無論、ネットワーク構築、データベース構築なども重要となってきますが、それは既存の方法となんら変りありません。アクセス指向設計が他のアプローチと違うところは、メタデータのアクセス性についても考える点です。オブジェクト設計時に一番多い間違いは、不適切なクラス定義から生じます。本来オブジェクト指向設計では実装言語を意識してはなりませんが、多くの人がついつい実装面を意識して継承するためだけに不適切なクラスの親子関係や、メソッドとクラスの関係を定義してしまいます。そういった誰しもあるような間違いを設計段階で防ぐために、アクセス指向設計ではメタデータのアクセス性に意識を集中させる事により、クラス設計に論理上の矛盾が無いかをチェックします。では実例を見るために、引き続きインドリの観察をしてみましょう。

ドリィちゃん「ねぇインドリ。オブジェクトデザインは終わった？」
インドリ「うん♪終わったピヨ♪えっとねぇ・・・うちの店は文房具も売っているから、メタデータの少ない文房具オブジェクトから本オブジェクトを継承して・・・」
ドリィちゃん「ちょっとまったぁぁ！論理的に考えて文房具の子オブジェクトが本オブジェクトと言うのはおかしいわぁ。それならば、商品抽象オブジェクトから文房具オブジェクトと本オブジェクトを継承させるべきよ。ちょっと想像してみて。本オブジェクトが文房具オブジェクトの子にした場合、本オブジェクトは文房具としてアクセスされる可能性がある事も意味するわ。それじゅあ変だよね♪」
インドリ「なるピヨ。本を清算した後、いつの間にか文房具になっていたら吃驚するもんね♪あれ？詳解Linuxカーネルを買ったのに、家に帰ってから見たら大学ノートに変っていたぞ！」
ドリィちゃん「・・・いや、本が文房具に変身することは無いと思うけどぉ・・・もしあったとしたらそれは詐欺被害だよね・・・例えとしてしてどうかな・・・まぁおかしい事を分かってもらえればそれでもいいわ。・・・あれ？何で本オブジェクトに買うメソッドがあるの？」
インドリ「その方がプログラミングしやすいと思ったピヨ。」
ドリィちゃん「それならば【買われるメソッド】ね。でもねぇ、本と言ったオブジェクトは再利用できるかもしれないから、プロジェクトに依存した動きをする受動態メソッドは止めておくべきよ。違うプロジェクトからこのオブジェクトをアクセスする時に、店で買われるメソッドとか、ネットで買われるメソッドとかあったら気持ち悪いじゃない。オブジェクトがどうアクセスされるのかを考えて柔軟性があるようにするべきよ。ライブラリの再配布問題もあるしね。」
インドリ「その通りだね♪わかったよ♪」

順調良く進んでいるようですね。先ほどドリィちゃんが指摘していましたが、なるべく広範囲のプロジェクトからアクセスできるようにオブジェクトを定義するのがアクセス指向設計の勘所です。オブジェクト指向をしているのにも関わらず再利用し難いオブジェクトを定義していませんか？オブジェクトは再利用できないと、ただ開発コストがUPするだけです。十分に注意しましょう。あと、保守性向上の為に論理的に正しい定義をする事に意識を集中させながらクラスのデザインを行いましょう。
その他にもアクセス指向設計ではアクセスするリソースとセキュリティ上のアクセス要件を決定します。こうする事により、並列的な実装とセキュアな実装が出来るようになります。これでアクセス指向設計の解説は終わりです。多分ね♪

書籍をつつく73-ゲームプログラミングのための3Dグラフィックス数学。基礎を押さえよう♪

少し前に注文して今日面白そうな本が家に届いたから紹介するピヨ♪
ゲームプログラミングのための3Dグラフィックス数学
この本はボクにとって適切な本ピヨ♪じゃあ、レビュー行くピョ♪


【目次】

はじめに
内容の概略
表記規則
訳者より

CHAPTER 1 ベクトル1
1.1 ベクトルの性質
1.2 内積
1.3 外積
1.4 ベクトル空間
まとめ
練習問題
CHAPTER 2 行列
2.1 行列の性質
2.2 連立1 次方程式
2.3 逆行列
2.4 行列式
2.5 固有値と固有ベクトル
2.6 対角化
まとめ
練習問題
CHAPTER 3 変換
3.1 一般の変換
3.1.1 直交行列
3.1.2 掌性
3.2 スケーリング変換
3.3 回転変換
3.3.1 任意軸まわりの回転
3.4 同次座標
3.4.1 4 次元変換
3.4.2 点と方向
3.4.3 w 座標の幾何学的解釈
3.5 法線ベクトルの変換
3.6 四元数
3.6.1 四元数の数学
3.6.2 四元数による回転
3.6.3 球面線形補間
まとめ
練習問題
CHAPTER4 3Dエンジンの幾何学
4.1 3 次元空間における直線
4.1.1 点と直線の距離
4.1.2 2 つの直線の距離
4.2 3 次元空間における平面
4.2.1 直線と平面の交差
4.2.2 3 つの平面の交差
4.2.3 平面の変換
4.3 視錐台
4.3.1 視野
4.3.2 錐台平面
4.4 透視補正補間
4.4.1 深度の補間
4.4.2 頂点属性の補間
4.5 射影
4.5.1 透視射影
4.5.2 正射影
4.5.3 錐台平面の抽出
まとめ
練習問題
CHAPTER 5 レイトレーシング
5.1 求根
5.1.1 2 次多項式
5.1.2 3 次多項式
5.1.3 4 次多項式
5.1.4 ニュートン・ラフソン反復法
5.1.5 逆数と平方根の改良
5.2 交差
5.2.1 レイと三角形の交差
5.2.2 レイとボックスの交差
5.2.3 レイと球の交差
5.2.4 レイと円柱の交差
5.2.5 レイとトーラスの交差
5.3 法線ベクトルの計算
5.4 反射ベクトルと屈折ベクトル
5.4.1 反射ベクトルの計算
5.4.2 屈折ベクトルの計算
まとめ
練習問題
CHAPTER 6 照明
6.1 RGB カラー
6.2 光源
6.2.1 環境光
6.2.2 平行光源
6.2.3 点光源
6.2.4 スポットライト
6.3 拡散反射ライティング
6.4 テクスチャマッピング
6.4.1 標準的なテクスチャマッピング
6.4.2 射影テクスチャマッピング
6.4.3 キューブテクスチャマッピング
6.5 鏡面反射ライティング
6.6 発光
6.7 シェーディング
6.7.1 法線ベクトルの計算
6.7.2 グーローシェーディング
6.7.3 フォンシェーディング
6.8 バンプマッピング
6.8.1 バンプマップの構築
6.8.2 接空間
6.8.3 接線ベクトルの計算
6.8.4 実装
6.9 物理反射モデル
6.9.1 双方向反射率分布関数
6.9.2 クック・トランスの照明
6.9.3 フレネル係数
6.9.4 マイクロファセット分布関数
6.9.5 幾何減衰係数
6.9.6 実装
まとめ
練習問題
CHAPTER 7 可視判定
7.1 境界ボリュームの構築
7.1.1 主成分分析
7.1.2 境界ボックスの構築
7.1.3 境界球の構築
7.1.4 境界楕円体の構築
7.1.5 境界円柱の構築
7.2 境界ボリュームのテスト
7.2.1 境界球のテスト
7.2.2 境界楕円体のテスト
7.2.3 境界円柱のテスト
7.2.4 境界ボックスのテスト
7.3 空間分割
7.3.1 8 分木
7.3.2 2 分空間分割木
7.4 ポータルシステム
7.4.1 ポータルのクリッピング
7.4.2 縮小された視錐台
まとめ
練習問題
CHAPTER 8 衝突検出
8.1 環境との衝突
8.1.1 球と平面の衝突
8.1.2 ボックスと平面の衝突
8.1.3 空間分割
8.2 オブジェクト間の衝突
8.2.1 2 つの球の衝突
8.2.2 球とボックスの衝突
8.2.3 2 つのボックスの衝突
まとめ
練習問題
CHAPTER 9 ポリゴン技法
9.1 深度値のオフセット
9.1.1 射影行列の修正
9.1.2 オフセット値の選択
9.1.3 実装
9.2 デカールの貼り付け
9.2.1 デカールメッシュの構築
9.2.2 ポリゴンのクリッピング
9.3 ビルボード
9.3.1 無制約の四角形
9.3.2 制約された四角形
9.3.3 ポリライン四角形ストリップ
9.4 ステンシルシャドウ
9.4.1 エッジリストの構築
9.4.2 シャドウのレンダリング
9.4.3 実装
9.5 ポリゴンの削減
まとめ
練習問題
CHAPTER 10 並進運動の物理学
10.1 位置関数
10.2 2 階微分方程式
10.2.1 同次微分方程式
10.2.2 非同次微分方程式
10.2.3 初期条件
10.3 弾丸の運動
10.4 抵抗を受ける運動
10.5 摩擦
まとめ
練習問題
CHAPTER 11 回転運動の物理学
11.1 回転環境
11.1.1 角速度
11.1.2 遠心力
11.1.3 コリオリ力
11.2 剛体運動
11.2.1 重心
11.2.2 角運動量とトルク
11.2.3 慣性テンソル
11.2.4 慣性主軸
11.3 振動運動
11.3.1 ばねの運動
11.3.2 振り子の運動
まとめ
練習問題
CHAPTER 12 流体シミュレーション
12.1 波動方程式
12.2 導関数の近似
12.3 面変位量の評価
12.4 実装
まとめ
練習問題
APPENDIX A 複素数341
A.1 定義
A.2 加算と乗算
A.3 共役と逆元
A.4 オイラーの公式
APPENDIX B 三角関数の公式
B.1 関数の定義
B.2 対称性と位相シフト
B.3 ピタゴラスの定理
B.4 加法定理
B.5 逆関数
B.6 正弦定理と余弦定理
APPENDIX C 座標系
C.1 円柱座標
C.2 球座標
APPENDIX D テイラー級数
D.1 導出
D.2 ベキ級数展開
D.3 オイラーの公式
APPENDIX E 練習問題の解答
参考文献
索引

この本は題名どおり3Dグラフィックスで必要となる数学の知識を解説した本ピヨ。とはいえ、ざっくり読んだ所、やっぱり数学の知識は必要ピヨ。数学については大学受験用参考書が役に立つピヨ。それらの数学書で基礎的な部分を学習しながら、この本で力を身に付けるといいと思うピヨッ♪
この本の長所は数学を実用的に学べる点ピヨ。一方短所は、価格が高い点ピヨォ。年末に思わぬ収入があったし、皆が書籍をつつくシリーズで紹介した本を買ってくれるから買えたけど（みんな協力有難う♪これからもそのポイントを使ってレビューをしていきます）、4000円ぐらいにして欲しかったな～。とはいえ、3Dに関する数学を解説した書籍は少ないから基礎から学びたい人にとっては必要な本だとボクは思うな。

中の人の徒然草122

本日も笑って生きましょう♪インドリです！今日はネタ指向の実装以外何を書こうかな・・・
いきなりですが、私はネットデビューしてから日が浅い事もあり、ネットでのコミュニケーションが非常に難しいものだと感じております。ブログを書く私が言うといまさら感がありますが、ブログって一体何なのでしょう？未だによく分かりません。ブログと一口で言っても様々なタイプがあります。ネットワーク用語でたとえると、ブログの書き手と読者が気楽に意見交換する全二重通信、ブログの書き手が発言した内容以外の事を話しかけてはならない半二重通信、ブログの書き手の発言の感想しか書いてはならない一方向型通信があると感じます。これがネットでのコミュニケーションを難しいものだと私が感じる要因です。
現実世界では話しは広がります。こんな風に・・・

A「最近不景気だね」
B「ああ。俺の会社もやばいよ」
C「そういえば映画で似たような状況があるぞ。」
A「その映画はなんていう題名？」

ってな具合で話題が展開していきます。しかし、ブログでは全二重通信型で無いところでは、必ずしもこれが成り立ちません。さらには、話しかけても居ない第三者から思わぬ事を言われる事があります。しかし文章とは対象が居て書くものです。そんな話しかけても居ない人から言われても困ります。現実で考えるとその不可解さが伝わると思います。

C「そういえば映画で似たような状況があるぞ。」
D「映画の話なんてして無いだろ。」
A&B&C「その前に君は誰？」

かなりの違和感を感じます。何故ならば、話しかける対象で無い人までも考えて文章を書かねばならない事を意味するからです。でもそんな芸当私には出来ません。１億人ぐらいの人を想定して、同時に会話できる人が居るでしょうか？私は絶対不可能だと思うのですが・・・とはいえ、今まで知らなかった素敵な人と出会える可能性があるから否定もしきれないし・・・
それに、文章ではどうしても伝わり難いことがあり、会って話せば簡単に解決する事でも「想定外の人」の乱入などの不確定要素により会話が変になる事があります。これはきっと、私がブログや掲示板の様なメディアに慣れていないがゆえに感じる事だと思います。
他にもどのような文体で書けばいいのかといった問題もあります。現実世界では場所である程度分かりますが、ブログなどではあるのは文字と絵だけです。静的な情報しかなく、ブログの厳密な定義が分からないので、どうしていいものやら私には分かりません。文章は余りにも丁寧に書きすぎると距離感が生じたり、冷たいという印象を与えます。特に私は関西人なので、仕事以外であまり堅苦しい物言いは苦手です。公私をはっきりとわけたいので、普通の会話ではフランクに、ビジネスでは標準語と使い分けます。なので会話口調で書いたり、キャラクターとして書いてみたり試行錯誤しておりますが、あまり上手くいっていないようです。うーん難しい。でも私は逃げるつもりはありません。現実に出来ない体験をするのがネットだと前向きに考える事にしています。
誰かネットコミュニケーションについてアドバイスしてくれないかな・・・

ネタつつき23－乾杯した後は大笑いで負の感情をぶっ飛ばせ！

私も笑える記事を書く事を心構えます。皆様も互いにそうするといいと思います。笑いで全てをぶっ飛ばせ！