rfc2445 Draftの解釈

開発

えー、例えばWEEKLYでBYMONTHの制限がある場合のINTERVALの解釈のしかたがよくわからんのですよ。
とりあえず、


If multiple BYxxx rule parts are specified, then after evaluating
the specified FREQ and INTERVAL rule parts, the BYxxx rule parts
are applied to the current set of evaluated occurrences in the
following order: BYMONTH, BYWEEKNO, BYYEARDAY, BYMONTHDAY, BYDAY,
BYHOUR, BYMINUTE, BYSECOND and BYSETPOS; then COUNT and UNTIL are
evaluated.
とは書いてあるのですが、multipleじゃなかったらINTERVALが先に来ないのか、とかね、
わかんないわけですよ。

で、
DTSTART=20080709
FREQ=WEEKLY;BYMONTH=7,9;INTERVAL=3
だと、
7/10 ~ 7/13,7/28 ~ 7/31, 9/8 ~ 9/14, 9/29 ~ 9/30
でいいのか、あるいはLimitが先に効いて、
7/10 ~ 7/13,7/28 ~ 7/31, 9/15 ~ 9/21
になるんじゃないか、とか、考えてしまうわけですよ。exampleを見ても、比較的安全というか、常識的な範囲でしか書いてないし。

例えば、FREQ=MINUTELY;INTERVAL=17;BYMONTH=1,3,5,7,9とかだったりしたら、BYMONTHに該当しない月の分もずっと数えなきゃなんないわけでしょ。まあ、多分この解釈でいいんだろうけど。だったらそういう例を明示的に示してほしいわけですよ。
つか、multipleを抜いてくれ。たのむよ。

楽天ショップメルマガ

雑感

えー、リンクをクリックして1 ポイントもらう代わりに楽天ショップメルマガに登録される例のアレなんですが、あれって有効なんですかね?
あれって、目的はポイントな訳だから、とりあえず片っ端からリンクを踏むわけじゃないですか。そうすると、ショップメルマガがどっさりくるわけじゃないですか。で、メールをきちんと処理する人であればあるだけ、そのメールはかなり邪魔くさいものになると思うんですよね。そうなると、もうその手の楽天ショップメルマガのメールは見ないような処理をすると思うんですよね。
で、まぁスパムはスパムなりに1000通に1通反応があればいいということで、それなりに効果はあるのかもしれませんが、問題は、そんなのとは関係なく普通に情報提供を待っているショップのショップメルマガなんですよね。これが例のアレでくるメールと同じフォーマットなものだから、勢い必要である方のメルマガも見ないような処理をしてしまう。そうすると、買ってくれる可能性が高い顧客を店から離してしまう結果になるんじゃないかと思うんですよね。
自分だったら、メールをばらまいて捕まるお客よりも、以前ショップで買ってくれてまた買ってくれる可能性が高いお客を大事にするがなぁ。楽天的にはどうなんだろ。とにかく合法的スパムがばらまければ、それでいいのかしらん。

iPodにファイルが書き込まれなかった件の続き

生活

えー、NFSマウントした先のフォルダをiTunes Musicフォルダにした場合にiPodにファイルが転送できなかった件ですが、根本的に考え方の誤りがありました。iPodというより、iTunesがNFSマウントしたフォルダを正しく扱えなかったんですね。
そもそも、iTunes Musicフォルダを指定する際に、/Volumesからのパスが表示されずにマウントしたフォルダがルートディレクトリに指定されているのをおかしいと感じるべきだったんですね。どうやら、iTunesからは、/Volumesを認識しないようなんです。というか、マウントポイントを/mntや/NetworkやMacintosh HDの下にしても、/mntや/NetworkやMacintosh HDを無視してその下にあるフォルダ(のエイリアス)を一番上のフォルダとして認識するようなんですね。どうやら、Finderから通常操作で見えないフォルダは、iTunesからも見えない、という事のようで。
問題は、iTunesからは/Volumesの下にあるフォルダをルートディレクトリの下にあるフォルダと解釈しても問題なく/Volumesの下のファイルを探し出すのに対し、/Volumesの下のファイルを直接指定してiTunesにファイルの操作を指示するとiTunesがそのファイルを認識できない(パスが異なると判断するから)ということなんですね。
というわけで、解決方法。ディレクトリユーティリティでマウントする際、マウント先を直接ルートディレクトリの下に指定します。そうすると、iTunesの認識するパスと実際のパスとの間に齟齬がなくなり、正しく認識する、というわけなんですね。
しかし、AFPやSMBでのマウントは、iTunesからはルートディレクトリの下(というか、共有の下)と認識されるのに、NFSマウントはFinderから隠すようにしてるから、こーゆーワケワカンナイことが起きるわけで。例えばディレクトリユーティリティのオプションで、ファインダーから見る際は「ネットワーク」の下に見えるようにする、とかいうのがあればいいのに。

iPodにファイルがコピーできない件について

生活 Leopard

えーと、iPodを同期しようと接続すると、「iPodディスクへのコピーに失敗しました。ディスクから読み込んだり、ディスクに書き込むことができません。」というアラートが出力されました。
とりあえず、接続をしなおしたり、iPodをリセットしたり、iTunesを立ち上げなおしたり、iPodを復元したりといろいろやっていたのですが、どうにも解決しません。で、私のiTunes環境はちょっと特殊でして、nfsでマウントしているフォルダにiTunes Musicフォルダを置いているんですね。で、やっぱり原因はそこだよなー、とか思ってちょっと考えてみたのですが、思い当たる事がひとつだけありました。いままでディレクトリユーティリティでホスト名を直に指定してマウントしていたのですが、今日そのホストにmusicという別名をつけてマウントしなおしたんですね。Volumeの下に作られる名前が同じなんでほとんど気にしていなかったのですが、マウントしているフォルダでCmd-Iをすると、しっかり「サーバ名」が見えるようになっていて、こりゃ確かに異なるものと認識されるなぁ、と。
しょうがないんで、一回iTunes Musicフォルダをリセットしてから、再度iTunes Musicフォルダを指定して、ライブラリの作り直しですよ。
あ、そういえば、別のMacもホスト名を指定しなおしたんだった。この処理、結構時間がかかるのになぁ。前は四時間くらいかかってたはず。あーあ。

9/26追記
うまくいくはずだったんだけど、ダメだ。別名がダメなのか? 途中まで中途半端に出来ていただけに、原因がつかみにくい。最悪、Windowsマシンから使うようにするかな。

9/27追記
[id:ctrlb:20080927:1222476964]で、とりあえず解決。中途半端にうまく言っていたのは、始めはAFPでつないでいたからかな。

便座はそんなに汚いのか?

雑感

よく何かの汚さを表す基準として、便座よりも菌の数が多い、という比較の仕方を目にする事があるのだが、それははたして汚さを示す基準になり得るのだろうか? そもそも人間の皮膚上に菌があふれているわけだし、それは太ももも同様なわけで、便座に菌がつくのは当たり前。で、キーボードや買物のカートなんかも常に人間が触れているわけで、むしろ菌がいない方がおかしい。菌がいて当たり前の場所の菌の数を比較して、意味があるのだろうか。というか、そもそも菌が汚れである、という基準は正しいのだろうか?
もちろん経口摂取すればまずい菌はたくさんあるだろうけど、人間の皮膚から移った可能性が高い菌が、それほど有害なのだろうか?
ま、カートやキーボードや便座をすすんでなめたいとは思わないけどね。