一ヶ月前に「ソフトウェアインスペクションの試行」(http://dev.ariel-networks.com/Members/inoue/software-inspection)の記事を書きました。 実施を始めて、約一ヶ月経ったことになります。

実経験と合わせて読めば何かヒントをつかめるかと思い、「ピアレビュー」を読んでみました。

• http://www.amazon.co.jp/exec/obidos/ASIN/489100388X/arielnetworks-22/

結論から言えば、読んでも役に立ちません。最初の4章ぐらいは読んで楽しい(役には立たないですが)ところもありましたが、後半は読むのもつまらない本でした。

2章の最後の「レビューの原則」は知っておいて損はありません(ぼくは、読む前から知っていたので特に感銘は受けませんでしたが)。次の5つです。

• 始める前に自身のエゴをチェックせよ(改善提案に受容的であれ)
• レビューチームは小さくせよ(参加者は3-7人。呼ぶのはブタだけ、ニワトリを場に呼んではいけない)
• レビューでは問題の発見に努め、解決を試みるな
• レビューミーティングは約2時間に制限せよ
• 事前準備を要求せよ

繰り返し書いてあるプロセス上のポイントが次の3点です。

• インスペクションを計画せよ
• インスペクションの結果を記録せよ
• インスペクションを(部下の)評価に使うな

これもまあ本を読む前から自明です。

興味深いと思った部分が、「単体テストの前にコードインスペクションせよ」の部分でした。単体テストの後に実施すると、どうせバグは無いだろうという心理的バイアスがかかるため、らしいです。ここは異論がありそうな部分です。

3章に「インスペクション」、「レビュー」、「ウォークスルー」の比較表があります。 誰が定義したんだ、と言いたくなる比較表で、この定義に従う必要性は感じませんが、この3つの用語、日常の中であまりに曖昧すぎて何を指しているのか分からないのも事実です。

比較表を見る限り、モデレータ、作成者、読み手の役割の部分が明らかな相違です。

• インスペクション: モデレータ、作成者、読み手を、それぞれ別の人が行う。
• レビュー: インスペクションとウォークスルーの中間形態(モデレータと読み手が一致する場合など)。
• ウォークスルー: 作成者がモデレータかつ読み手を兼ねる。

コードインスペクションをしていて思うのが、本当は、デバッガで動的にコードを追いながらコードを見る方が効率的だろうな、という思いです。 デバッガを使わず、頭の中だけでコードを動かしてバグを見つけられる自分のスキルを誇らしく思う気持ちは、正直に告白すれば、あります。しかし、自分のささやかなプライドを満たすことがコードインスペクションの目的ではありません。

基本的にデバッガは好きです。gdbは好きなUnixコマンドの2番目ぐらいです(1番はemacs)。マイクロソフト製のソフトの中で一番良いと思っている(あるいは、Windowsにあって一番羨ましいと思っているのが)Visual C++のデバッガの部分です。

残念ながら、Javaでは事情が異なります。eclipseでコードを動かしながらコードインスペクションをしたら、ミーティングの20%ぐらいが待ち時間になりそうです。イライラして集中できなくなるので、実施できません。

「プログラミングの心理学」

• http://www.amazon.co.jp/exec/obidos/ASIN/4839915946/arielnetworks-22/

この業界でワインバーグは一種のブランドで、ワインバーグの本を理解できない奴は本質的な思考のできない奴だとレッテルすら貼られかねません。 白状すると、ぼくは過去、ワインバーグの本を読んでそんなに感銘を受けた記憶がありません。読む前の期待値が大きすぎたせいかもしれません。読んで感動した記憶が無いのです。内容もまったく覚えていません。

今回も、名著と呼ばれるだけに期待しすぎたかもしれません。それほどでも無い、というのが率直な感想です。部分部分で面白いところもありますが、全部読む必要は感じません。

一番面白いと思ったのが、プログラマに向く性格と向かない性格を分析した章(8章)でした。ちなみに、8章全体としての結論は、プログラマに向いた性格を判定できる単一の指標は存在しない、です。ありきたりですが。

ワインバーグが考えたプログラマに向く性格分析として次のようなものが載っています。

• 一週間以上の緊張状態に耐えられる能力
• ある程度急速な変化に適応する能力
• 多少ともきれい好きであること
• 少しばかりの謙虚さを持ち合わせていること
• 自己主張、性格の強さ
• ユーモアのセンス

最初の、緊張状態に耐えられる能力は、共感できないでも無いですが、プログラマ固有かと言われると疑問です。どんな仕事でも多かれ少なかれ緊張状態を伴うと思うからです。次の急速な変化に適応する能力も同じです。この業界だけが特別に変化が速くて、他の職業とは違うと主張するのは、自意識過剰な特権意識を表明しているようでぼくは嫌いです。

きれい好きの部分は、並んだ性格特性の中でも一番目を引くのではないでしょうか。世間一般のプログラマの印象とかけ離れているように感じるからです。本書の中でも、きれい好きの意味は身なりのことを言っているのではない、と断っています。では何かと言うと、コンピュータは膨大な紙類を生産するのでそれを整理できないとやっていけない、と書いてあります。この部分、昔とはだいぶ事情が違います。今やプログラマはソースコードの印刷などしないからです(まともなエディタを使える限り)。

紙類の整理の必要が無くなっても、少し違う観点でのきれい好き、つまり、自分の中にある(もしかしたら他人には窺いしれない)規律でモノを整理しなければ気がすまない気質は、プログラマにとって重要では無いかとぼくは思っています。かつて冗談混じりにマイクロソフトの社員の一定数はアスペルガーだと揶揄(?)されたことがありますが、アスペルガーの一部の人は、規則性への異常関心を持つと言われています。そういう規則性への執着はプログラマに向く気質のひとつだと思います。

謙虚さと性格の強さは、本の中でも相反する特性と書かれています。謙虚さが無いと、自分のバグを認めることができませんし、新しいことを学ぶことができません。一方で、本書にもあるように、プログラマの仕事は現実の泥臭さの中で物事をやってのけることです。本書の表現を借りれば、物事をやってのけるには、ときには邪魔物をよけて通ったり、乗り越えたり、いっそのこと叩きのめしたりすることが必要です。そんな性格の強さが必要です。謙虚さと強さの共存は、Larry Wallの言う三大美徳に通じるものがある気がします。

最後のユーモアのセンスはどうでしょう。ぼくが確かに言えることはrmsのユーモアのセンスが素晴らしいことぐらいです。

• http://www.ariel-networks.com/blogs/airone/2008/05/av484.html

v4.8.3からほとんど変わっていません。今回はブランチからのリリースです。

AirOneは過去細かくバージョンアップしている割には、ブランチからのリリースはあまりしていません。今回は珍しくブランチからのリリースでした。もっとも、ブランチの作業はマスター浜岸にお任せでした。

オープンソースなどで、複数のブランチで開発が進むプロジェクトがあります。あれをうまくやれる人を本当にすごいと思います。ポストCVSと呼ばれるバージョン管理システムの多くは、自分たちのソフトはCVSよりうまくブランチが扱えると主張します。確かにsubversionはCVSよりブランチをうまく扱えます。他も、CVSよりマシだろうと思わせるモノがあります。

CVSのブランチの扱いが難しいのは事実です。未だにメモを見ながらでないと、まともに操作できません。しかし、逆に言うとメモさえ見ていれば操作ぐらいはできると言うことです。本当に大変なのは、分岐した複数のソースコードを把握することです。この辺の大変さは、ツールの問題では無い気がしています。本質的にソースコードの複雑さの問題だと思うからです。それとも単に無知なだけで、ツールを使いこなせば何か変わるのでしょうか。

今日はちょっと辛口です。

徳力さん経由で知ったイベントです。facebook内の招待だけで人を集めるイベントだと思っていたので、こじんまりとした集まりかと想像していました。実際には、100人以上の人がいました。TV東京のカメラも来ていました。

夜7時に始まると、頭の悪そうな4人の男女がステージ上でパフォーマンスを始めました。安っぽいステージ上で、ダンスなのか良く分からない動きでfacebookのロゴを壁に組み立てました。わざわざあのパフォーマンスのために人を呼んだとは思えないので、店の人だったのかもしれません。このオープニングは実にセンスが悪かったです。

全体で2時間ありましたが、前半はfacebookの人のスピーチで、後半が日本人による自作アプリを紹介するデモでした。

facebookの人のスピーチは、特に開発者向けではありませんでした。新しい機能も乞うご期待、だけで目新しい発表もありません。Googleを見習って、何か新しい機能の紹介のひとつでも言えばよさそうなものです。

自作アプリのデモも、プロジェクターの調子が悪く、進行がぐだぐだで、全般的に低調でした。一番受けたのが、「開発Tips」と始めて、「facebookのAPIの呼び出しは遅い」と聴衆を引きつけて、「なので、APIの呼び出し回数を減らすか...速いネットワークにしてください」と落としたところです。笑うところかどうか微妙ですが。

椅子は遠いし、床に座り込むのは嫌いなので、後半、壁に寄りかかっていました。人が多いところでは壁を背にするのが基本です。

• level1: 誰かが書いたテストスペックを愚直に実行する
• level2: 特別な文字とかを使ってテストしてみる
• level3: 境界条件や異常ケースを意識してテストしてみる
• level4: 最近のコードの修正やバグ報告の傾向を意識してテストしてみる
• level5: コードを頭の中で動かしてバグを見つける。テストは裏を取るための作業
• level6: 仕様書を読んでバグを見つける。テストは裏を取るための作業
• level7: 無意識にバグを引き寄せる能力を獲得

レベルの高い人だけが揃っていると、却って簡単なバグがスルーされたりします。好打者が却って真ん中の好球を凡打してしまうようなものです。レベルの低い初心者にも存在価値があるのが、ソフトウェアテストの奥の深いところです。

ネットワーク(TCP)同時接続数が数千ほどあるマシンがあります。

負荷が高くなってきたので、ハードウェア増強やソフトウェア(アプリ)の見直しをしています。 同時に、Linux(kernel)のパラメータに工夫の余地があるか調べてみました。

Linuxのネットワーク系のパフォーマンスチューニングで調べると、以下のようなサイトが見つかります。

• http://www.performancewiki.com/linux-tuning.html
• http://people.redhat.com/alikins/system_tuning.html
• http://www.zdnetindia.com/index.php?action=article&prodid=8288
• http://www.enigma.id.au/linux_tuning.txt
• http://www.acc.umu.se/~maswan/linux-netperf.txt

ここに書いてある設定を愚直に設定すれば改善するかと言うと、そんなに単純ではありません。 なぜなら、ネットワークのパフォーマンスと言っても、前提条件が色々と異なるからです。 特に危険なのが、ネットワークパフォーマンスと言っているのが、サーバとクライアントを超高速回線で直結して、その時のスループットを最大化する設定だったりする場合です。ほとんどの実運用環境において、そのような設定値は無意味です。

今回考慮した前提条件は以下のようになっています。

• 普通のインターネットからの接続を受けつける(同一リンクからの接続は基本的にありません。接続相手は超低速でもないですが、超高速でもありません)
• TCPのセッションを張りっぱなし(パケットは流れ続けている)の接続もあれば、つないですぐに切れる接続もある
• それなりにパケットは落ちている(再送が発生している)
• 接続数が多いので、反応が無さそうな接続は(なるべく)早めに見切りをつけたい
• 接続待ちのキューにあまりクライアントが待たれても困るので、(クライアントに)早めに見切りをつけてもらいたい(接続を諦めてもらう)
• ムダなメモリ消費をなるべく抑えたい

上の参考サイトの中で、比較的無害と思われる次の設定を /etc/sysctl.conf に書くことにしました。無害そうである一方、実は(パフォーマンス的な)効果もあまり期待できそうにありませんが。

# Drop it so lack of FIN times out quicker
net.ipv4.tcp_fin_timeout = 30
# reuse TIME-WAIT sockets
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
# Turn off timestamps
# Turn this back on if you're on a gigabit or very busy network
# Having it off is one less thing the IP stack needs to work on
net.ipv4.tcp_timestamps = 0
# Turn syn-cookie protection on
net.ipv4.tcp_syncookies = 1
# Enable really big (>65kB) TCP window scaling if we want it.
net.ipv4.tcp_window_scaling = 1        #デフォルト1だったので書かなくても同じ

これ以外、当然の設定(net.ipv4.conf.default.forwarding = 0)などありますが(*)、デフォルトで適切な値になっているので特に言及しません。

(*)ここでの「当然」の意味は、意図に反してforwardingがenableになっていたらおかしい、という意味での「当然」です。

上記サイトの多くで、次のようにソケットのバッファ用メモリサイズを増やす設定を勧めています(値はページによって色々です。以下の例は見つけた中で最大値を設定している例です)。

# Bump up max r/wmem
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
# Increase size of socket buffers
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

この設定は却下しました。理由は同時接続数が数千あるという事情からです。例えば同時接続数が2000で、接続ごとのバッファサイズが2Mバイトあれば、掛け算すると4Gバイトです。もちろん、全ての接続が一斉にバッファを埋める可能性はあまりありません。しかし、メモリ周りのリスクを冒す気にはなれませんでした。

# Widen local port range
net.ipv4.ip_local_port_range = 1024    65000

上の設定を勧めているサイトもありました。これは、accept(2)するだけのサーバ系ソフトの場合は関係ありません。このため、設定はしません(デフォルトのまま)。

# Drop keep-alive time
net.ipv4.tcp_keepalive_time = 1800

上のようにTCPのkeepaliveタイムのインターバル値を下げる設定を勧めるサイトもありました。これがパフォーマンスに与える効果は良く分かりません。 今回考慮したマシンに関しては、keepalive相当の処理はアプリ層でやっていて、TCP層のkeepalive機能に頼っていないので、この設定値には意味がありません。良く分からないモノはいじるなの鉄則で、デフォルトのままです。

# Increase number of incoming connections backlog
net.core.netdev_max_backlog = 1024
# Increase number of incoming connections backlog
net.core.somaxconn = 512

サイトによっては上の設定は有効かもしれません(短期で切れるセッションが多数のサイト。小容量のコンテンツ配信が中心のWebサーバなど)。今回に関しては、前提に書いたように、ビジー状態で大量にクライアントに待たれても困るので、この値は増やしませんでした。

# Turn off sack
net.ipv4.tcp_sack = 0
# Turn off sack/fack
net.ipv4.tcp_fack = 0

この推奨を勧めるサイトもあります(手元のGNU/Linuxマシンのデフォルトは、どちらも1(=有効)になっていました)。パケットの再送がそれなりの率で発生する環境では有効な機能のはずです(元々そういう意図でTCPに追加された機能なので)。無効にすることを勧める理由は...たぶん、理想的なスループットを発揮できるネットワーク環境では不要な機能だ、という判断でしょうか。よく分かりません。結局、これらは、そのまま(デフォルト)にしました。

少し前ですが、apacheのMLに以下のメールがありました。

• http://mail-archives.apache.org/mod_mbox/httpd-dev/200805.mbox/%3c200805141444195002867@case.edu%3e

apacheのソースコードを静的解析して、バグ(らしいモノ)を見つけたという投稿です。apacheのソースは、保守的かつ慎重で、非常に多数の目が通っています。今さら静的解析ツールでバグを見つけたとしたら驚きます。

メールから引用します。

The 6 bugs can be categorized into the following 2 groups:

Category-1: missing of a check of the return value of a function A function may return an error code such as 0, -1 or NULL to indicate that an error occured inside of a function. We've found several potential bugs where a check of the return value is likely to be missing for certain functions.

Category-2: missing of a function call This normally happens when a function call is missing in a set of function calls that always need to be invoked together, for example, malloc() and free().

前者(category-1)は、たいしたことありません。関数の戻り値を無視するコードなら、(成熟したソフトでも)珍しくはありませんし、静的解析で見つけたと聞いても驚きません。

後者(category-2)は典型的なバグで、ある条件下では発見が難しいバグです。これに関するバグをツールで見つけたとしたら、たいしたものです。

理想的には、このように呼び出し側が順序を気にして呼ぶAPIを無くすべきですが、現実に無くすことはできません。局所的には、設計の工夫や言語の持つ機能で可能ですが、全てを無くせると思うのは幻想です。GCを持ったJavaでmalloc()/free()相当のペアを無くせても、close()相当のメソッドを完全に追放できないことからも分かります。Rubyのブロックでclose()相当の呼び出しを隠蔽できることを知っている人は、まだ幻想を持つかもしれませんが、解決できるのは局所的な場合のみです(解決できるのはC++のRAIIのテクニックでカバーできる部分と同程度)。

結果的には、category-2として見つけたふたつのバグらしいものはバグでは無いという結論でした。apacheのコードの場合、メモリプールの解放時にコールバック関数を登録できて、そこで暗黙にリソースの解放をできます。今回、ツールが指摘した箇所は、そういうコードだったようです。静的解析ツールの言うがままに解放処理を入れてしまうと、想定より早い解放のために誤動作(たぶんクラッシュ)します。

ある程度の規模のソフトウェアの場合、こういう風に、局所的にコードに見えている部分だけではなく、より上位のメタ知識が暗黙に要求されるコードがあります。これは、プログラミングで最も難しいことのひとつです。逆に言えば、暗黙の要求が少ないコードほど、可読性が高いコードであり、多くのプログラマが書きたいと思うコードでもあります。

今回は残念な結果でしたが、静的解析ツールで「We found a potential rule requiring that the ap_destroy_sub_req() be executed to release the object returned by ap_sub_req_lookup_uri()」を発見できるのはクールだと思いました。

• http://www.amazon.co.jp/exec/obidos/ASIN/4822281116/arielnetworks-22/

原稿が進まない現実逃避かもしれませんが、「ゆとりの法則」を読みました。

「第22章 恐怖と安全」が一番気に入りました。人(組織)が変化できるためには、失敗しても責められないという安心感が必要だという主張です。一部、引用します。

皮肉やいやみを言い、ぐさりとくる批判をし、目の前であざ笑い、人前ではじかしめ、いらだち、かんしゃくを起こし、あきれてみせる。これらはすべて、重要な変化にとって本当の敵である。変化を受け入れられる組織にするには、このような不遜な態度を組織から一掃する必要がある。かわりに、どの階層の人でも、あえて苦労を受け入れようとすれば尊敬されると、はっきりわかるようにすることだ。

変化の最中は、どんな失敗でも、教訓を伝えるものとして尊重されるべきである。失敗した人はヒーローであり、変化の立役者である。失敗によって、その人は前にもまして尊重される。

失敗した人はヒーロー、ってところが良いですね。最近、人の失敗を見ていらだちを見せてしまったかもしれません。今度から、失敗した人はヒーローという格言を忘れないようにします。