Archive for February, 2006

Rubyist Magazine 0013

Posted by on Wednesday, 22 February, 2006
> >http://jp.rubyist.net/magazine/?0013 >。今号も盛り沢山。やっぱりコード添削が面白いなあ。コードがみるみるうちに短くなっていくさまには見ていてある種の快感を感じます(やばい人みたいだな)。 > >他言語探訪のネタですが、 Lua とか Erlang とかはどうでしょうかと言ってみるテスト。単に自分もよく知らないのでコンパクトな解説記事が欲しいというだけですが。あと CVSup でしか知らない Modula-3 とか。このネタ、本気で伝えようと思ったらどこで言えばいいのかな。 Lua は割とマジ。 > >Dylan というのも名前しか知りませんが、そういえば ICFP のプログラミングコンテストで上位にいたような。 >
Category: Uncategorized  
Comments closed

で、なぜ特許文なぞ見てるのかというと署名広告が特許だという説があるからだ

Posted by on Tuesday, 21 February, 2006
>→ >そういえば、署名広告は、私の知財なんだけど、堀江君 >。ホントかよ？　と思ったわけだ。調べてみたが、 >特許公開2002-342235 >だろう。もしくは >特許公開2002-175249 >だ。 > >前者の請求項は、 >
> >ＨＴＭＬ文書の送受信が可能かつ電子署名自動添付機能を有する電子メイルシステムにおいて、電子メイルユーザの電子署名に必要な氏名・住所・連絡先などを入力するユーザ個人情報入力手段と、広告主が掲載すべき広告と広告配信数や広告閲覧に対する対価情報を入力する広告登録手段と広告情報送信運営者が広告情報内容の自由に広告内容を制御できる広告情報手段と、ユーザ個人情報入力手段において入力された情報を基に広告情報手段を挿入した電子署名ファイルを作成する電子署名作成手段とを有し、電子署名作成手段で作成された電子署名を電子メイルユーザが電子メイルシステムシステムに登録することで電子メイルユーザが電子メイルを送信するたびに電子署名作成手段で作成された電子署名が送信されることを利用し、電子メイルユーザの広告情報手段を挿入した電子メイルの送信数と送信電子メイル中の広告閲覧数を受信者が閲覧した数をカウントする送信・閲覧数カウント手段と、送信・閲覧数カウント手段を用いてカウントされた広告の送信数と受信者の閲覧数とにより広告掲載料を算出する広告掲載料算出手段と、広告掲載料算出手段によって算出した代金を広告主に請求すると共に電子メイルユーザに支払う広告掲載料精算手段を有することを特徴とする電子メイル署名添付広告配信システム。 > > >これで1文…………。以下、ちょっと構造化をほどこす。 > > >電子メイルシステムにおいて > > > >その電子メイルシステムは以下の機能を有する > >ＨＴＭＬ文書の送受信が可能 > > > >電子署名自動添付機能 > > > > > >そのシステムは下記の手段を有する > >電子メイルユーザの電子署名に必要な氏名・住所・連絡先などを入力するユーザ個人情報入力手段 > > > >広告主が掲載すべき広告と広告配信数や広告閲覧に対する対価情報を入力する広告登録手段と広告情報送信運営者が広告情報内容の自由に広告内容を制御できる広告情報手段 > > > >ユーザ個人情報入力手段において入力された情報を基に広告情報手段を挿入した電子署名ファイルを作成する電子署名作成手段 > > > > > >次の機能を利用する > >電子署名作成手段で作成された電子署名を電子メイルユーザが電子メイルシステムシステムに登録することで電子メイルユーザが電子メイルを送信するたびに電子署名作成手段で作成された電子署名が送信されること > > > > > >次の手段を有することを特徴とする > >電子メイルユーザの広告情報手段を挿入した電子メイルの送信数と送信電子メイル中の広告閲覧数を受信者が閲覧した数をカウントする送信・閲覧数カウント手段 > > > >送信・閲覧数カウント手段を用いてカウントされた広告の送信数と受信者の閲覧数とにより広告掲載料を算出する広告掲載料算出手段 > > > >広告掲載料算出手段によって算出した代金を広告主に請求すると共に電子メイルユーザに支払う広告掲載料精算手段 > > > > > >という電子メイル署名添付広告配信システム > > > > >本文はいじってない(はず)。だいぶ見やすくはなったものの、まだまだやりようはあるだろう。 > >で、この内容から考えるに、たんにメールの署名(シグネチャ)に広告を添付するだけではなくて、広く一般に広告主を募り、またメールのユーザが登録することで自動的に広告シグネチャを付与する……つまり hotmail とかみたいなウェブ上のフリーメールサービスを想定しているように思える。ちなみにもう一方の方も請求項は大差ない。 > >もちろん、広告主と広告情報送信業者、メール作成者がぜんぶ同じ人、というケースもありうるが、たとえば受信者のうち閲覧した数をカウントできないと請求項を満たさない。堀江氏のメールの場合には、たとえば自社のURLでの書籍の紹介ページを提示していればカウントできるという主張は可能かもしれないが、一般的に言ってこの請求項は満たさないように思った。 > >もちろんこっちのカンチガイである説もあるが、やっぱり「メールの署名に広告」が特許というなんだかびっくりするような事態はなかったということじゃないかな。 >
Category: Uncategorized  
Comments closed

「特許文」てなんであんなに読みづらいんだろうか

Posted by on Tuesday, 21 February, 2006
>ちょっと眺めて死にそうになった。わかりづらく書いているようにしか見えない。 > >なぜわかりづらいかというと、構造化が明示的でないからだろう。今が全体のどの部分に対応し、その項目のどれが何で、ということがまったくわからないわけだ。自然言語で書かれていること、改行やカッコなどの記号がぜんぜん使われていないこと、1文で書くという制約があるのかどうかは知らないがやたら長い1文であること、の3つが構造の理解を阻んでいるのだと思う。けっきょくいくら読んでもわからないので、エディタにコピペして手元で擬似YAMLのようなものに書換えて眺めることでようやく理解できた。やりながらなんだか >RDF >がたいへんすばらしい技術に思えてきました。ビバ・セマンティックウェブ。 > >っていうか、こういうマークアップ技術は、特許文とか(あと法律とか？)のような類型的で構造が明確であるべき文章にこそ適用されるべきだよなと思ったわけだよ。 > >今更だがな。 >
Category: Uncategorized  
Comments closed

Bright Side of Life / よみがえる空 -RESCUE WINGS-

Posted by on Monday, 20 February, 2006
>けっこう久しぶりに、アニメを見て本気で感動してしまった。この『 >よみがえる空 >』は、自衛隊の災害救助隊を主人公にしたアニメで、地味〜な演出など正直言って「ドラマでやった方がいいんじゃね？」という感じなのだが、個人的にはけっこう好きだ。で、今日言及するのは、先週との対のエピソードでサブタイトルが「Bright Side of Life」。 > >前編の冒頭、いつものオープニングではなく、葬式の場面にオープニング用のスタッフテロップがかぶさるという構成。「故人は言っていました。暗いのは嫌いだから、おれが死んだら好きだったこの曲を流してほしいと。故人の意思を尊重し、この曲で出棺を執り行います」という台詞のあとに流れるのは「ひょっこりひょうたん島」。新聞のカットが差し込まれ、故人が自衛官で、事故死していたことが示唆される。この曲の能天気な明るさが、逆にいたたまれなさを強調して「うひー」となったところでオープニング終了。 > >あとはふつうに日常生活のエピソード。葬式は、主人公の上司がかつて戦闘機パイロットだった頃の同僚だったこととかがわかる。で、前編の終わりころに事故が発生し、主人公のチームが捜索/救助を行う。 > >でまあ救助活動のすえに、結末としてはタイトルの通り「明るい面を見ようじゃないか」ということに落着くと。最後、救助隊のメンバーで宴会をしていて、主人公と上司がカラオケで歌うハメになり、そこで「ひょっこりひょうたん島」を歌って、やがて救助隊全員の大合唱となり、それがエンディングテロップにかぶさって〆め。 >
> >♪苦しいこともあるだろさ　悲しいこともあるだろさ　だけど僕らはくじけない　泣くのはいやだ笑っちゃおう > > >というあの歌詞が、前編のOPでは聞いているだけでこっちがつらくなってくるほどなのに、後編ではまさに Bright Side of Life を照らしている。実に心に沁みわたる名エピソードだった。 > >よいアニメだと思いました。 >
Category: Uncategorized  
Comments closed

CML の CACHE_MISS と CACHE_HIT

Posted by on Monday, 20 February, 2006
>たぶん誰ひとりとして興味ないと思うけど、ついつい lua のソースなどを見てしまった。で、結論から言うと、型の誤りによるものだった。 CACHE_MISS や CACHE_HIT は、 lua_pushboolean を使って値を定義しているから真理値の値をもつ(ところで、どちらでも良いとはいえ CACHE_MISS が true なのはどうかと思う)。一方、 cml ファイルの評価結果は lua_tonumber で取得しているようだ。 > >lua_tonumber のコードを見ると、 > >LUA_API lua_Number lua_tonumber (lua_State *L, int idx) {
TObject n;
const TObject *o = luaA_indexAcceptable(L, idx);
if (o != NULL && tonumber(o, &n))
return nvalue(o);
else
return 0;
} > >細かいところはあまりよくわからないが、指定したオブジェクトを o として取得してから、 null かどうかの判定などをしているということだと思われる。 んで、 tonumber では、 o の型が LUA_TNUMBER かどうかのチェックをしている(それだけではないが今回意味があるのはそれだけ)。ということで今回の場合、 CACHE_HIT にせよ CACHE_MISS にせよ真理値型なので、この判定でミスる。したがって 0 が返される。 > >ところで昨日のエントリを見てほしいわけだが、 cml では 0 が成功、 1 がキャッシュミスを意味していたわけだ(たぶん CACHE_* は後で追加されたのだと思う)。tonumber が失敗すると 0 を返すという仕様と組み合わせると、 CACHE_* を使っているかぎりキャッシュミスは発生しないということになる。どうも上手く行かない原因はここにあったわけだ。なるほどなあ。 > >対処は簡単で、 lua_pushboolean になっているのを lua_pushnumber にしてやればよい。もちろん返戻値を lua_toboolean にしても問題ないけど、後方互換性が保てなくなるという問題がある。 boolean でないものを toboolean しようとすると真が返るので、従来的な 0 か 1 を返すやり方では絶対にキャッシュが成功しなくなります。 >
Category: Uncategorized  
Comments closed

HTTP で、リソースの不在の意味が 404 なのはなぜか

Posted by on Monday, 20 February, 2006
> >それは CERN の部屋配置に由来する >
という記事。個人的には眉唾もいいところだと思っているのだが(それじゃ200号室や301号室、408号室、500号室などにはいったい何があったというのだろう？)、どうなのだろうか。もちろん、大元の由来が404号室で、そこから逆算して4xxはエラー、とした、といった論の展開が考えられるから、200号室があろうがなかろうが矛盾はしないだろうが……。 > >で、この件についてちょっと調べてみたところ、 >http://www.plinko.net/404/history.asp >というページを発見。このページの著者は、 > > >HTTP のステータスコードは FTP をもとにしている。 4xy がエラーなのもFTP由来 > > > >実は CERN には 404 という部屋は存在しない。404号室はただの伝説 > > > > >という主張をしている。 CERN のオフィスのつけかただと、まずそもそも404 は「4階」を意味しないと。最初の数字が建物を意味し、4棟は10から部屋の名前がついていて、つまり4xyな部屋の場合には 410 より大きな部屋番号しかないのだという。 > >どっちが正しいかなんてのは、実際に行ってみるなりなんなりしないことには(もしくは Berners-Lee にじかに聞かないことには)わからないわけですが、おれならこっちの方がまだ信じられるかなぁ。 > >ところで http://www.room404.net/ がさっきからずっと Object Not Found なのはおれだけ？ >
Category: Uncategorized  
Comments closed

CML on lighttpd

Posted by on Sunday, 19 February, 2006
>で、その lighttpd には CML (Cache Meta Language) という奇妙なモジュールがあります。これは、スクリプトを実行するなどの動的なコンテンツを持っているときに、スクリプトを実行するかわりにキャッシュからデータを持ってきたりすることで負荷の軽減化を計るという処理を記述できる言語です。ちなみに言語じたいは Lua を使っています。 Lua とはまた渋い。 > >どういう風につかうか。以下、 >lighttpd の CML のマニュアル >と同じよーな説明ですが、簡単に書いてみます。 > >たとえば、ある test.cgi が適当な出力を吐くとします。こんな感じ。 > >#!/usr/local/bin/ruby
require 'cgi'
cgi = CGI.new
cgi.out { some_proc(File.read("content")) } > >このとき、 content というファイルの中身が変わらなければ、 test.cgi の動作じたいは変わりません。なのに毎回この cgi を実行させて some_proc を実行するのはアホらしいので、キャッシュを利用します。 > >#!/usr/local/bin/ruby
require 'cgi'
cgi = CGI.new
cachefile = "_cache"
unless cache_valid?(cachefile, "content") then
File.open(cachefile, "w") { |fio| fio.print some_proc(File.read("content"))}
end
cgi.out { some_proc(File.read("_cache")) } > >でもやっぱり cgi としてプロセスを駆動させないといけません。 cml を使えば、サーバに組込まれたかたちでキャッシュを利用してファイルの中身を書き出すといったことができます。 > >cgi の側は、キャッシュを使わなくてよいのでこうなります。 > >#!/usr/local/bin/ruby
require 'cgi'
cgi = CGI.new
cachefile = "_cache"
File.open(cachefile, "w") { |fio| fio.print some_proc(File.read("content"))}
cgi.out { some_proc(File.read("_cache")) } > >一方、 test.cml なるファイルを作成し、こちらでキャッシュを取り扱うということです。中身は次のような感じ。 > >cwd = request["CWD"]
cachefile = cwd .. "_cache"
trigger_handler = "test.cgi"
output_file = { cachefile }
if file_mtime(cwd .. "content") > file_mtime(cachefile) then
return 1
end
return 0 > >Lua はあんまり詳しくないのですが、それほど複雑なロジックは使っていないので問題ないでしょう。 .. は文字列の連結。 CWD はおそらくカレントワーキングディレクトリでしょう、スクリプトの設置してあるディレクトリです。 file_mtime はファイルの最終更新日時ですね。数値が返るので大小比較が可能になっています。つまり、 content というファイルと cachefile の更新日時を比較しています。 > >cml のポイントは返戻値にあります。 1 は失敗、0は成功の意味です(lighttpdのマニュアルでは CACHE_MISS と CACHE_HIT が使われている例もあるのですが、なぜか手元では動きませんでした。ちゃんと CACHE_MISS が1で CACHE_HIT が0と定義されてるみたいなんだけどなあ)。成功すると、 output_file で指定したファイルを(順番に)出力します。一方、失敗すると trigger_handler で指定したスクリプトを実行します。で、今回の例では、作成した test.cml にアクセスすると「content の方が新しければ test.cgi を駆動してキャッシュを更新しつつ表示。以降のアクセスが来ると test.cgi は無視してキャッシュの中身を書き出す」という動作になります。 > >cml は lighttpd 内に組込まれて動作するのでプロセスを起動する必要もなく、高速かつ低負荷に動作するとのこと。なんかたぶん、 apache でいうところの mod_* のような仕組みを使えば同じようなことはできるような気はしますし、その場合はその言語のロジックも記述できるからもっと柔軟な気はします。ただまあ、言語ごとにいろいろ用意するのではなくて「出力をキャッシュする」という仕組みに絞って、スクリプトのロジックと分離して機能を提供するってのはなかなか面白いんじゃないですか、と思います。 > >ま、あんまり凝ったことは出来ないでしょうけれど、たとえば「同じようなデザインで、コンテンツとなるファイルだけを差し替える」とかいったケースでもなかなか有用なのではないかと思います。 >
Category: Uncategorized  
Comments closed

lighttpd と htaccess

Posted by on Sunday, 19 February, 2006
>最近ちょっと >lighttpd > で遊んでいます。その理由はというと、 Apache の設定ファイル書式がヘドが出るほど嫌いだからというネガティブなものと、あとちょっとした好奇心。 > >でまあやってみた感じでは基本的にはけっこうわかりやすくてよろしかろうと思うわけですが、 htaccess に相当する機能がないのはちょっとよろしくありません。まあこれがなければそりゃ速くもなろうという感じ(いやまあそれだけではないでしょうが)。 > >で、なぜ htaccess 相当の機能がないか、ということをつらつら考えるに、そういう用途を想定していないからだろうと考えました。 > >一般的なウェブサーバの利用形態というのは、大多数のユーザとごく小数の管理者というモデルが想定されています。システムワイドな部分は httpd.conf を管理者様が維持し、個別のディレクトリのちょっとした設定(indexファイルの設定とか)をユーザが利用するという。 > >でまあそういう運営モデルが崩壊した、というわけでは全然ないわけですが、lighttpd の想定するモデルはもっとコンパクトな世界なのであって、管理者とサーバにアクセスするユーザ層は一致するか、でなくても数として大差ないというレベルなのだろうと。 ISP の www サーバみたいに、ユーザに対して「ホームページ領域」を提供するというモデルではなく、 www サーバにアクセスするのはごく少数のユーザで、その人たちは何らかのサービスを提供するのが主。サービスのスタートのために「こういう設定にしてほしい」と言えば割とホイホイと変えられるようなイメージ。で、最初に「ここだけやってくれ」という設定だけをやってもらってwebアプリを立ち上げちゃうと。ユーザが多いとしても、サービスは基本的にwebアプリ上で提供するわけなので、 htaccess をチマチマ弄るような必然性がそもそもない。なのでサーバ側で余計なことはあまりしませんと、そういうことなんじゃないかと思えばなんとなく納得できる気もします。 > >まあでも htaccess は欲しいよなぁ。 >
Category: Uncategorized  
Comments closed

豆腐の三分割問題

Posted by on Friday, 17 February, 2006
>昨日のことだが、豆腐のパックを買って、さて食うかというときに、なんとなく1/3くらい食いたかった。さてどう分割したものか。もちろん、平行に薄っぺらく3枚に切れば3等分できるが、もっと好ましい切り方があるような気がする。 > >好ましい切り方とは何か？ > >私見だが、冷奴のような喰い方の場合には「塊」っぽくしたい。塊っぽさとは何だろうか？　それはようするに、立方体に近い形状をしているということではないだろうか。つまり、ある豆腐片を取り巻く最小の立方体の一片の長さによって評価できるのではないだろうか。 > >……などと考えつつ冷奴でいただいた。ちなみにパックの豆腐はよくよく考えたところ4等分でもまだデカいほどだったのでさしたる問題はありませんでした。 > >さて、もう少しまじめに取り組んでみたい。 > >豆腐の形状は、バラツキがあると面倒なのでひとまず立方体としておく。直方体は立方体の問題が解けてから取り組むべきだと考える。するとこの問題は、 > >この立方体を、体積で三等分する。それぞれの形は同じでなくてかまわないが、体積は等しくなくてはいけない。そのような3つの立体のそれぞれについて、外接する球の半径の和が最小となるような分割の仕方は何か？ > >という問題に定式化できる。 > >定式化できることはわかったのだが、さてそこからどう取り組んだものかがよくわからない。べつの数学の問題に帰着できるのかどうかもよくわからない。なんか、けっきょくある辺を3等分して得られる薄っぺらいやつが最適とかいうつまんない結果になりそうだしなぁ。 > >mixi 日記で書いたところ、評価関数としては重心からの慣性モーメントみたいなものを使うのはどうかといった指摘とか、 >バナッハ＝タルスキ分割 >
すればオーケーといった解決案はいただいたものの、当初の悩みはあまり解決していない。 > >おかげで今は『ホワイトライト』を再読中だ。 >
Category: Uncategorized  
Comments closed

howl

Posted by on Friday, 17 February, 2006
> >http://mono.kmc.gr.jp/~oxy/hiki.cgi?howl >。おおこれは良さげですな。といいつつまだ試せていません。 >
Category: Uncategorized  
Comments closed