‘WEBサービス’ タグのついている投稿


3年くらい前から、IT系、技術系の情報をクリップしていました

http://week.dgdk.net/
SNSのシェアやブックマークサービスなどを使っても良かったのですが、分類するのが面倒だったので、ページタイトルから形態素分析で単語に分けてタグ付けしとけばオーケーみたいな感じのものを作って記録していました。

クリップの仕組み

ページのクリップはChromeの拡張機能を自作しました。単純に該当ページのtitleタグとURLをサーバに送信するだけの拡張機能です。
拡張機能から送信されたtitleタグの文字列は、Yahooの形態素解析へ送信して単語に分割します。その後、title、URL、分割した単語を、それぞれ記事のタイトル、本文、タグとしてwordpressに投稿します。投稿は即公開されます。
実際の操作は、気になったページを開いて拡張機能ボタンをクリックするだけ。拡張機能ボタンなのでメニューを開くこともなく、1クリックだけで記録できる。

ざっくりな形態素解析ではあるけれど、それなりに興味深い

終了なんてタグで検索すると、色々なサービスが終了したことを知ることができるし、そのサービス名のタグで検索すると、開始した時のリリースなんかも見つかったりします。たとえばタクシー配車サービスのHailo
さすがに3年続けていると始まりと終わりの両方が把握できるもんだな、なんていう感慨にふけります。

ここから先はあるあるネタ

分類の手法で常に出てくるものとしては、類語でタグができてしまうのを整理できれば、とは思います。オラクルoracleのような状態を1つに出来ればモアベター。
形態素解析の元がページのタイトルなので、サイト自体のタイトルもタグになってしまうのはノイズの要因になっています。朝日新聞なんかがそうです。フィルタをかけて外したりもできるのでしょうけれど。
それと、やっていて気づいたのが、ページのタイトルに本文の内容を表記しない所がそれなりにあるということ。例えば日立のニュースリリースは「ニュースリリース:日付:日立」の形式なので、同日のリリースはすべて同じタイトルになるし、amazonなんかはそもそもtitleタグが無かったりします。発信する側はそういう所まで気にしない傾向があるのかも知れません。


ツイッターでツイート数取得が10月からできなくなるという話が出ています。

Twitter:ツイート数取得API「count.json」提供終了のお知らせ

http://did2memo.net/2015/09/28/twitter-count-json-shut-down/

ツイッターの情報が日本語でまとめられている所が思っているより少なくて、情報源がここばっかりなのが少し面白いですが、そこを面白がってる場合じゃないかもしれません。
今まで

http://urls.api.twitter.com/1/urls/count.json?url=http://www.mybenjo.net/

という具合にURL指定で取得できていたツイート数も取れなくなるんじゃないか、そもそもそのURLは公式サポートしてないし、なんていうことになっているので、実際近い将来機能しなくなっても不思議じゃない。

ということで試しに似た動作をするものを作ってみました。

作ってみたサンプル

同じ要領でURL指定してアクセスします。返ってくる結果も同じJSON形式です。

http://api.dgdk.net/TwEmu/count.php?url=http://www.mybenjo.net/

※サンプルなので戻ってくるまでに3秒程度かかるようにしています。

ソースと簡単な説明

TwitterApplicationとして運用します。OAuthで認証したあとの処理になります。OAuth周りはそれだけで沢山の資料があるのですが、ざっくり”abraham/twitteroauth”のライブラリを利用します。
ライブラリはPHP5.4向けに書かれているので、arrayの定義方法が5.3以前と違うのでエラーが発生します。5.3以前の環境の場合は、[] を array()に書き換える必要があります。世界は着実に動いていますね。

abraham/twitteroauth

https://github.com/abraham/twitteroauth

ソースはライブラリのドキュメントにあるサンプルソースとほぼ同じ内容になります。ざっとこんな感じ。

<?php
require "twitteroauth/autoload.php";
use Abraham\TwitterOAuth\TwitterOAuth;

define("CONSUMER_KEY"   , "コンシューマーキー");
define("CONSUMER_SECRET", "コンシューマーシークレット");
$access_token = "アクセストークン";
$access_token_secret = "アクセストークンシークレット";

$connection = new TwitterOAuth(CONSUMER_KEY, CONSUMER_SECRET, $access_token, $access_token_secret);
$statuses = $connection->get("search/tweets", array("count"=>100,"q"=>$_GET["url"]));

header("Content-Type: application/json; charset=utf-8");
echo json_encode(array("count"=>count($statuses->statuses),"url"=>$_GET["url"]));
?>

ツイートをURLで検索して結果の件数をカウントしているだけ、実にあっさりしたもの。
URLのチェックやAPIの使用制限を考慮したキャッシュなどの工夫は必要に応じて実施する必要がある。

誰に向けて書いていいかわからないのでモヤッとしてます

そもそもTwitterAPI分かる人にとって特になんともないことだし、そういうのが分からない人にとっては書いてあることが分かるのか、モヤッとしています。そう思うと理想としてはURL一発で取得できる仕組みが今後も継続するのがいいんだろうなあと考えるのですが、企業のサービスとして継続できるのか?みたいな部分はあるんだろうと思います。

でも、そもそもツイート数ってそんなに大事なものなんでしょうかね。沢山ツイートされていると価値があるような感じになるのは人間として当たり前なのかな?なんてことを考えてしまいます。


表題の件の通りのことが起きました

報告があったのはIE10と8で起きるということでした。
開発者ツールのコンソールでは

‘google’ は定義されていません

と表示されて画面が真っ白になるという状況。

真っ白な画面のソースを調べてみると

<script defer onreadystatechange=’google.loader.domReady()’ src=//:></script>

というjavascriptが1行あるだけ。
なんでそうなっているのか分からないけれど、googleが定義されてないからエラーが出たのはなんとなく分かる。

Googleで色々検索してみました

日本語で関係ありそうなページは見つからなかった。
「GoogleSiteSearch」で検索すると5件目くらいに吉祥寺北口システムの記事が出てくるくらいに何にも情報が無いので仕方がないことではある。
技術系ではよくあることなのだけど、stackoverflowにこれかなぁというのがあった。世界は広い。

Why is my website a blank screen in IE? (Including IE9!)
http://stackoverflow.com/questions/12028652/why-is-my-website-a-blank-screen-in-ie-including-ie9

報告されている現象は同じ。Answerに

From what I remember, IE does weird things when you try to access elements on the page that haven’t been fully parsed yet.

という説明がある。
IEのjavascriptの実行がマークアップ完了する前に動いてしまう、らしい。
ならば思い切ってIEの時だけはタイマーをかけて検索処理の実行を遅らせてみた。

こんな感じ

var ua = window.navigator.userAgent.toLowerCase();
if (ua.indexOf('msie') != -1) {
  $(document).ready(function(){
    setTimeout( function() {
ここにGoogleSiteSearchのコードを書く
    }, 5000);
  });
}else{
IEじゃない場合はここにGoogleSiteSearchのコードを書く
}

タイマーの5000(5秒)は適当な数字。もっと短くても大丈夫かも知れない。

結果、動きました

これで現象はとりあえず起きなくなった。元々謎の挙動なので、本当に全く起きなくなったのかは分からないけれど、繰り返し確認しても大丈夫になったようだ。
もちろん、タイマーが動く分だけ検索表示は待たされるので、実用的かどうかという面はある。本来ならばしなくて良い待機時間なので。


無料枠でテスト的に使うとして

AWSは、業務で使うことはあるけれど、テスト的に導入するといった場合にどれだけ気軽に出来るのか?ということは考えたことはなかった。制限があるし、その制限が無いことがAWSを使う利点でもあるという意識があったからだ。
とはいえそこで否定するのもアレなので、もし無料利用する場合にはどんな条件なのかをメモしてみた。

参照元は クラウドサービス 無料利用枠のご案内 | アマゾン ウェブ サービス(AWS 日本語) で、2013年11月17日現在の情報なので、あくまで参考までに。

前提として利用期間は12ヶ月間でさらに月内の利用時間に上限がある

AWS新規申込みのユーザーに対してのサービスで12ヶ月間の提供となっている。1年無料ということ。
さらに以下の制限がある。

月750時間というのは、24時間×30=720時間なのでEC2を1台起動しっぱなしで問題ないと判断出来る。複数台の場合は起動しっぱしは出来ない。AWSの柔軟な部分は切り捨てて1台のレンタルサーバと考えれば問題ないとは言える。

データ転送が15GB/月なので、大きめのファイルやトラフィックの多い場合には注意が必要だ。ソフトバンクのテザリングが7GB/月を超えると速度低下が発生するということなので、15GB/月というのもそこまで余裕のある数字では無いのかもしれないが、そもそも論でそんなにスペックの高いサービスでは無いことを考えると、高トラフィックでデータ転送量が跳ね上がる恐れはそこまで無いかも知れない。そんなに心配ならばチェックしよう、ということだとは思う。

1台のレンタルサーバとしてのスペック

EC2で使えるインスタンスはマイクロインスタンス。マイクロインスタンスのスペックはインスタンスタイプを参照すると以下のようになっている。

AWSの考え方前提なので他のレンタルサーバと比較するのは簡単では無いけれど、乱暴にまとめると

というVPSサーバ1台に相当する。さくらのVPSの1Gよりも低いスペックだと判断しても良いと思われる。

経験上、メモリが1GB無いとapache+phpだけでも物理メモリを圧迫する。mysqlをRDSに外出しするにしてもリソースギリギリの構成だと想像できる。
980円/月のプランより低い、期間限定の無料プランだと考えれば仕方の無い内容だとは思うけれど、そこまでしてAWSを使う理由は感触を確かめたりオペレーションの学習といった理由以外ではあまり利点は無いのではと考える。

セットアップの手間などはどこまで一般的に想定されているのか分からないのですが

これは他のVPSやクラウドでも言えることだけれど、セットアップは自前で行う必要がある。
この部分、自分では感覚がズレていることだけは分かっているのだけど 通常サーバを借りる=必要なシステムは用意出来ている という感覚であるならばAWSではもう一手間、しかも今まで知らなかったような作業が発生することになる。
今はネットで検索すれば、セットアップ方法もそれなりにあるだろうし、それの練習だと思えば問題ないけれど、無料のレンタルサーバのサービスだと考えてしまうとハマってしまうのでは無いかと思われる。


The Old Readerがプライベートに移行するというアナウンスを出した。

先週、ストレージ移行をアナウンスして、丸一日ダメだったりしていて、とにかくスケールアウトが大変なんだろうなぁと思っていた矢先。
ストレージ移行後は同じフィードをとっている他アカウントを表示したりと、着実に新機能も追加されていただけに、それでもギブアップしてしまったか、という印象。想像する以上に悔しい気持ちがあるのだろう。

個人商店的にポツポツやっていたサービスが一気に信じられない流入が起きたことによる、とてつもない混乱は読み馴れない英文からも伝わってくる。プライベートを捨てて頑張ったんだろうな。

成功した事例で休日返上なんてエピソードはよくあるけれど、それは上手く行けばあとから武勇伝的に言えるだけで、同じように自分をすり減らして困難に立ち向かっている成功していないプロジェクトの人達がそれ以上にいることは容易に想像できる。全員がハッピーになれれば良いけれどそういうわけじゃないという当たり前の話なのだけど。

なんて書いていたら追記が入った。

過去の2ちゃんねる閉鎖騒動では無いけれど、何かしら良い結果に結びつくことを祈る。成功事例が1つでも増えると、頑張った事が報われたストーリーが増えると、頑張る人達のちからになる。


引き続きのRSSネタ。

ブログパーツにRSSフィードありましたよね

ブログのサイドに置いてあったフィード表記が、最近はあんまり目に止まらなくなった。

いつからかは分からないけれど、気がついたのつい最近。Google Readerの騒動があってから。

chromeのエクステンションを使うとソース中の link rel=”alternate” を探してくれてアドレスバーにフィードアイコンを表示してくれるので、そればっかりに頼っていたのだけど、きっと数年前から少しずつ減っていったのでは無いかと思う。

ブログサービスのデフォルトの設定が非表示だったりするのかも知れない。
そういえばこのサイトも出してない。wordpressはデフォルトで表示しているけれど、わざわざテンプレート直した時に非表示にした。

やっぱりわかりにくいですよね

非表示になったとしたならば、その理由は何となくわかる。

・ユーザーにとって、そもそも何かわからない。
・表示の文言も意味不明。RSS2.0とかatomだとか複数あったりする。
・あった方が良いものなのかが分からない。

などなど。
フィードについてハッキリした説明が無いし、簡単に出来そうもない。記事を書く人にとって良いものだと思わせる分かりやすい何かが無い。

ブログサービスが流行り始めた頃は、WEB2.0なんて言葉が出まわっていて「RSSも先進的な何か」ということで許容されていたのかも知れないけれど、普及してしまったことで、その存在の説明をすることよりも引っ込めた方が良いと判断したのだろう、と推測できる。

実際、分かっている人は分かってるわけで

ソース上の記述を追って、フィードのURLを見つけて登録という仕組みは、それがちゃんとソース中に記述されている記事のURLがあれば可能だ。
上でも書いたけれど、エクステンションなんかを使えばブラウザのインタフェイスでフィード登録出来てしまう。

サイト上にフィード表示が無くても、積極的にフィードを使う人にとって特に面倒は無いわけで、結局表示しなくても良いじゃないですか、という話に落ち着く方向性なのだろう。
実際自分もそうだ。

ページビューは落ちる可能性がある

RSSリーダを多用すると、そのサイトを閲覧する機会が減る。記事は読むけれど、そのサイトに行かない。フィード表示が無くなりつつあることに気づかなかった理由の一つでもある。

本文抜粋のサイトは、全文読むために訪問しなければならない。人は怠け者に出来ているのか、そういう記事はよっぽど見たい内容じゃないと、そこまでだけでパスしてしまったりする。
だとしたらフィード配信している意味って、そんなにあるのだろうか?という風になっても不思議じゃない。
ページビュー数を誇るアメブロのフィードは記事の抜粋で、画像も非表示となっていることが多いのは、サイトへの訪問を狙ってのことだろう。

というなんとも微妙な位置のRSSフィードなのだけど

Google Reader終了アナウンスで、色々な人が困ったことが明るみに出た。なんだみんなフィード読んでるんじゃない。

WEBは日々進歩していく技術が多く、先進性や新規性、そしてそこからくる収益性に注目される事が多い。わざわざ損するような技術を採用しようと考える人は少ない。
RSSフィードはとても便利な技術だし、使うことで損することは決して無いけれど、地味に普及してしまったために
「で、それで新しいこと出来るの?」
「で、それで話題を集められるの?」
「で、それで儲かるの?」
といった面が現状とても弱い。

Google Reader騒動でも「終わった技術」なんて揶揄を目にした。新規性という意味では枯れつつある技術だと言えるけれど、まだまだ使える技術ではある。


The Old ReaderにGoogle Raderのサブスクライブ情報(subscriptions.xml)をインポート出来た。
インポート設定後、数万人待ちの状態だったのが、ある日突然、出来ましたのメールが到着次第。
Google Readerで設定していたフォルダ情報もそのまま引き継がれているので、さながら見た目の違うコピーサイトを見ているような気分。

引っ越してみて、ああそうだよねえと思ったことがあったのでメモ。大したことではないけれど、同じ事を感じた人は大勢いるのではないか。

当たり前なの話なのですがRSSリーダなのですよね

フィードの情報をインポートしたので、RSSリーダが再度全部のフィードを舐めなおしてくれている。
既読情報はインポートされないので各フィードの情報がまるまる未読になる。

別に最新の情報が少し巻き戻るだけ、なのでちょっとだけ重複するように思えるのだけど、問題は随分前に終わってしまっているフィード。
ブログやフィードの配信源が生きていれば、古い情報だとしても律儀に最新記事20件くらいが返ってきてくれる。いつの話ですか、と思う記事が続出することになる。

ブログを長く続けていれば引越しして新しいサービスに移ることもあるし、期間限定のプロジェクトや、解散してしまったグループなんかのフィードだって残っていることがある。いちいちその度にアンサブスクライブしていなかったので、予想以上にそういうのがあってビックリした。

Google Readerのsubscriptions.xmlに既読未読の情報はありません

エクスポート/インポートのデータ形式はどこかで定義されているのかなぁと思って少し探してみたけれど、特に無いようだ。XMLの中にDTDの宣言も無い。構造はすごく簡単だし、よろしくやって下さいってだけのデータだ。
引越しそのものが頻繁にあるわけで無いし、本当にザックリやってしまうようなところなのだろう。Google Reader終了騒動で他のサービスが引越し対応をした、なんて記事があるくらいなので、インターフェイスはアドホックで合わせたのでは無いかと想像する。元データがそうなので、どこのサービスに引越しても既読情報は引き継がれないだろう。

ということで、世界中で同じような体験をする人が沢山いるんだろうなぁ、という話。


発端はGoogle Readerの終了アナウンス

3月13日にGoogle Readerが7月終了のアナウンスが出た。

個人的にも引越し先を探さないとと思ったわけなんだけど、アナウンスが出た当日は検索しても数年前の「RSSリーダで最新の情報をチェックしよう」みたいな記事ばっかりが出てくるような状況だった。
その後しばらく経って、移転先のサービスはどこがよいか?なんて記事が出回ったり、実際受け入れ体制を進めるサービスも出てきたわけで、如何にこの分野がGoogleReader一択で、安定した刺激の少ない状況になっていたかが伺い知れることになった。

The Old ReaderはGoogle Readerクローンらしい

引越し先として目をつけたのがThe Old Reader。去年の6月にベータを、8月に最初のリリースが出ている、かなり新しいサービス。

今までのアナウンスはこちら

使い勝手はインターフェイスがGoogle Readerにとても近いので今までと殆ど変わらない。
動作が若干遅かったり、インポートが数万人待ちになっていたり、PCブラウザからしか使えないなど、不満はあるにはあるけれど、そこまで問題にならないレベル。
配信された記事の中に大きな画像やYouTubeなんかの埋め込みがあればGoogle Readerでも表示が遅かったりしていたし、逆にこれを数人でやれるんだなぁ、なんて感心してしまう。

そして、その伸び率

そんなこんなでインポート待ちなので、ポツポツ手で新しいフィードを登録しながら様子を眺めていたら、こんな記事が流れてきた。

まさかまさかの移転者続出で、寄付や要望やリアクションが沢山来てありがとう、頑張るよ。あと手伝ってくれる人募集という、本当に牧歌的な内容。ちょっと寄付したくなる。

そんでもって最後に載せているグラフがスゴい。


Mixed news everyone: update, help search, report and pics.http://blog.theoldreader.com/post/47142810692/mixed-news-everyone-update-help-search-report-and より引用

ユーザー数、取り扱い情報数のどちらもGoogle Reader終了アナウンス前の値がほぼゼロになってしまうくらい伸びている。
これは蜂の巣をつついた騒ぎどころじゃない。

ちなみにFeedlyは300万人増えたそうだ

メジャーな移転先として名前があがるFeedlyでも300万人が流入してきたそうだ。

The Old Readerが17万人だから、それのおよそ20倍の数字。上のグラフを見ると20倍といってもそんなでもなさそうに感じするのがグラフの恐ろしさ。
300万ユーザーって、単純にユーザーテーブルが300万レコードあるってことだ。

結論。Google Readerはハンパ無かった

分かっていることは、おそらくこの317万人のウチの結構な人数がGoogle Readerから移って来たということ。つまりGoogle Readerはその人達にサービスしていたということ。
RSSリーダはとにかくストレージを使う。日々流れてくるRSSフィードの情報を格納して、既読未読の情報をユーザー単位に記録する。やっていることは単純だけど、データの維持管理は膨大で、パフォーマンス低下が起きない為の努力は想像を絶するものだと思う。
そしてそれをやっていたGoogleは、やっぱりスゴいんだなぁ、という小学生みたいな感想。マジですごいや。

そしてそれの何%かを肩代わりしていこうとしているThe Old Readerのチームの冒険には期待している。本当にちょっと寄付したい。


サイト内検索をしたいという要望はウェブサイトが出来てからずっと存在する。
最近ではGoogleなどの検索エンジンを埋め込むという手段で簡単に済ませるケースも多い。ユーザーもそれに慣れているので違和感を感じる人も少ないようだ。

ただし商用サイトなどで不要な広告、場合によっては自社製品やスポンサーなどなどの関係で検索エンジン側の広告を出したくないというケースもある。
その場合には検索エンジンの有料サービスを使うことになるのだけれど、さてさて、いくらくらいかかるんだっけ?というのを毎回探して、ハウツーページを見て回ったりすることになる。
サービス本体へのリンクが見つけたいのだけど昨今のSEO技術向上の影響なのか、なかなか上手いこと見つからなかったりする。

このページもそんなノイズの一部になってしまうかも。

ということで、Googleのサービスへのリンクをメモ書きしておく。

無料サービスである「Googleカスタム検索」と、有料サービスの「GoogleSiteSearch」の機能比較

Googleブランドや広告が出るのが気にならなくて、そんな大規模なサイトでなければ、Googleカスタム検索でも十分で、それ以上は一律有料サービスですという割り切りじゃないかなと思う。
有料サービスで何が出来るかはとにかく問い合わせて下さいというイメージなのかな?
この辺はGoogleでも普通のシステム屋さんとあんまり変わらないスタンスというか、定石なのだろう。

有料サービス「GoogleSiteSearch」の料金

年間の検索クエリの件数によって金額が変わってくるということは、どのくらい検索されますか?という部分を検討しないと予算は決められないですよ、という当たり前の質問が発生する。
そういう数字を意識してサイトデザインしないといけないですよと暗に教えてくれている。ありがたい。

でも、GoogleCheckoutで2000ドルの支払をするとか、慣れていないだけなんだろうけれど不思議な気分がする。クレジットカードで支払うのと実質は変わらないんだけど。


作業をしてて、またちょっとひっかかったのでメモ。
結論としてはタイトルの通り。当たり前なことなのだけど、Facebookは日々アップデートしていて、それは多くのユーザーが目にする部分だけでなく、Facebookアプリの開発機能にだってあるということ。

よくあるiframeでの埋め込みをFacebookページにいれようとしていた

アプリを設定して、さてFacebookページのメニューに組み込もうか、というタイミングで引っかかった。
そこまでの大雑把な流れはネットを検索すればハウツーを沢山見つけられる。

「iframe Facebook page」で検索した結果

ハウツー記事が作られた時期によって、細かい手順は異なる。これもまたタイトルの通りで、日々変わっていることを確認出来る。興味深い面もあるけれど実用性の面では難しいところ。

今回は、Application Profile Pageのメニューが無くなっていて、Facebookページに追加できなくなっていた。あれれ、困ったな。どこか場所が移ったのかなと調べてみたところ…

Application Profile Pageを外しました

どこかに移したわけじゃなくて、外しちゃいましたという話だった。
12月10日の記事なので、それ以前のハウツー記事には当然載っていない情報。もしかしたら直近で出版される書籍にも書かれないかも知れない。外したらそりゃ無いですよね。

その代わりにどうするのか

その代わりに異なるメニューが用意されたのかと思ったら、準備出来るまでは自前でページに追加するダイアログを表示させてくださいということだった。こんなサンプルソースが出ている。

<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:og="http://ogp.me/ns#"
      xmlns:fb="http://www.facebook.com/2008/fbml">
<body>
  <a href="#" onclick=window.open("http://www.facebook.com/dialog/pagetab?
  app_id=YOUR_APP_ID&redirect_uri=YOUR_URL","PageTab","width=500,height=200");>
  Dialog</a>
</body>
</html>

シンプルで非常に分かりやすい。

でも、これを暫定でもメニューに入れておけばいいんじゃないの?と思わなくも無い。
メニューなどを修正する予定なのだろうし、その間、これでも構わないんだけど、ちょっと何か親切というかの部分、ざっくりしてますねという印象。

まぁでも、困るのは開発者だけだし、こうやって調べて解決できてしまうので、大勢には影響無いのかも知れない…ってこれで良いのだろうか?

サービスへの認識としての問題

ということで、今話題のFacebookでも、たまにこんな風な感じでハマったりしますよ、という話でした。

こういうことは、WEBサービス開発のプロジェクトでは「たまには、そういうこともあるよねー」レベルで認識が共有されていると、それで進行がちょっと遅延してしまったりなんて時に、ストレスが発生しにくくなって良いのでは無いかな、と思う。

オープンソースはどこまでサポートがあるのか?なんていう話に近い事例かも知れない。