Rails Best Practices
After many years of rails developing I have finally found satisfying solution to implement enums in rails.
We always have multiple processes for rails websites, if any of them crashed, your website failed, so it would be better to monitor all of the processes and automatically restart crashed processes.
Recently we saw rails exposed some security issues, github was attacked, rubygems.org was crashed, they all remind us we must pay more attentions on our rails projects.
Rails is integrated with sprockets from 3.1, which gives you the power to pre-process, compress and minify your assets. It's awesome, but it slows down deployment a lot.implemented
The "save" method on ActiveRecord returns "false" and does nothing if the record is invalid. You should always check the return value, otherwise you may inadvertently not save the record. If you think the record can never be invalid, or don't want to check the return value, use "save!"implemented
In C# or Java, you can `catch (Exception)` to rescue all exception types. However, in Ruby you should almost never catch `Exception`, but only catch `StandardError`.implemented
Your capistrano deploy.rb file might become complicated with the growth of your application, contain more and more cap tasks, it would be better to split these tasks into different files according to the functionalities, which makes it easy to maintain, and they are more likely to be reused in the future.
Sometimes you may face the situation that some features will be released, but you are not sure if it is friendly to end user, or if it will lead to performance issues, at that time you should use what we called "feature flags"
Most developers use AR callbacks after_create/after_update/after_destroy to generate background job, expire cache, etc., but they don't realize these callbacks are still wrapped in database transaction, they probably got unexpected errors on production servers.