Here at Productive, we’re building an operating system for digital agencies. Because each agency is different, they need customization options for their workflows. If only there were a way to let them shape those models to their own needs.
Service objects and/or after_commit callbacks are ubiquitous in most real-world Rails applications. Whether it’s a good idea or not (ActiveRecord callbacks - I’m looking at you) is a different story, but one thing that is notoriously overlooked in the application design is reliability. And yes, the service objects are equally bad as after_commitcallbacks in that regard.
Long-running jobs can create maintenance and support nightmares as they run up against resource and time constraints. What if we could break them up—automatically—into smaller chunks of work?
Recently we discovered that we were wrong on computing lock key for acquiring advisory locks. It was already covered as an update to article about building read models, but we thought that telling the whole story behind the issue could be interesting for you.
For the past several weeks, I've been trying to fix a cranky spec in Karafka integrations suite, which in the end, lead me to become a Ruby on Rails micro-contributor and submitting similar fix to several other high-popularity projects from the Ruby ecosystem.
While the Rails Guides do a great job teaching developers how to take advantage of migrations, there is little guidance on the habits needed to keep an application’s migrations healthy over the long-term. This post will outline a few things I look for in well-maintained Rails projects.
Web responses are functions that turn input (the HTTP request) into output (the HTTP response). If that function has side effects that don't affect that return value, those side effects should almost always be done asynchronously (e.g., in a Sidekiq job).
After more than three years of work, Hanami 2.0 is here! With this release we enter a new phase of maturity for the framework, and open a new chapter for the Ruby community.