今そこにあるSlack


この記事は 『Slack Advent Calendar 2016』2日目の記事です。

昨日はru_shalmさんの「Slackで業務チャンネルの平穏を維持するbot、そして人間のトークンをbotに与える話」でした。

今そこにあるSlack

Slackで何が起こっているか、知ってますか?

Slackはいつでもそこにいるわけですが、実際に自分が観測しているSlackの世界は意外と限定的です。自分がjoinしているチャネルで何の発言がされて、自分がどんなリアクションを付けられ、またあるいはアットマークを付けて呼び出される、くらいの情報しか通常は知る方法がありません。

しかし、Slackにはあなたの知らないたくさんのチャネルがあり、そのたくさんのチャネルでは沢山の人達が会話を楽しみリアクションを付けたり、また新しいチャネルを作ったりチャネルをアーカイブしたりしています。もしかしたら、新しい絵文字を追加しているかもしれないし、登録した絵文字を消しているかもしれません。自分が所属している組織では、2016年12月2日2時14分現在、2478個のチャネルがあり、4496個の絵文字が登録されています。それに対して、自分が参加しているチャネルは100程度と、知っているSlackの世界はごく限られた一部だけです。

数人しか参加していない、規模の小さな Slack team であれば、もしかしたらあなたはSlackの世界で起こっているすべてのことを知っているかもしれません。すべてのチャネルに参加し、すべての発言やリアクションを見ることができます。ですが、誰かが発言し、すぐに削除した発言は見ることが出来るでしょうか? 誰かがこっそり作った(プライベートではない)チャネルの存在を、知ることは出来るでしょうか?

Slackには、クライアントを作成するために用意されている、Slackの世界を知るための方法が用意されています。というよりも、種々の便利なbotを作ろうと思うと、このAPIを避けて通れません。それが、Real Time Messaging APIです。

Real Time Messaging APIから飛んでくる通知を、逐一どこかのチャネルに(どこのチームにもbotの練習をするためのチャネルが必ずいくつかあると思いますが、その中で最も活発なチャネルがオススメです)逐一流すことで、今そこにあるSlackで何が起こっているのかを知ることが出来ます。

わりと簡単に作れると思いますが、一応私が作ったテキトーな実装をご紹介しておきます。

一年以上前からゆるく運用し続けているコードで、使ってるGemが古かったり微妙な実装が多いので、リポジトリにしないでGistにしました。時間があったらちゃんとGemにしますが、今回はちょっとこのコードでお茶を濁させてください。大した規模のコードでもないので、このコードは参考程度にして、ご自分で実装することをオススメします。

slack_watcher.rb

ある日のリアルタイム通知botの様子

screenshot-from-2016-12-02-020908

Caution

このbotをSlackに放つ前に、よく考える必要があります。というのも、このbotは基本的に嫌われます。そしてそのbotをSlackに放ったあなたも嫌われることでしょう。

このbotは、Slackで起こっているありとあらゆることを可視化します。その結果、様々な人から「本当は知られたくなかった」ことを暴かれたとして、厄介者を蔑む目で見られることでしょう。

例えば、仲間内でこっそりと楽しむために作ったチャネルに、どこからやってきたのかわからない人が突然たくさんjoinしてきます。当然このbotの通知を見て興味を持った人が参加したのですが、チャネルを作った本人は、Real Time Messaging API の存在など知らず、一体どうやって新しく作ったばかりのチャネルを補足されたのか、気味悪がることでしょう。個人的にはprivateチャネルでやればいいと思うのですが、どうもIRCのように、クローズではないけど名前を知らないと入れないチャネルを求めている人は想像以上に多いのです。

「どうしてSlackで起こったことをいちいち監視して、あまつさえそれをチャネルに流すのか」と罵られることもあります。とはいえ、このbotで知り得ることは当然公開情報であり、privateチャネルなどで起こっていることは捕捉できません。公開されている情報を可視化したからといって何故責められるいわれがあるのでしょう。とはいえ、そのような正論ぶったことを面と向かって相手に言うと、当然ながらさらなる怒りをかうだけなので、私はよく「公開されている情報をここであえて公開することによって、こっそりと監視するというストーカーみたいなモチベーションを削ぐ効果がある」と、言い訳になっていない言い訳をします。

心の底から本音を言うと、このbotの本当の目的は、圧倒的な権力を持ったアドミニストレーターという特権階級に対して、その力を不用意に乱用することが無いかどうかを監視する、いわば民主主義のような観点のつもりで作ったのですが、実際のところ私が所属している組織のSlackを管理しているアドミニストレーターたちは特に権力を乱用している様子もなく、運用も平和そのものなので、ただ単に私が憎まれるだけの結果になっています。

Real Time Messaging API

Slackで今起こっているたくさんのイベントを、勝手に教え続けてくれるWebSocketのAPIです。Slackのクライアントを作成するには、新しく作られたチャネルや、新しく追加された絵文字、新しくチームに参加したユーザーを常に知っている必要があります。さすがに、すべてのチャネルにポストされた投稿を逐一教えてくれることはありませんが、大抵の情報を教えてくれます。

非常にたくさんのイベントを通知してくれますが、私が特に重宝しているイベントを、アルファベット順に共有します。

bot_added event

https://api.slack.com/events/bot_added

新たにbotが追加された時に通知が来ます。新しいIntegrationが追加された時や、新しいOAuthトークンが発行されたことなども教えてくれます。

誰かが何やらよくわからないOAuthなどを発行した時に真っ先に教えてくれるので、組織内で謎の闇サービスが誕生したことを最初に知ることができます。

channel_archive event / channel_created event / channel_rename event / channel_unarchive event

https://api.slack.com/events/channel_archive

https://api.slack.com/events/channel_created

https://api.slack.com/events/channel_unarchive

https://api.slack.com/events/channel_rename

チャネルに何か変化があった時に通知されます。RTMは、基本的に自分がjoinしていないチャネルに関しても、すべてを教えてくれます。

1日目のru_shalmさんが作っていた蟻地獄botも、このイベントを参照しているはずです。

emoji_changed event

https://api.slack.com/events/emoji_changed

絵文字に何か変化があったときに通知されます。先述のchannel系のイベントと違い、サブタイプがやたらと多く定義されていて、サブタイプによって挙動を変えなくてはいけません。SlackのAPIによくある構造の統一性がちぐはぐなやつで、心がほっこりする気持ちになれます。

reaction_added event / reaction_removed event

https://api.slack.com/events/reaction_added

https://api.slack.com/events/reaction_removed

リアクションが付いたり消えたりした時に来るイベントです。これもチャネルの参加を問わずすべて通知してくれるので、便利です。リアクションが付くということは、何かしら情報量の多いPOSTである可能性が高いので、これを通知するとウケますし、同時に顰蹙をかいます。

ちなみに、starに関するRTMもあるのですが、なんかしらないけどいつの間にか「あ、それあんまり使ってる人居ないから廃止したわ」とか、同僚のSlackBreakers(注:どういうわけか、私の所属している組織では、Slackが好きでたまらない人たちのことを、SlackBreakersと呼ぶ風習があります)はSlack社に言われてたので、現在は使えるかどうかよくわかりません。

team_join event

https://api.slack.com/events/team_join

新たにチームに参加したメンバーが居るときに通知されます。こういのを監視してると、ストーカーと言われます。

ちなみに

RTMは本来Slackクライアントを想定して作られていると思われるので、あまりにたくさんの情報をブロードキャストする上に、その組織に所属する人しか参照することが出来ず、Slack Appを作るには不向きでした。そこで、Events API という、OAuthのスコープで参照を許可させることが出来るAPIも存在します。しかし、自らの所属する組織のイベントを参照するにはやや手順が大げさで面倒なので、Slack Appを真面目に作る以外の用途で利用することは今のところなさそうです。

実装の勘所

勘所というほど大層なものでもないですが、運用していていくつか困る点があったので共有します

Slackは勝手にチャネル名を書き換える

チャネル名が変わった時、フツーに #hogehoge のようにPostすると、変更後にSlackが余計な気を利かせて、過去にさかのぼってすべてのチャネルの表示名を書き換えます。これはチャネルに限ったことではなく、Slackの特殊なMarkdownを使っている場合はたいてい起こるケースです。そのため、チャネル名の変更などを検知するときは、キャッシュに残っていたデータと新たに取得したデータを付きあわせて、Markdownを使わずに記述することで、Slackの余計なお世話を回避することが出来ます。

SlackのWebSocketは突然キレる

どんなサービスでもそうだと思いますが、WebSocketは突然一方的に遮断されるものです。リトライ機構を設けましょう。

APIの結果はできるだけ頑張ってキャッシュする

SlackのAPIは、大きな組織で使っていると正直レスポンスがでかすぎて、色々辛くなる上に重いです。しかし、このbotは基本的に今までSlack上に無かったものが増えたことを教えてくれるので、キャッシュに頼ると死にます。なので、キャッシュコントロールはがんばりましょう。

無限ループに気をつける

これもbotあるあるだと思いますが、自分の発したメッセージに反応して、核分裂でも起こしたかのような急激な無限ループが発生することがあります。今回のGistには入れていませんが、特定のキーワードに反応するときは気をつけましょう。

余談

RTMを使えば、特定の誰かがオンラインになったとかオフラインになったとかもわかります。つまり、誰もが気になるあの人がSlackでオンラインになったりすると、それを教えてくれるbotとかも作れたりします。需要があるかどうかは知りませんが、組織の誰もが知りたい人物のオンライン情報とかがあれば使ってください。

まとめ

まあだいたい、これくらいのイベントを見ていれば、立派にストーカー扱いされますな情報通です。

先に強調したとおり、RTMが教えてくれることは、botのトークンを使う限りはprivate groupなどの秘匿情報を一切含んでおらず、あくまでSlackのチーム全員に公開されている情報なので、非常に有益です。

みなさんもぜひ、今そこにあるSlackをリアルタイムで可視化し、世界を知りましょう。


カテゴリー: Ruby, Slack | コメント / トラックバック: 0個

RubyKaigi 2016 に行ってきました


RubyKaigi 2016

2016 09/08 〜 09/10 の三日間で、RubyKaigiが開催されたので、Ruby大好きなひとりとして参加してきました。

自分がRubyを触り始めたのはここ一年半くらいの話で、前回のRubyKaigiが開催された頃はまだRubyに本格的に染まる前だったので、自分がRubyistとして目覚めて初めてのRubyKaigiでした。

同じく大きなカンファレンスであるYAPCのお祭り感とは違って、ストイックにRubyの話題を中心にしたセッションが大半を占め、更にはCRubyやJRubyの実装にも深く立ち入った話が多く、単純にRubyを書く人だけではなくRubyを作っている人たちの目線を感じることも出来て、普段Rubyのコードを書いている自分から見て新鮮な刺激を感じました。(たまに全然Ruby関係ないよくわからないセッションもあって、それはそれで面白かったです)

今回のRubyKaigiのセッションの中で、ひときわ特徴的だったのは、コンカレンシーに関するセッションの数の多さと、CRubyに関するセッションの数の多さです。全40セッション中、6セッションがメインでコンカレンシーを、5セッションがCRuby(とそのエッセンス)を扱っていました。これは、ここ数年の関数型言語の考え方の流行だったり、マルチコアを活かしきるプログラミングをRuby3に期待している人が多いのだろうといった理由が感じられます。CRubyの話題の多さに関しては、Ruby3に向けてもっとコミッターに興味を持って欲しいという現コミッターたちの意識の表れではないかと思います。

半分は英語のセッションで、同時通訳も無かったので、必死に英語をリスニングして結構頭に効きました。面白いことに、日本語のセッションは英語の同時通訳があり、実に国際的なセッションなのだなということを感じました。

聴いたセッション

一日目

http://rubykaigi.org/2016/schedule/#sep08

  • Ruby3 Typing (Keynote)
  • dRuby in the last century
  • Who reordered my cord?!
  • A proposal of new concurrency model for Ruby 3
  • Isomorphic web programming in Ruby
  • Unifying Fixnum and Bignum into Integer
  • Scalable job queue system build with Docker

二日目

http://rubykaigi.org/2016/schedule/#sep09

  • Fearlessly Refactor Legacy Ruby (Keynote)
  • Writing a Gameboy Emulator in Ruby
  • How DSL work on Ruby
  • Learn Programming Essence from Ruby patches
  • Web Server Concurrency Architecture
  • Pwrake: Distributed Workflow Engine based on Rake
  • Modern Black Mages Fighting in the Real World
  • SciRuby Machine Learning Current Status and Future

三日目

http://rubykaigi.org/2016/schedule/#sep10

  • Ruby committer vs the World
  • Ruby3x3: How are we going to measure 3x?
  • High Tech Seat in mruby
  • It’s More Fun to Compute
  • Optimizing Ruby
  • Game Development + Ruby = Happiness
  • Dive into CRuby (Keynote)

特に凄かったやつ

3日かけて22ものセッションを聴きました。どのセッションも基本的に素晴らしいものでしたが、その中でも特にこれはヤバイなと思ったものを、いくつか感想として残しておきます。

Ruby3 Typing (Keynote)

Matzの基調講演で、Ruby3において型をどのようにして扱うかを、今現在のMatzの頭のなかにあるアイディアレベルで話してました。

Rubyには型がないから、最近新しく力を伸ばし始めた静的型付けの言語に比べて遅れているとよく言われる。しかし、技術というのはトレンドの間を振り子のように行ったり来たりするもので、いまは静的型付けの方に振り子が傾いているが、今後はどうなるかわからないので、Rubyは安易にその波に乗ることはできないと言っていました。これは、Matzのここ最近の講演で常に共通している意見で、YAPCの時N高特別授業の時も同じことを言っていました。

特に印象的だったのは、「絶対に型は書きたくない!」と「絶対にインターフェイスは書きたくない!」という2つの力強い宣言でした。

Rubyのダイナミックな言語仕様が尊重しているのはダックタイピングの概念で、静的型付けやインターフェイスではダックタイピングを壊してしまうため、安易に採用することはできないと、繰り返していました。継承の概念を大事にすると、たとえばIOやStringBufferの関係の様に、同じ挙動をするのに継承関係が無いオブジェクト同士のダックタイピングを阻害するということです。しかしその一方で、Goのように振る舞いを定義するインターフェイスに対してはかなり好意的な立場で、Goのインターフェイスは良くできていると強調していました。また、型推論というアイディアは素晴らしいが、それでも柔軟性を犠牲にするところが多く、何か新しい型の解決方法を考えつかないと、Ruby3に型の概念を入れることは難しく、現状はそのアイディアの実装がないので、Matz自身がプロトタイプを作ってコミュニティに問うていくしかないとのことでした。

dRuby in the last century

いきなりoso-matzとjushi-matzが出てきて、受けとか攻めとか言っててヤバイなこれって感じでした。

そしてdRubyの存在を初めて知りましたが、これは結構実用的で面白いのでは? と感じたので、家に帰っていろいろ触ってみようと思います。

A proposal of new concurrency model for Ruby 3

Guild、というRuby2との互換性を保ちつつ、Ruby3でコンカレンシーを実現するライブラリの提案でした。

アイディアはかなり面白く、Guildという1つのグループの中では今までどおりGVLが働くが、Guildグループは複数持つことができ、他のGuildとの間ではオブジェクトのやり取りに制限がつくという、ForkとThreadの中間(あるいは混ぜあわせ)のあるようなアイディアです。

1つのプロセスは必ず1つのGuildグループをもち、この最低1つは存在しているGuildが、今までのRuby2との互換のために使用される、すなわちRuby2は1つしかGuildグループが作れないGuildと同等ということです。

これがRuby3に採用されるとかなり面白いな、と思いました。

Isomorphic web programming in Ruby

Rubyでバックとフロントの両方のコードを書いてしまおうというアイソモーフィックライブラリ Menilite の紹介&ライブコーディング。

そもそもRubyでIsomorphicしようというスタイルが既にヤバくて面白いだけではなく、非常に完成度の高いライブコーディングのテクニックが披露され、発表そのものがショーのようで素晴らしかったです。

ライブコーディングはだいたいミスって、ミスるところまで含めてライブコーディングの楽しさというところがあるのですが、ゆうちゃんさんは

  • あらかじめ完成したコードをgitで管理しておいて、ライブコーディングの進みに合わせてコミットしておき、いざというときにリカバーする
    • Diffを見せながら解説を加えるので、実際にどういう変更が入ったのかがコミット単位でわかりやすい
  • TODOアプリを作りながら、実際にライブコーディングする内容をTODOする

といった、技術面でも演出面でも舌を巻く完成度で、絶対に真似しようと思いました。

Modern Black Mages Fighting in the Real World

Fluentd 0.14 を支える、黒魔術の話です。

トークが軽妙で面白いのに、扱っている内容が深刻すぎて引きつった笑いが出てしまう。みんな大好き黒魔術! という感じです。

同じ日の2つ前のセッションにHow DSL work on Ruby というセッションがありましたが、それと合わせてRubyの黒魔術の深い部分がよく伝わってくる、この2つのセッションを聞くだけで黒魔術師になれる最高のセッションでした。

Ruby3x3: How are we going to measure 3x?

Ruby3 を3倍の速さにする話ではなく、どうやって3倍の速さを計測するかという話でした。

ベンチマークに関する、体系だった知識を一度に頭に入れるには最適なセッションで、ベンチマーキングを正しく行うということの難しさとその原因をわかりやすく解説していました。

惜しむらくは、セッションが英語というだけで難しかったのですが、スライドが進むのが早く、頭の理解が追いつかないという点でした。このセッションのスライドは、ベンチマーキングを理解する上で非常に役にたつものになると思うので、どこかで公開されることを祈ってます。

It’s More Fun to Compute

Rubyで作曲。ヤバすぎ。国際会館のメインホールがダンスフロアと化した。最高。

Dive into CRuby

CRubyの世界への入り口、というにはちょっと専門的すぎて、さすがコミッターという格の違いを見せつけられたセッション。

主に2つの話題で、Rubyコミッタになるためにはと、CRubyにどうやって貢献するかという話。

新しい機能を提案するときには、ユースケースを正しく理解したうえで提案するべきであること、というのが非常に腹にストンと落ちてくる話で、普段の仕事にも活かせそうだと思いました。

心機能の提案時に、その機能をどのように使うか、そしてその機能の名前は本当に適切なのか、新機能という事象を研ぎ澄ますように精査して、本当に必要な使い方を見出していくという考え方はとても重要だと理解できました。

また、CRubyの世界を旅するときに、大事なことは現象を観測することだということも強調していました。様々なツールを使い、CRubyのメモリやコールスタックがどうなっているのか、解析ツールを使ってどこがボトルネックになっているのか、などを観測することで、Rubyの最適化やバグレポートに繋がると教えてくれました。

Drinkup by Misoca

二日目には、MisocaさんのDrinkupに参加させて頂きました。

途中、Misocaエンジニアに質問タイムがあったので、Rails4から5へのアップデートで苦労したところや、デプロイの戦略に関して質問してみたところ、丁寧に答えていただいてとても楽しかったです。

お料理とお酒、ごちそうさまでした。

RubyKaigi 2016 楽しかった

三日間の日程や、朝が早めであることから、体力的には結構辛かったですが、とても楽しめました。RubyKaigi最高です。

そういえばちなみに、Closingの時に「会社がRubyKaigiの費用出してくれた人ー?」っていう質問があって、ちらほら手が上がっているのを見て、「いま手を上げた人は、 #rubykaigi のハッシュと一緒に会社名をつぶやくと、リクルーティングの役に立つよ」と言っていたのがとてもおもしろかったので、来年は弊社の偉い人に「RubyKaigiのチケットと交通費ください! なんでもしますから!」ってお願いして、弊社の宣伝をドヤ顔でやってやりたいと思いました。

RubyKaigiのスタッフの方々、登壇者の方々、最高の三日間をありがとうございました。


カテゴリー: Ruby, プログラミング, ポエム | コメント / トラックバック: 0個

YAP(achimon)C::Asia Hachioji 2016 mid で、 Slack as a Game platform というLTしてきました


タイトルのとおりです

YAPC::Asiaが去年最終回を迎えて、いつかYAPCで登壇したいなと思っていた夢が終わってから1年。やっぱちーが開催されると聞いて、忙しい時期だけど絶対にLTくらいは出来ると思って応募して、無事採択されたので喋ってきました。

本家YAPC::Asiaに比べるととてもこぢんまりしていましたが、それでも集まった人たちは楽しそうにセッションをしたりそれを聞いていたりして、YAPCってこんな感じだよな、って雰囲気を感じられて楽しかったです。

自社のセミナールーム以外でやるカンファレンスで喋るのは初めてだったので緊張したけれど、ニコナレの録音を聞く限りではまあそこそこうまく喋れていたようなので安心した。

あとで自分のトークを見返せる(聞き返せる?)ニコナレ、素晴らしいサービスですね。

SlackGameのgemの0.2.0をリリースしました

YAPCの他のトラックを聞いている間に、0.2.0をパブリッシュしました。

半年くらい前に、お酒を飲みながらノリで書いたコードは酷いなぁと思いながら、とりあえず変なメソッド名や変数名を修正して、あとはReactionに対応して、リリースしました。

とりあえず、まだ問題点はあるので、近いうちに0.3.0にアップデートになると思います。


カテゴリー: ポエム | コメント / トラックバック: 0個

blink(1)を買ったので、雑にGemを作ってSlack監視botを作った


blink(1)

http://blink1.thingm.com/

プログラマブルなLED。同僚が社内の有志を募って共同購入して遊んでいたのを見て面白そうだったので、余ったものを売ってもらった。

たくさんの言語用のライブラリが用意されていて、大抵の人は好きな言語を使って開発できると思う。

用途

面白いなぁとおもって購入し、とりあえず一通りチカチカさせて遊んだけれど、特にこれといって用途が思いつかない。

同僚の人たちは、HTTPサーバーを立てて、リクエストに応じてLEDを光らせるAPIを社内公開するというよくわからない遊びに興じていた(しかも攻撃されてすごいことになっていた)が、とりあえず自分はSlackに新しいメッセージが投稿されたらチカチカ光るようにした。ついでに自分の名前がSlack上で呼ばれたら激しく光るようにして、誰かがリアクションをするとまた激しく光るようにした。

とはいえ、どちらかと言うとSlackだけではなく、HTTPサーバーを立ててリクエストで光るようにして、色んなサービスのリアルタイムAPIを繋げてピカピカ光らせるのが正しい使い方な気がする。

WindowsだとIFTTTと連携したりしていろいろ光らせられるらしいけど、Macにはそのソフトは用意されていない。

ならば自分で作るしか無いと思い、とりあえず予行練習ということで、blink(1)用のDSLを書いてみた。

Blinkman

blink(1)となんかしらのadapterを繋げて、DSLで光らせるgemを書いた。

https://github.com/kinoppyd/blinkman

とりあえず、今のところ存在しているadapterは、デフォルトのshellとSlack用のみ。暇があったらほかのも書こうかと思う。

https://github.com/kinoppyd/blinkman-slack

使い方は、Gemfileにblink-slackへの依存を書いて、簡単なDSLを書いて起動するだけ。

DSLの構成としては、blink blue の様に blink hoge で発光する色を指定し(現状で有効な色はred, green, blueのみ)、その後に 2.times で2回チカチカ、durin(250) で250 millisec で実行する、と指定する。

when_if のブロックは、どのメッセージを受信した時に発光するかを指定するブロックで、今回はSlackのRTMが返すJSONをパースしたオブジェクトがそのまま渡ってくる。そのうち、typeが’message’の場合、つまりSlackの自分が所属してるチャネルに何かしら新しいメッセージが投稿された場合に true を返して、発光するようにした。

今後

とりあえず、blinkmanは練習のつもりで書いたので、適当にメンテしていく。

ひとまずは、messageの中身がSlackのJSONそのままなので、IDとかの解釈がめんどくさい。それらをラップしたMessage Object を定義して、扱いやすくしていきたい。

blink(1)自体は、Raspberry Pi に繋いで、色んなサービスの通知に応じてチカチカさせるマシーンを作ろうと思っている。


カテゴリー: Ruby, プログラミング | コメント / トラックバック: 0個

S3クローンMinioを使って、自前MicroServices用データストレージを構築する


Minio

Minioという、S3のクローンサービスがある。Goで書かれたAWSのS3のオープンソースクローンで、API互換のあるすごいプロダクトだ。Minioの起動時のヘルプに書かれている説明が非常にわかりやすいので、そのまま引用する。

Minio – Cloud Storage Server for Micro Services.

S3は使いたいが、個人プロダクトだからそんな派手な利用をするわけではないし、そんなちまちましたことでS3の料金をシミュレーションしてわざわざ胃を傷めたくないので、何かしらいい感じのクローンが無いかと思って探していたところ、普通に[s3 互換][検索]でぐぐったら上の方にこのエントリが出てきたので、早速試してみた。

なお、Minioはサーバー版のDLページに移動すると書いてあるが、「Minio server is under active development. Do not deploy in production.」とのこと。確かに、コミット履歴を見てみると、そこそこの勢いで更新され続けている。自分は単なる自分用のしょうもないサービスのストレージに使いたかっただけなので問題ないが、素直にプロダクション環境に使いたいなら、S3を使ったほうが良さそう。あるいは、S3でCI回すのがコスト的にキツイ時の代替手段程度だろう。

起動

ダウンロードページにも書いてあるが、非常に簡単。

Goで書かれているので、単体のバイナリとして配布されているのが嬉しい。

ただ、上の方法だとhelpが表示されるだけなので、実際に起動するときは

の様に、serverコマンドとオブジェクトを保存するディレクトリを指定する必要がある。

起動すると、Minio内でAWSのaccess_key_idとsecret_access_keyとして扱える値が表示される。

素晴らしく簡単。

Webコンソール

Minioを起動すると、デフォルトでは9000ポートでサービスが起動し、同時に9001ポートでWebUIでMinioを操作できるコンソールが起動する。

ローカルで起動しているなら、http://localhost:9001にアクセスし、Minioの起動時に表示されたaccess_key_idとsecret_access_keyを入力すると、BucketやObjectを作って遊べるWebUIが提供される。

これを触っているだけでもそこそこおもしろいので、SDKからアクセスして挙動を試すために、いくつかBucketやObjectを登録しておくと良い。

Screenshot from 2016-03-07 02:41:51

 

とりあえず、テスト用にDownloadのフォルダにあったMemtestとUnetbootinを適当にぶん投げてみた。(どうして自分はUbuntuを使っているのに、rpmのファイルがDownloadに入っていたのだろう……?)

Rubyからのアクセス

素直に、Amazonが公式で用意している aws-sdk gem を使用する。

aws-sdk自体は、AWSの他のサービスのAPIも全て含んでいて、AWSを普通に使う分には申し訳ないのだが、今回のようにS3クローンのみを使うにはかなり巨大なコードベース、かつコードもあんまり読みやすくないので、正直なところ使いたくなかったが、他のS3に特化したgemではAWS4-HMAC-SHA256、通称V4と呼ばれる方式に対応しているものが見つけられず、かつMinioはこのV4を要求する。そのため、公式のSDKを使うのが最も手っ取り早いようである。もしかしたら、Minioの設定でV4をオフに出来るのかも知れないが、調べるのが面倒で調べていない。

なんらかの任意の方法でaws-sdkをインストールするが、とりあえずbundlerとpryを使って簡単にテストするには、次のようなコードが一番楽だと思う。

見づらい、が。

Aws::Credentialsクラスをわざわざ作っているが、どうせS3の機能しか使わないので、Aws::S3::Clientを作るときに直接指定しても良いかも知れない。

重要なのは、Aws::S3::Clientをnewするときに、endpointというオプションで ‘http://localhost:9000’ というアドレスを指定しているところで、これがAWSの繋ぎ先を変更し、ローカルのMiniに向けているところである。

また、おそらくURIを構築するときに何かあるのだろうが、force_path_styleオプションをtrueにしないと、Objectの取得が getaddrinfo: Name or service not known というエラーで終了してしまう。

そして作成されたクライアントに対してlist_bucketsのメッセージを送ると、先ほどWebUIで適当に作ったBucketsが返される。

list_objectでObjectの一覧の取得にも成功しているし、get_objectで、指定したローカルファイルにオブジェクトをコピーすることもできた。もちろん、MD5を取ってみたが、元のファイルと一致している。

すごいぞMinio

ざっと触ってみたが、個人ユースのS3を使っているプロダクトのバックエンドをまるっと置き換えても、そこそこ使えそうな雰囲気が素敵だ。

何より、最近はDockerを使ったり、作ってるものをなるべくポータブルにするように心がけていたりするので、何かしら永続的なストレージが必要だけど、S3ほど大げさなものは必要ないという場合にはとても強力な選択肢になりそうだ。

すべての機能は試していないが、Rubyのaws-sdkのgemでそこそこ動くので、他の言語に用意されているS3用のクライアントでも、比較的簡単に切り替えが出来るような気がする。これはかなり嬉しいことで、開発中は適当にMinioを使って、プロダクションにのせるときにS3に変更したい時も、ライブラリ構成を変更せずに、設定一つで切り替えられてしまうということだ。

とりあえず、目下は自分のしょうもないプロダクトのバックエンドに使ってみるのと、このブログもDocker上で動いているので、ファイルストレージをMinioに変更してスケールが出来るようにしてみたい。


カテゴリー: Linux, Ruby | コメント / トラックバック: 0個

ConoHaちゃんが好きすぎるので、WebAPIを叩くためのGemを(途中まで)作ってみた


この記事は、ConoHaちゃん Advent Calendar の22日目です

TL;DR

ConoHaちゃんが、普通にクラウドサービス的に使えて便利な上にマスコットは清楚かわいいしWebAPIも用意されていてプログラマフレンドリーだし、好きすぎるからAPI用のRubygemを途中まで作ったけどいろいろ大変だった話。

ConoHaちゃん

このはちゃんは、昔は一応VPSサービスと言っていましたが、リニューアル後はクラウドと名乗っています。フルSSDが使えて転送量は定額、そして一番小さなインスタンスだと国内で(たぶん)一番安い料金設定がステキです。

このはちゃんとの出会いは、丁度いまの会社に入った時に、同僚の人たちに「このサービスのキャラかわいいよ」と教えてもらったことに始まります。確かにキャラが可愛かったことと、サービスとしても気軽にサーバーを借りられて、しかも転送量が一定であること、さらに結構頻繁にイベントや勉強会をやっていて、そこでクーポンをばらまいてくれるというどの辺が清楚なのかわからないところが好きで、いまでは自分で何かするときにはとりあえずこのはちゃんのサーバーで検証してたりします。先日、別のAdvent Calendar に書いた「Deep learning でニコ生監視システム」にも、ConoHaちゃんのサーバーを使っています。

ちなみに、1年くらいはもらったクーポンで運用できてましたが、最近は普通に課金しまくってます。

ConoHaAPI

このはちゃんには、OpenStackに準拠した(らしい、実は私はよくわかってない)WebAPIが用意されていて、ほぼすべての操作をAPI経由で実行できます。できますが、APIの数がかなり多いのと、クエリをビルドするのが結構たいへんなので、これはライブラリ書くしかないなと思ってGemにしました。

conoha_api

Usage

問題点

conoha-apiは、以前に作ったGorakuと同様に、Octokitを参考に作られています。が、このはちゃんのAPIは、GithubやChinachuと違い、サービスごとにAPIのエンドポイントが変わります。たとえば、VMを操作するCompute Serviceと、アカウント情報を管理するAccount Service、アクセスの認証を得る Identity Serviceは、全部APIのホストが違います。ただパスが違うだけだったら良いんですが、普通にホスト名レベルで違います。最初は面倒だな程度に思っていましたが、実装を進めていくうちにいろんな問題にぶち当たりました。

ConohaApi::Clientのモジュールたち

ConohaAPIへのアクセスは、ConohaApi::Connectionモジュールに書かれたrequestメソッドから、Sawyerのラッパーを経由して行われます。そして各APIのエンドポイントは、ConohaApi::Clientクラスの名前空間の下にある、各サービス名に対応したモジュールに定義されています。たとえば、Computeサービスであれば、ConohaApi::Client::Computeモジュールにエンドポイントとメソッドとクエリが記述されています。

ここで問題になるのは、各モジュールでアクセスするホストが違うということです。OctokitやGorakuであれば、ConnectionモジュールをClientクラスにincludeし、Connectionクラスに定義されたget, put, post, patch, delete メソッドを呼び出すことで単一のエンドポイントに統一的にAPIにアクセス出来るのですが、conoha-apiの場合は、APIの定義されたモジュールごとに、ホストを切り替えなくてはいけません。

とりあえず、まずは各サービスのモジュールに、エンドポイントを定義して、呼びだされたモジュールごとにホストを切り替えたSawyerオブジェクト(agentという名前で定義して、requestの中から呼び出されます)の向け先を変えようと思っていました。ですが、ある程度実装を進めたときに、問題にぶち当たりました。

  1. Identity Service でアクセストークンを取得するときに、各サービスのエンドポイントが提示される
  2. ライブラリとしての使い勝手を考えた時、Identity Serviceへのアクセスは暗黙的に行われるべき

1つ目の問題点は、各モジュールにホストをハードコートできないということです。Identity Service にアクセスした時に取得する情報こそ真に信じるべき情報であって、エンドポイントの情報はハードコートされるべきではないからです。これに関しては、Identity Service にアクセスした時に、各エンドポイントの情報を保持することで対応は出来ました。Clientクラスが持っているクラス変数に、各モジュールの名前をキーにしたハッシュマップを用意し、その中にIdentity Service にアクセスした時の情報を保持しておきます。そして、各サービスのモジュールからメソッドをコールした時、Clientクラスはそのメソッドをスタックコールから確認し、そのモジュール名に対応したエンドポイントをクラス変数から引くようにしました。

更に大きな問題は、2つ目の問題でした。例えば、conoha-apiをrequireして、VMを立ち上げるためにComputeサービスにアクセスするために、わざわざClientオブジェクトを作成して、authを行う、という2ステップは行いたくありません。普通は、Clientオブジェクトを作成して、Computeサービスのメソッドをそのまま呼び出します。そうしたとき、Computeサービスが利用しているConnectionモジュールのAgentは、リクエストがあったときにまず認証情報があるかを内部的に確認します。そして、ない場合はIdentity Serviceにアクセスして、トークンを取得し、そして何事もなかったかのようにCompute Service のメソッドを呼び出します。こうすると、ユーザーが明示的にauth処理を行うこと無くライブラリを使えます。

ここで問題になるのは、実際にAPIを呼び出しているのはComputeモジュールなのに、内部で必要な通信はIdentity Serviceということです。ということは、1つ目の問題を解決した「呼び出し元のモジュールによってホストを変える」作戦だと、微妙にうまく行かなくなります。Connection#requestメソッドが複数回コールされた時、微妙に整合性がとれなくなります。

最初は、Connection#requestがコールされた時に、現在のagentをtmp変数に保持して、新しくagentを取得し、最終的にtmpに戻すという方法をとりました。しかし、これではrequestの中で使用されるagentメソッド自体に、自分がどこに接続されているかの情報を渡す必要があり、agentを毎回新しく作成しなさなくてはならないという、やや微妙な実装になりました。インスタンス変数自体にその情報を持っても良いのですが、少なくとも自分が書いたコードでは、なんだか複雑な見た目になってイマイチだと感じました。

そこで、Connectionクラスのインスタンス変数に、次に繋ぎたいエンドポイントをスタックとして所持することによって、この問題はひとまず回避しました。requestがコールされた時、スタックトレースからServiceのつなぎ先を取得しスタックに積み、agentメソッドがこのスタックを参照してSawyerオブジェクトを切り替えることで、コネクションのプーリングが可能になりました。スタックにすることによって、agentもconnectionも複雑な処理や見た目を持つこと無く、比較的わかりやすく書けたと思います。

もちろん、これはベストプラクティスとは思えないので、今後改良の余地はありますが、ひとまずこのように対応しました。

最大の問題点

Connectionモジュールの問題を解決すると、今度はまた別の問題が出てきました。ConoHaAPIは、数が多すぎることです……

数字の問題

ConoHaAPIは、かなりの数があります。Connectionの問題を解決したら、あとはAPIの仕様に沿って機械的にガーッとエンドポイントを定義していくだけなのですが、それでも大量のリクエストJSONの作成や、例外処理、デフォルト挙動の定義など、かなり時間のかかる作業です。

そのため、一旦公開するバージョンはv0.1.0として、Identity Service と Compute Serviceの一部を実現した形になりました。理由は、Identity Service と Compute Serviceさえ実現できれば、最低限のVMの操作を行えるからです。これ以上の各サービスは、順次時間と必要を見て実装していこうと思います。

お金の問題

ライブラリを作った以上、テストをしないわけにはいきません。

が、このはちゃんがいくらリーズナブルとはいえ、VMを落としたり立ち上げたりしてたら、まあそこそこのお金になることは想像できます。今のところ、かかっているお金は数十円ですが、これから先各サービスを実装していくうえで、金銭的な負担はまあまあのものになりそうな気がしています。

これに関しては、モチベーションだけではなく、財布的な意味でも辛いので、ConoHaAPIのサンドボックス環境ができるか、あるいは勉強会でクーポンをもらうまでは、あまり積極的に開発に臨めないかも知れません。

今後

とりあえず、他のAdvent Calendar のネタにした、Deep Learning でニコ生を完全監視システムを、API経由でぱぱっと立ち上げられるくらいには、ライブラリと周辺ツールを整備させていきたいと思います。

あと、すごくこのはちゃんのカレンダー欲しいです。今年の分は勉強会に行ったらもらえてすごくハッピーだったんだけど、リニューアル後はなんかあまり勉強会が開かれて無くて、このはちゃんと触れ合う機械が少なくて正直しょんぼりしています。


カテゴリー: Ruby, プログラミング, ポエム | コメント / トラックバック: 0個

ゲームプラットフォームとしてのSlack


この記事は、 Slack Advent Calendar の19日目です。

Slackは、ゲームプラットフォームだ

最近、よくSlackをチームのチャットツールだと誤解されている方をお見受けしますが、皆本質を見誤っていると言わざるを得ません。Slackがチャットツールではなく、ゲームプラットフォームだという理由は、次の点から明らかです。

  • Emojiという美麗なグラフィックのアセッツ、しかもどれだけ登録しても無料
  • Emojiのサイズが統一的で、ドットとしての役割も果たす
  • テキストベースの複雑なコマンドも入力可能なコントローラ
  • ユーザー識別も可能なので、複数のコントローラでマルチプレイも可能
  • 画面描写がシンプルなので、難しいことを考えずにただ更新前と更新後の画面を用意するだけ
  • あといろいろと

以上のように、Slackがゲームプラットフォームだということは疑いようのない事実ですが、その反面ゲームプラットフォームとしてはやや機能が不足していると思われる面も少なくありません

  • 音を鳴らせない
  • FPSが低い
  • Directなんとかとまではいかないものの、なんか微妙に不便でよくわからないAPI
  • あといろいろ

まあなんというか、Slackはゲームプラットフォームなのに割とゲームを作る能力としては低いです。むしろ最近は、副産物としてのチャットツールの方を成長させようと躍起になり、ゲームプラットフォームとしての本分を忘れ去っているように見えます。

Slack Game

そんなSlackを、ゲームプラットフォームとして活用するために足りないのは何かと考えたところ、どうやら啓蒙活動が足りないように思えました。そう、Slackをゲームプラットフォームとして便利に利用するフレームワークが無いのです。

そこで、作りました。

slack-game

Slack上でゲームを作ることを支援する、RubyGemです。

How to use

とりあえず、手っ取り早く説明するために、デフォルトでデモとして入っているライフゲームを動かします。

lifegame

なんとなく、雰囲気はつかめてもらえたのでは無いでしょうか?

次に、最も簡単なサンプルをGistに用意しました。SlackGameのgemの中に用意されている、Demoというゲームを解説するために、適当に作りました

コード自体はこんな感じ

 

簡単な解説も付け加えておきます

  • SlackGame::Controllerクラスを継承して、commandに識別子と正規表現を渡す
    • 正規表現にマッチするmessageが入力されると、識別子がControllerに記憶される
    • takeメソッドを使って、その識別子を取り出す
  • SlackGame::Canvasクラスを継承して、dotに識別子と、その識別子に対応するemojiを渡す
    • Canvasクラスは、NxMのドットマトリクスを持っていて、drawメソッドでemojiの文字列に変換できる
    • それを、Slackに書き出すことで、NxMのドットのキャンバスを作成する
    • ENV[‘DEFAULT_SPACE’]に設定したものが、デフォルトの空白emojiになる
  • 適当なクラス内で、先に作ったControllerとCanvasをインスタンス化する
    • main_loopメソッドで、Controller.takeを呼び出し、入力されたコマンドを得る
    • コマンドに対応し、Canvasを操作し、再描写する

このデモでは、l(left), r(right), u(up), d(down)の入力をSlackへの入力から取得し、キャラクターを動かして画面を再描写する簡単なゲームです

このように、SlackGameを使うことで、ドットを使った簡単なゲームを作成することが可能です。

免責

SlackGameは、基本的にSlackAPIを連打します。RateLimitに引っかかってなにか泣きを見ても、私は一切の責任を負いません。

言い訳

1ヶ月ほど前に、お酒を飲みながら作ったコードなので、いろいろと内部は綺麗ではありません。あまり参考になるコードは無いと思います。

これからは心を入れ替えて、真面目にコードを整備するので、いつの日かきちんとしたコードになると思います。

他の頭おかしい方々

Vim scriptによるゲームの新アーキテクチャの考察


カテゴリー: 未分類 | コメント / トラックバック: 0個

Deep learning で、全ニコ生番組をリアルタイムで監視するシステム作ってみた


この記事は、ドワンゴAdvent calendar(表)の15日目の記事です

ドワンゴでエンジニアをしている @kinoppyd です

TL;DR

ニコ生を監視し、新しく始まったユー生を定期的に視聴し続け、Deep learning Framework の Caffe を使って画像認識し、何が放送されているのかをリアルタイムに知るシステムを作りました。

注意:この記事の中で使っているニコ生へのアクセス方法に関しては、すべてGoogle検索で分かる範囲の情報を使っています。開発者として知っている情報は一切使っていないことを明言しておきます。また、そこそこの数のリクエストを飛ばすので、真似してニコ生側から垢BANされたとしても、一切の責任を負うことはできません。

何の話か

弊社では、なんか人工知能のラボが立ち上がるくらい、人工知能や Deep learning への関心を高めています。毎日サラッとみんなDLの話をしているのに、私自身はDLをまだ利用したことが無かったので、体験してみたくなって作ったという話です。

残念ながら、DLにあまり造詣が無いので、DLの仕組みやチューニングの話は、この記事ではトピックに上がりません。

ともあれ、DLといえば画像認識の話をよく聞きます。画像に何が映っているのかを、かなり高い精度で理解することが出来るデモを幾つか見たこともあります。そこで、生放送のようなリアルタイム性の高いサービスをリアルタイムに画像認識し、何が映っているのかをリアルタイムに認識させるのは面白いんじゃないか? そうだ、せっかくだし今やってる番組全部解析させてみればいいかな、と思ってこのシステムを作ってみました。

建前

画像認識を使ってニコ生の全放送を監視することによって、ニコ生では今何がトレンドで、どういう放送が人気を集めるかということを可視化して分析するツールが作りたかった。

本音

猫が出てくる生放送をすぐに知りたいんだよおおおおお仕事中に猫の映像を見てなごみたいんだよおおおおおお

構成

構成図は、なんかごちゃごちゃしてますがこんな感じです

niconama-watcher.001

流れとしては、ユーザーがブラウザで見るニコ生のストリームを直接CLIで受け取りながら、ffmpegを使ってストリームのスクリーンショットを取得し、それをCaffeで画像認識した結果を取得します。

各パーツはそれぞれ Docker で構築されていて、ストリーム監視とキャプチャ作成に関しては、WebAPIのリクエスト経由で、都度Dockerコンテナを立ち上げて処理をしています。

Docker

各部分は微妙にセットアップが曲者揃いのソフトウェアばかりなので、それぞれDockerを使ってセットアップしました。

このうち、Caffeとffmpegに関しては、すでにImageが提供されているので、docker pull してくるだけで利用できます。ストリームを取得してくる部分に関しては、Ubuntuの公式イメージをベースに、自作のスクリプトをGistに置いてDockerfileに取得してきたり、必要なツールを入れたりしたものをbuildしています。

Caffe

画像認識に特化したDeep learning framework と聞いています。正直、まだはじめて日が浅いため、全く見識はありません。

今回の画像認識は、リファレンスの学習済みモデルを使用しました。分類とかはかなりイマイチですが、他の学習済みモデルを入れて動作確認する時間が無かったこと、猫を探すだけならリファレンスでも足りるだろうということで、そのままです。

Dockerを使って、既に構築済みの Caffe 環境をそのまま手に入れられますが、なんか古いみたいでいろいろと手を入れる必要がありました。Yahoo!の記事をベースに参考にしつつ、そのサポートという形で複数の記事を参照しました。

Caffeで手軽に画像分類

Caffeで機械学習 -1- リファレンスモデルを使って画像をカテゴリ分類

『Caffeで手軽に画像分類』が手軽にできない。

OSX10.10でCaffeをインストール、リファレンスモデルで画像を分類

本当であれば、このすごいエントリを見て感化されたので Google Cloud Vision API を心の底から使いたかったのですが、一週間ほど前に利用申請を出しても今日の今日まで完全にガン無視されてしまったので、泣く泣く自前で Caffe のサーバーを立てて使います。Cloud Vision API を使ってみたかった……。Cloud Vision API を本当に使ってみたかったから、残念で仕方ない。悲しい。つらい。

ffmpeg

ニコ生は、Flashを使ったFLV形式で放送を配信しているので、それをキャプチャするためにffmpegを使いました。これも普通にセットアップするのは面倒ですが、Dockerを使ってコマンドを実行するごとにコンテナを立ち上げれば非常に簡単に使えました。

ひとつはまった点として、ドキュメントのとおりにキャプチャを作成すると、引数の順番の関係で一度flvを再エンコードしたうえでキャプチャを生成するので、非常に遅くなるということでした。下記のQiita記事を参考に、リアルタイムで切り抜けるようになりました。

FFmpegことはじめ

ニコ生を監視し続ける部分

ここに関しては、いくらGoogle検索で集められる情報とはいえ、あまりおおっぴらに書くものでも無いので割愛します。ただ、安定して動かなくて困ったという感想だけ。

Sinatra+Unicorn

それぞれのDockerを制御するために、WebAPIを用意しました。リクエストを受け取りDockerを起動させるものや、起動しているDockerの中でなにか処理をしたりと様々ですが、それぞれの受け口をすべてをSinatra+Unicornで手っ取り早く用意しました。Sinatraは、単一機能の簡単な処理をするAPIなどを作るときに、非常に簡単に記述できます。Unicornを使っているのは、複数のWorkerを手軽に立てたかったからです。

  • ニコ生番組のIDを受け取り、監視用のDockerを起動するAPI
  • ニコ生番組のIDと秒数を受け取り、ストリームの指定の秒数をキャプチャするDockerを起動するAPI
  • 画像を受け取り、Caffeで画像認識を行った結果を返すAPI

以上の3つを作成しました。番組の監視とキャプチャは、Dockerコンテナを起動することが目的なので、Dockerのホスト側で動かしています。それに対して、Caffeの画像認識は、既に起動しているDockerのコンテナ内で、画像を受け取り認識するために動作しています。

Ansible

各サーバーのプロビジョニングには、Ansibleを使用しました。基本的に、サーバー側での作業はDockerをインストールして、イメージをビルド、あとはUnicornを走らせる環境を用意するだけなので、シングルファイルのPlaybookで十分足ります

全生放送を監視する関係上、番組を監視する部分にトラフィックがかかるため、今回は10台の監視サーバーを用意しました。そしてそれに合わせて、毎秒大量の画像認識のクエリが発行されるため、Caffeのサーバーはコアとメモリの大きめのものを2台用意して、中で複数台のコンテナを立てて、画像を受け取り分析しています。

ConoHa

インフラストラクチャには、このはちゃんを使用しました。なんでかっていうと、このはちゃんのファンだからです。本来ならば、AWSのGPU付きサーバーを借りるのがベストだとは思いますが、トラフィックの料金の見積もりが微妙に心もとなかったのと、学習済みモデルを使うので別にGPU使うほどでは無いだろう、というのが理由です。ただ、やはり学習済みモデルを使っても、画像認識にはかなりの時間がかかったので、素直にAWS借りておけばよかったと後悔しました。

実行

実際には、このシステムで1日中ずっとニコ生に張り付き続けていると、普通に攻撃していると受け取られてBANされかねないので、30分だけ全番組監視システムを作動させてみました。また、毎秒のキャプチャを解析していると全然マシンリソースが足りないので、5秒に1回に設定しています。とはいえ、同時に数百の番組の1シーンを解析すると、それでも5秒程度のインターバルでは足りないと思いますが……

ニコ生では、だいたいピーク時間で2000番組前後のユーザー生放送が同時に放送されていますが、そのうちシステムを起動した時間以降にスタートした番組を監視します。

結果

大変悲しいことに、猫は見つかりませんでした……

一応、猫と判定された画像は2枚あったのですが、ポケモンのプレイ画面とFPSのやたらブレた画面で、一体何がどういう理由で猫と判定されたのかは不明です。

正直、1枚くらい猫が見つかってくれると思っていたので、悲しい気持ちでいっぱいです。

とはいえ、猫が見つからなかっただけでは結果としてアレなので、大量の画像認識の中で一体何が最も多く検知されたのかを見ていきたいと思います。

以下が、 Caffe のリファレンスモデルを使ってニコ生をリアルタイム監視した結果、最も多く得られたクラスの上位です

420 web site, website, internet site, site
370 scoreboard
166 bubble
110 toyshop
107 television, television system

1位の Web Site というのは、だいたいデスクトップをキャプチャした放送や、ゲーム配信で多く見られました。どうやら、画面を操作するためのアイコンがやメニューが並んでいる様子が、ブラウザに見えるようです。

2位の Scoreboard も同様に、ゲームのリザルト画面や、普通のゲームの画面のがチョイスされていました。おそらく、数字が規則的に並んでいるためにスコアボードと判定されたのだと思います。面白いところでは、麻雀のゲーム画面がスコアボードと判定されていました。

3位の Bubble はなんだかよくわかりませんでしたが、なんか丸っぽい線が多く現れている画像に多かったです。PS4の配信禁止中の画像なんかは、だいたいこれに引っかかっていました。

4位以下は、正直もうなんだかよくわかりません。

また、 Caffe は画像認識をした結果、マッチ率のようなものを%で出してくれるのですが、これもほぼ頻出上位とかぶっていて、微妙でした。

感想

ニコ生を Deep learning してみた結果、とりあえずゲーム配信がすごく多いというのはわかりました。キャプチャした画像を並べて観ているだけで、ああゲームばっかりだ、という感じです。PS4配信などで簡単にニコ生で放送できる手軽さが影響しているのかも知れないし、もともとそうだったのかも知れませんがよくわかりません。

技術的な感想。

大量のコンテナを立ててみたけれど、やっぱり Caffe で画像認識するところがものすごい詰まります。このボトルネックに引っ張られて、数百番組のリアルタイムの監視とは程遠い速度でした。数十程度ならリアルタイムで監視出来ると思うので、実用的には Caffe を動かすマシンに GPU を使い、もっと後ろに大量に並べるべきかなと思います。また、ニコ生を監視する部分も全然足りてませんでした。1サーバー数十番組くらいイケるかと思いましたが、裏の画像認識部分が詰まっていたので、引っ張られて監視部分も完全に詰まってました。

Ansible+Docker構成なので、横にブン並べるだけであれば札束で殴ることも可能です。ですが、そうすると今度は全体を制御する部分にものすごい負荷がかかります。今回は、各APIをコントロールしていたのは手元のホストマシンで、Rubyで書いたスクリプトで大量のスレッドを生成して各監視サーバーにクエリを投げて回してました。実際に数百番組を同時に監視するのであれば、やはりメッセージキューイング等の非同期クラスタで本格的な対応が必要だと思います。

膨大な情報量に対して、多少こちらの準備が甘かったため、やや残念な結果に終わってしまいましたが、まともなジョブ管理と札束があれば、意外と実用的に全ニコ生監視システムが作れそうな実感はありました。

ソース類に関しては、4日ほどで作ったためかなり荒削りなところが多いことと、普通に公開するとやっぱり怒られそうな気がするので、ある程度整備したうえで問題なければ後日に公開しようと思います。

ひとまず、 Deep learning に触れてみるという目的を達成したので、満足しました。


カテゴリー: Debian, Linux, Ruby, プログラミング, ポエム | コメント: 2 件

劇場版ガールズ&パンツァーを観てきた


神だった

これはすごい、最初から全力の、最後まで総力戦って感じだ。もう1回、いやもう何度か観なくては……


カテゴリー: 未分類 | コメント / トラックバック: 0個

Spectre 007 を観てきた


James Bond が大好き

ジェームズボンドシリーズがとにかく大好きで、しかもリブート後初のスペクター登場ということで楽しみにしていた。

とりあえず、観た感想としては、これはロジャームーア時代の007クオリティだわ、って感じだった。さすがに、ロジャームーア以降最高の駄作ダイアナザーデイを超えることは無かったけど、クレイグボンドでは最下位の出来。

楽しめたところとダメだろと思ったところが半々くらいで、まあこんなこともあるよね、って感じの普通の007映画。

とりあえず、車のエンジンが唸る音はもっと聞かせて欲しかった。せっかくのアストンマーチンDB10なのだから。

 とりあえず、あと1回くらい観に行こうかな

007そのものの大ファンなので。

ほんの少しだけネタバレ感想

あのすげえタフな悪役、ジョーズじゃねえのかよ


カテゴリー: ポエム | コメント / トラックバック: 0個