2013.6.7
第９回
次回以降の予定
・PaaS API
・ヘルスケアデバイス系API Nicke+とか
・地理系API GEO系
・決済系API
■twitter API1.1
・Twitterエコシステムの定義
・いわゆるtwitterクライアントは自社で出すので作って欲しくない
・”クライアント”の定量的な判断基準はない
・今後新規のいわゆるクライアントはもう無理（ユーザ10万に限るなど…）
・ポイントはtwitterにとって有益になるかどうか
・ディベロッパ利用規約変更
・表示形式の指定がrequiredに
・タイムラインのレンダリングは、twitterのタイムラインであることがわかるように
・twitterの鳥を配置
・API1.0 -> 1.1
・endpointの変更
・単純なURLプリフィクスの変更
・xml廃止、jsonのみに
・廃止されるエンドポイント（public_timeline, retweet関連など）
・レートリミット方式変更
・1.0：1アカウント350回/1時間、1.1：1エンドポイント15回/15分・多く使われるものは180回/15分 （いずれもOAuth必須）
・OAuth必須に
・1.0：一部は150回/1時間でOAuthなしで呼び出し可能、1.1：全て必須
期限
・1.0は、3/5＞6/11に廃止（at SF time）
移行
・twitter4j（Java）：バージョン3.0.xに切り替え＞コンパイルエラーをつぶす
・他言語：エンドポイントのバージョン部分を1から1.1にかえてエラーをつぶす
■Twitter Cards
・tweetにメタ情報、付加情報を埋め込む為の仕様
・140文字以外の文章として出してくれる
・例：webページURLをはるとそのページのアイコンが自動で表示
・例：SlideShare、tweet内にスライド
方法
・webページにmetaタグで埋め込む
・twitter:card, summary photo, player
Twitter CardsとOpen Graph
・twitter cardsはopen graphがベースになっており、だいたい一緒
・基本のメタ情報(url, title, description, image...)はopen graphを設定しておけばtwitter cardsとして表示される（twitter:cardは必要）
事前申請が必要
・open graphは普通は不要（Facebookなど）
・twitterの申請ページからフォーム入力して申し込み
・期間は数日から2週間くらい（申請確認メールに返信すればチケット作られるのでやってくれるはず）
・何故必要なのか
・tweetが多いので全URLに反応してクロールするのは高コストなため事前申請（ほぼ登録みたいな感じ？）にしている
＞webを展開するなら、Twitter Cardsは対応しておいた方が良さそう。tweetへの追加情報の表示は魅力的
■なんとなくわかってきたtwitter APIとのつきあい方（小宮さん）
・twitter4jを使ってツイートをDBに蓄積するにあたって、実際のなま情報
・仕様と違うとか
・注意するポイント６点
１）アプリケーションの登録に注意する
・WebSite：twitter.comドメインとかいれといてAPIをはげしくつかうと、アプリケーションのstatusがsuspendedになって、アプリケーションも削除できずどうにもできなくなる
２）絵文字に負けない
・絵文字（UTF-8外字）を含むテキストをVARCHAR(140)に保存すると文字数オーバ
・絵文字を保存する際は、MySQLならcharsetをutfmb4にする必要があり、絵文字1文字につき4文字分消費するので、560にする必要がある
３）NULL文字に負けない
・時々tweetにNULL文字が紛れ込むことがある
・NULLは除外する方がよい
４）NFD/NFKDに負けない
・UNICODE正規化：発音記号等を1バイト文字2文字で表現するような分解
５）ユーザが常に存在するとは限らない
・search/tweetsのstatus["user"]が存在しないことがある
６）screen_nameが15文字であるはずがない
・サイトには15文字と書いてあるが、過去に20文字許されてた時期があった。
■家族フォト
MVP（mininum valuable product）
・最小構成でサービスをリリースする
・その後仮説と検証を経てよりよいものにつくってく
ベネッセとデジタルガレージの協業
・2ヶ月でweb, iOS, Android向けアプリを出さなきゃなかった
・APIは自社json（HTTPS）、bgはappEngine
・appEngineではSSLを使う際、金払った実績がないと利用できない制約がある
・appEngine：dbモジュールからndbモジュールに変更：modelで定義してるものは自動でmemcacheでキャッシュを利用してくれる
・スマホアプリは基本APIをたたく。
・PhoneGapを使った（iphone4あたり少しもっさりだが、一般のユーザはそんな気にしない）
・sharp端末で不具合頻発、あとandroidでは画像の保存ディレクトリが端末によって違ったりした
・phonegapはhtml+css+jsで開発しやすかった
仮説と検証
・DL当日しか使ってないユーザは30〜40％
・週1以上起動ユーザは約半数
■Acitivity body (fitbit API)（朝倉さん）
・アクティビティトラッカー
fitbit feature
・歩数
・移動距離
・消費カロリー
・上位機種は、階段上り下りや睡眠時間なども記録可能
Fitbit API（json or xml）
・userinfo
・body measurements(体組織：体重、慎重)
・Activities（歩数とか）
・利用
・要ディベロッパー登録
Third party libs
・ruby, php, .net, java
■飯テロのススメ（美馬さん）
・twitter日本語で、一番つぶやかれる時間は0時
・おやすみが一番いわれるのは23:50分くらい
■Application-only authentication
・ユーザの認可を必要とせずに、twitter APIにアクセスできるようになる認可方式
・tweet投稿や、フォロー等の操作に依存するAPIは使用できない
・一部APIのレートリミットは大きく緩和されている。search/tweetsは+270回、friends/list・folloowers/listは+15回
twitter4jでの実験的な利用方法
・OAuthコンシューマーキーを作る
・twitter4j.propertiesを編集する：consumerkey, consumersecretの設定、useSSL=true（3.3.4以前）、enableApplicationOnlyAuthentication=trueにする
・twitter.getOAuth2Token();を呼び出すとA-oAが適用になる
■だれとくアプリからSNS活用への道（佐藤さん）
・秋葉の雁川という中華料理屋のアプリ
・そのおすすめアプリサービス（androidアプリ）
・twitter, Facebook, mixi, forsquareへ同時投稿や行ったときのチェックインを一括で行うアプリ
・twitter ->twitter4j, forsquare->forsuqare-api-java
・mixi, facebook ->SDKが多機能だったので独自に利用部分だけ実装
・公開後1年たったら公式アカウントからキャンペーンに使いたいという連絡が来た＞杏仁豆腐おごってもらった。
その他メモ
・twitterのAPIが1.1になって、tweetを集めるのはやりやすくなったが、フォロワー関係を取得しづらくなっている
・3時間で128ツイート、1日に1024ツイートで規制。メンションしまくりでsuspended
