gadgethack

最近、たびたびトラックバック・スパムが来る。
ドメイン名やIPアドレスは毎回異なるが、内容からして同じような発信元なのは間違いない。
コメントやトラックバックは基本は自由にしておきたいが、
スパムは鬱陶しい。

seesaaではマイ・ブログのコメント/TB->スパムフィルタから設定できる。
後から追加された「言及リンクのないトラックバック」を有効にして様子を見てみよう。

まだ拡張の余地はあるが、それっぽく動くWiresharkプラグインができた。
だいぶ前にできてはいたが、他の人にも有益と思われる情報をまとめる時間ができたので書いておこう。

かなり汎用的に設計したつもりだが、業務で使っている特殊なプロトコルの仕様のせいで、
一部どうしても汎用的な作りにできなかったので、今回はオープンソース化は見送った。
オープンソース化のメリットはいろいろあるが、それを語るのはまた別の機会に。
また、私が考えたコンセプトは、Wiresharkの他のプロトコル解析プラグインとはちょっと設計思想が異なるので、
文化的にも受け入れられるか疑問が残るし、何をどうやればできるかTrial&Error的に作ったので、
設計も美しくないと言うのも見送った理由。

今回作ったプラグインの解析対象となるプロトコルはクローズドなネットワークだけで使われる特殊なもの。
仕様も度々変わるので、その度にWiresharkプラグインをビルドし直すのもだるいし、
誰もがWiresharkの作りに精通しているわけでもない。

と言うわけで、基本的なコンセプトは、"XML definedable multi-protocol dissector plugin"と言う感じ。
XMLにプロトコルの仕様を書き、Wiresharkプラグイン側でこれを解析してXMLの内容により動作を変えるというもの。
XMLの解析にはlibxml2を使った。Windows用バイナリはこのへんからゲットしてくる。

"dissector"はあまり聞きなれない言葉だが、解剖する人と言う意味。
プロトコルを分析するところからWiresharkプロジェクトではdissectorと呼んでいるのだろう。

Developer's Guideの9.2. Adding a basic dissectorに従えば、最も基本的なUDPの1つ上のレイヤのプロトコル解析プラグインはすぐに作ることができる。

しかし、ちょっとまともな作りにしようと思ったら、Developer's Guideには記載がなく、日本語でも英語でもインターネット上にはあまり情報源がないため、既存のdissectorのソースコードを読まないといけない。


1. Wiresharkのリリースに含まれているプラグインをビルドして、それをバイナリリリースされているプラグインディレクトリにコピーしてもエラーダイアログが出て正しく読み込まれない。
これはどういうことか。
Help->about Wiresharkを見ると、バイナリリリースのものは、VC++6.0でビルドされているようだ。
VC++2005EE+PSDKでビルドする場合には何か注意点があるのか？
Windows XPだとエラーダイアログ内にメッセージが出ないので、何が問題かよくわからない。
Windows Vistaで実行すると、msvcr80.dllがないというメッセージが出ていた。
なるほど。CRTをダイナミックリンクにしているのが原因か。
MSVCR80.dllに依存しないようにするを参考にして対処する。

Makefile.namke内のCFLAGSにテキストエディタで直接/MTオプションを書き入れる。
「/MDより/MTが優先されます」というようなWarningがでるが気にすることはない。
それにしても、CRTをスタティックリンクしただけで、22kbyte程度だったdllが、100kbyteを超えたのには驚いた。


2. リリースビルドはどうやるのか
VC++の構成で、Releaseを選択してもなぜかデバッグ情報を吐き出しているようだ。
かといって、Makefile.nmakeの中にデバッグ用とリリース用のターゲットが書かれているわけではなさそうだ。
ふとしたことからスタートメニューにあるPSDKの配下に、Windows XPとか、2000とか、32bit/64bit、Debug/Retail用のコンパイル環境変数を設定したシェルを開くショートカットが用意されていることに気づいた。
なるほど、PSDKの環境変数を変えることで切り替えるのが流儀なのか。
と言うことで、VC++を使ってビルドする場合は、プロジェクトのプロパティページの構成プロパティ->NMakeで、ビルドコマンドラインに渡している

"c:\Program Files\Microsoft Platform SDK for Windows Server 2003 R2\SetEnv.Cmd"
と言う文字列を
"c:\Program Files\Microsoft Platform SDK for Windows Server 2003 R2\SetEnv.Cmd" /XP32 /RETAIL
などのように変更すればいいということだ。
私の環境では、SetEnv.Cmd内のデフォルトで、/XP32、/DEBUGが指定されたのと同じ動作をするようになっていた。


3. 未知の上位プロトコルに対して、dataという表示をツリーペインに表示させるには
handoff内で、find_dissector("data")を呼んで戻り値のhandleを保存しておき、自分のプロトコルのdisssectを行った後、まだ残りの解析していないパケットデータがあれば、call_dissectorにこのhandleを渡せばよい。
この辺は、epan/dissector/packet-udp.cを読むとわかると思う。


4. 自分で追加したプロトコルのさらに上位のプロトコルを解析するにはどうすればいいか。
たとえば、ether headerのether typeを見て、0x0800だったら、次は、IPのdissectorを呼び、
ip headerのprotocolを見て17だったら、次は、UDPのdissectorを呼び、と言うことを、自前のプロトコルの解析でやるにはどうすればいいかということ。
epan/dissector/packet-eth.c、epan/dissector/packet-ip.c、epan/dissector/packet-udp.cをよく読めばわかるが、ちょっと面倒。
ether typeから上位プロトコルを判別する仕組みは、epan/dissector/packet-ethtype.cにハードコーディングされている。
ipヘッダのプロトコルの解析の仕方は、もっとごちゃごちゃしている。
XMLに定義されたプロトコル仕様からその動作を決めるという要求を満たすには、UDPヘッダやTCPヘッダのポート番号から、上位プロトコルを解析するルーチンへジャンプする仕組みと同様な方法がよい。
例えば、plugins/agentx/packet-agentx.cを見ればわかるが、create_dissector_handleでハンドルを取得し、dissector_add("tcp.port", agentx_tcp_port, agentx_handle)と言う具合に文字列(Wiresharkでは、abbrevと呼んでいて、表示されたパケットをフィルタする時に使う文字列と同じもの)を指定することで上位プロトコルのdissectorを追加したい。
これをやるには、まず、"udp.port"や"tcp.port"という文字列を、abbrevとして登録する必要があり、これをやるには、register_dissector_tableを呼ぶ。
パケットを解析した後、register_dissector_tableの戻り値と共に、dissector_try_portを呼び出せば後は勝手にdissector_addしたdissectorを検索して呼び出してくれる。
この仕組みを使えば、たとえばIPv6のnext headerのように、プロトコル中の特定のデータの値によって、次に来るデータを解析するための型を動的に変えることが可能になる。


5. フラグメントされたパケットをどう扱うか
実は、フラグメント機能は、私はまだ全容を把握していない(ので、実装もできていない)。
基本的な知識は、9.4. How to reassemble split packetsを読む。
UDPやTCPの(というか、実際にはIPフラグメント)フラグメントに対応するには、この手順どおりにやれあばうまくいくだろう。
しかし、独自のプロトコルがフラグメントをサポートする場合はどうすればいいだろうか。
pinfo->fragmented、fragment_add_seq_check、process_reassembled_dataあたりがキーになるようだが、もう少し調査が必要だ。


6. プロトコルの型をXMLに定義する際に、同じ型の繰り返し表現をべたに書いていたのでは大変なので、配列表現に対応した。他のwiresharkプラグインでは特定のプロトコルのみを解析すればいいので、配列のサイズや次元は固定的に扱って(ハードコーディングして)いるようだが、私が作ったプラグインではそうはいかないので、XMLに定義を書けるようにした。多次元配列で、それぞれの次元の配列サイズもXML読み込み時に決定されるが、これをプログラム上でどう扱うかについては、多少工夫が必要だった。基本アイデアは、配列のdimension分のサイズを持つg_arrayの要素に配列のサイズを突っ込んでおいて、後でこれを順次とりだして再帰的に処理を行うということをやっている。XMLの定義を信用して再帰的に処理しているので、セキュリティ的には問題があるが、世間で広く使われるものでもないので、汎用性と実装のしやすさを優先させた。


7. まだ実現できていない機能に可変長対応がある。汎化すると、プロトコル中のある特定のデータ数分、何かのパターンが繰り返されるというデータ解析ロジックをどうやってXMLに定義し、どうやってそれを実装するか。最近、別件で忙しいのであまりWiresharkプラグインには取り組めていない。


他にも、hfとかettとかハマリポイントはあるのだが、それはまた別の機会に。dissector_try_heuristicも何ができるのか気になる。。。

2009年から公募株式投資信託を換金した際は原則として確定申告が必要になったらしい。
一般口座に置いたままだと損益計算が面倒なので、特定口座へ移管することにする。
そもそも、特定口座って何？っていうところは、このへんとか、このへんとかで勉強しておく。

私は新生銀行と取引しているが、非上場公募株式投資信託の受益証券の取得証明書という書類を返送する必要があるようだ。
この書類の中で、取得価額は、(1)買付けた際に要した金額に基づき計算した額と、(2)個別元本の額に購入手数料等の金額を加算した額のどちらかから選択できるが、どちらを選んだらよいかよくわからなかった。

電話して聞いてみたらなんということはない、この金額が、将来、投資信託を売却したときの損益計算に使われるということで、金額が大きい方を選択しておけば、有利になるということらしい。
それならそうと書いておいてくれれば親切なのに。

昨年、入居してからたったの1年でマンションを売却した、という話は以前に書いた。

さて、譲渡益が出ても、損失が出ても、土地・建物の譲渡所得は分離課税であるから確定申告はしないといけない。
譲渡所得については、国税庁のページを見ると概要がわかる。

ただ、土地・建物の譲渡所得の申告が初めての私には、どんな書類が必要なのかとか、実際の作業レベルで、何をすればいいのかがよくわからない。
マンションを売却すると、仲介業者から、確定申告のガイドをもらえるはずなので、それにも目を通しておくとよいだろう。

土地・建物等の譲渡所得の確定申告をする場合は、分離課税申告書(申告書Bと第三表)というのを税務署に提出する必要がある。
お金に余裕がある人は税理士にお願いしてもよいと思うが、大体2万円ぐらいかかるし、1度覚えればたいした手間でもないので、自分でやれるものは自分でやることにする。
税金関連の法律が難しすぎるから税理士という職業が必要なのか、税理士という職業を守るために、わざと難しい状況を解消する方向へ進まないのか、この命題には取り組む価値はあると思うがそれはまた別の機会に。

e-taxで提出するにしろ、書面で税務署に提出するにしろ、書類自体は、国税庁の平成20年分　確定申告書等作成コーナーから作成するのが楽。

マンション購入時に、e-taxで申告したので、今回もe-taxでやろうと考えていたのだが、落とし穴があった。
公的個人認証の電子証明書は、住所が変わると失効してしまうが、転居の際に、再発行してもらっていなかったので、失効してしまっていた。
というわけで、電子証明書を再発行してもらわないとe-taxでは申告できないことがわかった。

e-taxで申告するのと、書面により申告するのとでは何が違うかというと、住民票の除票を省略できるかどうかが違う。

売却したマンションがある地域を管轄する市町村では、住民票の写しは、1通300円の手数料がかかるが、土日祝でも取得可能。
電子証明書の再発行には、手数料が500円かかる上、平日しか対応してもらえない。
ということで、今回はe-taxによる申告はあきらめることにする。

多少わかりづらい分離課税申告書(申告書Bと第三表)の書き方や、相変わらず使いづらい確定申告書等作成コーナーのハマるポイントについては次回書こうと思う。

以前、WiresharkをVC++でデバッグしてみるで書いたが、VC++でWiresharkをデバッグしていると、フリーズするぐらいIDEの動作が遅くなる現象に出くわすことが度々あった。
Core Duo 1.66GHzで、メモリも3GB積んでいるから、そんなにポンコツマシンでもないのだが、なんでだろう。

1つの原因は、Wiresharkのソースツリーをネットワークドライブに置いているせいだろう。
ビジネス向けのPCは、HDDの容量が少ないことが多い。私が会社で使っているものは40GBしかない。
パーティション切って、Linux用に15GB割り当てているから、何かとディスクを消費するWindows用には25GBしか残っていない。
これではデータをローカルに置いておくには少な過ぎる。
Wiresharkプロジェクトは、フルビルドするには1GB弱のディスクを消費するから、リモートに置くしか選択肢がない。
ローカルディスクには、パブリックに公開するわけにいかない情報をTrueCryptの暗号化ドライブに入れて保存している。

もう1つ。VC++のステータスバーに「IntelliSenseを更新中」という文字列が出ているのに気づいた。
一度更新が完了しても、VC++を再立ち上げすると、再度更新を始めたりするようだ。
これは、ネットワークドライブにモノを置いているのも影響しているのだろうか。

IntelliSenseを無効にしたらいいだろうと思って、調べてみると、今日のワンポイント : 既定で IntelliSense を無効にする方法 - #098というのが出てきたが、この通りやっても、IntelliSenseを更新する現象は変わらない。
IntelliSenseを無効にしているのだらか、IntelliSense用のデータベースを更新する必要はないだろうと思うのが常識的発想と思うが、なぜか更新は止まらない。
もはやこの動作はバグの世界だな。。。と悪態をつきつつ、上記の記事からリンクされている原文も読んでみると、
ということが書かれていた。
なるほど、テキストエディタの設定は、自動的にポップアップするのを抑止してくれるだけで、オンデマンドでは動作すると言うことらしい。
したがって、VC++がIntelliSenseのデータベースの更新を止める動作にならないのはそういうわけだったのだ。

あきらめずに調べると、おしえてgoo!にVC++ 2005 Intellisenseを更新...が終了しないと言うのが投稿されているのを発見した。
私が使っているのもVC++2005SP1だ。
元ネタは、Intellisense Updating never terminates, hangs VS 2005。
これを実行するこで、問題はとりあえず回避できたが、こんなworkaroundを適用しないと回避できないとは。。。

C#やVBで.NETのクラスライブラリを使っていたときは、IntelliSenseはすごい便利な機能だと思ったものだが、今回のようなプログラムを扱うときにはOFFにできた方が便利だと悟った。

自転車で走行中、青信号の横断歩道内で、右折してきたバイクに巻き込みをかけられた。
自転車とバイクが接触はしたものの、両者転倒はせず、お互いに怪我はなし。
自転車・バイクへの損傷も走行には支障ない程度だった。

警察官だって人間だもの、ミスはある。
怪我がなかったからかも知れないが、事故が起きたこと自体はとやかく言うつもりはない。
が、事故後、いくつか思うところがあったのでそれを書こう。

まず、自身が警察と言えど事故後の処理には、交通課の別の警察官を呼ぶようだ。
事故後の処理の客観性や公平性を保つ事を考えればこれは正しい。
てっきり警察無線を使うかと思ったが、携帯電話を使ったのは公務の連絡ではなく、事故の加害者としての連絡だからか。

さて、交通課の人が来るまでの間、現場を目撃していた新聞屋が近寄ってきて、警察に何の恨みがあるのか、「警察のくせにふざけるな」とか、ブツブツ暴言を吐いて行った。
事故の被害者は私だ。
その私が怪我もなく大丈夫だと言っているのに、部外者の新聞屋がバイクのナンバーまで記録して他の警察に通報したりするのは非常に違和感を感じた。
市民の安全を守るはずの警察。
今回はたまたまミスを犯してしまったわけだ(※1)。
新聞屋の件が警察への個人的な怨恨なのかよくわからないが、警察と言うだけでなぜこうも目の敵にされなければならないのか、市民からこうまで信頼されいないのかと思うと悲しくなった。

事故を起こした彼は、そういうことを敏感に感じ、市民に信頼される警察を作る為に、今後の行動に変化があるだろうか。


さて、一方の警察の方にも組織的な問題があるように感じた。
まず、事故の現場検証をするのに駆けつけた交通課の警察官が3人。
身内の事故だからだろうか、それ以外にも何とか課の課長やらなにやらが来て、総勢6〜7人ぐらいになった。

あの新聞屋のような人間が被害者であれば、上官を呼べ、とか、むやみやたらと騒ぎ立てそうだが、私はちょっと違う感じ方をした。
「これだから公務員は。。。」と思うのは単なる偏見なのだが、こんなにも大勢でやる仕事には思えないのは確かだ。

交通事故統計によると、日本国内の年間交通事故発生件数は約80万件。
今回の事故検証にかかった時間は約0.5時間。
今回の事故検証で無駄だった人数を4人とすると、
800000 x 0.5 x 4 = 1600000[Man-Hour]
仮に1ヶ月の労働時間を160hrsとして計算すると、実に10万人月もの無駄だ。
もちろん、今回ほど簡単な事故の方が珍しいだろうし、毎度、事故処理に必要な人数は変わるので、この計算はそのままは信頼に足る数値とはいえない。
事故検証にかかる平均時間と平均無駄人数の推定値から、フェルミ推定を使って、もう少しまともな定量化ができるだろうが、今回は「いかに無駄があったか」ということを強調するだけの方便なので省略する。

交通課の仕事は、企業の中における間接部門の生産性の問題に通じるものがあり、ものを作り出しているわけではないので、成果の定量的な評価がしづらいのが今回のような無駄とも思える行動につながった原因だろうか。

ところで、物損と人身では事故の重大性が異なる。
この事故を起こした警官を悪意を持って陥れたいなら話は別だが、私自身の時間の無駄でもあるので、病院にはいかないつもりだった。
また、自転車への損傷もほとんどなく、新しい自転車を買ってもらえるわけではないし、量販店で買った安い自転車だったので、特に修理する必要もない、と言ったら、「答申書」なるものを書いてくれ、と言われた。
答申書なるものの法的拘束力がどの程度のものかわからないが、「答申」とは、「上級の官庁や上役の問いに対して意見を申し述べること」だそうだ。
答申の意味は後から調べてわかった話だが、事故の被害者である私が下で、警察側が上だという上下関係が存在していたことは、ちょっと気分が悪い。

私自身への検分が終わった後、昨日はかなり冷えたので、警察の車両の中で待機させてもらった。
寒いから中へ、という配慮は大変ありがたかった。
が、答申書を作成を依頼する環境はよくなかったのではないか。
警察車両の中の密室で、交通課の警察官と1対1、と言う状況でお願いされたのだ。
意思が薄弱な人にとっては、これは無言の圧力になりはしないか。
なんだか、冤罪が発生する土壌の一端を見た気がした。

こういう態度だから、あの新聞屋のように、隙を見せるとバッシングの対象になってしまうのだろう。

私の部下にも、体を動かす、世間のためになるような仕事がしたいと言って、警察を志望し、退職した若いヤツがいたが、彼は今どうしているだろうか。


※1 私がソフトウェア開発業界に従事しているせいかも知れないが、ヒューマンエラーというのはゼロにはできないと思っている。「バグを出すな」ということを上から強制しようとしても、人間は必ずミスをする。現実の世界では、人間がミスを犯すと言う前提で、人間が不得意な分野で人間性・属人性を排除するためにオートメーション化したり、ミスによる被害をいかに最小限に食い止めるかを考えたほうが現実的で、まともな解が得られることが多いのではないだろうか。たとえば、交通事故に関していうと、車のエアバッグとか、バイクのヘルメットとかは、リスク管理の一環だろう。

キリスト教徒以外の多くの日本人にとっては
数多くある年中行事の1つにしか過ぎなくなっているクリスマス。
今年は、街を歩いても、クリスマスシーズンだというのに、
「クリスマス、Christmas、Xmas」の文字列が並んだ広告をあまり見ない。
不景気で、広告を打つ余裕もないということか。

今年は、「ホームページ」という言葉ではなく、
「WEBページ」という言葉が、メディアでも普通に使われるように
なったような気がしていたので、同様に、"X'mas"という誤記が、
どの程度減少するのか興味を持っていた。

目にする広告の絶対数が少ないのでなんとも言えないところもあるが、
このグローバル化の時代にあって、いまだに
"X'mas"という表記をしているものもあるようだ。

"X"と"mas"の間に星をあしらっている広告を見たことがあるが、
ここによると、"Xmas"という表記に対して誤記ではないか、
という問い合わせがくるので、苦肉の策として、ということらしい。
人に文句を言う暇があるなら、ちょっと調べればすぐにわかることなのに、よっぽど自分に自信があるんでしょうね。
それにしても、これを考えたデザイナーはスゴい。

言語は生き物であるから、ｘｘは正しい言葉の使い方だとか、
「日本語の乱れ」などと言うことはナンセンス(※1)だと私は思うが、
元来、クリスマスはキリスト教文化のもの(※2)であるし、
日本で独自の文化を形成しているというほどの状況でもないと思うので、
文化に受け入れられないうちは、X'masは誤用の域を出られないだろう。
単に表面的な言葉を知るだけでなく、背景にある文化・歴史を知ると
新たに見えてくるものがあるのではないだろうか。
いつでも、オリジンを訪ねる旅というのは知的好奇心を満たしてくれる。

※1 これについては、平安時代の日本語と、現代の日本語はまったく異なる言語と言ってもいいほど変容していることから容易に結論付けられる。

※2 宗教が絡む話は、ひどい場合には戦争に発展するから怖い。

たけしの日本教育白書2008で、トロッコ問題というのが取り上げられていた。
「作業員は動けない状態」という状況は省略されているから、Wikipediaとか、WIRED VISIONとかに出ている話とはちょっと違う部分もあるが、まぁそこはあまり事の本質ではないので省略したのだろうか。
(この条件がないと、危ないから避けろ!!と叫べばいいだけの気がしたが。。。)


TVでは、「この問題を子どもにどう教えますか」と来た。


私の回答はこう。
「答えない。子供に自身の頭で考えさせる。」

もちろん、「自分で考えろ」という言い方はしない。
子供と共に考え、また、彼・彼女らがさらに考えを発展させるためのヒントを出すだろう。
早期から1つの考えに固執しすぎないように、あえて別の角度からものを考えさせる。
私は自分の部下に対しても日々の課題解決を行うに当たってそのように接している。

この問題には、そもそも正解などない。
こういうのをオープンエンドと言ったかな、確か。
考えて自分なりの答えを出し、それをその後の行動に結びつけることに意味があるのであって、「どう教えますか」という質問の仕方そのものが、正解があることを前提としているようで、どうもしっくりこない。

さて、話をトロッコ問題に戻そう。
私ならこの状況でどういう選択をするだろうか。

* case1
私がこの問題を聞いたとき、最初に思いついたのは、ポイントを半分だけ切り替えて(あるいは線路に石でも置いて)トロッコを脱線させることだ。
トロッコを脱線させてしまえば、6人の作業員の命は全員助かることになる。
この場合、トロッコが無人運転で、トロッコの脱線による被害者がないという前提は置いてはいるが。。。

え？
この問題のルールでは、答えらえる選択肢は2つだって？
そういうことを言う人は、与えられた2つの選択肢が妥当かどうか一瞬でも考えたのだろうか。
現実に起こるさまざまな課題を解決するにはそんな硬い頭では最良の解は見出せないのではないだろうか。
多くの場合、まず「前提を疑う」事が問題の解決へつながる近道だったりする。

いいでしょう。ゲームにルールは必要。
私もルールに則り、ポイントを切り替えるか、切り替えないか、のどちらかから選択することにしよう。

* case2
私ならポイントを切り替える。そもそも何で作業員が線路の上で動けないという意味不明な状況になっているかも説明されていないが、その不可解な状況を素直に受け入れるとすると、ポイントを切り替えた後、動けない1人の作業員の元へ走って行き、その人を線路から引きずり出せばよい。
動けない人というのが1人なら体力的にも時間的にも何とかなる可能性があるが、5人の方にトロッコを進めさせてしまった場合はその可能性が極端に低下する。
もちろん、トロッコのスピード・距離と、自分の足の速さと、動けない人までの距離も関係はするが。。。

トロッコはすぐそこまで迫っていて、ポイントを切り替えた後に作業員の元へ走っていくような時間的な余裕はそもそもないって？
私は宗教は信じないが、そんな切迫した状況で、こんな究極の選択を迫られる状況に遭遇したら、神への悪態もつきたくなるというものだ。
「おお、神よ。あなたは無力な私になぜこのような試練をお与えになるのか。」

* case3
ポイントは切り替えない。いや、正確な表現としては、切り替えられない、だ。
case1、case2は、今こうしてPCに向かいながら、より多くの人命を救うという使命の元、理性的に考えた結果だから言える事だが、ケース2の最後の方に書いたように、トロッコは自分のすぐ目の前のポイント切り替え部分に接近している状況で、2つの経路に5人と1人がそれぞれ「動けない」状況にあるという状況判断、そして、その一瞬で5人と1人の命を天秤にかけるような判断は、少なくとも私には「できない」と思われる。
救急医療とか、消防とか、軍隊とか、日々、危機的状況下でも対応できるような訓練している人々でさえ、実際の現場では判断を誤ることもあるわけで、私のような素人がそのような過酷な状況下ではまともな判断ができるとは思えない。
ということは、呆然として瞬間的には積極的な行動は何もとれないだろうということは容易に想像できる。

* case4
case3では、事故当時、何も手を打たなかったことに対して、世間からバッシングの嵐になることも予想される。
ゴシップ好きの暇人たちには格好の餌だ。
仮に世間から何も言われなかったとしても、何か行動を起こせなかった自分に対して、本当に何もしないでいることが正しかったのか、自問自答の日々が続くだろう。
ノコノコ生き残った自分には、まさに生き地獄というわけだ。
トロッコ問題には、「The fat man」という続きがあるそうだ。
多くの人は、隣の見知らぬ人を橋の上から突き落とさないという回答をし、5人を見殺しにするという結果が出ており、ポイントを切り替える場合と回答に一貫性がないということが指摘されているようだ。
そもそも、1人を線路に突き落としたぐらいで、簡単にトロッコが止められるなら、私が最初にcase1で考えた脱線させるという案がもっともまともな解な気がするし、5人の路線でも1人の路線でもどうせ犠牲者は1人だ(1人を引き殺したところでトロッコは止まる)。
確実に1人の命が犠牲になれば、トロッコは止まるとわかっているなら、case3のような状況になって一生悩み続けるよりは、自分を犠牲にしてトロッコを止めるということも一案だ。
自己防衛本能に逆らっているから生物学的には正しくないが、これで私も歴史に残る英雄になれるというわけだ。

* case5
何もしない。
行動結果はcase3と同じだが、もう少し別の観点で考えて見る。
そもそも、ブレーキの壊れたトロッコが走ってきたとして、そのトロッコが人をひき殺すというのは妄想ではないか。
トロッコがどのぐらいの大きさなのかとか、どのぐらいのスピードか、積荷はどの程度あるのかといった情報がまるでないので、問題文からだけでは考えるに値する状況かどうかも判断しかねる。
これは、Aになったら誰かが死ぬ、Bになっても誰かが死ぬという危機的な状況での究極の選択、という前提条件を疑ったものだ。
この考え方ができれば、自殺や、昨今の「相手は誰でもよかった」という無差別殺人のような事件は無くすことができるのではないか。
自分にとって切迫した、非常に重要なことを選択しなければならないとき、それが本当に悩むほど重大な事なのかを一度客観的に見直してみることは意味がある。
本当は、トロッコが人をひくかどうかが問題なのではなくて(トロッコによっては誰も死なないのだから)、6人もの人間が同時に比較的近い線路の上で動けなくなっている状況の方がずっと問題だったりしないか。
現場は炭鉱かなにかで有毒ガスでも出たのか、テロの仕業か、はたまた集団自殺か。

その他、道徳観を養うという意味では、次のような状況も考えると面白い。
1人の方へポイントを切り替えるという人がいて、5人死ぬより、1人の方が犠牲が少ないというような人がいるとしたら、「5人は赤の他人で、1人の方は自分の親・子供・配偶者・親友のいずれかだったら」という前提をつけてみるといいと思う。
今度は、5人の方を犠牲にすると言い出すだろうか。

こういうことを子供のころから考えさせることは非常に意義があると思う。
現実は、もっと酷い。
この問題に少し似ている状況として思いついたのが、例えば、救急車のたらい回しによって、救急患者が亡くなるという事件が繰り返し発生しているのだから。

PCがお手軽なプロトコルアナライザに変身するWireshark。
ネットワークに関わる人なら1度は使ったことがあるはずだ。
近い将来、仕事で新しいプロトコルのアナライザが必要になりそうだったが、この手の世界で無料でお手軽に試せるようなものはない。
ないものは作ればいい、ということで、Wiresharkのプラグインとして対応することを思いついた。
私の周囲にはWindowsマシンしか使えない人が多いので、プラットフォームとしてはまずWindowsを考える。

WiresharkのWindows上でのビルドについては、ここの手順に従えばよい。
ここで不足する情報は、本家のDeveloper's Guideを読むとよい。
もともとWindows専用にデザインされたわけではないアプリケーションの場合、Windows上でビルドするのは環境をそろえるところからして非常に大変だ。
ビルド対象は、今日時点で最新リリースのWireshark-1.0.4を使う。

さてコンパイラには何を使おうか。
候補は、VC++ 2008 Express EditionかVC++ 2005 Express Editionか。
有料なツールは却下。
個人で気軽に試せないし、最近はコスト圧力が強くて会社も気前よく購入してくれない。
config.nmakeを見ると
という記述がある。
そうは言っても、VC++2005EEではPlatform SDKを別途インストールしなければいけないというところが面倒。
VC++2008EEではPlatform SDK相当が同梱されるようになったようだ。

というわけで、Wireshark本家の開発者の警告を無視し、VC++2008EEでやってみた。
config.nmakeの記述どおり、起動しない。
原因を調べるのは本筋から外れるので、VC++2005EEに切り替えてリビルドする。
今度はあっさり立ち上がる。

と、ここでデバッグはどうするのだ？という疑問が沸いて来た。
私が普段デバッグでよく使うのはgdb。
Visual Studioプロジェクトのソフトウェアをデバッグするときは、IDEからデバッグする。
ところが、前述のビルド手順では、nmakeとclを直接呼び出しているので、IDEのプロジェクトは使用していない(Wiresharkのソースコードには付属していない)。
こういう場合、どうやってデバッグすればいいのか。
もちろんgdbでもデバッグは可能だが、gcc -gでビルドしていないのでデバッグシンボルがない＝ソースレベルデバッグはできない。
GUIアプリケーションをアセンブリレベルでデバッグするのは正直しんどい。
*.pdbファイルは吐き出されているから、Visual Studio用のデバッグ情報は出力されている模様。
gdbのようなコマンドラインデバッガがVC++にも付属しているかと思って調べてみたが情報が出てこない。
Wiresharkを立ち上げておいて、VC++からプロセスにアタッチすれば、もちろんアセンブリレベルでのデバッグはできるが、せっかくIDEがあるのだから、これを活用したい。
Developer's Guideにも3.7. Debug your generated Wiresharkという章はあるのだが、中身は未記載だった。

次に考えたのは、IDEにWiresharkプロジェクトをインポートする方法。
これがうまくいったので紹介しておこう。
ファイルー>既存のコードからプロジェクトを作成
プロジェクトファイルの場所には、Wiresharkのソースコードを展開した場所を選ぶ。
プロジェクト名には適当な名前をつける。
プロジェクトのビルド方法は、外部のビルドシステムを使用するをチェックする。
ビルドコマンドラインには、
を指定する。
リビルドはビルドと同じコマンドを、クリーンにはdistcleanターゲットを指定すればいいと思う。
最初、Platform SDKの環境設定用のコマンドは実行していなかったのだが、
と言われてハマる。
U1052は、file not foundの意味のようだ。
Makefile.namekの7行目は、
なので、win32.makが見つからないということだろう。
私はnmakeは書いたことがないが、<>付なので、システムとしてパスが通っていることを期待していると予想できる。
というところで、Platform SDKの環境変数が見えていないのだということに気づいた。
SetEnv.Cmdの中身を環境変数に常に展開するのは面倒だし、VC++はあまり使ったことがないので、とりあえずnmake実行時に毎回実行することにした。

さてこれでVC++ IDEからビルドする準備は整った。
プラグインの読み込みは、epan/plugins.cあたり、また、agentxプロトコルだったら、proto_register_agentxにでもブレークポイントをはれば、プラグインDLLの登録時のデバッグもできる。

結論から言うと、週末にオーダーを出してもあまりいいことはないってことだ。
下げから始まると思っていたが、マーケットがオープンしてみると、上げから始まった。
FX Onlineでは6時10分からopenしていたのに、MJでは7時ぐらいまで取引はcloseのままだった。
会社によってこんなに差があるとは。。。
MJがcloseしている状態でオーダーを出してみたが、50pips以上スリッページが発生した。

ま、世の中そう簡単にはうまくいくようにはなっていないということだ。