なかなか便利 tweepyのソース読んだり、ぐぐったりしながらなんとか形になった。ここで言う擬似ストリーミングはツイッターのStreaming APIではなく、Rest APIを自動で投げて表示させるって意味なので全然Streamingじゃないですね。 リストにStreaming APIが提供されてないことに気づくまでバカみたいに探しててバカみたいだった。バカみたいだった。 記事執筆現在、API1.1のリストタイムラインの取得制限は180回/15分なので、単純計算で5秒に一回投げれます。スクリプトでは読み上げ時間も+8秒ぐらいで余裕を持たせてます。リストの流速によっては取得漏れが発生すると思いますが、それぐらいだとそもそも読み上げが追いつきません。リスト廃人とかじゃなかったら大丈夫だと思います。 英語用のリストを英語で読ませたり、単に気になるリストを読み上げさせたりと結構おもしろいです。
Introduction An API, or Application Program Interface, enables developers to integrate one app with another. They expose some of a program’s inner workings in a limited way. You can use APIs to get information from other programs or to automate things you normally do in your web browser. Sometimes you can use APIs to do things you just can’t do any other way. A surprising number of web properties
イイ感じに Tweet を収集したい。 というわけで何も考えずに Tweet を収集出来る Heroku-ready アプリを作りました。 キーワードを指定し、合致する Tweet を収集することが出来ます。 使い方 git clone git@github.com:kaiinui/tweet_collector.git config/keys.yml に Twitter App のキーと Firebase の Base URI を書く(下記参照) config/words.yml にトラッキングしたいワードを書く。("xvideo"とか面白いと思います。) ./push これでたくさんツイート収集してツイートコレクターの称号をゲットしましょう! 注意点 日本語ワードを使うと上手く取れません。(TwitterのAPIの都合) 1つの Twitter App につき1つのtweet_coll
DjangoからTwitterアカウントにOAuth認証してTwitter API を利用しようと思う。 python-twitter を利用して容易に実現。。。と思いきや、若干はまったので、メモしておく。 やりたいことは、利用者の認証と、利用者のリソースへのTwitterAPI経由でのアクセス。 1.OAuthの基本的な流れ まずは、利用者にTwitterのユーザー認証をさせたい。Twitterでは、認証にOAuthを利用している。OAuthによる認証のシーケンスは、以下のサイトがわかりやすい。 http://www.atmarkit.co.jp/fsecurity/rensai/digid01/02.html 下図でいうと、Resource Owner が、Twitterのユーザーであり、開発アプリケーションの利用者。OAuth Client が、開発アプリケーション、OAuth Se
実際にはこの定義に加え、自動的に id という列が定義されます。では最初に myapp アプリ内に item モデルを作成し、これらの3つの列を順に定義していきます。まず model name は "item" を入力します。次に data-source は、今回はデフォルトのメモリ DB を使うので "db (memory)" を選びます。またこのモデルは永続性(persistant)を有効にしたいので、その Base class には "PersistedModel" を指定してします。またこの item は REST API で公開したいので Expose するかどうかの質問には Yes を選択。この item モデルの複数形名にカスタムな名称を使うわけではない(普通に items とする)ので、Custom plural form の質問は空のままで Enter を押します。そして
ニコニコ動画API単語 ニコニコドウガエーピーアイ 3.4千文字の記事 33 0pt ほめる 掲示板へ 記事編集 概要公式API非公式API API利用ツール等外部リンク関連項目脚注掲示板ニコニコ動画API とは、ニコニコ動画で利用可能なAPI (Application Programming Interface)である。 概要 中の人曰く、 [1] 現時点でも様々な方法でニコニコ動画内の情報(動画情報やサムネイルなど)を取得している方がいると思いますが、これも思ったより負荷がかかるので心情的にはやめてほしいというのが正直なところです。できれば負荷の少なそうな時間帯にやってもらえるとありがたいです、こっそりと。 最終的には他のサービスと同様にニコニコ動画内の情報を提供するAPIというのは用意していく予定で、具体的なスケジュールはまだ未定ですが年内にはいろいろできてるんじゃないかと思います。
いいねの対象に指定されているページ内に、og:urlがあった場合、facebookのクローラーはそのURLへリダイレクトを行う。 その先にも指定されていた場合、リダイレクトを繰り返した結果、最後のページに書かれたogpの情報を読み取る。 <meta property="og:title" content="タイトル" /> <meta property="og:type" content="website" /> <meta property="og:url" content="http://redirect" /> <meta property="og:description" content="概要" /> <meta property="og:image" content="http://hoge/thumb.png" /> ogpタグを指定していない場合は、canonical が使
140dev Twitter API Programming Tips, Tutorials, Source Code Libraries and Consulting streaming_framework As described in the code architecture, the tweets received from the Twitter streaming API are stored in the database in two steps. First the entire payload for each tweet is stored in the json_cache table by get_tweets.php. No parsing is done at this point, instead all the data for the tweet is
Clarifai is recognized as a Leader in The Forrester Wave™: Computer Vision Tools, Q1 2024
【特定のURL(記事)の、Facebookの「いいね!」「シェア」「コメント」数を取得する】graph apiじゃなくてFQLで取得する このブログのある箇所では、記事一つ一つに対して、Facebookでの「いいね!」「シェア」「コメント」数を、プレーンテキストで取得しています。それでですが・・・去年の末あたりから(12/27,28あたりかな、厳密にはわかっていません)以降に公開した記事に対しては、「graph api」を使用しても取得できなくなっていました。 具体的には、以下のような現象です。 取得できていた例以下は、2012/12/17に公開した記事です。 http://graph.facebook.com/https://www.imamura.biz/blog/web/7998{ "id": "https://www.imamura.biz/blog/web/7998", "sha
前提:Twitter Developersでアプリのconsumer_key等を取得しておく必要があります。詳しく知りたい人は「Twitter OAuth」などを調べるといいでしょう。 なぜこんな技術が必要なのかは、cURL編で書きました。 Streaming APIを使うときは、接続が切れてしまったときにいかに接続し直すかというのがキモなわけですが、cURLで簡単に実現する方法がわからなかったので、240秒ごとに強制的に接続し直すという方法を採用しました。この方法には、(1)再接続のときにつぶやきを取りこぼす危険と重複して取得する可能性があること、(2)接続が切れてから再接続を試みるまでに平均で120秒かかる、という問題がありました。 Streaming APIは、つぶやきが無いときには「CR LF」を30秒おきに送信してくるので、これをチェックすれば切断を検出できるのですが、検出と再接
アーキテクトの(機能面での)主要な仕事の1つに、システムを構成するサブシステム/コンポーネントの境界、つまりインターフェイスを決める、というものがあります。またはそこまで大げさに捉えなくても、例えばライブラリのAPIを設計する、というのは単にプログラミングをする、ということとは少し違う視点が求められるように思います。 案外インターフェイスを考えるという観点での技術書まとめがないような気がしたので、需要があるかわかりませんが関連して読んだ本を紹介しておきます。なお、個人的なキャリア上、C++/Javaが対象です。(色々経験したら随時追加するかも知れません) 何か他にいい本があったらぜひ教えてください。 言語仕様をきちんと知る まずはAPIを設計する対象言語をよく知る、ということは必要であると思います。これだけだと、結果的にプログラミングに精通するということとあまり変わりはないかも知れません。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く