ハブろぐ - havelog.ayumusato.com

LPO関連の機能

a-blog cmsのv1.3.0から本格的に実装されそうなLPO関連の機能について簡単に。検索エンジンからアクセスがあったときに、検索に使われていたキーワードを利用して、動的にランディングページのコンテンツを変える機能です。たとえば、弊社で制作中のサイトの404ページには、検索エンジンから404にきてしまったときに、検索に使われていたキーワードでサイト内検索した結果を表示するという実装(Ajax)がされています。

公開済みの例だと、株式会社マールさんが制作された、株式会社 JUNIOR【ジュニアー】さんのサイト（参考: 事例紹介）でも有名な機能です。このサイトのトップページに、検索エンジンからブランド名でランディングしたときは、そのブランドに関するコンテンツが表示されます。

検索ページじゃないと検証できない

そんな便利な一連の機能も、そもそも検索エンジンからアクセスしない限り、正常に動作しているかどうかは確認しようがありません。制作中のサイトでソレでは困ることも多いはず。

LPO機能の中核を成す、グローバル変数%{SEARCH_ENGINE_KEYWORD}には、検索エンジン（Google, Yahoo, Bing）からのアクセスがあった場合、検索に使用されていたキーワードが格納されます。この変数自体は、アクセス時のリファラを参照しているだけなので、リファラを任意の文字列に設定してしまえば、好きなように%{SEARCH_ENGINE_KEYWORD}の値を操作できるというわけです。

レッツ★改ざん

前置きが長くなりましたが、そんな事情により今回はリファラを任意に設定できるFirefoxのアドオンを紹介します。

リンク：refspoof :: Add-ons for Firefox

このrefspoofというアドオンは、任意のリファラーになりすましてサイトにアクセスできる機能を持っています。（別に悪いことしてるわけじゃないですよ！）スクリーンキャプチャの「ここでGoogleで検索したときのURLなどをセットします」という部分に、下のような検索ページのURLを貼り付けてみます。

おいしいりんご - Google 検索

おいしいりんご、というキーワードで検索したときのURLを貼り付けます。上のリンクをコピーするか、リンク先に飛んでからURLをコピーします。

a-blog cmsのサイトで実験

さて、a-blogcmsのサイトトップの下部にも検索ワードに反応する部分があります。これも、検索エンジンからアクセスがあると、使われたキーワードでサイト内検索をした結果を表示するようになっています。なので、手っ取り早くa-blog cmsのサイトで検証してみましょう！以下手順。

1. a-blog cmsのサイトにアクセス
2. 前項でGoogleの検索URLを貼り付けた欄の横のspoofをクリック
3. サイトの下部を確認してみましょう！

もちろんそんなキーワードのコンテンツはありませんでしたが、検索エンジンから飛んでるわけでもないのに、リファラーを操作してなりすますことができました。

これで、LPO関連機能の検証もバッチリですね！a-blog cmsで本格的に使うのは、v1.3.0からになりそうですが、今のうちにゼヒ導入してみてください。お役立ちツールです。

バカにするつもりが結構欲しくなった

参考：Apple - iPad - The best way to experience the web, email, ＆ photos

米アップルのサイトはとっくに更新されてるみたい。ビデオは必見。何言ってるか分からなくても利用シーンをなんとく見せてもらえると欲しくなる感じの製品。きっと、人が持ってるのを見ると、自分も欲しくなっちゃうような一番危ないタイプ。

地味にスペックいいなー。

参考：Apple - iPad - Technical specifications and accessories for iPad.

CPU

Apple A4 1Ghz

色

White, Black

サイズ

242.8mm x 189.7mm x 13.4mm（大体B5ノートぐらい）

ディスプレイ

9.7inch LED 1024x768px　（地味にIPSパネル）

保存容量

16GB・32GB・64GBのいずれか

バッテリー

公称10時間(！)

ネットワーク

Wifi, Blutooth

その他

VGA外部出力(？)・ボイススクリーンリーダー・加速度計・方位探知・環境光センサー・モノラル内蔵スピーカー・GPS対応(3Gモデルのみ)

デカいiPhoneであり、そうでなく

iPhone（＋Wifi使いまくりのiPod Touch）ユーザーからすると、デカいiPhoneに過ぎない印象だけど、実際はもちょっとエグい立ち位置だと思う。値段といい、サイズ感といい。

使う人次第

このあたりの特性はiPhoneも同じ。PDAにも、ゲーム機にも、ただの電話にもなりえる。そこから更に発展して、値段感とサイズ感が並んだことで、今度はネットブックあたりと用途や印象が近づいた。その上で他より魅力的な製品ってのがAppleらしい。薄いからカバンにも入れやすそう。

使う人次第でネットブックにもなるし、Kindleにもなるし、ゲーム・ビデオ・音楽のエンターテイメント機にもなる。何食わぬ顔で、他の製品の用途を良いトコ取りしようとしてる。さすがApple。後発のくせに、先発を蹴散らすプロだね！

ネットブック買うぐらいならiPad？

日本的には、Kindleは比較対象にならんけど、ネットブック買うぐらいならiPadかなー。という感じ。そうでなくても、家置きのお遊び端末にいいかな。

個人的には近親者で、家庭内シェアする端末として魅力的。ああオモチャ欲しい！キーボードドックいいなー！でも、四六時中MacBookとiPhone触ってる自分には無用の長物なんだろうなー！くそー！

日本の携帯を使ってる人

ケータイ＋αとして使うと、弱点が良い感じに補強できるかも

ネットブック使ってる人

ビジネス用じゃなければ、iPadのほうが楽しいかも（iWorksも一応あるみたいだけど）

iPhoneもっててネットブック使ってない人（俺）

たぶん不要・・・

とりあえず、これから溢れていくであろう評価を見つつ、様子見したいと思います。

Twitter API つーか OAuthと格闘

Twitter APIと遊ぶ機会があったので、もそもそと調べたり書いたりしてみました。OAuth部分の処理を書くのに少し時間がかかったり。既存品を使っても良かったのですが「その場の環境で動けば正義」というわけにもいかないので、処理を自分の制御下におくべく、OAuth部分の実装もゼロから書いてみました。

参考：APIアクセス権を委譲するプロトコル、OAuthを知る − ＠IT

そんときの調べごとをスピンアウト的にメモ

TwitterではOAuthでの認証を推奨？

むしろ、Basic認証はそのうち非推奨＆サポートしなくなるみたいですね。OAuthのほうがセキュアな気もしますけど、スパムにあっさり引っかかる人間の不注意がなくなるまではBasic認証のほうがセキュアじゃないんすか疑惑。

参考：Twitter APIのBASIC認証は2010年6月に「廃止予定」 - 頭ん中

APIの制限が150回ではない？

APIの回数制限がネックになるだろうなー、って思いましてAPIを叩ける回数について調べていました。したらば、公称の150回を超える回数で、回数制限対象のタイムライン系API( statuses/home_timeline.format, statuses/friends_timeline.format )を叩いていたら、150回を超えても一過性のタイムアウトを除いてちゃんと応答が返ってきている謎。

account/rate_limit_status という、現在の制限状態（残り回数とか制限がリセットされる時間とか）を教えてくれるAPIも並列で叩いてみたところ数字の推移が明らかにおかしいのです。

んで。

httpリクエストしてからレスポンスのヘッダーをとってみたら以下のような不思議な記述（抜粋）が。

string 'X-RateLimit-Limit: 450'
string 'X-RateLimit-Remaining: 306'

そしてその瞬間に account/rate_limit_status い問い合わせたところ

object(stdClass)[15]
  public 'reset_time' => string 'Tue Jan 12 12:23:27 +0000 2010'
  public 'remaining_hits' => int 102
  public 'hourly_limit' => int 150
  public 'reset_time_in_seconds' => int 1263299007

150回を超えてAPIを叩いてもちゃんと反応してくれたという事実を加味すると、どうも今の制限回数は公称値の3倍である450回に設定されているようです。remainingの値も、account/rate_limit_statusの値 *3 = http_request_headerの値 で安定しているので裏付けとなっているでしょう。

補足的に下の記事も、自分の仮説を支持してくれているようなので、ひとまず450回の制限を軸に考えていきます。もちろん、途中で150回に戻る可能性も考えなければいけませんが。

参考：Twitter API の Rate Limit が一部緩和？ - trial and error

おまけ＠TwitterとOAuth用のphpをかいたので

業務的にはきっと、a-blog cmsの中の組み込みシステムとして吸収されてしまうので、まだ独立性を保っているうちにコア部分だけ単品ファイルにして用意してみます。もう処理は書けてるので、サンプルファイル作ったら公開してみますね。

今度、ソレを使ってa-blog cmsでつくるTwitter BOTの作り方でも書いてみましょうか。もっと実用的にTwitter連携のGETモジュールでも書けたらそれでいいかな。

おまけ2＠a-blog cms でつくる Twitter BOT

今使っているロリポとかcron（指定プログラムを指定スケジュールで実行するヤツ）がないので、GETモジュールとしてBOTプログラムを起動させたらいいんじゃないかな、と。

検索エンジンのクローラーがアクセスしてくれれば、最低限の回数ぐらいは起動してくれるはず。逆にアクセス過多な場合でも、キャッシュの残存時間を調整すればいいんじゃないかしら。