ソフトウェア開発の文化

明日から2名ほど開発メンバーが増えるらしい。これまでは、0.5人分くらいしか戦力がなかったので、少しは開発現場らしくできるかな。

チームができるとき、何らかの文化が生まれる。今のチームにもそれはある。しかし、新しいチームになるのをきっかけに、もう一度これを見直してみるのも良いかもしれない。

「ソフトウェア要求」が名著だったので、期待とともに同じ作者の本を読んだ。この本は、少し前に書かれた本のようで、何か懐かしい香りがする。内容はもっともなことが書かれている。ただし、広く浅く説明してある感じなので、この本に書かれた原則を実践する場合は、別途専門書を読む必要があるかも。

少しだけ残念だったのは、人を感動させるものが少し足りないと思ったこと。自然発生的に創られる文化に満足するのではなく、自分たちでそれをコントロールしようとするには覚悟が必要。日々の過大なストレスと妥協への誘惑に耐え、自分たちの成長を常に求める気持ちがなければいけない。そんなきっかけを、読む人皆に与えるような力が欲しかった。名著「ソフトウェア要求」には、そういう力があったのだけれどな。

ソフトウェア開発の持つべき文化 IT Architects' Archive ソフトウェア開発の課題1

ランドタワー70階

弟の結婚式に出席。弟カッコよす。○○ちゃんもめちゃきれい。

しばらく忙しかったから、親戚と会ったの久しぶりだったり。奈良で工場経営してる叔父さんが、今度、栄養付けさせてくれるそうだ。それよりも、ソフトウェアの仕事ないかな〜。

行きと帰りの新幹線の中で、パテントと読みかけの本を読んだ。

誰と一緒に働くか

来週から、以前に一緒に仕事をした人と、再び一緒に仕事ができることになった。尊敬できる人と、一緒に仕事ができるのは嬉しいことだ。

これまでは、まともな開発者が周りに誰もいないという状況だったので、僕は、自分の能力の向上だけをコツコツ行っていた。しかし、設計理論やソフトウェア開発論について語れるようになっておかないと、彼に、僕が退化したと思われてしまう。以前は、そういう話しを良くしていたものだ。

というわけで、設計の本を読んだ。

ソフトウェアアーキテクチャ―アーキテクチャとドメイン指向トラック (ソフトウェアテクノロジーシリーズ)

いかにも、学者が書いた本という感想。理論をまとめただけで、実際の開発プロセス改善に役に立つものではなかった。それと、気のせいか、現場で適用できる理論と、机上の理論がごっちゃになっている感じ（具体例がないのでそのように感じるのかもしれない）。かなりの経験を積んだ人が読んだら、面白いのかもしれないが（自分の経験を当てはめながら読めるので）、自分には少し早かったかな。

ネットワーク暗号化技術

うちの会社の関係会社が、ネットワーク暗号化の技術を作ったということが、新聞に載っていた。新聞記事なので、本当に良い技術なのかは判断付かないが、関連していくつか考えたことがある。

その技術は、ネットワークの第4層のトランスポート層で暗号化する技術ということだった。第5層で暗号化するSSLよりも高速で、第3層で暗号化する（この表現少しおかしいかも）IPSecみたいに大掛かりな機器が必要がない、さらに、TCP/IPを利用する既存のアプリケーションを一切変更せずに導入できると書かれていた。

ここから先は想像。おそらく、この仕組みは、通信する双方（サーバとクライアント）に、特別なソフトウェアをインストールする必要があるのだろう。だとすると、できることは、VPNの技術と変わらないのではないか、というのが僕の第一感。ちなみに、VPNは、第2層でトンネリングを行う技術が普及しつつあるので、わざわざ第4層で暗号化をする必然性が分からなかった。しかし、もしも、彼らがこれまでのTCPのアルゴリズムに不満があり、そのアルゴリズムを置き換えて暗号化の仕組みを入れているのならば、非常に興味深い。

もう一つ考えたこと。SSLが遅いのは、やはり最初のハンドシェイクがあるからだろうな。ハンドシェイクなしで、http通信の途中経路を単に暗号化する仕組みがあれば嬉しいかもしれない。既存のhttpページを何も変更することなく、インターネットがより安全になる。

しかし、通信相手の保障はどうするかが課題だ。もう一つ問題なのは、サーバとクライアントの双方に、新しいソフトウェアをインストールしないといけないのならば、不特定多数の利用を前提とするインターネットとして成立しないということ。なので、WebブラウザのFlashプラグインくらい簡単に暗号化の仕組みを仕込むことができれば、成立するかもしれない。

パテント調査

一日中パテント調査。数が多くて疲れる。

危ないパテント（我々のソフトウェアが侵害してるかもしれない）がけっこうあった。例えば、「VNC系操作権の交代ができるソフトウェアで、操作権を持ったユーザが、一定時間操作しないと、自動的に操作権が返却される」ってだけのパテントがあった。こんな機能はうっかり作ってしまいそうだな。

もう一つ思ったこと。膨大な数のパテントは、それぞれ既存の技術に少しずつ工夫をしている。逆に言えば、ちょっとの工夫でパテントになることがわかる。それを見ていると、「我々のソフトウェアにこんな工夫を入れたらパテントになるんじゃないか？」というアイデアがいくらでも出てくる。

以前、パテント研修の講師が言っていたこと、「ものを作ってからパテントを調べても遅すぎる、パテントありきの開発をしないといけない」ということが実感できる。

それにしても、パテントを見てると、けっこうおもしろい物が見つかり、創造性を刺激される。例えば、httpを通さないファイアウォールで、httpを通すための工夫、というものがあった（smtpでhttpをエミュレートするというものだった）。世の中、httpしか通さないファイアウォールばかりな状況で、そんなのを思いつくとは、一本とられた感じ。

今後、パテントは定期的に調べるようにしようと思う。

Apacheモジュールの開発

Apacheの本を衝動買い。読んだ感想：Apacheモジュールの開発は、サーブレット開発と大して変わらない。これまで避けていたのだが、実は簡単かも。

Apacheモジュール プログラミングガイド (Advanced Server‐side programmingシリーズ)

ちなみに、11/4の日記の内容少し間違い。http上にsshを使うためには、RFCエイプリルフールネタを使わないといけないと書いたが、それは、あくまで、通常のhttpサーバを使う場合のことだった。httptunnelのように、独自のhttpサーバを使う場合は、そうとは限らないはず。というわけで、自分の環境で、httptunnelが動かないのは、ソフトウェアのバグ（どこかに、httptunnelはバグがあると書かれていたのを見たことがあるような）か、Webプロキシが厳しいチェックを行っているかのどちらかのようだ。

ちなみに、自分で独自のhttpサーバを立てなければならないことは、httptunnelの欠点になりうる。すでにhttpサーバが立っているところでは使えない。

この問題は、Apacheのモジュールとして、sshトンネル用の仕組みを入れるということで回避できそうだ。ちなみに、これを単なるサーブレットで実現するのは、恐らく無理。ずっと昔、サーブレット上で双方向通信ができるかどうか（クライアントからの一回のPOSTが完了しないうちに、サーバがクライアントに返事を出すことで、双方向通信を実現する）の実験をしたことがある。そのときの結果は、Tomcat＋サーブレットではうまくいくのだが、Apache＋Tomcat＋サーブレットではうまくいかない、というものだった。どうやら、Apacheが、POSTをすべて読み込んでから、サーブレットコンテナに処理を渡す、という仕組みになっていたっぽい。

攻撃的セキュリティw

ネットワークセキュリティの本を読む。

ネットワークセキュリティHacks―プロが使うテクニック&ツール100選

ハニーポットにクラッカーを誘い込んで、キーロガーでクラッカーの振る舞いを観察するというテクニックが楽しそう。

もう一つ考えたこと。ハニーポット（もしくはサンドボックス）に、sshdを無防備で公開しておく。さらに、そのマシンでは、sshでコンソールを開くと同時に、ポートフォワーディングが有効になるようにしておく。そして、クラッカーがsshでログインしたときに、逆にそのコネクションを使って、クラッカーのマシンのポートにアクセスする。ってことはできるのだろうか？