BotはBotと会話するべきかどうか？
このエントリは、 Mobb/Repp Advent Calendar の十三日目です
BotとBotの関係性
突然ですが、このBotは無限ループを引き起こします。
require 'mobb'
on 'Yo' do
'Yo'
end
Yoという発言を受け取り、Yoと自分も発言すると、自分の発言を拾って更にYoが無限にYoするからです。Mobbでは、これを防ぐために ignore_bot というコンディションフィルタを用意しています。
require 'mobb'
on 'Yo', ignore_bot: true do
'Yo'
end
ignore_botコンディションを利用することによって、このonのブロックはBotに反応しなくなります。したがって、自分自身のYoの発言に自分で反応することもなくなります。（もっとも、これはReppハンドラが正しく人間とBotのアカウントを判断して情報を送ってくれるときに限るので、例えばBotと人間の区別がつかないサービスの場合はもちろん機能しません）
チュートリアルを紹介したエントリでも言及しましたが、この ignore_bot というフィルタは、今後デフォルトで機能するように変わる予定です。すなわち、次のバージョンのMobbでは、最初のコードと次のコードが全く等価になるということです。そのかわりに、次のバージョンからは react_to_bot と include_myself コンディションが用意されます。このコンディションをtrueに設定すると、BotはBotのメッセージに反応するようになります。
なぜこのような変更が入るかというと、BotとBotの関係性と安全性の問題があるからです。
Botフレームワークに限らず多くのライブラリは、記述の簡単さと、自由さと、安全性を天秤にかけることになります。Mobbは、その中でも簡単さと自由さに重点を置いていて、安全性に関しては優先度を下げていました（ここでいう安全性とは、ライブラリのセキュリティではなく、問題を起こしそうな記述を未然に防いでくれるかどうかということです）。そのため、Botが発したメッセージに関しても、ユーザーは特に何も考えることなくアクセスが可能で、Botに反応したくない場合はそれを明示的にユーザーが拒否すればいい、デフォルトでBotが可能な限り多くの情報に触れられるようにしたほうが良いという考え方で始まりました。しかしその一方で、この方針は無限ループを容易に引き起こしたり、無意味な発言を繰り返したりという行儀の良くない行動に関しても、記述するユーザーに責任を求めることになりました。
Mobbの安全性への姿勢は、リリース後に様々な人に触れてもらう中で、必要以上に軽視されているということが指摘されました。そのため、Mobbは次のバージョンから、いたずらに無限ループを起こしたり、他のBotにちょっかいを出す行儀の悪い行為をデフォルトで禁止し、そうしたい場合はユーザーに明示的に指示を求めるように変更することになりました。
次のバージョンからは、Mobbは自分を含む全てのBotの発言をデフォルトで無視します。これは、Botの安全性を高めるためです。そして、Botの発言を意図的に取り込みたい場合は、次のような記述が必要になります。
require 'mobb'
on 'Yo', react_to_bot: true do
'Yo'
end
on 'Yo', react_to_bot: true, include_myself: true do
'YoYo'
end
react_to_botコンディションは、自身を含めない他のすべてのBotの発言に対して反応するようになるコンディションです。そして、 include_myself コンディションは、自分自身の発言に対しても反応するようにするコンディションです。
ほぼすべてのケースにおいて、Botの作成者は react_to_bot コンディションを利用することでやりたいことがすべて実現すると思います。 include_myself は、昨日のエントリで紹介した chain/trigger 構文によって、自分自身への反応をする必要が無いからです。しかし、どうしてもすべてのメッセージに目を通したいというユーザー（例えば、自身を含む全ての発言を記録して、自身は何もしないBotを作りたいなど）のために、自分以外へのBotの反応、自分を含めたすべてのBotへの反応、という二段階の安全策を用意します。
記述性、自由度、安全性でバランスの取れた設計に
次のバージョンで追加されるコンディションで、Mobbは記述性をわずかに失い、安全性を大きく手に入れます。これは、必要なトレードオフです。しかし、Mobbの基本的な方針として、記述性と自由度を重視していく姿勢は変わりません。
次のバージョンのMobbは、年内にリリース予定です。よろしくおねがいします。
Mobbのメソッド呼び出しをチェーンする、 chain/trigger シンタックス
このエントリは、 Mobb/Repp Advent Calendar の十二日目です
Mobbにできないこと
これは、Mobb/Reppの未来の実装の話です。
Mobb（というよりも、Repp)の最大の特徴に、「発言を受け取り、返答を戻り値で返す」というシンプルな記述があります。これはとても強力でシンプルなルールですが、その一方でいくつか困ったことも起こります。
たとえば、Botにあるとても時間のかかる作業がさせたいとします。何も考えずに実装すると、その作業の起動トリガーを発言し、Mobbがそれを受け取り作業をし、完了したという文字列を返します。これは一見何もおかしなことは無いように見えますが、一つ大きな問題を抱えています。それは、時間のかかる作業の間、Botは無言で作業をこなしていて、その作業を起動させた人は、Botがちゃんと仕事をしているのか、それとも無言で死んだのかを区別する方法がありません。
次に、少し人間に優しい実装をしてみましょう。無言で死ぬのではなく、何かしらのエラーが発生した場合は、それを戻り値としてサービスに返せば、少なくとも何かエラーが発生したことはわかります。エラーメッセージの返し方によっては、何が原因で失敗したのかという細かい情報も得られるでしょう。これで概ね困ることは無いように思いますが、本当にそうでしょうか？ この実装では、Botが作業を開始する指示を正しく受け取ってくれたのかどうかがわからないという問題が残っていませんか？
最後に、完全に人に優しい実装を考えてみましょう。作業の起動トリガーとなる発言を受けると、Botは即座に「作業を開始します」と返答します。その後、時間のかかる作業をやりながら、適宜「いまXXまで作業が終わりました」と教えてくれれば、ものすごく優しくないでしょうか？ 少なくとも、コマンドを間違えてBotが起動してくれなかった場合などにはすぐ異常を検知できますし、何よりBotに愛着がわきます。
ところが、現状のMobb/Reppの構成では、このような適宜返事を返すBotと言うものを作ることが出来ません。なぜなら、最初に書いたとおり、Mobb/Reppはメソッドの戻り値がサービスの発言となり、途中経過で何かしらのアクションをすることが出来ないからです。そして、Reppはインターフェイスというその思想から、Mobb側にサービスに対してアクションをする方法は完全に秘匿されており、何もすることはできません。これは、よくあるBotフレームワークが、処理の途中で適宜サービスへのアクセスができることと大きな違いです。
しかし、Mobb/Reppは秒でクソボットを作れるフレームワークであると同時に、快適なBotを人々に提供することも軽視しているわけではありません。それでは、この問題を解決するにはどうすればいいでしょうか？
chain/trigger
Rubyを使って秒でBotを作るなら、秒でRedisだって使えなきゃ、やっぱり話にならないですよね？
このエントリは、 Mobb/Repp Advent Calendar の十一日目です
mobb-redis
昨日のエントリでは、MobbでActiveRecordを利用する方法を紹介して、Sinatraの資産をMobbが継承できるという話をしました。そして今日はRedisです。こっちは本当に秒でいけます。
https://github.com/kinoppyd/mobb-redis
まず、検証用のRedisを立てましょう。今ならDockerで秒です。
docker pull redis
docker run --rm -p 6379:6379 redis
次に、mobb-redisをインストールします。例ではBundlerを使います。
# frozen_string_literal: true
source "https://rubygems.org"
gem "mobb"
gem "mobb-redis"
最後にアプリケーションを書きます。
require 'mobb'
require 'mobb-redis'
register Mobb::Cache
on 'hello' do
settings.cache.fetch('great') { "hello world #{Time.now}" }
end
はい、秒ですね。起動して動作を見てみましょう。
bundle exec ruby app.rb
== Mobb (v0.4.0) is in da house with Shell. Make some noise!
hello
hello world 2018-12-11 01:36:16 +0900
hello
hello world 2018-12-11 01:36:16 +0900
このように、返答の中の時間が変化していないので、Redisを経由していることがわかります。
redis-sinatra
Rubyを使って秒でBotを作るなら、秒でActiveRecord使えなきゃ話にならないですよね？
このエントリは、 Mobb/Repp Advent Calendar 2018 の十日目です
ActiveRecord
ここ数日書いているエントリで、Mobbがいかに秒でBotを作れるすごいやつかというのは伝わったかと思います。しかし、世の中には秒で複雑で素敵なBotのアイディアが思い浮かぶ人もいます。そして、そういう人の多くは「いやいや、いくら秒でロジック書けても、DB使えないと話にならんでしょ」という人もいます。
そうです、Botのロジックは会話的なものが多いため、状態を記録したりデータを保持したりという行動を行いたいケースが非常に多いです。それでは、DBを使いましょう。RubyでDBといえば、ActiveRecordですね。ActiveRecord、使いたくないですか？
Mobbは、秒でBotを作るエンジニアを本気で応援するフレームワークです。当然、ActiveRecordも使えなくては話になりません。
安心してください、使えますActiveRecord。たった一つのgemを追加するだけで。
https://github.com/kinoppyd/mobb-activerecord
Usage
Mobb, test, spec
このエントリは、 Mobb/Repp Advent Calender の八日目です
最初にはっきり言っておくこと
このエントリは読まなくていい
Mobbのテスト
無い。現状、存在が無い。皆無。虚無。無。無って漢字に飽きてきた？ じゃあ観測できないって言いかえる。
Mobbをテストするということ
Mobbをテストするということは簡単です。簡単ではないですが、書けます。なぜなら、MobbはSinatraのコピーとも言えるプロダクトなので、テストもコピーしてしまえば言いわけです。
ただ、現状そうもいっていない。私の時間ややる気の大小は感情的問題なので、定量的な判断からは除いておくと、Mobbの開発はあまり活発とは言えません。なので、単に書いていないだけです。これに関しては激しく切腹という言葉が脳裏に浮かびつつもどうにもならない問題で、時間とキーボードのストロークが解決してくれると思っています。どうしてMobbそのもののテストが無いのかという問題に立ち向かうとき、あなたはテストを書きましょう、私は怠けてしまったのです。としか言えません。
Mobbアプリケーションをテストするということ
Mobbアプリケーションをテストするということは、ほぼそのままの意味でReppアプリケーションをテストするということです。なぜなら、MobbはReppアプリケーションを作成するためのDLSであるからです。これをわかりやすく言うと、SinatraのテストをするということはRackアプリケーションをテストするということ、と同義です。
さて、Sinatraのテストはどう書くのか？ 正確に言うと、Rackアプリケーションのテストはどう書くのか？ それは、Rack::Testというものを使います。
https://github.com/rack-test/rack-test
これは、シンプルな意味でRackアプリケーションをテストするためのヘルパー群の集まりです。Rspecやtest-unitなどの各種テストスイーツを利用できます。
同じように、RackにもRack::Testというモジュールを追加する予定があります。現在鋭意製作中ですが、概ねRack::Testと似たような構成になると思っています。
Rack::Testは、内側でセッション情報などいろいろなものを頑張って扱っていますが、幸いMobb/Repp構成においてセッション情報とかいうものはあまり関係無かったりするので、Rack::Testよりは多少シンプルになるのではないでしょうか。
最後に
ネタが切れてきた
Reppのインターフェイス
この記事は Mobb/Repp Advent Calendar の7日目です
Reppのインターフェイス
少し前のエントリで、Reppはインターフェイスだと解説しましたが、実はそのインターフェイスの定義をきちんと書いたドキュメントは存在しません。それは何故かと言うと、まだインターフェイスをどのように固めれば柔軟に今後対応していけるかという確信が、書いている本人である私にないからです。現状の仮実装として、Slackを事実上の対象サービスとして想定した記述ができるように、次のように実装されています。
-
environmentのハッシュを引数に一つ受け取るcallメソッドが実装されている
-
2つの要素からなる配列を返す。サービスに投稿する文字列が1つ目の要素、各サービスごとにオプショナルに解釈してほしい内容をハッシュで2つめの要素に入れる
ReppはRackの模倣をして作られた、各種サービスとBotフレームワークとの間をつなぐ取り決めですが、Rackの取り扱うHTTP（正確にはWebサーバー）の世界とは違い、Botが接続するSlackやShellやChatWorkやLINEや、あるいはHTTPかもしれないサービスとの接続はその形式が多種多様に渡り、抽象化するとどのようにまとまるのかをうまく調整することが難しいのです。
たとえば、SlackにはAttachmentsというチャットの発言とは別にチャットの内容を装飾するための取り決めがありますが、それは他のサービスにはありません。しかし、Reppとしては存在したりしなかったりする内容に関してもきちんと橋渡しをする必要があります。
Mobbの実装とSinatraの実装の比較
このエントリは、Mobb/Repp Advent Calendar の六日目です
Mobbの実装の元ネタ
これまで何度も出てきましたが、Mobbの実装はSinatraから非常に強烈な影響を受けています。しかし、はっきりと宣言しておきますが、強烈な影響を受けているなんていう生易しいものではありません。Mobbのコードは、ほとんどSinatraをコピペして作られていると言っても過言ではありません。
Mobbの文法やDLSのIFは、ほぼSinatraの形を踏襲しています。そしてその形を受け継ぐのであれば、どうやってもSinatraと同じコードが頻出することが最適解になっていきます。なにせSinatraは10年以上の歴史があるフレームワークで、その歴史の中でコードが無駄なく洗練され続け、その後追いをするならば必然的に同じコードが頻出することになります。なぜなら、Sinatraはわずか2000行ほどのコードで構成され、どうしてもそれ以上コードを削ることが難しいためです。
Sinatraと全く同じコード
昨日のエントリでも書きましたが、helpers/registerは全く同じコードが出現します。
def helpers(*extensions, &block)
class_eval(&block) if block_given?
include(*extensions) if extensions.any?
end
def register(*extensions, &block)
extensions << Module.new(&block) if block_given?
@extensions += extensions
extensions.each do |extension|
extend extension
extension.registered(self) if extension.respond_to?(:registered)
end
end
この2つは本当に全く同じコードを使っています。そのおかげで、Sinatraの資産をそのまま流用できる箇所でもあります。例えば、mobb-activerecordなどです。
他にも、before/afterフィルタや、invokeメソッド、デバッグ用にスタックトレースを追跡するコードや、デリゲータのコードなど、全く同じものが出てくる箇所がいくつもあります。
Mobbの機能拡張を実現するhelpersとregister
この記事は Mobb/Repp Advent Calendar の五日目です
Mobbの機能拡張
これまで見てきたように、MobbにはSinatraとほぼ同じ仕組みが多数存在します。そして今日紹介するhelpers/registerメソッドも、Sinatra由来の機能です。これら2つのメソッドは、Sinatraと全く同じコードが書かれているので、挙動も全く同じです。
helpers
helpersメソッドは、トップレベルモード(require ‘mobb’をしてそのままロジックを書き始めるケース）では暗黙的に作成されるMobbのアプリケーションクラスを、モジュラーモード(require ‘mobb/base’ して自分でクラスを定義するケース）ではhelpersが呼び出されたクラスをそれぞれコンテキストとして、渡されたブロックをclass_evalで実行します。ブロックではなくモジュールを渡した場合は、そのモジュールがincludeされます。
require 'mobb'
def hoge
'hoge'
end
on 'hello' do
hoge
end
require 'mobb/base'
class Bot < Mobb::Base
helpers do
def hoge
'hoge'
end
end
on 'hello' do
hoge
end
end
Bot.run!
モジュラーモードでは、そもそもhelpersの中で定義しようがクラスの中で定義しようが、クラスのインスタンスメソッドとして定義されるのであまり違いはありません。ですが、トップレベルモードの場合、Rubyのmainクラスで定義したメソッドはObjectのプライベートメソッドとして定義されるので、いろいろなものを汚染しかねません。そのため、暗黙的に作られるMobbアプリケーションのクラスに、helpersを使って直接定義を行います。
https://docs.ruby-lang.org/ja/latest/class/main.html
やっていることは結局の所include呼び出しとあまり変わりませんが、ブロックを渡せるところが軽量でいいと思います。
helpersメソッドの中身は、Mobb::Baseを継承したアプリケーションを拡張しています。
MobbのCron
このエントリは、Mobb/Repp Advent Calendar の四日目です
Cron Job
Mobbには、Botのための定期実行の仕組みが備わっています。MobbはSinatraをベースとしたBotフレームワークですが、完全にSinatraと同じことをするわけにはいきません。その一つが、Cronです。
Botの重要な役割の一つとして、定期実行が存在します。これはWebアプリケーションという世界には存在しない概念ですが、Botには必ず備わっていて欲しい機能です。例えば、BotをSlackに接続して、毎日決まった時刻に備忘のためのメンションをくれる、とかは重要な機能です。
重要な機能である一方、Webアプリケーションの世界に存在しないこの機能をどう扱おうかという考えはなかなか難しかったので、詳細はこのエントリを読んでください。
http://tolarian-academy.net/mobb-0-3-out-now/
Mobbでは、Cron実行のためにそのままCron Syntaxを採用しました。それに加えて、より人間にわかりやすいCron記述のために、WheneverというGemのパーサーも利用しています。CronとWheneverのどちらが簡単かは人によりますが、多くの人はWheneverのシンタックスのほうが親しみがあると思います。
https://github.com/javan/whenever
詳細はWheneverのドキュメントを参考にしていただければと思いますが、簡単な例をいくつかあげておきます。
Mobbの基本的な書き方
このエントリは、Mobb/Repp Advent Calendar の三日目です
Mobbの基本的な機能
Mobb/Reppがなんなのかは昨日までのエントリで書いたので、今回はMobbで書ける基本的な機能を紹介します。
以下に上げるのは、Mobbのほとんどすべての機能なので、これを知っていれば秒でBotが作れます！
特定の文字列との完全マッチ
receive 'テクテクテクテク' do
# テクテクテクテク という発言があったらこのブロックに入る
end
on 'ポッポポッポハトポッポ' do
# on は receive のエイリアス
end