GANCHIKU.com

ソーシャル系サービスのリンク数取得について

2012年1月21日

個人的にはあまり積極的には使っていないのですが、Facebookの「いいね」Google+の「+」Twitterの「ツイート数」はてなの「はてブ数」などは、URLに対して行うことができ、そのサイトを見るにあたって参考にするということがあると思います。また、各サービス側では、そのリンク数を表示するウィジェットを用意しており、ホームページのヘッダ等に組み込むことが結構ありますね。
このブログ自体には組み込んでいないですが、まぁ、そのうちに組み込むかもしれないです。たまにはデザインを見なおした方がいいかな、とも思ってるので。

というわけで、それらのサービスのリンク数を取得する方法をちょっと調べてみたついでにブログを書いてみます。

はてなのブックマーク数

みんな大好きはてなさんのサービスです。ブックマーク数に関しては公式APIがありました。

        $url = "http://www.yahoo.co.jp/";
        $url = "http://api.b.st-hatena.com/entry.count?url=" . urlencode($url);
        $data = file_get_contents($url);
        if ($data) {
            echo $data;
        }

ちなみに結果は11400になりました。すごく簡単ですね。

Facebookのいいね数

これも調べたらすぐわかりました。こちらも公式APIになります。まぁ、簡単な例がありましたのでこちらのサイトを参考にしても良いでしょう。[PHP]FacebookのAPIを使って、特定のURLのいいね数を取得する

        $url = "http://www.yahoo.co.jp/";
        $fql = urlencode('SELECT total_count FROM link_stat WHERE url="' . $url . '"');
        $data = file_get_contents('https://api.facebook.com/method/fql.query?query=' . $fql);
        if ($data) {
            $xml = simplexml_load_string($data);
            echo (int)$xml->link_stat->total_count;
        }

ちなみに結果は、11550となります。

Twitterのツイート数

これもググればやっている人が何人かいるので、すぐできます。ただ、どうやらこれは公式のものではないので、変更されてしまう可能性もあります。ここでも、また、ここでも公式じゃないから、それを理解してやってね、的な話になっています。

        $url = "http://www.yahoo.co.jp/";
        $url = "http://urls.api.twitter.com/1/urls/count.json?url=" . urlencode($url);
        $data = file_get_contents($url);
        if ($data) {
            $object = json_decode($data);
            echo $object->count;
        }

ちなみに52704でした。

Google+の+数

なんて読むわからないw これですが、これもググればわかるのですが、あまり日本の方は積極的に調べていないようで、だいたい英語のサイトに引っかかります。また、Twitterと同じく公式APIではありません。ここ辺りを読むと、まぁ、そのうちにできるだろうと思うのですが、非公式の方法で調べることができます。これを実際にやってみると数が取得できます。なんだか「AIzaSyCKSbrvQasunBoV16zDH9R33D88CeLr9gQ」という文字列が穏やかじゃないですね。というわけで、こんな感じになります。

        $url = "http://www.yahoo.co.jp/";

        $ch = curl_init();
        curl_setopt($ch, CURLOPT_URL, "https://clients6.google.com/rpc?key=AIzaSyCKSbrvQasunBoV16zDH9R33D88CeLr9gQ");
        curl_setopt($ch, CURLOPT_POST, 1);
        curl_setopt($ch, CURLOPT_POSTFIELDS, '[{"method":"pos.plusones.get","id":"p","params":{"nolog":true,"id":"' . $url . '","source":"widget","userId":"@viewer","groupId":"@self"},"jsonrpc":"2.0","key":"p","apiVersion":"v1"}]');
        curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
        curl_setopt($ch, CURLOPT_HTTPHEADER, array('Content-type: application/json'));

        $curl_results = curl_exec ($ch);
        curl_close ($ch);

        $parsed_results = json_decode($curl_results, true);
        echo $parsed_results[0]['result']['metadata']['globalCounts']['count'];

ちなみに結果は、2304になりました。

これらの数ってうまいこと使えばなんか楽しそうな気がするんですよね。今は考えを温めている最中なのですが、いいアイデアがあったら早速組み込みたいなぁ、と。

EC2のデータをS3にバックアップを取る

2008年3月31日
API

ためには、どうしたらいいの?ということで調査中。

正直なところ私はバックエンドに自信がないのだが、せっかくの機会だということで、Amazon EC2にチャレンジしている。そして調べていくうちに、この環境ってすげぇな、と思うようになった。こんな構成よく思いついたね。天才じゃない?

ということで、EC2を使ってホスティングをする予定なのだが、使用しているAMIのインスタンスを落としてしまう(落ちてしまう)と、データは全部ふっ飛んでしまうので、バックアップを取る必要があるのだ。一般のサーバならハードが残っていればなんとか復旧できたりしそうな気もするが、EC2においては、そんなことはできない。というよりも、問題が起きたときには、ハードをゴニョゴニョして復旧をさせるというアプローチはもうやめようぜ、という立場なのだろう。つまり、ちゃんとしたバックアップ構成を組んでシステムを運用するべきだ、と。

そして、そのバックアップのために(それだけのためではないが)、S3というサービスも展開している。でも、どうやってそのバックアップを取ったらいいのだろう、ということがわからなかったので最近はそれを調べていた。

まだ調査中だが、二つの方法があることがわかった。たぶん。

AMIのインスタンスをそのままイメージ化してS3に退避

環境をすべてバックアップする。Amazon Elastic Compute Cloud Getting Started Guide Creating an Imageに書かれているように、構成をすべてバックアップとるので、EC2で運用しているサーバを落としても、AMIの選択で、バックアップしてあるイメージを指定すれば、復旧できる。

s3syncにてディレクトリを指定してS3に退避

必要なディレクトリのみをバックアップする。Using Amazon S3 from Amazon EC2 with Rubyに書かれているように、s3syncというRubyのスクリプトを使って、指定したディレクトリを指定したバケットにバックアップをする。

私が言っているバックアップというのは、サーバに乗っけた自作のWebアプリ自体やそこで使用しているデータベースのことなので、s3syncの方を採用するのだろうな。しかし、リリース時点のサーバの構成のバックアップは取っておくのはいい考えだと思うので、その際には、イメージ化してS3に退避するという方法を採用する必要がありそうだ。

というわけで、使い分ける必要がありそうだ。間違っていたら指摘よろしこ。

というわけで、YouTubeのAPIがGData対応になりましたん。

2007年9月3日
API

私は、ニコニコよりもYouTube派です。

で、どうAPIが変わったか、というところの詳細はここ見てね。
YouTube Data API Developer’s Guide: Protocol
なんかすでにクライアント用のライブラリのリストもあったり。。。
Google Data APIs Client Libraries

Competeを使ってみたが。。

2007年7月23日

Services_Competeに投票しようかみるために、まず、Competeって何?ってとこから始めたよ。

ほむほむ。Webサイトのトラフィックの比較とかをするらしい。
で、Compete Aboutを読むと、

Is this website safe from spyware and other threats like phishing?
How many people visit this site and how does it compare to other sites?
Are there promotion codes for this site that can save me money?

なるほどね。しかし、なんだか、ググルタソができそうなネタのような気もするが、

Today, search engines help us find sites, but they fall short of showing how safe, popular and valuable a site is.

と書いてあるように、今の段階ではしていないみたい。で、Competeは、なんだか独自の方法で評価する仕組みを持っているみたい。それが何かはよくわからんが、何百万もの人の動向を反映しているんだとさ。うーん。ググルタソが少し力を入れれば、速攻できそうな気もするが、その辺どうなんかな。つか、そこにお金儲けの仕組みがあると判断されれば、買収が一番早いのかもしれん。

で、だ。今回使用してみたかったのが、Services_Competeなのだが、CompeteのAPIをラップしたものということだ。CompeteのAPIでは、Compete Site Analyticsで手に入るようなデータをもらえるようだ。そして、それをうまいことマッシュアップしてみたらどうかね、といったものか。

まず、自分のサイトganchiku.comでやってみたけど

Sorry, we don’t have any data for ganchiku.com. With more data, we can cover more sites.

とか言われた。なにー!どうせトラフィックなんてないですよ。うちのサイトは。

というわけで、結構大きなサイトを比較するのがいいみたい。Site Analyticsのページを開くと、mlb.comとnfl.comとnhl.comの比較をしているのがわかる。確かにネットではどのスポーツが見られる人気が高いのかわかるわけだ。なるほどー。ということは、だ。同じようなサービスでどれだけシェアを持っているのかを見るのにいいんじゃね、ということで、SBMサービスを提供しているところを比較してみた。diggとdel.icio.usとhatena。しかし、だ。バグ発見。。。

hatena.ne.jpがne.jpと判断されてるじゃねーか!つーわけで、Contact Usからバグ報告してみた。yahoo.co.jpとかならいけるんだけどね。なぜかne.jpはダメ。バリデーションが変なところで切ってしまっているのだろう。まぁ、おそらく他にもダメなものがあるのだろうね。

本当は、hatena.ne.jpをServices_Competeから使ってみたら、ne.jpと認識されていたみたいで、ソースを見たのだけど、どうも間違っていないっぽかったので、Site Analyticsで試したら、やはり、ということだったのだ。話をうまいことそれに持っていくことができなかったので、無理矢理話を作っちゃった。

続きを読む

phptubeだって。

2007年7月4日

phptubeというのを発見した。
こういうアプローチの方がいいのかな。なんつーか、ハックって感じで。でも、公式APIではないので、変えられたら面倒そうだけどね。ファイルのアップロードとダウンロードができるようだ。まぁ、両方ともphpでHTTPクライアントを書いてみたってだけだけど、中途半端なAPIを対応するよりこっちの方が需要がありそう。ソース見たけど、まぁ、思った通りか。

つーか、YouTubeのAPIがGDataに対応したら、PEARから下ろしてもらうように言おうかしらん。Zend_FrameworkはGoogleと一緒にZend_GDataを開発していたみたいなので、勝負しても意味ないし。しかし、ZendとPEARの調整なんとかならんかね。

他にもいくつかのフレームワークは依存するのが嫌のようで、独自でいろいろ作ったりしている。symfonyも自分で勝手にlimeというテスティングフレームワーク作って組み込んでるしね。

んー。今の流れは小技ハックを出していくのではなくて、大物オープンソースを出していくことなのかしらん。ちょいと考えてみますか。

Shin Ohno 2003-2012