概要

ステートマシンを実装するための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への乗り換えは逆より簡単であると思われる。