エージェントの実装Agentのサブクラスを作ります。メソッドで受け取ったアイテムを処理して指定先のゲートに新たなアイテムを送る処理を書きます。ここで制御(起動・停止)します。室温が摂氏17度以下になったらエアコンをオンにします。受け取ると次のゲートに送り、自身は終了するという仕様の実装を意識させないためです。特徴のまとめ複雑なデーモンやバッチプログラムに向いている。同じエージェントを並列で動かすようなことは想定していないので、大量に捌く処理には向いてない。メインプログラムで登場するゲートとエージェントと、アイテムのタスクフローが定義できる。そのためこれだけで全体が把握できる。スレッドベースのように重くならない。ゲートの置き換えが容易なので、エージェントのユニットテストが書きやすく、部分的な実行の確認もしやすい。予想される疑問と答え参照先サービスは全部ゲートになるのか?Noです。ゲート間は一方通行に限定されます。エージェントはその先を知らない。リクエストを投げて、それに対するレスポンスを得ることはできません。往復ではなく、ループにすることは可能ですが、ステートレスなのでどの送り出したアイテム(リクエスト)に対してのレスポンスかはわからないのです。ゲートは、エージェントにとってトリガーとなるものを出す部分と成果を送る部分になります。一連のフローが終わったら時にキッカーに完了を通知するには?キューシステムはタスクが完了したら完了通知を送る必要が往往にあります。いった場合は、アイテムにそのコンテキストを持たせてフローに流して、最後のゲートが完了通知を送る役割を担うようにします。ロガーはゲートにすべきか?ログがアウトプットそのものになるならゲートにすべきです。ジョイントするものに置き換えて、そこからログ解析サービスに投げるといった修正も容易にできます。ゲートにどこまでロジックを含めていいのか?ゲートはできる限りシンプルな方が良いです。エージェントはテストしやすいように設計しますが、ゲートそのものにロジックを入れてしまうと入出力先を付け替えてテストできなくなります。プロジェクト共通のロジックでそれがフォーマット程度であれば、ゲートに実装してもいいでしょう。複雑ならばそれ用のエージェントを作ってゲートの前に置き、ジョイントで繋げるだけです。興味を持っていただけたら幸いです。onlyになったときの対応方法RubyでYARD定義を使って実行時にメソッド引数と戻り値の型チェックを試みる構造化ログのススメとRuby向けロガーOugaiを作った理由はてなブログをはじめよう!tilfinさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。