kawama.jp

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

カテゴリ: 技術関連 — タグ: , — 2010年10月28日 21:53 — Comments (0)hatebu count

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

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

カテゴリ: PHP,サーバー,技術関連 — タグ: , — 2010年10月25日 20:44 — Comments (2)hatebu count

先週のことですが、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って本当に迷惑ですね。特にレンタルサーバだと思ったようにアクセスログが取れないこともあるので、対応に苦労しました。

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

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

カテゴリ: PHP,技術関連 — タグ: — 2010年10月22日 14:09 — Comments (0)hatebu count

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

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

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

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

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

カテゴリ: Ajax,JavaScript — タグ: , , — 2010年10月21日 16:33 — Comments (0)hatebu count

こういうやつです。

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

$(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

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

カテゴリ: MySQL — タグ: — 10:21 — Comments (0)hatebu count

MySQLでカラム名を

regiDate

とか

startTime

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

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

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

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

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

カテゴリ: 技術関連 — タグ: — 2010年10月19日 23:33 — Comments (0)hatebu count

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

ということを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

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

カテゴリ: 技術関連 — タグ: , — 2010年10月8日 16:16 — Comments (0)hatebu count

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

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

RoundedCornr

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

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

CSS文法チェッカー

カテゴリ: CSS — タグ: , — 2010年9月30日 17:35 — Comments (0)hatebu count

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

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

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

CSS検証サービス

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

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

AmazonPAAPI仕様変更 CustomerContentLookup廃止

カテゴリ: PHP — タグ: — 2010年9月11日 20:58 — Comments (0)hatebu count

amazonより、Product Advertising APIの仕様変更についてのお達しがありました。

利用率低下のため、以下に記載する Product Advertising API のオペレーション/レスポンス・グループは、2010年10月15日をもってサポートを終了いたします。

オペレーション

  • CustomerContentLookup
  • CustomerContentSearch
  • Help
  • ListLookup
  • ListSearch
  • TagLookup
  • TransactionLookup
  • VehiclePartLookup
  • VehiclePartSearch
  • VehicleSearch

レスポンスグループ

  • ListmaniaLists
  • MerchantItemAttributes
  • PromotionDetails
  • Subjects
  • Tags
  • TagsSummary
  • VariationMinimum

とのこと。
あまりメジャーでない機能の廃止なので、自分には関係ないかな、と思ってたんですが、念のため調べてみたら、CustomerContentLookupを使ってるところが一カ所だけありました。

自分で作ったウィッシュリストをAPI経由で参照してリストを作成する、という機能。ほとんど使っていなかったので影響はそれほど大きくありません。
ウィッシュリストが活用できるという点でけっこう便利だと思ってたので、なくなっちゃうのは少し寂しい気がします。

とは言っても廃止が決定してしまったのはしょうがないので、APIを使うのをやめ、代わりにASINを配列に保存するという簡単な改修を行って対応を完了しました。

Services_TwitterのOAuth対応

カテゴリ: PHP — タグ: , , — 2010年9月10日 21:49 — Comments (0)hatebu count

少し前にTwitterAPIがOAuth対応になり、これまでのベーシック認証が使えなくなりました。

そのうち対応させなきゃいけないなー、と思いつつ後回しにしていたのですが、こちらの記事を見て簡単にできることがわかったので対応してみました。

http://phpspot.org/blog/archives/2010/09/oauthphptwitter.html

まずは必要なPearライブラリを用意。その時点での最新バージョンをインストールします。


pear install channel://pear.php.net/Net_URL2-0.3.1
pear install channel://pear.php.net/HTTP_Request2-0.5.2
pear install HTTP_OAuth-0.1.18
pear upgrade channel://pear.php.net/Services_Twitter-0.6.2

※Services_Twitterはバージョン0.4以降はphp5.2以上でないとインストールできません。
自分の場合、php5.1の環境だったんですが、-fオプションで強制的にインストールしました。
そのまま使ってますが、今のところ特に問題はでていません。

続いてソースコードの修正。こんな感じになります。


require("Services/Twitter.php");
require("HTTP/OAuth/Consumer.php");

$tweet = "ツイートです\n";

$twitter = new Services_Twitter();
$oauth = new HTTP_OAuth_Consumer(
'*************', //Consumer Key
'*************', //Consumer Secret
'*************', //Access Token
'*************' //Access Token Secret
);
$twitter->setOAuth($oauth);
$msg = $twitter->statuses->update($tweet);
echo "Tweet OK \n\n";

これでAPI経由でtweetできるようになりました。

Copyright (C) 2002 - 2017 kawama All Rights Reserved. — Powered by WordPress