2008年07月

日本Ruby会議2008やジュンク堂トークセッションで話したときの様子が動画で公開されているので張ってみる。

Pythonのdecoratorは格好いいよね。Rubyでこんな感じのものを作れないかと何回か考えたものの、上手いAPIを思いつかずにいた。

このたび、technohippyさんの挑戦に刺激されて書いてみた。

• decorator.rb

仕様としてはPythonに合わせて、呼び出し可能オブジェクトを返す関数としてdecoratorを作成する。そして、declareというメソッドにdecoratorを渡すと、ブロック内で定義されたメソッドはdecoratorで修飾される。

■ 例

 class Module
  def type(name, types)
     before(name) do |name, args|
       args.zip(types).each_with_index do |(arg, type), i|
         raise TypeError, "#{i}th argument #{arg} should be #{type}" unless arg.instance_of?(type)
       end
     end
   end
   def always_one(name)
      proc{|*args| 1 }
   end
 end
  
 class Calc
   declare :type, [Float, Float] do
     def add(x,y); x+y end
     def sub(x,y); x-y end
     def mul(x,y); x*y end
   end
   declare :always_one do
     def div(x,y); x/y end
   end
 end
 
 calc = Calc.new
 p calc.add(1.0, 2.0)
 p.calc.div(1.0, 2.0)   #=> 1
 p calc.sub(1.0, 2)     #=> TypeError

■ ポイント

• Rubyなんだからブロック使おうよ、という。Module#privateみたいに頑張ってブロックなしにするのも考えたけど、労多くして実り少なしだよね。
• Ruby 1.8.7以降で動作する。
• 特異メソッドに非対応
• イテレータは修飾できない。define_methodにブロックを渡した場合、呼び出し時にメソッド本体へブロックを渡す方法がないので。Ruby 1.9だと頑張ればできるんだけど。
• UnboundMethod経由のメソッドすり替えを試せて楽しかった。
• もうちょっと真面目に書いてgem化したら誰か使う?

子供の頃、大人とその社会は神のように見えた。私には見えない大きな何らかの機構の中から給与を稼ぎ出してくるすべ、自動車の運転の仕方、料理を習得する方法とその技量、美容院の予約の方法、私にはよく理解できない不思議な知人のネットワーク、これらを、彼らはどうやって身につけたのだろう。彼らは私にはまったく理解できない、どうやって習得するのかも見当も付かないそれらのことがらを身につけて、当たり前にその力を行使していた。全知全能であるように見えた。

今は、そうでないことを知っている。彼らは私と同じ等身大の人間であって、私は必要とあらば彼らと同じ力を揮うことができる。まだ身につけていない分野は数多くあるけれども、それらをどうやって習得すればよいのか知っている。

そして彼らが構成する社会も構成物も。すべての仕組みは私と同じ人間が作り上げたものである。

■ 魔術について

子供の頃、経済システムは理解不能な魔術であった。どうやって富は循環し、私の処へお小遣いがやってくるのか。私は、それをリヴァイアサンの仕業であるかのように捉えていた。Win32APIは魔術であった。どうやってこの不思議な機能が実現されているのか、私は神に等しいマイクロソフトのなせる技であると理解していた。

今は、そうでないことを知っている。種々のネットワークプロトコル、スケジューリングアルゴリズム、ハードウェア制御、CPUの命令実行の仕組み、論理回路、トランジスタの原理、物語の祖、ウォーターフォールの由来、科学思想の発展に見られる形態、一般的な商慣習、贈与経済について、熱交換について、円運動とピストン運動の変換について、犯罪被害者の落ち度を探したくなる心理の由縁、を学んだ。見た。考えた。

どれも、人間が作ったものだった。理解を超えたものを何らかの超越的なブラックボックスに押しつけることはやめた。なるほど未知の分野であれば、それは今の私にとってブラックボックスではあるかもしれない。しかし、超越的な存在ではない。

■ 理解と支配と変革について

だから、すべては人間が作り上げたものなれば、必要であればそれを変革することができる。私が原理上理解しえないものはない。投資とリターンの問題だ。私の手持ちの資金と時間を鑑みて、十分な投資が可能であってリターンが望めるならば、理解し、変革すればよい。世の中に、私が普段意識しない、知りもしない仕組みはあるだろうが、それを改善する必要があるならば改善すればよい。必要であれば私は時間と資金を費やしてそれを理解できる。

私は現在、投資判断の下に「性同一性障害者の被抑圧構造」「東京を中心とするソフトウェア技術者のエコシステム」「Ruby」に時間と資金を注ぎ込んでいる。

要素が絡みあった複雑な問題を解決できる、ということを私は知っている。沢山の構成要素から成るカオスティックな問題に摂動を加えて制御できる、ということを私は知っている。曖昧な問題設定を具象化し解を導いていくことができる、ということを私は知っている。すべての要素が自明であってただ高度な抽象的思考が駆動するのを待っているだけの問題を、それが自明と思えるまで知性を尽くすことができる、ということを私は知っている。人間関係に分け入って整理し調整することができる、ということを私は知っている。

■ 環境について

だから、所与の環境などというものは存在しない。すべては、私が選択した、あるいはコストを評価して肯定したものだ。あるいは私が変革しつつあるものだ。それは私と同じ人間が作り上げたものなれば、私はそういった姿勢で接するのだ。

私は破壊者ではないから所与の環境をむやみに否定するものではない。けれども、環境を肯定することと、環境を所与のものとして自明視することは別である。自らの現実的な限界を知って投資判断することと、超越的なものの前にひれ伏すことは別である。環境を超越的ブラックボックスによる自明なものであると認識するのは、それはとても幼い振る舞いであると私は考える。子供の頃の私のように。

■ 思考について

子供の頃、疑問に思ったことがあった。天文学者が望遠鏡を受け入れるまでに、何故あんなに時間が掛かったのだろうと。望遠鏡を地上に向ければその機能は把握できるのだから、それを天体に外挿することは容易ではないかと考えた。だが、当時の人々にとって天界は神という超越的ブラックボックスの原理が支配するものであった。投げれば落下する定めにある地上の物体に対する発見を、虚空にあって規定の運動を永続する天体に適用するのは大きな論理の飛躍であったに違いない。天体と地上が同じ原理によって支配されているという発見こそがニュートンの功績であった、という。

かつての天文学者が木星系を信じられず、幼い日の私がそうした天文学者を理解できなかったのは何故か。思考の枠組み自体が異なっているのである。環境の由来を超越的な存在に求める発想は思考の枠組みを変容させる。今ある伝統、社会、システム、テクノロジーを自明視してその原理を超越者に委ねるならば、私たちは望遠鏡もなく恒星の固有運動など発見もできず、周点円の重なる天球に閉じこめられるだろう。

■ 可能性について

環境を超越者による所与のものと信仰するのは、ニュートン以前への先祖返りに他ならない。どんなシステムであれ、それは人間が作った同じ人間の原理によって成立している。だから、不合理を不合理のままにしておく必要はない。その認識に元に思考する方がいつでもより有益な結論を出せることだろう。

パンがなければパンを焼けばいいじゃない。小麦がなければ小麦が出回る社会を作ればいいじゃない。不作ならば農地を改善すればいいじゃない。農地がなければ開墾すればいいじゃない。労働力が足りなければ機械化すればいいじゃない。

gitをベースとしてsubversionと適宜組み合わせて使うような開発プラクティスがだいぶ貯まってきている。この辺りのノウハウの需要というのは意外にあるようで、今日もちょろっと喋った。

■ Git

gitは、『Pragmatic Version Control Using Git』の刊行が予定されていたりするし、いずれはより中心に近い人が「バイブル」みたいなのを書くこともあろう。でも、もうちょっと開発プロセスに寄った話のニーズはあるよな、と思う。今試行錯誤の中で自分なりに見いだして来ているもの、あるいは人から教わったもの、これらを体系化して実践に活かせる話としてまとめられたら素敵だなぁと思う。

以前に諸橋さんに「一緒にgit本書こうZE! (w」と言ったのも、まぁ、本当に書くかどうかは別としても何かしら体系化のきっかけになればと思ってのことだった。まぁ、案外なんかで実現するかもしれないし。

■ Ruby 1.9 Internal

RHGはやっぱり歴史に残る名著な訳だよね。実用されている言語処理系の一般プログラマ向け解説書というのはそうはない。大げさに言えばタネンバウム先生のOS本みたいなもんだ。

Rubyの新バージョンに対応した改訂版の予定がないのは非常に残念である。いろんな事情で、やっぱり難しいみたいに聞いている。

で、私は「RHGの逆襲」と題してRuby 1.9ソースコードリーディングの会を主催しているわけだけど、ここで得た知識をもっと還元したい。だとすると、どうせRHGの章立てに沿ってソースを読んでいるんだから、新しいRHGを作るっていうのは有りじゃないかな?

暇を見つけてぼちぼち書いてみたいなぁと思っている。ブログで小出しにしても良いし、どこかの開発者向けサイトに置かせて貰えるように頼んでも良いし。

■ この記事の趣旨

とまぁ、公言すると自分への圧力になるわけだ。そうすると、途中で投げ出さないでいつかはできあがるんじゃないかな、という仕組み。

コモンズマーカーというサービスが立ち上がった。私もyuguiアカウントを作ってある。

■ コモンズマーカーとは何か

様々な外部サイトに対してユーザーが「マーク」をため込んでいくという意味では確かにソーシャルブックマーク的だ。そして、ページ内にユーザーがコメントを書き込むという意味では以前いくつか立ち上がったWEB付箋紙サービスにも似ている。けれども、これはそれ以外の何かだ。

付箋紙サービスはまだ近いのだけれども、コモンズマーカーは付箋紙というアナロジーを捨てた。これは大きな飛躍である。対象文書の特定箇所にコメントを貼り付けるに当たって、当該箇所のまさにそこにコメントを配置するのが付箋紙である。だが、このやり方はstaticな紙媒体の制約下で当該箇所とコメントとの結びつきを示すのに必要であるに過ぎない。

コモンズマーカーの場合は、コメントは文書の右サイドに一列に表示される。従って、大量のコメントがついたとしても、ページが付箋で埋め尽くされるということがない。そして、当該箇所に対してそこの部分へのコメントたち、コメントに対して対象箇所、相互の対応関係を辿るのが容易であるように上手く動的な表現がもたらされるように設計されている。

コモンズマーカーをソーシャルブックマークと見なすのは愚かだ。確かに、一部の人々はこれまでソーシャルブックマークを「コモンズマーカーのように」使ってきた。だから、運営側はそういった人々の移行を促すために敢えて誤解を招くような物言いもするかもしれない。

でも、むしろ私はLUNARRとの相似を見る。そして、LUNARRがサイボウズの系譜に属する、「集約の元のコラボレート」を意図しているのに対して、コモンズマーカーは「分散しながらのコミュニケーション」である。乱暴な比喩で対応づけるならば、LUNARRがイントラネットでコモンズマーカーがインターネットだ。

■ 可能性

コモンズマーカーは付箋サービスの系譜と無関係ではないだろう。だが、付箋というアナロジーを捨ててUIを再設計した、ということによって使いやすくなった。従来ソーシャルブックマークサービスを無理矢理適用していたような用途に使えるようになった。そして。

このサービスの初の発表はRejectKaigi2008であった。その前夜に私は星さんからデモを見せてもらったのだが、とても興奮したのを覚えている。

残念な点を上げるとすれば特定人が付けたマークを提供するフィードがないこと、それからマークそれ自体に対するURIがないことである。これについては既に星さんに文句を言ってあって、近いうちに実装するという話だ。

フィードさえあれば、私はtwitterやはてなブックマークを利用していた発言の一部をもっぱらコモンズマーカーでするようになるだろう。Web上の特定のリソースを肴にみんなでtwitterでわいわい言い合うようなコミュニケーションはとても楽しいし、そこからしばしば有益な議論ができあがる。しかし、その肴としているリソースは後から発言を見た第三者にははっきりしないことがある。貴重な議論のコンテキストが、流れていってしまう。マーカー形式であればその問題は解消するだろう。とか。

twitterとはなんであったろうか。ミニブログと呼ぶのは簡単だが、それは、大量にfollowし合って利用しつくした人にしか分からない何かであった。そして、私たちはtwitterを通じて貴重な何かを得ることができた。同様にして、コモンズマーカーはソーシャルブックマークではない何かである。

自分が注目したURIを集積するだけなら今までもあった。自分が付けたコメントを集約できるだけなら今までもあった。ページ内にマーカーを引けるだけなら今までもあった。自他の発言を流してコミュニケーションするだけなら今までもあった。だが、違う。twitterやLUNARRを評価する系の人はコモンズマーカー使ってみたほうがいいよ。

コモンズマーカーとは何か。それは使い込んでみなければ本当には分からない。そして、一定の人数が参加してその真の価値が現れてくる。この手の「類似物の存在しないまったく新しい何か」にコストを費やすのはある種の賭であるが、twitterのときと同様に私は賭ける価値があると感じている。

私も、継続的な利用を通じて言葉にはできない使い分けの感覚を身につけたり、新しい使い方を発見したりすることだろう。おそらくはtwitter(またはその代替)、tumblr、blog、mixi、SBSと並んでコモンズマーカーを使うだろう。(とりあえずフィードが実装されれば!)

サミットに反対するデモの参加者が逮捕されたっぽい。何も言わないとこの逮捕を黙認することになってしまいそうなので反対しておく。

一体何が不満でサミットに反対するのやらデモ参加者の主張はわからない。が、とりあえず荷台に人が乗っていた件は前例を踏まえてきちんと事前に警察の許可を取っていたそうだし。道路使用許可を取っている以上はいかなる行為も、その許可の範囲を基準として逸脱性を判断されるべきであって、Youtubeに上がっている動画を見るにも、デモ参加者にそういった悪質な行為があったとは思えない。警察官に車が接触した件もどちらかといえば警察官が車に接触したように見える。

従って、警察が違法行為があった証拠を提示して正当性を主張しない限りにおいて、私はこのデモ参加者の逮捕は不当なものであったと判断する。証拠の提示があったらまた考える。

なんというか、自分が動物本を書くことになるとは思ってもみませんでした。大変名誉な、貴重な機会を頂いたものです。

さて、そうして『初めてのRuby』を出版したわけです。で、この出版を記念してジュンク堂書店池袋店でトークセッションをすることになりましした。

『JavaからRubyへ』の翻訳者の角谷さんと対談します。2人ともRubyが大好きな人間で、Rubyを実際に業務で活用してきていてしかも適用領域は全く異なるので、たぶん面白い話ができるんではないでしょうか。

On Fri, 4 Jul 2008 16:12:45 +0900, KOU Keiko wrote:

ジュンク堂書店池袋本店にてトークショーを
開催いたします。
著者のYuguiさんと、『JavaからRubyへ』の翻訳者である角谷信太郎さん
をお迎えして、「幸せなRuby生活に必要なこと」をテーマに、Rubyと
一緒に幸せに暮らすために知っておきたい知識や考え方、文化について
楽しく語っていただきます。
■『初めてのRuby』出版記念トーク
「幸せなRuby生活に必要なこと」
Yugui（著者） × 角谷信太郎（『JavaからRubyへ』翻訳者）
●2008年7月19日（土）18：30開場　19：00開演
会場：ジュンク堂書店　池袋本店　4Ｆ喫茶コーナー
入場料：1,000円（1ドリンク付き）　定員40名
●お申込：ジュンク堂書店池袋本店1Ｆサービスカウンター
お電話（03-5956-6111）でも7月4日18時よりご予約を承ります。 

キーサインパーティーの実施と効率的な身分証明書確認について考えてみた。

■ キーサインもらった

先日、日本Ruby会議2008の懇親会でPGP公開鍵に卜部さんのキーサインをもらった。キーににサインしてもらうのはこれが初めてで、今まで何のために公開鍵使ってたんだという話はある。「信頼の輪」に入ってなかったわけだからね。

PGPとか信頼の輪とかの話はOpenPGP作法(PDF)を参照。

ちなみに、私の公開鍵はpgp.nic.ad.jpに登録してあって、yugui.jpのメールアドレスで検索すると出てくる。fingerprintは"438F 411C FC0E 9589 A0E3 CC88 397C C7E4 92DB FC05"。新しいバージョンの名刺にはfingerprintを入れたから、比較的最近名刺を交換した人は見てもらうと裏に書いてある筈。

Rubyコミッタの認証には一応PGP公開鍵を使っていて、いざというときのオンラインの本人認証には「信頼の輪」が活躍するわけだ。だから、「コミッタは名刺にfingerpintを入れろ」とCommitterHowtoに書いてある。ま、普段はRubyistはもっとやることがルーズだけど、それでも厳密なセキュリティが必要な場面というのはあるわけだ。

■ キーサインパーティーしたい!

で、Rubyの人たちの間でもっとPGP署名を活用するために、今度の「日本Rubyの忘年会」か日本Ruby会議2009のときにでも、「日本Rubyのキーサインパーティー」をやりたいと思っている。前回の忘年会でも今回のRubyKaigiでも提案しようと思って忘れていたので、次回こそは!

ここで、どうやって効率的に本人確認をするか、という問題がある。公開鍵にキーサインをするというのは、「その公開鍵に対応する秘密鍵の持ち主がその人本人であることを、私が確認したことを保証する」って意味なわけだ。Debianみたいな開発者が世界中に散った開発プロジェクトの成果物をそれなりに信頼できるのは、こうして確認された「信頼の輪」によるものだ。各パッケージの開発者が全員「Debianコアメンバーの顔見知りの誰々の顔見知りである誰々」という風に実在の、トレースできる誰かであることが保証されているからだ。いい加減な確認でサインしてしまうとそこで「信頼の輪」が崩れるとか、自分が「いい加減なサインをする奴」ということで信頼を失うとかしかねない。

というわけで、キーサインするに当たってはその鍵を持っている人を、「国家もしくはそれに準じる組織による身分証明書」によって確認することになっている。私は自動車運転免許証を卜部さんにみせたし、卜部さんはパスポートを持ってきていた。なるほど、国際カンファレンスではパスポートのほうが確認してもらいやすくて良いんだろうな。慣れてるね。

■ 本題

Debianの過去ログを見ると、身分証明書確認のやり方が書いてある。「2列になって」と書いてあるのは、つまり二人ペアになって確認し、確認したら1つずつずれて、端の人は反対の列に移って、これで一周したら全員の身分証明書を確認しした、ということなのだろう。

Sassaman方式というらしい。O(n)だから、全員がごっちゃになってfingerprintを渡して確認してを個別にやる場合のO(n²)よりは効率がよい。

でも、n人のパーティーで確認するにはn回ずれる必要がある。もっと効率よくできないのか。そこでどうすれば良いのか3分くらい考えてみた。

■ 仮定

• Sassaman方式と同様に、事前にfingerprintと名前のリストを構築しておく。
  • したがってあとは、そこに居る人物と身分証明書が一致することを確認すればよい
• 1対1でなくても、mが十分に小さければ1対mの身分証明が可能。
  • 身分証明書片手に名乗ればよい。mが小さければ、証明書をはっきり見られし声も届くのでOK
  • で、m人が順番にそれをやればm×(m-1)パスの確認が終わる

そこで、m人組を作って相互確認し、それから組を攪拌した後にこれを繰り返す、ということを考える。

• 小さな素数pをとる。簡単のため、今パーティー参加者はp²人とする。
• p人組をp個作る。これらを第0組 .. 第(p-1)組とする。また各人には組内で一意な0 .. (p-1)の番号を与える。
• 各組で相互確認を行う
• その後、番号がjで、現在第i組にいる人は第(i+j) mod p組へ移動する
  • 繰り返す

これをp-1回行うと、全員が全員を確認したことになる。pは小さいのだからそれこそ列を作れば組み分けは容易だし、移動回数が少ない分だけ速いんじゃないかと思った。

が、が、実際にはどうだろう。

• 素数の2乗に足りない部分は欠落させておいても大丈夫そう
• だが、p人組内の確認は本当に速いのか?　これをほぽO(1)と見なせば良いんだが、実際にはO(p)だったりしないか?
  • だとすると、結局O(n) = O(p²)じゃないか。
• 操作が複雑な分だけ混乱を起こしそう
  • そこに不正な動きをする余地がある?
  • 互いに最初は信頼していなくても信頼の輪を広げられる、というのが趣旨だから不正を許すようでは意味がない?
• 仮定が成立する「十分小さいp」は精々が7じゃないかな?　だとすると、7×7=49で、オーダーを気にして複雑な操作をする意味があるか?

難しいね。と、3分ぐらい考えたことを書いてみた次第。このアイディア、絶対に既出で「捨てられた」ことがあると思う。公開鍵暗号を扱う人たちが巡回群を考えないわけないもん。

山なし落ちなし意味なし。