2002-12-27(金) [長年日記]
■ トンネル掘削
自宅のpiccoloに職場から接続するために、新たなトンネル掘り。
現在は、外部サーバ(ext1)でZebedeeを動かして、クライアントからはZebedee→stoneで接続している。両者の間はHTTPSだ(ふりをしているだけだが)。ext1のZebedeeからはマルチターゲットを使って他のホスト(ext2)にsshできるようになっている。
さて、これに自宅(home)を追加する場合、一番簡単なのはext1のマルチターゲットに追加することだが、ただでさえ重いトンネルだから、できるだけ途中は省きたい。そうなるとクライアントでもうひとつZebedeeを動かさないといけない(Zebedeeはサーバ側のマルチターゲットはできるが、クライアント側ではできないため←たぶん)。stoneは複数のトンネルを1プロセスで指定できるので、こっちは問題なし。
さて、sshだけだと面白くないので、自宅で動かしているPostfix経由でメールを送れるようにしたい。となると、クライアントはWindowsなので、メーラーからLinux上で口を開けているZebedeeに直接送るか、Windows上でZebedeeを動かしてそこからstoneに接続させるか。
前者だとZebedeeを解放(localsource false)にしなきゃならないから、結果的に社内オープンリレーになってしまってよろしくない。カーネルが2.4ならiptablesで制限することも可能だが、いまさらipchains覚えたくはないしな。……つーわけで、けっきょくWindows上でもZebedeeを動かすことに。
最終的に、我が軍の秘密トンネルはこんな感じとなった。
+- Zebedee -+- sshd Zebedee -+ | (ext1) | (ext1) (Win) | | | | | +------ sshd | | (ext2) Zebedee -+- stone -- squid -+ (ext1用) | | | +- Zebedee -+- sshd Zebedee -+ (home) | (home用) +- Postfix
実際は、末端ごとに接続できるポートとできないポートの組み合わせがこれに加わる。んーむ、複雑すぎてわけわからん……。
■ tDiary: 本日のハンティング
……は最近やってないのだが。というか、やめたんだけど。
実は、tDiary.Netのアンテナには毎日、数個程度の日記が増えているのだ。いちいちアナウンスをしないのは、多すぎて手に負えなくなってきたためである。
というわけで、何も言わないけどリンクされれば数日以内にはちゃんとアンテナに入っているはずなので、登録希望者は確認されたし。入ってなかったら、ちゃとツッコんだ方がいいです。
って、もはや確認するのも大変な数だけどね……。もう、はてなアンテナにアウトソースするしか?(笑)
2002-12-26(木) [長年日記]
■ 何番目まで見るか
「proxy認証」で検索すると8番目に「トンネル掘削機」が……という話はどうでもよくて(相変わらず無意味にページランクが高いのはアレだが)、「8番目なんて見るかね?」という疑問が。
自分に照らし合わせてみると、だいたい3〜5番目くらいまで見て、いい感じのページが引っかからなければすぐに別のキーワードを試してしまう。Googleは適切なキーワードさえ食わせれば、5番目あたりまでに目的のページを見つけてきてくれる……と信じているからで、見つからないのはキーワードの指定の仕方が悪いからと考えているからだ。これって、あまりにコンピュータに合わせすぎているという気もするけど。
というわけで、おれ的には(よほどせっぱつまっているのでない限り)、Googleは最初の5件さえ表示してくれればけっこう。だから、日記の検索refererで50番目くらいの位置にあるのを見つけてしまうと、「よほど困ってるんだなぁ」とか思ってしまうのだが。じつはみんな、けっこう後ろの方まで見てるのか? おれがせっかちなだけ?
■ リリースマネージメント
こういうやり取りを読むと、つくづくオープンソースソフトウェアのリリースマネージメントは難しいと思う。
Ruby(や、もちろんtDiaryも)のような「優しい独裁者タイプ」のプロジェクトに複数のコントリビュータが関わっている場合には、各コンポーネントをリリースに間に合わせるためにマネージャが命令して歩くわけにはいかない。いくらこっちが「独裁者」だからといっても、相手は無償奉仕なわけだし。けっきょくプレビューリリースやβ版を出しつつ、「出すぞ、出すぞ」とポーズを取ることで、徐々にプレッシャーを高めるしかないし、間に合わなければ置いていく非情さも時には発揮しなくてはいけない。
いっぽうApacheやMozillaのような組織的なプロジェクトの場合は、どうしてもβ期間が異様に長かったり、リリースが遅くなりがちな傾向がある。合議制だからだろうなぁ、と思う。関わったことがないから、内実は良く知らないけど。ま、オープンソースに限らず、人が増えるとそうなるけどな……。
結局、リリースマネージメントに必要なのは、調停能力や政治力、カリスマ性といった能力で、ロジックやきれいごとで解決できるたぐいのものではないと思う。ボランティアに頼っているオープンソースプロジェクトならなおさら。「リリースエンジニアリング」なんて言葉もあるけど、あんなもん、エンジニアリングとちゃうわい(笑)。
◆ やまぐち [しまった、構成がよくわからない…]