We recently upgraded our monolith application from Rails 6.0 to Rails 6.1. In this post we are going to give some insights on our workflow, from organizing such a milestone to actually delivering it without blocking an engineering team of more than 160 developers.
Having a thousand lines long controllers and/or models is not the right way to have sustainable applications or developers’ sanity. Let’s look at my solution for business logic in the Rails app.
I love JavaScript and React, and Python is extremely versatile, but every time I have the opportunity to build something in Ruby I feel joy. I'm constantly having "wow" moments where I'm reminded how easy it is to write it.
My aim in this article is to explain how fibers work from the point of view of a concurrent Ruby application written using Polyphony. I’ll give an overview of fibers as concurrency constructs, and discuss how Polyphony harnesses Ruby fibers in order to provide an idiomatic and performant solution for writing highly-concurrent Ruby apps.
If you want more value faster, take Many More Much Smaller Steps. Today I want to start laying this out for folks. This isn’t gonna happen in one thread, but let’s get started.