24キロダルトン : 自作オナホなどの理想的なオナグッズを探究していたブログ

メニューまで移動

カテゴリ : その他

“blosxom”を使って3回目のサイトリニューアル！

サイト開設から5年…また無駄にリニューアルです！Twitterを使い始めました。ストレージ用にServersMan@CASを使用中です。アクセスランキング始めました。巨像密林がオープン。Googleサイドウィキを停止。自ツイートを埋め込むように。

ブログっぽく？

2010年04月01日 00時00分

なぜか分かりませんが、昨年末あたりからまたリニューアルしたいという衝動に駆られました。

ということで、“マルナナニゴウシツ(http://room072.961832.info/)”と“サワラヌカミニ(http://tiptoe.961832.info/)”にあった記事をまとめ、新しく作ったこの“24キロダルトン(http://961832.info/blog/)”に移動しました。ほとんど更新していなかった“エロノトマリギ(http://roostxxx.961832.info/)”は停止しました。

なぜか“blosxom”に

「どうせやるなら構築ツールも変えてみよう」ということで、検索していて見つけたPerl製の“blosxom”というツールを使ってみることに。本当はWordPressといったイマドキのツールがいいのかもしれませんが、自分はPHPをあまり知らなくて少し不安です。

以前、chalowを見つけた時もそうでしたが、やっぱり新しいものを知った時はワクワクしますね。

blosxomが作るページの種類には“インデックス”、“カテゴリ”、それから“ストーリー”と、年月日ごとの“アーカイブ”があります。なかでも中心となるのはストーリーで、ブログでいうところのエントリーと同じ意味合いになるでしょうか。

ストーリーの元となるデータはテキストファイルで作り、最初の1行にタイトルを、それ以降の行に内容を記述することによって個別ページができあがります。基本はこのストーリーファイルをポンポン作って放り込んでおけばいいので楽でした。

インデックスでは、このストーリーが更新日時順に指定した数だけ表示されます。カテゴリは、ディレクトリを作って、そこにストーリーファイルを入れるだけで分けられます。URLにディレクトリ名を含めれば、そのカテゴリ内のストーリーが表示される仕組みです。

と、こんな感じで非常にシンプル。プラグインやテンプレートといった機能があり、自分で深い部分までカスタマイズすることもできます。これはワクワクします！

自分だけのblosxomにカスタマイズ

自サイトの更新間隔は月に多くても1エントリーくらいの激遅なので、日記のように表示するのには向いてないかなと思いました。なので、エントリーを少しずつ積み重ねていけるような構造にするため、しばらくあーだこーだしていたのでした。

まず、blosxomのカテゴリをエントリーとして扱うことにしました。ストーリーの集合体がエントリーになるといった感じでしょうか。ではストーリーの個別ページはどうするのかというと、動画や画像などのギャラリーとして使うことにしました。上手く表現できませんが、１階層上にシフトしたような感じになります。

これのままだとblosxomのカテゴリ機能は使えないので、自分でカテゴリ機能を用意することに。そして、インデックスは時間軸で表示するのではなく、サイトマップのように全体を表示するようにしました。

最初は、大量にある既存のプラグインを組み合わせてやろうとしましたが、プラグイン同士の競合がおきたりして解決するのが面倒だったので、結局は自分で作ったプラグイン1個だけになってしまいました(汗)。それから、各プラグイン関数がどのタイミングで呼ばれるのか調べるために結局、blosxom本体のソースコードを見るはめになったので、楽しかったけど少し苦労しました。

こうして、ひとまず大まかな部分はできあがったものの、やっぱり過去データの移行作業が一番大変でした。でも、「これとこれは一つのエントリーにまとめられるな」といった、見直す機会もできたので良かったです。

ブログっぽくしたので、URLだけで何のエントリーなのか分かるように注意して名前も決めてみました。といっても自分はそもそも英語ができないので、とりあえず機械翻訳を使って“tried ～ing”が“～してみる”というのは分かりましたが、たぶん意味はメチャメクャです(汗)。

あまり更新しないので、RSSのフィード配信はひとまずやめることに。今後は、この手作り感あふれるデザイン(笑)やビデオサイトマップを見直していきます。

参考になった情報

コメント機能に“Google Sidewiki(サイドウィキ)”を使ってみる

2010年04月05日 23時51分

リニューアルしてブログっぽくなった(？)ので、コメント機能をつけてみたくなりました。

blosxomにもコメント機能のプラグインは既にあって、これが使えそうかなと思ったのですが、どうやら自作のプラグインは共存することを許してくれそうにありません(笑)。

コードをいじるのは面倒だったので、少し前にネットニュースで見ていた“Google Sidewiki”を使ってみることに。JavaScriptのクライアントライブラリが用意されていたりして、手軽にコメントを取ってこられるもようです。また、検索しているとJSONPで取ってくる方法もありました(推奨されていない？)。

今回はblosxomの自作プラグインに組み込むことで、URLの末端にcommentを追加すると、そのURLのコメントページになるようにしました。そして、コードがさらにスパゲッティ化しました(笑)。

取ってくるのは手軽でいいのですが、コメントの投稿が“Googleツールバー”からじゃないとできないらしく、これは少し面倒です。ってか…サイドウィキ自体、使っている人があまり居なさそうですね(苦笑)。

このサービスがいつまで続くのかは分かりませんが、コメントの評価機能が面白そうなので、これから24kDaではサイドウィキを使っていきます。

ビデオサイトマップの見直し中に、再生がヘンになる動画を発見

2010年04月09日 19時50分

最近、以前のGoogleビデオサイトマップを見直したので、サイトマップファイル内のリンク先が正しいか一通りチェックしていた時のことです。

そのなかに、まるで早送り再生のような状態になってしまう動画があったので探ってみると、だいたい次のことが分かりました。

FlashPlayer上で再生するとなる

自分の環境だけでしか試していませんが、同じファイルでも、ローカルなffdshowDirectShow経由のプレイヤーだと大丈夫です。

H.263が使われているFLV1形式の動画で、かつ携帯動画変換君v0.34付属のffmpegでエンコードしたものがなる

同じFLV1形式のものでも、かつてFLV4形式の動画を作った時に、変換君セット付属mencoderでエンコードしたものは大丈夫っぽいです。

最近なった？

でも少なくともリニューアル前までは、この現象を見なかったような気がするので、リニューアル時にFlash関係で変更したことを思い出してみると、

この2点だけだったので、バージョンを変えたものを組み合わせ、あーだこーだテストしてみることに。 その結果、Flash Playerのバージョンに関係なく、JW Playerのバージョンが5系だとなる事がわかりました。

もともとこの動画は、こうなる前にもトータル時間やシークつまみがプレーヤーに表示されなかったりしていたものだったので、たぶん変換君でエンコード時に何らかのパラメータを忘れてしまっていたのかもしれません…自業自得です(汗)。

バージョンを戻して一件落着

いっそ全部MP4形式にしちゃおうか迷いましたが、JW Playerはバージョン5からウォーターマークが有料版でしか使えなくなったようで少し残念だったというのもあり、深入りすることはやめて、とりあえずバージョン4.6に戻して様子を見ることにしました。

関係ないですが、MP4形式(H.264)の動画を作った時におきていた拡張子問題も、いつの間にか大丈夫になっていることを確認。ビデオサイトマップも無事、作業が終わりました。ちょうど、サイトマップファイルに画像ファイルが登録できるようになった事を知り、ついでにやってみたので、これからどうなるのか楽しみです！

ギャラリーのプレイリストXMLファイルをXSLTで視覚化

2010年05月21日 20時19分

ある日、Googleでいつものように自サイトのインデックス具合を見ていると、予想外のファイルがインデックスされていました。

そのファイルというのはギャラリーページのFlashが使っている、XML形式のプレイリストファイルでした。HTML内のJavaScript部分でファイルのURLを引数として渡しているのですが、ページ中に記述してあるためか気を利かせてインデックスしてくれたもようです。

これはこれで嬉しい事です。でもこれをブラウザで見ると中身がそのまま表示されてしまい、人間が見たら分かりにくいですね。こんな場合はXSLTの出番と思い、久しぶりに使ってみる事に。

XSLTは昔やっていたのですが今ではすっかり忘れていて、名前空間が必要だという事を思い出すまで表示すらされない状態でした(笑)。あーだこーだ何日か格闘し、いちおうHTMLページのように表示できています(実際のプレイリストファイル)。ひとまず安心安心。

MegaZine3をギャラリーページ用として使ってみる

2010年07月13日 15時21分

今までギャラリーページで使ってきているのは“JW Player”というFlashソフトなのですが、今回これに加えて“MegaZine3”という別のFlashソフトを取り入れてみる事にしました。

なぜMegaZine3を選んだのかというと、JWPlayerと同じく画像と動画が表示できる事と、自分がRAW現像をはじめてから、大きなサイズの画像も表示したくなり、画像がモニタ画面より大きい場合にスクロールできるような機能があるといいのになと思ったためです。これはJWPlayerでもプラグインを自作すれば可能なのかもしれませんが、自分のスキルでは時間がかかりそうなので(汗)。

ちなみにMegaZine3の“3”という数字はバージョン番号ではなく、FAQによると“ActionScript3”を意味しているみたいで、バージョン番号のほうは2.0.9でした…少しまぎらわしいです(笑)。

自分でも使えそうな感じ

MegaZine3を実際に試された方の日本語の情報が少なかったので、公式サイトのマニュアルを機械翻訳に通して見ながら、あーだこーだ試していました。といっても全ての設定がXMLファイルからできるので、そう難しくはありません。このへんはJWPlayerと同じ感じでやりやすかったです。共通の設定を別ファイルで指定できると、より簡潔に書けていいのになと思いました。

レイアウトによっては画像やテキストなどの位置を座標で指定しなければならないので少し面倒と感じましたが、これは凝った配置ができるという事でもあるので仕方のないところでしょうか。今のところ何種類かテンプレートを作って当てはめるようにしています。

プラグインもある程度用意されていて、ギャラリー画面やSWFAddress連携など使えそうなものがありました。MegaZine3は“ASUL”なるXMLベースの言語が使われていて、本体やプラグインのカスタマイズだったり、プラグインの自作だったりと色々できるもようです。自分もFAQにあった自動スクロールが無効になる設定をしています。デフォルトで自動スクロールを無効にしたかったのですが、ファイルの設定を変えても反映されない(汗)。設定画面の“Auto move”で決めないといけないのかな？

エフェクト関係はできるだけ削るようにしていますが、PCへの負荷はJWPlayerよりもありそうですね。

リダイレクトするURLには一部未対応？

MegaZine3をテスト中、つまずいた部分もありました。自サイトでは動画ファイルや容量が大きな画像ファイルは、回線は貧弱だけど容量に余裕のある自宅サーバにリダイレクトしています。しかしimg要素のsrc属性は、リダイレクトするURLだと表示されない事が発覚。vid要素のpreview属性もダメでした。でも同じvid要素のsrc属性や、Galleryプラグインで使えるようになるimg要素のhires属性は問題なくリダイレクト先のファイルを表示しています。

Flashのクロスドメインポリシーファイルは読み込み先に置いてあり、HTTPのレスポンスも302のあと、ちゃんと200がきているので問題なさそうなのですが…。これに関しては今のところ謎です。もしかしたら自サーバの設定が足りていないのかもしれません(汗)。とりあえずリダイレクトできない部分に使われる画像は、サムネイルなど容量を小さくしても大丈夫な画像なので、リダイレクトせずにメインサーバへ置くようにしました。

写真用アルバムっぽく

自分は最近になってから、自分が撮った画像はネットの写真屋さんでプリントしてもらい、それを写真用アルバムに貼り付けています。アルバムの重要性に気づいたというか…PCに入れておくよりも見返しやすくて、何というかイメージがわきやすい感が自分にはあります。今では寝る前などの少し空いた時間にアルバムを開き、写真を撮った時の状況を思い返したりするのが好きになりました。

“page flip engine”と説明にもあるように、MegaZine3は本のページをめくるような表現ができます。自分は写真を黒台紙に貼り付ける事が多いので、MegaZine3も黒台紙のアルバムと同じような感じにできるか、あーだこーだやってみました。最初は背景が黒のベタ塗りでしたが質感が違う感じがするし、ページの境目も分かりにくいです。なので、黒いパターン模様にグラデーションを軽くあしらった画像を用意して、これを各ページのベースとして表示するようにしました。これで少しは写真用アルバムっぽくなった気がします。

一部の画像は、Galleryプラグインにより、マウスクリックすると大きな画像で表示できるようにしてみました。また、Titlesプラグインにより、マウスオーバーすると撮影＆現像情報が表示されるものもあります。

しばらく使ってみる事に

画像や文章などの配置が少し面倒なので、既存のギャラリー全部をMegaZine3に置き換える事はできていませんが今のところ、ユメノツヅキ、デジタルカメラ“DMC-GH1”、デジタルカメラ“DMC-GF1”、USB-DAC付ヘッドフォンアンプ“DR.DAC2”がMegaZine3を使ったギャラリーのあるエントリーとなっています。

これから作るギャラリーについては、出来るだけMegaZine3を使っていきます。

参考になった情報
『MegaZine 3』 ページ内にZOOM機能を追加する ::: 東南アジアのリゾートホテル写真集 | Beach Resort Photoclip

MegaZine3を実際に試されたかたの記事です。自分もGalleryプラグインを使っているので、とても参考になりました。

Control the skin colour and position of video's (MegaZine3:Community Portal)

MegaZine3が用意する動画プレーヤーのスキンは、デフォルトだと動画に重なって表示されます。これを変えたかったので、このフォーラムのレスを参考に動画の下へ表示されるスキンにしました。でもこれはこれで動画のすぐ下にテキストがあったりすると隠れて見えなくなってしまうので、レイアウトには注意が必要ですね。マウスオーバーすると表示されるようなスキンは自作するしか無いのかな？

[ja] Japanese - 日本語 (MegaZine3:Community Portal)

メニューなどにある説明文を日本語化するローカライズファイルがダウンロードできます。ファイル自体は以前のバージョンのもののようですが、一部参考になりました。

“ServersMan@CAS(MZK-NAS02SGS)”を自サイト用オンラインストレージとして使ってみる

2010年07月28日 15時25分

最近、部屋の撮影場所をもう少しどうにかしようと、まず配置替えからやり始めていたのですが、ルータまわりの掃除をしている時ふと思い出しました。今年の初め、何かに使えるだろうとPLANEXの“MZK-NAS02SGS”を買っておいたという事を…。

このMZK-NAS02SGS、パッと見、いわゆるNASと呼ばれているものなんですが、それに加えて“ServersMan”なる仮想化技術を搭載していて、ローカルネットワークからはもちろん、ServersManを使ってリモートネットワークからも手軽にアクセス可能になる、というのが大きな特徴のようです。

NAS向けのServersManは“ServersMan@CAS”と呼んでいるようで、技術的な部分などの詳しい事はBB Watchの記事に分かりやすく載っていました。ちなみにServersManを提供しているのは本体とは別の企業です。

手軽に大容量オンラインストレージを構築！

このServersMan@CASには色々な使い方があるのですが、その中でもWebページ公開機能というのが自分の場合は特に気になりました。自サイトでは動画やRAW現像した画像など容量の大きなファイルの置き場に困っていて、今までは自宅サーバマシンで対処してきているからです。

これは今のところ特に問題なく動いてくれていますが、もし自サイトのファイルストレージ用途としてServersMan@CASを使えるのであれば、自宅サーバマシンよりメンテナンスも簡単そうだし電気代も抑えられるかなと、買ってServersManへの登録だけ済ませておいたのでした。すっかり使うのを忘れていましたが(汗)。

こんな感じで、およそ数ヶ月ぶりに電源を入れてみる事に。すでにServersManへの登録は完了していたので実際に使うのは簡単でした。設定も迷う部分は無く、特定のディレクトリにファイルを入れてあげればWebブラウザから普通にアクセスできます。この手軽さで、ミラーリング(RAID 1)された容量1テラバイトのオンラインストレージを手に入れたという事になります。もっとも、アパートの一般的な光回線なので上り速度はそれほど出ていませんが、ひとまず使い続けて様子を見ることにします。

本体から聞こえる音

あとこれは自分のだけかもしれませんが、本体から聞こえる音が少し気になりました。本体底面にある吸気ファン自体の音ではなくて、どうやらファンとケースが触れ合って震えているようです。本体がホットスワップ対応なので電源を入れたままハードディスクを全部取り外してみても音は止まず、取り外したまま今度はケースを強く握ると音が止みます。このファンへはケースを分解しないとアクセスできないっぽいので、ひとまず底面に防振シートを重ね置いて、音を少し軽減させました。

Twitterを自サイトのフィード配信機能の代わりとして使ってみる

2010年09月13日 17時58分

いまさら感が溢れていますが(汗)、いわずと知れた“Twitter”を使ってみることに。

といっても、主な用途が3回目のリニューアル時に停止させたフィード配信機能の代わりとしてなので、使いこなそうという感じではないです。それから公式ツイートボタンが最近できたもようなので、各ページに対してツイートできるようにもしてみました。

何というか、今までのように全て自サイト内に置かず、こういった外部サービスに頼ってみるのも良いかなと思えるようになってきました…サイドウィキへの書き込みが皆無というのも大きいかもしれませんが(笑)。

とりあえず、これからは細かなものも含めた自サイトの更新情報をツイートしてゆきます。続けられるかが心配(汗)。

外部リンク

Google Analytics のAPIを使ってアクセスランキングページを追加

2010年10月21日 13時19分

ブログのアクセスランキングを表示してみたいな～と前々から思っていたので、用意されているAPIを使って以前から利用している Google Analytics と連携してみることに。

負荷がかかるといけないのでサーバーのcronデーモンを使い、1日1回だけ Google Analytics へアクセスし、1ヶ月ぶんのデータを取りに行ってファイルへ書き出しています。そしてblosxom側ではランキングページアクセス時、その保存されたファイルを整形して表示するような流れです。参考となる日本語の情報もあり、今回はスムーズに作ることができました。

とりあえず、エントリー別とギャラリー別のページを作ってはみたものの自サイトはアクセス数自体が少ないので、あまりランキングにする意味が無いのかもしれませんね(笑)。

実際のPerlコード(ギャラリー別ランキング用)

APIはフィルターに正規表現が使えて便利でした。今のところ元気に動いていますが、かなりアバウトに書いた汚いコードです(汗)。

下記コードは、バージョン2.3のGoogle Analytics APIを使用しています。

 
use strict;
use warnings;
use HTTP::Request::Common ();
use LWP::UserAgent;
use URI::Escape;
use Time::Local;
use XML::TreePP;
##おおよそ30日前から1日前までを
my ( $mday, $mon, $year ) = ( localtime (time-86400) )[ 3 .. 5 ];
my $date_end = sprintf "%04d-%02d-%02d", $year + 1900, $mon + 1, $mday;
( $mday, $mon, $year ) = ( localtime (time-2592000) )[ 3 .. 5 ];
my $date_start = sprintf "%04d-%02d-%02d", $year + 1900, $mon + 1, $mday;
##
my $email  = '*****';
my $passwd = '*****';
my $source = '*****';
##
my $ua  = LWP::UserAgent->new();
my $treepp =
  XML::TreePP->new( { output_encoding => "UTF-8", force_array => '*' } );
##
my $url = 'https://www.google.com/accounts/ClientLogin';
my $res = $ua->request(
    HTTP::Request::Common::POST(
        $url,
        [
            accountType => 'GOOGLE',
            Email       => $email,
            Passwd      => $passwd,
            service     => 'analytics',
            source      => $source
        ]
    )
);
my %cl;
foreach my $keyval ( split( /\n/, $res->content ) ) {
    $cl{(split( /=/, $keyval ) )[0]} = (split( /=/, $keyval ) )[1];
}
##
$url = 'https://www.google.com/analytics/feeds/accounts/default';
##$url .= '?prettyprint=true';
$res = $ua->request(
    HTTP::Request::Common::GET(
        $url, 'Authorization' => "GoogleLogin Auth=$cl{'Auth'}"
    )
);
my $res_hash = $treepp->parse( $res->content );
##
my $regexp = 'ga:pagePath!~^/blog/category/.*$;';
$regexp .= 'ga:pagePath!~^/blog/popular/.*$;';
$regexp .= 'ga:pagePath!~^/blog/2[0-9]+/.*$;';
$regexp .= 'ga:pagePath=~^/blog/[^/]+/gallery[0-9]+/index\.html$';
$url = 'https://www.google.com/analytics/feeds/data';
$url .= "?prettyprint=true";
$url .= "&ids=$res_hash->{'feed'}{'entry'}[0]{'dxp:tableId'}";
$url .= "&metrics=ga:visits,ga:pageviews";
$url .= "&start-date=$date_start";
$url .= "&end-date=$date_end";
$url .= "&dimensions=ga:pagePath";
$url .= "&sort=-ga:visits,-ga:pageviews";
$url .= "&max-results=30";
$url .= "&filters=".uri_escape($regexp);
$res = $ua->request(
    HTTP::Request::Common::GET(
        $url, 'Authorization' => "GoogleLogin Auth=$cl{'Auth'}"
    )
);
$res_hash = $treepp->parse( $res->content );
$treepp->writefile( '*****', $res_hash );
外部リンク

URL内の“_(アンダーバー)”と“-(ハイフン)”の使い方

2011年01月08日 11時52分

昨年4月におこなったサイトリニューアルの際、URLだけでも大体どんなページか分かるようにと各エントリーのURLを英文っぽくしました。

といっても英語はチンプンカンプンなので、機械翻訳で試しながら単語を並べているだけなのですが(笑)。その単語の区切りは“_(アンダーバー)”を使い、固有の名前で複数の単語の場合には“-(ハイフン)”を使って繋がりが分かるようにしています。

ナゼこうしたのか特にこれといった理由はありません(汗)。自分はプログラミングをかじっているので、変数や関数などの名前をアンダーバーで区切る癖があり、それが影響しているのだと思います。

違っていた！

ところが数日前、いつものようにネット検索をしていて知った衝撃の事実がありました。なんと、アンダーバーのほうが単語を連結する場合に使い、反対にハイフンは単語を分離する場合に使うというのが正しい使い方のようなのです。自サイトの使い方と逆だったとは…もう少し早く知るべきでした。

検索すると関連記事が色々あり、検索エンジンによっては両者を区別するものもあるということなので、SEO的には少し気になってしまうところです。とはいえ自サイトの場合は完全に日本語サイト、その影響も少ないのかなという感じもします。それ以前に英語そのものの使い方が残念な感じですから(笑)。

そんなこんなで修正が面倒というのもあり、今後もアンダーバーで区切ってゆくことに。新年一発目だというのにこのグダグダ感…今年も先が思いやられます(汗)。

ちなみに今回、“アンダーバー”という呼び方が和製英語であることをWikipediaで初めて知りました。

外部リンク

ギャラリーページの見せ方を考える

2011年04月04日 18時44分

来たるべきGoogleのパンダ・アップデートに備えて？

いつものようにネットを見ていたところ、気になる情報が。

上記リンク先にもあるように、米国ではすでに導入済のパンダアップデート。改良も続けられているみたいです。ノイズとなる質の低いコンテンツや薄っぺらいコンテンツが検索結果に出てこなくなるのは、使うほうからしてみれば嬉しい限りでしょうね。

そしてこのパンダアップデート、日本にも導入されるかもしれないという事なので、今回を機に自サイトはどうだろうと一通り見返してみると…自サイトのコンテンツは一様に質が低いような(笑)。更新は遅いし、ほとんど自分のために書いている感じなので分かりにくく、メインコンテンツに関しては低俗と思われても不思議ではありません(汗)。

気をとりなおして、今度は薄っぺらいコンテンツがあるか見てゆくことに。すると、各ストーリーのギャラリーページはFlash製のプレーヤーが1個、どんと置いてあるだけなので、これは人間以外から見たらとりわけ薄っぺらいだろうなと思いました。

いちおうGoogleのクローラーはSWF形式のファイルを見ているようですし、プレイリスト用に使っているXMLファイルもインデックスされることを確認していますが、これらはギャラリーページそのものではないので少し見せ方を変えてみようかと。

ギャラリーデータを出来るだけテキスト化してみる

しばらくあーだこーだ考えていましたが、今までのようにギャラリーデータをXMLファイルで持っておくのは変わらないものの、それをプレーヤーへ渡さずblosxomにギャラリーページとして展開させるように。そして動画や画像はあくまで単体ファイルとしてリンクを張り、個別にプレーヤーへ渡すことにしました(ちなみにプレーヤー専用ページもbloxsomを使用しています)。また、トランスクリプションではないものの、字幕データがある動画は自動でページ中に埋め込むようにもしてみました。

今後はExifなどの撮影情報がある場合にも自動で埋め込めるようにしたいですね。今回の改造でblosxomの自作プラグインがさらにスパゲッティ化、そろそろコードを整理しないとヤバい(笑)。

いちばん大切なこと

個人的には早く日本にもパンダアップデートを導入してほしいですね。その結果、たとえ自サイトがGoogleのインデックスから削除されたとしても、今あるコンテンツは自分が好きでやっている事なので絶対に消したりはしないでしょう。正直なところ検索結果は気になります。とはいえ、質はともかくとして(汗)コンテンツを充実させること自体はパンダアップデートの導入いかんにかかわらず大切な事だと思うので、そういう意味でも今回は自サイトについて考える良いきっかけとなりました。

気づけば3回目のサイトリニューアルをしてからはや1年、これからも地道に更新を続けてゆきます！

ギャラリーの各ファイル情報を自動展開する！

2011年04月12日 14時42分

Image::ExifToolを使って

字幕情報が自動展開できるようになったので、今度は画像ファイルのExif情報を取得できる便利なPerlモジュールがないかなと探していたところ、良さげなものを見つけました。

このImage::ExifTool、名前からイメージする以上に色々なファイル形式に対応していて、画像のExif情報はもちろん動画にも対応しています。また、PurePerlなのでインストールせず使えるのも手軽で良いですね。今回は動的に使わずImage::ExifToolから得た情報をひとまずXMLに変換しておいて、それをblosxomが展開する流れでやってみることに。

実行用antターゲット

入力と出力、2つのファイルパスをPerlスクリプトへ渡しています。実行にはbatchantを使用しました。

<target name="fileinfo2xml">
    <exec executable="/xampp/perl/bin/perl.exe">
        <arg line="-I ${basedir}/perl/lib" />
        <arg line="${basedir}/perl/fileinfo2xml.pl ${batchant.input.file} ${batchant.input.file}.info.xml" />
    </exec>
</target>
Perlスクリプト(fileinfo2xml.pl)

入力ファイルから得た情報をXML形式で出力ファイルに書き出すスクリプトです。得られる情報のグループごとに要素を分けようと、全グループを取得して力まかせにブン回しているのですが、これはもっと上手い方法があるような気がします(汗)。

use strict;
use warnings;
use lib qw(./lib);

use XML::TreePP;
use Image::ExifTool qw(:Public);

#引数を受け取る
my ($path_in, $path_out) = @ARGV;

#ファイル情報取得
my %opts = (
    ##バイナリデータが入る要素などは除外
    'Exclude' => [
        'JpgFromRaw',     'DataDump',
        'ThumbnailImage', 'PreviewImage',
        'Directory',      'FilePermissions',
        'HandlerDescription', 'Palette'
    ],
    ##日時フォーマットを変更
    'DateFormat' => '%Y-%m-%d %H:%M:%S',
);
my @tags       = ();
my $group_tree = {};
foreach my $group ( Image::ExifTool::GetAllGroups(0) ) {
    $opts{'Group'} = $group;
    $group_tree->{$group} = ImageInfo( $path_in, \@tags, \%opts );
}

#書き出し
my $treepp = XML::TreePP->new( 'indent' => 4 );
$treepp->writefile( $path_out, { 'info' => $group_tree } );
実行結果の例
画像ファイルの場合

たくさんのグループがありますが、どのファイルも必ずFileグループへ何らかの情報が入るようですね。そして、ExifがあればEXIFグループへ、PNG形式ならPNGグループへといった感じで追加されています。また、自環境ではカメラやRAW現像ソフトによって、得られる情報にばらつきが見られました。取得したExif情報は、blosxomがギャラリーページ内で展開します。

<?xml version="1.0" encoding="UTF-8" ?>
<info>
    <AFCP />
    <AIFF />
    <APE />
    <APP0 />
    <APP12 />
    <APP13 />
    <APP14 />
    <APP15 />
    <APP4 />
    <APP5 />
    <APP6 />
    <APP8 />
    <ASF />
    <CanonVRD />
    <Composite>
        <Aperture>8.0</Aperture>
        <CircleOfConfusion>0.018 mm</CircleOfConfusion>
        <FOV>47.4 deg</FOV>
        <FocalLength35efl>24.2 mm (35 mm equivalent: 41.0 mm)</FocalLength35efl>
        <HyperfocalDistance>4.13 m</HyperfocalDistance>
        <ImageSize>720x1080</ImageSize>
        <LightValue>14.0</LightValue>
        <ScaleFactor35efl>1.7</ScaleFactor35efl>
        <ShutterSpeed>1/250</ShutterSpeed>
    </Composite>
    <DICOM />
    <DNG />
    <DV />
    <DjVu />
    <Ducky />
    <EXE />
    <EXIF>
        <ApertureValue>8.0</ApertureValue>
        <BitsPerSample (1)>8</BitsPerSample (1)>
        <Compression>Uncompressed</Compression>
        <DateTimeOriginal>2011-01-01 07:02:34</DateTimeOriginal>
        <ExifVersion>0221</ExifVersion>
        <ExposureCompensation>0</ExposureCompensation>
        <ExposureProgram>Aperture-priority AE</ExposureProgram>
        <ExposureTime>1/250</ExposureTime>
        <FNumber>8.0</FNumber>
        <FocalLength>24.2 mm</FocalLength>
        <FocalLengthIn35mmFormat>41 mm</FocalLengthIn35mmFormat>
        <ISO>100</ISO>
        <ImageHeight (1)>2612</ImageHeight (1)>
        <ImageWidth (1)>1741</ImageWidth (1)>
        <LensInfo>24.2mm f/?</LensInfo>
        <LensModel>24.2 mm</LensModel>
        <Make>SIGMA</Make>
        <MaxApertureValue>14.0</MaxApertureValue>
        <MeteringMode>Average</MeteringMode>
        <Model>SIGMA DP2S</Model>
        <ModifyDate>2011-01-01 07:02:34</ModifyDate>
        <Orientation>Horizontal (normal)</Orientation>
        <PhotometricInterpretation>RGB</PhotometricInterpretation>
        <PlanarConfiguration>Chunky</PlanarConfiguration>
        <ResolutionUnit>inches</ResolutionUnit>
        <SamplesPerPixel>3</SamplesPerPixel>
        <ShutterSpeedValue>1/250</ShutterSpeedValue>
        <Software>RawTherapee</Software>
        <XResolution>300</XResolution>
        <YResolution>300</YResolution>
    </EXIF>
    <ExifTool />
    <FLAC />
    <File>
        <BitsPerSample>8</BitsPerSample>
        <ColorComponents>3</ColorComponents>
        <EncodingProcess>Baseline DCT, Huffman coding</EncodingProcess>
        <ExifByteOrder>Little-endian (Intel, II)</ExifByteOrder>
        <FileModifyDate>2011-01-30 06:37:00</FileModifyDate>
        <FileName>SDIM0011.jpg</FileName>
        <FileSize>104 kB</FileSize>
        <FileType>JPEG</FileType>
        <ImageHeight>1080</ImageHeight>
        <ImageWidth>720</ImageWidth>
        <MIMEType>image/jpeg</MIMEType>
        <YCbCrSubSampling>YCbCr4:4:4 (1 1)</YCbCrSubSampling>
    </File>
    <Flash />
    <FlashPix />
    <Font />
    <FotoStation />
    <GIF />
    <GIMP />
    <GeoTiff />
    <H264 />
    <HTML />
    <ICC_Profile />
    <ID3 />
    <IPTC />
    <ITC />
    <JFIF>
        <JFIFVersion>1.01</JFIFVersion>
        <ResolutionUnit (1)>inches</ResolutionUnit (1)>
        <XResolution (1)>72</XResolution (1)>
        <YResolution (1)>72</YResolution (1)>
    </JFIF>
    <JPEG />
    <Jpeg2000 />
    <LNK />
    <Leaf />
    <M2TS />
    <MIE />
    <MIFF />
    <MNG />
    <MPC />
    <MPEG />
    <MPF />
    <MXF />
    <MakerNotes />
    <Matroska />
    <Meta />
    <PDF />
    <PICT />
    <PNG />
    <PSP />
    <PhotoMechanic />
    <Photoshop />
    <PostScript />
    <PrintIM />
    <QuickTime />
    <RAF />
    <RIFF />
    <RSRC />
    <RTF />
    <Rawzor />
    <Real />
    <SVG />
    <SigmaRaw />
    <Stim />
    <Vorbis />
    <XML />
    <XMP />
    <ZIP />
</info>
動画ファイルの場合

Image::ExifToolモジュールは動画情報も取得できます。自環境ではFLV形式よりもMP4形式のほうが得られる情報が多かったです。

<?xml version="1.0" encoding="UTF-8" ?>
<info>
    <AFCP />
    <AIFF />
    <APE />
    <APP0 />
    <APP12 />
    <APP13 />
    <APP14 />
    <APP15 />
    <APP4 />
    <APP5 />
    <APP6 />
    <APP8 />
    <ASF />
    <CanonVRD />
    <Composite>
        <AvgBitrate>1.71 Mbps</AvgBitrate>
        <ImageSize>640x360</ImageSize>
        <Rotation>0</Rotation>
    </Composite>
    <DICOM />
    <DNG />
    <DV />
    <DjVu />
    <Ducky />
    <EXE />
    <EXIF />
    <ExifTool>
        <ExifToolVersion>8.50</ExifToolVersion>
    </ExifTool>
    <FLAC />
    <File>
        <FileModifyDate>2010-07-24 00:00:00</FileModifyDate>
        <FileName>00007.MTS.mp4</FileName>
        <FileSize>18 MB</FileSize>
        <FileType>MP4</FileType>
        <MIMEType>video/mp4</MIMEType>
    </File>
    <Flash />
    <FlashPix />
    <Font />
    <FotoStation />
    <GIF />
    <GIMP />
    <GeoTiff />
    <H264 />
    <HTML />
    <ICC_Profile />
    <ID3 />
    <IPTC />
    <ITC />
    <JFIF />
    <JPEG />
    <Jpeg2000 />
    <LNK />
    <Leaf />
    <M2TS />
    <MIE />
    <MIFF />
    <MNG />
    <MPC />
    <MPEG />
    <MPF />
    <MXF />
    <MakerNotes />
    <Matroska />
    <Meta />
    <PDF />
    <PICT />
    <PNG />
    <PSP />
    <PhotoMechanic />
    <Photoshop />
    <PostScript />
    <PrintIM />
    <QuickTime>
        <AudioBitsPerSample>16</AudioBitsPerSample>
        <AudioChannels>2</AudioChannels>
        <AudioFormat>mp4a</AudioFormat>
        <AudioSampleRate>48000</AudioSampleRate>
        <Balance>0</Balance>
        <BitDepth>24</BitDepth>
        <CompatibleBrands>isom, avc1</CompatibleBrands>
        <CompressorID>avc1</CompressorID>
        <CreateDate>2010-04-17 23:58:37</CreateDate>
        <CurrentTime>0 s</CurrentTime>
        <Duration>0:01:30</Duration>
        <GraphicsMode>srcCopy</GraphicsMode>
        <HandlerType>Audio Track</HandlerType>
        <HandlerType (1)>Video Track</HandlerType (1)>
        <ImageHeight>360</ImageHeight>
        <ImageWidth>640</ImageWidth>
        <MajorBrand>MP4  Base Media v1 [IS0 14496-12:2003]</MajorBrand>
        <MatrixStructure>1 0 0 0 1 0 0 0 1</MatrixStructure>
        <MatrixStructure (1)>1 0 0 0 1 0 0 0 1</MatrixStructure (1)>
        <MatrixStructure (2)>1 0 0 0 1 0 0 0 1</MatrixStructure (2)>
        <MediaCreateDate>2010-04-17 23:58:37</MediaCreateDate>
        <MediaCreateDate (1)>2010-04-17 23:58:37</MediaCreateDate (1)>
        <MediaDuration>0:01:30</MediaDuration>
        <MediaDuration (1)>0:01:30</MediaDuration (1)>
        <MediaHeaderVersion>0</MediaHeaderVersion>
        <MediaHeaderVersion (1)>0</MediaHeaderVersion (1)>
        <MediaLanguageCode>und</MediaLanguageCode>
        <MediaLanguageCode (1)>und</MediaLanguageCode (1)>
        <MediaModifyDate>2010-04-17 23:58:37</MediaModifyDate>
        <MediaModifyDate (1)>2010-04-17 23:58:37</MediaModifyDate (1)>
        <MediaTimeScale>48000</MediaTimeScale>
        <MediaTimeScale (1)>60000</MediaTimeScale (1)>
        <MinorVersion>0.0.1</MinorVersion>
        <ModifyDate>2010-04-17 23:58:37</ModifyDate>
        <MovieDataSize>19311721</MovieDataSize>
        <MovieHeaderVersion>0</MovieHeaderVersion>
        <NextTrackID>3</NextTrackID>
        <OpColor>0 0 0</OpColor>
        <PosterTime>0 s</PosterTime>
        <PreferredRate>1</PreferredRate>
        <PreferredVolume>100.00%</PreferredVolume>
        <PreviewDuration>0 s</PreviewDuration>
        <PreviewTime>0 s</PreviewTime>
        <SelectionDuration>0 s</SelectionDuration>
        <SelectionTime>0 s</SelectionTime>
        <SourceImageHeight>360</SourceImageHeight>
        <SourceImageWidth>640</SourceImageWidth>
        <TimeScale>600</TimeScale>
        <TrackCreateDate>2010-04-17 23:58:37</TrackCreateDate>
        <TrackCreateDate (1)>2010-04-17 23:58:37</TrackCreateDate (1)>
        <TrackDuration>0:01:30</TrackDuration>
        <TrackDuration (1)>0:01:30</TrackDuration (1)>
        <TrackHeaderVersion>0</TrackHeaderVersion>
        <TrackHeaderVersion (1)>0</TrackHeaderVersion (1)>
        <TrackID>1</TrackID>
        <TrackID (1)>2</TrackID (1)>
        <TrackLayer>0</TrackLayer>
        <TrackLayer (1)>0</TrackLayer (1)>
        <TrackModifyDate>2010-04-17 23:58:37</TrackModifyDate>
        <TrackModifyDate (1)>2010-04-17 23:58:37</TrackModifyDate (1)>
        <TrackVolume>0.00%</TrackVolume>
        <TrackVolume (1)>100.00%</TrackVolume (1)>
        <VideoFrameRate>59.94</VideoFrameRate>
        <XResolution>72</XResolution>
        <YResolution>72</YResolution>
    </QuickTime>
    <RAF />
    <RIFF />
    <RSRC />
    <RTF />
    <Rawzor />
    <Real />
    <SVG />
    <SigmaRaw />
    <Stim />
    <Vorbis />
    <XML />
    <XMP />
    <ZIP />
</info>

と、こんな感じで今回は特に問題も無くできたものの、実際に組み込んでギャラリーページを確認していると、Exif情報の無い画像があまりに多かったです(汗)。単なるつけ忘れや、写真を始めて間もないころはJPEG形式との画質の差を気にするあまりPNG形式ばかりにしていたので、ここらへんは置き換えたりするなど今後なんとかしないとダメですね。

コメント機能も少し手入れ

それから、もはや“空気”と化している当サイトのコメント機能ですが(笑)、しばらくぶりにGoogleサイドウィキについてチェックしてみると、なんだか便利そうなAPIが用意されていたので、これもついでとサイドバー方式を使ってみることにしました(もしかしたら気づいていなかっただけなのかも(汗))。

今まではblosxomがAPIを使ってコメントを取得、あたかもサイト内コンテンツのように表示していましたが、これからはツイッターと同じような切り離した感じで扱うように。現在もログインせずの投稿はできませんが、まだまだ自分はサイドウィキを使い続けます(汗笑)。

自サイトのアフィリエイト部分を再考→巨像密林オープン

2011年06月16日 23時59分

自サイトでは、各ページの上と下にGoogleやAmazonの広告を表示する部分があります。

ありますが…全くといっていいほど収益というものは無く、もはやページのアクセントみたいな感じになってますね(笑)。今までは用意されたリンクをただ使っていただけだったというのもあって、せっかくだから自分なりにアフィリエイト部分を変えてみようかなと、ここ1ヶ月くらいあーだこーだして“巨像密林”というコンテンツを作ってみました。

きっかけはAmazonの画像サーバ

ある日いつものようにネット検索していると、Amazonの画像用HTTPサーバが面白い機能を持っていることを知ります。この機能は非公式なものの、商品画像の大きさを変えたり文字入れや切り抜き、さらにはシャープネスをかけたりといったことなども色々とサーバー側でできるもよう。

また、一部のAmazon商品にはとても大きな画像が用意されていることも知り、1000ピクセルを超える商品画像を最初に見たときは少し驚きました(通常だと500ピクセルが最大)。他のかたの関連記事をみていると、これらの機能はだいぶ前から発見されていたようですね。あいかわらず自分は気づくのが遅すぎです(汗)。

今回Amazon画像サーバのさまざまな機能を知ったことで、これを使って何かできないかなというのに加え、大きい画像が手軽に見られるといいのになという自分の願望も加わって(汗笑)、さっそく何かしら作ってみることにしました。

大きな画像のURLを作るにはASINが必要なので、まずは商品情報を得る必要があります。Amazonの商品情報を取得するには"Product Advertising API”を使いますが、このAPIは以前、2回目のサイトリニューアル時にも使っていて、当時はアクセスした記事に関連するワードの商品情報をItemSearchオペレーションで取得していたでしょうか。そんなこともあってか今回はスムーズに作り始めることができました。

BrowseNodeLookupリクエスト処理部分のPerlスクリプト(一部は伏字*****)

あいかわらず汚いコードです(汗)。


use URI::Escape;
use POSIX qw(strftime);
use Digest::SHA::PurePerl qw(hmac_sha256_base64);
use HTTP::Lite;

#引数を受け取る
my ( $country, @bnid ) = @ARGV;    ## 国,ブラウザノードID

#共通設定
require "global.pl";

#BrowseNodeLookupリクエスト処理
my %param = (
    'AWSAccessKeyId' => "*****",
    'Service'        => "AWSECommerceService",
    'Version'        => "2010-11-01",
    'Timestamp'      => strftime( "%Y-%m-%dT%H:%M:%SZ", gmtime ),
    'Operation'      => "BrowseNodeLookup",
);
$param{'ResponseGroup'} = join ",",
  (
    "BrowseNodeInfo", "NewReleases", "TopSellers", "MostWishedFor",
    "MostGifted"
  );
$param{'BrowseNodeId'} = join ",", @bnid;
$param{'AssociateTag'} = $::ecs->{$country}{'associate_tag'}
  if ( exists $::ecs->{$country}{'associate_tag'} );
##パラメータを
my $param =
  join( "&", map { "$_=" . uri_escape( $param{$_} ) } ( sort keys %param ) );
##署名を
my $signature = hmac_sha256_base64(
    "GET" . "\n"
      . $::ecs->{$country}{'server_api'}{'host'} . "\n"
      . $::ecs->{$country}{'server_api'}{'dir'} . "\n"
      . $param,
    "*****"
);
$signature .= "=" x ( 4 - length($signature) & 3 );
$signature = uri_escape($signature);
##リクエスト
my $url = "http://"
  . $::ecs->{$country}{'server_api'}{'host'}
  . $::ecs->{$country}{'server_api'}{'dir'} . "?"
  . $param . "&"
  . "Signature=$signature";
my $http = new HTTP::Lite;
my $req = $http->request($url) or die;
避けては通れぬライセンス

このAPIのライセンスについてチェックしておかねばなりません。見ていて最も気になったのは、取得するデータについての項目でしょうか。

利用条件 : Product Advertising API ライセンス契約
(n) お客様は、画像で構成される商品関連コンテンツを格納またはキャッシュしてはいけませんが、画像で構成される商品関連コンテンツへのリンクを、24時間まで格納することができます。お客様は、画像で構成されていないコンテンツを、データキャッシュの目的で、24時間まで格納することができますが、それをした場合は、その後直ちに Product Advertising API にリクエスト送信を行うか、または新しいデータフィードを取り込み、お客様のアプリケーション上の商品関連コンテンツを刷新することにより、商品関連コンテンツを直ちに刷新し、再表示しなければなりません。別途当方より通知されない限り、お客様は、個別の Amazon Standard Identification Number （以下、「ASIN」といいます）を、本ライセンス契約の終了まで、期間の制限なく格納することができます。前述に拘わらず、お客様のアプリケーションがクライアント アプリケーションを含む場合、かかるクライアントアプリケーションは、商品関連コンテンツを格納またはキャッシュしてはいけません。当方の要求があれば、お客様は、当方の要求から3営業日以内に、お客様が本ライセンス契約を遵守しているかを確認できるよう、かかるクライアントアプリケーションのコピーを当方に提供するものとします。

https://affiliate.amazon.co.jp/gp/advertising/api/detail/agreement.htmlより引用(2011年6月14日15時16分に取得)。

画像データの保存がダメなのは当前ですが、ASINを除いた、画像データ以外の全データのキャッシュが24時間までという制限まであります…。加えて、24時間以内のデータであっても、例えばそのデータを使っているページにアクセスがあった場合、再リクエストしてキャッシュデータを早めに更新させる必要がありそうです(これらは自分の勝手な解釈なので間違っているかもしれません)。

取得データのキャッシュは24時間まで…む、今回できるだけ多くの商品を表示させたく、ブラウズノード(商品グループみたいなもの)について下調べしていた頃、ブラウズノードってどのくらいあるんだろうとツリーの一番上から順にたどっていったことがあるのですが、日本のAmazonだけでも恐ろしく大量にあるようでした。1回のリクエストでブラウズノード情報を10個まで取得できるものの、24時間以内に全てのブラウズノードを巡るのは、実行時間に制限がある共用サーバ1つじゃ難しそうです(笑)。

そこで今回はチケット方式とでもいうのでしょうか。選んだ商品グループを取得する予約チケットみたいなものを発行して、順番にそのデータを取ってくるような方法にしました。もちろん取得したデータキャッシュは24時間以内に消すようにしています。ページにアクセスした場合は、関連する商品グループデータを更新するためチケットをそのつど発行するようにもしました。本当は1ヶ月くらい溜め込んで、商品グループのツリーをズラーっと眺めてみたかったものの、とりあえず自分でも実現できそうな方法で先へ進むことに。

また、当初はサーバ側でHEADリクエストを使い、大きな画像がある商品だけを表示しようかなと考えていましたが、APIライセンスを見ていると次のような項目がありました。

利用条件 : Product Advertising API ライセンス契約
(i) お客様は、当方が事前に明示の書面による同意なしに、商品関連コンテンツを統合、分析、抽出もしくは再利用する目的で、または、アマゾンサイト上で販売をしている個人または事業体による利用を意図したソフトウェアもしくはその他のアプリケーションに関連して、Product Advertising APIまたはデータフィードにアクセスまたはこれを使用してはいけません。

https://affiliate.amazon.co.jp/gp/advertising/api/detail/agreement.htmlより引用(2011年6月14日15時16分に取得)。

特定の条件を満たすものだけ表示っていうのは、やっぱり“商品関連コンテンツの抽出”にあたるかなと思ったので、取得したデータは全部使うことにしました(同じく勝手な解釈なので間違っているかもしれません)。すると、大きな画像が用意されていない商品ではテキストだけになってしまうため、これはイカンと新たなPerlスクリプトでOperationをItemLookup、ResponseGroupをImagesでリクエストし商品ごとの画像リンクを取得、どの商品にもできるだけ画像が表示されるようにしてみました。これもまたキャッシュデータなので、商品グループのそれと同じく24時間以内に消しています。

さらに、レスポンスグループ(ベストセラーや新着リリースなど)をまとめて表示しようかなとも当初考えていて、その際、重複する商品は除去しておきたかったのですが、これも“商品関連コンテンツの統合”にあたりそうな気がしたので、取得した全てのレスポンスグループはまとめず、URLを分けてそのまま使うことにしました。

ほかにもライセンスを見ると、ドメイン名やドメイン名の左側には使ってはダメなワードがあるとか、免責事項や商標をページの見えるところに表示するといったことなど、いろいろ気をつけることがありそうですね。

商品画像重視で

ページの構築には、使い慣れているblosxomを使用。といってもblosxomが持つ機能はほとんど使っていないのですが、ついついテンプレートエンジン感覚で使ってしまいます(汗笑)。ページのデザインやナビゲーションについては、できるだけ商品画像に注目してもらえるよう、色を使わずシンプルな使い勝手となるよう意識しました。

表示する商品画像は通常の500ピクセルまでのものと、前述したAmazon画像サーバの機能を使って巨大画像を余白つき長辺960ピクセル(_SCRMZZZZZZ_AA960_.jpg)にしています。ページ右側の部分ではMAIN以外の巨大画像(ANGLE、PIECE、INTERIOR)もコンボボックスで選べるようにして、それぞれをマウスオーバーで入れ替えられるようにしてみました。巨大画像が用意されていない商品の場合、この部分には何も表示されません(画像サーバーからは1ピクセル四方のGIF画像が返ってきているもよう)。

今回はページ中に多くの画像を載せるため、一気に表示してしまうと画像サーバに負荷がかかると思ったので、JavaScriptを使って表示タイミングをずらすだけの、遅延ロードっぽい事をやっています。自分はJavaScriptが苦手なので、いつもJQueryに頼りきり(汗)。今回も便利なライブラリがあったので助かりました。

それから、いきなり画像が表示されてしまうのを防止するため、ローテクかもしれませんがURLの一部にハッシュ値を入れて一定期間でコロコロ変わるようにし、ハッシュ値が無い、もしくはハッシュ値が古いURLでアクセスした場合にはクッションページを表示させています。このハッシュ値は、同じクライアントからデータ取得チケットが続けて発行されないようにするための限定的なIDとしても機能します。本当は全部セッション管理すればいいのでしょうが…メンドい(汗)。

ハッシュ値を求める関数

IDといっても、クライアントのIPアドレスとURL内の国コード、それから時間情報を混ぜて暗号化しているだけの限定的なものです。

sub get_hash {
    return hmac_sha1_hex(
        "$ENV{'REMOTE_ADDR'}$zzz::url_country" . ( time >> $zzz::hash_cycle ),
        $zzz::hash_seed );
}

最終的に、商品グループ情報を取得するスクリプトと商品情報を取得するスクリプト、それから、この2つのスクリプトを使ってやるチケット処理やキャッシュの削除などをおこなうマネージャースクリプトという3つのPerlスクリプトに落ち着きました。そしてサーバーのcronデーモンでマネージャースクリプトを走らせ、取得したキャッシュデータをblosxomが表示しているといった感じです。

あとは、ブログのエントリーに関係ありそうなブラウズノードIDをAmazonサイトなどから調べてきて、アフィリエイト部分に巨像密林へのリンクをはり、ひととおり完了なはずです。

なんとか形になったような

と、こんな感じでライセンスとにらめっこしながら、あーだこーだ修正しつつ作っていきました。でも完成したサイトをあらためて見ると…なんだかフツーになっちゃった気がしないでもないでしょうか(笑)。とはいえ無償でAPIが使わせてもらえるぶん、色々と制限があるのは仕方のないことです。ライセンス関連は不安なものの、ひとまず稼動してみることに。データベースを使っていないので処理速度が心配(汗)。このままうまく動き続けてくれるといいな～。

そういえばこのサイト“クロイワサンニ”も「エロいアフィリエイトでもやってみようかな～」というのがきっかけでサイトオープンしたのが始まりでした。当時は用意されたサンプル動画を自宅サーバでストリーミング配信なんてやっていましたが、たんに「自分が見たかった」という思いが強かったですね(汗)。

今回作った巨像密林にしても、「いろんな商品の大きな画像を手軽に見てみたい！」という己の欲望がエネルギー源だったとはいえ、あたり前ですが“販売促進のために”というのが何といっても重要ですよね。アクセス数の少ないブログですが、このコンテンツが少しでもAmazonのためになってくれれば良いですね…自サイトの収益もちょっと増えますように(汗笑)。

関連リンク
Product Advertising API

APIリファレンスなどです。バージョンが少し前の日本語版があったので、とても助かりました。

BrowseNodeLookup[JP]

このサイトはAmazonの商品グループが網羅されているのでスゴいです。自分もこのサイトのようにツリー状にしたかったな～。ブラウズノードIDも一緒に表示されるのは地味に便利ですね。ちなみに、ブラウズノードIDはAmazonサイトのURLからでもわかります。

巨像密林にワード検索機能を追加、TwitterトレンドトピックAPIも、そしてGoogleサイドウィキ停止へ

2011年10月30日 20時23分

その後、ちょこちょこ手を加えてきた巨像密林。でも使っていて少し気になることが。

それは、お気に入りだった末端のブラウズノードが、統合されて無くなるのを何度か確認したのです。増えることはあっても消えはしないだろうと勝手に決めつけていたのが甘かったですね(汗)。存在しないブラウズノードIDでリクエストしても、レスポンスにはエラーが返ってくるのですぐ分かるのですが、そのつど新しいブラウズノードIDを見つけてきて修正するのは自分には面倒と感じてしまうのでした。

ワード検索をメインに

そんなこんなで、これからはブラウズノードを指定するのをやめ、巨像密林にItemSearchオペレーションを使ったワード検索機能を持たせてみることに。面倒なので今のところパラメータを全てURLに含められるようにしています。重要なパラメータは上書きされないように注意しました。

このItemSearchオペレーションは以前にも使った事があったため大丈夫かなと思っていましたが、「/(半角スラッシュ)」をURLエンコードした「%2F」の扱いに今回つまずきました。検索ワードなどでURL中にこの文字が含まれていると、エラーを返してきます。あーだこーだ調べていると、WWWサーバーであるApacheの問題らしく、回避策もいくつか見つかりました。

自分が使っているレンタルサーバのApacheはバージョン1系だったので、今回は上記リンク先にもある「%2F」を「%252F」として渡し、 サーバー側で元に戻してリクエストする方法にしてひとまず解決。今後は記事の中にも関連したワードで検索するようなリンクを入れてゆくことにしました。動作テストしていると、どこにこのワードがヒットしたんだろうと思ってしまうような商品が出る場合もあって面白いですね。

Twitter APIを使ってみる

また、ページ上下段のアフィリエイト部分も少し変えてみることにしました。まず、下段のアフィリエイト部分はやめてブログのメニュー項目をそこへ移動。そして上段アフィリエイト部分にはTwitterの流行トピックを表示して、さらに先ほどの巨像密林ワード検索機能と連携してみました。TwitterのAPIはたくさんありますが、今回使ったのは地域ごとの流行トピックを取得できる“Local Trends”です。

はじめに地域ごとのIDを取得。現時点だとJPコードのものは2個(日本と東京)あるようです。そして、このIDで流行トピックを取得するのですが、なぜかレスポンスデータがJSON形式のみでした。JavaScriptからならスムーズなのでしょうが、Perlメインの自分はXML形式で扱いたいのです。でもこの問題はすぐ解決。ありがたいことにPurePerlもOKな、JSON解析モジュールがありました。

あとは今までと同じく、cronで定期的にデータ取得するPerlスクリプトを実行しています。でもこの流行トピック、やたら長いワードもあるのでそのままだと商品検索にはちょっと不向きかもしれませんね(汗)。現時点ではリクエスト時にエラーが出ているものは検索リンクを張らないようにしています。GoogleやYahooの急上昇ワードと連携してみるのも面白そう。

Googleサイドウィキが提供終了

そして「ついに」というか「やっぱり」なのか、Googleサイドウィキが停止するもようです。

コメント機能にと使い始めて約1年半。結局、自サイトでは一つも書き込みが無いまま終わりを迎えることになりそう(笑)。とはいえコメント機能を自前で管理するのは色々面倒なので、今後も別の面白そうなサービスがあれば使ってゆきたいですね。でもしばらくはTwitterだけでいいかな？

自サイトのメディアファイル表示用ページを新調

2014年04月20日 00時56分

ツイッターの画像付き投稿がなぜか失敗する
TwitterCardsに翻弄される

当初はTwitterCardsを埋め込んだページURLをツイッターに投稿すれば画像が表示されるから、これは画像付きツイートのかわりになるかなと思っていました。でもツイッター公式サイトの左カラムにあるフォトギャラリーに表示されなくて、ちょっと残念。

いつのまにか失敗しなくなっていた

あーだこーだしているうちに、なぜか画像付きでもタイムアウトしなくなっていました(笑)。作ったメディアファイル表示用ページは無駄になってしまいそうですが勉強になったのでよしとします。

自分のツイートをブログへ埋め込むように

2014年05月26日 02時52分

きっかけは新プロフィールページ

今年4月。Twitterの新プロフィールページが自分のアカウントでは少し早めに使えるようになっていて、切り替えボタンを何も考えず押してしまいました(笑)。

いろいろと変更のあった新プロフィールページ。先頭部分に表示されるヘッダ画像もその一つでした。画像サイズが幅1500、高さ500ピクセルと、以前よりかなり大きくなっています。以前と同様、この新しいヘッダ画像もデジカメで撮ったものでよかったのですが、また同じなのもな～と、旧バージョンに戻すことも出来ないしで困っていました。

今年のツイートをまとめる

せっかくだからヘッダ画像を変えたい。でもこの大きさをどう使おうか。自分が見たアニメのタイトルでも書き込もうかな～等あーだこーだ考えたものの、最終的には今年のツイート内容を整理して画像に書き込んでみよう、となりました。

また、ちょっと前に自サイトのメディアファイル表示用ページを新調していた事もあって、これを流用したツイートまとめページも作ってみることに。関連するグループごとに分けたツイートをページに埋め込むだけのシンプルなものです。

まとめページを作ったのは、ツイートが増えてゆくと以前のツイートが埋もれてってしまうので、このヘッダ画像を見て興味をもった人が、関連するツイートをすぐ見られればいいのにな～と思ったのがはじまりでしょうか。もっとも、Twitterは本来こういう使い方はしないのかもしれませんが(汗)。

まとめきれず中断、ツイートはブログへ埋め込むように

こうして始まったツイートまとめページでしたが、内容を充実させるべくツイート数を増やしているとちょっと問題も…。それは、ただでさえ更新が少ない自ブログが益々おろそかになってしまうことでした。ブログのほうは何年も前から更新する気力が無い状態(汗)。更新スタイルを変えて、どうにかならないかなと考えていたのです。

加えて、当初は1年分のツイートを一つのページに埋め込んでも大丈夫だろうと思っていた自分。でも埋め込んだツイートが多くなってくると、ページの表示が遅く感じるようになってきました。

そんなこんなで「ブログの更新」と「ツイートのまとめ」を両立させようと、自分のツイートはブログ記事を作る「きっかけ」として使ってみることに。これなら埋もれてゆくツイートも目にとまりそうだし、ツイート日時がタイムスタンプがわりにもなって、ついでに追加する文章も少なくて済みそう…いや、これは単に長い文章を書きたくないだけですね(汗)。

ちょっと面倒だけど、ブログの更新はしやすくなった

ツイートを埋め込む際に以前から思っていたことなのですが、個別ツイートを探して1個ずつ埋め込み用データを取得するのが地味に面倒です。それでも、全ツイート履歴をダウンロードできることを知って、この作業もちょっとは楽になりました。月ごとに分かれていてツイートが見つけやすいし、キーワード検索もできるので便利です。

こんな感じで、少し面倒なところもありますが、ブログのためにツイートすると考えればTwitterも積極的に使えそうです。しばらくはこのスタイルでブログ更新してゆきます。

未整理

2015年11月08日 02時22分

未整理(2019年)

2019年06月06日 15時51分

ページ先頭まで移動

24キロダルトン, クロイワサンニ, ©2005 by クロイワサンニの代理人(961832p).
Powered by Blosxom, Hosted by XREA. Let’s Encrypt