Ellinikonblue.net Devlosxom

　緊急事態です。

　最近、どうも bsnap_asin プラグイン の 動きが変だと思っていたら、 このプラグインのアルゴリズムで用いている Product Advertising API における XSLT を用いた変換機能がそもそもなくなっているという事実が判明しました。

　よく全貌を把握していないのですが、 Product Advertising API そのものが廃止になった訳ではなく、 出展者向けの一部の機能が Amazon マーケットプレイス Web サービス という 新サービスに置き換えられ、そのためになくなった機能の中に XSLT 変換機能が含まれていたようです。

　えーまじか！？ orz って感じです。

　bsnap_asin プラグイン は 極端に大きな応答（商品情報の XML がそのまま帰ってくるとか…）では キャッシュを更新しない仕組みになっているので、これがあだになって気がつきませんでした。

　根幹のアルゴリズムを作り直しです。
　ひとまず同じ blosxom の プラグインに fukaz55 の中の人が作成された awsxom がありますので、これをベースに作り直します。

　うげー。
　awsxom のおかげで修正コストを削減できそうですが、 そもそも Product Advertising API が廃止になったりしないよね。頼むよ＞ Amazon 様
# これ終わったら Amazon MWS の勉強始めとこうか… orz

　いや単に実験用エントリです。

その１ Kindle Fire HD (16GB)


その２ のだめカンタービレ (1)
　なにもでてないでしょ？ (^^;>（ 2012/11/05 現在）

　やっぱりうまく動作していませんでした。しかし、プログラムのバグでもありませんでした。

　先般の Product Advertising API の仕様変更の際、さらっと書いてあった 「 2011-08-01 バージョンを除くすべての旧バージョンのサポートを終了させていただきます。」 との下りがくせ者でした。
　bsnap_asin プラグインは Amazon Web サービスへのリクエストの際、 XSLT スタイルシートを指定して、 応答としては HTML を返してもらうところがプログラムの肝なのですが、 このとき、リクエストの際にも、XSLT のスタイルシートにもバージョンを指定していなければならず、 「 旧バージョンでのリクエストはすべて 2011-08-01 バージョンに変換されます。」との 下りもありましたが、少なくとも XSLT スタイルシートを指定しての REST リクエストはいっさい変換されず、 中身のない（ 0 バイトの）応答が帰ってきていました。
　ただこれはこれまで指定したことのない商品を指定したときで、 既に指定したことがあった商品の場合はキャッシュが 0 バイトファイルで上書きされることもなかったので、 気がつくのが遅くなりました。

　結局、既存のキャッシュが更新されなかった理由は今も謎なのですが、 XSLT スタイルファイルを見直して、リクエストするときのバージョンも 2011-08-01 で 統一すれば正常に動作するようになりました。一件落着 (^^)b

　ということで、プログラムの方はほとんど直していないのですが、 PukiWiki の方にのせてるものからは、 ちょこちょこと変わっていますし、今回、 XSLT スタイルファイルも見直しましたんで、 近いうちに更新します。

　XSLT スタイルファイルの見直しの際、以下のドキュメントを参考にさせていただきました m(_ _)m

Ajax の学習なら AjaxTower 「 Amazon Web サービス入門」

　先般、 Product Advertising API 仕様変更があって、 また bsnap_asin プラグイン が 動かなくなるかと戦々恐々としていたのですが、 動かなくなることは幸いありませんでした。
　ただ、まだ確信はないのですが、動作がおかしいような気がしています。

　ちょっと PukiWiki 側に反映していない変更も たまってきたので、そろそろこのあたりで気合い入れて（必要があれば）修正します。

　その決意のテスト用エントリです (^^;

　久々に思い立って blosxom のプラグインを いじってみた。 bsnap_asin プラグイン を延々と使っていると、 キャッシュファイルが一つのディレクトのしたにどんどんできるので、 あまりたくさんのファイルが一つのディレクトリ下にできるとファイルの検索効率が落ちると思い、 サブディレクトリを切ってキャッシュファイルをができるように改良。
　思ったより簡単に出来ました。

　現状、ASIN コードの下一桁をとってきて最大 36 ディレクトリができるようになっていますが、 原理的には、以下の三か所

：（略）
  $cache_dir = $asin_dir.'/'.substr( $1, 9, 1 );
：（略）
  my $cache      = "$asin_dir/".substr( $asinCode, 9, 1 )."/$asinCode.html";
：（略）
  my $tmp_file = "$asin_dir/".substr( $asinCode, 9, 1 )."/$asinCode.tmp";
：（略）

の substr の第二引数を 8 に、第三引数を 2 に設定すれば、 さらにたくさんのサブディレクトリを切るようになります（おそらく）。

　問題なさそうなので近々、 Weblog の方にも導入予定。 その後、Ellinikonblue.com PukiWiki で ドキュメント整理＆公開予定。。。

「 『 Google Insights for Search 』日本語化、未来予測機能も公開」 （ INTERNET Watch より）

　ということで、Google Insights for Search で 検索ワードとして「 blosxom 」を 分析した結果 　まぁ、上記の検索結果は普段から何となく想像はつくことなんですが、 その関連情報に注目検索クエリとして「急激増加」となっていた 「 blosxom markdown 」
　Markdown ってなに？気になって調べますと…

hail2u.net 「 Markdown 」
にーやんのブログ
「 Markdown を Blosxom のプラグインとして使用する」
「 Markdown のシンタックス」
チェリオメアリー 「 Markdown 入れた」

　要は Wiki みたいに簡単に HTML を記述してしまって、 それが blosxom で使えて便利だねと。
　う～確かに便利そうだけど、記述シンタックスを見ていると、 うちの bracket_fep プラグイン と もろにコンフリクトしそう。。。
　一応こういうものがあるといことは覚えとく。。。ということで。

　しかし、私が今頃になって調べている話を hail2u.net では 5 年も前の話題。。。 やっぱりこの中の人はすげー。。。

• Daring Fireball: Markdown

　bsnap_asin プラグイン の Product Advertising API 対応、 何とかできたみたいです。
　ここ一週間ぐらい、 ここ と Ellinikonblue.com Weblog で 試験を続けましたが、特に問題なく動いているようです。
　やっと「勝った」って気分です (^^)b

　うまくいかなかった大きな原因は、XML の名前空間の問題。
　XSL スタイルシート中に記載していた以下の部分

<xsl:stylesheet version="1.0"
  xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
  xmlns:aws="http://webservices.amazon.com/AWSECommerceService/2005-07-26">

とリクエスト時に渡す Version 引数で同じ日付を指定しなければならず、 これを新しい日付にしていたら、そもそもその日付に名前空間が Amazon 側にないという、 ならどの日付の名前空間ならあるんだとちょっと調べてみましたがこちらで見あたらず、 結果、以前使っていた日付の名前空間を利用してみたところやっとうまくいきました。
　この Version の指定で帰ってくる XML の内容も違うので、 ちょっと時間をおいてじっくり見直して新しい XSL スタイルシートも考え直したいと思います。
# ひとまず今回はこれまでと同じ「 2005-07-26 」の名前空間を使っています。

　ひとまずどうにかこうにか 8 月以降も Amazon アソシエイト Web サービス 続行可ということで。 ほっ f^O^;
# ここまでの成果は近々、 Ellinikonblue.com PukiWiki の方で 公開いたします。

　bsnap_asin プラグイン の Product Advertising API 対応ですが、 やっと光が見えてきました。
　とは言っても、リクエストを出して、応答が帰ってきたところまでなんですが…

　bsnap_asin プラグイン は XSL スタイルシートを指定して、その応答をキャッシュして出力しているのですが、 これまで使用していた XSL スタイルシートを指定しても、 XML の生の応答が帰ってくるだけで、スタイルシートを適用してくれません。

　そもそもにして、webservices.amazon.co.jp や ecs.amazonaws.jp に リクエストを送っても 403 Forbidden が帰ってきますが、 同じリクエストを xml-jp.amznxslt.com に送れば応答は帰ってきます。 しかし、 XSL スタイルシートは適用されて戻ってきません。

　Signature を生成してつけるだけでこれまで通りなどとは思わぬ方がよいようです。 ぐったりです。

　とりあえず、以前 疑問に思っていたことがだいたい解決したのでその回答をメモ。

1. Secret Access Key ってなに？
   Subscription ID (AWSAccessKeyId) をしたときと 同じで Amazon Web Services のホームページ にログインすれば表示されます。
2. タイムスタンプは GMT or 日本時間？
   たとえ日本のサイトにリクエストするときでも GMT です。
3. Signiture を作る際のテキストの改行コードは CR or LF or CR+LF ？
   LF 。

　その他。これまでの参考記事。

web2.0 的ラボ 「 Amazon Product Advertising API 電子署名と XSLT のまとめ」
RinGoon POP!! 「 [PHP] Amazon Product Advertising API で認証付きリクエストを送る方法まとめ」

　もう一息！？…そうなのか？くじけそう orz

　先週末に bsnap_asin プラグイン の Product Advertising API 対応に向けて 1st Try してみた訳なんですが、一筋縄でいくはずないんですよね…これが orz

　まずは RFC 2104-compliant HMAC with the SHA256 hash algorithm で Signature を生成しないといけないのですが、このために Digest::SHA を use してみるとエラー。
　XREA のサーバにはインストールされてないみたいなので、 ソースを引っ張ってきて、サーバにアップロード。そしてソースコード中に以下のコードを追加。

use lib '/Common/perl/lib/';

　Perl のライブラリパスを追加してみてもエラー。
　どうも SHA.pm は ソースだけでは動かないらしい。

　そこで今度は Digest::SHA::PurePerl を アップロード。
　これを use してもエラーは出なくなりました。 これでおそらくハッシュエンコードは大丈夫？

　ところがプラグインはうまく動作しない。というか、そもそもプラグインが有効になっていないよう。
　ここで時間切れで 1st Try は終了しましたが、 あとでよくよく考えてみると、 blosxom は プラグインのファイルの名前の最後に _ （アンダーバー）をつけると、 一時的にそのプラグインを無効にできますが、 bracket_fep プラグイン も 専用プラグインを読み込むときはアルゴリズムが同じで、 このため古い方をアンダーバー付き、新しい方をなしで、同じファイル名でアップロードしてしまうと、 両方ともプラグインが無効になることがソースを読んでみてわかりました。

　以上、作業日報かねて経過報告。
　余裕がないときに焦ってやると何でもうまくいかないものです。。。 時間に余裕があるときに再チャレンジすることにします。 (_ _;>

• Digest::SHA
• Digest::SHA::PurePerl

　そもそもにして、このサイトを立ち上げた理由の一つは、 この gin プラグイン を開発するためだったのですが、 すでに丸二年経過… orz

　なんでこんなに放置プレーになっているかというと、 途中で JSON の仕様を勘違いしていることに気づいたから。

　しかし、そろそろ初心に戻ろうと、今年は少し進展させたい。
　と言うことで、しっかり JSON の仕様を理解して（ると思う）、 このプラグインの入出力の鍵となる各ファイルの形式をもう一度見直した結果。

まず categories_index.json 。

[
	{ "directory": "/home/public_html/devlosxom/data", "count": 7 },
	{ "directory": "/home/public_html/devlosxom/data/About", "count": 2 },
	{ "directory": "/home/public_html/devlosxom/data/Doc", "count": 4 },
	{ "directory": "/home/public_html/devlosxom/data/Doc/Idea", "count": 1 },
	{ "directory": "/home/public_html/devlosxom/data/Plugin", "count": 1 },
	{ "directory": "/home/public_html/devlosxom/data/Plugin/Spec", "count": 1 }
]

次 categories_alias.json(categories.alias) 。

[
  { "directory": "/home/public_html/devlosxom/data/About", "alias": "このブログについて" },
  { "directory": "/home/public_html/devlosxom/data/Doc", "alias": "ドキュメント" },
  { "directory": "/home/public_html/devlosxom/data/Doc/Idea", "alias": "アイデア" },
  { "directory": "/home/public_html/devlosxom/data/Doc/Resources", "alias": "参考資料・メモ" },
  { "directory": "/home/public_html/devlosxom/data/Plugin", "alias": "プラグイン" },
  { "directory": "/home/public_html/devlosxom/data/Plugin/Spec", "alias": "仕様" }
]

最後に archives_index.json 。

[
	{ "year": 2007, "count": 7 },
		{ "year": 2007, "month": 5, "count": 1 },
			{ "year": 2007, "month": 5, "day": 4, "count": 1 },
		{ "year": 2007, "month": 4, "count": 2 },
			{ "year": 2007, "month": 4, "day": 18, "count": 1 },
			{ "year": 2007, "month": 4, "day": 7, "count": 1 },
		{ "year": 2007, "month": 3, "count": 3 },
			{ "year": 2007, "month": 3, "day": 24, "count": 1 },
			{ "year": 2007, "month": 3, "day": 3, "count": 1 },
			{ "year": 2007, "month": 3, "day": 2, "count": 1 },
		{ "year": 2007, "month": 2, "count": 1 },
			{ "year": 2007, "month": 2, "day": 26, "count": 1 },
	{ "count" : 7 }
]

　このデータ形式を元にコード書き直し。
　どこまでコードを使い回さなければならないかもだいたい見えたので、 ちょっとまじめにプログラム構造を考え直そうかと思っています。

　ただすぐにコーディングに入らない理由が一つ。 　archives_index.json のデータを内部的にどういう構造で扱うかというところで、 ひらめきがない。。。これがひらめいたら。。。今年はちょっと進むと思うな ＞ gin プラグイン