概要
ステートマシンを実装するためのgemを調査するのに結構時間使ったので自分用メモ。
比較表
注：データは2016/12/06時点
| 比較項目 | state_machines | aasm |
|---|---|---|
| レポジトリのURL | https://github.com/state-machines/state_machines | https://github.com/aasm/aasm |
| スター数 | 268 | 2607 |
| 直近のコミット | １ヶ月前 | ２日前 |
| isitmaintained.comによるイシューの解決状況 | 良い(http://isitmaintained.com/project/state-machines/state_machines) | あまり良くない(http://isitmaintained.com/project/aasm/aasm) |
| 提供する機能 | 初期値・コールバック・ネームスペース・aasmと同じシンタックスのサポート・条件付きトランジション・ActiveRecord連携（公式外部gem）・変更ログ（公式外部gem） | 初期値・コールバック・条件付きトランジション・ActiveRecord連携（Enum含む）・クラス内での複数ステートマシンのサポート・定数の自動生成・イベントのインスペクション・RSpec用マッチャー |
| 基本シンタックス | state_machine :state { state :stopped } |
aasm { state :stopped } |
| stateシンタックス | state :stopped { def speed; 0; end } |
state :stopped |
| eventシンタックス | event :start { transition stopped: :started } |
event :start { transitions :from => :stopped, :to => :started } |
備考
state_machinesはソースコードを残してレポジトリを再構築している（最初のコミットが"Initial import"であり、旧state_machineのソースコードをコピーしたと思われる）ため、コミット数が非常に少ない（２桁）。
雑感
あまり違いがわからない。
aasmのRSpecサポートは個人的には大きいが、一方でstate_machinesのステート変更ログ機能は重要になるケースがあると思われる（そもそも、ステートマシンを導入する時点でそこにはある程度重要なビジネスロジックが含まれる可能性が高いので、その記録も必要になる可能性は高い）。どちらも自分で実装できるといえばできるけど。
シンタックスは明確にstate_machinesのほうが優れているし、互換性のある書き方もできるのはうれしい。逆に言うと、aasmからstate_machinesへの乗り換えは逆より簡単であると思われる。