SHOYAN BLOG

I am a pragmatic programmer.

5分でできるRubotyのインストールとプラグインチュートリアル

RubotyはhubotクローンでRubyで書けるbotです。
このチュートリアルではRubotyのインストールとプラグインの作成方法を紹介します。
冗長な説明をあえて除きRubotyを動かすために重要な部分のみ解説することでスピーディにRubotyを動作できるようにしています。

Rubotyをローカルで動かす

以下のコマンドでinstallします。

1
$ gem install ruboty

以下のコマンドでひな形を作成します。
ruboty/ ディレクトリとその配下にGemfileが作成されます。

1
$ ruboty --generate

Rubotyを起動してみます。

1
2
3
$ cd ruboty
$ bundle install
$ bundle exec ruboty

すると対話型のプロンプトが起動します。

1
2
3
$ bundle exec ruboty
Type `exit` or `quit` to end the session.
>

ruboty pingコマンドを実行します。

1
2
> ruboty ping
pong

ruby helpコマンドで一覧が見れます。

1
2
3
4
> ruboty help
ruboty /help( me)?(?: (?<filter>.+))?\z/i - Show this help message
ruboty /ping\z/i - Return PONG to PING
ruboty /who am i\?/i - Answer who you are

Rubotyプラグインを作成する

Ruboty はhubotと同様にプラグインで拡張できます。

Helloプラグインを作成してみましょう。
Helloプラグインはhelloと挨拶すると、helloと挨拶を返すだけのプラグインです。

hello.rb

1
2
3
4
5
6
7
8
9
10
11
module Ruboty
  module Handlers
    class Hello < Base
      on(/hello/i, name: hello, description: "こんにちは")

      def hello(message)
        message.reply("Hello!!")
      end
    end
  end
end

Ruby::handlersの名前空間の下にプラグインの名前でクラスを作成し、on メソッドを定義します。
on メソッドの第1引数はコマンドです。正規表現で定義できます。
第2引数は呼び出すメソッド名、コマンドの説明等のオプションを指定します。

実行してみましょう。
-l オプションで読み込むファイルを指定することができます。

1
2
3
4
  bundle exec ruboty -l hello.rb
Type `exit` or `quit` to end the session.
> ruboty hello
Hello!!

また、bot名のprefixなしに実行することもできます。
allオプションを使って実装します。

サンプルとして、ぬるぽプラグインを実装します。
これはぬるぽという言葉に反応するプラグインです。

nullpo.rb

1
2
3
4
5
6
7
8
9
10
11
module Ruboty
  module Handlers
    class NullPoHandler < Base
      on(/.*(ぬるぽ|ヌルポ).*/, name: 'nullpo', description:'ぬるぽに反応します', all: true)

      def nullpo(message)
        message.reply("ガッ!!!!")
      end
    end
  end
end

実行してみましょう。
-l オプションで読み込むファイルを指定することができます。

1
2
3
4
$ bundle exec ruboty -l nullpo.rb
Type `exit` or `quit` to end the session.
> ほげ ぬるぽ ほげ
ガッ!!!!

bot名のprefixがなくても反応していることが確認できます。

次回はSlackと連携させる方法を紹介します。

GitHubのリポジトリを監視するGitMonitor

GitHubのリポジトリを監視するGitMonitorというサービスを紹介します。
このサービスはGithubのリポジトリを監視して、そのリポジトリに行った操作をダッシュボードで確認することができます。
また、Flowdock、Slack、Emailに通知することも可能のようです。

以下は、masterに直接pushしたときのログです。

git-monitor-image

GitMonitorは様々なルールが設定でき、そのルールに該当したものがダッシュボードに表示されます。
例えば、LGTMがないPull Requestがマージされたときや、リストに定義していない人がマージしたときに通知することもできるようです。

操作の制限ができるわけではなく、ルールに該当したときにダッシュボードに通知されるだけのようです。

30日間は無料で使えて、それ以降は有料プランとなります。
有料プランは3つあって、Small($10 / mon)、Medium($20 / mon)、Large($35 / mon) が選べます。
監視するリポジトリの数がプランによって違います。

Gitのコミッターを集計するGitFindCommitterをつくった

Gitのコミッターを集計するGitFindCommitterをつくったので紹介します。

GitFindCommitterとは

GitFindCommitterとは変更されたファイルを対象としてコミッターを探すツールです。
名前の通り、Gitのコミット履歴からコミッターを探します。
例えば、fixブランチでhoge.rbとfuga.rbを修正したとします。
GitFindCommitterはhoge.rbとfugue.rbを対象にコミッターを探します。

なぜつくったのか

チーム内でコードレビューを行っているのですが、なかなかレビューしてもらえないということが時々あります。
コードレビューの際に詳しいコミッターをレコメンドすればスムーズにレビューしてもらえるのではと考えました。
レビュアーのレコメンド機能はまだ作成中なのですが、そのモジュールの1つとしてGemに機能を切り出しました。

使い方

以下のコマンドでインストールします。

1
$ gem install git_find_committer

searchメソッドにリポジトリとブランチを指定すると、関連するファイルのコミッターを探してきます。

1
2
3
4
require 'git_find_committer'

GitFindCommitter.search(repo: 'balloonbros/sutekki', branch: 'add-ui')
=> [{:name=>"Shohei Yamasaki", :commit_count=>51}, {:name=>"keitakawamoto", :commit_count=>21}]

GitHub Enterpriseにも対応しており、GitHub Enterpriseで利用する場合は、以下の設定が必要です。

1
2
3
4
GitFindCommitter.configure do |c|
  c.url = "https://<hostname>"
  c.access_token = "<your 40 char token>"
end

便利なTips

集計対象のコミッターをフィルターすることができます。

1
2
3
GitFindCommitter.configure do |c|
  c.available_committer_names = %w(shoyan)
end

名前のみ配列で取得します。

1
2
GitFindCommitter.search(repo: 'balloonbros/sutekki', branch: 'add-ui).names(1)
=> ["Shohei Yamasaki"]

CircleCIでお手軽にCI環境をつくる

最近はCIプラットフォームが充実していて、Travice CI、Wercker、Droneなど様々なプラットフォームが開発されています。
最近はCircleCIを使っているのですが、なかなか便利です。

CircleCIの便利な点

CircleCIの便利な点は特別な設定をせずにテストコードさえあればCIができてしまうことです。
CircleCIにアカウントを作って、CIを行うリポジトリを設定すればOKです。
リポジトリにpushするとCIが実行されます。
ソースコードからbundle installなどの必要な前処理をしてくれるので、CIを行うための前準備的な設定が必要ありません。

私はgit_find_commiterphp-syntax-checkでCircleCIを使っています。

注意点

デフォルトのRubyのバージョンが古いので(マニュアルによるとUbuntu 12.04 and Ubuntu 14.04 build imagesのもの)、Ruby1.9から導入されたキーワード引数など比較的新しく導入された機構を使うと構文エラーが発生することがあります。
その場合はcircle.ymlファイルにRubyのバージョンを設定できます。

1
2
3
machine:
  ruby:
    version: 2.3.0

また、bundlerのバージョンでエラーが発生することがありました。
その場合は、以下のようにバージョンを指定することができます。

1
2
3
dependencies:
  pre:
    - gem install bundler -v 1.12.5

circle.ymlの構文についてはドキュメントを参考にしてください。

3年経ってスクラムをふりかえる

一時期のスクラムムーブメントは一体なんだったのか。
最近はスクラムマスターやファシリテーター、振り返りなどのスクラム用語をめっきりと聞かなくなった。

私のチームではスクラムの最後のプラクティスである朝会さえもなくなった。
結果、それで困っているかというとそんなことはない。

スクラムムーブメントを振り返ってみたいと思う。

スクラム黎明期

スクラムが流行り始めたのは2013年頃だったと思う。
次々と新しいスクラム本が出版され、私もSCRUM BOOT CAMP THE BOOKやアジャイルサムライを読んでスクラムの手法について勉強した。
会社ではスクラムの講習が開かれ、スクラムマスターやプロダクトオーナーを決めたりもした。

私のチームでは朝会と夕会を行い、カンバンでタスクを見える化し、プロジェクトの前には見積もりをチームで行い、定期的にふりかえりを行った。
スクラムマスターとプロダクトオーナーを決めて、スクラムのプラクティスを実践していた。

スクラム暗黒時代

うまくいっているように思われたスクラムだが、雲行きが怪しくなってきた。
スクラムのやり方に縛られ、チームの雰囲気がギクシャクしたものになってきたのだ。
定例のふりかえりでは発言が出ず、議論も深まることなく、時間の無駄に思えた。

スクラムとはなんだったのか

わずか3年でスクラムは姿を消してしまった。
誤解のないように言っておくが、スクラム自体がダメではないということである。
実際にスクラムを導入して成果をあげているチームもあるだろう。
実際によい時期もあったと思う。

スクラムとは手法であり、その内容は主に人同士のコミュニケーションを増やすためのものだ。
よって、人同士のコミュニケーションがうまくいかないと当然スクラムもうまくいかない。
また、コミュニケーションが増えるにあたりMTGなどの時間が増えてしまう問題がある。
そのコストは無視できるほど小さくない。

スクラムは悪くない。
しかし、スクラムは難しい。