Rubyを256倍使うための本 魔道編

* [Rubyを256倍使うための本 魔道編][1]

RDについて書かれた、おそらく唯一の書籍。

RDの入門から始まり、HTMLの作成や、Rubyのリファレンスマニュアルの書き方、RDIndexや作表などの高度な使い方まで、幅広く解説している。著者はRDを活用しているだけあり、内容は実践的だ。

RDの構文は読みやすく、書きやすい。私もこの本を読んで以来、ドキュメントはRDで書くようになった。

ただ、残念な点は索引がないこと。知りたいことを探すのがちょっと大変だ。

[1]: http://www.amazon.co.jp/exec/obidos/redirect?path=ASIN/4756137474&link_code=as2&camp=247&tag=gesource-22&creative=1211

Premature end of script headers

[Premature end of script headersの解決法][1]は、エラー時のチェックポイントがまとまっており、困ったときに参考になります。

チェックポイント

1. 改行コード
2. Perlのパス
3. ファイル転送モード

追加情報ですが、Premature end of script headersのエラーなる場合に、Suexec を無効にすると動くことがあります。

[Apache Tutorial: CGI による動的コンテンツ][2]

> Suexec の権限のチェックは非常に厳しく、それを満たさない場合は CGI プログラムが Premature end of script headers エラーで 実行されません。

あるCGIのインストールプログラムが Premature end of script headers になり、調べたところ Suexec が原因で、無効にすることにより動作しました。

そのインストールプログラムが、ファイルのアクセス権を 705 や 707 に変更しているのが問題ではないかと推測しています。(未確認)

[1]: http://sagittarius.dip.jp/~toshi/premature.html
[2]: http://httpd.apache.org/docs/2.0/ja/howto/cgi.html

チェンジ・ザ・ルール!

* [チェンジ・ザ・ルール! ][1]

要点は次の2つ。

* ITの利益を享受するには、IT導入前のルールを変えなくてはならない。
* ソフト会社はテクノロジーだけでなく、バリューを提供するのだ。

ソフト会社やソフトウェアの導入を検討している会社が直面する一般的な問題と解決方法が描かれている。是非とも読んでもらいたい一冊だ。

> 「テクノロジーの『物理的な』限界を取り除くだけでは不十分だ。たとえ表面的には取り除かれたとしても、実はまだ存在している。ルールが変わらなければ、完全になくなることはない。」

新しいソフトを導入して今までの物理的な制約を取り払っても、物理的な制約があった時代のルールをそのままにしていては、導入したソフトのメリットを享受することはできない。ソフトをインストールしておしまい、ではないのだ。

ITの導入は重要な経営戦略である。パソコンに詳しい社員に任すような仕事ではない。そのことを知らず、今までにも多くの企業が失敗してきた。

> 「それともう一つ、三つ目はトップマネジメント、つまり経営幹部の使う言葉。利益だ。これが最も重要だ。純利益や投資収益率とかいったお金の話だ。キャッシュだよ。私のところの人間も君のところの人間も、この言葉は話さないじゃないか。」

ソフトを導入する会社は、そのソフトが欲しいのではなく、ソフトがもたらす利益が欲しいのだ。ソフト会社は、データフローとかインテグレーションとか、コスト削減や生産性の向上でなく、どれだけの利益をもたらすのか説明できるか。

> 「考えてもみてください。もしシステム導入の早い段階で、利益的に何らかの結果を出すことができればどうなるのか。プロジェクトをずっと円滑に進めることができるはずです。」

大企業に比べ体力のない中小企業は、その分リスクを冒すことに対してより慎重だ。システムの導入でどれだけ利益が向上するか示すこと、早い段階で利益を出すこと、これは中小企業のシステム導入において重要なことかもしれない。

たとえば、[エクストリーム・プログラミング(XP)][2] では、ビジネスの最も価値のある機能から順に、短いサイクルでリリースする。短期リリースによって、顧客企業の利益を最大化する。他にも様々な方法があるだろう。

> 「コンピュータにシステムを追加するのは簡単なことだ。どんなシステムでも追加できる。そんなことは問題じゃない。本当に結果を出したいなら、それ以上の努力が求められるさ」

システムを導入する企業は、「それ以上の努力が求められる」ことをしっかり理解しなければならない。さもなければ、結果を出すことはできない。覚悟はできているか。

ソフト会社はそのことを説明できているだろうか。

[1]: http://www.amazon.co.jp/exec/obidos/redirect?path=ASIN/4478420440&link_code=as2&camp=247&tag=gesource-22&creative=1211
[2]: http://www.amazon.co.jp/exec/obidos/redirect?path=ASIN/489471275X&link_code=as2&camp=247&tag=gesource-22&creative=1211

コードコンプリート (下)

* [コードコンプリート (下)][1]

本書は、数多くの研究結果や経験から導き出されたコンストラクションのベストプラクティスを解説する。

本書を読んで驚いたのが、話題がかなり新しいことである。エクストリームプログラミングやテストファーストプログラミングも検証している。

> 本書では、「テストファーストプログラミング」を、過去10年間に登場したソフトウェアプラクティスの中で最も効果的なものの1つであると同時に、一般的なアプローチとしても優れたものであると考えている。

豊富な研究結果から、特定の方法を盲信したりしない。問題点を指摘する。

> 平均的なプログラマは、自分はテストカバレッジ95%を達成したと考えるが、実際に達成しているのは、せいぜい80%、最悪の場合は30%、平均的なケースで50~60%である。

そして、対策を講じる。

> デペロッパーテストは価値のあるものであると同時に、それだけでは適正な品質保証を実現するのに十分でない。このため、独立テストやコラボレーティブコンストラクションなど、他のプラクティスで補う必要がある。

章の終わりに、多くの参考文献が紹介されている。知識の不足を実感したり、より深い知識を習得したくなったときに便利だ。むしろ、本書を読み終えた後、次に読みたい本がたくさんありすぎて困るかもしれない。

本書は、経験の浅いプログラマにとって、これからの道しるべとなる。経験豊富なプログラマにも、知識を体系的に再構築し不足している知識を補うのに役立つだろう。

[1]: http://www.amazon.co.jp/exec/obidos/redirect?path=ASIN/4891004568&link_code=as2&camp=247&tag=gesource-22&creative=1211