1  Amazon.com: Customer Discussions: No more post-order price matching!?!?

米国Amazon.comには、「購入処理から30日以内に値下がりした場合、自己申請によって1度に限り、購入金額から値下がった分の差額を購入者に返還する」と言うことが出来る。いや、出来た。

Only orders placed before September 1, 2008 are eligible for a price difference refund under the Post-Order Price Guarantee policy. As of September 1, 2008 we are no longer offering discounts if prices change on our website after you make a purchase."Amazon Dropping Post-Order Price Guarantee Effective Sept 1st - SlickDeals.net Forums

これを信じる限り、その手続きが9月1日以降は廃止されるらしい。あらら。Amazon.com: Help>Payment, Pricing & Promotions>Pricingに過去にあったその旨の記載が確かになくなっている。

Amazon.com の値段は結構変動が激しいので、あまり頑張って底値を見極めて買わなくても、購入直後に大きく値下がりして泣くということがないこの制度は、精神安定的には結構良かったんだけど、ちょっと残念。

1  家族や実家との情報共有やコミュニケーションに使っているWeb・ネットサービス

うちの夫婦は元々二人ともPCの前に長時間滞在していることが多いので、PC上で情報共有するようなツールは結構重宝している。 最近になって米国に住みはじめたこともあり、距離を問わないインターネット越しのサービスはありがたい。最近使っているのはこんな感じ。

Google Calendar
互いの飲み会予定や外出予定、訪問者の予定などを共有するのに重宝している。 共同編集可能なカレンダーを作れるのが便利。

1. 自分のカレンダー (私が編集可、妻が閲覧可)
2. 妻のカレンダー (妻が編集可、私が閲覧可)
3. 家のカレンダー (私と妻が閲覧・編集可)

こんな感じで数種のカレンダーを共有している。こうした予定は口頭でもやりとりするが、何日の何時だったかは聞いても結構忘れるので、後から確認できる手段があるのはなにかと楽。それと旅行イベントを入れておくとそれに向けてなんとなく盛り上がったりする。
ちなみに職場はOutlook/Exchangeなのでそちらとは全く別管理にしている。

Zenbe lists
Todoリスト、特に買い物リストを共有したくて色々と探していたが、妻が iPhone を買ったのを契機に使い始めてみる。無料のiPhone専用アプリ Zenbe Lists の方はボタン一つで同期が完了するし、WebインターフェイスはAjaxでそこそこ快適。リストの共有がURLを送りつけるだけなので認証などはちと不安だが、買い物リスト程度ならさほどリスクもあるまい。
惜しむべくはPalmのWebブラウザからまともに使えないことか。専用アプリとまでは言わないが、できればモバイルデバイス用ページを用意してほしいところだ。

ちなみに Zenbe と言うサービスは Todo List 以外にもWebメールやカレンダー、その他Webサービスとの連携機能を提供しているようだ。ちなみにRTMでも良かったんだけど、iPhoneとの連携にProアカウントが必要だったのでやめといた。

Skype
言わずと知れた無料VoIPソフト。出国前に互いの実家PCにマイクとカメラを仕掛けてアカウントの登録まで済ませ、日本にいる間に通話テストまでしてきた。
とは言えPCを立ち上げたり USB カメラを抜き差しする度に「Skype音声入力元」を設定で変更しなければならなかったりと分かりにくい部分があり、さほど積極的に使われている感じではない。それでもこちらから SkypeOut で安価に日本に電話したりするのには十分役立っている。

Youtube, Picasa Web Albums
夫婦間のファイル共有は自宅のLinux/Sambaや mt-daapd なのだが、撮った動画や画像を友達に見せたい時に、ユーザ限定公開しておいて先方で見せるというのにはこのあたりを使っている。 Picasa の方はパスワード付URLで共有できるので相手側にアカウントが必要なく、アクセス制御と言う意味では難があるものの、より手軽ではある。 世間一般に公開するものは Flickr を利用中。

del.icio.us
for:username で相手にbookmarkを送ったりもできるがその機能はあまり使っておらず、基本的には私が一方的に妻のbookmark rssを購読するだけになっている。

Amazon wishlist
時々送りつけられてくる。

IRC
最近はあまり夫婦でPRIVと言うのはしなくなったけど、隣のPCにURLを送るなんて用事には未だに役立ってる。IM代わりといったところ。

1  政府認証基盤(GPKI)

引越しをしてしばらく経ったし、オンラインで在留届を出そうと思って外務省のサイトにアクセスし、入力ページに移動してみると、Firefox3 が例によってオレオレ証明書警告を出してきた。

政府機関なのによろしくないなと思ったが、よく見てみると、政府認証基盤(GPKI) と言う日本政府共通の認証局を利用したものらしい。 証明書の取得方法では、きちんと『自己署名証明書をフィンガープリントを確認してからインストールするように』という方法が記載されている。

それではと自己署名証明書をダウンロードしようとするが、このダウンロードの https サイト自体が自己署名証明書である。ではまぁ書かれている通りにフィンガープリントを確認すればいいのかとフィンガープリントの確認ページを開くが... これも同じドメインであり自己署名証明書サイト。 これ、いったいどこでこの証明書・フィンガープリントの妥当性を確認すればいいんだろう…。

しかしどこかで聞いたことがあるような気がしてググッて見ると、正しく例によって 2002年には類型の問題が 高木浩光氏のレポートで指摘されている。 せめて fingerprint だけでもブラウザ標準の証明書でサインされたSSLサイトで配布するなり、もしくはブラウザに最初からインストールするようには出来ないんだろうか。

1  twitlogger.rb 更新

Twitter のタイムラインログ記録スクリプト twitlogger.rb の更新。ダウンロードは前回記事、ないし twitlogger.rb より。

変更内容としては、since=... の時刻を「前回取得したタイムライン中の最新更新時刻」にしてもまだ取りこぼしが出るケースがあるようなので、since の時刻に since_margin と言うパラメータでマージンを与えた上で取得したタイムラインがログ上で重複しないような処理を入れた。狭間の取りこぼしが気になる人はこの値を適当な秒数、例えば 30 くらいにしてみると少しマシになるかもしれない。

正直なところ個人的には「取りこぼし無く取得しよう」と言うモチベーションは高くないし、Twitter API 自体がよくエラーを吐いたりおかしなタイムラインを返したりするので、あくまで出来る限りの努力をするというスタンスで。

1  twitlogger.rb 更新

少し前に書いた twitter のログ取りツール twitlogger.rb を走らせているが、どうも timeline の取得に抜けがよく発生していた。見てみたら 304 Not Modified エラーが頻発していたようだ。恐らくこれは API に since=... の形で送信している前回取得時刻がよろしくないのだろうと思い、現状の「前回取得時刻」から「前回取得した timeline の created から最新時刻のもの」を送るようにように修正。修正後に数時間走らせてみた感じでは取りこぼしは無くなった。

どうも API で取得できるタイムラインは「現在時刻の数分前」程度な事があるようで(DBレプリケーションの都合?)、単純に前回取得した時刻を since で投げてしまうと 304 Not modified エラーが結構な頻度で発生してしまうみたい。修正したものは前記事、ないし twitlogger.rb からどうぞ。これも近いうちに CodeRepos に置く予定。

1  mixi2gmail.rb

少し前から mixi のちょこちょこした変更もあって以前書いたmixi2gmail.rb の挙動が怪しくなっていたので、WWW::Mechanize 0.7.5 への対応も兼ねてコードを書き直した。最近のバージョンでは取得結果を Hpricot::Doc で返すようになり、XPath での検索も出来るようなので、以前の正規表現で切り出す形から XPath で抜き出す形に変更。画像の扱いもHTMLの中にインラインで表示されるよう、mixiアルバム画像貼り付けへの対応も含めて少しマシにした。
また Mechanize が Net::* を上書きする挙動も無くなったようなので、ちゃんとNet::SMTP を使って送信する形に書き換えた。数日試したが、ちゃんと動いているっぽいので公開。

• mixi2gmail.rb

挙動としては、基本的に Linux 前提で、~/.mixi/mixirc に幾つか設定を入れて実行すると、友達の日記を画像を含めて(添付として)指定したメールアドレスに 1日記 1 HTML メールとして送信する。次回実行は新しいものだけを対象にし、また除外リスト、ウォッチリストなどの設定も出来る。

WWW::Mechanize は以前にも書いたが、ログインが必要なウェブサービスからコンテンツを持ってくるなんて言う用途には手軽で便利だ。Hpricot は Htree を改良したっぽいコンセプトだが、そこそこ高速になっているし、non well-formed な HTML 相手に Xpath や css 指定が出来るのは便利。

この手の小物は trac を直してそっちで公開したいが、どうも腰が重い。

2  (追記ないし注意書)

初回挙動は new_friend_diary にいる全ユーザの list_diary から全日記を引っ張るので処理が相当長くなってしまう。時間が長すぎると、メモリを圧迫したり、画像取得に失敗する可能性がある。
動作としては ~/.mixi/lastid.log にある数字より大きい view_diary.pl?id=.... の id の日記のみ取るようになるので、初回も適当な数字を入れておくのが無難かも…。ファイルが無いとエラーになるのはとりあえず 0 入れておいた。

ちなみにこういう挙動にしたのは、以前 mixi が new_friend_diary に 1ユーザ 1日記しか載せなかった期間があった(ので単純にそこから取ると2個以上書いているユーザの日記で取りこぼしが発生した)からなので、現状では挙動変えてもいいかもなと思わないでもないんだけど、初回以外は問題でないだろうしなぁ。

3  再追記: たださんからもらったpatchを適用

たださんがpatchを作って送ってくれたので適用しました。テスト足りてなくてすいません。頂いたメールを引用すると以下のような変更・修正になってます。

• rubygems対応 (Mechanaizeをgemで入れてる人向け)
• lastid.logの初期値対応
• HTTP_PROXY対応
• 空のexcludelistとwatchlist対応

他にも幾つかコメント頂いたんだけど、近いうちに coderepos に置いておくのでその後追々。

4  再追記: 日記トップ画像を1つしかfetchしない問題のfix

T/O。XPath の指定をミスってました。

1  twitlogger.rb - friends_timeline を logging

そういうもの。基本的には Basic 認証をかませつつ決まった URI を叩いて戻り値の XML を REXML に食わせているだけ。ログファイルは日毎に YYYYMMDD.log として分けるようにしている。
まぁ GTalk に全部吐き出させて置けば Gmail に全部溜まるし表示はBitlbee+IRCクライアントで出来るよという話もあるけど。

2  twittail.rb - twitlogger のログを装飾表示

更にそのログをコンソール上で tail -f の代わりに表示するスクリプト。すごくニッチなツールだけど個人的には割と便利。特徴としては

• 実行するとログ最後尾に移動して更新があったもののみ表示
• VT100用コンソール文字修飾(太字・下線・色付け)
• URLのタイトルを展開して付与表示
• @reply があった場合、先頭の reply ユーザの過去ログを展開して表示

ちなみに reply 展開は Auth付きAPIの制約条件(60分内に70アクセスまで)を避けるため、認証無しで取得しているので Protected の Timeline は表示できない。

入力欄とか Notify を固定表示する部分も作りたいような気はするんだけど、 ncurses に手を出すのはちょっと憂鬱のような。

3  4月9日追記: twitlogger.rb 更新

API に since=... の形で送信する前回取得時刻を、timeline の created 時刻の最新のものにするように修正。どうも API で取得できるタイムラインは「現在時刻の数分前」程度な事があるようで(DBレプリケーションの都合?)、単純に前回取得した時刻を since で投げてしまうと 304 Not modified エラーが結構な頻度で発生してしまうみたい。修正後に数時間走らせてみた感じでは殆ど取りこぼしは無いようだ。

4  4月22日追記: twitlogger.rb 更新

since=... で渡す最終取得日時に、since_margin と言うパラメータでマージンを持たせることが出来るように変更。初期値は 0 (since は前回取得したタイムラインの最新時刻)で単位は秒数。

1  Amazon ECS 4.0 への対応

blogを含むサイト内の幾つかのコンテンツで AWS (Amazon Web Service) を使っているが、ECS3.0 が今月末で廃止という事で現行バージョンの ECS4.0 への対応をした。今までAWSへのアクセスに使っていた ruby-amazon は ECS4 非対応なので ruby-aws を使えとのことだが、手元で使うのは ASIN からの lookup 程度なのでお手軽に自前実装。

基本は REST でリクエストして帰ってきた XML を REXML に食わせ、XPath で指定して必要な部分を切り出すだけ。そのまま使うには微妙かもしれないし、ライブラリとしては前述の ruby-aws を使えばいいと思うが、参考になる人がいるかもしれないので公開しておく。

• amazon-a2s.rb

今のところ自分では使ってないが、キーワード検索も一応実装してある。REST のパラメータや戻り値については Amazon Web サービス入門 等を参考にした。

1  spam blog の増加と対策

最近の話でもないんだろうが、spam はメールだけでなくWebでも増加しているようだ。

ニフティは3月26日、国内のブログ記事の4割が「迷惑ブログ」に分類されるという独自調査の結果を公表した。アフィリエイト広告収入や特定サイトへの誘導が目的で、同社では「無意味なコンテンツ」と定義している。ブログの4割は「迷惑ブログ」――ニフティ調査 - ITmedia エンタープライズ

こうした spam blog はコピー元にされたblogや検索者にも迷惑だが、一番困るのは検索エンジン各社だろう。現在でも当然ながら個別のblogに対して blacklist を作ったりなにかしらのロジックで回避するような対応策を考えているんだろうが、今のところその手の blog が検索で引っかかるのは事実だし、spam blog 自体が AdWords 広告を出していたりするのも鬱陶しい。

いっそ迷惑blogが目立つblogサービスでは、ドメインやIPアドレスブロックごと、いわゆる Google八分 を仕掛けるルールにしてしまうのはどうだろう。サービス提供側も真面目に対応せざるを得なくなると思うんだが、規約に盛り込めるような悪行と見なせるかどうかが難しいところか。コンテンツ的にはリンク集やニュースサイトや Planet と大差ないんだし。

そう言えばRSSを全文コピー掲載されることへの対策として、各記事本文に元記事へのリンクを入れると言う方法がRSS FooterでWordPressのRSSに情報を入れてコピーブログを防ぐ | 秋元 や フィードの各記事に署名を入れました - F.Ko-Jiの「一秒後は未来」 で紹介されていたので、うちでも近いうちに入れてみようかなと思っているが、鬱陶しくならないかがちょっと心配。

メールでの SPF/SenderID や DomainKeys/DKIM のような本家送信元証明手段が blog にもあるといいのだけど、うまい方法はちょっと思いつかない。

1  yoosee city - Myminicity

皆様のアクセスのお陰を持ちまして、MyMiniCity は 13,000人を越え、ようやく巨大ビルも建ちました。他のCityを見ると11,000前後で建っているようなんだけど、うちは人工密集度が低いのかな。最初の大型ビルもかなり遅かったし。

去年の暮れに始めた頃の141人のCityと比べると発展の具合が伺えます。

1  そろそろ意味もなくスクリーンセーバを動作させるのは止めるべき

これを見てふと思ったこと。

テレビで放送終了後や開始前に画面に出るカラーパターンを表示します。かえって焼き付きが促進されたらごめんなさい。試験電波発信中スクリーンセーバー

この作者の方がどう意図して書いたのはともかく、焼き付きは CRT では発生するが、最近主流の液晶ディスプレイでは発生しない。そもそも最近のディスプレイならば電源OFFの状態からでも殆ど即時に復帰してくれるんだから、基本的に一定時間経過したらディスプレイを切る設定にした方がいい。

ものによっては3D処理をゴリゴリまわしてCPUを普段以上に使ってくれるスクリーンセーバもあって、まぁ本当にそれを見て楽しんでいるならともかく、そういう画面が放置されているのを見ると何となく悲しい気分になってしまう。もちろん電力的にも無駄であり、でんこちゃんもお怒りだろう。

それでも趣味としてどうしてもスクリーンセーバを使いたいなら、SETI@Home や Folding@Home などの分散コンピューティングでCPUを有効活用してくれるものや、RSS表示スクリーンセーバ、Wikipediaをランダムに表示するスクリーンセーバ(Mac用) のように Push型の情報配信をしてくれるものなどが面白いかもしれない。