Rails introduced ActiveSupport::CurrentAttributes in version 5.2. Since its addition there has been a lot of discussion about it, with advocates both for and against it making valid points. The merits of ActiveSupport::CurrentAttributes actually depend heavily on how it is used.

Assume you have a large or mid-level organization where a repository is shared by multiple developers and they often push the code during a day. Let’s say, a developer was building a feature and was coding in a class/module that was being called by ten other places, coded by other developer(s). Let’s also assume that he has completed his feature, tested it and it’s ready for production and it is pushed to the repository and deployed. But he might not be aware of the fact that he has changed the code that was being called by several other modules, and now, let’s say if not all, 2 to 3 of the places are broken and no one knows about it until end-user hits the problem, report it, then the developers fix the code for those 2 to 3 places, this might end up causing problems in other places where it was being called, and you end up in total chaos and it also multiplies the cost of development.

Assume you have a large or mid-level organization where a repository is shared by multiple developers and they often push the code during a day. Let’s say, a developer was building a feature and was coding in a class/module that was being called by ten other places, coded by other developer(s). Let’s also assume that he has completed his feature, tested it and it’s ready for production and it is pushed to the repository and deployed. But he might not be aware of the fact that he has changed the code that was being called by several other modules, and now, let’s say if not all, 2 to 3 of the places are broken and no one knows about it until end-user hits the problem, report it, then the developers fix the code for those 2 to 3 places, this might end up causing problems in other places where it was being called, and you end up in total chaos and it also multiplies the cost of development.

Software development practices change with time and the practices that were used before are being continuously replaced by some new practices that we call “Best Practices”. In this article, we will discuss something similar that is related to refactoring the code in a Rails application following SRP (Single Responsibility Principle).

Just about every application inevitably needs to support file uploads of some kind. For example, a user might need to associate a profile picture with their bio, or notes may be more helpful if attachments could be attached, etc. Cloudinary can be a great choice, as it’s quick and easy to implement, and handles a lot of the heavy lifting for us, including integration with various cloud storage providers.

A common approach to modern Ruby on Rails development includes continuous integration checks, such as: