Wander Alone Like A Rhinoceros Horn

去年は1回しかこのサイトを更新できなかったと述べているうちにすでに2006年も末で今年もこのDICE v0.86リリースに合わせての年1回の更新となる。書きためていた文章もいくつかアップロードした。サイトの全体的な改装なども行いたいけれどなかなか難しい。リンク切れの修正程度が精一杯だ。 Webサイトを公開し始めて7年、このサーバに移ってきてから4年経つ。DICEも4年が経ち、かなり大規模なアプリケーションになった。4種類のサーバが1つになっている上にGUIクライアントやWebアプリケーションのスクリプトなどが入って、一人でメインテナンスするには正直言ってかなり厳しいサイズになっている。ドキュメント類の更新だけでも一仕事だ。アプリケーションのライセンスであるとか、ソフトウェアにまつわる形式的な物事に対して自分で決定し細部まで凝るのが以前は楽しみだった。 プログラミングそのものについても一貫していて、DICEのデザインについてみると、自分がかつて書いた 2本の記録 を読み返してみても構築的な欲求や形式へのこだわりを強く感じる。ネットワークセキュリティにも強い興味があり、DICEの設計も偏執狂的にセキュリティを追及していた。IRCサーバというのは、他の種類のサーバに比べ、一つの独立した世界を創造するという側面が非常に強い。OSからハードウェアの抽象化という機能を抜いたような物だと考えれば案外近いかも知れない。セキュリティは、作り出した世界を確固としたものとするためには必須要件である。 また、DICEを作り始めた2001年頃には、デザインパターンやeXtreme Programming、RUP、アスペクト指向などの、ポストOOとでもいうべきソフトウェア工学のトレンドが旺盛に議論されていて、その頃は私もその関係の本やドキュメントを一生懸命追いかけていた。当時の自分のスタンスはどちらかというと保守的なもので、eXtreme Programmingのような教えは米国のソフトウェアコンサルタントの新しい飯の種にすぎない、自己啓発セミナーのようで胡散臭い、といった見方だった。また、色々なプログラミング言語を勉強したり、積極的に新しいプログラミングのトレンドを追いかけたりもした。C++のテンプレートなどもその一つで、自分の 3年前の文章 を見...

For the first half of this article the main topic is multithreading in the 2 scripting languages, Perl and Ruby. By writing a multithreaded download manager application in Perl and then porting it to Ruby, it'll show you how to write a multithread application in the both languages and show you the difference of these 2 languages in this area. This section should be fairly easy and doesn't require much knowledge about the scripting languages, but it's expected that you have basic grasp of multithread programming. The second half is for a bit more advanced programming topic; it's about how to write a C++ application with an embedded Perl or Ruby interpreter. Simply embedding them is not rocket science, but using them in an effective manner is not a very easy task right now because of the implementations of these languages. If you are familiar with .NET you might know it's embed-friendly with AppD...

プッシュテクノロジと呼ばれる、Web通信をデータ放送に見立てた一連のWeb技術が1990年代後半に注目され、Webブラウザによる実装も試みられたことがあった。通常のHTTP接続はWebブラウザがリクエストをサーバに送りつけるとレスポンスを1つしか返さないのに対し、Content-type: multipart/x-mixed-replaceを利用したHTTP上でのサーバプッシュでは、クライアントのリクエスト無しで第二第三のメッセージが連続してサーバから送られてくるように見える。これを利用するとユーザの介入無く動的なページの表示が可能だった。ところがこの方法はNetscapeブラウザしか対応しておらず、Internet Explorerの台頭と共に完全に死滅することになった。 OSの最大シェアを握るMicrosoftの影響力はやはり強く、何年もアップデートされないIEがWebの進化を停滞させているという批判の一方で、画面遷移無しでWebページの内容を更新する手法としてのAJAXの基盤であるXMLHTTPRequestは、Microsoftが生み出したデファクトスタンダードとしてすんなりと世間に受け入れられた(ただしGoogleがその成果を非Microsoft化してしまった)。しかし、XMLHTTPRequestはクライアントがリクエストを一々発行するクライアントプル技術であり、サーバプッシュの真の代用にはなり得ない。 そもそもHTMLやHTTPというWebの標準がここまで貧しい設計でなければ特定ブラウザで動作するしないといった些細な事柄について無意味な議論を重ねる必要は生じなかったはずだ。HTMLベース技術の大半がプラットフォーム間の互換性の維持に労力を費やしている状況はある観点から見れば極めて寒々しい。例えばblogのデファクトスタンダードであるトラックバックという仕組みは、技術的なメリットではなくそれが標準として流布しているという政治的状況によって生かされているのである。その現状を一旦忘れ、例えば全てのWebページが別個のソフトウェアアプリケーションだったらどうだろうか。HTMLがチューリング完全なプログラミング言語で、自己が利用できるサーバまたはクライアント上の資源を理解しつつ全てのWebページが位置透過的・自律的にサービスを提供していたら?

When you have to write a secure network application, cryptography is one of the topics you can't escape from. In most cases there are high-level packages such as SSL available, but it's not always like that and you may have to go lower-level. Besides, even if you don't program a custom security solution by yourself, it's not a bad idea to know how these secure protocols actually work as it helps you to choose a right solution for your problem. This article provides a basic idea of secure communication by illustrating C++ and C# code examples. Also this article will be useful for those who writes a custom secure protocol between a C++ application and a C# application. (Disclaimer: but don't use the example explained here as is in your mission-critical application! This article is only for the education purpose. Realworld secure communication libraries implement countermeasures against many kinds of known cryptogr...

DICEの更新日付を見たらなんと1年ぶりの更新だった。このウェブサイトについても同様である。実はDICE 0.85自体は去年の8月に完成していたのだけれど、それから色々あって手を付けることが出来なくなり、リリースそのものは今日に至ったという有様だ。書きたいことも多々あるが、しかしまたしても時間がない。後日に譲る。

In late 2001 when I started the development of the DICE , a multi-protocol network server, one of the planned features was secure authenticated connection across the web for remote server administration. I implemented it with SSPI (Security Support Provider Interface Architecture) found in Microsoft Platform SDK. SSPI is an abstraction framework through which you can control 3 (or more) different secure authentication/communication protocols including SSL (Secure Sockets Layer). Among the protocols supported in SSPI, I chose SSL because others (NTLM and Kerberos) were useless in my context over the internet without ActiveDirectory and related mess. But SSL in SSPI has some caveats before use - Since SSL is an inefficient streamed protocol unlike others and the abstraction by SSPI is not in high-level, your code starts to look nasty if you attempt to make it conform to the streaming nature of the protocol. It gets worse especially when your application is constructed arou...

昨年末に Prince of Percia: SOT をやって以来、全くPCゲームをプレイする気が失せていたのは前回書いたとおりである。 Painkiller も昔の面クリア型ゲームを中途半端に模したような感じでかなり興醒めというか期待外れだった。ところが、 ビデオカードのアップグレード予定も当分ないので今年はこのまま何もやらずに済まそうかなどと思っていたところ、あっさりと その方針を覆らせるゲームに当たってしまった。何のことはない、 Unreal Tournament 2004 である。デモ版をダウンロードして遊んでみたところ、ネットワーク対戦のOn-slaughtが実に面白い。デモ版でこれだけ遊べていいのだろうかという出来の良さに率直に驚いてしまった。 前作では、前々作からのグラフィックスの進歩にばかり目を取られ、時間もないということでUTで定評のあるボットの能力を信用してシングルプレイのラダーを クリアしあっさり通り過ぎていたのが、今作のONSで遅ればせながらやっとネットワーク対戦FPSの真価に触れたような気がする。グラフィックス上は前作からほとんど進歩しておらず、またキャラクターもほとんど使い回しという状態ではあっても、乗り物 が正式サポートされたことで遊びの幅が立体的に広がった。最近では乗り物が登場するFPSは珍しくないとはいえ、Unrealの世界の武器の扱いに慣れすぎているせいか、Halo等では味わえない絶妙のバランスを感じる。それも、Haloほどにはかっちりと した作りでもなく、Unrealという名の文字通り非現実的にキャラクターがぴょんぴょん跳び回りつつ激しく接近戦を行うというのがUnreal Tournamentの真骨頂だ。20分程度で済むONSは実にリプレイバリューが高く、たとえ負けても激しい抗戦ができればそれなりに満足感がある。その場限りの人間のチームは、上級者と下級者が混ざっているのでよりメリハリのあるプレイを楽しめる。ONS(とASの一部)では乗り物もあるので、1on1だとさかんにサイドステップで飛び回る上級プレイヤーを叩ける逆転のチャンスも増え、集団ゲームとして実に合理的なハンディキャップ配置である。PCの...