val it: α → α = fun

というわけで、しばらく Google Desktop for Mac を使ってみている。使っているとそれなりに快適ではある。

ただし、インデックス化をしているときはけっこう処理が重い。これはまあ仕方ないところはあるのだけれど。とはいえ、新しいファイルをインデックスにつっこむ処理はいつやられているのか知らないが、それほど時間がかかるわけではなく、起動しているときはそれほど処理の重さに悩まされることはない。あと、手動で(つまり、自分の好きなタイミングで)インデックスに特定のファイルを入れるようなコマンドラインツール(mdimport みたいなもの)がない。

ただ、どうも印象としてだが、マシンが起動するたびに、ちょっと重いインデックス化処理をやっているようだ。据置き型のマシンで電源入れっぱなしという Mac しか想定していないのかも。わたしのはノートで、わりと頻繁に電源を落とすから、起動するとしばらく重いというのは、ちょっとつらい。これが一番問題かな、個人的には。

ほかの雑感。

メールは、 Mail.app のデータしか検索してくれないようだ。わたしは Wanderlust を使っているけど、さすがに elmo のキャッシュはインデックスのなかにはないらしい。拡張子が重要なのかな？　まあ、これは spotlight も同じ。

一部のディレクトリはインデックスにつっこんでほしくない、というのがあるような気がする。たとえば /opt/local/var/db あたり。こういうカスタマイズはできない。もっとも /Application とかはデータに入れていないようで、それなりのことはしているのだろうが。まあ、これも spotlight もできないか。

パスといえば、特定のパスの下だけ検索したいケースというのもあると思うけど、これもできないのかな。まあ、全文検索でそれは面倒だし、パス名を検索クエリに混ぜればできるだろう。どっちみち spotlight でもできないから同じ。

最後に、日本語の処理が甘い。どうもパースとかはまったくしてなくて、文字単位で分解してクエリに与えているようだ。あーと、これはどういうことかというと、つまり、そうだな、たとえば「雑感」というクエリを与えると「雑誌を見てみた感じでは……」みたいな文章にもひっかかってしまうのね。ちょっとこれはしょぼいかな。

うーん、ただ、まあ、こういった印象よりは「起動するたびに重いインデックス化処理を走らせてねえ？」疑惑が一番大きいですかね。でもまあ、はじめて触ってみてあまりの重さのあまりにすぐ消したときに比べると、ずいぶん便利なツールになっているという印象で、あのときに悪印象を持った人は、いずれ試してみるといいんじゃないかと思いました。

追記: 案の定というかなんというか、ツッコミが入りましたので
リンクしておきます。ようするに「特定のパスをインデックスから除くことは現状で可能(Google Desktop でも可能だった)」「特定のパスの下だけ検索するのは Spotlight なら可能、 Google Desktop で可能かどうかはわからん」ということです。おわびのうえ訂正いたします。

ところで前々から思っているのだが、「冥王星」の「降格」という表現について、(欧米は知らないが)日本で感情的な反応が巻き起こるのは、「冥王星」というカッコイイ名称にもあると思うのだ。「天王星」「海王星」「冥王星」、うん、なんか通りがいいじゃない。このなかで冥王星だけが仲間外れと言われても、なんだかしっくりとこない。

つまりなんだ、野尻抱影の命名がロマンチックすぎた、という非難なのかこれは。わからんが。

なんとなくだが、名前に縛られるということはあるのではないだろうか。 pluto もローマ神話だが、学術的な人々はさておき、一般の人々にはそういうことが極めて重要なのかもしれないと思わないでもない。「降格」という単語が使われたりする情緒的な反応には、そういう面もあるんじゃないだろうか。

まあ、しょせんは結果論の妄想だけれど。

ところで、実はこの歳になるまで知らなかったが、天王星とか海王星という名称は中国での訳が先にあって、それが日本に移入されてきたのだそうである。なかなかカッコイイ名前だと思っていたのだが、なるほど納得。

ついでに、↑のようなことを mixi 日記に書きちらしたところ教えてもらったのだが、中国ではもちろん、発見された準惑星にも漢字の名前が割り当てられている。なかには塞德娜(セドナ)のような音訳もあるのだが、同じような意訳もあって、たとえば

まとまった文章を書く気力が、いまちょっとない。

某メーリングリストからスパムがいっせいに届いた。管理者が止めるように頑張っていたらしいのだけど、数日前、なぜかいっせいに。なんだろうね、留めておいたのが誤って放出されちゃった感じ？→削除前のメールボックス

まあ、面白かったのでついキャプチャしちゃったんですが、これの責任を追求したいとかいうことは別に目的じゃなくて。いやまあ、こんだけスパムが来るというのもひさびさでびっくりしちゃったというのもありますが。

わたしはいま、ベイジアンフィルタみたいなタイプのコンテンツフィルタリングはまったくやっていない。対策は Rgrey だけだ。これまでもこの日記で何度か紹介したけど、効果は劇的といっていいくらいで、スパムはほとんどこない。日に数通くらいかな。わるくない成績だと思う。

Rgrey を適用する前は、これは賢いスパマーには効果がない手法じゃないか、とわたしは思っていた。ようは、つまんないスパムは減るけど、賢い業者のめんどくさいスパムは残るんじゃないのー？と。ところが、面白いことに実際は逆だ。これ、ほんとうはスパム業者の利益になりそうなのであんまり日記に書きたくはないのだけれど。 Rgrey が採用している greylisting というののそもそもの考え方は、「エラーコードとして一時的なエラーを返し、再送してきたら受け付ける」という方式だ。まともなメールサーバは一時的なエラーに対処するコードがあるけれど、スパマーはダイレクトに送信してきて、エラーが起きるようなホストにちんたら再送なんかしてらんないのでフィルタリングできる。

実際に greylisting をくぐりぬけるスパム、というのは実際にはそれほど多くはないが、ないこともない。で、そういうスパマーが何をしているかというと、これはまあ推測でしかないんだけど、同じメールを何度も送ってるんじゃないかと思うんだな。リストがきちんと整理されていないのか、ほかの理由なのかはよくわからないのだけど、そうなると2通目の送信が再送かどうかというのの判断はしづらいもので、受理してしまう。たぶんそういうことだと思っている。つまり、賢いスパマーはいちどでもエラーになると、それに対応してくれるのでスパムはこなくなるんだけど、愚直に何度も送信してくるスパマーには無力なのだ。

とはいえ、実際にはそういうスパムはそれほど多くない。再送要求に対して、あまりにも早く再送したらはねられるし、遅すぎても無効化されちゃうから、届いちゃうやつというのは本当にたまたまなんだろう。結局やってくるスパムとして大勢を占めるのは greylisting が効かないタイプのものだ。上のようにメーリングリストが配信してしまうケースはその典型例。ほかにも、たとえばわたしの場合、仕事でとあるアドレスから転送されてくるメールがあるんだけど、これの9割がスパムだったりする。こういう場合、直近の配信元や転送元は妥当なホストだから自前のサーバではどうにも対処のしようがない。メーリングリストならば管理者に「もっと厳しくしてください」と言えるかもしれないけれど(というかいまどきメンバー以外に送信可能な設定というのはいただけないと個人的には思うが)、転送なんかはもうほんとにどうしようもないわけだし。

そもそも、 greylisting という考え方そのものが、こういうメーリングリスト配信や転送とは相容れない方式なんだろうな。中継するものが間に挟まると、再送のしようがないから。この考え方だけでスパムと戦うには、すべてのメールサーバがスパムに厳しい対応を取るようにする必要があるわけだが、それは極端な理想論に過ぎない。

さて、どうすればいいのだろうか。わたしには案はない。ないというか、コンテンツフィルタリングしかねえんじゃねえの？と思うのだけど、さてはて。

4月のリリースのときにさっそくインストールして、あまりの重さに辟易して削除した Google Desktop for Mac ですが、ふとあれからどうなったかなあ、と見に行ってみたところ、5月末くらいにバージョンが上がっていたらしい。

恐る恐る入れてみたけど、やっぱりインデクシングが止まらない点は変わらず。いったいこの「initial indexing」というのは終了しうるのだろうか。「Initial index update in progress. 433,834 items indexed.」だそうで、余計なものまでインデックスしてんじゃないかなあという疑惑が……。

ただ、理由不明であれだけ無茶苦茶重かったのがかなり改善されている。ような気がする。もちろん、まったくないときに比べると一部の処理がじゃっかん重くなったような気はするものの、ふつうに許容範囲内になっているな。

spotlight があるのになんでこんなモノを入れなければならんのだ、というのが常識的な感想とはいえ、これくらいならしばらくは入れといてもバチは当たらんのではないでしょーか、という感じに仕上がっているように思います。しばらくこのまま生活してみますよ。

ま、どっちみち spotlight ってあんまり使ってないんで、しばらく生活していても特に何もないかもしれませんけれども。

追記: インストールを試みたのは実は昨晩のことで、その後えんえんと一夜かけてインデクシングをしていて↑を書いた段階では止まっていなかったのだが、さきほど(夕刻ころ)ふと見てみたら、70万余というファイル数で初期インデクシングが終了していた。この辺の処理は、以前と比べると格段に良くなっている、のかも。

あと、どうせもともと spotlight はぜんぜん使っていない(Mail.appも使っていない)し、 Google Desktop for Mac を使うというコンテキストではムダっぽいので、試みに mdimport を止めて利用みることにした。ちなみにいちおう書いておくと、 mdimport は spotlight のインデックスにデータを突っ込む作業を受け持ってるデーモンで、ふつうにやっているといつも起動している(ユーザコマンドとしても存在していて、ターミナルから叩けば明示的にDBへのインポートを促すのもできる)。で、動かすのをやめるには /etc/hostconfig にある SPOTLIGHT=-YES- を -NO- に変更すればいい。らしい。今のところ、以前に書いたような重さは特に感じられない、ような気がする。

http://www.fritolay.co.jp/gekikaramania/index.html

昨夜、コンビニでたまたま見かけて買ってみた品。かなり本気で辛い。暴君ハバネロとかと違って、辛さのほかにも味があり、それがまたウマいし、その味によって辛さが引き立つ印象なのと、かなり舌や喉の奥に辛さが残る雰囲気がヨイ。

しかし、一人で食べるときは気をつけた方がいいでしょう。かなりしんどくて、わたしも半分ほど食ったときに「残りは後日にしようかな」とちらっと思いました。けっきょくぜんぶ一人で食べたけど。

ビールのおつまみとかに最適とか書いてあるけど本当か。かなり本気で辛いが、辛いものを食べるときに水を飲んではいけないの法則が発動してエライことになるんじゃないかなあという気もする。

うむ、わりとオススメです、辛いのが好きな人には。

この日記(ブログ)は100%わたしが自分で書いたシステムとなっていて、あれこれ綻びもあるんだけど、メリットのひとつとしては、既存のシステムと違うので単純なツールを使ったスパムに(たぶん)強いだろう、ってのがあります。コメントスパムはいまんとこないしねえ、とかそんな風。

というわけでのんきに構えていたんですが(実際には最初に作成したときには過剰にスパムを恐れて承認制のメカニズムを実装したんだけど、ふと我にかえってこんな仕組みは必要ないと外して特にスパム対策もなく使っていたんですが)、ついにというかようやくというか、トラックバックスパムが凄い勢いで来てました。どうやってか知らないけどスパマーのリストに当該日記のトラックバックURLが登録されたのだろう、特定のエントリーに対してだけ、凄い勢いでいろんなサイトから、いろんなURLのトラックバックが押し寄せる(といっても大した量ではない)。

さてどうしよう。

トラックバックURLを変更するのが対処法としては一番楽なんだけど、そんな対症療法ではきっとうまく行かない。 URL もリクエストするホストの範囲も非常に広大で、単純なブラックリストでは役に立たないようだ。コメントとちがって、 excerpt も大してヒントにはならないし、リンクがあるかどうか調べるのは面倒くさいのでやりたくない(笑)。

ふと思いついたのだが、(すくなくとも今回の)スパマーはボットネットか何かのツールで送りつけているらしい。つまり、 sender も不特定多数のホストだし、リンク先のURLも不特定多数だ。ということは、 S25R 的な手法が使えるかもしれない。つまり、

なりました。

立方数になるチャンスはまだ残されていますが、ふつうに考えると完全数はおそらくこれで最後でしょう。よく生きたいと思います。

Mac の JDK は性能が出ないってことかなあ？

先方へのコメントには test/fib.rb って書いたんですが、 samples には fib.rb というファイルは(私のアーカイブには)なかったのでカンチガイでした。とまれ、この test/fib.rb というプログラムを実行させてみました。その前に簡単に説明すると、 test/fib.rb では、再帰ではなく逐次的計算でフィボナッチ数を計算しています。でも通常のループではなく末尾再帰的に計算しているため、そのうちスタックが溢れてしまうと。じゃ、どれくらいのデカい引数ならスタックが溢れますか、というのを SystemStackError で検知して、二分探索的に調べるとまあ、そういうプログラムのようです。

% bin/jruby test/fib.rb Estimating max fib recursion. This will be slightly lower than actual. good: 1 good: 2 good: 4 (snip) bad: 14849 17.675000 0.000000 17.675000 ( 17.617000) % ruby test/fib.rb Estimating max fib recursion. This will be slightly lower than actual. good: 1 good: 2 good: 4 (snip) good: 6391 0.370000 0.020000 0.390000 ( 0.397956) % /usr/local/ruby-1.9/bin/ruby19 test/fib.rb Estimating max fib recursion. This will be slightly lower than actual. good: 1 good: 2 good: 4 (snip) good: 6225 0.160000 0.010000 0.170000 ( 0.166586)

ガーン、スタックの大きさが違う。

この fib.rb というのは、フィボナッチ数を(再帰的ではなく繰り返しによって)計算しますが、再帰しているので巨大な場合はスタックを食い潰す、ということでどれくらい深く再帰できるかを二分探索的に調べている方式です。あれっ、 ruby1.9 って末尾再帰の最適化をしていないのかな？

まあいいや。

そういうわけでやっぱり JRuby が猛烈に遅いのですね。 JDK のせいなのかなあ。

ほかにも test/bench の下にフィボナッチ数の計算を逐次的にやる版や再帰的にやる版のベンチマークもありました。これも JRuby の方が若干遅いのですが、面白いことに逐次的計算の場合、 ruby 1.8.6 と ruby 1.9.0 は大差ない性能になっていました。

ところで前回、結論めいたことを書こうかどうしようか迷ったのですが、そうしているうちに keisuken さんに書かれてしまいました。実はわたしも、パフォーマンスには大した問題はないと思っています。いや、少し違うかな、速いならそれにこしたことはないのですが、ほかにも重要なことっていっぱいあるでしょう。というか、 Ruby は(Rubyistは)これまで散々遅い遅いと揶揄されてきていて、そこで「それよりももっと重要なことがある」という開き直りをしてきたわけです。自分より遅い処理系が出てきたからといって態度を変えるべきではない。

JRuby には JRuby のメリットがあるわけで、きちんとそういう点を評価をするべきではないかなーと思います。べつに遅くったっていいでしょう。でも国内のメディアでは「本家Rubyよりも速い」という触れ込みが効いている気がするんですよね。上みたいな極端な速度差はともかく、実際には大差ないんじゃないかと思うのだけど、どうなのかなあと。

ところで、マイコミジャーナルのOpenOffice のマクロを groovy で書くという記事を読んだら「誰か JRuby でもやってくんないかなー」と思ったり(他力本願)。

JRuby と cRuby、それに YARV(ruby-1.9)の比較についてちょろっと書いてから RubyKaigi のページを見たら、速報ログのJRubyの講演にこんなことが書いてあった。