fj の教祖様の蔵書/既読書@FC2

どんな世界にも「コツ」というものはありますが、 それは Graphics の世界にもあります。 しかも結構『数学数学』した『コツ』だったりして 自前で式を立て直せとか言われると気が遠くなったりします。

そんな時にはこれ！Graphics Gems シリーズ！！ このシリーズは、それはそれはもう、手元に置いておくと イザと言う時に役に立ってくれます。 最悪でも研究室に１セット持っておくべきです。 可能ならば自前で買うべきです。

CG 屋さんの必須アイテムと言えましょう。

まぁ、欠点があるとすれば、「英語だ」ってことかな。

Linux kernel 2.0 の inside 解説本。

役に立つかと思って買ったのだが、何のことはない、 2.4.* の現在では似て非なるものになってしまい、 ここに書かれていることを信頼すると、 逆に最後の瞬間に痛い目に合うことに気が付いた。

さらに言えば、ここに書かれているのは Linux の上っ面である。 上っ面がどこなのか理解するには良いが、それ以上のものではない。 Linux は非常に汚い実装になっていて、 「仮想…層」と言われるもの (VFS とか)があまりにも薄すぎて ほとんどただの「関数へのポインター表」でしかない。 しかも、何処に何があるのか判らなくなるよう、 醜く書かれている。

ここに書かれている程度は判らなくては駄目だが、 ここに書かれていることを判っても駄目で、 さらに言えばここに書かれているものでは古すぎて駄目、 という3重苦な本。

ついに。ついに。ついに。
ついにこのような本が現れた。
歓喜とともに、この本を紹介する。
推奨レベルは 神クラス である。
読むべき人間は全てのプログラマーである。
共に喜びを分かち合おうではないか。

英語版と日本語版、両方持っているが、別にどちらだから読みやすいという事はない。 記述上の言語はほとんど障害にならない。 日本語版の方には和田英一先生の推奨の辞があり、 そこにはさらに楽しみが埋まっている。 それぐらいの違いしかない。 言語などたいした問題ではないのだ。

これは本当のことだ。

32bitの変数中の 1 になっているビットの個数が

是非、この本を買ってほしい。
読んで欲しい。
そして一行一行、記述を検討して欲しい。
それが楽しみだと言う人が一人でも多く現れることを私は心待ちにしている。

Security と Secure の違いが判るだろうか?

Securityというのは、 乱暴に言えば機能だ。 ユーザー認証とか、暗号通信とか、署名とか、 そういった機能が Security である。

これらは「xxx がある」という形になるので positive feature とも言われる。

Security は機能なので、 これらをサポートするプログラムにバッファオーバーフローがあろうが、 何があろうがスペック一覧上は、これらの機能は存在する。 データと暗号鍵の対が同じときに理論と違う値が出てくる、 などの現象が起こらない限り、 問題とはならない。

Secureというのは、要件だ。
Buffer overflow が起こらない。
Back door がない。
Parse error がない。
こういうものが Securityだ。

これらは、「xxx がない」という形になるので negative feature とも言われる。

当たり前だが、Negative Feature は Positive Feature とは比べ物にならないほど難しい。

まずもって、「xxx がない」という条件を満たすには、 全プログラムがこの条件を満たさなくてはいけない。 自分が書いたコードだけではなく、ライブラリ、OS、HW、 ネットワークでくみ上げられる計算機群のすべてがこの条件を満たさなくてはいけないのだ。 Positive Feature はどこか一箇所に該当の機能を実装すればいいだけなので、 Negative Feature と比べて圧倒的に簡単なのだ。

その一方で、「xxxがない」という条件を確認するテストは書けない。 「xxxがないという条件を満たしていない」事は問題点を1箇所見つけて、 そこをつつくコードを書けばよいので簡単だが、 その逆は、実質的に
「プログラムの正当性を確認するプログラムを書く」
事になるので、チューリングの停止不能問題そのものに陥るのだ。

従って、Secureという要件を満たしていることを証明するテストはかけない。

じゃぁどうするかというと、 アーキテクチャの段階から何度も何度も確認を繰り返すのだ。 そうすることで間違えている確率を下げ、 出荷前にトラブルポイントを発見する確率を上げるのだ。 そしてそれらの作業全体の履歴を管理しそれをもって品質管理とし、 問題が発生した場合は履歴からどこで問題が入ったのか、 どのようにして問題点が見落とされたのかを解析するのだ。

さて。以上の知識に基づいて。

この本はこの Secureという条件を満たすコードを書くために、 どうすればよいのかを述べている。 201ページしかなくA5サイズなので微に入り細に穿った説明はないが、 上記の条件を可能な限り満たすためにやるべきことが一通り網羅されている。

まず、Secure な Code とはどういうものなのか、 どうしてそれが大事なのか、 どのようなポイントで問題が入り込むのか、 それを可能な限り回避するためにはどうすればよいのか、 などの話が述べられている。 その中には、プログラムを作成するところまでではなく、 利用する際のオペレーションにまで言及されている。

その中には「なぜいい人がひどいコードを書くの?」など、 なかなか個人的に笑わせてもらったタイトルも含まれている。 (いや、2つ目の会社で
「いや、問題なんかあるわけないよ。xxxさんはいい人だもの」
というアメリカ本社に対する皮肉が大流行したんだよね。)

セキュアプログラミング―失敗から学ぶ設計・実装・運用・管理 というタイトルで邦訳もされている。 ちょっとタイトルがおかしい気がするんだが…。

是非、すべてのプログラマに読んでもらいたい。

プログラムを書く場合、同じことを似た形で書いているのに 同じ結果が得られる場合と、違う結果が得られる場合がある。

program 1:
  if ( x ) {
    a = y;
  } else {
    a  = z;
  }
program 2:
  a = ( x ) ? y : z;

たとえば program 1,2 は全く同じことを記述しているが、 この二つが同じコンパイル結果を生むコンパイラと生まないコンパイラがある。

違いはコンパイラがプログラムを解析した後に存在する。 program 1 と 2 が同じものであることを認識するには、 パース段階では全く違っていたこの2つのパターンを同一化させるための 中間コード間の変換が必要になる。 その機能を持っているかどうかが、 この二つのプログラムの運命を分けるかどうかを決定する。

これらの、 コンパイラが何を読んだら何をどう理解して何を出力するのか、 こそが「コンパイラの気持ち」と呼ばれるものだ。 この本はその「コンパイラの気持ち」と言われるものがどのような 原理によって作られ、どのように動作するのか、 そこに使われている技術にはどのようなものがあるのか、 が説明されている。

この本は最終的にはどんなプログラマーも読むべき本だ。 コンパイラの基本構造に関する知識無しに良いコードは書けない。 全く同じことを記述するのに何をどう書けば良いのか、 何はコンパイラに依頼して読みやすいコードに徹すればいいのか、 何はコンパイラに依存できないのか、 それを知らない限り良いプログラマーにはなれないからだ。

コンパイラーを使ってプログラムを作る人は、 意識する・しないはともかくとしてリンカーと言われるソフトウェアを使っている。 最近では、リンカーの作業の一部の仕事を実行時に行う。 この場合はローダと呼ばれるものがその仕事を行う。

リンカーとローダの仕事はコンパイラーが生成したプログラムの部品を統合し、 一つの実行可能なイメージを構築する事にある。 この場合主な仕事は、 「アドレス」を確定しアクセスに必要なコードを生成・修正することにある。

しかし、プログラマーの中にもリンカーの存在を知らないことからも判る通り、 あまりにも地味な作業なので、 大抵の人はこのようなプログラムについてほとんど知らない。 この本はそのようなリンカーとローダーについて解説した本である。

リンカーとローダーは、 プログラムを実行する上で「最後のコード変更ユニット」である。 このため、ここは実はプログラムの最適化を行う最適なポイントの一つなのだ。 実際、Solaris 8 などではついに optimize after load のように 実行直前に最適化を行う機能がついた。

プログラマーならば、是非この本は読んで欲しい。 リンカーを理解できないのでは、プログラムの最終的な適正は理解できない。

はっきり言って、この本を買うのは３度目だ。 前の2度は人に貸したら戻ってこなかった…。 まぁ、それはともかく。

この本は「問題発見の人間学」の本である。

「工学」というのはそもそもが問題を見つけ出し、 他人のためにそれを解くというのが仕事です。 従って、皆、問題を見つけるのは得意だと思っていますし、 そんなものはゴロゴロしている、と思っています。 難しいのは解くことの方だと。

しかし、現実にはそうではありません。 問題が難しいのは問題が 難しい からではなく、 本当は 正しく定義されていないから なんです。

ある現象があって、それによって困っている人がいるとして、 それを 誰の立場に立って 定義するのか、によって問題は変わり、 それによって問題の解決方法は変わるのです。

この本はそのことを教えてくれます。 万人、絶対読むべし。

多分この本は コンサルタント業のテクニックを披露している本の１つなんだと思う。 でも違うとも思う。

この本が『何』であるかについて評価するのはやめることにする。 重要なのは この本の内容は役に立つ ということで、それで十分だと思う。

内容としては、ワインバーグがコンサルタント業を (あるいはその前の教授業を)やっている時に得たヒント/教訓集である。 しかも明らかに役に立つ。

『ライトついてますか？』が問題発見学への国道だとすれば、 これは裏道集のようなもんである。 あらゆるプログラマーに読むことをお勧めしたい。 その上司は言わずもがなである。

テーマは「思考とパターン」。

「ものの考え方」というのは一種の「パターン」である。 それはあるものに注目し別のことを軽視して物事を分類し、 評価し、対応する、ということ。 この本では、「ソフトウェアの品質の管理」という観点、 特に対人間(プログラマ)という観点から、 このことについて考える。

「欠陥の発生」「予想外のプロジェクトの遅れ」 「バージョンアップに伴うシステムの硬直化と、 どんどん使えなくなっていく理由」などは、 すべからく『何かを軽視し過ぎ、何かを重要視し過ぎたために』 発生している。 (大抵の場合、納期を無意味に重要視し機能を無視したり、 『すでにある』という事実を重要視して『拡張性があるかどうか』 を無視して拡張要求を飲んだりするために起こるのだが)

人間が「自分のパターンを(気づかずに)絶対視する」ことは 有名であると同時に、 「わかっていてもその失敗から逃げるのが難しい」ことも有名である。 でも、実はそれは『わかってると言っているだけでわかってない』 からなのかもしれない。

もし、あなたが、 「なぜスケジュール通りにいかないのだろう?」と思っているなら、 この本を読むといい。 理由は、スケジュールを決めている「あなた」にある。

テーマは「観察」。

プログラムの質を高める、 従業員に一杯仕事をさせる、 などの目標を立てるとき、 なぜか『プログラムの行数を数える』などの わけのわからない計測基準が出てくることが非常に良くある。 (しかも困ったことに、これを提唱／採用した人間は大真面目で それが有効だと思い込んでいる。 「思考とパターン」にも問題がある場合が多いと言うことだ)

この本のテーマは「観察」とは何か。

一体何を計っているのか？ ある方法が一見うまく行く理由と、 うまく行かなくなっていく理由は？ などの問題は、 基本的にこの「観察と反応」とは一体なになのかを きちんと認識しないことから始まる。 きちんと認識しないから「プログラムの行数を数える」などという 馬鹿げた計測法が横行するのだ。

だからまず自分が何をやっているのか、きちんと把握しましょう、 という本。

この本に書かれていることは、私の場合、 学生の時に制御工学科ですべて同じことを習っている。 その意味では目新しさはなかったが、 同時にほとんどの人はこんなことすら知らないでいるのか、 ということにちょっとびっくりした。

是非読んでみることをお勧めする。

ワインバーグの本は英語の段階で文章がしっかりしているため、 翻訳者もしっかりした文章に翻訳し易くなっている (しっかりした文章に翻訳されている、とは言わないが)。 このため、『一体何を言っているのやら』状態な文章や、 救い難いような誤訳もない。

内容は明確で順を追っており、例も多く、わかり易い。 プログラマだけでなく、どんな人にも読んでいただきたい一冊です。

テーマは「行動と『行動の管理』」。 ようするに「問題に対する対処」の中でも 「対人間問題の対処」について扱っている。

問題が発生した時におかしな上下関係が存在していると、 最適な解決策が人間関係レベルの影響で選択されなくなる、 という現象が起こる。

たとえばＡさんとＢさんがいて、 Ａさんからの頼みをＢさんは嫌と言えないとする。 そしてＡさんの直接の要望が、 Ａさんの問題解決にとって適切な解ではなかったとしよう。 そしてＡさん自身はそのことを理解していないとしよう。 もちろんＢさんはその問題のエキスパートで、 Ａさんの要望が問題を解決しないことを知っている。

ＡさんとＢさんが対等であれば、ＢさんはＡさんの要望ではなく 『問題を』解析して、正しい解を導くことができる。 ところがＢさんがＡさんに『嫌』と言えない場合、 Ｂさんは『Ａさんの要望』に答えるはめになる。 殺那的にはＡさんの要望は満たされるが、 それは問題を解決しないからＡさんの問題は緊急度を増し、 再度Ａさんに降り掛かってくる。 Ａさんはとりあえずの要望をＢさんに出し、 Ｂさんは『要望』に答え… そして悪循環が完成する。

管理者の仕事の一つがこの『行動の管理』である。 集団の中にこのような不適切な状態が存在すれば、 当然集団全体としてのパフォーマンスが落ち、 「納期に間に合わない」「問題が解決しない」などの 大きな問題が発生する。 真の問題の解決は往々にして「Ａさん」に負荷を強いるが、 それでも悪循環を起こすよりはましである、 ということをまずは自覚し、 自覚させなくてはいけない。

この本では、どのような「不適切さ」が存在するのかを中心に 症状と対処について述べられている。

30歳ぐらいの人はもう読んでないと駄目な本。

図解している内容の大半は「文字コード」ではなく、 「IME の使い方」だったりするがそれはともかく。

説明の内容が「Unicode 万歳、Unicode 最高」という狂った内容なのも こちらへ置いておくとして。

これらの看板に偽りだらけな部分と、 内容が正当に評価されていない部分を除いて、 技術的な側面にのみ神経を集中するならば、 この本は Unicode の理解に関しては役に立つ。 Unicode の持っている問題の大半はこの本の説明から導出できる。

ただし、「超漢字」などの「Unicode より全然便利じゃん」な文字コード の技術的説明が丸っきり欠ていることなどなどからも判る通り、 この本は著者の信念と衝突することに関しては、 技術的説明を期待してはいけない。

と言うわけで、この本は Unicode の腐れぶりを理解するためにのみ、 有効である。

計算機による機械学習には大雑把にいうと2種類ある。 学習機械に「答」を教えていく「教師つき学習」と、 「答」は教えないが出力結果に対する「評価」だけが与えられて そこから機械自身が正解を探索していく「教師なし学習」だ。

強化学習というのは、 ものすごく乱暴にいうと教師なし学習の別名である。 基本的には出力に対する報酬関数(評価関数)があり、 その値を maximize するように学習を行うようシステムを作ると そのシステムは強化学習の機能があるという。

この本は、様々な強化学習システムについて 入門的に説明している。 説明範囲が広く、難しい所までは入っていないので 確かに入門に丁度良い。

結構面白いので読んで見る価値はたっぷりある。

「256倍」シリーズの中で私が使えると思っている 著しく数少ない本の一つ。

awk というのは、なんか初心者にとっつきにくい。 あれはなぜなんだろうと思うことも多々あるが… 結局「プログラミング言語」と認識しないと駄目なのかも。 なんか「Ｃがあればいいや」調でいると覚えられないのかも。

そういう向きにはこの本は良いと思う。

awk は便利でいいっすよ！

Unix の歴史、Unix の環境、Unix のある生活…

なんというか『とても使える話の載っている、掴み所のない本』。 でも、載っている情報は結構便利だったりします。 Unix ってとんでもなく奥が深いので (OS としてというよりも環境として、奥が深いのだ)、 この本は『よほどの Unix ハッカー』以外何らかの形で 役に立ってくれること受け合い。 ただし、どこに何が載っているか覚えてないと大変だけど…。

この本は楽しい。とんでもなく楽しい。なぜなら C の本ではないから。 でもこの本は C の本としては上級者向けの、結構良くできた本である。

この本の著者は(本の中では明確には書かれていないんだが) どうやら Sun Microsystems の社員のようだ。

C に関する解説も、基本的には SunOS 上の C を中心に据えている。 もっとも SunOS 上のＣは ANSI C に準拠しているので 他の C でも成立する話ばかりだが。

実は C に関する話の多くは、『Cそのものだけの』問題ではない。 大抵の場合 OS だの CPU だのと絡んで問題を起こす。 この著者はその辺をとてもよく理解しているらしく、 C というよりはリンカーだの OS だのといった話から、 問題点に入っていく形をとっている。

で、その中にはさらに、 Cとは結局つながらないで終る話も散りばめてある。 これがもっとも楽しい。

これらのせいで、 この本は『Cの本ではない、Cの本』という条件を満たしている。

この本を読んでいると、 Sun Microsystems 社は、もうしばらく安泰だ、 ということがわかる。 この本の著者はそのネタの多くを自分の会社の中から捜し出している。 そこに出てくる話の多くは仕事『以外の』話で、 それも「クダラネー」お遊びに近い話だったりする。 もちろん、中には仕事の中から真面目に出てきた話もあるんだが…。

この話を見ていると、Sun Microsystems 社の社員は

• 仕事だけでなく、仕事以外でも結構交流が盛んであり、
• なおかつそういう場でこの手の話をできるだけの余力がある

• それなりにハードな仕事をこなしており
• なおかつそれに対して十分な支払がなされている

この本はお勧めの一冊の１つである。 読者としてはプログラマーはもちろんだが、 学生の人にも読んで欲しい。 良い就職先と言うのはこのような本に書かれているような環境を 持っているものだよ、ということを知っておくと言う意味で。

まず最初に言っておきます。 もし、あなたが
「ん?その本は大昔に出てなかったか?」
と思ったなら、それは Brian W. Kernighan & P.J. Plauger 著 ソフトウェア作法 の勘違いだ。 確かにこれも名著だが、この本はこれじゃない。

この本は原著が1999年に出ている、 The Practice of Programming の翻訳本である。

内容はまさに「プログラミング」の「お作法」書だ。 要するに プログラムを書く上での 心構え が書かれている。
曰く、記述スタイルは統一せよ。
曰く、デバッグとテストは違うぞ
曰く、define macro は混乱の元だからなるべく使うな…

内容の多くはプログラミング以外にも幅広く応用できる。 まぁ、厳密に言うと 日々の生活、これ、無意識のプログラミング だからなのだが。

もちろん、プログラムを組む人は絶対読むべきである。 一応この本は C/C++/Java でサンプルが書かれている、 と言うことになってはいるが、 ほとんどソースコードなど読まなくても理解できるので、 これら以外しか使ったことのない人にも是非お勧めしたい。

NFS プロトコルと、 その関連プロトコルや使われ方に関する包括的な説明書。 これを読むと、しみじみ、思うことが2つ。

1つ目は NFS プロトコルは極めて「いい加減」だ、というものだ。 確かに「ファイルシステム」のセマンティックをネットワーク上で 実装するのは困難である、というのは事実だが、 だからといって「だから適当にマップすればどんな世界でも動きます」 はないだろう…。

2つ目は NFS プロトコル自体は Stateless なのだが、 それが必要とする周辺プロトコルは Stateful で、 しかも Stateful である必要がある、と言うことだ。 挙げ句の果てに NFS プロトコルの Stateless さが ファイルシステムとのマップに障害になってさえいるのだから、 結局 Stateless というのは『ファイルシステム』の実装という 観点から行けば間違っているのだろう。

NFSv4 でこれらの間違いが正されることを祈りたい。

IPv6。
128bitのアドレス空間を持ち、 向う10年間は確実にアドレス不足を解消してくれるに違いないと信じられている、 何故かその浸透速度が異常なまでに遅い IPv4の後継プロトコル。

プログラムをこのプロトコルに対応させるのは、 簡単なようで難しい。 主な理由はIPv4が32bitというあまりにも従来の計算機にとって都合の良い サイズだったがために、 このサイズに依存したコーディングに人々が慣れてしまった事、 そのことを念頭につくられたSocketライブラリはbackward compatibilityを 保持する必要性から、 このようなコーディングを阻止する機能が全くついていない事があげられる。 さらに、一歩間違えるとこのコーディングはかなり深刻なセキュリティホールを 作り上げる場合がある。

この本はKAMEプロジェクトで有名なitojunさんが、 これらのポイントを念頭に起きつつ、 IPv6にも対応したプログラムをどうコーディングしていけば良いか、 示している。

とても役にたつ。 単にIPv6だけに限らず、 さまざまなプロトコルに対応できるコーディングができる 書き方を勉強できる。

ただね。ただね。 本体よりAppendixの方が大きいってのは、どうかと思うぞ。 まだ書くべきこともあると思うしさ。

C++ とはほとんど関係がない。 単にサンプルプログラムが C++ なだけ。 この本で重要なのは「文章による」説明の所。コードではない。

内容は「アルゴリズム」というよりは「データ構造とその使い方」で、 この本に書かれている程度のことは 「常識」として自由に使いこなし、思いつかないとプログラマじゃない。

「何か、簡単で、いろいろな形状が一発で表現できそうな、 便利な曲線とかの表現形式はないかなー」と思って、 本屋でランダムに探してて見つけた本。

はっきり言って、全然「早わかり」ではない。 ちょっと話を前後させ過ぎて、かえってわけがわからなくなっている。

でもね、他の普通の CAD 系の自由曲線の説明よりははるかにわかり易い。 この本の2倍の厚みがある本よりも はるかにサクサクと必要な情報が出てくる。 結局似たようなものを何度も説明しようとする『教科書』よりも、 最初から『Non Uniform Rational B Spline を説明する』という 究極目的のために他の表現形式を説明しているこの本の方が、 ぴしっとした説明ができるんだろうなぁ、と思ってしまいました。 お値段もそんなに高くないし、くらくらするような教科書を買うぐらいなら これを手元においといた方が便利だと思います。

ちなみに、NURBS という表現形式そのものは 『人間が手でぷちぷちと制御点を置いていく』 世界用にはいいのかもしれんけど、 私の目的にはちょっと合いませんでした。 しょうがないので Rational Polynominal Form という奴の方を 使いました。

HDD の基本的な構造と動作原理についての解説書。 HDD のヘッドがどうやって浮いているのか、 とか HDD で読み取ったデータをどのようにして エラーコレクションを行っているのか、 とか そういう話が出ている。

また、SCSI や ATA の規格についても一通り説明してある。 基本的な部分しか書いていないので、 これだけで何かが作れるわけではないが、 かなり使い手のある本であることは間違いない。

LaTeX2εの説明本。

おせじにもよくできているとは言えない。 Lamport の LaTeX 本 よりも酷い順番で並んでいるし、 だからといって詳しい説明になっているわけでもない。 機能説明が完全なわけでもない。

はっきり言ってなんでこんな分厚い本になってしまうのかもわからない。 まぁ 2,800円という値段は決して高い方ではないから それはいいのかもしれないが…。

…まぁ…コレクターズアイテムですか? LaTeX2εの本を全部欲しければ持っておく必要があるでしょうが…。

"Applied Cryptography"といえば、 読んだことのないセキュリティ屋はもぐりだ、 というほどに有名な、暗号とセキュリティの名著。

暗号の理論、それも乱数などの依って立つ基盤の説明からはじまり、 共有鍵暗号、公開鍵暗号、ハッシュ関数、署名、認証など、 暗号をつかって実装するほぼ全ての項目を一通り網羅している。 また、この本が参考にしている文献にも優れているものが多い。

暗号技術に関する話は、1996年発行のせいでどうしても古い部分がある。 たとえばAESなどは当時まだ存在しなかったために説明がない。 が、それ以外の部分は今でも十分に通用する。

繰り返し読んでおきたい本の1つである。

ネットワーク接続、 特に経路決定に関するお話が主題になっている本。

ハッキリ言って、ここに書いてあるようなことが書いてある本は、ない。 それもいろいろな意味で、ない。

たとえば…そうだな。
「Ethernet における Switching Hub は、 あれは Ethernet レベルでの router である」
なんて話はどうだろう? 専門家でもない限り、IP レベルでの router については意識しても、 Ethernet レベルでのルーティングはまるで考えないと思う。 が、よくよく言われてみれば、Switching Hub はある特定の port から 来たパケットを別の特定の port にだけ流すようにして、 それ以外の port には流さないようにしているのだから、 あれは立派な「経路決定デバイス」の一種なわけだ。

こういうのはどうだろう?
「ブリッジとはデータリンク層リレーであり、 ルータとはネットワーク層リレーである」
特に違和感はないですよね?では質問:
「データリンク層って何?ネットワーク層って何?」
多分ここで多くの人は困るはずです。 え?困らない?本当に?
「データリンク層とネットワーク層ではネットワーク層の方が OSI参照モデルなどでは上にいますよね? 例えばネットワーク層の例は IP だし、 データリンク層の例は PPP や Ethernet なわけだ。
じゃぁ、Ethernet packet を IPSec の上に載せて、 仮想ネットワークを張る場合、IPSec はデータリンク層? それともネットワーク層?」
Ethernet プロトコルがデータリンク層なら、 IPSec はその下にあるのだからこれはネットワーク層ではあり得ない。 でも IPSec は一般にはネットワーク層だと言われている。 じゃぁ Ethernet はネットワーク層なのか?
(この本における正解は、 「データリンク層プロトコルを標準化する委員会によって標準化されたものは、 なんでもデータリンク層プロトコルである」 逆に言えばデータリンク層プロトコルとネットワーク層プロトコルに 明確な違いはない。)

Radia Perlman は「スパニングツリーアルゴリズム」という、 経路制御をする上で不可欠なアルゴリズムの考案者である。 ハッキリ言ってこのアルゴリズムがなければ Internet は今の何十倍も 遅くてコストのかかる世界になっていただろう。 つまり、この手の世界の第一人者の一人である。

ネットワーク管理者には必読で、 それ以外の人も読んで絶対に損はない一冊である。 少なくとも次のようなことは言える。
「もし、この本を読んで理解できない所があったら、 そのジャンルは速攻で再履修の必要あり。」

Windows だけ、Ethernet Hub も1つだけという世界だと まったく問題なく Windows 同士でディスクやプリンタを共有できたのに、 rooter を増やした、gateway を増やした、 VPN 経由でも繋ぐようにした、 unix マシンがやって来た、 などネットワークの構造が大きく複雑になると途端に
「xxx から yyy が見えない」
「ネットワーク上はいることになっているのに、 ダブルクリックするとサービスが提供されてないとか言われる」
という謎のトラブルが乱発する。 それが Microsoft network だ。

はっきり言って、 Internet の世界で Internet だけの機能でまともに通信できないのは 『不良品』以外の何者でもない。 Microsoft network の仕様は RFC になっていない(嘘八百が 並べられているだけの RFC なら1つあるが、 アソコに書いてある通りにプログラムを作ってもろくに通信できない)、 Microsoft のページへ行っても嘘しか書いてない、 下手をすると Microsoft 自体仕様すら解っていないとしか思えない 現象が次々とまき起こる。

このトラブルに、Winsock のバグが追い討ちをかける。 もはやちょっとした時間しかない人間には 解決できない。 にもかかわらず、初心者ほど「何も設定しなくても動く」 MS network が使いたいと言い張る。 新しいプログラムの1つインストールするぐらい、 ちゃんと説明するからやれよ、 と言いたいがそうもいかない。

この本はそのような、泣きそうな IT 産業の人達に対する朗報である。

高橋さんは「Samba の偉い人」の一人だが、 その彼が Microsoft Network を1から動作をトレースした結果の 集大成がこの本だ。 実際に動作しているシステムを1つ1つトレースして割り出した 動作解説ははっきり言って Microsoft が出している資料よりも正しい。 下手すると Microsoft の人間は会社の金で全員この本を買い、 実はどうなっていたのか理解しなくちゃいけないじゃなかろうか、 と思うぐらいである。

彼の努力と根性には本当に頭が下がる。

ただ、その結果見えてきたのは、
「やっぱり Microsoft の代物なんぞ使うもんじゃない」
という結論だけだ。 理由?この本をまず読んでどういう実装になっているのか見れば解る。

このような仕様を「意図的に」作り上げられる人間がいるとしたら、 そいつは悪意の固まりに違いない。 知らぬうちに作ってしまってそれを正当であると主張する奴は 恥知らずだ。

この本は是非みなさん、読んで欲しい。 この気が狂った仕様のnetworkは、絶対滅ぼすべきだぞ。

Mach → OSF/1 と続く、『もっとも著名な』マルチスレッドOSに関する 解説書。

この本にはマルチスレッドプログラミングに必要なあらかたの考え方が すべて載っていますが、一度読んだだけでは理解できません。 マルチスレッドプログラミング自体が極めて複雑で、 なぜにそんなものが必要になるのか、 実際にある程度熟慮を重ねてからでないと判らないからです。

何度も読み直すことをおすすめしたい一冊です。

C++ はそもそも再利用し易いことを歌い文句にしているが、 実際はそんなことはない、と感じる人は多い。 まぁ、後先考えないプログラムは どうあがいても再利用などできるはずがないのだから それは当然のことなのだが、 じゃぁ「どうしたら、本当に再利用し易いコードを書けるか」 ということをテーマにした本。

そう、これは「再利用し易いコードを書くにはどうしたら良いか」を テーマに した本である。 現実問題として、この本の通りコードを組んで再利用できるかと聞かれたら、 私は即座に NO と答える。

オブジェクト指向にとって重要な要素は結構書いてあるし、 C++ の持つ癖もそこそこ押さえてはある。 そういう意味では良い本で、 ちょっと C++ に慣れた辺りで読む分には結構良い本だとは言える。 細かいテクニックもそこそこは書いてあるし、 多分「慣れた」辺りの人が気がついてない C++ の機能なんかを自覚させてくれるという意味ではまぁ使える。

しかし、 この全てを実践してもなお 「全く再利用性のないプログラム」 は簡単に書ける。 後先を考えないで作ったライブラリは、 たとえ継承などをどんなに慎重に考慮しても それ以前の機能のレベルで再利用に耐えないのだ。

オブジェクト指向言語はそれゆえに 「クラスデザイン以前の問題」 の方にはるかに多くの力を注がなくてはいけない。 そのことが全く記述されていない。

ただ、それでも役に立つことは書いてある。 『きちんとマニュアルを書け』なんてのはその際たるもので、 これをやらずにソースを見て全部理解しろと言う人間がいかに多いかを 考えると、この１文だけでも上に述べた欠陥を補って余りあると思う。

一応、お勧めである。

この本を持っておらず、 この本の原著である C-FAQ の存在も知らない人は、 C のプログラマーではない。

もし、あなたがポインターを理解しはじめた頃のプログラマーなら、 この本なしではいられない。

もし、あなたが一流のプログラマーなら、 後輩にこの本を勧めているはずだ。

だいたい、C はあまりにも「落とし穴」が多すぎる。 結局ハードウェアもソフトウェアも理解した上で、 さらにコンパイラーの気持まで酌んで上げなくては、 望み通りのコードが発生しない。 この中には最適化によるメモリアクセスの消失など、 正しく理解していないと致命傷になりかねないものまである。 しかも、商用実装系の多くは実に呆れ返るようなバグが残ってたりもする。

それ故にこの本は C でプログラムを組む全ての人にとって重要である。 この本は、あなたのもっている「判ったつもり」を粉砕してくれる。 代わりに C に関する正しい知識をくれる。

もし、あなたがプログラマーならこの本を持っているか、 この本の原点である C-FAQ を読むべきだ。 読んで、その全ての内容が「当たり前」だと思うのなら、 あなたは C のプログラマーとしては1流だろう。

Security それは最後のフロンティア(そーじゃなくて)
理論に対する理解のなさ、実装と理論との乖離、 そして現実と理論の乖離が隙を生み、 その隙を攻撃され、 望まぬ結果に突き落される。

Securityと言うと、暗号と勘違いする人もいる。 確かに暗号はSecurityを語る上で重要ではあるが、 これは同じものではない。 暗号は離散数学の一種。 Securityは Computer Science(工学)の一種。 工学は当然、 数学理論を応用するからSecurityを考えるときには暗号も出てくるけど、 暗号が Security の全てではない。 どれぐらい全てではないかというと、 暗号はSecurity全体の1%を切るぐらい。 別の言い方をすると、 暗号で悩む量の100倍悩まないとSecurityとしてろくなものにさえならない。

じゃぁ、Securityって何さ、と言うとしかし、途端に詰まる。 あまりにも広大な範囲を含んでいるからだ。 その中には「セコムしてますか?」も、 「シリンダー鍵」もあれば、 Software 品質管理もあれば、 リスクマネージメントもある。
当然、それらの防御技術だけではなく、 攻撃技術も Security の一環だ。 "Man in the middle", "replay", "Social Engineering"…
暗号と情報隠蔽の違いは知っている?

この本はこれらの技術を総括的に説明してくれる。 この本と Applied Cryptography は、 Securityに一瞬でも手を付けるならば、 最低限読んでおくべきものだ。 会社の社長だろうが、部長だろうが、営業だろうが、関係ない。 これは最低限であって、この程度も知らないようでは、 他の人達に迷惑だ。 ましてやエンジニアともなれば…。

「コンサルタントの秘密」の続編。

ワインバーグがコンサルタントとして提示している 発想の転換や問題の真相、それらを解決する方法の探索などを 思いつく上で必要なのは、 心が不必要に縛られていない事だ。 彼は16の道具になぞらえてこれらに必要なポイントを説明している。

うーん。 彼の本がいまだにハッとさせられる事が多いという事は、 わたしもまだまだだという事だよなぁ。 いかん、いかん。 精進しないと。

まくらネタは萌えネタのくせに、 内容はちゃんとしていると言う、 一体本当にこれは戦略として当っていたのかいないのか 良く判らないシリーズの2つ目。

ネットワーク管理に関する基本的なポイントはちゃんと押えてあって、 この一冊を読めば、 物理層からアプリケーション層までどこで問題が生じても 一通り調べられるようになる。

手元にあって絶対役に立つ一冊だが、 手元にあると絶対周囲は誤解する一冊でもある。

RAID テクノロジーに関する基本中の基本のような内容を かなり噛み砕いて説明している本。 超初心者向け。

ソフトウェアを作っている人、Middleware を作っている人で、 RAID を見たことがない人はこの本から始めると良い。 押さえておくべきポイントの基本的な項目に関しては、 一通り簡略した説明がなされているので、基礎知識をつけるには最適。

あなたが私のページをみている、 と言うことは何らかの形で計算機を使っている、 と言うことだ。 と言うことは何らかの形でstorageを持っていると言うことであり、 と言うことは…そのデータは、あるいはプログラムは、 メディアの破損によっていつか必ず消滅するわけだ。

で、質問。バックアップ、取ってる?

この本は Unix の、主としてサーバーに関しての、 バックアップに関する説明をしている。 単に Unix の通常のファイルシステムだけでなく、 データベースシステムのバックアップに関しても述べている。 もちろん、バックアップを取っても復元しなかったら意味はない。 リカバリがいかに重要か、も当然判る。

単にバックアップのやり方に関する説明が並んでいるだけでなく、 バックアップの必要性についても述べている。

この本は次のような計算をしたことのない人にお勧めである。 以下の計算を見て、「げっ」と思ったなら、 多分あなたが必要とする情報の 80% はこの本に書いてあるからだ (これはある SOHO な事務所での実際行った計算結果だ。 こんな簡単な計算でもバックアップを取らないとかなり損をすることは、判る)。

仮に、あなたは今、どうしても計算機上に存在して欲しいデータが 1Mbyte ほどあったとしよう。 もちろん、この 1Mbyte のデータのオリジナルはすでに何らかの形で 印刷されているので、 失っても再入力は可能だとしよう。 ただし、その入力には 80時間ほどかかる、としよう。

この 1Mbyte ほどのデータは、 さほど大きくないのだが毎日少しづつ変化していくとしよう。 従って、バックアップを取る場合、 毎日バックアップを取らなくてはいけないとする。 バックアップを取るのに必要な時間は一回 3分とする。 メディアは Floppy disk とし、50枚1セットの Floppy をローテーション で利用するものとする。このメディアの価格は 2000円だったとしよう。

一方、あなたがバックアップを取ろうが取るまいが、 OS や計算機、HDD などのせいで、平均 3年で破損するとしよう。

さて、3年とは 1096日である。 仮にあなたがバックアップを取ったとするならば、 あなたは平均 54.8 時間をバックアップのために消費することになる。 この他にメディア代 2000円があなたの支払ったコストである。

バックアップしなかった場合、 80時間が浪費されるのだから、 あなたはバックアップを取ることで、 平均 25.2 時間をセーブし、その代わり 2000円を使うことになる。 この事実は、もしあなたがバックアップを取らなかった場合、 あなたがデータを復旧するために消費した時間の時給は 79.36円/時 だ、という事になる。

これらは、あなたがデータ入力をしている間、 データを使えなかったために生じる被害が全くなかったとして、 の話だ。 もし1時間 100円の損害が発生したら、 データ入力の間 8000 円の損害が発生することになるから、 25.2時間の余計な労働と、6000円の相対損失が発生したことになる。

バックアップを取った上でマクドナルドでバイトした方がまだまし、 という状態だと思わないだろうか? バックアップを取らなかった場合、 あなたの場合は一体どれぐらい損をするのだろう?

「印刷機」が「計算機」とつながり、 「計算機」が「画像」を「印刷」できるようになった。 グーテンベルグ以来の印刷の革命である。

計算機がネットワークによって相互接続されるようになるとすぐ、 プリントサーバという概念が生まれた。 印刷機を管理するマシンを用意し、 その他の計算機は管理用マシンに頼んで 印刷を行ってもらうわけだ。

と言うわけで、この本は「プリントサーバ」についての話である。

この本では lpd のような簡単なプリントスプールシステムから、 LPRng(LPR Next Generation)、 Windows->Unix, Macintosh->Unix, NetWare->Linux などのプリントスプールの管理と SNMP や LDAP などのプリンタ管理の両方について説明している。

あまり知らない情報は書いてなかったので、 役に立たなかった。 そもそも、この本を買った理由は プリントサーバ と プリンタサーバ の明確な違いを知るためだったのだが…。

Web Server において特に顕著なことではあるが、 一般に公開されているサーバに対してクライアントの数が多すぎると、 単体のサーバではその負荷を処理しきれなくなる。 この場合、サーバを外部からは一台のように見せかけた サーバ群 にすることで、負荷に対処する方法がある。 もちろん、これは１つ１つの負荷が基本的に独立していて (あるいはそれに近い状態にあって) 並列化が可能な場合に限られるが。

この場合、サーバー群と Internet の間にあって、 負荷を複数のサーバーに分配すると同時に、 外部に対してはまるで単一のマシンであるかのような振りを演出する マシンが必要になる。 このようなマシンを負荷分散装置と言う。

この本は、負荷分散装置の基本的な構造、 提供してくれるサービスと、 負荷分散の理屈に応じたそれらの接続方法、 さらにいくつかの代表的なメーカーの負荷分散装置について 述べている。

負荷分散技術は、 これに集中しすぎると Security に欠損が出るし、 分散のさせかたが甘いとボトルネックが発生してしまう。 はっきり言って 下手な考え休むに似たり な類いの問題で、 自力で考える前に、 どのような場合にどのように攻撃を受けるとどう突破されるのか、 ちゃんと既知のパターンを調べた方が良い。

この本は、 残念ながら半分が既存の負荷分散装置の簡略版マニュアルになっていて あまり役に立たない。 今、負荷分散を必要とする人に重要な本だ、と言える。

2000年7月以来、Microsoftが叫び続けている .NET Frameworkは、 2002年末現在、Microsoft社製品の多くが対応を進めている、 Microsoftの一大攻勢戦略である。 そのキーワードは、 分散型コンピューティング、 コンポーネント化、 Web(HTML, XML, SOAP)化、 ということになっているが、これら以外に Common Type Systemという 実行用ファイルに自分が提供しているクラス・メソッド情報を格納する 機能を使ってのDynamic Loadingに対する対応、 Common Language Infrastructure という何でも中間言語攻撃によるプラットホームCPU独立にして 自分の作ったVMインストラクションへのユーザーの囲い込み など、市場を独占するための機能が満載になっている。

一言で言えば、 .NET Framework は、正しく作り、 公正なコンソーシアムによる標準化が行われればとても便利なものだが、 OSだけでも致命的なバグフィックスを月2回づつ発行し、 寡占のためならヤクザそのものなMicrosoftが規定すれば、 危険窮まり無い代物だ。

この本はその .NET Framework について広範に説明した本である。 半分は XMLを利用したリモートコンピューティングについて どのような機能が標準的に提供されているのか、 という話になっている。

これだけではプログラムはつくれないが、 たしかに面白い機構であることは良くわかる。

表題どおり。 Linuxについて、 特にServer系のトリックを中心にまとめた本。 100の項目に分かれているが、 特に最初の方のブートパラメータなどが結構役に立つ。

特にboot時の引数の説明の中には init の代わりに任意のプログラムを動かす方法が述べられている。 当然、/bin/shが動かせるわけで、この場合 login/password を 尋ねられる事もなく、root権限が得られることになる。 当然、知っていると便利だが、セキュリティ的には致命傷である。

unix ってここまで危険だったっけか…というか、 こんなOSを Server として使ったら危険極まりないと思うんだが…。 いいんだろうか。

とにかく。とりあえずお勧めである。

ldd の動作とか、 LD_PRELOAD を指定するとどのタイミングで動的ライブラリを持ってくるのか、とか。 objdump は何ができるのかとか、 シグナルハンドラを書く上での注意点はとか。

とにかく、どこぞへ問合せが来る質問のうち、 中ぐらい80% は「この本を読め」と言うだけで問題が解決してしまうような、 そんな本。残り20%はこの本まで到達していない…。

そういうわけで、素晴らしい本だと思います。 ちょっと分類法が苦しくて、欲しいQAを見つけるのがとんでもなく大変ですが、 しかも大抵3つぐらいを合わせ業にする必要があるんですが、 まぁ、それでも圧倒的に便利です。

問合せなんぞしてこないでこの本を買え、と言いたい。

前使っていたC言語辞典 がぼろぼろになったので、買い替えた。 が、これは酷い。失敗である。 これなら前の奴を使ってた方がよかった。

何が悪いって、本を小さくするために読み難いフォントと小さな字を使い、 項目毎にページを使うこともなく無理やり詰め込んでいる。 さらに、可能な限り小さくするため説明も最小限度。

初心者にはとてもお勧めできない。 こんなのを使えと言うぐらいならば「Cを使わずに C++ を使え」 と言った方がましである。

ただし、書いてある内容に関しては比較的信頼できる方である。

C やPascal のような言語を使っている人間には、 C++ のようなオブジェクト指向言語というのは、 わかりやすいんだかわかりにくいんだかわからない所がある。 オブジェクト指向の中の一部は良くわかるんだけど、 別の所が全然…

この本はそういう人にお勧めである。

別に内容が優れているわけではない。 説明としては嘘がたくさんまぶしてあるし、 文章としては二流だし… だからこれは『オブジェクト指向の教科書』にはならない。

この本は今まで手続き型言語でプログラミングをしてきた人が、 オブジェクト指向の教科書を読んだ後に読むものである。 教科書を読んだので説明としては正しい内容を覚えている、 でも全然頭の中でこなれていないので、よくわからない。 そう言う時に、 この本を読んで『従来の知識』と『新しい知識』をくっつけるのだ。 多少の嘘があってもすでに正しい概念の方は覚えてはいるのだ。 糊としての役目が終れば自動的に頭から消えてくれる。

そういう「オブジェクト指向という概念の仮止め用の糊」 のような本だというのがもっとも適切な評価だと思う。

新しくオブジェクト指向を勉強しようと言う人は、 普通の教科書とこの本の両方を買ってきて、 『２冊目として』読むことを強く勧める。 間違いなく、オブジェクト指向とは何かを理解できるようになるだろう。

プログラムを作る上で最も大切なのは、 たくさんアルゴリズムを知っておくことである。

「問題」を「解く」ために「解き方」を考えるのは悪いことではないけど、 もう誰かが解いちゃった問題を解き直す必要はないし、 その結果が「誰か」のより悪かったら洒落にもならない (もちろん、 新しい答を出した場合に、 今までのどれよりも良いことを知るためにも過去の 「解き方」 は知らなくちゃいけない)。

だからといって「アルゴリズムを暗記する」というのもばかばかしい。 ゆっくりとではあるがアルゴリズムというものは確かに進化していて、 それらを全部追いつつ、覚え直す、というのはしんどいだけ。

でも「アルゴリズム事典」ものの中には名前の羅列だけで、 具体性に欠けた 『書いた奴がわかってないのか、編集が馬鹿なのか』 と言いたくなるようなものもある (自分が触れたことのある唯一の本がそういう本だ、 というのは秘密だ)。

安心して下さい。この本は違います。

JavaScript を Netscape Navigator 3.0 上で書くための本。 と、そういうことになる。

JavaScript を書くときには役に立つ。 特に、Java と JavaScript は似て非なる言語なので、 Java を知っている人が「楽勝」とか言ってるとえらい目に合う。 そんなあなたにはこの一冊、かもしれない。

基本的に、プログラミングをやったことのない人向けの 本の体裁をとっているので、 バリバリのコーダーにはちょっと煩いところはあるかもしれない。

「Tanenbaum 先生の教科書」のネットワーク編。 物理層から Application 層まで、基本概念がきちんと書いてある。

これだけで network プログラムを書くのは無理があるが、 ここに書いてあることを知らずに network のプログラムを書くと、 大抵失敗する。

一方で最近は network を使ったプログラムは 当たり前になっているので、 この本は絶対に読んでおくべし。

「最前線」とあるが、この本の本当の価値は

という点にある。

unix のシステムは決して完璧なものではない。 歴史的な理由で不完全なものが採用され、 互換性保持のために矛盾が解除できないでいる、 などの問題点をいくつもかかえている。

そのような OS が未だに『最も実用的で安全』であるというのは、 おそらく恥ずべき事実なのだろうが、 それはともかくとしてこの本はそれらの問題点を全て キチンと説明している、という点にその真の価値がある。

この本は原著が 1996 に書かれた本なので、 新しいとは言っても本当の本当に『新しい』話は出てこない。 ただし、この本に出てくる内容は 2001年現在、全く古くなっていない。 実質的な進化は止まっているに等しい (いや、それどころか Linux など、ここまでまだ到達していない。 vfs の実装が不完全すぎる)。

もしあなたがいかなる形であれ自分をプログラマーであるとしたいなら、 これは最低限読んでおくべき本である。 世の中の OS の「最低線」はここにあること、 ここよりも下は「OS」などと呼べるものではないこと、 どんなに悪くても最低これぐらいはやるべきだと言う事、 を把握しておくのは、 プログラムを書く上で絶対に重要な知識だからだ。

「古典的な」という注釈をつける必要はあるが、 デジタルロジックからアセンブリ言語までの、 ソフト屋さんが主として「ハードウェア」と認識している部分に 関する教科書。

この本ではソフトウェアを作っていく上でとても重要な いくつかの視点が提示されています。 その最も大きなものは、

OS のシステムコールやライブラリコールというのは、 CISC 命令を拡張するのと同じことだ

というものです。

この視点をさらに拡張すると、 RPC も CISC 命令を拡張するのと同じことだ、 という発想が成り立ちます。 この視点に立つと、 CISC 命令を拡張する際に使われた Microcode レベルでの最適化は 当然、RPC などを実装する際にも利用できる、と言うことになります。

このような視点の変化、を齎すという意味で、 この本を読むのは大事でしょう。

プログラマも上級になってくると、 必要になるスキルはプログラム言語の文法を知っているのでも、 アルゴリズムを知っているという知識でもなくなる。 プログラムをデザインする際に、これらの知識を駆使する能力になる。 さらに複数人数でプログラムをつくることになれば、 意志伝達能力や決定なども問題になる。

この本はそのようなスキルに関する話を少しづつ集めた本。

このクラスになると個人的な好き嫌いが強くでるらしい。 賛同できる内容も、出来ない内容もある。

たとえば、この本では
「自分の作品にはちゃんと自分のものであるという印を入れろ」
とある。 一般の品質管理本には「これはやめろ」とあるが、 私はこの本の言うことのほうが正しいと思う。

その一方で、この本では
「テストは重要である。」
として、テストを最初につくる事を推奨しているが、 私はこの意見には賛成ではない。 最初に思いつくテスト項目がそんなにしっかりしているぐらいならば、 その後のコーディングでも大きな問題などでない。 最初に思いつく問題項目が『甘い』からこそ実装段階で失敗するのだ。 私の意見では、テストは最後に作るので構わない。 ただし、
「テストにはいる前に休暇を取れ」
という点が普通と異なる。 結局休みなしでコーディングからテストに突入するから 甘いテストになるのだ。 テストを開始する前に休暇を取って一息つくと同時に、 休暇が取れるぐらい『無理のない』スケジュールこそが 良いコードを最短時間で得られるコースである。

というわけで、この本は良い点も悪い点もあるが、 少なくとも最低限ここで述べられているような事について 考えておくことは良いことだ。 と言うわけで、プログラマーには必見の書。

ソフトウェア工学という言葉は NATO の「ソフトウェアにおける問題」に関する 協議会の設立を提唱した研究グループによって1967年に作り出された。 このソフトウェア開発戦略は2つの特徴がある。 1つ目は大規模開発向けである、と言うこと。 2つ目は「品質」だけが制約条件だ、と言うことだ。 1つ目は良く知られているが、 2つ目はあまり知られていない事実だろう。

たとえば、この本では1969年から1975年にかけて開発された SAFEGUARD 弾道ミサイル防衛システムが例として挙げられている。 このプロジェクトは 1969年に 188人年ではじまり、 1972年 の1261人年をピークとする、 合計 5407人年を要している。 1人年当たりに変換すると 418命令(アセンブラで記述したため)しか 生成されていない。 そして、この効率は決して例外的に効率が低いわけではないのだ。

ソフトウェア工学がこのように、 生産効率の悪い戦略であるにも関わらずこのようなやり方をするのは、 品質が絶対条件のプロジェクトだからだ。 SAFEGUARD が「そこそこに安く、そこそこに動く」ようなシステムでは困る。 敵の弾道ミサイルは 100% 検出し、 確実にミサイルを叩き落とせなくてはいけない。 そのために必要なコストはいくらになっても確実に。 これがこのプロジェクトの命題であり、 だからこそソフトウェア工学は必要なのだ。

同じことは NASA のプロジェクトについても言える。 当時の NASA のプロジェクトは人をつきに送りるものだ。 しかもソ連(当時)との対立があるので、 絶対に失敗は許されない。 絶対の品質を要求するのだから、 ソフトウェア工学のように品質要求を満たすまで人間を投入し、 テストを繰り返すシステムは絶対に必要なのだ。

逆を考えてみよう。

普通のアプリケーションは『絶対の品質』など要求しない。 しかし、ソフトウェア工学以外に適当な指標がなかったため、 アプリケーション開発にもソフトウェア工学は適用された。 ただし、コストを加味するために「ほどほど」に。

しかし、よくよく考えてみればこの方法は成功しない。 1人年で418命令しか記述できない戦略のコストを半分にしても、 1人年で836命令にしかならない。 乱暴に4命令1高級言語行と計算して、 現在1人年で期待されている行数 8000行を発生させるとは、 コストを1/76倍にすることを意味する。 ソフトウェア工学が示すバグ曲線の「最初の 1/76」の領域は、 まだバグが急速に生長を始めたかどうか、 という入り口も入り口のポイントに過ぎない。

これでは事実上全くデバッグをしないに等しい。 このようなものは、誰も買ってはくれまい。

実際には、成功するソフトウェアプロジェクトもある。 それらのプロジェクトの多くはソフトウェア工学にちゃんと従っていない。 だから成功することも、大失敗することもあるのだ。 成功するのは、本当の意味で成功する方法を(偶然かも知れないが) 実行したからであり、 失敗するのは、成功する方法を外したからだ。

本書は、 ソフトウェア開発を「職人技」としている。 「繰り返し」を前提とする『工業』ではなく、 工業をデザインする「設計」がソフトウェア開発の真の姿であり、 「工学」は「設計の道具」であって「設計技術そのもの」ではない。 「設計」そのものは結局「職人技」である。

そして、その職人を、「アプレンティス(入門者)」 「ジャーニーマン(中級職人)」 「クラフトマン(上級職人)」に分類し、 入門者をどのようにして上級職人に育て上げていくべきか、 それぞれをどのように扱うべきなのか、 述べている。

おそらくは最も企業から絶対受け入れられないであろう、
「管理職よりも上級職人の給与は『圧倒的に』高くなくてはいけない」
(個人的には大いに同意する。 無能で、全くコードを書かないくせに、 ぎりぎりまで自分のコーディング分を主張する Group Leader に、 私より高い給与が払われているなど、承服しがたい) など、 大胆で『正しい』方針がしっかり記述されている。

うまく行かなかったプロジェクトに参加したことのある人、 プロジェクトがうまく行かなかった経験のある管理者は、 この本を読んでみると良い。 もし、冷静にそのプロジェクトの事を思い起こせるなら、 この本にはそのプロジェクトの問題点が記述されていることが判るだろう。

プログラマーは全員これを読むべきだ。

Firewall とは何なのか、 こいつがないと悪意を持った人は一体何をしでかしてくださるのか、 について言及している本。

ネットワーク全般に関する話なども書いてある、 という意味でも役に立つし、 悪いことをしようと言うときにも役に立つ。 実に一石何鳥にもなる本。 是非確保しておくことをお勧めする。

家庭から会社のメールを読んだり、 サーバの状態を監視したりするには相応の Security 保護が必要になるが、 だからといって会社の LAN のために専用線を張るわけにはいかない。 コストが高すぎるからだ。 そこで、 暗号による Secure Pipe を通して Local Network の外部から Firewall などの防壁の中へ (Local Network に直接接続されているのに極めて近い) サービスを受けるニーズが高まっている。 このニーズに答えるのが Virtual Private Network(VPN)だ。

VPN に近いものを実装する方法はいくつもある。 IPSec を使うのも1つの方法だ。 ただし、ストレートに IPSec を使うには Lan の中のアドレスが 外部から見えなくてはいけなくなる。 これは別の Security Hole をつくりだすので、 VPN では Gate の所に Server を用意し、 VPN Client と VPN Server の間に(Gate を越えて)仮想トンネルを張り、 仮想トンネルを通じてデータをやり取りさせる。

じゃぁ、PPP と SSH を使って…。 実はそれも VPN。

この本はそのような話が書いてある。

OSの基礎と応用 の続編とも言うべきOS に関する教科書。 今回は主に分散 OS について述べている。

「分散OS について述べている」とは言ったものの、 実際には非分散 OS においても重要な概念がたくさんでてくる。 mutex、 時間同期、フォールトトレラント、分散障害など の概念は確かに分散 OS ではじめて『深刻な問題』として表出する。 そのため、非分散 OS の教科書ではあまり扱われないが、 実際には非分散 OS を考えるときだって これらが重要な概念なのには変わりない。

従ってこの本は OS の構造について興味を抱いた人にはお勧めである。

お勧めではあるが、 この本、 相変わらず Tanenbaum 先生は良い英語の文章を使っていない。 さらに翻訳陣はどうやら英語の「冗談」がほとんど理解できないらしく、 冗談の果てまで全部『直訳』している。 もし、「日本語の本としてどうか？」と聞かれたならば、
さいてー
と答えざるを得ない。 実際、これほど酷い文章でかかれていなければ、 はるかに理解しやすかったはずだ。 内容が内容でなければ途中で投げ捨ててここのリストに載らない『却下本』 の仲間入りをするはずである。

内容が、文章の酷さを圧倒的に凌駕しているとも言え、 それゆえにお勧めではあるが、忍耐力を要する一冊である。

どうでもいいが、このプレンティスホール出版、 こんな酷い翻訳をするぐらいなら私に任せて欲しいもんである。 圧倒的に良い訳を出してあげるぞ。

『オブジェクト指向』というと『開発期間が短くなる』とか 『オブジェクトの再利用性が高まるよ』とか良く言う。 でも、現実にはそんなことがちゃんと起きてない場合が多い。

これは、歌い文句を信じ過ぎた結果であって、 決してオブジェクト指向そのものの罪ではないが、 でも落し穴ではある。

『オブジェクト指向』は、まず『再利用するもの』がなくてはいけないし、 『再利用すること』を前提にシステムを熟慮して作らなくてはいけないので、 デザイン期間はとても長くなる。 このことを忘れてデザイン期間を短くとれば当然使いものにならないコードの 固まりになる。

『オブジェクト指向』的な考え方をまず訓練してからでなくては そもそも『オブジェクト指向』は使えない。 この『訓練』を忘れると、救い様のないものしかできない。

以上のような問題が、従来の手法を使っても成立している 『仕様の頻繁な変更』 『パターン列挙をすればよいと思い込む』 『不適切なアーキテクチャの利用』 『同一動作を行なう、異なるデータ構造の乱立』 等々に加えて生じる。 これらの落し穴をきちんと解説してくれる、 プログラマーは必見、マネージャー必読の本である。

ここに書かれていることの中に１つでもわけのわからないものがあるなら、 マネージャー失格だし、プログラマーは経験不足だと言えよう。 そんな恐ろしい事実がバレル前に読むべし！

世界最大のデータセンターを持ち、 世界最強の分散コンピューティング環境を構築している Google。

この本は、分散ソフトウェア、ハードウェア、企業文化の3点について、 特に分散ソフトウェアを中心に、 既存の論文集やすでに公開されている資料等を元に一部類推を交えつつ、 あの会社が持っている技術を説明した本。

本質的には既出情報なので、それらを全部読んでも同じ結論に到達するが、 技術的理解が面倒な部分などをばっさり切り落として判りやすく要約しているため、 かなり読みやすい。

超・お勧め。

特に、日本の SIer や SIer にシステム発注をする人達は必須。 分散システムの方がコストやエネルギー効率が良い事、 分散システムでは最初から一部分が壊れる事を想定して、 定期的なメンテナンスをしつつも全体としては止まらないようにする事、 などを最初から考慮したシステム作りについて多くのヒントが得られる。 このような方法論を最初から退けたり、 無駄に過去の実績、他社の事例ばかり追い求める 人達にはGoogleというすでにある実例は 都合の良いものだろう。

各資料の URL もきちんと掲載されており、 後々までも役に立つと思われる。

『詳説 正規表現』 の改訂第3版。

上記の初版が出て以来9年、 正規表現は実に多くの言語やアプリケーションに採用されるようになった。 特に Lightwight Language と言われるインタープリター系言語は ほぼ確実に何らかの形で正規表現を使えるようになった。

と、同時に。さまざまな正規表現の拡張が図られ、 従来ならば不可能だったマッチングが次々と可能になっている。

本書は、これらの機能を理解し、有効に使えるようになるために、 次のような手順を取っている。

1. 基本的な正規表現の理解
2. 正規表現エンジンがどのように実装されているのか、その基本的な動きの理解
3. 基本的な動きを理解した所で、再び正規表現の理解。今回は複雑な動きをするパターンについて

これらを全て追い回すのはすさまじく大変だが、 これらを理解する事で初めて、 正規表現はあなたの手足となってくれるだろう。

中級者以上の全ての人にお勧め。 この本を読んで見て、有用性が判らないうちは初心者だ、といえよう。