Memory leaks are a pain for gem users. They are hard to track and can lead to expensive infrastructure costs. Memory leaks within a C extension are even worse. You'll see a lot of tools and articles about finding leaks in Ruby. However, you don't have the same access to internals in C. A naive usage of rb_funcall can cause memory leaks: it's much better to use rb_protect instead. So, if you are a C extension writer, please read on for the sake of developers who will use your gem. Let's get started!

Instrumentation is an essential part of monitoring and operating an application, especially for apps heavily used in production. Even in today's everchanging technology landscape, visibility and observability still challenge developers and system administrators. Metrics and logging are essential for monitoring and operating an application. Metrics measure an application's performance and system health, while logging records system health and application state.

In the previous part of this series, we optimized our Lambda function. However, our API is open to the public — anyone with the URL can use it and get a response. In this take, we are going to secure our API using a tool called Amazon Cognito. This will only allow authenticated users access to our endpoints. Ready? Let’s go!

Ruby is a wonderful language, made for humans first and machines second. It is easy to read and write. There are plenty of ways to write anything, and you can often guess its standard library by typing the name of the method you would have chosen yourself. Because of this, Ruby's arguments are very flexible, which lets us express our APIs very clearly. But this comes with a drawback: Ruby is quite hard to parse for C extension developers!

As web developers, we tend to approach problems with traditional low-risk solutions. When all you have is a hammer, everything looks like a nail. When you need complex input from the user, you use a form and JSON representation (even if, in retrospect, it is not the most efficient solution). In this post, we'll take a different approach. We'll leverage some tooling to create a business language that extends the functionality of a Rails application. Let's get started!

In part one of this series, the debugging tools we used — Elixir's IO.inspect/2, IEx.pry, and dbg/2 — required us to insert changes into code directly. Outside the development environment, you probably won't (and shouldn't) have access to your code. Erlang has a few tools to debug code at runtime: :debugger, :dbg.tracer, and :observer. First, let's look at the:debugger, a graphical debugging tool. Let's get going!