state_machine

No mention of the rails:update rake task, which is a very valuable tool to get your boilerplate updated. I'm guessing at GitHub there is so much customization over the years that they wouldn't get much out of it, but it's still a valuable exercise to run through, and it's worthwhile to keep your boilerplate aligned as much as possible since it makes gems, documentation, and everything else more likely to align with shared community experience. Also, I want to add a big proviso to the lesson "Upstream your tooling instead of rolling your own". Historically in ruby, and now even moreso in node, the ease of pushing new packages and the trendiness of the language at times has led to a lot of churn and abandoning of packages. The trick is to include stable dependencies, and that requires quite a bit of experience and tea-leaf reading to do

That faster than linear maintenance growth is exactly why you need SMs. You don't need to test every scenario - only the critical positive/negative ones. If you abstract out all the generic SM logic you can have a neat source file per SM that contains only the allowed transition mappings or do something like https://github.com/pluginaweek/state_machine where the transitions are contained behind methods. My experience with recursion has been the reverse - the more recursion in use the less predictable the code behaves (at least initially) - but even just a little bit of SM usage can increase stability from the start and also forces you to think about all the states required.

Using (explicit) state machines in Rails is so easy, thanks to the gem of the same name(1), that we use them very often, with good results. I think that ease of setting them up and integrating them in whatever framework/language you use is a very important factor in their adoption. 1 current version: https://github.com/pluginaweek/state_machine 1a original unmaintained version: https://github.com/pluginaweek/state_machine