ソフトウェア開発の勉強（第3回）

ソフトウェア開発の勉強 第3回は英語の重要性とパケットモニタリングです。

まず英語の重要性から。

私の今の状態がそうですが、JSFやEJB3など最新の情報を入手しようと思った場合、日本語の書籍では不十分なことが多いと思います。また、書籍化されておらず各開発元（Apacheなど）のWebサイトの情報を頼りにするしかないという場合もあります。こうした場合、どうしても洋書（英語）の原著を参照する必要があります。少なくとも英文読解は仕事上普通に使うと思っていたほうがよいと思います。
　また、こんな事例がありました。とあるシステムで通信プログラムを書いていて、あるシステムコールを使って制御をしようとしたことがあります。そのとき参照したのが日本語のmanページだったのですが、いくらやってもうまく動かない。なぜかなーと1日中考えていたと思います。あるとき、rootか何かでログインしたウィンドウでmanページを参照したところ偶然英語の文章が出てきました。（LANGUAGEが日本語に設定されていなかったんですね）まあいいや、ということで当該システムコールの部分を読んでいたのですが、何と日本語とまったく反対のことが書かれていました。英文のとおりにプログラミングしたらすんなりと動きました。この日本語manページはOS提供元が出しているもので、基本的に信頼できると思っていたのですが、実は誤訳があったということなのです。これに気づかなければさらに数日悩んでいたことでしょう。

　こうしたことから英語力、特に英文読解力は必須と考えてよいと思います。

続いてパケットモニタリングについて。
私の経験ですが、パケットモニタリングは最低限TCPとHTTPのパケットをモニタリングし、そのシーケンスを解読できるようになっていたほうがよいと思います。パケットモニタリングで問題が解決したということが何度もあります。
事例１：
　別の部署が開発していたプログラムで、どうしても問題が解決ができない、どうやら通信まわりが原因ではないか（その部署では当初OSやドライバの不具合を想定していたようです）、ということで私がパケットモニタリングして問題を分析することになりました。
　問題の部分のパケットをキャプチャしシーケンスを解読したところ、TCPプロトコル上の問題はありませんでした（普通はTCPに問題があることなんてありません）。さらにシーケンスを解読していったところ、私の頭の中に問題の原因が見えてきました。何の言語で作られていたか、一切コードを見ていなかったので知りませんでしたが私の頭の中では（C言語のコードで）どんなプログラミングをし、どんな間違いを犯しているのかがはっきり見えたのです。その内容を担当部署の方に告げるとまさに私の頭に浮かんだプログラミングミスのとおりのミスを犯していたのです。担当部署の方は数日悩んでいたようですが、私はパケットから２～３時間でプログラミングミスの内容まで到達することができました。
（同様なことが他に２件程度ありました）
事例２：
　私がインフラ担当として関与したシステムで、本番稼動後一部端末で問題が発生しました。プログラムコードを確認してもどうしてもそんなことが起きるとは思えず、また特定端末だけで発生するということも理解できませんでした。そこでここでもパケットをキャプチャしHTTPのシーケンスを解析しました。最初は自システム内だけモニタリングしていて原因がまったくつかめなかったのですが、モニタリング範囲を少し広げ自システムに入ってくるところが出るところまでを解析しました（多段階層のシステムだったので解析が非常に大変だったのを覚えています）。原因はなかなかつかめなかったのですが、ふとしたときに”あれ！？”という部分を発見しました。でも何でそうなるの？ということが理解不能な現象でした。そこでシステム外部の機器構成も頭にいれ、どうやったらその”あれ！？”という現象が発生するかの仮説をたて、もしそうなった場合のシーケンスを仮想的に組み立て、仮説が正しいかどうかを検証しました。私の紙の上では「問題は外部のキャッシュサーバだ」ということが明確になりました。あとはそれが事実かどうかを確認するだけでした。社内で「推定原因はXXです」という説明をしたのですが上層部からは「一般的な機器だし、そんなわけないだろう！」という反発がありましたが、それ以外原因がかんがえられなかったため、私の考えで顧客に説明し当該端末の環境を確認してもらいました（本来であれば、外部キャッシュサーバを通らない設定にしてもらうことになっていたのです）。案の上端末側の設定に誤りがあり、外部キャッシュサーバ経由でアクセスしており、この外部キャッシュサーバに不具合があったため問題が発現した、ということが確認できました。
（この他、某有名Webサーバのバグも発見したことがあります）

　どちらの事例もパケットモニタリングの結果を分析していなければ、問題は解決していなかったと思います。この他にも自分自身でプログラミングしていて、不具合が合った場合にパケットを見ることですぐに原因が判明するということが何度もありました。
　今の時代、TCPでの通信のないプログラムはあまりないと思います。システムの不具合を早期に解決するためにもパケットモニタリングの分析という武器を持っているとよいと思います。

　今回はちょっと長くなりましたが、事例を紹介したほうがその必要性がわかりやすいと思い長文とさせていただきました。みなさんも自分自身を武装する意味でもこれらの勉強はやっておきましょう。

　さて次回第4回ですが、プログラミングから少し離れる予定です。要件定義（要件開発）かインフラ関連の知識の必要性などについて触れてみようかと思っています。まだ、頭の中でまとまっていないので期間が空くかもしれません。もともと不定期なものなのでお許しくださいませ。