Twitter API, favoritesのレスポンスの考察

RailsでTwitterAPIを使ってfavoriteを取得する処理を実装したけど、表示が遅かったので、調査してみた。

前提：
gem Twiiter

コード：
client.favorites(count:200)
clientは別途初期済み

計測：
MiniProfiler gem を使って計測。導入が簡単でかなり助かった。
http://yachibit.hatenablog.jp/entry/2013/05/29/004756

count:200

API getで合計500msくらいかかっていて、これは厳しい。
他のリソース使ったことないけど、favoriteは特別遅い気がする。
以下、いくらか処理を変えてみたけど、変化なし。

結論：
バックグランドで取得する。
取得件数・検索範囲を変えても効果ないので。

count:10

since_idを付加して、直近のツイートから検索。

今までの振り返りと、見えてきた方向性

ソフトウェア開発をしてきて10年が経過して、今までのこと、分かったことを整理してみる。

略歴

福島県生まれ、中学校まで福島で育つ
高専に入学し、宮城県でプログラミングを学ぶ
卒業後、東京に本社のあるSIerに就職
と思ったら、配属されたのは宮城県で組み込みソフトの開発
マイコンとかそんなに好きじゃないな、と思いながらも、車載ソフトを結構頑張って開発
主に海外向けの開発を楽しくやらせてもらい、出張でも良い経験・人脈を築けた
プロセスにこだわって、独学で学びながら実践でもノウハウを蓄積
ポイント：MBD、TDD、リファクタリング、課題管理、日程管理、チーム運営

要件定義、設計、実装、テスト支援、チーム管理と一連の仕事をこなして10年経ち
最新のソフト開発を求めて、Web開発に転職
現在、Ruby On Railsでサーバーサイドの開発に勤しむ

こだわり

コードにこだわる

潔癖コーダーの名のとおり、DRYでリーダブルなコードにこだわっています。書籍やWeb記事で情報はたくさんありますが、実践出来ている人は少ないです。

理由は様々ある（使い捨てのコードとかプロジェクトが短期間とか）と思いますが、どんな理由があれ、コードにこだわらない人はいつになってもできるようにならず、そういう人に増えるにつれ、チームのサステナビリティ・モチベーションはどんどん低下し、Outputの質が落ち、プロジェクトの最終的な品質・価値は低いものになってしまいます。

プロセスにこだわる

コードにこだわるためには、プロセスにこだわる必要があり、テストを使ってリファクタリングすることが欠かせません。全体の設計ももちろん重要で、不適切な機能分割では無駄なコードを作りがちですし、テストもしづらいです。

総じて、全体設計→実装→テスト→リファクタリングと、どれか一つでも手をぬくと最終的な品質の低下・遅延になります。

否定しない

自分が否定されるのが嫌いなので、人のことも否定しないようにしています。否定してしまうと、否定しあう負のスパイラルに陥り、消極的になってしまいます。
議論でも、なるべく否定せず、肯定的に建設的に結論をつけるようにしてます。

目指すところ

たくさんの人が使って、楽しい・うれしいWebサービス

月並みですが、GoogleやFacebook、Airbnbなどのサービスが好きです。

・一過性ではなく継続して使えるもの

・楽しいだけではなく、生活に不可欠だったり、楽になる

ハードウェアも連携

Webだけで完結せず、ARやVR、カメラなどを使ったセンシングで新しいUXを提供したいです。

Ruby On Rails でTwitter連携アプリのプラクティス

Webでも記事が多い情報になりますが、実際にきちんと運用できるレベルの実装をするとそれなりにポイントがあったので、ブログとしてまとめてみます。
また、最後にTwitter　gemを使ったベストプラクティスとして、モジュール化したコードを載せておきます。これはWeb上にもなかなかないので、ぜひ参考になれば幸いです。

参考：
https://syncer.jp/twitter-api-matome
https://takuyokomizo.com/ruby-twitter-api/

Twitter認証

gem omniauth を使いました。https://github.com/intridea/omniauth
使い方は、wikiが詳しいです。特に難しいことはなし。
以降は、情報が少ないものに絞って列挙しておきます。

TokenをSessionに保存

    auth = request.env['omniauth.auth']
    session[:access_token]        = auth['credentials']['token']
    session[:access_token_secret] = auth['credentials']['secret']
    session[:username]            = auth['extra']['raw_info']['screen_name']

    session[:profile_image_url]   = auth['extra']['raw_info']['profile_image_url_https']

このときに、なるべく情報を保持しておくと、API回数制限を少しでも回避できる。

使える情報は、こちらから。https://github.com/arunagw/omniauth-twitter

テスト

https://github.com/intridea/omniauth/wiki/Integration-Testing

wikiどおりで基本はOK.

　@auth_resp = {

      provider: 'twitter',

      uid: '123456',

      info: {

        nickname: 'johnqpublic',

        name: 'John Q Public',

        location: 'Anytown, USA',

　　。。。

    OmniAuth.config.test_mode = true

    OmniAuth.config.mock_auth[:twitter] = OmniAuth::AuthHash.new(@auth_resp)

authのテストデータは、TwitterAPIのExampleレスポンスを基にするとよい。

https://dev.twitter.com/rest/reference/get/users/show

認証失敗のテストは、バグがあってWikiどおりにはできない。

OmniAuth.config.mock_auth[:twitter] = :invalid_credentials

これをやっても、Failureのパスには飛んでくれない。

通常のパスに飛んで、CredentialsがInvalidになるだけ。

https://github.com/intridea/omniauth/blob/1cc1cf4b2821a7d2a4a376a5ca93c61b6bd8b5f1/spec/omniauth/strategy_spec.rb#L663

Twiter API

client

gem 'twitter' を使った。使い方は、参考URLが詳しい。
テストなどに使うデータは、Twitter APIのページを見ると例がのっているので、それを流用すると簡単。

update profile image

https://dev.twitter.com/rest/reference/post/account/update_profile_image

このAPIを使用したところ、レスポンスでくるprofile_image_urlは更新前の情報になることがあった。これは、Twitter側でデータを更新するタイミングで発生していると思われ、その時によって、発生頻度はまちまち。頻発するときもあれば、出ない時もある。

対策は、レスポンスを使わずに、自サーバーで保持しているデータを使うことにした。
本質的な解決とはいえない気もする。
APIで取得しなおすと、レートリミットに＋1されてしまうので。

APIレートリミット（回数制限）

こちらも既にWebで情報があるので、簡単に。
https://dev.twitter.com/rest/public/rate-limiting
15分に15回のAPIのアクセス制限あるよということ。世のアプリも結構引っかかることが多いらしい。
今回とった施策は、
・認証時のレスポンスをなるべく使う。
・既に持っているデータはなるべく取得しない。

TwitterアイコンのdefaultイメージはCORS

defaultイメージ(卵アイコン)は、URLのドメインが通常とは異なり、CORSが許可されない。つまり、直接HTMLに画像をURLで埋め込むことはできない。
対策：
予めdefaultイメージを保存しておいて、ドメインが変わったらそちらを使う。
defaultイメージは、7種類あって0からの連番だった。（自分が確認した時点で）
使用した正規表現　regex = /http.*default_profile_images\//

その都度、wgetでローカルに保存してそれを使うこともできたが、実装のインパクトが大きかったので、上記方法を採用した。

CORS(Cross-Origin Resource Sharing)は、その名の通り、ブラウザがオリジン(HTMLを読み込んだサーバのこと)以外のサーバからデータを取得する仕組みです。http://dev.classmethod.jp/cloud/cors-cross-origin-resource-sharing-cross-domain/

Twitter client module

https://github.com/Samemura/twitter-client-practice

新しいプログラミング言語の習得、Kata

新しい言語を習得、Kata

プログラミング言語を学ぶ

初級者

構文を覚える

簡単なプログラムを作る

中級者

少し難しい使い方を覚える

配列

ハッシュ

クラス

ライブラリ

上級者

人に教える

ライブラリを作る

これは結構充実

意外と少ない 今日の主題

どうやって

初級者

書籍

Webサービス

まとめ (link)

サービス名 日本語対応 学習スタイル エディタ機能Codecademy △ テキスト ○ドットインストール ○ 動画 ×Progate ○ テキスト ○ミニツク ○ テキスト（一部動画） ×CODEPREP ○ テキスト ○RubyWarrior × テキスト ○CodinGame × テキスト ○

RubyWarrior (link)

中級者

日々の業務

Webサービス

上級者

フォーラム

Github

いいところ

他の人の回答が見れる (link)

いっぱいクリアすると、昇級する

1問、20分前後でできて、ちょうどいい

対応言語が多いので、新しい言語の勉強に良い

新人教育にも良い

いざ実践 (link)

Githubでログイン

Kataを選ぶ (link)

テストを読む

コードを書く

テストする

回答を送信

def days_until_christmas(day)

 date = Date.new(day.year,12,25)

 date = date.next_year(1) if day.month == 12 and day.day > 25

 date - day

end

Kataとは (link)

空手の型 繰り返しの練習

「格闘技の世界では練習もせずいきなり試合にでるなんて自殺行為に等しい。スポーツや芸術、手工芸の世界でも常日頃から地道な反復練習が必要不可欠だ。それなのに、プログラミングの世界では最初に大学などで基礎を習った後、仕事をしながら技術力を高めようと考えるのが常識だ。これはおかしい。プログラミングの世界でも、既存技術の反復練習や新技術の習得に、継続的にいそしむべきだ」

つまり

こういうこと

Mindmesiter プレゼン お試し埋め込み

MindMesiterのプレゼン機能を試してみた。

前提

MindMeisterのフリープラン
GoogleDriveにmindファイルを保存して、管理

やりたいこと

• マインドマップをプレゼンに使う
• プレゼンをブログなどに埋め込んで、再利用できるようにする。GooglePresentationみたいに。

マインドマップをプレゼンに使う

マインドマップを作成して、プレゼンを設定する。

マップをリンクで共有（閲覧）して、自分がプレゼンを開始すると、放送できる。

はずだったが、プレゼンの放送はフリープランでは対応外らしい。
ただし、あまり使う場面がなさそう。Hangoutとかで画面共有すればことたりす。

プレゼンを埋め込む

埋め込めたけど、スライドショーは動作せず。
フリープランだからか。Proになると、PowerPointにもできるらしい。

RTFで吐き出して、GoggleDriveにインポート。それを開いてコピペすれば、リンク含めていい感じにBloggerに貼り付けられる。
あとは、PNGで吐き出して貼り付け。

プレゼンお試し 所有者： Masaki Murano