01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
2010 : 01 02 03 04 05 06 07 08 09 10 11 12
2009 : 01 02 03 04 05 06 07 08 09 10 11 12
2008 : 01 02 03 04 05 06 07 08 09 10 11 12
2007 : 01 02 03 04 05 06 07 08 09 10 11 12
http://nl.amatz.com/
nicoline
Twitter の Streaming API でニコニコ動画関連と思われる発言を地引してきて、ニコニコの API とマッシュアップしてタイムラインとして再構成するサービスです。
ある Twitter ユーザーがニコニコでどういう動画を見ているかであるとか、ある動画には Twitter でどういう反応があるかとか、ある動画を見てる人は他にどういう動画を見ているか、といったものが監視できます。
現在追加で開発中の機能としては、あるユーザーについて、視聴傾向が似たユーザーをリストアップするだとか、そんなの作ってます。作ってますっていうかコード自体は仕上がってるのですが、驚異的に遅いのと(Fiber&NeverBlock とか使ってるんですが、そもそもの推薦ロジックが悪いのでどうにもならない)データがあまり蓄積されていなくて結果が使い物にならないので投入出来ないとかそういう状態です。
業務の間の暇潰しみたいな感じで作ってたものがいつのまにかに会社のプロダクトということになったものです。そのような経緯から内部は驚異的に属人的な実装になってます。
中身ですが、フレームワークは Rails 、 データの保存は ActiveRecord ではなく TokyoTyrant をメインのストレージとして使うデータベースインターフェイスである SimpleResource を使っています。 Lang-8 さんが作ってる奴で、いわゆる完全なるオープンソースフリーライドです。 Ruby 1.9 で正しく動かなかったので、そこだけ修正して使ってます。
http://github.com/ssig33/SimpleResource
ssig33's SimpleResource
個人的には SimpleResource 使った開発大好きなのですが、いかんせん全然ユーザー居ないっぽいので(Lang-8 と俺ぐらいしか使ってねーんじゃねーの)、プロダクトが属人的になりすぎてしまうかなーとか思ってます。
SimpleResource 非常に便利で簡単なので布教してゆきたいですね。
Twitter の Streaming API ですが、下手にイベントフレームワークとか使うよりは、メッセージキュー間に挟んで処理を非同期化した方がプログラムが単純になるのではないかな、と思ってます。 nicoline ではかなりオレオレな感じのメッセージキューが動いてます。この辺り、用途がもっとクリティカルなら話が違ってきそうだけど、 Twitter 関連のサービスでそこまで厳密さは求められないでしょう。
オレオレメッセージキューについては以下参照
http://ssig33.com/blog/2010-01-25-1.html
Rails で非同期処理
SimpleResource を使っているので、基本的にモデルっていう考え方が無いのですが、まあそんな感じのを適当に作ってる。
ネットストーキングに特化した感じで結果として収益モデルが全然無いものを今回は作りましたが(そもそもの成り立ちが暇潰しなのでこの辺しょうがないですね)、次はマネーを生んで僕の給料が増えるようなものを作りたいと思います。
ブログ書こうと思ってエディタ開いたら、このブログの中身の ChangeLog Memo が度重なるマージによって変なことになってた、執筆の前にとんだゴミ処理させられたぜこんちくしょうが。
このブログ、歴史的な経緯で、 dotfile や Plagger の yaml やらが入った git リポジトリに同居していて、いろいろ面倒なので分離させたい。あとでやる(永遠にやらない)
そんな訳で本題。 Hello 糞野郎ども。 Twitter の話。 Basic 認証や OAuth で RESTful な API を叩いては生活されているかと思います。最近、そこに Streaming API が追加されました。従来あった Streaming API (firehose gardenhose sample track) とは違ってユーザー向の Streaming です。
これはどういうものかというと、かつての IM のように、 following の行動がリアルタイムで push されてくるというものです。よかったですね。
かつての IM とは違うところはプロトコルが Jabber ではなく HTTP で、 following の RT Fav Follow Delete が流れてくる、というところでしょうか。
実のところ、 Streaming であるというのは大した話ではなくて、従来の API を使うより、数十秒早くタイムラインを取得出来るという程度のことです。問題は RT Fav Follow Delete が流れてくるということです。以下使い方と共に実例を示します。
現在 User Streaming は
http://chirpstream.twitter.com/2b/user.json
に Basic 認証をかけて GET すれば使うことが出来ます。 JSON がガンガン流れてくるので、一行ごとに区切って処理していきましょう。ちなみに、ベータ版(&仕様に問題アリ)ですので、多分そのうちサクっと使えなくなります。
流れてくるもの。
1.tweet
{"coordinates"=>nil, "truncated"=>false, "created_at"=>"Sun Apr 25 14:09:59 +0000 2010", "favorited"=>false, "text"=>"@peachchch @siguri にならおこられtm (ry", "contributors"=>nil, "id"=>12823261895, "geo"=>nil, "in_reply_to_user_id"=>24514923, "in_reply_to_screen_name"=>"peachchch", "source"=>"<a href=\"http://www.misuzilla.org/dist/net/twitterircgateway/\" rel=\"nofollow\">TwitterIrcGateway</a>", "place"=>nil, "user"=>{"profile_sidebar_fill_color"=>"c28c8c", "profile_sidebar_border_color"=>"405add", "name"=>"紫雪", "profile_background_tile"=>false, "created_at"=>"Mon May 07 09:06:35 +0000 2007", "location"=>"Nagoya Japan", "profile_image_url"=>"http://a3.twimg.com/profile_images/781317847/icon2_by_chrcc_normal.png", "profile_link_color"=>"e8b7b1", "favourites_count"=>682, "contributors_enabled"=>false, "url"=>"http://iddy.jp/profile/shisetu/", "id"=>5827682, "utc_offset"=>32400, "profile_text_color"=>"000000", "lang"=>"en", "protected"=>false, "followers_count"=>939, "verified"=>false, "description"=>"来年から社会人の大学生な声オタ。茅原実里/堀江由衣/富樫美鈴/堀中優希/田村ゆかり/白石涼子/佐藤利奈/新谷良子/松来未祐/吉田真弓/藤田咲/木村まどか/阿部玲子。公開中の壁紙:http://tidama.hp.infoseek.co.jp/tw/ since.2007.05.07", "notifications"=>nil, "time_zone"=>"Osaka", "profile_background_color"=>"b8a088", "geo_enabled"=>false, "friends_count"=>581, "statuses_count"=>104141, "profile_background_image_url"=>"http://a1.twimg.com/profile_background_images/2317728/121212.jpg", "following"=>nil, "screen_name"=>"shisetu"}, "in_reply_to_status_id"=>nil}
ふつの API と一緒。ただし、普通の API と違って、 follow してない人への @ も流れてくる。
2. favorite
{"target_object"=>{"id"=>12823149509}, "event"=>"favorite", "target"=>{"id"=>101784326}, "source"=>{"id"=>4301761}}
event の中身が favorite のやつ。見ての通り、 ID でしか流れてこない。 follow してない人の発言や Protected な発言を favorite した場合でも容赦なく流れてくる。これが仕様として問題アリ。
3. follow
{"event"=>"follow", "target"=>{"id"=>100233679}, "source"=>{"id"=>4565971}}
event の中身が follow のやつ。 ID しかこない。 following じゃない人を follow した場合も流れてくる。これも普通に考えて仕様バグ。
4. retweet
{"target_object"=>{"id"=>12824333560}, "event"=>"retweet", "target"=>{"id"=>3557911}, "source"=>{"id"=>25021939}}
event の中身が retweet のやつ。これも ID しかこない。 following じゃない人を retweet した場合も流れてくる。これもおかしい。
4. delete
{"delete"=>{"status"=>{"id"=>12600620062, "user_id"=>5979722}}}
delete の中にごちゃごちゃ入ってるやつ。 user_id が "user_id" な人が status_id が "id" な発言を削除したよ、みたいな奴。仕様はおかしくないが、これが流れてくるのはどう考えても狂ってる(後述)
5. unfavorite
{"target_object"=>{"id"=>9389610133}, "event"=>"unfavorite", "target"=>{"id"=>86054248}, "source"=>{"id"=>15919159}}
favorite を削除した時のやつ。読み方は favorite と同様、仕様バグ。
以上一例です。手元のログから発掘してきました。
この User Streaming ですが、問題点があります。大きく分けて二点。仕様バグがあることと、倫理的におかしいこと。
1. 仕様バグ
favorite follow retweet unfavorite は明らかに仕様の策定ミス。狂っている。 following ではない人の発言を following が favorite したと ID だけで通知されても、 ID から発言を取得する方法が事実上無い(API の実行回数制限により)。 following 、 unfavorite も同様。これにもユーザー情報や status の情報を入れてくれなければ使い物にならない。
現状の仕様では White List を持っていないとどうにもならないので、これは正式リリースまでになんらかの対応(機能が無くなるか、バグが消えるか)がされるでしょう。
2. 倫理面の問題
delete が流れてくるのはどう考えてもおかしい。先述の仕様バグも含め、 firehose をそのままユーザー向けに移植していることが原因と思われる。 firehose であれば delete を API の利用者にリアルタイムで反映してもらう必要があるが、ユーザークライアントでそれをする必要は無いはず。仕様バグの方は firehose ユーザーはそれまでの全発言を持っているので問題無い、ということになる。
こんなものが流れてきても得をするのはネットストーカーだけだ。

めんどくさいから編集してないけど、まあ問題ねえか。実際はもっと際疾い発言が消されているのを観測できたりする。
まとめ
イベントにあわせて firehose 流すのに使ってるのををほぼそのまま無調整で User Streaming に流用していると推測される。いくらなんでもやっつけすぎだし、こんなやっつけ API で「テストをしろ」と開発者に言ってくる Twitter は明らかに狂っている。
それから、 White List に登録された恐しいネットストーカーが発言の削除や favorite の削除すらも監視しているので気をつけましょう。
リンクポリシー
とのことですので適当にいくつかリンクを貼っておきたいと思います。
iPad 作りまくりの話
ネットで選挙運動できるかもしれない話
雑感:
法律的根拠が全くない(無視してかまわない)リンク禁止条項よりも、 URL の汚なさと title のなかに記事タイトルが入ってない事の方が問題
追記:
右クリック禁止されてるみたいですね、、、
もう何も考えたくないです、、、
フィードとかも一切吐いてないし、これは読んでほしくないということなのでしょうね。
読んで欲しくないサイトを公開する意味が僕には全く理解出来ません。
お前は腐女子かって話ですよ。
ここまでやるなら、検索避けも導入してもらいたいところですね。
2010 : 01 02 03 04 05 06 07 08 09 10 11 12
2009 : 01 02 03 04 05 06 07 08 09 10 11 12
2008 : 01 02 03 04 05 06 07 08 09 10 11 12
2007 : 01 02 03 04 05 06 07 08 09 10 11 12
最終更新時間: 2010-08-05 22:09