2010年10月30日土曜日

Amazon PAAPIのカスタマーレビューiframe対応

またAmazon PAAPIネタです。

仕様変更のため、2010/11/09以降、PAAPIレスポンスデータからカスタマーレビューの文字情報が無くなり、かわりにiframe用のURLが返されるようになります。詳細はこちら

ちなみに実際のIFrameURLの内容などは、Amazon商品情報ビューワーで見るとよくわかります。(最近このツールよく使ってます)


しかも合計レビュー数や評価平均などのサマリ情報も取得できなくなります。
これは過去何度かあったPAAPIの仕様変更の中でも、一番影響が大きいのではないかと思います。

この新仕様の制約の中で、どうすれば最善の対応ができるか。調べてみました。


、、、が、特にいい案も浮かばず。とりあえずはそのままiframeタグを使って表示するしかなさそうです。


iframeを使う上でネックになるのが高さ(height)です。
ひとまず適当に500pxとかで指定するんですが、レビューがないと下300pxくらいスカスカになってしまうし、逆にレビューが多いとスクロールバーが出てしまうので、インターフェース的にあまりキレイじゃないです。

JavaScriptでIFrameURLの高さを取得して、heightを動的に変更、なんてこともできるんでしょうけど、色々面倒なことになりそうです。

あとphpでincludeする方法もありますが、PAAPI公式ページのよくある質問に見ると、

IFRAMEのみが、現在カスタマーレビューデータを表示する唯一の方法となります。ご了承ください。

IFRAMEのみが、現在カスタマーレビューデータを表示する、Amazonにおける唯一の方法となります。

現状、IFRAMEのみがサポート対象となっております。当方としては、アソシエイトの皆様にAmazonの商品を紹介いただくお手伝いをするために、近い将来、他のフォーマットについてのサポートについても検討予定です。


と、IFRAMEのみを連呼されてるので、iframe以外の方法を使うとガイドライン違反と判定されてしまう可能性もなくはありません。

というわけで、ひとまず素直にiframeを使うことにして、しばらく様子をみてみようと思います。最後の近い将来、他のフォーマットについてのサポートについても検討予定です。というのに期待したいと思います。


あともうひとつの大きな問題として、携帯対応があります。

そもそもiframe対応していない機種はどうしようもありません。

実際に自分の端末(ドコモP-09A)で試してみたところ、iframeは表示できたのですが、iframeの枠をクリックしてフォーカスさせないとスクロールできないので、PC以上にインターフェースが分かりにくくなってしまいます。

それよりも問題なのがiframe内のリンクをクリックしてもPC用ページに飛んでしまうこと。携帯のことはまったく考慮されていないようです。

というわけで、携帯サイトのほうは現状ではレビュー表示なしにするしかない、という結論に至りました。



正直かなり残念な仕様変更ですが、もう決まってしまったことなので利用者としては変更にはおとなしく従い、今後のバージョンアップで改善されることを期待するしかないです。

2010年10月29日金曜日

findを使って特定ディレクトリ以下のファイル数カウント・削除をする

findを使ってファイル数のカウント、削除をするコマンドです。

PAAPIのリクエスト2000回制限で導入した、放っておくと際限なく増えてしまうキャッシュファイルの対応用です。

特定ディレクトリ以下のファイル数カウント
/usr/bin/find /path/to/cache_dir/ -type f | /usr/bin/wc -l

最後にアクセスしたのが120分以上前のファイルを削除
/usr/bin/find /path/to/cache_dir/ -amin +120 -exec /bin/rm -f {} \;

これをcronでスケジュール化し、増え続けるキャッシュファイル対策は完了です。

参考ページ
http://mytips.exblog.jp/7558083/
http://d.hatena.ne.jp/yohei-a/20090303/1236048930
http://aligach.net/diary/20090624.html
http://www.k-tanaka.net/unix/find.html

2010年10月26日火曜日

Amazon PAAPIのリクエスト回数制限(1時間2000回)にひっかかる

先週のことですが、Amazon商品情報ビューワーを見てデータの構造をチェックしていたところ、突然「503エラー」が出て、amazonから情報が取得できなくなり、ちょっと焦りました。

調べてみたところ、この503エラーは「1時間につき2,000リクエストまでの当初利用限度」という利用制限にひっかかったのが原因みたいです。

この制限は2010年10月15日から施行されていたようですが、「1時間2000リクエストなんて自分のサイトではあり得ない」と思って完全スルーを決め込んでいました。

1時間に2000リクエストということは、1分に33.333リクエスト。だいたい2秒に1リクエストくらいです。

自分の管理サイトがこんなにアクセスが多いはずはないんですが、放置するわけにもいかないですし、とりあえず調査します。


ひとまず様子をみてみましたが、だいたい毎時30分くらいになると503エラーが出るようになり、毎時55分~00分くらいになると商品情報取得が再開され、また30分くらいで503になる、、、というのが繰りかえされていました。

30分足らずで2000リクエストの制限を使い切ってしまっているようです。
人間によるアクセスがこんなに多いというのはありえないので、おそらくbotによるアクセスが原因でしょう。


とりあえず、以下の対策をとってみました。


■自作ウィジェットを削除

まずはこのブログのサイドバーに置いていた自作のウィジェットを削除しました。今はAmazon公式のウィジェットにしてます。

ちなみに削除したウィジェットはキャッシュを使ってなかったので1アクセスごとにリクエストを送っていました。

このブログはだいたい1日あたり1,200PVくらい(Google Analyticsの解析結果)なんですが、analogの解析結果だと5,000PVくらいありました。

まずはこれで1時間あたり200くらいはリクエストを削減できたと思います。(後になって焼け石に水だったわかりましたが)


■不明なボットを弾く

別の管理サイトのログを見てみたら、ここ数日同一ホストから1日8,000ほどアクセスがあるのがわかりました。User-agentも名乗らず、リファラもなし。ホストが「www????.sakura.ne.jp」になってるので、たぶん誰かがレンタルサーバーに設置してるbotだと思います。

.htaccessで

deny from www????.sakura.ne.jp

して弾くようにしました。


■GoogleBot-Imageを弾く

GoogleBot-Imageが大挙襲来していたのが分かりました。
画像をインデックスしてもらっても特にメリットはないので、robots.txtでブロックすることにしました。
あとmsnやyahooのボットもちょくちょく来てるようなので、ついでにCrawl-delayも追加。

User-agent: Googlebot-Image
Disallow: /

Crawl-delay: 10



■キャッシュを使う

キャッシュを使うようにしました。

キャッシュは当然使うべきなんですが、実は過去に

bot襲来→キャッシュファイル増大→数GBに膨らむ→サーバ落ちる→サーバ再起動時のディスクチェックに12時間以上かかる

という苦い経験があったので、キャッシュを使うのは避けていました。

とりあえずキャッシュの設定を復活させ、有効期限を半日にしてしばらく様子を見みます。

で、一晩明けてみてみたら、まあ予想はしてましたが、キャッシュファイル数が1万を軽く超えてました。

とりあえず一旦キャッシュファイル全削除。
ちなみに調べてみましたが、Linuxでひとつのディレクトリ内に格納できるファイル数はせいぜい1万程度ということらしいです。それ以上だとパフォーマンスが大幅に落ちたりするらしいです。とりあえず全削除で凌ぐとして、この問題はなんとかしないといけません。

というわけで、キャッシュの使用によって新たな問題をひとつ抱えることになってしまいました。。


■asianetcom.netを弾く

ログをみていたら、MSIEのUserAgentを名乗っているものの、アクセス数も動きも人間のものではないIPアドレスがいくつかありました。
逆引きしてみたら、「asianetcom.net」といういかにもあやしいホスト名。調べてみたら、どうもBaidu関係の、お行儀の悪いBotのようです。

http://wiki.livedoor.jp/aissle/d/%A5%ED%A5%DC%A5%C3%A5%C8%A1%CA%B9%F1%C6%E2%A1%CB#content_2_4

↑こちらのページを参考に、というかそのまんまの設定でBotを弾くことにしました。


deny from 61.14.160.0/19
deny from 122.152.128.0/18
deny from 125.252.64.0/18
deny from 202.147.0.0/18
deny from 203.192.160.0/19
deny from 210.232.15.16/29


これがかなり効果があり、ほぼ1時間2000リクエスト以内におさまるようになりました。


■Amazonへのリンク先をDetailPageURLにする

1時間2000リクエストの制限は、売上に応じて変動します。

Product Advertising APIへのアクセスのために使用される各アカウントは、1時間につき2,000リクエストまでの当初利用限度が認められます。その後は、各アカウントは、 30日間に発生する出荷された商品の1時間あたりの収益100円ごとに、1時間につき500リクエスト(1時間につき最大25,000リクエストまで)が受けられます。


要は売上に応じて段階的にリクエストの上限が増えるということです。

さらに

利用限度は収益実績に基づき毎日再計算されます。また、各アカウントに利用限度の追加が認められるかどうかを確認するため、アマゾンへのリンクバック時にはProduct Advertising APIのレスポンスにより返されるURLを改変なしに使用しなければならず、使用されるアソシエイトタグは、Product Advertising APIアカウント所有者のEメールアドレスと同一のEメールアドレスのもとに設定されたものでなければなりません。登録アドレスが一致しない場合、上記利用コントロールが正しく適用されない恐れがありますので、ご注意ください。


ともあります。

これまで自分の場合、amazonへのリンクはhttp://www.amazon.co.jp/exec/obidos/ASIN/B003T9VDIC/myhp-22/みたいなシンプルなものを使っていたんですが、これだと収益実績としてカウントしてくれないわけです。

というわけで、PAAPIのレスポンスにあるDetailPageURLを使うように変更しました。




以上でひとまず対応完了。
悪質なbotはいなくなったものの、まだgoogleやyahooのbotが頻繁に来てるので、やや危ない水準ですけど、2000リクエスト制限問題はほぼ解決しました。

しかしお行儀の悪いbotって本当に迷惑ですね。特にレンタルサーバだと思ったようにアクセスログが取れないこともあるので、対応に苦労しました。

このまま落ち着いてくれるといいんですけど、まだ対応を終えて数日しかたっていないので、しばらくは監視を続けようと思います。

2010年10月22日金曜日

Yahooウェブ検索APIのバージョンアップ対応

Yahooのウェブ検索APIがバージョンアップし、いずれ古いバージョンが使えなくなるということなので、バージョンアップ対応しました。

http://developer.yahoo.co.jp/webapi/search/websearch/v1/websearch.html

まあ対応といっても自分の場合は一カ所だけ、しかも/V1//V2/に変えるだけで済みました。

これもYSTからGoogleエンジンの移行への布石なんでしょうかね。

[jQuery]フォームのテキストフィールドに入力例を入れておき、フォーカスと同 時に消す



こういうやつです。



コードはこれだけ。かなりシンプルです。

$(function(){
$('input').focus(function(){
$(this).val('').css("color","#000");;
});
});




参考にした例。
http://gihyo.jp/design/serial/01/jquery-site-production/0009?page=1
http://h2ham.seesaa.net/article/103945151.html
http://txqz.net/blog/2009/05/16/2312

プラグインもありました。
http://phpspot.org/blog/archives/2009/04/toggleval.html

2010年10月21日木曜日

MySQLのカラム名の大文字・小文字

MySQLでカラム名を

regiDate

とか

startTime

みたいな感じにしてみたんですが、どうもこれはよくないみたいです。
Pear::MDB2でデータを引っ張り出して配列に格納したら、添字がregidateとstarttimeになってました。

http://dev.mysql.com/doc/refman/5.1/ja/identifier-case-sensitivity.html

カラム名、インデックス名、ストアされたルーチン名とカラムのエイリアスは、どのプラットフォームでも大文字と小文字が区別されません。トリガ名では大文字と小文字が区別されます。


長いことMySQLを使ってましたが、これは知らなかったです。
小文字+アンダースコアの形式を使っておくのがいいみたいです。

2010年10月20日水曜日

fireworksのスクリプトでファイルを一括トリミング&書き出し

・124x80のjpg画像が50個ほどあり、
・真ん中でトリミングしてサイズを110x80にし、
・ファイル名はそのままにしつつ、書き出す

ということをfireworksのスクリプト(jsf)でやってみました。ちなみにスクリプト言語はjavascriptが使えます。

var dom = fw.getDocumentDOM();

var basePath = "file:///C:/path/to/origImage/";
var outPath = "file:///C:/path/to/newImage/";

var jpgs = new Array("1.jpg","2.jpg","3.jpg","4.jpg");

dom.deleteAllInDocument();

var jNum = jpgs.length;
for ( var i = 0; i < jNum; i++ ) {
fw.getDocumentDOM().importFile(basePath+jpgs[i], {left:0, top:0, right:0, bottom:0}, false);
saveFile(jpgs[i]);
dom.deleteAllInDocument();
}

function saveFile(F){
dom.exportTo( outPath + F , {
exportFormat: "JPEG",

percentScale: 100,
crop:"true",
cropTop: 0,
cropLeft: 7,
cropRight: 117,
cropBottom: 80,
});
}



fireworksを起動後、適当なサイズで空の新規ドキュメントを開き、[コマンド→スクリプトの実行]でこのスクリプトを実行すれば、一気に書き出されます。

javascriptとはいえ、fireworksでのオブジェクトやドキュメントの扱いは初めてなので少し時間がかかりましたが、思うようにスクリプトが動いて一気に書き出しされると気持ちいいですね。

あと欲を言うとフォルダ内の全ファイルを自動で処理できたらいいんですけど、そこまではわからなかったので、ファイル名は自分で配列に入れています。


ちなみに使ったfireworksのバージョンは8です。たぶんCSやもっと古いバージョンでも動くと思います。


以下は今回参考にさせてもらったサイトです。
http://help.adobe.com/en_US/Fireworks/9.0_Extending/
http://trinine.net/blog/?p=74
http://www.pixelimage.jp/blog/2008/02/_fireworks.html

2010年10月9日土曜日

角丸背景画像が簡単に作れるWebツール「RoundedCornr」

最近はCSSだけで角丸を実現してるケースが多いようですが、個人的には背景を画像にするやり方のほうが好みです。

ただ、いちいち画像を作るのも面倒なので、いいツールないかな~と思って見つけたのがこれです。

RoundedCornr

ページ内にツールが複数あって、画像を生成してくれるのは一番下のSingle RoundedCornr Imageというやつになります。
他のはCSS方式のようです。

色やサイズ、角の大きさなどを指定して、こういう画像が簡単に作れます。なかなか便利です。



2010年10月1日金曜日

CSS文法チェッカー

長いCSSファイルを編集している時、途中どこかで文法を間違えてしまったようで、CSSが機能しなくなってしまいました。

おそらくカギ括弧の閉じ忘れとか、セミコロンを普通のコロンにしてしまったなどのミスで、正直上から一行ずつチェックしていくのは面倒。

そういえばCSSの文法チェッカーってないのかな?と思ってググったら、ありました。

CSS検証サービス

これでチェックしたら一発でした。原因はやはりカギ括弧の閉じ忘れ。

かなり便利なので、これからちょくちょくお世話になりそうです。