スキップしてメイン コンテンツに移動

投稿

2009の投稿を表示しています

Quid Pro Quo

One thing that I don't like about scripting languages is usage of bizarre identifiers. Statically compiled languages don't care about verbose identifiers, but scripting languages often employ abbreviated names to gain run-time performance and typing speed. my ( $x, $y ) = $self->invoke( +{ METHOD => 'foo', PARAM => 'bar', }, '' ); In this Perl snippet, I had no idea what "+{}" stands for. It looks like some kind of hash, but not sure. Googling it didn't bring good results since Google doesn't recognize a string made only of non-alphabetical characters such as braces and math operators. To figure out its meaning I wasted so much time by trying many different words in Google. Anyway here's the answer: or to force an anon hash constructor use +{ : @hashes = map +{ lc ($_) => 1 }, @array # EXPR, so needs comma at end to get a list of anonymous hashes each with only one entry apiece. It's embedde

C++ Dependency Injection (or the next best thing) on Windows

Dependency Injection (DI) is one of the recent buzz phrases within the design pattern community after Martin Fowler picked it up with another related concept Inversion of Control (IoC) in 2004. Since then, it became popular in Java lightweight frameworks where adding late binding was seen as a critical step for upping productivity. The core value of DI is basically represented in these 2 points: Testability. DI makes testing easy by enabling loosely coupled components that are easily replaced with mock objects. Dependency control. When you deploy a DI framework instead of using the Factory Method pattern, dependency can be managed outside of components. The first point is rather obvious. To understand the second point, I recommend you to browse the Google Giuce lightweight Java DI framework for its video presentation and documents. It illustrates the necessity of such a framework for Java in a straightforward way. Particularly, Giuce appears to be a neat implementation of DI where y

Red Pill or Blue Pill

先月7月頭に、Googleの Chrome OS が発表された。Linuxカーネル + 軽量ウィンドウマネージャ + Google Chrome Webブラウザという構成を取るといわれるこのOSは、いわゆるシンクライアントを最低限のハードウェアリソースで実現するための環境となると推測される。ただし、従来の企業向け用途の単なるシンクライアントではなく、ビデオ再生や3Dなど、ハードウェアリソースを要求するリッチメディアがWeb上で当たり前のようにやりとりされている現在や近未来のパーソナルコンピューティング環境をも視野に入れていることは間違いないだろう。 これが、かつてOracleが提唱した ネットワークコンピュータ を越えていくものとなるかどうかは、実際のプロダクトの出来を見なければ、占うにはまだ早すぎるといわざるをえない。それでも、Google Chromeに続きChrome OSによって、Googleが考えるところの理想のクライアント環境を実現しようとする動きは、きわめて自然であるし、一貫性があるといえる。しかし、この一貫性は、単にGoogle内部で完結しているものではなく、歴史的な流れの中のある一点で、たまたまGoogleという企業が、マイルストーンとして一般に認知される発表を行うことを可能とするリソースや動機を有していた、という見方もできよう。 test 1 この仮想的な歴史をめぐる可能世界で、Chrome OSの前駆者として、またもう一つの可能性として念頭にあるのは、Microsoftの活動だ。今年の2月に発表された Gazelle は、プリンシパルベースのセキュリティという概念を主軸に置いて、Google Chromeより徹底したセキュリティアーキテクチャのWebブラウザを、OSをも巻き込んだ形で実装してしまおうという試みである。このアプローチは、Google Chrome実装の経緯と、興味深い鏡像関係を成している。Google Chromeの実装者らは、Windows上でセキュリティサンドボックスを実現するために、Windows XP SP2の実装に 深く依存せざるを得なかった 。市場を独占するOSのAPIや実装を管理できるというリソースを持ち合わせるMicrosoftにとっては、そのあたりの苦労は、技術的なものではなく、単に手続き的なもので

Whisky-Tango-Foxtrot

更新を再開しようかと思ったのだが、まだネタがないので仕方なくblog風に先日撮った写真で茶を濁す。 芝公園にて、2009年4月3日 昨年も書いているように、サイト自体をCMSかblogツールにいい加減移行したいと本当は思っていて、そのくせ時間がないので踏み切れないでいる。 VS2008はやっと自分のPCにインストールしたところで、昨年書いた課題に取りかかる以前の段階で1年以上足踏みしてしまっている。その間に生活環境が変化したため、以前描いていた計画も、実装に取りかかる遙か以前の段階で既に再検討を余儀なくされている。具体的には、DICEに関して、ある部分のみC++/CLIを用いて.NET化することを考えていた。それというのも、ネイティブコードもそろそろ潮時かと考えて、C++を利用する部分を徐々に縮小させることを意図していたからであった。現在もその方針自体は誤りではなかったと考えているが、今それを為すべきか、そのための時間があるかということを熟慮すると、同じ時間を使うにしても他にやらなければならないことがあるのではないかというのが今回至った結論である。 また、去年計画・調査だけ行って結局頓挫したものとして、どのみち日の目を見ないだろうから忘れないうちに書いてしまうと、RTMPをDICEに実装することを考えていた。それというのも、抽象サーバーフレームワークであるDICEのプロトコル実装の試金石として商業的に意味のありそうなプロトコルを是非実装しておきたかったのと、Flashとの親和性を高めておきたかったという事情がある。サーバー用のソフトウェアスタック(と.NETで作った簡易クライアント)しかコントロールできない私にとって、Flash + JavaScriptはクライアントアプリ作成のためのRAD環境たり得た。ところが状況は変わり、C++の非常に有望なクライアント用ソフトウェアスタックが自由なライセンスの元で利用できることになり、今はそれをどう活かすかについて思案している。勘の良い諸兄ならそれが何かもうお分かりだろう。