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

小話と技術解説を繰り返しながら Mail や News の セットアップの仕方などを説明する本。

この手の本はやはり枕の小話だけ読んで、 本体は本当に必要になった時に読んでしまうという悪い癖のある私には、 ちょっともったいないかもしれない。 でも思わず買っちゃう。

メールやニュースなどのシステムってどう動いているんだろうとか、 sendmail ってどうしてあんなに厄介なのとか、 そういう疑問を持っている人にはお勧め。

じゃぁどうして今持ってないのかというと…そりゃ、 FreeBSD の解説書が出たから。 そちらの方が情報が新しい。

NetNews が華やかなりし頃…つまり、 WWW がまだ全然流行ってなくて、 Netscape なんかないも同然で、 パソコンが通信すると言ったらパソコン通信だった頃、 一番多くの人と通信するための手段は NetNews だった。

NetNews の中でも日本語が自由に使えたのは fj(From Japan) だけだった。

で、この当時流行っていた「歩き方」本の形で出したのが、これ。 この直後辺りから WWW が流行り出して、 NetNews 自体が一気に下火になってしまった…。

CD-ROM の基本的な知識を説明した本。 途中からこの前提に立ってマルチメディアコンテンツについて説明もしている。

基本的には sector 構造などを知りたくて買ったのだが、 はっきり言って何を考えるとこんなにややこしいフォーマットにできるんだ…。

昔、bit という雑誌があった。

およそ一般販売されている中で最も高レベルな内容を扱う、 主としてプログラマ向けの計算機雑誌ではなかったかと思う。 これはその bit での不定期連載、「ナノピコ教室」を 本にまとめたもの。

様々な変わった問題が並べられており、 これを「計算機を使って」解く事が求められる。 結構面白い問題が多くて、私は好きです。

プログラミングからプログラミング言語、OS、 インストールとうとう、 実に様々なソフトウェアに纏わる 半分真剣・半分妄想のエッセイ集。

Themsky は実際にはそういう「単体の人」の名前ではなく、 複数の執筆者が集まって作り上げた名前なので、 そのことがさらに話の多様性を持たせて面白い。

昔、まだ O'Reilly がオライリージャパンを立ち上げていなかった頃、 ASCII が翻訳して出版した NUTSHELL HANDBOOKS の一つ。

Unix においてC言語でプログラムを書こうとする場合、 必要になる一般的な知識が書かれている。 2007年の今となっては POSIX の名の下に、 大抵の(組み込み系以外の)環境で提供されているこれらの システムコールやライブラリは、1980年当時は本当に資料が少なかったのだ。 と言うわけで、私もかなりお世話になりました。

なお、 2006年当時の仕事で、 どこぞの三鷹にある研究所 の人達が真剣に問合せをかけてきたことの一つに、
『fwrite と write の違い』
というものがありますが、この本にも答が書いてあります。第2章と第3章です。

確か同じようなタイミングで、 シグナルを使ったかなり勘違いしたプログラミングをしようとした問合せも あったかと思います。
「死ぬほど難しいから辞めとけ」
が本当のメッセージだったはずですが…どう難しいのか、 この本の第8章と第10章にも書いてあります。 Binary Hacks の方が入手しやすいのでそちらで答えたかと思いますが、 判りやすさだとこの本の方が上です。

もちろん、問題点はあります。 内容が2007年現在では時代遅れです。当たり前ですが。

でも、訳もかなりしっかりしていて、良い本です。 本棚に余裕があるならば、 購入してみるのも手でしょう。

sed と awk に関する解説本。 さすがにボロボロになってきたので第2版に切り替えた。

大昔、私が持っていた誤解の一つに、 計算機言語というのは１つ使えてりゃいいもんである というのがあった。 これは、ことが Pascal, Modula-2, C, C++ の４つに関する限り、 そして環境が DOS である限り、正しかった。 ところがぎっちょんちょん、 環境が unix のようなマルチプロセス環境にいる場合、 これは間違いだったのである。

DOS のような環境においては、 フィルタリング処理というのはかけてせいぜい１段なものである。 何しろいちいちテンポラリファイルに書き込むのだ。遅い。 しかも処理している間は何もできない (仕事をしなくてもいいのは嬉しいが、ゲームもできないのだ)。 こんな環境では、処理の全てを一度に済ませてくれるプログラムを 組んだ方が早いのは理の当然である。 ３時間かけてプログラムを練りあげ５分で処理を修了させる方が、 10分でフィルターを完成し、３時間イライラ待つよりも有意義なのだ。

ところが unix の世界はそうではない。 計算機が多少チンタラ仕事をしてたとしても、 こちとらもその間別の仕事(ゲーム)をやることができるのだ。 ３時間かけてプログラムをきっちりと練りあげ ５分で処理を修了させるよりも、 10分でフィルターを設計し、20分で処理を修了させ、 その間に rogue を１フロアークリアする方が有意義なのだ。

unix でフィルターを設計する場合、 圧倒的に文字列を処理するもんが多い という特徴がある。 そして、一度でも C を使ったことがあればわかると思うが、 C 言語と言う奴は論外なほどに文字列処理が無能 である。

どうやら他の人達もそのことは極めて初期のころから判っていたらしく、 いくつもの文字列処理を専門とするインタープリターができている。 sed と awk というのは、この条件を満たす、便利なインタープリターである。 これと perl をマスターすれば完璧。 フィルターマスターとして めでたくゲームをする時間を確保できたも同然である。

この本は nutshell シリーズの１つである。 このシリーズの特徴通りこの本も比較的わかり易い。 是非読んで、時間を有効に使って頂きたい。

ハッカー用語の辞書です。 編者は、後に「伽藍とバザール」で暴言を吐くことになる Eric Raymond。

こうしてまとめると、結構笑えていいです。 ただ、もはや、若干、歴史教科書の仲間入り。

昔、まだ PC に Sound Board が拡張ボードとしてしか存在しなかった頃。 Sound Blaster という Sound Board が、 世界を席巻しつつあった。

この本は、 Sound Blaster の外観から初めて BIOS call、利用できる Application などが説明されている。 基本的にプログラムを作るのに必要な情報なども揃っている。 今となっては ActiveX とかを使うんだが…。

Java の基本的なプログラミングパターンについての説明を、 LTK(Little Toolkit)というGUIツールキットの設計と実装を 通じて説明している。

昔はこれで完璧だったのだが、 JIT だのJVM が Sun の出しているバージョン以外にもあるだの 言い出している昨今では、 これではちょっと不十分。

確かに Java の配列はおかしい、 などの Java という言語の落とし穴は問題なくそのままで使えるのだが、 コードの実効速度が遅いとか、 そういうのは javac の出力ならびにそこからさらにチューンする JIT の 性能如何な部分があるので必ずしもここに書いてある通りとは限らない。

というわけで、半分ぐらいしかもう役に立たないような気がするので、 放出を決定した。

Java 関連技術に関して、Peter van der Linden が書いた本。

最大の問題点は、Linden 氏が完全に Sun の「宣伝部長」と化していることだ。 Java の弱点に関してはいっさい言及を許されない鬱憤を、 敵対技術を扱き下ろす事で晴しているきらいがある。 もちろん、だからといって間違ったことは言っていないし、 大抵の場合敵対技術は Microsoft が後猿知恵で出してきたものなので、 この程度の批難では全く足りていないのだが。

というわけで、『Sun 万歳』的な側面が強すぎて、 読んでいてあまり面白くないです。 Java だって単なる１技術に過ぎないんだから、 ここまで「まんせー」状態にしなくてもいいじゃないか、 という気がバリバリ、する。

Windows 上で、 普通なら Visual Basic でやることを Ruby を使ってやろうぜ、 というまさに『邪道』な話。

しかし、何よりも邪道だったのは、 この本で Ruby の基本を学ぼうとした、私の行為だろう。

まぁ、乱暴に言えば、
「Linux マンセー!
だから Linux に纏わる GPL を作った Stallman もマンセー!
*BSD から Linux に来た人が多いという意味で *BSD もマンセー!
Perl も Samba もマンセー!
Eric Raimond もマンセー!
OpenSource マンセー!」
という本。 主に歴史を紐解いている。

「動かしてから直す」モデルが Security Hole をいかに沢山作っているか、 とか Incremental Design が破綻的な品質を作っているかとか、 まさに Open Source 的な作り方をした結果が Windows なのであって、 Linux と Windows の喧嘩は近親憎悪の賜物でしかないとか、 そういう事実は都合良く忘れ去られている一冊。

昔の人はね、いきなりキーボードの前に座ったのではなく、 何もなくても頭の中だけでデザインができたのだよ 。 と突っ込みたくなること多数。 Samba の heap overflow バグを見てからこっちは、 突っ込む気力すら失った一冊である。

最近はなんでもかんでもデジタル化が進んでいる。 これに伴って半導体自身も多様化が進んでいる。 もちろん、その他に基本構造自体の改善や、 特定用途にあった技術も開発されている。

この本はそれらの技術を、 よく言えば判りやすく、 悪く言えばほとんど本質を突かないまま、 並べた本。 若干特定の政党・企業に偏った紹介などがたまにきずか。

ソフトウェアにどっぷりつかっていると こういう話が全く判らなくなるので、 とりあえずエントリとして買ってみた。 エントリとしては十分だろう。

Java という言語がある。 ポインターがなく、C++ より単純で純粋なオブジェクト指向言語と 言われている奴だ。 しかし、使っていくとすぐ判る話だが、Java には 違和感 がありまくるのだ。

この本は、その 違和感 の元について解説してくれる。

すごく乱暴に言うと、 Java は C や C++ の文法を真似ている所に根本的な間違いがあるのだ。

C や C++ から来たプログラマは Java が実装しようとしている(あるいは、理想としている)世界では あり得ない実装パターンを、 C や C++ に文法を真似たために、 記述できるかのように錯覚してしまう。 さらにその誤解を助長するかのように、 Java の文法にはおかしな所があって、
「そんな機能、あるだけ無駄やん」
と言いたくなるような機能が(配列とか)、 コレクションクラスライブラリとしてではなく、 基本文法の一部として存在したりする。

しかもそのややこしい代物に Secureness 機能を追加すると、 継承機能にまでパッと考えただけでは理解不可能な制約が出る。

結果として、 デザインをトータルで見ると、 はい？ と言いたくなるような事がゴロゴロ出てくる。

この本は、そういう変な所を指摘している。 変 な所を指摘することで、 Java の誤解しやすい所を解説し、 結果として理解に繋げているわけ。

読んでみる価値はある。 Java が最初の言語だ、という人にはつまらないかも知れないが、 そうじゃない私には結構面白かったです。 ただ、何となくだが、Java の弱点って この本が書いている事だけじゃ無い気がするのは… 多分気のせいじゃないんだろう。

ムック。

ソフトウェアの「テスト」についての専門誌。

今回の特集はテストの中でも上流インスペクション。 あとテスト管理、組み合わせテストがトピック。

個人的には「モデル駆動テスト」が面白かった。 技術的に面白い、という意味ではなく、 あぁ、聞いたことあるねぇ。えぇ、それ弱点が多いんだよねぇ。 ぴしゃっと当たるとめちゃくちゃ効率がいいんだけど…という意味で。

上流インスペクションについては、 是非皆さん一度読むことをお勧めします。

80x86 系プロセッサに 64bit 拡張を加えたAMD64。 Intelが Microsoft にタコ殴りにされて泣きながら出したEM64T。

そのようにして準備された64bit対応CPUって、 従来の32bitCPUに比べて何がいいの? どうちがうの? 美味しいの??! というのはあって当然の疑問だと思うが、 そのレベルの疑問に答えるために書かれた本。

ただし、i4004からの歴史が連綿とつづられたり、 仮想化技術に関する話(それも Virtual Machine の話はほんのちょびっとで、 kernel の仕事の話とか)が延々と述べられている割には根本的に kernel の 説明をしていなかったりとか、
「判っている人が読まないと判らない」
という悪い例になっている。

余分なものを除去するとだいたい厚みが 1/4 ぐらいになるかな。

また、ちゃんとプログラムを組む人になりたいなら、 この本の内容を信じちゃいけません。

でも、普通の人がなんとはなしに64bit CPUってなにー?と思っている程度なら、 この程度の間違いは、ま、いいか、と許容できる範囲。

ただし、どう考えても間違わない説明の方が、 どんな初心者にもわかりやすいとは思いますが。

とりあえず、「使えない」評価はぎりぎり回避、というレベルの本。

表題から判るように、 プログラマ裏話暴露本。 Webの日記もどきを一冊にまとめたもの。

ただ、最初のほうで品質がガクッと落ちて、それっきりになる。 後のほうで、結婚した後で抗そう病になっていたと判る。 ちょうどその辺りで女性だったということもわかる…。

面白かったのは最初だけなので、 あまりお勧めできない。 値段の価値はない。 古本屋で100円だったら読んでもよい、という内容。 投資大失敗。

計算機上に、 人工的な生物を作り、 人工的な環境を作っておいて、 人工生物を突然変化させながら何世代も経過させる。 すると人工生物は与えた環境に適応した存在になる。

仮に、ここにあなたが解きたい問題があるとする。 どう解けばいいのか判らないとしよう。 その代わり、最適解である必要はないとしよう。 もし、生物の記述形と表現形、そして環境を適切に設定したならば、 適応した生物を解析すればあなたが欲しい答が判る、 そのようにプログラムを組むことができるだろう… というのが Genetic Algorithm(GA) の基本的な考え方である。

当然、生物や環境の記述の仕方によって、 適応可能性や適応速度に違いが出る。 環境もいきなり目標状態に持ち込むのではなく、 最初は「甘目に」設定しておいて、 徐々に「厳しい」状態にしていくといいかも知れない。 ただしもちろん、問題によって特徴は変るだろう。 それらを研究するのが GA の研究である。

この本は私の担当教官と助手だった人の著作だ。 ので、ちょっとだけきつめに。

残念ながらこの本ではまだ入門も入門、入り口しか説明がない。 しかもプログラムは Turbo C 用で汎用性がない。 実行系と表示系は普通分離して書くだろうに…。
というわけで、あまり高い評価はできない。 実装を主体とした本としても、 理論を主体とした本としても、 中途半端だ。

技術系 Web 日誌。ハード屋さん系統。 Win95 メイン。

情報量はあまり多くない。 各情報そのものは役に立つのだが、

1. やたらと未来予測が当たるのを喜んでいて、繰り返し出てくる。 でも繰り返さなくてはいけない理由は、記述が熟慮不足で欠損や 不明瞭点が多すぎるから。
   そういう「根拠レス」なのは「予測」じゃなく「予知」だ。 そして予知ならはっきり言って、教祖様、負けない。
2. Windows に固執しすぎているがゆえに出せないでいるパフォーマンス、 という側面が異様に強いが、当人、気づいてらっしゃらない。 L2 キャッシュが Windows でヒットしないなら、 Windows を使わなきゃいいのよ。 Word を使わざるを得ない、 のではなく好き好んで使っておいて、 動作が遅いも何もないものだよ。

というわけで30点。 「使えない」まで行かないが、 Cost Worthy とは到底言えない。

これはもう、タイトル通り。 Smalltalk を使ってオブジェクト指向でプログラムを書こう、という話。 普通の本とちょっと違っているのは、 Smalltalk/V という処理系を使って、 PC-9801 などの上で、アセンブラでメソッド等を書いて、 信号処理などをやらせちゃおう、 というもういかにも制御工学科的発想。

この本のおかげで、 私も C++ などにアセンブラコードを組み込むときのコツなどが解って、 実は重宝した。 ただなぁ…ちょっと古すぎるからなぁ…。

OS/2 を一言で言うならば「デザイン倒れ」と言えばいいだろう。

unix を越える先進性デザインと研究トピックの内容を、 80286というゴミのようなアーキテクチャマシンと、 少なすぎて涙がでてくるようなメモリ・HDD・Network アーキテクチャマシン の上に無理やり実装し、 さらに無理難題なGUI まで載せようとしたのだ。 失敗するに決まっている。

unix がなぜ成功し、Multics がなぜ失敗したのかを全く学習せずに、 あれもこれもと欲しいものを欲しいがままにぶち込んだ産物、 それが OS/2 だ。

この本はそのような OS/2 のアーキテクチャデザイン本である。

この本を読むと判るが、80286 と、16bit interface と、 Presentation Manager と、Installable File Systems と Micro Channel を 全て捨てれば、 結構悪くない物ができあがることが判るだろう。 インターフェースの他の世界との互換性の悪さがまだ残るだろうが、 それでも、unix に thread 機能をくっつけた、 かなり素姓の良いものになる。

OS/2 は無駄に早く出すぎたのだなぁ…と言うことを、 しみじみと教えてくれる一冊。 いろいろとすり抜けて、これを相手にする必要がなかったことは、 実に幸いである。

4CPU マシン(Hyper Threading 分を全部別のマシンとカウントしていい)上で、 独立系 Micro Kernel を実装した上でならば、 OS/2も悪くないかも知れない。 PM は駄目だが。

何とも言いがたい。

確かにこの本のテーマは 『プログラミング言語の概念と構造』 というその本のタイトル通り。 プログラミング言語についてその概念と構造について述べている。

それはいいんだけど…何と言うか…まとまりがない。 読み終わったときに、「で？」と言いたくなる。 別に「悪い」本ではありません。 単にまとまりがよくわからないだけで。 もしかしたら私が何か大事なことを見落としているのかも知れないし。

IT 化と言われて久しいが、 効率よくこれらを使っている日本企業にはとんとお目にかからない。
なーんでだ。
というのがこの本の大雑把な趣旨。

ポイントは3つ。

• ようするに、自分の業務形態をまずきちんと見直して、 IT 化することで効率が良くなるポイントはどこなのか調べ、 そこを IT 化するべき。
  とりあえず、既存のモデルを無理やり計算機の中に入れようとしても 意味はない。
• 「よく判らないから、最大の保障を」
  的に、ムダにハイスペックな要求をしない。
• レガシーシステムとの連携などムダ。

まぁ、ある意味正しい。 規模問題を解決できるならば。

残念ながら、規模がでかくなると、全体としての信頼性要求が上がる。 すると、徐々にこの本に書かれているモデル自体成立しなくなる。

ようするに、坂口さんは小さな会社の小さな問題を一杯解いた経験がある、 っていうことだな。

邦訳されている Unicode に関する資料のなかでは、 もっとも必要な情報が揃っている。

この本を読むと、いかに Unicode が「腐って」いるのか良くわかる。 Unicode は Glyph ではない、と言っておきながら 装飾記号のようなものが存在したり、 幾何学模様があったりする。 こんなものを導入する余裕はあっても、 Han Unification を行い漢字は統合するんだ、 などという問題点はまだ基本でしかない。

そもそも A と a は「アルファベット」においては「同じ文字」の 「別 Glyph」にすぎない、と言う事実を知っているだろうか? 大文字/小文字は正しくは upper case/lower case という。 これは「上段の活字箱に入っている活字」か 「下段の活字箱に入っている活字」か (たくさん利用する活字は下段に格納していた)、 という意味がそのまま転用された物で、 ようするに「違う活字箱に入った同じ文字」の事なのだ。 『Glyph の違いは同じ文字』と言うなら、A と a を unify するべきだろう。 逆に言えば、これを unify できない理由と同様に、 Han Unification もナンセンスである。

ISO 10646 がもう少し「強ければ」こんな馬鹿な文字コードもなく、 こんな馬鹿な unification もなかったのに、と 残念でならない。

この本は、Unicode がいかに腐っているのかを知り、 Unicode を推進している連中がいかに自己中かを知るうえで とても有効な資料である。 技術者たる者、是非、 この本を読んで、Unicode を廃絶に追い込むべく努力していただきたい。

計算機業界の内面暴露本は多い。 外から見るとそんなに「美しい」世界に見えるんだろうか…。 でも、実態はとんでもない。

この本もそんな本のひとつ。 http://www.amy.hi-ho.ne.jp/~lepton/program/ にある「闘わないプログラマ」の内容を元に作った本らしい。

基本的に笑える。というか、これで笑えないならプログラマじゃない (あ、泣き出しちゃう場合は除いて)。

FreeBSD や Linux であらかたの事ができてしまうので、 Windowsの問題は「ウィンドウズにするから」悪いんだよ、 と実に口語調で(256倍本と同じ調子で、とも言う) 書いてある本。 でもなんでもプログラマーズ叢書というご大層な名前のついているシリーズの第4弾。

内容は無いよう。
重量対コストはかなり悪いこのシリーズ。 しかし、娯楽としては楽しめます。

ちなみにこの本で一番役に立ったとも役立たずだったともいえるのは、 p.124の MrProject の画面を出しているページ。 このページを読んだのは、 適切なGanttグラフを書くツールが無くて四苦八苦した直後だけにショック倍増。

原題の通り、 これはオブジェクト指向モデリングの本である。 つまり、オブジェクト指向を使って、 問題をトップダウンに解析・分解していこうというお話だ。 当然そのようなアプローチには「表現方法」が必要になるので、 「オブジェクト図」というのが最初に出てくる。

悪くはないんだよね。

悪くはないんだけど、 こういう図とかそういうのって、 そんなに便利だと主張するならその図を書くだけでプログラムの 骨格部ぐらいは吐いてくれるような 環境ぐらい作ってみろよ、 と言いたくなってしまう。 それぐらい「都合の良い場合にしか使えない」表現方式ばかりなのが玉に傷。

逆に言うと、オブジェクト指向でモデリングをしようと言ったって、 そりゃ普通最終的にオブジェクト指向言語に落とす場合は、 その方が便利だろうし、 そうじゃない場合は問題に依存するだろう、 としか言いようがないのだが、私は。

ちなみに訳はあまりよくないです。 人数をかけて一気呵成に翻訳したらしくて、 文章に味もそっけもない。 内容も合わせると、読んでて眠くなる本だった。

基本的なデータ圧縮手法について解説された本。 良くできていますし、LossLess, Lossy な方法の両方について 説明されているのはよいのですが…。 残念ながら根本的な点が説明されておらず不十分。

データ圧縮で最も重要なのは、 実は「データ圧縮」は「データの圧縮方法」を定義しているのではなく、 「データの伸長方法」を定義しているだけだ、 という事実にある。

LossLess, Lossy 共、ビット列 Y から生成されるビット列 Z は基本的に 一意である。 むろん、ビット列 Y を通信などで投げる場合に Y が完全に転送できていない Y' でもそれなりのビット列 Z' が作れるのか、作れないのか、 という点はあろうが、 一旦 Y が完全に揃ってしまえば Z は一意決定するのが 「データ圧縮アルゴリズム」 と言う代物の特徴である。

大本のビット列 X からビット列 Y を生成する方法は、 実はどうでもよい。 ビット列 X からビット列 Y を経由してビット列 Z をつくる場合に、 X=Z が常になり立てば LossLess だし、 X≠Z が成立する場合があれば Lossy になる。

ので、実はビット列 Y が一意決定である必要はないのだ。 もちろん、一意決定になるようなアルゴリズムもあるし、 大抵のプログラムは一意決定になるように作ってあるが、 『そうでなくてはいけない』といういわれはどこにもない。 特に LZ77 や LZ78 などの圧縮方法は、 一意決定性が乏しいことで有名で…。

と言うわけで、一通り理解できたので、ま、いっか、というわけで放出。

日経BYTE には、昔の(米国の) BYTE 誌と連動していた連載があった。 "Computing at Chaos Manor" という連載で、 これは米国の BYTE 誌がつぶれた後も、日経BYTE では連載し続けていた。

著者は Jerry POURNELLE、ラリーニーブンなどと共著で、 SF作品を山盛りに書いている人だ。 この人、かなり前から自分の作品をパソコンで執筆しており、 その機能を使って共著などもこなしてきた。

彼はまた、 BYTE誌が COMDEX で Best of COMDEX Awards を選ぶ際の、 選考委員の一人としても有名である。 かなりのNurdなのだ。

この本は 1985年から 2004年までの連載の一部を、 本にまとめたものである。

内容は…うーん。Microsoft に関する感想が、 もうめまぐるしい勢いで変化する。 毎年毎年、こき下ろしたり、賛美したり…。 まぁ、新しい機能を見ている間は賛美したくなるだろうし、 バグに出会うたびにこき下ろしたくなるし、 Microsoft はこの両方が(まぁ、徐々に後者が前者を上回るんだが) とても頻繁に発生する会社だから、こういうことになっても自然なんだろう。

Palm/WorkPad 用のソフトを作るために必須の PalmOS に関する説明書。 3Com の SDK に付属しているドキュメントの日本語訳。 最新の OS 用のドキュメントの翻訳ではないが、 プログラムを書きたければ、 これの第1章は全部読んでからにするべきだろう。

ただ、このドキュメントもそうなのだが、 3Com のドキュメントは全般的に情報が不足している。 たとえば、malloc() のようなことをするとき、 size に 0 を与えると何が起きるか、 どこにも書いていない。 こういう「不足」が極めて大きいため、 「最後の瞬間」に Try & Error をせざるを得なくなる。

もうひとつ問題なのは、 これらのドキュメントが Mac ユーザー向きに書かれている、という点だ。 unix, DOS, Windows ユーザーは「リソース」という概念を知らない。 X11 のリソースは Mac のリソースとは全く違うもので、 これは正当(?)な Smalltalk と同じ、 「ユーザーが自由にカスタマイズするための」 ものとして成立しているが、 Mac の場合も Palm の場合もこれは成立していない。 Windows には本当はリソースはあるのだろうが、 SDK などが完全に隠してしまっているので、 どうなっているのかさっぱり判らない、 というかうっとうしいから制御させてくれと言っても制御用のソフトはない。

PalmOS はその意味で MacOS とそっくりなのだが、 そっくりすぎるらしくて、 リソースの何たるかを説明する必要性を感じないらしい。 PalmOS を作ったのが、元 Apple の社員である、 という点がこの状態に拍車をかけている。

結果として、リソースって何で、何が必須で、何は不要で、 そもそもなんでダイナミックな構造ではなく、 そげなものがあるのか、さっぱり判らない。 何が定義できるのかも判らないし、 どうやって目的物を検索するのかも判らないし、 どう管理されているのかも判らない。 当然、「嘘っこリソース」の作り方も判らないから、 ダイナミックなものを『まるでリソースのごとく』振る舞わせる方法も わからない。 わからないから、できないのかどうかも判らない。

だれか、そこら辺をもっときちんと1から説明してくれないだろうか…。

ソフトウェア開発やその利用・運用にはいくつもの規則が間違いなく存在する。 また、同様に迷信も存在する。

これはその中の真実55個と、迷信10個を選んで述べたものだ。

別に55とか10とかに意味はないらしい。 単に、オリジナルタイトルの最初の案が
Fifty-Five Frequently Forgotten Fundamental Facts and Few Fallacies abuot Software Engineering
というFで一杯のタイトルにしたかったかららしい。 その後で、Few Fallacies は Five + Five Fallacies になり、合計10個になったようだ。

この本に書かれている真実にも、嘘にも、大いに賛同するものが多い。 大いに賛同するとは、単にその通りだ、と思うだけではなく、 周囲を見ていて判っていない人が多いと思われる者が多く存在する、 という事だ。いくつか挙げてみよう(青字は私のコメント)。

真実13: 管理者とプログラマの間には大きな断絶がある

生産性において最も高いスコアを示したのは、全く見積もりをしなかった場合。 次に高いのはプログラマが見積もったもの。 最低のものは管理者が見積もったプロジェクトである。

真実19: プログラムを再利用する場合、流用母体の変更はバグの原因になる

20〜25%以上の変更が必要なら、根こそぎ作り直したほうが効率が上がり、品質も良い。

真実21: 対象となる問題の複雑度が25%増加するたびに、 ソフトウェアによる解法の複雑度は100%上昇する

これは改善しなければならない数字ではなく、 こうなるのが普通だ。

真実28: 最初に考え付いた設計方式が間違っている可能性は高く、 最適解ではない

これはソフトウェアの設計が複雑で反復が必要なプロセスだから。

真実34: デバッガはみんな使うが、カバレージ・アナライザはほとんど使わない

ツールを使わないと、不良除去は上手くいかないのに、だ。 もっとも安くて高性能なカバレージ・アナライザがないのも事実だと思う。

真実37: インスペクションを厳しく実施すると、90%ものバグを叩きだせる

プログラムをマシンで実行する前に、だ。

真実38: インスペクションはテストの代わりにはならない

特に、ランダムテストの代わりにならないと思う。

真実43: 保守は解法であり、問題ではない

なぜか問題だと勘違いして、どうにかして保守を減らそうとするようだが、 それは間違い。なぜなら保守はデバッグではないから。

真実45: 優れたソフトウェア・エンジニアリングに沿ってプログラムを開発すると、 保守は減らずかえって増える

真実48: 誰もが共通に作りこむ種類のバグが存在する

従って、同じ問題を n 個のグループに解決させても、 全てのグループが同じ間違いを犯している可能性は常にある。

真実49: バグは固まって存在する

大抵の場合、そこを書いたとき人は半分眠っていた。

真実52: プログラムの処理効率には、よいコーディングよりも、 良い設計が大きく影響する

ただし、よいコーディングはミクロレベルでの良い設計だと思う。 問題は、よい設計であるようなよいコーディングがどのようなものか、 多くの人は知らない、という事だろう。

嘘1: 計測できないものは管理できない

定量計測なんぞできなくても、 比較さえできれば制御はできるし、 制御できれば管理もできる。 その意味では、オリジナルの「計測できないものは制御できない」だって、 本当とはいえない。

嘘3: プログラミングからエゴを取り去ることはできるし取り去らなくてはならない

エゴを取り去る意味が無い。

嘘8: 多くの目にさらせば、バグは枯れる

100人寄っても馬鹿は馬鹿。 同じ間違いを犯し、レミングのように崖から飛び降りるだけである。

オブジェクト指向入門書。

チープな安物本かと思ったが、意外としっかりした良い本だった。

もちろん、入門書なのでそんなに難しいことが書いてあるわけではないが、 何が「オブジェクト指向」で何が「オブジェクト指向ではない」かがちゃんと書かれている。 その段階で十分評価に値する。

この本を読んだ段階で終わりにされると非常に困るのだが、 しかしたぶんこの本を先に読んでから C++ なりなんなりの本を読むと、 おそらく理解にかかる全日数が10日ぐらいは短縮できると思う。

というわけで、この本は初心者にはお勧め。

ただし、「別の本を捨ててこの本を選ぶ」のではなく、 「この本も読んで、他の本も読む」必要がある。

再帰構造 という点で共通している ゲーデル、エッシャー、バッハをテーマに、 徐々に徐々にゲーデルの不完全性定理を説明していく本。

700p強という一見簡単そうに見えるページ数だが、 実は ハードカバーでこのページ数 という事実の前に大抵の人は根負けする。 事実、この話の長さと展開性は 再帰構造 をきちんと理解していて、 不完全性定理 をぼんやりと理解しているぐらいでないと、 途中で飽きてしまう。

しかし、のんびりと、時間をかけて読んでいく分にはよい本である。 あ、あと「book end」としても使い勝手がいいぞ。

どう考えてもオリジナルの名前の方が良い。

内容は雑多すぎてかえってつまらなくなってしまった。

面白いと言えば面白い、 下らないと言えば下らない、 計算機科学に関連した雑学集。

実際問題として、この手の本の中では中の下。 提示の仕方が下手なのと、 それ以上に内容がつまらない。

非常に簡単に言えば、 値のハードコードされたプログラムや、 無意味にデータの値に依存した構造化されていないコーディングはやめよう、 という話。

ある程度は同意する。 まとめるべきものをバラバラに管理し、 あるいは設定値を仮定し、ハードコードたプログラムが多すぎる。

ただ、この話の後半部、 値から実行関数を決定するルーチンを lookup table にしよう、 という辺りは、 最近は恐くて実行できない。 heap overflow 攻撃はこういう lookup table を攻撃できて、 ここを書き換えられると executable 権限を一切持つこと無く プログラムの実行パターンを変更できてしまうのだ。 dynamic linking 機構が OS によってサポートされるともう少し 話は安心できる世界に行くのだろうが…。

というわけで、ある程度痛し痒しな側面があるので、 時と場合によってはやむをえない部分もある、 という事は認めつつも、 80% ぐらいの確率で、ここで書かれていることは全く持って正しい。

2ちゃんねるに、OSの事を欠片も判っていない人が、 OSを作りたい、とやってきたことからすべては始まった。 無謀なる登山、MicroKernel ベースのOSを造ると言うのだ。

というわけで、MONA です。

まだまだ品質をどうこうできるレベルにはありませんし、 機能自体「ここからまででは緞帳すら上がっていない」というレベルですが、 どこに行くのか判らない面白さがあるのは事実です。

separator が \ なのさえやめてくれれば。 実は私の中では期待度 No.1 なんですけどねぇ。

Windows ユーザ(それも比較的初心者)に、 Linux を紹介する、という本。 一応、同じトピックについて Windows と Linux を比較する、 という形式を取るはずなのだろうが、 そのフォーマットはきわめて早々に破れて、それっきり。

メインの内容的には目新しいことは何もない。
「UNIXはサーバ用OS」
「Windowsはクライアント用OS」
などの記述に至っては初心者用でなければ笑止なのだが (UNIXはサーバもへったくれもない頃からあるわい)、 まぁ、そこはおいておくとして。 それらの説明はUNIXじゃなくて unix だろう、 というのもおいておいて。

この本で役に立ったのは小さなTips群だ。 多くの場合、どこに書いてあったのかすらも忘れるような。 とりあえず、

前半でこの手の「思考ゲーム」と呼ばれるプログラムの 基本的な説明が、 後半に 強いことで有名な「森田のオセロ」 Version 6.1 のソースコードが載っている。 そう。実際に動くコードがあり、 しかもそれが強いことで有名な「森田のオセロ」のソースだ、 という点がこの本の最大の特徴だと言える。

この手の「思考ゲーム」は本当の意味での『思考』を行うわけではない。 この手のプログラムが実際に行うのは、 あり得る「次の手」(並びにそのさらに先の手のバリエーション)を検索し、 その各手について「評価」を行い、 最良の手を選ぶ、 という事だ。

「次の手」そのものは完全探索以外あり得ない。 また「評価」も結局は「そのさらに先の手」に対する評価を くっつけ逢わせた結果から成り立つ。 このような演算を与えられた時間以内に、 与えられたりソースだけを使って、 可能な限り行い、 最も「妥当」な結果を選ぶ事になる。 当然強いアルゴリズムというのは、

• 無駄な「手」に関する評価をとっととやめる事で、 他の「手」を評価するリソースを稼ぐ。
• これ以上先読みをする暇がない、となったときに 「適当な」評価値を与える。
• ゲーム固有の特徴点を探しだし、 そこを特別扱いする。

これらが序盤、中盤、終盤の３つについてそれぞれについて、 重点を変えながらデザインすることになる。 序盤というのは乱暴に言えば失敗しても回復可能な段階、 終盤というのは最後まで読みきれる段階、 中盤はこの中間ポイントになる。

このような構造の説明が終わると、 説明のほとんどは「無駄の手の排除」、 つまり mini-max 法とか α-β法 といった無駄の少ない探索法の説明、 定石と言われる手を使って主に序盤をのりきる方法、 などになる。

何よりも実例があるのが嬉しい。 実例があると理解が進む人間の場合、 この本は絶対参考になる。

Googleという名の巨大な検索エンジンと、 広告から得られる収入だけで莫大な利益を上げている会社。 この会社がどのように誕生し、 どのように利益を上げているのか、 多くのインタビューの結果を元に練り上げた、 おそらくもっとも Google の真実に近い一冊。

丁寧に読んでいくと、Google Engine がどのような構造になっているのか、 透けて見えてきます。

規模拡張速度や拡張性、 どのようなポイントは高速に変更できて、 どのようなポイントはなかなか変更できないのか、 という点は全て、 内部で動作しているプログラムをきれいに反映しています。 また、巨大な Google engine 群のフェイルオーバー速度の速さは、 多重度の高さと各ユニットの対称性の高さを表しています。

この本から判るのは、 Google が最初からとんでもない拡張性を前提に作られていたこと、 いかに無駄なHWを省くかを念頭にハードウェアをデザインしてきたかということ、 そしてそれら全体が相まって、強力な拡張性と、 コスト対効果の高さを生み出していることです。

ラリーとサーゲイの政治的な思惑や、 Microsoft に対する想いについては、 たいしたことは判りません。 所詮、「今、発表すると都合が良い」形でしかありませんから。

もし、技術者なら、あるいは新しい事業を考えている人なら、 この本は役に立つはずです。いや、 推測能力の低い人には、この本は役に立たないでしょう。

大企業へのコンピュータシステムの導入やそのリプレースには、 通常のPCの導入とはまた違った知識も必要とする。 ネットワークの全体の構造を考え、 負荷分散を見据え、 拡張性を確保し、 不明瞭極まりないお客様の要求を理解し、 少ない予算をやりくりし…

そもそも、この業界、宣伝文句と実態の乖離が酷すぎる。 また、その集金構造たるや土建屋と見まごうほどで…。

この本はそんなシステムインテグレーションの世界の内情を暴露した 月刊ウィンドウズ2000ワールドの連載をまとめたものである。 結構気軽に笑える話が載っている。

もちろん、少しの同情と、圧倒的な同意をもって…。

J2SE 5.0 Tiger は、 進化したというか変化したというか、 しすぎて言語的に過去と異なる記述方法をしなくてはいけないほど の大改造になった。

そんな J2SE5 の変化した部分を説明した本。

差分しか説明していないので、 元をちゃんと理解していないと、 変な具合に間違えそうな記述が幾つかあるが… まぁ、「簡単」という意味では、いい感じの本。

でも、Java はまだ変化が不充分。

Palm Device 並びに Palm 用 PC プログラム「コンジット」を 組むための基本情報が揃っている。

残念ながら、この本は「書いてない」事が多すぎる。 そしてその「書いてない」事は多くの場合、 本来あってしかるべき機能がない事 を書いていないのだ。

判りずらい? Palm には、本来あるはずのものがなく、 ないものは書いてない。 それだけではなく「存在しない」事も書いていない。 このため、 その機能が本当にないのか、 書いてないだけなのか、 素人には判らない。 ないと言うことに気が付いてショックを受けたときには、 プログラマーは締め切りを目の前に迎えている、と言うわけだ。

この本を読む人は、 何らかの理由で Palm 用のプログラムを書いている人だろう。 そのような人は、 この本に書いてない事で、常識にはあるはずのものは、 実はないのだ と思った方が良い。 基本的にその問題を解決するには、 OS をスキップしてハードウェアを直接操作するしかない。 そう思っていればあまり間違いはない。

書いてある内容に関しては、 おそらくこれよりも詳しく、 丁寧で、広範におさえてある本はないだろう。 コンパイラーからデバッグに至るまで、 必要なことは一通り書いてある。

最近は Versioning system といったら CVS らしい。 まぁ、RCS や SCCS じゃ能力不足やわね。 こじんてきには最近は SVN がお気に入りだが…。

というわけで買いました、リファレンス。 CVS の操作概念を覚えているけれど、 細かい操作方法を失念したときに便利。

ただし、man cvs とどっちが速い?と言われると…。 必要なページにしおりが挟んであるのでこの本の方かなぁ…。 あと、たまにマニュアルが古すぎて役に立たない(RHELとか)ので、 そういうときには便利。

Microsoft がJavaを自分勝手にいじって怒られたので、 .NET FrameworkというOSの新標準インタープリターと共に 世の中に放ったのが言語C#。 この本は、そのC#を網羅的に解説した本。

はっきりいって、MSILのできの悪さと、.NET Frameworkの無理難題と、 OSの腐れっぷりをどうにかするためにC#という言語側に やたらと環境依存で一般性のない、ややこしい機能が追加されている。 おかげで、頭の中にすっと入ってこない。 .NET Frameworkも、こりゃ先がないな。

比較的利便性が高く、互換性の高いシェルスクリプトを 書くための説明書のようなもの。

えー、説明の歯切れが悪いのは、 日本語のタイトルと英語のタイトルが全然異なっており、 内容は当然英語のタイトルに近いから。

"Classic Shell Scripting" とある通り、 この本は「sh でも動くプログラムの書き方」の本です。

しかし、その一方で ksh98 とか bash とか固有の命令についても説明しています。 はたまた trap 命令のようにシグナルを受けたときにどうする、 など sh の基本の動きについて説明していません。

一方で。shell はそれ自身の能力だけでは殆ど何も出来ません。 そのため、外部コマンドのはずなのに、du とか df とかの説明が 結構あったりします。 さすがに find レベルになると全部とは行きませんが…

このように「一体何をしたいんだ君は?!」というレベルの本なのです。

網羅性はない。 完全性も無い。 汎用性(sh だけでも使える機能に限定している)もない。

幅は広いんだけれどね。

多分、一番使える所は eval の説明の部分にある、 shell がどのようにコマンド行を展開していくか、 という説明図だと思います。 まぁ、これすら「どのシェルか」によっては大嘘だったりするわけですが、 それでも sh に関してはこれで殆どあっていたように思います。

GNU Make.

様々なプロジェクトで、 ソースコードから何か別の成果物を出力できる場合に、 ほぼ確実に便利に使える make というツールの GNU 版。

悪夢のような拡張と、BSD 非互換性のお陰で、 GNU Make 派と BSD Make 派が出来てしまうほど、 ある意味パワフルなツール。

その GNU Make に関する解説本。

読んでいくと判りますが、 GNU Make はかなり頭がくらくらします。 記述『可能性』はかなり強力ですが、 記述『自由性』はほとんどありません。 しかも記述のずいぶんと多くが「直感に反しています」。

著者は Cygwin 環境で主に GNU Make を使っているらしく、 Windows 環境で LaTeX を使う場合の便利マクロ集のようなものが載っているなど、 結構重宝するんだか、偏ってるんだか、よく判らない本です。

一度、読んでみるのは非常に良いと思います。 GNU Make の記述方法を理解する上で、 うろこが何枚も落ちるでしょう。 ただし、その結果、GNU Make が嫌いになるかもしれません。

MS-DOS のシステムコールと BIOS コールについて説明した本。

懐しいねぇ。標準ライブラリもなかった頃だ。 int 21h とか register の AH と AL に request 番号を設定するとか…。

邪悪(MS)が世界を支配する兆候でもあった。

昔はこれは必須だったのだが、もはや不要になった…。

ファイルのタイムスタンプと作業ルールから 最小限やる必要があることを調べあげてそれを順次こなす、 これが Make のお仕事である。

ということは、タイムスタンプを調べあげた場合に、 他のファイルの元になるファイルがあるということで、 こいつらをきちんとバックアップをとってやれば安全である。 また、バックアップをきちんと時系列で保存し、
「いつごろのちょうだいー」
と言ったらちゃんと出てきてくれれば万々歳だ。 こまめにバックアップを取りさえすれば、 多少のムチャをやっても元に戻せるんだから。 このバックアップをとってくれるソフトが RCSだ。

この本はようするに、Make と RCSの使い方をまとめた本。

ただ、どうにもこうにも帯に短し襷に長し。
make の本ならもう少し BSD make と GNU-make と nmake の違いとか、 いろいろ書くことがありそうなものだがそれが書いてない。 RCSは比較的まとまっているが、 それはどちらかというとRCSが版による癖が少ないからでしかない。
何よりもこの2つのプログラム、 入門以外の理由で１つにまとまっている理由ってのがない。

というわけで、今三だったので放出決定。

RHL のパッケージシステム rpm が使いにくくて使いにくくてたまらなかったので、 買ってみた本。 パッケージをインストールする方法が知りたかったのに、 man を見ても、この本を見ても、 パッケージの作り方が書いてあった…。

あまつさえ、良く判ったのは、 RPM はとても「馬鹿」だということだ。 それも、「下手な考え休むより悪し」なタイプ。 これなら、ない方がまし。

やはり、BSD の ports/packages システムの方が 統一性があって良い。 いや、Debian のシステムも良さそうだが…これは 十分調べていないので判らない。

Wnn6 と eWnn と dp/NOTE の公式ガイドブック。

まさに、そのもの。 Wnn の歴史から始まって、 基本的な動作から、emacs 上での使い方から…。 最新の Wnn は Wnn7 だけど、これでも十分使えるよ。 私はいい加減慣れたので不要になっただけだ。

来るべきコンピューターは「人間中心である」。

人工知能全盛の1960年頃からずーーっと言われてきたお題目である。 この本は、MIT Computer Science Lab の Dertouzos 教授が、 自然言語解析と超高速ネットワーク経由のユビキタスコンピューティング と自動スクリプティングと どこでも計算機インターフェース・なんでも計算機インターフェース さえ出来上がれば、人間中心主義になる、 と唱えている本。

軽く考えても、セキュリティを考えていない。 皆でデータを共有するって、 計算機本体の持ち主に sniffer を仕込まれたらアウトじゃない。

そもそも計算機がそんなにそこらじゅうにあって、 皆で共有している資産になるには、とんでもない重厚長大政府が必要だ。 道路だって税金でようやっと整備しているのだ。 インフラとしての計算機があり、そのすべてが信頼できるためには、 政府自身が自前の計算機を作り、OSを作り、それを全国民に強要し、 Cracking を一級犯罪として扱う必要がある。

というわけで、 あまりにも犯罪と言うものを無視した夢想世界。 絶対に来ません、こういう世界は。

HTML だの GIF だの Mpeg だのといった、 ようするに Internet で良く知られたファイルに関する説明書…なんだが、 あまり使えないことに、説明が不十分かつ不適切で、 内部構造までわからない。

内部構造が判らないならいっそ利用目的だけ書いてくれればいいものを、 それでは済んでいない。 中途半端とはまさにこのこと。

と言うわけで、却下だこれは。 Internet を直接サーチして、きちんと解説ページを読んだ方が よほどちゃんとしたことが判る。

X 上で Wnn と Mule と WebBrouser を使って、 マルチリンガル環境を…という本。 とは言っても、マルチリンガルとは「日本語と韓国語と中国語」程度であるが。

まず、マルチリンガルのための基本的な文字コードのお勉強を軽く。 ついで Wnn6 の話になる(kWnn とか cWnn の話にもなる)、 で、それらの Input Method を使って、 Mule で入力して、そうやって作った html ファイルを Web Brouser で表示、というそういう話。

昔は役に立ったのですが、 Mule は今や Emacs20シリーズ以降不要になり、 Wnn は標準的に使うので判るようになり、 Web Brouser はマルチリンガル当たり前なのできにする必要もなく… X のフォントは何も考えずに全言語投入できるぐらい disk space があるので、もはや全く使わなくなった本です。

物凄く簡単に言えば、 Macintosh 上のプログラミング言語である Object Pascal についての 説明(上巻)と、 Smalltalk ならびに各種 toolkit が提示しているインターフェースの オブジェクト指向ぶりを「どうだえらいだろう」と紹介している本。

全体的に良くできていると思う。 若干図表が「低解像度」なのが気になるが、 まぁ、当時の Mac でプリントアウトすればこの程度だろうし。

一番の惜しむらくは、私が Mac を持っていないという点だな。 『Object-Oriented Programming』までは読んでいたのだが、 『for the Macintosh』という文面を読まずに買ってしまったのだ。 失敗失敗。

「絶対サポセン黙示録」 <URL: http://www.din.or.jp/~f-aniki/sc/index.htm> の厳選抜粋本らしい。

内容的には「プロッピーをコピーしてと言われたら XEROX した」等と同じ、 サポートもの。 さすがに上記のネタはないが、 人類は全く進化していないことを確信させてくれる程度には 同じレベルの爆笑ネタ満載。

9割の爆笑率と、1割の「こういう他人の褌本って本当はいいのかなぁ…」 という思いを抱えつつ、「面白いのでありありあり〜」。

ISP があり、dialup があり、firewall があり…と Internet の世界はどんどんややこしくなっていく。 ここにさらに Security だの何だのと言うのが出てきたり、 POP, IMAP などの新規サービスが入ってくると、 e-mail に関する環境も sendmail だけ、 というわけにはいかなくなってくる。

と言うわけで、qmail 関係の本があったので読んでみました。 qmail は MTA と言われるもので、 あなたが出したメールを送信したり、中継したり、 あるいは受け取って適当なスプールに貯めてくれたり (この中には POP Server に転送するなども含まれる)します。

結論から言うと、この本ではあまり役に立ちません。 Reference Manual ほどの詳細さもなく、 Users Manual としての「イロハからの説明」もない。 procmail とか ML マネージャの話にページを割くよりも他に 説明するべきものがあるだろう?と言いたい。

基本的にここに書かれている内容は重要なことばかり。 アルゴリズムとかも大事だがそれ以上に、 「デザイン」というものの重要性を説得力高く述べている。

私に必要なわけではないが(もう読んじゃったし)、 プログラマーには必読書ではあろう。 プログラムとはこうやって作るものだ。 いきなり端末の前に座ってコードを組むもんじゃない。

ソフトウェアパターンの中でも、 メモリ利用パターンに焦点を当てた本。

計算機上でプログラムを組む場合、 デザインのほとんど最初の段階から始まって最後の瞬間まで念頭に置き続けなくてはいけないのが、 メモリ管理の問題だ。

メモリを不適切に管理すればメモリリークは起こる。 じゃぁGarbage Collectionのように自動回収機構を使うと、 今度はGCがいつ発生するかわからない。いつまでかかるかもわからない。 それではCPUがどう消費されるかわからないのでリアルタイム性を必要とするものに利用できない。

ちょっとデータ構造デザインの際に無配慮なまま放置した部分があると、 無駄に大量にメモリを消費する。 でもそのメモリ消費にだけ眼をやると逆に拡張性がなくなってしまったりする。

場合によっては絶対に止められないプログラムと言うのもある。 メモリ不足で止めるわけに行かないとなると、 事前に必要な絶対量を確保するという手が考えられるが、 その方法だと一歩間違えるとメモリ中が事前確保領域だらけで、 普段のサービスに支障が出たりする。

この本では、プログラムに突きつけられている要件・要求を force と呼んでいる。 で、どの force を満たすにはどのようなソフトウェアパターンが使えて、 その代わりどのような問題(新たなる force の元になりうるもの)が発生するのか、 を丁寧に分類・説明している。

ソフトウェアパターンという分類法が良いかどうかはともかくとして、 この本に書かれている内容の優れている点はその網羅性の高さにある。 あるポイントにおけるいくつかの要件軸のそれぞれの方向について 解決法を示しているため、 いつそのパターンを使うべきか、が明確になっている。 従来のアルゴリズム本はいつ使うべきかは実はあまり明確ではなかったし、 どのアルゴリズムとどのアルゴリズムが force という観点から見て ちょうど逆向きのベクトルに当たるのか、が良く見えなかった。

この本はプログラムをデザインする人全員に読んで欲しい。 一応、ここに説明されているソフトウェアパターンの一覧を付けておく(目次をコピーしただけだが)。

あと、調査したほうが良いと思われる参考文献は次の通り。

RFC の中には joke RFC と言われる類いのものがある。 大半は日付が4月1日で、 内容は荒唐無稽なものからかなりセンスがないと何が面白いのか判らない上に、 下手すると本当に使えちゃうんじゃないか、 というものまで様々である。

この本はそのような joke RFC を翻訳し、 ランク付けして本にまとめたものだ…が。 はっきり言って翻訳にセンスがない。 内容のランク付けにもセンスがない。 駄目じゃん。

たとえば RFC 2550 Y10k and Beyond なんて、 実に素晴らしいではありませぬか。 私はこれを読んだ瞬間抱腹絶倒して、 Y2k 問題は絶対これで解いてしまうべきだと思ったもの。

掲載されている RFC は、

三ツ星

1149, 1882, 2322, 2324, 2549

二ツ星

748, 968, 1217, 1605, 1925, 2321, 2323, 2795

一ツ星

527, 1121, 1300, 1437, 1438, 1439, 1606, 1607, 1776, 1924, 2325, 3091

無星

1025, 1097, 1216, 1313, 1926, 1927, 2100, 2550, 2551, 3092, 3093

その通りで、この本はRISC CPUを用いたWorkStationが普及し始めた頃に、 どうすれば効率よく動作するプログラムを書くことができるのか、 従来のCISC計算機とRISC計算機やベクトル計算機はどこが違うのか、 どこで何に頼るべきなのか、 などを中心に纏め上げられている。

この本の優れている所は、 Risc CPU, Compiler などがその当時最適化するためにどのような技術が 用いられていたのか、pipe line や register renamingはもちろん、 コンパイラの使う最適化がどのように最適化可能な部分を見つけ出すのか、 どのような時に「人間には明確でも機械には不明瞭な最適化部分」が 発生するのか、 などを説明している点にある。

並列計算機などの話も出ているが、 これらは残念ながらこれ以降の研究が進んで最近の技術とは微妙にずれている。 基本を押さえるという意味で読むべきだろう。

この本はプログラマに読んで欲しい。
CPU が中でどのようなことをやっているのかを理解し、 Cache ヒット率などを考慮したプログラムやアルゴリズム選定を行わないと、 定数レベルで動作性能が数倍違ってしまう。
また、コンパイラがどのような最適化を、 どのように判断しながら行っているのかを理解すると、 無駄にややこしい記述をするのが間違いだ、と気がつくはずだ。
無理やり構造体へのポインタをbyte列へのポインタに置き換えてそれを送受信する、 などというコードはコンパイラにとって最適化を阻害する要因にさえなる、 という事が判れば、 もっと判りやすいコーディングを心がけるだろう。 それはそのまま人間にも優しいコーディングにつながるはずだ。

コンパイラを買う際の予算を割り振る人にも読んで欲しいな。 マネージャとか。
そういう人は、高性能コンパイラはこれだけのことをするのだという事、 だから「ちゃんとしたコードであれば」相応に性能が変わるのだ、 だから高性能コンパイラは製品開発において必須のものなのだ、 という事が理解できていなくてはいけない。
実際、某会社の古い製品には、 コンパイラを新型に変えたら性能がべらぼうに向上したので バージョン番号を1つ上げて売り出した、 などという過去があったりするぐらいだ。 開発ツールの中でもコンパイラはなめてはいけない。

この本は第2版が英語では出ている。日本語では出ていない。 そして英語版の2版も、日本語版も、 絶版になっている(2003年12月現在)。

そろそろ新しい版が出て欲しい1冊である。 絶対お勧め。 少なくとも10年経っても色あせていない。

副題は『OCNを使ったSOHO環境の実現』。

オライリジャパンの編集者の能力が、 オライリ本社のそれに比べていかに低レベルかを露呈した一冊。

ある一群の人間が独立して会社を作る話にかこつけて、 自前のネットワーク環境を FreeBSD で作るぞ、 外との接続は OCN だぞというお話なのだが、 そもそもオライリ本の良い所は、
「そういう余計な話はなくして、 技術的詳細に徹する」
点なので、 こういうオーム社的な本はオーム社ブランドで出して欲しいと 思うことしきり。 しかも、OCN とか、全部時事ネタだし。

少なくとも、オーム社ブランドで出してもらえれば、 本の大きさが一回り小さくなったと思うんだ、 もう少し厚くなったかも知れないが。 その方が絶対使いでが良かった。 オライリの本の形は卓上設置に向いているのであって、 こういう一過性の内容には向かない。 この手の内容の本はどこへでも持ち回して、 一気呵成に読みきってしまってはじめて価値がでるのだから。

そういう点を全く考慮していないという意味において、 この本は駄目駄目。

ちなみに FreeBSD のバージョンは 2.2.5 なので、 2002年7月現在、BIND のバグのせいでどのみち使いものになりません。

「vi は使いづらい」
「emacs は判らない」
「perl って難しい」
「awk, sed なんて何がいいの?」
という人は多い。 そういう人に話を聞くと、 突っ掛かっているところはほぼ1個所。 それが正規表現だ。

実際、正規表現はとてもややこしい。 そのややこしさは、 正規表現が表現できる事柄の本質的な複雑さから来ている。 つまりそもそもがややこしいことを全部表現しろと言われたら、 ややこしくならざるを得ないのだ。

どんなにややこしいものでも、 基本規則を覚えてしまって、 慣れてしまえば便利なツールであるのと同様、 正規表現も良い教科書があり、 便利な正規表現利用ツールがあれば、 あとは3日も使っていればこれなしではいられなくなる。

この本は正規表現の良い教科書として、 とりあえず日本語で読める最良のものだと言える。 記述ルールはもちろん、 どのように実行されるのかも、どのように処理されているのかも、 全て書かれている。

make の入門書のようなもの。

make は様々な方言によって微妙に動作が異なるが、 そういう微妙な所はつつかず、 あくまでも共通して動く所を中心に説明してある。

このため、この本に書いてある事だけを使って Makefile を実装できると、 いろいろな環境で使える Makefile になることが多い。

ただし、実際問題としては、 ちょっとでもややこしいことをしようとすると すぐ方言のお世話になるか、automake 等のお世話になる羽目に陥るので、 痛し痒し、と言った所。

手元に一冊あると便利です。

コンピュータ用語辞典版悪魔の辞典。

笑えるが…その笑いに一抹の不安が過るのはなぜ…。

人工知能の中でも Knowledge Base といわれる類いのものに関する教科書。 厳密には、2000年以降、これらは「人工知能」とは呼ばれていない。

大学の教科書。 当麻先生の授業で使った。

ブール代数など、 デジタルスイッチング回路を理解するのに必要な 基本知識が載っている。

2011年2月16日。

"Jeopardy!" というクイズ番組の特別編として、 過去のチャンピオン二人と、IBM特性の Jeopardy! マシン "Watson" が対決、 人間を圧倒して "Watson" はクイズ王になった。

自然言語を分析し、 キーとなる単語を拾い上げ、 それらの関連性のうち「何に注目して」「どのように範囲を狭めていけと問題は指摘しているのか」を理解し、 出てきた候補の中でどれが最も正しそうなのかを評価する。 自信が無いならボタンを押さない、自信があるならボタンを押す。 これ全体を 4秒弱の時間の中で処理する。

もし正解できたなら、次の問題が書いてあるパネルを選ぶ権利が与えられる。 どこを選ぶべきか? 幾つかの場所には、特別ボーナスが眠っている。どうやればそれを効率よく探し出せるか?

これらを300台弱の本体、2000台強のプロセッサコアを持つ Power7 によって 並列処理するように作られたスーパーマシン、それが "Watson" だ。

この本は、2006年からの4年強の間、IBMの研究者がどのように苦労してきたかを、 主に David Ferrucci の煩悶に焦点を当てて描いている。

技術的な内容はほとんどない。 どちらかというと Jeopardy! がどのようなクイズか、 何がそんなに面倒なのか、人間のスコアはどうなっているのか、 そしてワトソンのプロトタイプ達のスコアがどのような状況にあったか、 が描かれている。当然、これに煩悶するのはリーダーである Ferrucci ということになる。

ある意味、ワトソン研究所とその他の研究所の予算の差がいかに馬鹿でかいかが描かれている本、とも言える。 IBMは当時、世界中に8つの基礎研究所を持っていた(2010年にブラジルに基礎研究所ができて9つになった)。 しかし、こういう乱暴な(市場ニーズの調査を行わずに力技で開発が行われ、結果については大博打な) 研究はワトソン研究所以外では一切行われていない。 研究の後期になって人頭が必要になってから、他の基礎研究所から研究員を引っ張ってくることはあっても、 他の研究所がこれだけの大博打な研究を行うことは許されたことがないのだ。

ある意味、究極の力押しでもある "Watson" は、力押しだけでエキスパートシステムとしてかなりのことができる… 少なくとも人間なんかよりはよほど「物知り」として活躍できる… 事を示した。

最後の方の章で、研究者たちが
「さーて、こいつをどうやって商品に仕立てたら良いものやら…」
と苦悩しているシーンは笑えるものがある。 気持ちは判るぞ。

「古典的著名プログラマーにインタービューしたものをまとめました」本。

古典的すぎて、今の人には「それ誰?」な人のほうが多そうだ、というのが玉に瑕。 さらに、「その人よりもっと別の人がいるだろう?」的な人も… まぁ、人選は趣味だと思います。

面白いのは、その人がやっているジャンルによって、言っていることが 180度違うこと。

「Cは酷い、最低最悪の失敗だ」と言う人もいれば「Cのおかげで救われた」と言う人もいる。 「プログラマーに数学は必要だ」と言う人もいれば「プログラマーに数学は必要ない」 という人もいる。 その割には「数学じゃない」はずの数論的な発想は理解できて当然だったりするが… (たぶん「数学は必要ない」と言っている人は、自分が「数学を使っている」ことを 理解できていないんじゃ…)

また、プログラミングを教えている人とプログラムを作っている人での差、 どのようなプログラムを作っているのか、などで主張がぶつかっているのが面白かった。

インタビューの内容はどちらかというとダラダラとしていて、 一貫性のある質問の形はとっていないので、 時々冗長すぎたり、 インタビュアーの主張と合致していると比較的軽くスルーしてたり、 逆に合うからこそ長々と「そうよねー」話を展開したりと… まぁ、こんなもんだろう。

掲載されているのは次の15人。インタビューそのものの中に書いてあった インタビューを受けた人お薦めの文献も併せて記載する。 なお、私がすでに読んでいる場合は書評へのリンクを、 そうでなければAmazonへのリンクか、オンラインでコピーが得られるページへのリンクを張っておく。

「Appleを作り上げた二人の Steve の内(太っている方|重たい方|有名じゃない方|技術者としてモンスターな方|Apple I, Apple II を設計した方)」 と、さまざまな呼ばれ方をし、The Wizard of Wozとして有名な、 Steve Wozniak の自伝。

特に最初の方、少年時代から HP で働いていたあたりまでの話に共感したり、 「僕もやってみよう」と思わないようでは、 技術者の素養はありません。

M-Code 422021。

High Availability (HA) システムを運用するために基本的に考慮するべきポイントと、 はてな、ならびに KLab/DSAS での実装例の概要を、 実際にはてなやDSASを管理している人たちが説明した一冊。

日本語でHAについて説明している本自体が少ないので、 情報源として希少ではありますが… なんかまとめ方が論理的ではありません。

HAの理論的側面を十分追いかけているわけでもなく。

HAを実装しているオープンソースソフトウェアの使い方についても 網羅的なわけでもなく。

適切なパラメータを求めるための方法が 書かれているわけでもなく…

2008年9月の日付において、 彼らが使っているシステム設定の一部やスクリプトが少し載っているだけ。

そもそも珍しいジャンルに関する本なので、 一過性の情報源としての価値は高いです。 しかし、書籍としての有用性を考えると… 理論を十分追って欲しかった、と。

これは残念賞ですね。

主に、サーバ上で動く Webベースの アプリケーション を開発する場合の アーキテクチャモデルに付いて、 さらーーっと表面を撫でた本。

個人的には、あまりにも薄く浅く過ぎて、 結局著者は何が言いたかったのか、が判らない。

というか、「本を書かないか」と言われて嬉々として書き出したものの、 ターゲットとする読者のレベルを低くしすぎていた事に、 後半になってから気が付いたときには後の祭り。 本の厚みをおもいっきり厚くするか、 読者レベルを上げて1から書き直すか、 という選択を迫られたときに、
「いいや、締切りも迫ってるし、本業も忙しいし、適当にお茶を濁しちゃえ」
と投げたようにすら見える…

なので、読んでいて非常に面白いのだが、非常に面白いで終わる本。

この本で紹介されている手法に関する本や論文 (もちろん、参考文献として載っている) を読む、そのための入り口として使うべき本だと捉えると良い。 この本一冊でサクっと物事が判るようになります的な本では、 全くない。

M-code 430231。

「懐かしの inside Family Computer」 とでも言えばいいのだろうか… ファミコンの内部構造やら 6502 のすっごく基本的なコーディングテクニックやらを つまみ食いしたような本。

明らかにアセンブラとかスプライトとかそう言うのを理解していて、 昔ファミコンでゲームを作りたいなぁと思っていたような人たち… The BASIC とかの読者を想定している本。

どこをどうひっくり返しても、
「今のゲーマーは、昔のファミコンに学ぶべきだ」
的な内容はございません(いや、そう言い張ってる文章はアチラコチラにあるけれど)。

ファミコンに限らず、Belady の例外 を考慮せずに 手放しで「創意工夫の勝利」とか言うのは論外。

なのでこの本を「過去の技術に関する説明書」として読む分には構わないが、 提言書として読んではいけない。 それは、「売れたときにドツボにハマる」技術製品としてあなたを苦しめるだろう。

最後に。「プログラミングの功罪」という章が立っていて、 オブジェクト指向とGarbage Collectionを叩きたがっているようだが… 生憎、全然的はずれである事を書いておこう。

「オブジェクト指向」において文句を云っているのは「オーバーヘッド」。 うん、オブジェクト指向言語は確かにオーバーヘッドが大きい。
「だから駄目だ」
バカですか?

一般的なオブジェクト指向言語の実装を、 そんまんま使おうとするとオーバーヘッドが大きいコードになります。 ここまでは正しい。でも「理由」がある。

それはオブジェクト指向言語は、結局の所 link が完了するまで unknown なファクターが大量にある のに、 dynamic linkingという実行するたびにリンクし直すモデルで実行している からだ。 つまり、.dll でも .so でもいいんだが、 ある時の実行時に使う .dll のバージョンと、 次に実行するときに使う .dll のバージョンが同じである保証がない、 というのが問題。同じである保証がないから、 違っても動くコード しか準備できない。

ゲームは一般論として、これが成立しない。 特にファミコンのようなゲーム専用機はこれが全く成立しない。 すべて static link で済ませることができる。 ということは .obj ファイルなり .o ファイルなりではなく、 static link で全部をくっつける段階でもう一息、 最適化がかけられるはずだ。

たとえば、Class のコードは「あとで継承されるかもしれない」 という前提でコードが作られる。 でも、final …これ以上継承しません…というキーワードをかけまくった あとのコードなら、そんな前提はないから、もっと派手な最適化がかかる。

でも、それ、やってないだろう?

コンパイラに、そこら辺の dynamic linking 環境で動かすための バイナリを作るのが専門の一般的なコンパイラを持って来ておいて、 static linking でしかかけられないような最適化が 掛からないと言って文句をいうのはおかど違い過ぎる。

ちゃんと static linking 環境でしか動かせないような プログラミングテクニックを駆使しまくったソースを食わせて 見ればいいんだ。

いまどきのコンパイラは、ちゃんと条件を整えてやれば、 素晴らしいコードを吐くから。

Garbage Collection はCPUに負担をかける…あー、それはその通りだが、さほどでもない。

Garbage Collection はCPUに負担をかけるんじゃない。 メモリとキャッシュシステムに負担をかけるんだ。 そしてその最大の理由は 汎用のGarbage Collectorを使っているから。

ゲームでは扱うデータの種類や大きさが決まっていることがほとんどです。 (中略) プログラムを工夫すればメモリ領域の確保と開放を繰り返す必要はありません。

んー、微妙だね。

Cluster Allocation とか 階層型 Allocator というものと、 Garbage Collector を使うといい。

たとえば、敵が弾幕を張るために弾丸を打ちまくったとする。 だから一見ちまちました弾丸の数だけ オブジェクトを作らなくちゃいけなかったりする。 でも、だからといって弾丸の数だけ malloc/free したりはしないよね。 弾丸1000発単位でメモリをがっと確保して、オブジェクトを作って、 使って…でも 1000発全部の弾丸が画面の外に出たら(つまりもう二度と使わないなら)、 1000発分全部一気に回収するよね。

この大きな塊でメモリを確保し、 全部が不要になったことを確認したら、 大きな塊単位で回収するという構造を階層型 Allocation という。

GC はこの「大きな塊」の事を知っている。 で、「塊の中身」がまだ使われているかどうかを追い回す。 で結果として判別するのは「塊が」まだ使われているかどうか。 使われていれば、GCはしない。使われていなければGCする。 この「大きな塊」の中から再びちまちまと reallocation はしない。 これを Cluster Allocation と言う。

明示的に「使っているかどうか」を示すビットを用意してやれば… まぁそれはようするに 1bit の reference counter のようなものなんだけれど… GCのお仕事は大幅に楽になる。 reference counter が「使ってない」といっているものは使っていない。 残っている奴で使っていないものは reference counter を 0 に落とす。

でも、プログラム側も Cluster 単位でポインターを管理するので、 Cluster 自体が参照されていなければ全部まとめて捨てられる。 そういう多段階層型の GC をセットで使えば、 ゲーム用のGCというのはまだまだ開発の余地はある。

じゃぁ、今のゲームプログラムでそれをやらないのはなぜかというと、 それはGCが悪いんじゃなく、汎用環境上で動くゲームをつくろうとしているからだ。

携帯電話上で動くようにしたり、 汎用環境で動くことを前提にしたり、 あと動作環境を新規に作り直すのが大変だから、 速度要求の低い部分は既存のシステムを手直しせずに使って コストダウンを図るとか… そのように「汎用環境上で動くゲーム」が目的だから、 GC が存在する環境でプログラミングをすることになる、というだけの話。

GCが悪いわけではないし、悪い使い方をしているのはGCのせいではない。

と、このように。
非常に懐古趣味的で、その割にちゃんと判っていないな、という側面が あまりにも多い本ですが。 やはり「懐古趣味的なものが読みたい」時にはなかなか良い本です。

M-code 431121。

最近のプロセッサはもうアチラコチラに工夫がされていて、 ノイマンアーキテクチャベースの物の考え方では 何がどうなっているのか全然わからない。

で、それを放置してソフトウェアを書いていると、 直感に反するパフォーマンスの劣化に直面したりする。 なので時々、 CPUやチップセットなどについて、 どのような機能があって、 どのように実装されていて、 どの辺に気を付けなくてはいけないのか 勉強しないと、 良いコードは書けない。

この本は丁度、Core i7辺りのIntel CPUについて、 ソフトウェアに関連のあるポイントだけに絞って、 しかも実はかなり概念的な説明の仕方で、 最近のプロセッサはどうなっているのか、 説明しています。

各技術の説明は「それが何故必要か」という技術的依存性を含めて書かれており、 非常に分かりやすい。 というか、これぐらい分からない奴はプログラム組んじゃ駄目だ。

ソフトウェアに関連するという理由で、 GPGPUについてもある程度書かれています。 が…うーん、ちょっと分量の事を気にして切り捨てすぎている気が…。 個人的には「もう少し詳しくっ」という感じ。

というわけで、この本は特にソフト屋さんにお薦めしたい一冊。

C ならびに C++ を使った場合の、 よくあるバッドパターンを説明し、 その対策を述べた本。

残念ながら80%ぐらいしかないようには同意できなかった。

最も同意できなかったのは、 作者が 長大な switch 文や if/else 文を否定している点。 確かに条件分岐後の処理記述が長大な場合は良くないと思うが、 分岐条件が大量にあるために起こる switch 文の長大化はむしろ歓迎するべきだと思う。 それを関数ポインターで隠すのは必ずしも良いことではない。

もちろん、method もどきを実装する場合に switch 文で記述するのは よろしくない。 しかし、一般に関数へのポインターはプログラムの静的追跡を困難にし、 実行しながら追跡するしか手が無い、という状態になる。 お客様環境での障害を再現できるぐらい大量のリソースが与えられている サポート・デバッグ部隊はまれだ、という事を考慮すると、 関数へのポインタを使うよりも、switch 文による記述を行って 静的追跡性を追求するほうがはるかによい。

他にも数箇所?と思わざるを得ない所があったが、 全体的には非常に参考になる内容が書いてある。 初心者にはお勧めだ。

Amazon のサービスに Amazon Web Service というものがある。 Amazon が使っているサーバ群を用いてクラウドコンピューティングサービスをするぜ、 というものだ。 こいつの上で実装されたサービスとしては SecondLife とかが有名だ。

その中でも Elastic COmpute Cloud (EC2) と Simple Storage Service (S3) に 焦点を合わせて説明した本…だと思ったのだが、うっかりしていた。 秀和システムクオリティって奴の存在を失念していた。

これは入門以前。 そのようなサービスがありますよぉというご紹介。 その段階で終わっている…。

じゃぁ、EC2 と S3 はそれぞれどのようなサービスかと言うと。

EC2 はようするにVMWare の仮想マシン貸します。 何種類かのインストールイメージと、 何種類かのCPUやバス幅占有率の中から自分が欲しいイメージを使って、 VMWare による仮想マシンを立てろ、と。 で、稼働率とデータIO量(主にネットワーク)に応じて従量課金するぞ、というもの。 不人気なサイトを作っちゃった場合、最初の内は非常にコストパフォーマンスが良い。

仮想マシンなので当たり前だが仮想マシンを終了させれば全部消える。 reboot は「終了」させるのとは意味が違うので、 こちらでは消えないが shutdown -h は致命傷になる。

さて。仮想マシンを立てるとサービスデータをどこに保存すりゃいいのか、 という問題が出る。仮想マシンのイメージを保存して、 必要に応じてマシンを必要な台数だけコピーして立ち上げてやるのが 負荷が上がってきたときの対処なのだが、そもそも 仮想マシンのイメージを仮想マシン上に持つには仮想マシンを止めなくちゃいけない という自己矛盾に陥る。 そこでS3。

S3 はようするに仮想ディスク貸そうサービス。 仮想マシンのイメージだの、仮想マシンで行っているサービスデータだのを バックアップしたりするためのディスクを仮想的に貸しますよ、というもの。 仮想マシンなどの寿命と独立してストレージを定義できるので、 仮想マシンをパワーアップしたモデルにしたいとか、 OSをバージョンアップしたいとか言うときには必須のサービスだ。

この2つはどちらも本当のサーバ、本当のストレージを購入した場合ほどの性能は出ないが、 スタートアップとしては十分な性能のを提供してくれる。

ということまでを述べた本。

莫大な数の計算機を使ってサービスを行う世界… 特に Google をのような巨大なクラウドの世界では、 データセンター内のマシンがロバストであることを前提にできない。 つまり、データセンター内部ではマシンがバタバタ壊れ、 それを Standby に切り替えたり、人間が修理したりしている。 しかし、 データセンター全体としては安定したサービスを提供する必要がある。

ここにデータセンター全体を1つの計算機とみなす… Warehouse Scale Computer(WSC) という考え方が出てくる。

WSCにおいては、 エネルギー効率も、 障害パーツ対応も、データセンター単位になる。

たとえば、データセンターにおいては UPS の効率の問題や、 冷却施設の関係で、計算機が全く演算を行っていない場合でも、 データセンター全体としてのエネルギー消費量は0にならない。

つまり、データセンターというのは「計算能力に対して100%で運用されているとき」 が最もエネルギー効率が良いことになる。

しかし、100%負荷運用なんてしたら、ちょっとした負荷のゆらぎで、 データセンター全体がダウンしてしまう。 ということは、低負荷時のエネルギー効率を上げる必要がある、ということだ。

実際、今のGoogleの場合、大雑把に30%ぐらいの負荷が時間軸的に見て最も多いらしい。

一方で ソフトウェアはデータセンター内部での障害に対しては ロバストである事が求められる。 従来のソフトウェアのように、
「計算機単体が壊れたら、ソフトウェアも動けなくなって構わない」
とはならない。 適切に roll back して計算をやり直す必要があるし、

データもバックアップ・レプリケーションから復活させる必要がある。 それも一次対処は自動的に行われる必要がある。 データセンターのサービスノードから切り離された後であれば、 人間が関与してそのデバイス部分を治すなり、捨てて代わりのものを入れるなり、 諦めて縮退させるなり、できる。 しかし第一歩としては自動的に障害を検知し、 切り離さなくてはいけない。

というわけで、結構面白そうな話ではあるのだが。 全く同時に… ん〜…で? という感想しか持てない。

ようするに Google 自身はこうやって対策していますよ、 的な情報が既知の情報から1bitも増えていないので、 呆れ返るぐらいに具体性に欠けるのだ。 こう…なんというか…
「書けないんですよ。察してくださいよ」
の嵐。

具体的な対策がまるっきり書けないなら、そもそも本を書くなっ

と思わず言ってしまいます。

データ・ゼネラル社初の32bitミニコン MV/8000、 開発コード「イーグル」の開発部隊を密着取材、 書き上げたノンフィクション。

ある意味、かっこいい。 地獄だけどね。

ソフトウェア専門コンサルティング会社である ThoughtWorks 社が出したペーパーをまとめた一冊。

全編を通じて特徴的なのは、
「オブジェクト指向って使えるよね?! アジャイル開発ってすごいよね?!
だからこの発想はソフトウェア開発だけじゃなくて、 あらゆる場面に応用するべきだと思うんだ」
という…こう…何というか…中坊的短慮主義。

アジャイル開発は特に長期運用を考慮しない、 非常に危険な戦略なので、 そんなものを経営とかに持ち込まれると迷惑なんですが…。

というわけで、これは玉石混交。 テストなどのソフトウェア開発の後半に比較的近いジャンルにおいては まだ見るべきものがあるが、 ソフトウェアデザインとかの段階ではもう腐敗臭が…

アジャイル開発と Java にかなり偏った説明になっているが、 基本的には初心者を卒業した辺りのプログラマが、 上級プログラマになるために必要な考え方の転換を教えている本。

本質的なことを言えば、プログラム開発と言うのは「アジャイル開発」か「計画開発」か、 と言うような単純なものではない。

計画開発型のプロジェクトにおいては、 上級プログラマがデザインをし、問題を分割して部下のプログラマに役割を割り振る。 しかし結局一番コアな部分は上級プログラマ自身がコーディングするしかない。

その一方で、上級プログラマは部下のプログラマが出してくる コードの品質を管理・チェックするために、 彼らが躓いているポイントなどを時々確認してあげなくてはいけないし、 適宜アドバイスを与えなくてはいけない。

と言うことは、上級プログラマ自身は一番重要なポイントをコーディングするのに、 部下のプログラマの何分の一かの時間しか与えられていない、と言うことだ。

上級プログラマはこの少ないリソースをやりくりするために、 機械が作れる部分は機械に作らせる、 書かなくていい部分は書かない、 などの技を繰り出す。

これらの「技」の多くは、アジャイル開発で用いられている技法に近い。 アジャイル開発の技法は「優秀なプログラマだけが利用している分には」 非常に効果的だ、という理由はここにある。

アジャイル開発といわれる形でまとめられた もろもろの技法 から漏れた 技法や 発想法などをまとめたのが本書、 と理解すると比較的判りやすいだろう。

この本の弱点は、 Java や アジャイル開発が大前提になってしまっている事。 著者は ThoughtWorks 社のソフトウェア・アーキテクトだそうだが、 この会社は全体的に アジャイル・Java に偏りすぎていて、 その世界で出てくる問題が世界の問題の本質であるかのように勘違いしている所がある。 結果として、説明が非常に偏っており、 特にどういう問題があるのかの例は
「普通、そんな風に悩んだりしねーよ」
と言いたくなるようなパターンが満載だ。

と言うわけで、以上のような問題点をちゃんと理解した上でならば、お勧め。