ウイルス・スパイウェア検査・駆除 用ツール Dr.WEB CureIt! を無償配布中！
どうやら、 先日、Outbound Port 25 Blocking対応をした時に、 なにか設定に問題があって、配送サーバによっては 私からのメールが不正なメールとしてはねられているようだ。
具体的には日経BPなどにメールが届かない。
私自身と家族のところには届くので気付くのが遅れてしまった。
もし、「まつもとからの返事がないなあ」と思ったら もう一度尋ねてみてください。問題はそれへの対応が 届くかどうかよくわからないことだけど。
しかし、私からのメールが出て行かなくても、 (原稿提出以外は)あまり問題が起きないんだなあ。
自分の存在の小ささを感じる。
で、いきなり遅刻してしまい、ささだくんの発表の途中で到着。
今年は多い。が、去年の倍以上という気はしない。 やはり階段状になっている会場の構造のせいか。
今年はプロジェクタスクリーンがふたつになっていて、 片方はIRCに開放されていた。 今、まさに発表している内容にpublicにツッコめるのは 大変楽しいが(ニコニコ動画みたい)、発表者としては 予想外のタイミングで笑いが起きたりして当惑したりして やりにくい。
まあ、発表者よりも参加者が楽しむべきなので あるべき姿なのかもしれない。
で、午後イチは私の発表、「2007年とその先のRuby」。 まあ、ちょっと苦心した揚げ句の発表である。
でも、あんまりウケなかったなあ。 で、その時のスライドと同じもの。
というのも、発表直後に操作ミスかEmacs 22のバグかなにかで スライドデータを失ってしまい、後のセッションを聞きながら もう一度記憶とログに頼ってゼロからスライドを描き直したからだ。
だから、発表したものとは微妙に違うはず。
で、飛行機の時間の関係でTimの発表の途中で抜け出した。 ささだくんからは、あいさつするかと言われたが、 そんな恥ずかしいことはできないのでパス。
でも、会場の人みんなが、まつもとが途中で抜けたことに気づいたろうな。 ごめんよ。Timの発表にもいろいろとツッコミたいことがあったのだが、 それは別の機会に譲ろう。
で、がんばって帰る。米子便にすればもうちょっと遅くまでいれたけど、 体力的にしんどいし。
今年のRubyKaigiは特異であった、と思う。
手作り感があふれるという点では、 同じようにオープンソースソフトウェアを扱っていても LinuxWorldなどとは全然違う。あっちはビジネスショーだけど、 こっちはそんなに商売っけはない。
とはいえ、昨年のRubyKaigiや他のOSCのような ユーザが楽しくわいわいやるという雰囲気とも違う。 それはスポンサーセッションが開かれたり、 ビジネスについても開かれているということが 原因になっているのかもしれないし、 あるいはちゃんと仕事になる(私のキーノート中に挙手してもらったところによると 1/3はRuby (on Rails)を仕事にしている)という状況が参加者の意識に影響があったのかもしれない。
しかし、最大の原因はやはり非常に意識の高いボランティアスタッフと 会場にあふれた「Rubyへの愛」だろう。 かつてこれほど「愛」が語られたソフトウェアカンファレンスが日本で 開催されたことがあるだろうか(いや、ない)。
これはきっと「愛の力(The Power of Love)」なのだろう。
Railsではちゃんとした「Webアプリケーションが簡単」にできるのか、 という疑問提示。
事実としては
である。ただし、モデルの部分をがりがり書き換えるような複雑なWebアプリは やっぱりRailsでも危険性が残る。メンテしやすいのは利点だけど。
ほんとはここでtaint mode($SAFE=1)を使えば、 危険なデータは汚染されるから最低限のセキュリティチェックは 自動で行える(ので、PHPよりもずっとずっと安全)と書きたかったんだけど、 今調べたらRailsはtaint modeでは動かないんだって(だいぶ工夫しないと)。
これはRailsの不備といってもいいと思う。
せっかくのセキュリティ機能なんだし、デフォルトで活用してほしいなあ。
XMLの良いところ、10点。
ま、わからんでもないが、いずれも私に対してはそれほど訴求しない。
個人的にはRubyKaigiでTim Brayも指摘していた 「XMLはエンコーディングをいつも明示している」という点を挙げたい。 この点についてだけはXMLはYAMLやJSONよりもはるかに優れている。 いちおう「YAMLはかならずUTF-8」という規約があるようだが、 なかなか守れてないし。
文字エンコーディング明示以外で、XMLが優れている点:
HTTPによる流通を念頭に置いて仕様がデザインされている。
オリジナル文書の論理的な変更を伴わずに、他の名前空間からの修飾が可能。
潤沢な情報を含むXML文書を用途に応じてYAMLに変換したりHTMLに変換したり部分集合のみサマライズしたり…といったことは極めて容易だが、逆は不可能（したがって、あるXML文書の用途が複数ない時には、データ表現形式をXMLにすることの優位性は薄れる）。
ああ……一応PHPにもsafe_modeがありまして、
http://jp.php.net/manual/ja/features.safe-mode.functions.php
これがまたバグが多いらしいのですが、Rubyのはそうでもないんでしょうか。
単に$SAFEという状態があって、少なくともコアAPIではその状態に気をつかっている、というだけだと思っているのですが、そうなら双方の考えかたはだいたい同じなので、Rubyの$SAFEで安全になる範囲のことは、PHPのsafe_modeでも理論上は安全になるはずです。
この点においてPHPとRubyの安全性に大差はありません。
結局のところセキュアなコードがどうやって生み出されるかといえば、「いまコーディングしているインターフェイスを理解しろ！」(by Theo de Raadt@http://slashdot.jp/bsd/article.pl?sid=04/01/02/1655202&mode=nocomment)が全てでしょう。
むしろ$SAFEがなければコードを理解するだけでいいところ、$SAFEがあることでコードを理解する以外に状態を意識する必要があるようにも思うのですが。
PHPのsafe modeについては「使い物にならない」とか「PHP6ではなくす」とかいう「噂」しか聞いてないので、なんとも評価できません。
原理的には同じなのだと思いますが。Rubyの方はもう6,7年いろんなところで使われていますので($SAFE=1については)使えるレベルになっています(と信じたい)。
もちろん、あらゆるセキュリティ問題がtaintで検出できるわけはありませんが。
あと、$SAFE=4が「使い物になる」とは主張しません。たぶん、こっちは将来なくなります。
Theoの主張は理解できますが、残念ながら私はうっかりした人間なので、きちんと実践できる自信はありません。ので、ポカ検出は助かります。
また、Theoのやり方をきちんと実践できる人であれば、状態について考えなくても、taint検出に引っかからないはずですから、状態を意識する必要はないはずです。
そんな事より、Rubyでは「ちゃんとしたWebアプリケーション」が簡単にできるんだろうか、という方がずっと気になります。素のPHPとRailsを比較しても意味が無いような。フェアではない。
「素のRuby」や「Ruby+cgi.rb」なら「ちゃんとしたWebアプリ」を作るのはそれなりに難しいでしょうね。$SAFE=1の使用がPHPよりも一般的のようなので、少々安全度は高いでしょうが。
でも、少なくとも「RubyでのWebアプリ開発は初心者にも簡単」とは誰も主張してないので、私は問題にしてません。
問題にしているのは「本当は難しいことを(問題を解決することなく)簡単だと主張する態度」であって、PHPの特定の機能や性質ではありません。
この場合「フェアである(恐らく素のPHPと素のRubyを比較する？)」ことにどんな意味があるのか、私には理解できません。
私には言語とフレームワークを同じ位置で見ている事に、どんな意味があるのかが理解できません。
webアプリを作成するツールという観点からは十分比較可能だと思いますが。
まあ、理解できない(したくない)人がいてもしょうがないと思います。
比較することは私の主眼じゃないし。
私はPHPのsafe_modeを過大評価していたみたいです。ごめんなさい。
やはりというか、PHPのsafe_modeは使いものになりません。
safe_modeでもごく一部の関数に制限が加わるか無効になるだけです。evalとかケアされない危険な関数も多数あるように思います。
値とか変数が汚染されているかどうかを表せられるわけではないし、safe_modeの設定できる範囲に柔軟性がない。
safe_modeがObsoleteな機能とはいえ、Rubyのセキュリティモデルのほうが数倍は冴えたやりかたですね。
まあ、safe_mode以外にもあるようですけど
http://blog.ohgaki.net/index.php/yohgaki/2005/12/19/a_ra_sa_ya_oa_a_pamfcs_if_3a_ca_ra_oa_n
微妙。
ここで書く意味はないけど、しかしZendはPHP6をリリースしたあともPHP4をサポートし続けるつもりなんでしょうかね。
PHP5だけやめてPHP6とPHP4の2系統になったりして。