本体のコードにも、サンプルとして標準入出力用のアダプタが同梱されている。プラグインを開発するときのデバッグ用途などで重宝することが多い。本体から要求があればサービスに対してメッセージを投稿するというものである。メソッドが呼ばれたときにはサービスに対してメッセージを投稿する、というようなものである。Handler通信関係の低レイヤとのインターフェースを抽象したものがアダプタであったのに対して、発言のパターンを検査して処理を行うようなルール集合を定義するのがハンドラである。「ruboty」で検索すると大量に出てくる。time.rubygems.orgハンドラの設計は、正規表現とメソッド名の組をルールとして登録してもらって、そのパターンに一致したときに指定されたメソッドを実行する、というものである。メッセージを受け取ると、登録された順にルールに一致するものがないか走査していって、一致するものがあれば対応する処理を実行する。追加されたりしていった。して提供されることが想定されている。全て読み込むようになっている。書くだけでプラグインを追加できる。接続に使う認証情報など、各プラグインに必要な設定は、環境変数を介して与えられるようになっている。「設定を環境変数に格納する」に従い、環境変数を利用することにしている。apps.12factor.netBrainアダプタとハンドラ以外に、永続化を行うバックエンドを差し替えるための、ブレインと呼ばれる類のプラグインも存在する。バックエンドにしてデータを永続化するためのプラグインである。アクセストークンとの対応関係を記憶させておく必要がある。プロセスが終了するとそこでデータが揮発してしまう。バックエンドにしたプラグインをつくることは可能である。いうリポジトリを公開している。デプロイできる仕組みになっている。したリポジトリになっている。見ると、利用されているプラグインも調べられる。つくれるようになっている。出勤」で出勤記録を残せるようになっている。使われている様子が可視化できる。代わりにこれを利用することもできる。代わりにこれを利用することもできる。アカウントをつくらなくても利用できるというメリットがある。使って実現する方が良い。改善するならどうするかということについて考えたい。用意することができる。実現することも可能である。表現力の幅を広げられる。モバイルアプリからの利用では、テキストを入力するよりもボタンを押下する方が楽なケースが多い。利用した実装は提供していない。ベースで動作する実装にした方が良いかもしれない。組み合わせて実装する方法も考えられる。して実装を切り離すような設計も考えられる。システムも面白いかもしれない。行っているような類の仕事は難しくなる。エゴサーチして検索結果を表示してもらうというようなことは難しい。そのため、サーバレスなシステムベースで実装するときには、この手の処理の実現方法を別途用意してあげる必要がある。関係で他に参考になりそうな記事を挙げておく。製のChatterbotをつくった。Herokuにデプロイすれば無料で動く。界の知見を共有します。これをSlackというチャットサービスで利用していた...r7kamura.hatenablog.com。