[web] web servicesのハブ

[google] google readerにfeedを登録するスクリプト

ぼくはfeed購読にgoogle readerを使っているのだけれど、feed登録するのに、いちいちgoogleにログインするのが面倒なので、google reader APIを使って登録用のスクリプトを書いてみた。

必要なものの導入とログイン情報の書き換え

curlが導入されていないと使えないので、適当に導入してください。ただし、--data-urlencodeを使っているため、curl>=7.18.0。debian lennyで導入するには下のような感じ。debian etchのcurlは古い(7.15.5)のでだめ。

# aptitude -R install curl
# curl --version
curl 7.18.2 (i486-pc-linux-gnu) libcurl/7.18.2 OpenSSL/0.9.8g zlib/1.2.3.3 libidn/1.8 libssh2/0.18
Protocols: tftp ftp telnet dict ldap ldaps http file https ftps scp sftp 
Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz

で、下のソースをpushfeed.shという名前で保存し、EMAILとPASSWD変数をgoogle readerにログインするときのものに変更する。

使い方

-uオプションの引数に適当なfeedのURLを渡して走らせる。成功すれば最後にOKと表示される。

$ sh ./pushfeed.sh -u http://example.com/feed.xml
OK

問題点

google readerにログインするための情報がプロセスリストに載る。
SIDを決める際にgrepとかでやっているのでgoogleの仕様変更におそらく敏感に反応して、使えなくなる可能性が高い。
いちいち-uとか打たないとだめ
まとめて登録できない。1個づつしか登録できない

ソース

#!/bin/bash
function help ()
{
        CMDNAME=`basename $0`
        echo "Usage: $CMDNAME -u feedurl"
}

if test $# -eq 0;
then
        help
        exit 1
fi

while getopts u: OPT
do
        case $OPT in
                "u" ) FLG_U="TRUE";VALUE_U="$OPTARG" ;;
                * ) help;exit 1 ;;
        esac
done

URL_LOGIN="https://www.google.com/accounts/ClientLogin"
URL_TOKEN="http://www.google.com/reader/api/0/token"
URL_SUBSCRIPTION_EDIT="http://www.google.com/reader/api/0/subscription/edit"
S="feed/${VALUE_U}"
EMAIL="hoge"
PASSWD="hoga"
SERVICE="reader"
AC="subscribe"
#CURL="curl -Ssv "
CURL="curl -Ss "
SID=`\
        ${CURL} \
        --data-urlencode Email=${EMAIL} \
        --data-urlencode Passwd=${PASSWD} \
        --data-urlencode service=${SERVICE} \
        ${URL_LOGIN} \
        | grep '^SID=' \
`
#echo ${SID}
T=`\
        ${CURL} \
        --cookie ${SID} \
        ${URL_TOKEN} \
`
#echo ${T}
${CURL} \
        --cookie ${SID} \
        --data-urlencode s=${S} \
        --data-urlencode ac=${AC} \
        --data-urlencode T=${T} \
        ${URL_SUBSCRIPTION_EDIT}
exit

[google] google ガジェットは邪魔

ためしに数日間google ガジェットの検索ボックスを設置してみたが、僕が邪魔に感じてしまってやめてしまった。やめた理由の一つはcssで位置とか見かけを恒久的に変更する方法が見つからなかったから。ガジェット部分のJavascriptを読めばいいのだけれど、これだとGoogle側の仕様変更についていけないしなぁ。ということでやはり昔ながらの検索ボックスに戻ってしまった。

Googleユーザのクリックするアンカーとファイルサイズ

Googleを利用するユーザの行動を肩越しに観察してみた。なぜか、検索結果ページのキャッシュを利用するユーザが少なく、サイトへの直リンクを利用するユーザが多いことに気づいた。そして、ヒットしたサイトへの直リンクをクリックしたユーザの中には、検索したキーワードを再度ブラウザの検索機能を使って探しているユーザがいる事にも気づいた。

僕は、サイトへの直リンクよりもキャッシュへのリンクをクリックする利点を強くプッシュしたい。その理由は、キャッシュを使うことでキーワードが色分けされて表示されるので、ページ中からキーワードを探しだすのにとても便利だからだ。サイトへの直リンクから最新の情報を当たるというという姿勢は望ましいと思うが、Googleはキャッシュからキーワード抽出し、この情報を元にヒットしたページの順位を決定している。そこをあえて悪い方向に変化しているかもしれない最新版をチェックするのは、あまり建設的な解決策とはいえないのではないだろうか。

さて、直リンクをクリックするタイプのユーザにも的確に検索結果を伝えるには、サイトマスターは1ページに含まれる情報を細分化し圧縮してみてはどうだろう。2chの掲示板がヒットした場合、自分の欲しい情報を引き出すのが難しい。その理由は情報が時系列でソートされ、Simiralityでソートされていないからだ。つまり、視線の移動量に比べて必要な情報が散発的にしかヒットしないため「読みづらい」からだ。適当に細分化すれば、検索してきた人に適当な情報を提供できる。

目指せ1日100pv。

google検索で表示される最大ページ数は1000

最近になって知ったことだが、Googleで検索したときに「hoge の検索結果約 341,000 件中 1 - 10 件目 (0.06 秒)」と表示されても、検索ページをめくっていっても341,000件の全ての検索結果が表示されるわけではない。上から1000件までの情報だけが表示される。本当に341,000件のヒットがあったのかユーザとしてはチェックすることは出来ないが、まぁ1000番目以降のページにはほとんどキーワードに対する有益な情報が含まれないということで打ち切っているのだろう。

この問題に対する解決策として、SEOmoz | Cracking Google's 1,000 Page Barrierのようなページがある。タイトルにはクラックとあるが、「サイトの論理的な構造をurlに上手く反映させてinurl検索演算子で絞り込もう」というような感じだったと思う。

1000ページ以降に意味のある検索結果は含まれないであろうという予想と、これを上手いこと論理的な構造と結びつけることで絞り込もうという発想である。第一歩として、検索したら1000ページ目まではチェックするように心がけようかな。そうすることで、いままで捨ててしまっていた情報が見えてくるかもしれない。

目次

[google] google readerにfeedを登録するスクリプト

必要なものの導入とログイン情報の書き換え

使い方

問題点

ソース

[google] google ガジェットは邪魔

Googleユーザのクリックするアンカーとファイルサイズ

google検索で表示される最大ページ数は1000

googleでははてなブックマークのほうが元記事よりも上位に来る場合がある

Google Analitics

[Web] 検索エンジンが自分のサイトをどのように認識しているか

[Services] YourFileHost ダウンローダ

Services > twitterはじめました。

ブリコラージュ的メールマガジン一括登録解除方法

Memo > iswebの自動挿入広告の文字コードに関する考察

Services > Gmail Tips

ソーシャルブックマーク

日付の近い記事

ChangeLog

[web] web servicesのハブ

目次

必要なものの導入とログイン情報の書き換え

使い方

問題点

ソース

関連記事

web

ソーシャルブックマーク

日付の近い記事

ChangeLog