おまぬけ活動日誌

最近のツッコまれどころ

この日誌から Google してもらう


2003年07月18日(Fri) 昨日よりはいい天気 [同日]

湿度が高いかも。

[tDiary] お天気プラグインを設定プラグインに対応させてみました

設定画面のサンプル(そのうち消します)。実装はこれでいいのかな?

(追記) 6月中旬以前のadd_conf_procの無いtDiaryではプラグインのエラーが出て動かないかもしれません。お試しになる方は、今まで動いていたweather.rbをどこかにコピーしてからお試しください。もし動いた時はご一報いただけるとうれしいです。

(また追記)さっそく、halchanさんkosakaさんに使っていただいています。ありがとうございます。OKを押すとInternal Server Errorが出る…以前、IRCでどなたかがxreaでtDiaryを使っていて、Rubyのbegin周辺で、「unknown node type 0」というエラーが出ていたときに、beginの後に空行を加えると直ったとおっしゃってました。もしどこでエラーが出ているかわかれば、そこら辺に空行を加えることで直るかもしれません。

(もっと追記)手元でtDiaryを1.5.4に巻き戻して、weather.rbを入れた状態で、日記の更新と設定ができることを確認しました。少なくとも1.5.4以降をお使いの方は、ブラウザで設定する機能のあるweather.rbを使っていただけます。ブラウザからの設定のためには新しいtDiaryが必要ですが。

Creative Commons Licenseの賠償責任

バーチャルネット法律娘 真紀奈17歳さんのところから、クリエイティブ・コモンズ・ジャパンに動きがあったという記事。

残念ながら手元ではPDFの日本語が読めないのですが、Lenz教授「著作権とCreative Commons実施権」によると、Creative Commons Licenseでは、

その著作物が自分のものであり他人の著作物を侵害しているものではないということを表明し、保証する。そして、これに違反して第三者に損害が発生した場合、賠償の責任を負うとされている

とのことです。ホント?

試しにtDiary-users Projectに適用されているライセンスを斜め読みしてみると、

  • 5.a.ii: By offering the Work for public release under this License, Licensor represents and warrants that, to the best of Licensor's knowledge after reasonable inquiry: (i項を中略) The Work does not infringe the copyright, trademark, publicity rights, common law rights or any other right of any third party or constitute defamation, invasion of privacy or other tortious injury to any third party.
  • 6. EXCEPT TO THE EXTENT REQUIRED BY APPLICABLE LAW, AND EXCEPT FOR DAMAGES ARISING FROM LIABILITY TO A THIRD PARTY RESULTING FROM BREACH OF THE WARRANTIES IN SECTION 5, IN NO EVENT WILL LICENSOR BE LIABLE TO YOU ON ANY LEGAL THEORY FOR ANY SPECIAL, INCIDENTAL, CONSEQUENTIAL, PUNITIVE OR EXEMPLARY DAMAGES ARISING OUT OF THIS LICENSE OR THE USE OF THE WORK, EVEN IF LICENSOR HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

と書いてありました。(強調は筆者。)

うわー。

Wikiで責任を追うのは誰になるんだろう?どこかの閉鎖してしまったblogみたいな使い方は問題外として、Wikiに書く人は5.a.iiをちゃんと理解して、自分の書き込みによって万が一生まれてしまった6項の損害賠償責任をWiki運営者に代わって持つ覚悟が必要かもしれないですね。

この日誌にもCreative Commons Licenseをつけようかと思ってたのですが、もう少し真剣に考えよう。もちろん、このライセンスが無くたって、著作権の侵害をしていいわけではないのですが。

[Ruby] Rubyで呼ばれたメソッドが定義されていない時はmethod_missingが呼ばれる

refe method_missingより、

Object#method_missing
--- method_missing(name, args, ... )

    呼びだされたメソッドが定義されていなかった時、Ruby がこのメソッド
    を呼び出します。呼び出しに失敗したメソッドの名前 (Symbol) とそ
    の時の引数が name と arg ... に渡されます。

    デフォルトではこのメソッドは例外 NameError を発生させます。

tDiaryは勉強になるなあ。

[Ruby][tDiary] ruby-1.8.0とruby-1.6.7とではArray.joinの返り値が違う

手元でruby-1.8.0でtDiaryを見ようと思ったら動かんではないかい。 そういうわけで昨日のベンチマークは ぜんぜん正確ではない。キャッシュ消してなかったし。

調べてみると、Array.join()の挙動が変わったことがわかりました。 emptdiary_style.rb内で拡張文字列クラスを定義して、それをjoinして、 返り値に同じ拡張文字列クラスを期待しているのですが、 実際にはStringが返ってくるようです。具体的には以下のような感じ。

$ cat test.rb
class Mojiretsu < String; end
puts [ Mojiretsu.new( 'a' ), Mojiretsu.new( 'b' ) ].join( ',' ).class

$ ruby -v test.rb
ruby 1.6.7 (2002-03-01) [i586-linux]
Mojiretsu

$ /usr/local/ruby-1.8/bin/ruby -v test.rb
ruby 1.8.0 (2003-07-18) [i686-linux]
String

この部分の対策をして、emptdiary_style.rbをcommitしました。 ruby-1.8を使おうと思ったけどemptdiaryスタイルじゃ動かんやんけー、 という方はtDiary本体を更新してください。

[Ruby][tDiary] そういうわけでベンチマークやりなおし

テスト対象はこの日誌の7月14日分とほぼ同じデータです。 ちゃんとキャッシュを消して。

$ ruby -v
ruby 1.6.7 (2002-03-01) [i586-linux]
$ rm -f ../data/cache/{*.rb,*.parser*} ; echo date=20030714 | time ruby index.rb > /dev/null
1.85user 0.06system 0:01.92elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (665major+3115minor)pagefaults 0swaps
$ /usr/local/ruby-1.8/bin/ruby -v
ruby 1.8.0 (2003-07-18) [i686-linux]
$ rm -f ../data/cache/{*.rb,*.parser*} ; echo date=20030714 | time /usr/local/ruby-1.8/bin/ruby index.rb > /dev/null
1.47user 0.13system 0:01.60elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (740major+3993minor)pagefaults 0swaps

ふむ。userとsystemを合わせて1.6.7に比べて16%の増速でござる。 よかったよかった♪

[tDiary] disp_referrer2.rbはどれくらい遅いか

上と同じように、プラグインを出し入れして調べてみました。ruby-1.8.0で、今回はキャッシュの消去はしません。

00default.rbのみの場合
1.14user 0.04system 0:01.20elapsed 97%CPU
disp_referrer.rbを加えた場合
1.21user 0.06system 0:01.27elapsed 99%CPU
disp_referrer2.rbを加えた場合
0.60user 0.03system 0:00.66elapsed 95%CPU

ありー?素のreferer_of_today_longより速いってのはどういうことだろ?

じゃあ、1.6.7で。

00default.rbのみの場合
1.29user 0.11system 0:01.40elapsed 99%CPU
30386 bytes
disp_referrer.rbを加えた場合
1.50user 0.06system 0:01.56elapsed 99%CPU
30387 bytes
disp_referrer2.rbを加えた場合
0.80user 0.11system 0:00.91elapsed 99%CPU
31249 bytes

おかしいなー。生成する文字数が効いてるのだろうか? 上にwc -cの結果を追加してみよう…文字数はだいたい一緒みたいだ。

とにかく、手元ではdisp_referrer2.rbは 素のreferer_of_today_longよりも激速という結果になっちゃいました…。

…おかしい。

[tDiary] どうしてdisp_referrer2.rbは速いのか?

-rprofileした結果を整理してみました。1.8.0です。 特長的な部分だけ (プラグインの有無でcall回数が大きく違うように見えるcallだけ) 抜きだしてみます。 メソッド名の横の数字はcall回数です。

nametotal ms/call00defaultのみdisp_referrer.rbdisp_refrrer2.rbも
cumlative sec-7.8321.7811.13
Array#each133.72126126172
TDiary::DiaryBase.disp_referer78.14100100142
Array#sort!23.33006
Array#collect18.3111014
TDiary::Config#charset13.33030
String#%3.000010
Class#new1.460200974804
String#scan1.250024
CGI#escapeHTML1.07202202244
String#gsub!0.760200284
CGI#unescape0.6910200
String#strip0.5600107
Array#unshift0.490610
Regexp#initialize0.130200354710
Regexp#=~0.100200334885

ふーむん。profileを取った時は、素のtDiaryの方が速かった模様。 disp_referrer.rbと比べると、 Class#new、Array.unshift、Regexp#initialize、また、 Regexp#=~で得をしてるようです。Class#newって何やってるんだろう? 一方、Array#each、sort!、collect、String#gsub!あたりは call当たりの時間がかかるのに、disp_referrer2.rbで多用されている。

そのうちソースを見て改善できるところは改善してみよう。

本日のツッコミ(全1件) [ツッコミを入れる]
> halchan's diary (2003年07月17日(Thu) 21:31)

早速使っていますが、今の所は問題なしです。<br>[TrackBack from http://www.halchan.org/diary/20030718.html]


作り手とその取り巻きだけが楽しんでる間は本物じゃない。その中身が理解できない人々の生活を変えてこそ本物だ


zunda <zunda at freeshell.org>