2013年7月24日水曜日

インターネットと世間のズレを垣間みる

Twitter分析でのノイズ対応の検討の打ち合わせで、
「橋下市長がプリキュアとツイッターでつぶやいた」
という事例を紹介したところ
「橋本聖子が鰤をついた？」
という反応が帰ってきました。
取り敢えず、その場では簡単に説明したのですが、未だに冗談だったのか本気だったのか分かりません。
時刻:
ラベル: ,

2013年7月13日土曜日

次のTwitter分析ターゲット（予定）は…8月2日、バルスの日

　本来は、参議院選挙に向けていろいろと考えていたのですが（各党and/or候補者のTweet数と当選の相関関係の抽出など）、大人の事情で本件をレポートすることはできなくなりました。

　その代わりに、
『天空の城ラピュタ』
2013.8.2(Fri) 21:00-23:34 O.A. （金曜ロードSHOW!｜日本テレビ）
をTwitter分析ターゲットとします。（これなら大人の事情が絡んでくることは、まずないはず！）

　基本的には「バルス」Tweetによるバースト観測ですが、その他に何ができるかをいろいろと模索中です。
　検討しているのは、
  • 前回放映時との比較（過去データを捜索中…確かあったはず…）
  • 人名Tweet数の比較
  • 注目セリフTweetの比較（表現揺らぎ「目が目が」「目が、目がぁ～」などの扱いが難しい）
といったところですが、現時点では未確定です。もしかすると「バルス」観測だけになるかもしれません。

　表現揺らぎの問題は（注目セリフだけではなく）常につきまといます。そもそも音声表現されているものを文字表現に変換しているから仕方がないのですが…

　パロディ表現の扱いも困りものです。前回放映時は「バルス五段活用」らしきものが観測されました。また、某声優がらみで「海賊にならない／海賊王になる」の突っ込みとか、某公共放送さんアカウントが「ニルス！」とつぶやいていたりとか…

　今回は何が起こるのか、楽しみでもあり、分析しきれるのか不安でもあります。

--
　ところで、ガミラス語で「点火」らしき表現が「バルス」に聞こえるのは気のせいでしょうか？

--
※リンク先修正しました


時刻:
ラベル: ,

2013年7月4日木曜日

Ruby2.0でTwitterStreamingAPI (1.1) を使う

2014/11/21 追記
「Ruby2.0でTwitterStreamingAPI (1.1) を使う（改）」にtweetstreamを使う方法を書きました。
下記でも動作しますが、より効率の良いこちらもご覧ください。


これまで、PerlでStreamingデータを収集していたのですが、API1.1になったのを機会にRubyに移行しました。以下、動作までの覚え書きです。

投稿や検索は、gem で Twitterライブラリをインストールすれば、簡単に使えます。

ところが、このライブラリでは StreamingAPIには対応していないようです。
To access the Twitter Streaming API, we recommend TweetStream.
とのことだったので、TweetStreamを見てみました

ところがこちらにも
Note: TweetStream does not currently work with Ruby 2.0, this is a known issue.
という記載があります。
そこで、さらに内部で使用しているらしいEM-Twitterを使ってみました

ところが、これは実行時にライブラリが足りないらしく、なにやらDevelopperKitうんぬんとメッセージが表示されます。gemだけで使いたいので、これも不採用としました。


　上記の調査から既存ライブラリの使用は断念し、TwitterStreamingAPI を直接http接続から使用する方法をとることにしました。
　探してみると、以下のようなものがありました。３つのプログラムコードはほとんど同じです。



上記のページを参考にしながら、次のような変更を施しました。
１．CONSUMER_KEY、ACCESS_TOKENなど
　自分で用意したものに変更しました。

２．request["User-Agent"]
　自分の都合に合わせて変更しました

３．接続先
　「GET statuses/sample」
を使いたかったので、接続先を
　　https://stream.twitter.com/1.1/statuses/sample.json
に変更しました

４．サーバ証明書
　これは、本来は必要なんでしょうが、実験で使用するプログラムであることから、証明書なしで動作させるために
　　https.verify_mode = OpenSSL::SSL::VERIFY_NONE
としました
（将来的な動作を保証するものではありません）

※必要なライブラリは、適宜gemからインストールしました

以上で、基本動作の確認が出来ました。あとは、それぞれの都合に合わせて修正して使います。

※2013/07/04時点の調査です。

時刻:
ラベル: , ,

2013年7月3日水曜日

日付の明記されてないブログ記事や文書に振り回され

　ある情報を検索していたときのこと、問題解決法が書かれたブログ記事を見つけて喜んでいたら、実はそれは古い情報で使い物にならなかったという事がありました。日付が書いてなかったので最新の情報だと思い込んで読んでしまったのです。もし日付があったら、古い情報だという前提でその内容を確認するのでショックは少なかったはずです。

　同じことが、社内文書なんかでも良くあるから困ってしまいます。
　調査レポートや仕様検討の資料が、時系列無視してあちこちのサーバに格納されているという現状に直面し、ため息をついています。

　IT系サービスに関する情報は特に鮮度が重要な場合が多いように感じます。少し前の情報があっという間に役に立たなくなるということがこれまでにも何度もありました。
　そしてまた今回も同じ轍を踏んでしまいました。

　本来エネルギーを割かなければならないところに力を注げないのは困りものです。

時刻:
ラベル: ,

2013年7月2日火曜日

選ばれたのは…SuffixArrayでした…

最終製品版ではなく、短期に確実に動作するプロトタイプを作成する必要性から、今回は（とりあえず） SuffixArray を採用しました。
それでも、さすがにSAISを実装しました。MultikeyQuicksortでは、ある特定の条件下で致命的な遅さが観測されたので却下です。

実際問題としては、様々なしがらみとの調整の上で、ベストな選択を行うことになると思います。
たとえば、実際に実用的な速度で動いているものを改良するための工数を確保できるのか、というような問題があります。
研究室とは異なって、開発の現場では必ずしもベストな性能のものが選択されるわけではありません。良い悪いという話ではなく、プロジェクト全体がベスト（ベター）になるような選択がなされます。納期までに所定の製品ができなければ、それは何もないのと同じだからです。

良い技術であることと、それが製品／プロジェクトにとってベストの選択であるかどうかは、必ずしも一致しないということです。

（とはいえ、技術者としてはベストの技術を使えないのは悔しいので、いつかどこかで何とかならないか画策するつもりではいるのですが。）

時刻:
ラベル:
登録: 投稿 (Atom)