nDiki : コンピュータ書籍

書評 お薦めの本 ソフトウェア ゆとりの法則 リファクタリング 創発 ソフトバンクパブリッシング ソフトウエア開発 55の真実と10のウソ トム・デマルコ テスト駆動開発入門 テスト駆動開発 Web 開発 適応型ソフトウェア開発 ピープルウェア 自己組織化 本屋 DVD CD-ROM 検索 2002年 Palm OS C++ CVS エクストリーム・プログラミング 契約による設計 マニュアル 見積もり 干支 電子マニュアル

■ ソフトウエア開発 55の真実と10のウソ読了

いろいろ考えさせられる本。

ウソ5 - ソフトウエアには、もっと開発方法論が必要である。

というのはかなりドキっとさせられる。開発方法論が駄目だとどうすればいいのか。 (状況に応じて)自分なりのパターンを作って適用していくのも意味がないのか。 毎回毎回うんうん唸ってその場限りの作戦を立てなければならないのか…。

よく読むと

筆者の意見は、小文字の m の methodology は善である。 大文字の M の Methodology は悪であり、使う場合は相当の注意を払うべきだ。

とあり、なるほどと。

アジャイル開発、エクストリーム・プログラミングに対する話も随所で述べられていて興味深い。

真実23 - プロジェクトが途中打ち切りになる二つの原因のうち、一つは、仕様を凍結できないことだ。

もかなり納得。

技術者もそうだが、ぜひ上層部の人たちに読んでもらいたい。 「見積もり」とか「要求仕様」とか「保守」とか。

[ 書評 ] [ お薦めの本 ] [ コンピュータ書籍 ]

• Joel on Software - 必読書 (2008-08-14)
• どうみても、そのままでは失敗しそうなプロジェクト (2005-05-16)
• すごい会議 - 短期間で会社が劇的に変わる! (2005-05-27)
• トム・デマルコ ゆとりの法則 - 誰も書かなかったプロジェクト管理の誤解 (2004-04-17)
• ソフトウェアかんばん (2005-10-28)

■ 創発 蟻・脳・都市・ソフトウェアの自己組織化ネットワーク

• 蟻・脳・都市・ソフトウェアの自己組織化ネットワーク - ソフトバンクパブリッシング

以前からちょっと探していた本。 会社帰りに有楽町の三省堂で発見。

ソフトバンクパブリッシングから出しているからてっきりコンピュータ関連のところにあると思っていたのだが見あたらず、端末で検索したら動物学・植物学関連のところにあるとでた。

創発というキーワードは「適応型ソフトウェア開発」でも何度も出てきているし、ちょっと押えておこう考えている。

それと自己組織化といえば大学時代、研究室に興味を示している友人がいたな。

[ コンピュータ書籍 ]

• 創発 蟻・脳・都市・ソフトウェアの自己組織化ネットワーク 読了 (2004-07-09)
• tkh夫妻を囲む会 (2004-01-11)
• 第14回産業用バーチャル リアリティ展最終日 (2006-06-23)
• 今日のさえずり - 「じゅうふく(重複)」はやはり気持ち悪い (2008-03-21)
• ピープルウェア読了 (2004-05-25)

■ 献本がきた

[ コンピュータ書籍 ]

www.naney.org が書籍で紹介される件の献本がソフトバンクパブリッシングからきた。

「ハッキングLinuxザウルス」という本で、WalWiki の 塚本牧生氏が共著で書かれているもの。Zaurus 自体は持ったことがないな。

RCS/CVS 関連のページということで紹介していただいている。 感謝。

• 創発 蟻・脳・都市・ソフトウェアの自己組織化ネットワーク (2004-06-11)
• VSSの分岐 (2002-04-17)
• 私的10大ニュース2004 [ comp ] (2004-12-31)
• LaTeX2e マクロ&クラス プログラミング基礎解説 (2005-04-28)
• wxPerl PPM パッケージ (2006-12-13)

■ 創発 蟻・脳・都市・ソフトウェアの自己組織化ネットワーク 読了

[ コンピュータ書籍 ]

買ってから約1ヶ月。 本屋では動物学・植物学関連のところにあったのだが、やっぱり計算機科学関連の読み物。 創発に関していろいろ考えるきっかけとしてなかなか良かった。 スラッシュドットに対する考察なども興味深い。

本としては脚注が全て巻末にまとめられていて参照しづらい(結局見ていない)のと、日本語としてわかりにくい文が散見された(原文自体がわかりにくいのかもしれないが)のがマイナス。

フィードバックに関する話の途中で出てくる

スレッド型の討論掲示板は、イカレポンチと呼ばれる特殊な生き物にとって、理想的な生態環境となった。 イカレポンチは、ある特定の問題や解釈モデルに執着し、どんな議論であろうと自分の世界観を勝手に述べ立てて平気で、どうやら生業も家族生活もないので、ちょっとした挑発ですさまじいレスを返してよこす。(中略) あらゆる会話を自分の持つ特定の話題につなげないと気がすまず、自分のルールにしたがわない会話すべてに逆らう連中。(pp. 161-162)

という辛辣な表現は刺激的。ちなみにこの後、

ROMを考慮すると、スレッド型議論は実は伝統的な対面講義よりもインタラクティブ性が少なく、夕食のテーブルを囲んだ会話に比べればまるでインタラクティブではない。そこでならいちばん寡黙な参加者ですら、身振りや表情で参加する。(p.163)

と続く。

[ 書評 ]

• 創発 蟻・脳・都市・ソフトウェアの自己組織化ネットワーク (2004-06-11)
• テスト駆動開発入門 (2004-08-02)
• ピープルウェア読了 (2004-05-25)
• Joel on Software - 必読書 (2008-08-14)
• すごい起業 (2005-12-26)

■ テスト駆動開発入門

[ コンピュータ書籍 ]

契約による設計における段階的な表明を追加するプロセスの話などが昨日出た。 自分ももちろん assertion を書くのだが、それとは別に最近はテスト・ファーストによる開発がお気に入り。 しかしまだ「単体テストのカバー範囲」・「テストケースが充分であるか」・「リファクタリング時のテストの追随」などまだ勇気を持てていない部分がある。

ということで(テストとはまた別ではあるのだが)テスト駆動開発もちょっとチェックしておこうかと思い Kent Beck のテスト駆動開発入門を購入。

紙質も比較的チープ。 本屋でぱっと開いてみると細かいコードの断片が散らばっていて、何かプログラムの初学本っぽくてちょっとどうかなというのが最初の感じ。

しかし読み始めてみると面白く Part 1 までまず読み切った。 レッド/グリーン/リファクタリングのサイクルの中で、コードやテストが書き換わっていく様が非常にわかりやすい。 Martin Fowler のリファクタリング-プログラムの体質改善テクニックと同様細かい作業ステップを実演していて、雰囲気が良くわかる。

「テスト駆動開発はテストではなく開発方法である」というのも納得。

「動作するきれいなコード」を書くために続きを読もう。

[ 書評 ]

• テスト駆動開発入門読了 (2004-08-05)
• ソフトウエア開発 55の真実と10のウソ読了 (2004-06-08)
• Scheme でプログラムを書く (2004-08-09)
• 契約による設計と状態遷移モデルの抽出とか (2004-08-01)
• 創発 蟻・脳・都市・ソフトウェアの自己組織化ネットワーク 読了 (2004-07-09)

■ テスト駆動開発入門読了

短めなのですぐ読み終わった。 入門と銘打ってあるが、重要なエッセンスがカバーされているので1冊で結構テスト駆動開発の意味がわかると思う。

• グリーンにする(テストを通す)ために、アサートで期待する定数を返すようなメソッドをまず作ってしまう。

というのが衝撃的である。 自分でも実際そうした事はあるのだが何か罪悪感があった。 しかし TDD では続くリファクタリングのフェーズがあるので、悪ではない。

また

• 「テストの中とコードの中の重複を取り除く」リファクタリング

というのもなるほどという感じ。 コード中での重複はもちろん気を使っているつもりだが、テストとの重複というのは考えたことがなかった。

ぜひ実践してみたい。

[ 書評 ] [ コンピュータ書籍 ]

• テスト駆動開発入門 (2004-08-02)
• ソフトウエア開発 55の真実と10のウソ読了 (2004-06-08)
• ピープルウェア読了 (2004-05-25)
• かんたん年賀状素材集 (2004-12-10)
• 創発 蟻・脳・都市・ソフトウェアの自己組織化ネットワーク 読了 (2004-07-09)

■ かんたん年賀状素材集

[ コンピュータ書籍 ]

次の日曜日に母が年賀状の文面を作成しにやってくる。 ここ最近ずっと文面作成は筆まめで。

素材は筆まめについているやつか、Webのフリー素材を使っているが、

• 筆まめの素材も飽きた。
• 干支イラストは、筆まめが出たバージョンの次の年の分しか充実していない。しかし毎年ソフトをバージョンアップする気はなし。年々重くなるし。
• 筆まめが悪いのか、DVDドライブが悪いのかしらないがイラストを選んでいる時にフリーズする。

という問題を抱えている。

今年は素材集だけ買ってみよう。 箱売りのものはそれなりにするので、CD-ROMつきの書籍に。 どの書籍も、イラストが全て印刷されているで選ぶのも簡単で良さそうだ。

干支のイラストが充実度でいろいろ見て「かんたん年賀状素材集2004年版(技術評論社)」にしてみた。 はたして気にいってもらえるか。

[ 書評 ]

• 母の年賀状文面作成 (2004-12-12)
• 今年も無事母の年賀状の文面完成 (2005-12-17)
• 年賀状作成 (2003-12-06)
• 筆まめVer.19 アップグレード・乗り換え専用　CD-ROM (2008-11-07)
• 恒例の母の年賀状文面作成。 (2006-12-23)

■ わかりやすいマニュアルを作る 文章・用字用語ハンドブック

[ コンピュータ書籍 ]

今日の作業で今年度の作業に区切りがついて一段落。 (いつものことだが)マニュアルについては後手にまわってしまって完成度の高さが充分ではなかったと反省。

いや、時間だけの問題ではないな。 考えてみれば、テクニカルライティングのイロハをきちんと学んでいない。 自分で書くにしても他人が書いた物の問題の指摘をするにしても、これはいけない。

それから、電子マニュアル化ソリューションを提供するなんて言うのに「マニュアルとはなんぞや」を学んでいないなんて恥ずかしい。 Webベースソリューションを提供する企業のWebサイトが駄目駄目なのが恥ずかしいのと同様。

ということでまずは書籍をチェック。 まずは評判の良い「わかりやすいマニュアルを作る 文章・用字用語ハンドブック」を手にしてみた。 主にコンピュータ業界を対象にした内容になっているが、書泉ブックタワーではコンピュータ書籍のフロアではなく1階上のフロアに置いてあった。

冒頭で

この本は、この本で示したルールに従って書いています。p.iii

と書かれている。素晴しい。 X言語で書かれたX言語処理系とか、そういった自己記述・自己適用の好きな自分のハートをがっちりキャッチされた。

まずマニュアル作成工程

1. 企画
2. 目次の作成
3. アウトラインの作成
4. レイアウトの決定
5. 執筆規則の作成
6. 執筆と推敲
7. 査読とテスト

の概要が解説されている。 この点からして頭の中で整理されていなかった部分があるので有り難い。

さすが、読みやすく書かれているのでさらりと読めそうだ。

[ 書評 ] [ お薦めの本 ]

• 恋愛に写真を持ち込みたい人必読「センネン画報」 (2008-09-28)
• すごい会議 - 短期間で会社が劇的に変わる! (2005-05-27)
• かんたん年賀状素材集 (2004-12-10)
• Life Hacks PRESS で Life Hacks をおさらい (2006-03-28)
• 仕事のヒント (2005-11-26)

■ LaTeX2e マクロ&クラス プログラミング基礎解説

[ コンピュータ書籍 ]

dtxファイル、insファイルの書き方を知りたかったので「LaTeX2e マクロ&クラス プログラミング基礎解説」を購入。

[ 書評 ]

• LaTeX2e クラスファイルを .dtx + .ins 化 (2005-05-08)
• トム・デマルコ ゆとりの法則 - 誰も書かなかったプロジェクト管理の誤解 (2004-04-17)
• ソフトウエア開発 55の真実と10のウソ読了 (2004-06-08)
• テスト駆動開発入門 (2004-08-02)
• テスト駆動開発入門読了 (2004-08-05)

■ 「○○についてのお薦めの本、ありますか?」

たまに

「○○についてのお薦めの本、ありますか?」

と問われることがある。 ○○には C++ とか、C# とか Perl とかその他もろもろのコンピュータ関連キーワードが入る。

正直この質問は辛い。

コンピュータ関連の書籍は、今や大量に出版されているし陳腐化も激しいので相当マメにチェックしていないと人に紹介できるもんじゃない。

もちろん古典・定番もあることはあるが、こういう質問の時はたいがいこれには当てはまらない。 言語や開発環境なんかの本の質問はあるけれど、計算機数学とかアルゴリズムとかそういうのを求めてくる人などいないのである (大体そういうのに興味がある人は自分で探している)。

たまたま自分が詳してかつ最近リサーチをかけた分野については良書と呼べるものを知っている場合があるが、良いと思ったら自分でも買っているから既にその人に貸していたりする。

安直にコンピュータ書籍を紹介して欲しいという人は、よくわからないというのを理由に自分で探さず、しかもハズレを引いて金を払うことを非常に嫌っている。

一応質問されると Amazon.co.jp とかのぞいてみるのだが、その人のスキル・その人が求めているものまで理解していないので、結局徒労に終わるのである。 だいたいその程度なら、本人ができるはずなのだが。

ま、ようはケチらずどんどん読んで「この本はウンコだ」と言えるようになるのが一番ということだ。

で、なんかお薦めの本ありませんか?

• Naney お薦めの本

• ハッシュとは (2004-06-09)
• 今日もよくたれています。 (2006-11-17)
• ActivePerl で Ming (2005-02-23)
• トム・デマルコ ゆとりの法則 - 誰も書かなかったプロジェクト管理の誤解 (2004-04-17)
• ソフトウエア開発 55の真実と10のウソ読了 (2004-06-08)