ical2caldav公開

iCalendar形式のカレンダーデータをCalDAVを使ってカレンダーサーバに突っ込むスクリプトを書きました。

ical2caldav-0.01.zip - ogawa - ical2caldav-0.01.zip - Google Code
ogawa - Revision 607: /trunk/ical2caldav

このスクリプトを使うと、iCalendar形式での出力に対応したカレンダーアプリケーションのデータを、簡単にGoogle Calendarに代表されるCalDAV対応のカレンダーサーバに統合できます。

応用的な使い方としては、サイボウズオフィスのカレンダーをcybozu2icalを使ってスクレイプし、そのデータをical2caldavを使ってGoogle Calendarに統合することもできます。

また、メールに添付されてきたiCal/vCalファイルをカレンダーサーバに自動的に追加する目的でも使えるでしょう。さまざまなイベントデータをカレンダーサーバに集約しやすくする（カレンダーサーバをwhiteboard的に使えるようにする）ことで、CalDAVクライアント(iCalやMozilla Sunbird)の利便性がより向上することを期待しています。

さて使い方ですが、config.yamlをこんな感じで書きます。

caldav_url: https://www.google.com/calendar/dav/calid/events/
caldav_user: user@gmail.com
caldav_passwd: password

calid (カレンダーID)の調べ方はCalDAV Developer's Guide - Google Calendar APIs and Tools - Google Codeの後半を読むと分かります。

あとはコマンドラインから以下のように呼び出します。

$ ical2caldav --filename /path/to/calendar.ics --conf /path/to/config.yaml

--filenameを省略すると標準入力から読み込みます。--confを省略するとスクリプトのあるディレクトリのconfig.yamlを読み込みます(多分)。以下は注意点。

• まだまだ不完全です。Google Calendarで試した限りでは、統合できるデータとそうでないデータがあります。
• iCalendarの各イベントにはUIDが必要です。UIDがないイベントは無視されます。
• 上のダイアグラムを見て「サイボウズのカレンダーがGoogle Calendarに同期できるんだー」と思ってしまう、うっかりさんのあなたは（きっと天使のような方なのでしょうが）思慮が足りません。きっと実生活で痛い目を見ます、もう見てるかも。例えば、サイボウズ上でイベントを削除してもGoogle Calendar上では反映されません。移動は反映されると思いますが。

Perlがどうもな、という人にはcurlコマンドをお勧めしておきます。

$ curl -H 'If-None-Match: *' -u user@gmail.com:passwd -X PUT -T calendar.ics \
  https://www.google.com/calendar/dav/calid/events/

ただし、この方法ではイベントを一件のみ含むiCalendarファイルしか登録できません。これに対してical2caldavは、iCalendarファイルを読み込んでイベントごとにiCalendarファイルを生成し、それを順次CalDAVにPUTするという操作を内部的に実行してくれます。

新生銀行のアンケートに答えたら商品券がもらえたよ！

昨年末に新生銀行のアンケートに答えたら3000円分の商品券がもらえた。いい銀行だね。アンケートにはこう答えておいた：

オンラインバンクのシステムがお粗末過ぎ！

アンケートに100文字くらいしか入力できないフォームを使うな！アフォか！

P.S. 新生銀行の新生に期待しております _o_

I18N Helper Plugin

ついでなんでOgawa::Buzz: MT-I18N PluginをMT 4.2用に書き直したプラグイン。

I18NHelper-0.10.zip

TagSupplementals Plugin 0.20公開

いろいろあって(？)、TagSupplementalsプラグインをアップデートしました。今回のアップデートは、MT3時代から引き摺ってきたコードを改めてモダンな(MT4の)プラグイン構成に準拠させることを主な目的としています。したがって機能追加はありません。今回のバージョンからMT 4.2以降のみをサポートします。

TagSupplementals - ogawa - Google Code

また、このバージョンではMemcachedを利用したときにmt:RelatedEntriesのレンダリング処理を高速化する機構が実装されています。具体的には共起行列をMemcached上にキャッシュして再利用するようにしています。この最適化による効果は以下の通り。

青と赤が以前のバージョンをMemcachedなし・ありで実行した場合の再構築時間、オレンジが今回のバージョンをMemcachedありで実行した場合の再構築時間です。13%くらい速くなっていることが分かります。もちろん、mt:RelatedEntriesのレンダリング単体だけ測ればもっとずっと速くなっているはずです。

mt:RelatedEntriesのレンダリング時間のみ計測したところによると、Memcachedを使わない場合は31.6秒、Memcachedを使う場合は25.7秒(旧バージョン)、16.0秒(新バージョン)。

他にも、ブログ記事を更新したり削除したりすることによってキャッシュに載っている共起行列の再計算が必要になった場合には、自動的に関連ブログ記事(つまり、タグを共有している記事)に対応するキャッシュを無効化するようにしています。

今後はこのコードベースを元に実用的な性能を実現に向けブラッシュアップしていきます。

ところで、このプラグインのmt:RelatedEntriesでやろうとしているのは、結局ものすごく単純で、オンラインで計算可能なRecommendation Engineなんですよね。本当はMT::Recommendableみたいなインタフェースだけ切っておいて、再構築時に計算してしまえるようなlight & poorなengineも、バッチジョブとして実行されるheavy & richなengineも実装できるようにするのがよいかもしれませんね。

今さらですがMTOS 4.23に乗り換えました

長らく使ってきたMT 3.21を捨てて、MTOS 4.23にとうとう乗り換えました。これで晴れてGPLなMTユーザの仲間入りです。

（相当カスタマイズして使ってきたので）苦行になるであろう移行作業の億劫さと、「MTOS使えやゴルァッ!!」的なことを言いながら旧バージョンを使い続ける後ろめたさ、のせめぎ合いをこれ以上はないというほど楽しませてもらいました（笑）

で早速なんですが、

MT 4.2xって超遅くね？よく使ってられるね？

特に全部スタティックに再構築するのにかかる時間が以前の環境に比べて2倍以上遅くなっています。

その責任の一端はTagSupplementalsプラグインにあります。TagSupplementalsプラグインのmt:RelatedEntriesブロックタグは、タグの共起行列をオンラインで生成するのでO(N²)の計算量が必要なのです。これに対して、tagwireプラグインはエントリーの保存時に計算を行っているので、再構築のオーバーヘッドがかなり抑えられています。いずれ何らかの形で対処するつもりです。

もう一つは、再構築の単位を定めるEntriesPerRebuildというディレクティブの意味が変わったせいというか、バグと解釈しても差し支えないような仕様が4.2あたりで導入されたせいです(changeset 1611)。

EntriesPerRebuildは、ブログ記事アーカイブの再構築する際に、セッションごとに処理するブログ記事数（デフォルトでは40）を指定するためのディレクティブですが、実はそれだけではありません。

月別ブログ記事リストを再構築する場合を例に挙げると、セッションごとに指定された個数のブログ記事に対応する月別ブログ記事リストを生成します。EntriesPerRebuildが40で、月20件のブログ記事を書いていたとすると、一セッションで平均2個ずつ月別ブログ記事リストが生成されるわけです^*1。3.x系の場合には、EntriesPerRebuildの10倍のブログ記事に対応する月別ブログ記事リストをセッションごとに生成していたので、平均20個ずつ生成されていました。いかに4.2になってからアーカイブの生成が非効率になったか分かるでしょう。

^*1 勘のいい人なら気がついたと思いますが、月40件を超えるブログ記事がある場合には、まったくアーカイブを生成しないセッションも発生します。

この問題は、EntriesPerRebuildの値を思い切って大きめに取ることで解決できます。私は400に設定し、かつMemcachedを併用することでまずまずの性能が得られています。

以下は手元の環境（本番機とは異なります）でこのブログを再構築するのにかかる時間を、EntriesPerRebuildを変えながら測定してプロットしたものです。

Rebuild times in MT 4.23 - Google ドキュメント

EntriesPerRebuildの増加による性能向上が400あたりで頭打ちになること、Memcachedを利用することで約50秒再構築時間が圧縮できることが分かるでしょう。ちなみに何も設定しない場合は206秒、EntriesPerRebuild 400でMemcachedを使った場合は101秒。再構築時間が半減できたことになります。

住宅ローンの抵当権抹消手続きをしました！

住宅ローンの抵当権抹消登記が完了したので、完済から登記完了までのまとめ。

1/1

ソニー銀行から借りていた住宅ローンを完済した。

休日だろうが元旦だろうが返済できるのはネット銀行ならではかもしれんね...。

1/5

「抵当権の抹消手続き自力でやる？こっちの司法書士にやらせてもいいけど？」というメールがソニー銀行から届いた。速攻で「自分でやる」と返信。「担当者が帰宅したので翌日連絡する」とすぐに返信があった。

1/6

「わかった。住宅ローン契約書と抵当権抹消済書類を自宅に送る。あと、もう忘れていると思うけど火災保険証書を借りパクしてる。うちと保険屋さんでうちうちに質権抹消手続きしてあとで返すから。」と返答がある。

ふーん。

1/8

ソニー銀行から重要そうな封筒が届いた。住宅ローン契約書、抵当権設定契約証書、抵当権抹消登記委任状、抵当権解除証書、代表者事項証明書、履歴事項一部証明書が入っていた。

配達記録郵便じゃなかった...。大丈夫なのか...。

1/10

休日を利用して、新不動産登記法の施行に伴う登記申請書等の様式について（お知らせ）にある抵当権抹消登記申込書の様式にしたがって申請書類を書いた。

面倒くさいけどしょうがないな...。

1/13

東京法務局世田谷出張所（松陰神社の目の前）におつかいに行った。世田谷線の松陰神社前で下車、モヤさまで少しだけ有名になった松陰神社通りを抜けて神社前を左折しててちてち歩くと左手に見つかる。世田谷出張所には、ざっくり言って1階に閲覧関係、2階に登記手続きと相談の窓口がある。

まずは、2階の不動産の相談窓口で申請書類に問題ないかチェックしてもらう。窓口のおばちゃんは割と親切だが、取り扱っている分野の性質上説明が分かりにくいきらいがあるので、よく分からない点があるならしつこく質問してクリアにしておくとよい。

書類に問題はなさそうなので、おばちゃんに言われた通り、1階に降りたところにある印紙屋で2,000円分(土地・建物分)の収入印紙を買う。次に1階閲覧ゾーン内のコピー機を使わせてもらって抵当権解除証書、代表者事項証明書、履歴事項一部証明書のコピーを取る(一枚30円)。そのまま2階に上がって、代表者事項証明書・履歴事項一部証明書のコピーに「原本に相違ありません」スタンプを押して署名・捺印することで、ただのコピーをオーソライズされたコピーにする。

あとは、もろもろの書類を持って登記受付の窓口に行くだけ。そこでも書類のチェックをしてもらって無事申請完了。1/19日には登記完了証を受け取れるらしい。

あともうちょっと...。

1/19

ふたたび世田谷出張所におつかい。こんどは真っ直ぐ2階の登記手続きの窓口に行って、登記完了証二通を受け取り、申請時に渡していた抵当権設定契約証書、代表者事項証明書、履歴事項一部証明書を返却してもらった。

代表者事項証明書、履歴事項一部証明書と登記完了証一通をソニー銀行に返送して、すべての手続きが完了した...ような気がした。

ε=＼＿〇ノﾋｬｯﾎｰｲ!!

1/27

東京海上日動火災から質権消滅済み火災保険証券が届いた。これでほんとにほんとの終了！これで火災保険は好きなように解約して再契約できるようになったわけだけど、このまま期限まで放置することに決定。

FeedBurner のフィードをGoogleアカウントに移行できるようになっていた

FeedBurnerがGoogleに買われたのは随分前のことですが、それ以降ろくに音沙汰がありませんでした。確かにAdSenseの広告を付加するフィードをfeed.proxy.google.comに配布してもらうというサービスはありましたが、これはFeedBurnerとは無関係のサービスだと言っていいでしょう。何やってんのかなあと感じだったのですがようやく動きがあったようです。

FeedBurnerにログインすると表示される「Move your account now」というリンクをたどっていくと、FeedBurnerで管理しているフィードをGoogleアカウント(Gmailなどのアカウント)に移行することができます（ちょっと時間がかかります）。

作業を終えると、

http://feeds.feedburner.com/hoge

というURLのフィードが、

http://feeds2.feedburner.com/hoge

というURLでアクセスできるようになります。これだけだとURLがちょっと変わっただけじゃんという気がするかもしれません。が、元々はChicagoにあるFeedBurnerのサーバからダウンロードしていたのが、GoogleのCDNからダウンロードすることになります。大違いです。

ちなみに古いURL（前者）から新しいURL（後者）へのリダイレクトは行われています。

$ HEAD -S http://feeds.feedburner.com/ogawa
HEAD http://feeds.feedburner.com/ogawa --> 302 Moved Temporarily
HEAD http://feeds2.feedburner.com/ogawa --> 200 OK
Cache-Control: private, max-age=0
Connection: Close
Date: Sun, 18 Jan 2009 05:26:10 GMT
ETag: x8PzcojvWFaouAcm+1mNGmUa3s8
Server: GFE/1.3
Content-Length: 0
Content-Type: text/xml; charset=utf-8
Expires: Sun, 18 Jan 2009 05:26:10 GMT
Last-Modified: Sat, 17 Jan 2009 19:28:32 GMT
Client-Date: Sun, 18 Jan 2009 05:26:11 GMT
Client-Peer: 209.85.173.118:80
Client-Response-Num: 1
X-Content-Type-Options: nosniff

また、いずれはどっちのURLをポイントしてもリダイレクトなしにGoogle CDNから配布されるようになるのではないかと私は思っています（根拠はありません）。つまり、移行作業を今したとしても、ブログのヘッダなどに書かれているフィードURLを慌てて変更する必要はないということです。個人的には、2月末までにChicagoのサーバで管理しているフィードはGoogleに完全に移行する予定（Transferring FeedBurner Accounts to Google Accounts FAQ - FeedBurner Help Center）ということなので、そのときに改めて判断すればいいんじゃないかと思っています。

さて移行が済むと、

Google FeedBurner

からGoogleアカウントでログインすることで、今までと同様FeedBurnerのサービスを設定することができます。それだけでなく、FeedBurnerのPROアカウントでしか使えなかったいくつかの機能がGoogle FeedBurnerでは使えるようになります。MyBrand機能はそのひとつで、フィードを自分のドメインで配布できるようになります。

実録・自動車の保有コスト(2000〜2007年)

私は一昨年の4月末にプジョー306を手放したのだけど、年間のコストはガソリン代・有料道路代を除いてこれくらいかかっていた。

実録・自動車の保有コスト(2000-2007) - Google ドキュメント

23区内(かつ山の手外)在住なら1800ccクラスの普通の乗用車で最低でもこのくらいのコストはベースとしてかかると思っていれば間違いない。駐車場代が月最大23,000円までで抑えられているのは、マンション付設の駐車場が使えるなどたまたまラッキーだったからであって通常はもっと駐車場代がかかるエリアの方が多い(念のため、2003年2月までは安く済んでいるのは川崎市在住だったからです)。実際今の自宅の近辺で駐車場を探すと屋外でも月35,000円〜という相場になる。まず経済的合理性はないね。

でも「保有することに合理性がないと考える人が多い」ということは、「レンタカーやタクシーに合理性があると考える人が多い」ということだよね。つまりは都心部ではそういうカテゴリーで競争力のある商品が勝つってだけのことだよね。それなら売れん売れんとぼやいてないでそういう商売をすればいいのに。そこそこ中高所得者層が多いエリアがあったとして、そこにレクサスショップを開店するくらいなら、同じ場所にレクサスレンタカーショップをチェーン展開した方が実入りが多くない？

VMwareの共有フォルダで「このゾーンからファイルを移動したり、コピーできるようにしますか?」

Ogawa::Buzz: VMware Fusion 2.0のミラーフォルダの設定の補足。

Windows XP SP3をVMwareのゲストOSとして利用しているとき、hgfsで共有しているホストのファイルシステム上のファイルをローカルファイルシステムにコピーしようとすると、いちいち「このゾーンからファイルを移動したり、コピーできるようにしますか?」と尋ねられて鬱陶しい。特にVMware Fusion 2.0のミラーフォルダ機能を使って、ホストのMac OS Xのファイルシステムをデスクトップやマイドキュメントにマッピングして使う場合には、このメッセージが出まくって閉口する。

この問題は割と簡単に解決できる。

まず、コントロールパネルの「インターネット オプション」を開いて、「セキュリティ」タブを選択し、「ローカル イントラネット」ゾーンを選択する。

「サイト(S)」をクリックすると、ローカル イントラネットゾーンに含めるサイトを定義するためのダイアログが表示される。

「イントラネットのネットワークを自動的に検出する」チェックボックスにはチェックを入れた状態で、「詳細設定(A)」をクリックする。すると、以下のようにイントラネットゾーンに加えるサイトを設定するためのダイアログが表示される。

「この Web サイトをゾーンに追加する(D)」の入力欄に「file://.host/」と入力して「追加(A)」する。

以上の設定をすると、「このゾーンからファイルを(ry」をもう見なくて済むようになる。

この作業の意味するところは結局、hgfsで共有しているファイルシステムはWindows VMからは「.host」という名前を持つ仮想的なCIFSサーバのファイルシステムとして見えるので、そのCIFSサーバリソースをイントラネットゾーンに加えることで信頼できるリソースであることを宣言した、ということに他ならない。もし別途sambaサーバなどのリソースも信頼させたい場合には同様の設定を追加すれば済む。Parallelsの詳細は知らないのだけど多分同じような設定が必要になるだろうと想像している。

追記: ググるとレジストリを変更する方法が紹介されているページがたくさん見つかるが、実質的にXP SP3のサンドボックス機構を無効化することになるのでお勧めできない。このエントリーで説明したように必要なドメインだけをイントラネットゾーンに公開するようにすべき。

住宅ローンを完済しました！

2003年の4月から返済していた住宅ローンを元旦付けで完済しました。

サマリーを毎年書く予定にしていたのですが、失念していました。まあ今となってはどうでもいいや、という感じですが。

Ogawa::Buzz: 住宅ローン 2003年度のサマリー

この時期に完済して手持ち現金を減らすのは利益機会を自ら放棄するようなもので我ながらうまくないなと思います。でも、もう、いくら繰り上げするかいつするかというような手持ち資産のエバリュエーションやハンドリングはうんざりだというのが正直なところです。

今月中に抵当権抹消手続きする予定です。