おがた (@xtetsuji) です
Twitter への連携を要求する連携サービス（アプリ）はたくさんありますが、中にはそれを承認するとユーザに感染するように悪事を働くマルウェアと呼ぶに相応しいものもあります。
特に linkis.com （または短縮リンクより ln.is と呼ばれる）というサイトとアプリは、Twitter 上で承認をしたユーザのツイートを悪用し感染していくものとして有名です。
私が解説するまでもなく、上記を含めた様々な場所で注意喚起が行われています。
この linkis.com の問題点、そして簡単に探す方法であったり、Twitter マルウェアに対処する方法をまとめてみます。
おがた (@xtetsuji) です。
今回の記事は、ちょっと「気がついたから考えてみた系」のただのエッセーです。
Twitterにはツイートの「お気に入り」という機能があります。よく「ふぁぼ」とか言われるものです。ここではRTのように、Favということにします。
Favは「あとで読む」的な意味合いもあるとは思うんですが、世の中「あとで読む」とタグ付けされたものは、大抵あとで読まれないという法則があります。
自分も大量のブックマークをDeliciousに投稿したりしていますが、「あとで読む」というタグ付けは使わないようにしています。逆に「何度も読みたい」というタグ付けにして、一度は必ず目を通す、目を通すまでブラウザのタブは閉じないようにするという流れにしています。そういうようなタグ付けの工夫をすることによって、Deliciousブックマークの内容をあとで活用できることが多くなってきました。Delicious側が過去ブックマークの表示機能を高速化したというのも大きいです。使いやすい。
TwitterのFavも、この「あとで読む」的意味合いが多少なりともあると思います。もちろん、Fav結果がツイート主などにも伝わるのでそのツイートへの同意を示す意味合いや承認的意味合いもあるでしょう。ただ、このFav、あとで見返すことができるようになっているのに、しないのはもったいないなと感じた次第です。Deliciousブックマークの振り返り運用が最近うまくいっているからこそ思ったことなのかもしれません。
サードパーティのTwitterクライアントでは既に全てのFavをたどれないかもしれません。その場合はTwitterの公式クライアントか公式ウェブを使えば、少なくとも1000ツイートFav程度ならたどることができます。この理由は後述。
自分の場合、メモっておきたいツイートは自分専用のプログラムで自分用IRCチャンネルに投稿してIRCボットにログを取ってもらうようして (簡単なコンセプトは以前トークした「クリップボード監視と外部コマンド実行 #chibapm」のスライドを参照) います。ボタンひとつでログファイルに残るので、便利でガンガン使っています。ログファイルの検索も簡単なので、あとで「あのツイート、コピーしておいたけどなんだったけなー」といった時にも役立ちます。
TwitterのFavツイートは事実上あとで検索できないし、自分で書いたプログラムで回収しようとしてもTwitter API1.1のレートリミットの制限で指定時間内に数百ツイートしか回収できないようで、自分がFavするツイートは「これぞ」といったもののみに最近はしています。Tweetbot for iOSというクライアントでも2012年くらいのツイートまでしかたどれませんでした。これはTwitterクライアントが悪いわけではなく、Twitter社の提供するTwitter API1.1での制限です。
気になったツイートのロギング手法については、こんどいくつか解説してみたいと思います。
というわけで、私のFavには特別な思いがこもったものが多いのですが、それを振り返ってみようとして気づいたことを書いてみたいと思います。実際にツイートを列挙して振り返るのは今度にしようと思います。
Twitterは2006年頃からあるサービスですが、当時ブログや公での発言にあまり積極的でなかった私は「マイクロブログ」と称していたTwitterに対しては距離を置いていました。
ただ、2008年頃からジワジワとTwitterは日本でも影響力を増していきます。2009年9月のYAPC::Asia TokyoではTwitterを主要な連絡手段にするというアナウンスがあって、そこで半ば負けた気持ちでTwitterに登録したのが2009年9月9日でした。
最初のツイート。敗北を認めた感じが伝わってきます。当時は2008年くらいまで多忙を極めていて、ネットのトレンドなどが追えていなかったことがあって、Twitterは流行らず消えると考えていたり、とにかく勘が鈍っていたような気がします。
登録してみた。負けた気がすごいする(笑
— OGATA Tetsuji (@xtetsuji) September 8, 2009
その後、試行錯誤しながらツイートしていきますが、Twitterの楽しさというか活用法も分かってきて、同報通信的用途や自分のライフログ的用途に活用していくようになります。特に2011年3月の東日本大震災前後でTwitterの活用が広がっていったり変化していったような気がします。
他のブログ記事でも書きましたが、2011年からは勉強会でトークするようになったり、ブログを開設したり、対外的な発言も積極的に行うようになって、Twitterとの連動も広がっていきました。
震災に対外的活動デビューにと、2011年は節目の年でした。
2009年9月9日から2014年3月16日までの間に、私のFavツイートは1000ちょっとあるようです。https://twitter.com/xtetsuji/favorites にアクセスして、たどれる最初のFavまでたどって、Chromeのデベロッパーコンソールで document.getElementsByClassName(“tweet-text”).length を打った結果です。最初はよく分からずブックマーク代わり程度にFavを使っていたので、厳選してこの数というわけではないです。
とはいえ、Twitterのウェブインターフェースでは、たどれるFavの数に制限は無さそう(3200制限はあるかもしれない)なんですが、どうも2012年11月4日以前のツイートのFavの取り消しができないっぽい。もしかしたら私だけの現象かもしれませんが、Twitterは定期的に仕様を変えてきているので、何らかの要因はあるのかもしれません。特定の人にだけ起こる不具合というのもTwitterにはあって、それを踏んでいるのかもしれません。
当時はフィードリーダーの代わりにTwitterのURL付き投稿をブックマーク感覚でFavしていたのですが、あとで検索できないということもあって、このフィードリーダーのブックマークがわりとしてFavを使うのは、本当に大切なFavツイートを見返せないから良くないなと今になって追っている次第です。
実際に同感して付けたFavツイートを振り返って、当時または今の自分がどう考えるか、時間を見つけて少しずつ振り返ってみたいと思います。
おがた (@xtetsuji) です。
主にTwitterの実況時など、フォロワーのTLは汚しくたくないけどハッシュタグで検索はされて欲しいというときがあるかもしれません。そのようなときに役立つTips。
この手の話題が出ると、多くのサイトでは「@null への返信としてツイートすれば良い」と書かれています。これは数年前までは良かったのですが、2013年現在は @null という通常ユーザが居るので、これをフォローしている人 (稀ではありますが) にはTLを見られてしまいます。まぁ、@null をフォローしているということは、それを見たいという意思表示なのではありましょうが。
そこで生まれたのが @no_TL というアカウント。これもれっきとした存在するアカウントですが、このアカウントは鍵アカウントとなっており、フォローしようと思ってもフォローさせてくれません。
フォローさせてくれないので、@no_TL への返信としてツイートすれば、ハッシュタグなどで拾われるけれど、フォロワーのTLには表示されないツイートをすることができます。
Twitterでは複数アカウントの作成は許可されているので、作戦として自分自身で @no_TL のようなアカウントを作成してしまうという手もあるでしょう。ただ、それだけのためにアカウント作成をするというのも手間なので、同じ趣旨として作られた @no_TL を「利用させてもらう」ほうが手間も少なくて良いと思います。
最終的な結論としては、TLを埋め尽くして迷惑をかけるくらいの実況ツイートをすることがある場合には、実況専用アカウントを取得するほうが手っ取り早いと思います。私もテレビ実況用に別アカウントを作成しました。結構はかどります。Twitterで複数アカウントを持っていると都合が良い場面もあるので、多少の登録の手間が気にならない人は、用途に応じて別アカウントを作成してみるのも良いでしょう。
もちろん分かっている人は多いかと思いますが、@no_TL の返信にしても「フォロワーのTLに流れない」だけであって、「そのツイートが自分以外に不可視になるわけではない」ことに注意しましょう。自分のツイート一覧を見られれば、@no_TL への返信も見ることができます。
こんにちは、最近はTwitterで開放的に発言しているおがた (@xtetsuji) です。
ネットを検索していると「TwitterとFacebookを連携すべきか」「Twitterの投稿をFacebookに流すべきか」「Facebookの投稿をTwitterに流すべきか」という疑問が散見されました。私もどうするのがいいのかと思っていたので、興味深く読みあさってみましたが、後述の理由によりあまり参考になりませんでした。
この場合、「すべきです」という「主張」は少なくて、そういう人は主張するまでもなく「やり方」を書いて終わりにする人が多いようです。2012年11月現在であれば、https://twitter.com/settings/profile にアクセスしてTwitter社が提供するTwitter→Facebookの連携投稿が設定できます。Facebook→Twitterの連携投稿も https://apps.facebook.com/twitter/ 等でできるんじゃないでしょうか、以上、って感じです。すべきメリットとかの主張は無し。あらら。
一方、「すべきではない」という主張をする人も一定数いて、特にFacebookに思い入れのある方の一部がそういう主張をしている事が多いようです。ただ、理由が論理的でないところが笑いどころで、「TwitterとFacebookは空気感が違うからです！！！！！！」なんてキリッと言ってしまうところが意味不明。空気感って何だ？文字数の違い？こういう回答をしている人は大抵「Facebook◯◯の会」「SNS◯◯の会」といった肩書きを名乗っているのも面白かったです。思い入れ強いんだね。
…;とは言っても、私のTwitter TL、Facebookニュースフィード、両方じっくり見ていても、そんな空気感の違いがあるようには思えない。Twitterでも承前承前を繰り返して140文字をはるかに越える議論を展開した挙句Togetterでまとめられるケースもあったり、比較的長文が投稿できるFacebookでも一言二言しか投稿しない人がいたり、投稿内容や投稿文字数が醸し出している空気感という違いは無いように感じます。Twitterはエコシステムが発達しているので、画像を添付したりも擬似的にできますし、その点の機能についてはFacebookと大差ない。
まぁ、Twitterは不幸自慢、Facebookはリア充自慢が蔓延している傾向といった違いはありますが、リア充自慢はSNSの歴史が始まってからの伝統みたいなものがありますから。Twitter社はTwitterのことをSNSではなく「マイクロブログ」と読んでSNSではないと否定しているわけで、私もそれに賛同する派です。
ただ、TwitterにはRTがあったり、Facebookには「いいね！」やシェアがあったり、両者には機能的に違うものがあるのは確かです。同じTwitterでも、ウェブで見るのと各種クライアントソフトで見る場合では風景が違うように見えるのは気のせいではないでしょう(Twitter社は現在、Display Requirementsを開発者に強要する事でその違いを排除しようとしているようですが)。
ではどうするべきか、考えてみました。
「Twitter→Facebook連携」と仮に名づけてみましたが、Twitterの特定のアカウントに投稿した内容をFacebookのウォールやページに投稿することです。
この機能はTwitter社が提供していて、2012年11月現在 https://twitter.com/settings/profile にアクセスすればすぐに設定することができます。Facebookでもサードパーティが作った機能もあるけど、たぶん似たり寄ったりだったりTwitter社のDisplay Requirementsで排除されるかもしれなかったり、流動的なので、もしやるのであったらTwitter社公式の機能を使ったほうがいいんじゃないかな、というのが私の考え。
ただ、この機能はTwitter社公式(?)の機能にも関わらず、連投したツイートを本当によくこぼす。後述の議論にもありますが、これでは色々と使えない。
「ところで、Twitter→Facebook連携はすべきなの？すべきでないの？」の私なりの答えをしていませんでした。
私なりの回答をしますと「文脈を持ったツイートをFacebookにフィードするのはやめたほうがいいのではないか、それ以外はご自由にどうぞ」といった感じになるでしょうか。
では「文脈を持ったツイート」とは何かというと
等のこと。
先ほども挙げた通り、Twitter→Facebook連携は、よくツイートをこぼします。例えば A B C Dとツイートを連投した場合、B をこぼすことは結構あります。また、Facebookの恣意的なエッジランクにより、他者のFacebookニュースフィードでは、A B C D の順で表示されるとは限らないという点もポイントです(その人のウォールに行けば順序そのものが見られますが、そこまでする人が一体どれくらいいるでしょうか)。最悪、「Bをこぼされる→FacebookのエッジランクによってニュースフィードからCが重要でないと見なされ表示されない→時系列無視されて D A の順で表示される」といった無茶苦茶なことがこのシステムでは起こりえます。
この場合「文脈を持たないツイート」つまり1ツイート完結の話題であれば何の問題もありません。こぼされても、エッジランクで淘汰されても他に影響ありません。ただ、そのツイートが文脈を持っていた場合、他のツイートへのフォローや他のツイートからの参照となっていた場合、時と場合によってはFacebookのニュースフィード上で意味不明となる事があります。
特に上記の現象は連投によって起こる事が多く、実況(tsudaる)行為をする人は、普段Twitter→Facebook連携をしていても、実況時には一時的にオフにするくらいしたほうがいいと思います。他者のニュースフィードを埋めて迷惑をかけるからではなく、文脈無視の無茶苦茶な時系列での情報連投になるかもしれないからです。
RTの話では、公式RTは、たぶん標準のTwitter→Facebook連携ではフィードされないはずです。それなのに「さっきのRT…;」というツイートがFacebookにフィードされても意味不明であることは確かでしょう。非公式RTも文脈を持っていて、Twitterの世界の人はそれを追いやすいかもしれませんが、Facebookの世界に閉じこもっている人にとっては、単体でそれを切りだされても分からないといった問題をはらんでいます。RTを実際のツイート上の文脈で語るようなTwitterの使いかたをしている人には、少なくとも私はTwitter→Facebook連携はおすすめできません。私はそれほどFacebook愛がある人ではありませんが、Facebook愛のある人に嫌われるのはTwitterのRT文脈をFacebookに持ち込むことなんじゃないかと勝手に想像しています。
それ以外の一話完結のツイートの場合、Facebookにフィードされたおかげで、Facebookの返信で話題が盛り上がったり、良いこともあるんじゃないでしょうか。連携関係なく、Facebook内部での投稿の場合は、Facebookのコメント機能を利用することが多いので、それがいわゆるスレッドとして機能することで文脈を表現することができます。
今度は逆のケース、Facebookのウォールに投稿した内容を、Twitterの特定のアカウントでツイートする内容です。
これに関しての私なりの回答をしますと「自分のウォールを公開設定にしている人、そうでない人は投稿時の公開範囲設定を理解した人なら問題無さそう。ただ、140文字を越えるポストを繰り返すとTwitterから読むときにリンクを踏むのが相当面倒くさいと思われる」でしょうか。
なんか複雑になってしまいましたが、これの否定形をしているFacebook→Twitter連携のツイートの見え方を考えると良さそうです。
まずは自分のウォールを公開設定にしていない人は、140文字で収まらない長文投稿や、画像等の添付がある投稿は “fb.me” URL を伴ったツイートとして投稿されます。この先にアクセスすれば投稿内容を見ることができるからTwitterにツイートしても問題無いと思われる人もいるかもしれませんが、私はこれが面倒でなりません。たとえブラウザでFacebookにログインしている状態の人でも、iPhone/Android等のスマートフォンではTwitter専用クライアントを使っているケースがあります。そういう場合、URLクリックをアプリ内ブラウザで開こうとするわけです。そこで自分のFacebookウォールを公開設定にしていない人は「Facebookにログインしないと見られないよ」というページを見ることになるわけです。これは面倒臭い。Twitterのオープンな世界と相容れないと感じます。
Facebook→Twitter連携をしている人でも、普段は「友達のみ」の公開範囲で投稿している人はTwitterへのフィードは発生しないはずです。そういう人はFacebookの「公開」で投稿した場合にのみTwitterへのフィードが発生することが分かっているので、そういうときはTwitter向きのコンパクトな発言をしようと理解するクッションが生まれるはずです(と期待しています)。「友達のみ」にはじっくりとFacebookで長文を語り、世間に「公開」する発言はボソッと一言であれば、Facebook→Twitter連携の親和性が生かされることになるでしょう。
FacebookやTwitterは事実上の標準となったことは異論がないと思います。
その他のアプリとのFacebookやTwitterの連携はどうすると良いでしょうか。この場合、2通りの大別をしてみましょう。
SNSやマイクロブログというのは、例えばmixiボイス等のことですね。この場合、mixiボイス→Twitterという連携が考えられます(逆は通常の方法ではできない)。この場合も文脈の議論を持ち出せばいいと思います。mixiボイスならmixiの世界の文脈をTwitterに持ち出したとして、Twitterのみの世界の人に通じるかという思考。mixiボイスで一話完結したボイスをTwitterにフィードするのは何の問題もないと思います。{その他のSNSやマイクロブログ}→Facebookのような連携も同様でしょう。
それ以外のアプリも、TwitterやFacebookへの連携投稿をサポートしているものはたくさんあります。例えばInstagramやFoursquare等。Instagramなどは「写真SNS」などとSNSに強引にくくられるケースもありますが、「いわゆるSNS」と、何らかのキー(Instagramであれば写真)を軸としたゆるいコミュニケーションサイトは別に考えたいところです。
こういうサイトの場合は「一話完結」している場合がほとんどなので、InstagramでTwitterやFacebookに写真投稿、FoursquareでTwitterやFacebookに位置情報投稿というのは一つの話題として良い活用法だと思います。ただ、なぜかはよく分かりませんが、私のTLでは #nowplaying (今聴いている曲) は嫌われる傾向にあるようです。この部分は、通常の投稿同様、何事も限度があって、つまらない写真をInstagramで投稿フィードし続けたり、どうでもいい位置情報をFoursquareで投稿フィードし続けたりしたら、まぁ私でもウザイなぁと思いますね。私はFoursquareのヘビーユーザですが、比較的人の興味をひくと思われる場所のみフィードして、バス停や鉄道駅などへのチェックインはフィードしないようにしています。
以前はTwitter→Facebook連携をしていましたが、前述の「こぼす」問題、あと私があまりFacebookで好まれるような「リア充投稿」をしないので「ちょっと馴染まないなぁ」ということで、現在は連携を切っています。
ただ、Facebook世界の人たちの興味を引くような一話完結のツイートは、別途手作業でFacebookにもクロスポスト(?)するようにしています。私の場合は、Twitterクライアント「夜フクロウ」「Tweetbot for iOS」に投稿するときにツイートをコピーしておいて、Facebookにも合うかなと思った投稿を、OS X / iOS 標準の Facebook 投稿機能でペーストして投稿するというスタイルをとっています。
そういうのが面倒な人の場合、HootSuite等は標準でクロスポストをサポートしているので、そういうクライアントを使うのがおすすめです。私の場合は、Twitterクライアントはユーザストリーム対応じゃないとというこだわりがあるので、夜フクロウやTweetbotを使っているだけに過ぎません。
Instagram、Foursquare等のサイトの投稿は選別しつつTwitterとFacebookにフィードしています。前述の通り、バス停や鉄道駅などのFoursquareチェックインは除きますが、大体はフィードしていますね。その他のアプリについても、だいたいそんな感じ。ただ、ハッシュタグ付きポスト等、Twitterの文脈を強く持っているInstagramやFoursquareの投稿やチェックインの場合はFacebookには投稿しない、といったこともします。
Twitter→FacebookもしくはFacebook→Twitterという連携をしている場合、他のアプリからTwitterとFacebookに同時投稿をした場合に、どちらかに多重投稿をしてしまう可能性があるのもデメリットではあります。私がTwitter→Facebook連携を切った一つの理由でもあります。Facebookのニュースフィードで「それは情弱の所業」と断罪していた人がいたのもキッカケでした。まぁ、Facebookのエッジランクに期待とはいえ、同じ内容の投稿が複数流れてきて気持ちいい人はあまりいないでしょうね。
「TwitterがRSSを殺した」という言葉もあるようですが、ブログの投稿などもTwitterとFacebookに自動ポストするようにしています。私の場合は2012年11月現在Posterousというブログサービスを使っていますが、現在の大抵のブログサービスにはTwitterやFacebookへの更新通知機能は存在するでしょう。そういう点では、RSS/Atomなどのフィードリーダーを知らなかった人も、半リアルタイムで情報をプッシュできるTwitter/Facebookは新しい時代のフィードリーダーといっても過言ではないのかもしれません。
Google+も使ってみたいのですが、久々に行ってみたら見事に廃墟になっていて、退散してきました。TwitterのEvil化(API改訂など)、Facebookの独占などが騒がれますが、現状Google+はそもそも書き込みAPIも持たず、それゆえエコシステムも育たないので、そこが解決されない限り使い勝手は悪いよなぁというのが印象です。ウェブの作り込みは見事なんですけどね。
Google+の投稿読み込みAPIは存在するので、Google+を起点としてTwitterやFacebookへフィードするという使い方もあるようです。
Google+の最近は、ハングアウトなど、TwitterやFacebookよりもミーティングや議論に適した機能などがあるので、一度は使ってみたいものですが、人が集まらない限りはどうしようもないなという感想です。
TwitterやFacebookがEvil化しようと不穏な動きをしようと、多少のことでは現状は揺るがないでしょう。3年先はどうか分かりませんが、少なくともここ1年2年はそうであると言えます。プロプライエタリなシステムが嫌いだと公言している人もTwitterやFacebookを(仕方なく？)使っている時代です。SNSは言うにおよばず、Twitterが属するマイクロブログというジャンルも乱立の時代を経て淘汰され、今後はせいぜい「特化型」が細々と生き残るのではないでしょうか。
全てに平等に情報をフィードして、全てを平等に使うというのももちろんアリかと思います。この記事では「…;すべし」といった強制はしていませんので、この記事が何かの参考になれば幸いです。
こんにちは、「情報はなるべくオープンな場所に」をモットーにTwitterを活用している おがた (@xtetsuji) です。
先日、4月24日になりますが、「Twitter API勉強会」に行ってきました。今回からタイトルに回数が入らなくなりましたが、前回が第5回なので、今回は第6回ということになります。毎月月末開催の活発な勉強会の一つです。
私は今回を含めて3回連続の参加。前回は(グダった)トーク(Slideshare)をしましたが、今回は純粋に聴衆側として参加してきました (今回のfoursquareチェックイン)。
前回同様、公式サイトは無いようですが、Zusaarのイベント開催ページや、Togetterのまとめがあります。
今回の会場は、前々回(第4回)に行われた御茶ノ水のデジタルハリウッド東京本校さんでした。
最初のトークは、@yusukeyさんによる2012年5月12日に変更されるとアナウンスがあったAPIのお話。
このトークは多くのTwitterを使ったサービスの開発者に興味深い事柄ですが、幸いなことにSlideshareで公開してくださっています(2012年5月14日のAPI改訂 概要、Twitter API利用規約概要)。また@yusukeyさんによるブログ記事「第6回Twitter API勉強会を開催いたしました – ビデオ・スライドまとめ #twtr_hack」にてこのトークを含む当日のビデオがとスライドがまとめて観られます。
大きく分けていくつかのセクションに分けて解説をされていました。
とりあえず「II. Principles」を読んでおけばOKだそうです。憲法のようなもの。
詳細は、上記リンクからたどってください。以下は自分の手元のメモより。
「I. Twitter Content」のメモ。
「II. Principles」のメモ。
「憲法のようなもの。これを読んでおけばひとまずOK」
「III. Twitter Functionally in your Service」のメモ。
「IV. Commercial Use」のメモ。
「V. Other Legal Terms」のメモ。
これはよくある免責事項のようなものですね。いちおうポリシーとしては1ヶ月前までには変更はアナウンスされるとのことです。
「アプリ/サービスローンチチェックリスト」のメモ
「5月のAPI改訂」の概要メモ。
具体的なAPI改訂については、一覧 https://dev.twitter.com/docs/deprecations/spring-2012 を参照するか、上記スライドorビデオを参照いただけると分かると思います。メモの転記に疲れた？いや、ここは開発に関わる部分なので公式に近い情報を当たって欲しいという理由です(言い訳？)。
当然の流れかと思いますが、今後のTwitter APIはJSON中心になっていき、今回でAtom形式のエンドポイントが無くなります。今後、XML形式も無くなるかもしれない、とのお話もありました。
@kn さんによるTwitterの国際化のお話。
現在のTwitterは28ヶ国語。50万人のボランティアが翻訳をしているそうです。その翻訳の受理の流れなどを解説してくださいました。
twiccaの作者 @R246 (アオヤマテツヤ)さんによる、AndroidのTwitterクライアント「twicca(ついっか)」の話。
もともとはPHPやJavaScriptやももクロ(?)等のサーバサイドエンジニアだったそうですが、Android初期のTwitterクライアントのあまりの出来の悪さに「つい、カッ」となってつくったのが「twicca」だそうです。「当時はJavaとか知らなかった」という発言もありましたが、「つい、カッ」となった勢いはすごいなと思いました。
ネタが無いので、Twitterで「twiccaについて聞きたいこと」というツイートを流してみたとのこと。
twiccaを開発しようと思ったのは2009年7月当時、満足いくTwitterクライアントがなかったから。前段のお話です。
twiccaではユーザに「色」を割り当てることができるのが特長。クラスタごとに色分けをしたりすることで、タイムライン上の視認性をあげることができる。これは大事なツイートを見逃さないためのツイートなので「カラーラベルのご利用は計画的に」とのこと。
バックアップ/同期を実装しない理由→クラウド同期がかっこいい→クラウド同期ができない理由→サーバ料金を賄えない。
「twiccaサポーターズ」というのがあるそうで、twiccaの開発支援プログラムのようです。シェアウェアではないけど、twiccaを金銭面で応援したい人のための制度。目立つ告知はしていないそう。これに参加するとアプリ内の「twiccaについて」に名前が掲載されるらしい。「twiccaは儂が育てた」と言ってよいそうです。
「例の脆弱性」JVN#31860555 についてもお話がなされました。
「お金を積まれたら売る？」という質問には「売りません」とハッキリ発言。「サポーターズが居る限り」。カッコイイ。
最後にtwiccaアイコンの変遷を解説されて終わりました。
私も寝かせているAndroid端末があるので、ぜひそれでtwiccaを使ってみたいと思いました。
@i2key さん。リクルート(MTL?)の中の人。
「 マイクロコンテンツ化」という仮説を打ち立てて「3文字の絵文字」で情報を伝達できないか、というサービス「さんもじ絵文字できもち伝わる！Happy Balloon」の紹介をされました。
これはタイトルからも分かるようにネタLTの傾向もあって、動画のほうが場の面白さの雰囲気があるので、時間に余裕のある方は動画のほうをご覧いただくと良いと思います。
@tkawa (川村徹) さんによる、返信と@ツイートのTwitter仕様に対する提案のお話。
真面目なお話でしたが、個人的にこれはかなり有意義なトークでした。返信というメタデータと、返信と扱われるか扱われないか現状曖昧な「@ツイート」の仕様について、もっと明確に良い方向になっていって欲しいと思わされました。
詳しくは当該スライドをご覧いただくといいかと思います。
@yut148 さんによるdotCloudを使ったウェブアプリ開発のお話。クラウドを大量に使っているゲーム会社 or エンタテインメント会社に所属して、普段はPHPやPythonを使う方らしいです。
dotCloudを使えばとりあえずドメイン名は振られるので、Twitterのアプリ開発に必要なドメイン名を確保することができるとのこと。それに最初はFree！
Freeアカウントの制限は「登録できるアプリは2つまで」「ディスク容量」とのこと。
dotCloudはPHPやPythonだけでなく、様々な言語の様々な環境が選べるので、今後PaaSの環境として要注目かもしれません。2サービスまでなら無料で作れますし、より複数のサービスを作るのであればディレクトリ構成を工夫したりすることでやりくりできるらしいです。
@yut148 さんは本当にdotCloudが好きな方なようで、dotcloudユーザ会(仮称)を作って活動をしはじめているとのことです。
「困ったら@yut148 に質問送っていただければベストエフォートで答えるよ。」という心強いお言葉も。
私も以前、無料だったのでdotCloudにアカウントを登録したっきり使っていなかったので、これを機会に今度時間を作っていじってみたいと思いました。
情報源
今まで一通りAPIやったので、次回は「Twitter API勉強会」から違う名前に衣替えをする予定だそうです。名前募集中。
スピーカー常に募集中!
今回は貸し会議室での「立食パーティ」形式ではなく、会場すぐ近くの居酒屋での開催となりました。
当初自分が懇親会に申し込んだ時には定員割れになって開催されないのではないかと危惧していましたが、駆け込みで多くの方が参加されて、居酒屋の予約席は満席状態になりました。
Twitter API勉強会といいつつ、私の席ではTwitterの話よりもコンピュータ昔話に花が咲いていた気もしますが、それもまた一興でしょう。
定期的にTwitter開発の旬な話が聞けたり、著名なTwitterクライアントの作者の方のお話が聴ける、この勉強会。非常に有意義でして、私もかれこれ3回の参加をしていますが、今後も予定と体調が許す限り、参加して勉強させていただきたいと思いました。
こんにちは、「最近の主戦場はどこ？」と聞かれたら「Twitter」と答えるでしょう、 おがた (@xtetsuji) です。
先日、3月21日になりますが、「第5回 Twitter API勉強会」に行ってきました。前回「第4回」から二度目の参加になります。
公式サイトは無いようですが、情報をTogetterにまとめてくださった方がいらっしゃいましたので、タイムテーブルやスライド資料などはコチラからご参照ください。
前回の私の感想ブログの締めくくりで「機会があればPerlのTwitterライブラリについて発表してみようかなと思いました。」と書いたのですが、今回のタイムテーブルの10分LTに自分のアカウント名が登録されているではありませんか。「いつか発表したい」→「次回発表する」の流れにちょっとビックリ。
[tweet https://twitter.com/xtetsuji/statuses/172637481408282625]そういえば前回「第4回」で、こんなやり取りがあったのでした。まさか本当に「第5回」で発表になるとは…。
「Twitter API勉強会」は月1回の活発な勉強会で、準備期間は1ヶ月もありません。まぁ、結局スライドは前日の深夜に徹夜気味に作ったのですが…。当日いらっしゃった方々、内容もさることながら、発表がグダってしまって本当に申し訳ありません。練習不足でした。スライドの内容の補足等については後述します。
前回の会場は御茶ノ水のデジタルハリウッドさんでしたが、今回は渋谷の「ハロー会議室」というところでした。
広々とした会議室でしたが、私はちょっと遅刻してしまったので、最初は後ろのほうに座って聴講していました。その後、トークの隙を狙って前の方に進出していきましたが…。
最初のトークは、急遽タイムテーブルが変更になって、Twitterの国際化等に携わっている@keita_fさんによる「Twitterの日本語検索、ハッシュタグについて」。
資料も公開されていない半分オフレコっぽいトークだったので、どこまで感想を述べていいかちょっと分からないのですが、浅い範囲で手元のメモに書かれている興味深かった項目としては
といったところでした。
@keita_fさんは、あのティコリンク(t.co短縮URL)の実装にも関わっている人らしく、どちらかというとそちらの方で色々と質問したかったのですが、時間が無かったのと懇親会にいらっしゃらなかったので、そちらについてはほとんど話を聞けませんでした。
声をかけて一つお話をしたのは「ティコリンクの識別子(スラッシュの後の文字数)は8文字ですが、Twitterには日々膨大なURLが投稿されているので、あれが9文字になる日は来るんですか？」というつまらない(?)質問をしてしまった(とっさに思いついたのがそれだった)のですが「じきにそうなる日も来るでしょう」という回答でした。実際、Twitter APIからはティコリンクを展開したURLの情報も乗ってくるので、そちらを見れば各種実装が8文字を想定する必要すらないので、他愛も無い質問だったなぁと思います。
最初のトークが終わった後は、恒例の交流タイム。今回は学生さんの参加が少なかったようですが、周囲の社会人の方とどんなお仕事をされているのかとか、どういった興味でここに来たのかといった話で盛り上がりました。ここで後ろの席から前の席へ移動。
次のトークは@setomitsさんによる「昼会」のご紹介。デジタルガレージの中の方です。
なぜTwitterかという話から。最初は(デジタルガレージが業務提携を結んでいた)LinkedInのOAuthを使ったログインを検討していたらしいです。ビジネスランチ的な何か？そこは普及度を考えてTwitter OAuthに変更したとのこと。
開発は、Google App Engine(GAE)上でTweepyというAPIを使って開発しているとのこと。Pythonですね。
ユーザへの通知に自分へのDMを使用しているとのことですが、ユーザから「自分から自分にDMが来るのは気持ち悪い」「スパムかと思った」「アカウントを乗っ取られたかと思った」といった意見があったとのこと。でも開発者に話をすれば実装上「まぁこうするだろうね」といった感じで折り合いが着いた(?)ような感じです。Zusaarでも登録ユーザへの連絡はユーザ自身へのDM(ひとりごとみたいな感じ)で実現していますし、同種の考えのサービスは多いようです。
既存のサイトのOAuthの利用について、いちいち新しくユーザー登録をしなくて良いのは良いとのこと。
トラブルもあって、ログイン出来ないということはサービス開始前やサービス開始直後に頻発していた模様。原因追及できず、一切のAPIコールができない状態が続いたようです。
昼会の開発から8ヶ月、色々な発見があったようです。昼会というサービス自体で新しい出会いがあったこともあるようですが、昼会の敷居が意外に高いこともあったとか。確かにサイトを見ても中々昼会の予定が入っていない。質疑応答で「夜会もやったほうが…」というジョーク質問がありましたが「ドメインhirukai.jp取ってしまいましたし…」とのことでした。
昼会の開発体制は最初3人。開発1人、デザイナ1人、企画交渉1人。最小編成ですね。
質問はGAEコストにも波及して、改定前は数千円/月だったのが改定後に数万円/月になってヤバいと思い、APIのコール周り等のコストを見なおして、改定前くらいの価格まで押さえ込めたとのこと。GAEのコスト改定はニュースにもなっていましたが、桁が違ってくるほどの値上げだったんだなと思いました。
この後はLT。
@inda_re さんの「Twitter 4 contact」。問い合わせフォームをTwitterで作ってしまおうという発想は面白かったです。資料もPHPで作られたプログラムも公開されているので、導入しようと思えばすぐにでも導入できそうです。発想の面白さと、LTならではのウケ狙いの上手さに感服です。
これは私 @xtetsuji によるトーク。5分や20分の経験はあったのですが、10分LTというのは初めてで、どれくらいの分量でトークしていいか分からないまま、練習不足というかほとんど練習をせずにのぞんでしまったために、非常にグダってしまい申し訳ありませんでした。
前回、学生さんが多かった事を念頭に置いて「半分くらいはPerl自体の環境導入をやったほうがいいのでは」と思って資料を作ったのですが、今回はほとんど学生さんがいない(居たとしても既にスキルある方ばかりな)状況だったので、ちょっと構成に失敗したかなぁ、といったところです。
結局のところ、PerlにもStreaming APIをいじれるAnyEvent::Twitter::Streamというモジュールがあって、手軽にプログラムが書けるんだよといったところが伝わればよかったかなと思います。
以下、資料です。
デモプログラムで登場した twitter-stream-search.pl は、自分自身がテレビ番組(アニメとか)の実況をコンソールで tail -f のように流し見しつつ、あとで録画したものを観るときにそのストリームの詳細がログの様になっていて欲しい、と思い立って30分くらいで書いたプログラムです。今も便利に普段使いしています。仕事のプログラムは書くのに何時間も掛かるのに、人は私利私欲があればものすごい速度でプログラムが書けるんだと思った瞬間でした。AnyEvent::Twitter::Streamの導入さえ成功してしまえば、後は比較的簡単に使い始められるのも特長としています。
ここからは発表から蛇足になりますが、AnyEvent::Twitter::Streamも万能ではないようで、まだできないこともあります。最近Streaming APIで開始されたgzip圧縮にも対応していないようです。あと、上流でHTTPストリームが切られた場合の再接続アルゴリズムも実装されていないようです(Squid経由で接続してSquidを再起動させれば簡単に再現できる)。前回の勉強会の時にJava Hackerに囲まれて話をしたときに「TwitterのStreaming APIを正確に実装しているのはTwitter4Jしかない」という話がありましたが、まさにそういうことなのかもしれません。Twitter4Jの作者であり、このTwitter API勉強会の主催者である@yusukeyさんに、懇親会でその辺のお話をうかがってみると、再接続アルゴリズムは実装も確認も大変とのこと。Perlに貢献するべく、AnyEvent::Twitter::Streamにパッチでも当ててみようかとも思ったのですが、作者がPerl界の大御所過ぎて、どうしていいかちょっと悩みますね。でしゃばり過ぎとか言われそう。
twitter-stream-search.pl は Date::Format と Date::Parse に依存していますが、Perl-5.10以上を最初から要求しているのだから、Perl-5.10からコアモジュール入りしたTime::Pieceを使えば不要な依存関係を減らせると後で思ったのでした。これは気が向いたら直します。Date::Format も Date::Parse も cpanm で簡単に導入できるので、それほど深刻な問題ではないと思いますけどね。
@ngsw_taro さんによるトーク。KotlinというJavaベース(?)のプログラム言語があるようですね。そのKotlinからTwitter4Jを使おうというトーク。結局デモは失敗してしまいましたが、後日Kotlinから投稿したツイートがあったので、それでデモが成功(?)ということになった感じでしょうか。
LT中に紹介された、お手軽開発環境 http://kotlin-demo.jetbrains.com/
Java界隈にはGroovyとかJRubyとか、その上に乗る言語がたくさんあって面白いですよね。Twitterの勉強会なのに、Javaを見直すきっかけが多い勉強会でもあります。
懇親会
渋谷の外を移動して、今回も貸しスペースでのオシャレな場所で懇親会がありました。
(写真撮ってくるの忘れた…)
今回初めて出席された方と色々な話で盛り上がったり、前回トークをした方へ質問をしてみたり、有意義な時間が過ごせました。勉強会中だとなかなか質問したり交流したりといったことが苦手な日本人でも、酒が入るとその辺結構いけるものなんですね。酒が入った後にコードを書いたりできるかどうかは別として、初顔合わせや顔見知りの人と雑談する上で、お酒と貸切の静かな(勉強会関係者以外がいない)場所はうってつけの場所でした。
今回は発表者側に立ったこともあって、声をかけて下さる方もいて、発表者効果さまさまだなと思った次第です。用意は大変ですが、発表者として壇上に立つと、私のような知らない人に声をかけるのが苦手な人も話しに花が咲いて、非常に良い経験でした。
月1回の勉強会に、資料の用意がなかなか大変なこともあって、しばらくは発表者側にはまわらないとは思いますが、次回発表する際には低層の話ではなく、PerlとそのTwitterモジュールを使って書いた何らかのウェブサービスを紹介できればと思いました。体調が許せば、次回も聴講者として懇親会も含めて参加したいです。
こんにちは、日々Twitterで情報収集やテレビ実況を楽しんでいる おがた (@xtetsuji) です。
(とりあえずアップします。今のところ、もう少し加筆予定です at 2012/02/27)
先日、2月23日になりますが「第4回 Twitter API勉強会」に行ってきました。
公式サイトは無いようです。上記ZussarのURLのタイムテーブルより。
こんな感じでした。
今回足を運んだきっかけは、2012年1月28日に行われた「第3回Twitter研究会」のUstreamをたまたま観ていて面白かったことです。「Twitter研究会」は年1回の行事とのことで、特にそのUstreamで興味をひいたTwitter4JとTwitter APIについての @yusukey さんのトークで知った「Twitter API勉強会」は頻繁に行われている、というのがきっかけでした。しかも @yusukey さん主催。
今回初参加となりましたが、迷うことなくZussarで懇親会を含めて参加申し込みをして、「Twitter APIポケットリファレンス」を事前に購入して会場に向かいました。
詳細なメモは取っていないので、ざっくりとした感想をつらつらと書いていこうと思います。
まず @yusukey さんのお話。前述の「第3回Twitter研究会」でのお話とそれほど大差ないお話でしたが、生で聴くのはまた違いますね。とても面白かった。ちなみに @yusukey さんはTwitter社の中の人であり、JavaライブラリのTwitter4Jの作者でもあります。
座るときに机の左側に座るように指定されたのですが、これが「グループに分かれて簡単に自己紹介」の時に、左側が社会人で右側が学生だという仕掛けだとわかります。学生と社会人の交流を促進する、面白い仕掛けだなぁって思いました。もっとも、私の隣にいた学生さんは、起業をしている学生さんで、半分社会人みたいな方でした。後ろ席の方ともコミュニケーションを取ったりしましたが、皆さんいい人達ばかりで話題に花が咲きました。
前回と会場が変わって、今回はデジタルハリウッドさんが会場を提供してくれたということでしたが、意外に駅から近くて、Wi-Fiも貸してくれて、とても広くて快適な会場でした。一瞬入学したくなったくらい。
交流タイムも終了して、次はSEGAの中の人 @twtrfk さんによる「Virtua Fighter5 Final ShowdownのTwitter連動機能について」。ゲームセンターの機器と直接Twitter連携しないで別途サーバを用意する等といったお話。サーバ側はLinux/C/C++/Javaだそうで、Linuxの上にWebSphereとDB2を載せているとのこと。SEGAのシステムはIBMと懇意なのかなぁと思ったり。大企業のシステムにしては、テーブル構造や処理ロジックの詳細等、突っ込んだ話が多くて、大いに興味をそそられました。「部内SNSであるAmitterというのを作ってデモをした」「Twitterのテストアカウントをテストだと分からないように地道に100個作った」(Twitterの規約では連番アカウントはグレーなんですね)といった面白い話も聴けました。部内SNSを作ってしまってデモとは見習いたい開発パワーですね。最後の方はマーケティングとして、初音ミクさんのお話等が盛りだくさん。ちょくちょく格闘ゲーム全般は触っているのですが、久々にバーチャファイターをやり込んでみたくなりました。マーケティングに乗せられてしまいました。
LTで特に印象に残ったのは@makingさんによる「Twitter Bootstrap入門」でした。@makingさん曰く「CSSフレームワーク」。以前から名前は聞いていましたが、ここまで簡単なものとは。あまりに簡単にTwitterライクなおしゃれなデザインが作れるので、他との差別化が難しいといった新たな難題が出てくるくらいだそうです。社内ツールに色付けをする使い方とかに良いなぁと思いました。
その後、懇親会のため移動。指定された場所に行ったら雑居ビルのようなところで一瞬不安になりましたが、会場である部屋の中は非常におしゃれで、これまた居心地が良い空間でした。
懇親会でもそうだったのですが、全体的にJava Hackerの人口の多いこと多いこと。発表もJavaずくし。懇親会で話しかけた人が開発者だったらほぼ確実にJava Hackerという状況。まぁ、@yusukeyさん自体がJavaのTwitter4Jライブラリの作者で、その人徳で人が集まっているということも大きいのかもしれません。Perlしか書けない私に、なんとなくJavaも書いてみようかなと思わせるくらいの空気感。良い人だらけで、居づらいということは全く無く、どことなく自分から見た異文化を垣間見たようで楽しい空間でした。
しかし、Java Hackerの中でPerlのお話をすると「CGI(ry」「Perl6(ry」といった話を振られて、ちょっと困る場面もあったり…。PerlというかLLの外側の業界の人から見たPerlって、今も初心者がCGIを書くための言語という感じなんでしょうね、やっぱり。LL全般に言えることですが、Perlも日々相当進化しています。私が追いきれないくらいに。ここは「日本Perl改造計画」に期待したいです。
「PerlにはTwitterのStreaming APIを仕様通りに実装しているモジュールは無い」といった話をどなたからかうかがったのですが、AnyEvent::Twitter::Streamにも何か欠陥があるのでしょうか…。普段使いしていて大きな問題は無いのですが…(Proxy等にHTTPストリームを切られたときに再接続しない問題があるんだなということは最近把握しました)。
著者サイン！懇親会で機会をうかがって @yusukey さんからサインを頂きました。嬉しかったです。
Java以外の他の言語の発表も募集しているというお話だったので、機会があればPerlのTwitterライブラリについて発表してみようかなと思いました。発表をするかしないかは別として、次回も時間が許せばぜひ出席してみるつもりです。