In this post, we'll dive into ractors in Ruby, exploring how to build a ractor. You'll send and receive messages in ractors, and learn about shareable and unshareable objects. But first, let's define the actor model and ractors, and consider when you should use ractors.
In the first part of this two-part series on memory leaks, we looked at how Ruby manages memory and how Garbage Collection (GC) works. You might be able to afford powerful machines with more memory, and your app might restart often enough that your users don't notice, but memory usage matters. Allocation and Garbage Collection aren't free. If you have a leak, you spend more and more time on Garbage Collection instead of doing what you built your app to do.
A memory leak is an unintentional, uncontrolled, and unending increase in memory usage. No matter how small, eventually, a leak will cause your process to run out of memory and crash. Even if you periodically restart your app to avoid this crash (no judgment, I've done that!), you still suffer the performance implications of a memory leak.
RSpec provides tools that help you test the behavior of your Ruby objects. Join Abiodun Olowode for a tour of mocks, stubs, and spies—and learn how to use them in your Ruby projects!
A state machine can hold all possible states of something and the allowed transitions between these states. For example, the state machine for a door would have only two states (open and closed) and only two transitions (opening and closing). On the other hand, complex state machines can have several different states with hundreds of transitions between them.
In the Ruby programming language, exceptions are a common feature. About 30 different exception subclasses are defined in the Ruby standard library, some of which have their subclasses. Ruby's exception mechanism is quite strong, yet it is frequently misused. This article will go over how to use rescue exceptions in ruby and how to handle them.
What if you could write sloppy code and have Ruby fix it for you automatically? With RuboCop, you can! Of course, linters and auto-formatters have other benefits, even if your code is pristine. Join Ayooluwa Isaiah for a tour of RuboCop.
Ask any software engineer to review key portions of production code, and inevitably, they will point out three things that need to be refactored. So why does so much bad, brittle, or misunderstood code remain running in production? The answer is simple: engineers are afraid to touch it. Refactoring tasks get identified and added to the backlog, but rarely make it into the current sprint. There are numerous reasons for this.
If you define the same method on a class, a subclass, and a mixin, which one gets called first? Join Abiodun Olowode in an exploration of Ruby's object model!
Race conditions are hard to debug—especially when you don't know it's a race condition! This article looks at some common race conditions and the best solutions for handling each one.
