Vagrant上のUbuntuにRabbitMQをたててMQTTをお試し

MQTTがだいぶ流行ってきている感がある今日この頃。 仕事上でもちょっと触る必要がでてきたのでちょっとメモっておきます。 MQTTについてはこちらの素晴らしい記事で確認して下さい。

今回はとりあえずちょっと試したいのでブローカーサーバーとしてRabbitMQを使うことにしました。

Vagrantの準備


Vagrantのインストールとか使い方は至る所に記事が転がっているのでそちらを参照して下さい。

とりあえず今回はHashicorpが提供しているubuntu/trusty64を使っています。

あと、同一ネットワーク内の様々な機器からアクセスしたいのでVagrantのネットワーク設定はPublic Networkにしておきます。

私はMacWi-Fiで接続しているので以下のような設定をVagrantfileに追加しておきます。

config.vm.network "public_network", :bridge => "en0: Wi-Fi (AirPort)"

あとはいつもどおり、vagrant upvagrant sshでサーバーに接続しましょう。

RabbitMQのインストール


細かいことは公式ページに書いてあるのでこちらを見ればいけるかと思います。

私の行った作業をメモがてら残しておきます。

まず、RabbitMQのインストール。

sudo apt-get install rabbitmq-server

次にMQTTの有効化。

sudo rabbitmq-plugins enable rabbitmq_mqtt

実行結果。

vagrant@vagrant-ubuntu-trusty-64:~$ sudo rabbitmq-plugins enable rabbitmq_mqtt
The following plugins have been enabled:
  amqp_client
  rabbitmq_mqtt
Plugin configuration has changed. Restart RabbitMQ for changes to take effect.

Webインターフェイスの有効化。

sudo rabbitmq-plugins enable rabbitmq_management

実行結果。

vagrant@vagrant-ubuntu-trusty-64:~$ sudo rabbitmq-plugins enable rabbitmq_management
The following plugins have been enabled:
  mochiweb
  webmachine
  rabbitmq_web_dispatch
  rabbitmq_management_agent
  rabbitmq_management
Plugin configuration has changed. Restart RabbitMQ for changes to take effect.

RabbitMQ Serverをリスタートします。

sudo /etc/init.d/rabbitmq-server restart

起動しているか確認しましょう。 Erlang/OTPのプロセスはbeamで動きます。

vagrant@vagrant-ubuntu-trusty-64:~$ sudo netstat -anp | grep beam
tcp        0      0 0.0.0.0:15672           0.0.0.0:*               LISTEN      2328/beam
tcp        0      0 0.0.0.0:55672           0.0.0.0:*               LISTEN      2328/beam
tcp        0      0 0.0.0.0:47761           0.0.0.0:*               LISTEN      2328/beam
tcp        0      0 127.0.0.1:34940         127.0.0.1:4369          ESTABLISHED 2328/beam
tcp6       0      0 :::1883                 :::*                    LISTEN      2328/beam
tcp6       0      0 :::5672                 :::*                    LISTEN      2328/beam

動いていますね。

1833ポートがMQTT、15672ポートがWebインターフェイスとなります。

ホスト側からWebインターフェイスにアクセスしてみましょう。

f:id:braitom:20150513145007p:plain

繋がりますね。

初期アカウントはguest/guestとなります。

f:id:braitom:20150513145011p:plain

コンソールに入れました。

これでインストールは完了です。

ブローカーサーバーに繋いでみる


さてRabbitMQが立ち上がったのでMQTTで接続してみましょう。

せっかくなのでiPhone6から使える気圧センサーの情報をPublishしてみることにします。 Subscribe側はどこでも動くように今回はPythonで書いてみます。

Publish側(iOS)

今の時代はSwiftなのでSwiftで実装します。 MQTTライブラリとして以下を使用します。

コードは以下にありますのでご確認下さい。

実際にPublishしているのはこの部分です。

self.mqttClient.publishString("\(currentTime): \(pressure)", topic: "test/iOS", qos: 0, retain: false)

Topic名は、”test/iOS"、QoSは0(最高1回。届くかは保証しない。)、Retain(メッセージをMQTTサーバーが保持)はfalseにしてあります。

Subscribe側(Python)

ライブラリは以下を使用します。有名なやつですね。

pipでサクッといれましょう。

pip install paho-mqtt

コードはこんな感じになります。サンプルなのでただコンソールに出力するだけです。

MQTT subscribe sample

ポイントとしてはsubscribeするTopic名(今回は、"test/iOS")をPublish側と合わせることくらいですかね。

実行

まずSubscribe側を実行しておきましょう。

$ python subscribe_mqtt.py
Connected with result code 0

これでブローカーサーバーに繋がりSubscribeの準備はできています。

次に、Publish側を起動しましょう。

これで気圧情報をガンガンPublishし始めます。

f:id:braitom:20150515170104p:plain

Subscribe側を見ると情報が届いているのを確認できるかと思います。

f:id:braitom:20150515165931p:plain

まとめ


このように比較的簡単にMQTTをお試しすることができました。 MQTTを実際に使うには、切断検知や再接続方法、セキュリティ等を使用用途によって考えなければなりませんが、なかなかシンプルで良いプロトコルだと思います。 今後も情報集めていきたいですねー。

疲れた時にBotに癒してもらおう

前置き

作業中ちょっと息抜きしたいときってありますよね。そんなときは何故か戸田恵梨香さんを見たくなるのは私だけではないはず。

疲れているときはキーボードで文字入力するのも面倒なので楽に戸田恵梨香さんを見たいものです。

そんな時に便利なのがRingです。

届いた時にちょっと試して精度とかが全然ダメだったので使えねーとしばらく眠らせていたのですが、久々に触ったらやっぱ結構面白いかも?と個人的に感じたので、ちょっとしたデモを作ってみました。

ちなみに新型ももうすぐ出るみたいですね。300%精度が向上したということなので試しに予約してみました。さてどうなることやら。

仕組み

仕組みはいたって簡単です。

  1. 画像を検索するWebサーバーを立てる
  2. Ringでのモーションに上記のサーバーのURLをOpen URLで指定
  3. ジェスチャーを実行するとSlackの特定のチャネルに戸田恵梨香さん画像を投稿

たったこれだけ。

使い方

  • SlackのTokenを取得します。取得方法ついては自分でググって下さい。
  • サーバー側はこちらに置きました。

    Ring2Slack

  • デプロイ方法等はREADMEを読んで下さい。Heroku Buttonを置いておいたのでそのままHeroku上へもデプロイできるようにしておきました。
  • あとはRingのアプリからOpen URIでデプロイしたURLを指定すればOKです。 こちらのRingのページを見れば分かると思います。
  • あとは指定したジェスチャーを行えばSlack上に画像が投稿されます。

所感

まあぶっちゃけ現行のRingは精度悪すぎワロタ状態なのでジェスチャーを認識させるのも一苦労で逆にストレスがたまります。これは新型に期待。あとつけ心地悪すぎ。デカすぎます。これを普段着けておくとか無いっすわ。

とは言え、簡単なジェスチャーでWeb APIと連携できるようになるのはやはり素敵。Hueとかと組み合わせれば電気の点灯、消灯もジェスチャーでできるし、IRKitとか使えばTVのオン、オフもできますよね。

自前スマートホームを作りたいと思っているので、簡単な操作を何で行うのが良いのか個人的に考えている中で、音声認識よりはジェスチャーによる操作の方が性にあっていると感じたのでRingで遊んでみました。

さいごに

いろいろ述べてきましたが、言いたかったことは次の2点です。

  • ウエアラブルなジェスチャーコントロール端末に期待
  • 戸田恵梨香かわいい

f:id:braitom:20150323172438p:plain

Slack×Hubot×GitLabでレビューを効率化しよう

この記事はSlack Advent Calendar 2014 - Qiitaの22日目の記事です。

内容

チーム内でのちょっとした開発にはGitLabを使っているのですが、MargeRequest(以下MR)を投げた時にレビューを効率化するためにの方法を説明したいと思います。

Slack導入以前

別にMRが発生したらメールを投げればいいのですが、メールだとすぐに見ないことも多いのも事実。 そこで、Slackを入れる前はMRが起こるたびにYoを送ってMRが飛んだよーということを気づかせるようにしていました。

ちょうどYoが無駄に流行っている時期でもあったし、Yo APIもあったのでしばらくこれでしのいでいました。

そのとき作ったのがこれです。

Flask-yo

しかし、最初のうちは楽しくてみんな反応していたのですがだんだんと反応しなくなりました。結局Push型でみんなにYoが行くので、誰かレビューするだろ?ってなっちゃうんですよね。

Slackの導入

チーム内のコニュニケーションを円滑にするためにSlackを導入しました。 Slackいいですよね。チーム内のコニュニケーションがかなり活性化されたと思います。 業務中はだいたいのメンバーはSlackに常駐しているのでGitLabのMRもこっちに流そうと思いました。

やりたいこととしては以下となります。

  • MRが飛んだらMRのタイトルと内容とリンクを特定のチャネルに通知
  • 合わせて、@でランダムでレビュワーを割り当てる
    Slackの通知をスマートフォンアプリでも

これによりMRがいつ飛んだのか、誰がレビューするべきかを明確にします。

導入準備

まず今回試しているGitLabのバージョンは「GitLab 7.4.3」となります。

  1. SlackにHubot Integration
    まずはこれが必要です。ちょうどちょっと前にSlack APIのアップデートがあり以前とちょっと方法が変わっています。 すばらしいことにSlack Advent Calendar 2014の4日目にKeitaMoromizatoさんがこの新しいIntegrationの導入方法の記事を書いてくれていますので詳細はこちらを参照して下さい。
    SlackのHubot Integrationが知らぬ間にアップデートされてた
    また、hubot-slackもバージョンアップされておりこれによりプライベートチャネルにもHunotが常駐できるようになりました!素晴らしい!これが出るまではXMPP経由でHubotの設定をしなくてはならず若干面倒くさかったのですよね。。。

  2. Hubotの用意
    様々な記事があるようにHerokuに立てるのが一番楽だと思います。これも参考になる記事がいくつもあるので以下をご参照下さい。他にもググれば参考になる情報がたくさんでてきます。
    slackにHubotを導入(Heroku経由)

  3. GitLabの設定
    スクリプトを作成する前にGitLab側の設定を行いましょう。GitLabにはWebHookの機能がありますのでこれを使用します。
    設定したいプロジェクトの「Setting」→「WebHook」を選択します。

f:id:braitom:20141222133302p:plain

ここを見てもらえると分かるのですが、GitLabでは以下のタイミングでWebHookを使うことができます。
・Push events
・Tag push events
・Issues events
・Merge Request event

今回はMRだけ取りたいので「Merge Request event」にチェックを入れます。そしてURLにはリクエストを送る先のURL(Hubotが動いているURL)を入力して「Add Web Hook」を押します。
もちろんMR以外のイベントもHookして取り回したいという場合はスクリプト側でハンドリングしてあげればOKです。

スクリプトの作成

まずスクリプトの全体は以下となります。これをHubotのscriptsフォルダにおけばOKです。

hubot-gitlab mearge request review

特に難しいことはしていません。ポイントを解説すると、

Slack APIを直接たたいている

hubot-slackを使えば楽ちんなのですがHubotからSlackへ投稿すると@(メンション)と#(チャネル)はデフォルトでリンクとなりません。 こんな感じにただのテキストとして扱われてしまいます。これだとメンション扱いにならないので気付かずにスルーしてしまいそうですよね。

f:id:braitom:20141222134330p:plain

この辺のSlackの仕様は以下のリンク先で確認して下さい。

Slack API Message Formatting

今回は@できちんとメンションとして通知したいという目的がありますのでこの方法でいきました。

4行目のBASE_URLでSlack API Tokenを設定しています。

BASE_URL = 'https://slack.com/api/chat.postMessage?token=xxxx-xxxxxxxxx-xxxxxxxxxx-xxxxxxxxx-xxxxxxx' #replace your Slack API key!

44行目のurlの一番最後に&link_names=1を付与しています。これにより@がきちんとメンションとして機能するようになります。

url = BASE_URL + 'channel=' + channel + '&text=' + encodeURIComponent(message) + '&link_names=1'

レビュアーのランダム化

Hubotのrandom関数を使うようにしています。

random = require('hubot').Response::random

使い方は簡単です。36行目です。

assignee = random members

これでassigneeに6行目のmembersで定義したメンバーがランダムに入ってきます。

GitLabからのHook先

hubotにはrouterの機能があるので指定したURLにPostが来たときの動作を書くことができます。14行目ですね。

robot.router.post '/hubot/gitlab', (req, res) ->

これでhttp://HubotのURL/hubot/gitlabにPostが来た時にこの関数が呼ばれます。 つまりこのURLを上で述べたGitLabのWebHook設定時のURLに指定するわけです。

GitLabからのHook内容をハンドリングする

これは21行目〜24行目で行っています。GitLabが実際にどのようなJsonを送ってくるかは以下を参照して下さい。

GitLab Web hooks

※このJsonの内容はGitLabのバージョンによって変わってきますのでお使いのGitLabのバージョンのドキュメントをきちんと確認して下さい。

Pushでも反応させたい、MRクローズ時も反応させたい等の機能はここを書き換えることになります。

まとめ

この状態でMRが飛ぶと以下のようにメンション付きでbotが教えてくれます。

f:id:braitom:20141222134853p:plain

この方法でMRをレビューすることで前より効率がよくなった気がします。あと、おみくじ的な感じでなかなか面白いです。(また俺が担当かよー!みたいなこともありますが。)

今後もいろいろ改善していきたいですね。よいSlackライフを!

iBeaconで濡れしらず

この記事はおうちハック Advent Calendar 2014 の18日目の記事です。

お題目

外出してから雨が降ってきて、「傘がない!」という経験がある方は多いと思います。 天気予報を見る習慣がある方はいいのですが無い方もそれなりの数いると思います。

こんな悩みを解消しよう!というのが今回の目的です。

ちなみにこのコンセプトのプロダクトは実はもう既に世の中には存在しております。

KickStarter案件だとairfy Beaconというプロジェクトが存在しています。 日本国内だと最近、そら用心というものがリリースされて一部の間でちょっとした話題となっております。

こういったものを自分でも比較的簡単に作れるよ!というのを知ってもらうのも目的であったりもします。

使用する技術要素

今回はAppleのiBeaconを使用します。私の知っている範囲だとiBeaconを決済のものと思い込んでいる方も世の中にはまだそれなりにいるようなので、こういう使い方をするものなのだよということを示したいのでiBeaconでやってみました。

iBeacon自体の詳細は今回は述べません。ググればたくさんヒットすると思いますのでそちらを参照して下さい。

一つだけお勧めするとしたら以下の書籍です。非常に良くまとまっているのでこれを読んどけば大体は分かるかと思います。

使用する機器

  • 以下のいずれかのiOS搭載デバイス
    ※なお今回のサンプルはiOS8以降での動作を確認しております。動作させるためには端末のBluetoothがONになっている必要があります。

  • Beacon
    Beaconを自分で用意する必要があります。昨今けっこういろいろと出てきているので、「iBeacon モジュール」とかで検索してみて自分の好きなモノを選んで下さい。電波強度が調整できるものを選択した方が良いです。以下にいくつか紹介しておきます。

実装

今回はObjective-Cで実装します。気が向いたらSwift版のサンプルも用意したいと思います。

天気情報の取得ですがいくつかのサービスがAPIを提供しています。有名どころで言うとlivedoorのお天気Webサービスでしょうか。 今回は傘を持っていくかどうかを知りたいので降水確率が欲しいです。しかしlivedoorAPIは降水確率が取得できません。他のサービスも調べてみると降水確率が取得できるものが全然ありません。

そんな中見つけたのがこれです。

1分間に10リクエスト、一日で500リクエストまでは無料とのことなのでこれを使うことにしました。

※予報の情報が正しいかは保証できません。ちょっと試している限り問題無いとは思うのですが。。。もっと降水確率の精度を求めるのならば気象庁の予報ページとかをスクレイピングして情報を取得するのも手かもしれません。

ソースコードの全体は以下に上げてありますのでこちらをご覧下さい。

UmbrellaNotifier

動作確認

  1. まずはBeaconを玄関の隅の方に置きます。
  2. アプリを端末にインストールして玄関に近づきます。
  3. 今日は傘を持っていくべきかどうかを通知してくれます。

f:id:braitom:20141218004910p:plain

f:id:braitom:20141218010024p:plain

さいごに

このように比較的簡単に目的のものが作成できました。iBeaconを使うと他にも、「家に帰ってきたらhueのスイッチをONして電気を付ける」とか、「IRKitを使ってTVとエアコンのスイッチをオン」とかも今回の応用でできます。

みなさんも是非いろいろなおうちハックをしてみてはいかがでしょうか?

補足

  • Beaconの設定とか細かいことは購入した製品の説明書をお読み下さい。
  • このサンプルはiBeaconによる降水確率の通知にのみ焦点を当てています。CoreDateのベースだけ作ってあるので通知情報を保存したい場合はそのように実装し直して下さい。(つまり細かい実装をサボりました。。。すいません。必要あれば言って下さい。)
  • サンプルだとBeaconのリージョンに入った時に情報を通知するようにしています。ですので、帰宅時も通知が来てしまいます。これを回避したい場合はリージョンの入出も管理して帰宅時は通知をしないように実装し直して下さい。

pod installでエラーが出るときの対応

pod installしたときに以下のようなエラーが出ることがある。

[!] The `master` repo requires CocoaPods 0.32.1 -

こんな時は、CocoaPodsをバージョンアップしてあげればOKです。

gem install cocoapods

無事アップデートされたら再度、pod installしてあげれば問題なく動くはずです。

Mac OSXのDockerを1.0にあげる

Docker1.0がリリースされましたね。

IT’S HERE: DOCKER 1.0

早速アップデートしたのでメモ。

古いBoot2Dockerをアンインストール

既に1.0より前のDockerを入れている人はbrew経由でDockerを入れているはずです。今回からインストーラーが提供されているようなので古いバージョンのものはアンインストールしておきましょう。

あれDocker入れてたっけな?という人は以下コマンドでBoot2Dockerが入っているかを brew ls コマンド確認しましょう。

入っていたらアンインストールしましょう。

$ brew uninstall boot2docker

Boot2Dockerのインストール

公式サイトからpkgをダウンロードしましょう。

boot2docker/osx-installer

あとはポチポチ押してインストールしていけばOK。

環境変数の設定

Docker1.0からDocker Serverのポート番号が「4243」から「2375」に変わっているようです。

各自の環境に合わせて、.zshrcなり.bash_profileなりを書き換えましょう。

export DOCKER_HOST=tcp://localhost:2375

動作確認

Boot2dockerのDocker VMをアップグレードします。 ターミナルで以下を実行すればOK。古いDocker VMの削除、新しいVMのダウンロード、init、立ち上げまで行っています。

$ boot2docker delete
$ boot2docker download
$ boot2docker init
$ boot2docker up

止めるときは、

$ boot2docker down

念のためdockerのバージョンを確認しておきましょう。

$ docker version
Client version: 1.0.0
Client API version: 1.12
Go version (client): go1.2.1
Git commit (client): 63fe64c
Server version: 1.0.0
Server API version: 1.12
Go version (server): go1.2.1
Git commit (server): 63fe64c

上がっていますね!

あとはDockerを今までどおり使いましょう。

さいごに

ついにDockerも1.0がでましたね。今後のコンテナ型の仮想化が流行っていくことを期待しましょう。

ちなみに、より詳しい手順は公式サイトを見てください。

Installing Docker on Mac OS X

このサイトでは、

$ boot2docker stop
$ boot2docker download
$ boot2docker start

と書いてありますが、boot2dockerのヘルプを見ると、「start」は「up」、「stop」は「down」が正式なのかな?と思いこの記事ではupとdownを使っています。

Brewfileとbrew-caskとを使ってのMacのセットアップ

Macの初期セットアップをするにはBoxen使うよりもBrewfileとHomebrew-cask使うのが良いかと思います。

現時点ではこの方法が一番だと個人的には思っております。

BrewfileとHomebrew-caskについての記事はいろいろな方が書かれているので詳細はそちらを参照して下さい。

Boxenはなぜダメなのか?

Boxenが全然イケてないよという訳ではありません。上で上げた記事でもみなさん述べているのですが、Boxenは大掛かりすぎるのですよね。最初はBoxen使えば個人的にMac買い替えた時に便利だなーとか、みんなの環境揃えられるかなーと思ってちょっと調べていたのですがいろいろ面倒くさい。

あと、なんやかんやでPuppet覚えないといけないのもちょっと。Boxen触り始めて初めてPuppetを触り始めたのですが最初ちょっと辛かった。まあ慣れてしまえばどうってことないのですが。この最初の敷居がチーム内に浸透させにくそうだと感じました。

そして一番の原因が自分の環境がイマイチよく分からなくなること。Boxenの動きをきちんと理解すれば問題ないのでしょうが、rbenvとかもろもろ勝手に入れられてしまうのでなにがどこにあるのか私的には分からなくなりました。

そんなこともあり、結局仮想マシン上のOS Xでいろいろと試行錯誤しましたが結局使うことをやめました。

(ここが結構大事なところで私はチキンなのでいきなりローカル環境で試す気にはなりませんでした。安全策をとってこの方法仮想マシン上で実験しました。結果、これで良かったと心から思っております。)

Brewfile

HomebrewはMacで開発している方ならほとんど使っているはずです。(MacPortsを使っている人もいるかと思いますが。。。)。なのでbrewの延長線上で環境を管理できるので違和感なく導入できるのが最大のメリットだと思います。

そして非常にシンプル。Brewfileを用意してそこにインストールしたいものを記述しておけば、brew bundleコマンド一発でセットアップができます。

しかもこのコマンドをたたいた時に、既にインストールされているものは「既にインストールされています」とスキップしてくれます。これ地味に便利。

Homebrew-cask

brewだけでできることはあくまでもbrewに登録されているパッケージを管理することだけです。そこでbrew-caskが必要になってきます。これを使うとdmgやpkg形式の普通のアプリケーションもインストールできるのです。素晴らしい。

私が普段使っているアプリは全てcaskのリポジトリに登録されていたので全く問題なかったです。もし自分が使っているアプリが登録されていなくても簡単なRubyのコードを書いてあげればOKなので拡張性も高いです。

まあアプリケーションのインストールはBoxenでもできるのですが、何度も言うように Brewの延長上でできる ということが最大の肝だと思います。

補足

インストール方法についてはここでは特に触れません。それぞれのドキュメント読むなり、冒頭であげた方々の記事を読めば詳しくのっております。

一応、各ツールのリンクだけ張っておきます。

まとめ

私のBrewfileはdotfilesの一部としてあげておきました。

こうしておけば以前書いた記事のようにhomesickを使って、いつでもどこでも自分の環境を作りなおすことが可能です。

チーム開発を行う場合はチームでのdotfilesを用意しておけば良いだけです。

すごいべた褒めな感じでBrewfileとHomebrew-caskを紹介しましたが不満点が無いわけではありません。

以下に今のところの私の不満点をあげておきます。もしかしたら何かしら方法があるかもしれないので「それできるよ!」というものがあったら@braitomまで教えていただけると助かります。

  • OS Xの設定ができない

    • BoxenではDockを左側にするとかそういったOS Xに関する設定ができました。brew-caskだとこれができません。
  • App Storeのアプリはインストールできない

    • これは致し方無いきもしますが、AppStoreの履歴からポチポチするのがダルいです。
  • brew-caskでインストールするものの中にはたまにpassword入力が必要なことがある

    • 私の場合、Google日本語入力がpasswordの入力が必要で途中で処理が止まっていました
  • コマンド実行が必要なものをいれられない

    • 私の場合、nodeのバージョン管理にはnodebrewを使っています。 こいつはperlコマンドをたたいてあげる必要があるのですがこれができる方法が無いです。あとoh-my-zshもこの理由により入れることができません。

この辺を解決できる手段があればまさに最強のツールになるのですが、たいした手間でも無いので私的には全然許容範囲です。