In the Ruby programming language, there are many libraries that can be used to manage business or application logic. Some of the popular ones are dry-rb (framework-agnostic) and ActiveInteraction (used within the Rails framework). The strengths and weaknesses of these libraries are explored in more detail on another article.
While these are great libraries to use and provide enormous benefits to your code architecture, some consideration is needed before using them:
Rails is an awesome web application framework and it used by a lot of companies to ship features fast and iterate quickly. Developers also love the ecosystem and the stability that the framework offers. But it is not without its criticisms. One of them, which I experienced in my professional work as well, is its lack of direction on how to structure business logic.
The introduction of Concerns provided another layer where this logic can be extracted from models and controllers, but I think that this is still lacking, especially as the complexity of the application grows over time.
During the course of your software development career, you get to use different flavors and versions of databases, such as PostgreSQL. Newer projects and applications often use the latest versions while older projects tend to lag behind in upgrading their stack.
Consequently you need to be able to run different versions of the database in your machine, and be able to switch easily between versions. The alternatives, such as re-installing the desired version when needed or using a different machine for different projects, isn’t practical most of the time.
Upgrading your libraries and dependencies regularly is a must if you want to keep up with application security and performance. Sometimes though, things do not go as planned and part of your code breaks because of the upgrade.
This happened when we upgraded our Ruby version from 2.7 to 3.0. Suddenly, all of our requests to Amazon’s API started failing. As this was a critical part of the business, we had to investigate the root cause of the problem.
Recently, I came across a problem where I need to store values inside a nested Hash. The catch is, the keys within that Hash are unknown, and each key can also have a nested Hash within. In addition to that, the final value of this nested Hash is an Integer that needs to be accumulated.
In Ruby, we need to define the Hash keys first before we can get or modify the value. If you try and access a key that does not exist yet, it will return nil. When you try and access another key within that non-existent key, it raises an exception: