Software systems can be quite prone to error conditions. Systems that involve user interaction are more vulnerable to exceptions as they attract errors at multiple fronts. Errors can take many forms - syntactical errors, network errors, form input errors, invalid authentication errors etc. If not accounted for, these can affect user experience and can even manifest as security loopholes, enabling attackers to compromise the system.

Skylight 4.2.0 now includes GraphQL instrumentation! To use it, upgrade the Skylight gem and add 'graphql' to your probes list. We support graphql-ruby versions >= 1.7.

Configuring your Rails app via environment variables works well, but sometimes you want to be able to update your configuration on the fly. Here's a way to update your app's environment using SSM Parameter Store.

Instrumenting the performance of custom code (the code you write, not the libraries you require) in web apps has been a thorn in my side for years. Yes, we have a custom instrumentation API, but raise your hand if you enjoy sprinkling your code with this? Anyone? Having a custom code instrumentation blackhole doesn't matter if your app spends almost all of its time in common libraries that Scout instruments by default (ex: ActiveRecord, Redis, View Rendering, and HTTP calls).

The GitHub Readme describes Falcon as, "... *a multi-process, multi-fiber rack-compatible HTTP server ... Each request is executed within a lightweight fiber and can block on up-stream requests without stalling the entire server process."* The gist: Falcon aims to increase throughput of web applications by using Ruby’s Fibers to be able to continue serving requests while other requests are waiting on IO (ActiveRecord queries, network requests, file read/write, etc).

One of the joys of using the Ruby language is the many different ways that you can solve the same problem, it’s a very expressive language with a rich set of libraries. But how do we know which is the best, most efficient, use of the language? When we are talking about algorithms which are critical to the performance of your application, understanding the most efficient approach to take is essential.

Incidents happen all the time because of bad code deploys. You write some code that passes code review, it then is automatically shipped to production after a test suite passes, and BAM, an outage happens. This fairly common occurrence has ways to prevent it entirely. Using some simple ideas we can defend ourselves from the hidden mistakes that code reviews and chaos engineering sometimes won’t catch.

We are excited to announce a new version of the Honeycomb Beeline for Ruby! This new version solidifies our Ruby support, providing out-of-the-box automatic instrumentation for additional frameworks and enhanced support for our currently supported frameworks. The goods: For Rails applications we now have a generator that creates a configuration file for the Beeline. This generates a configuration file in config/initializers/honeycomb.rb with the Beeline pre-configured for your Rails application:

Ruby, like most other modern, high-level programming languages, doesn’t force you to manage memory. This feature is called garbage collection, or GC, and you get it for free in Ruby. You can write tons of Ruby code and never give a second thought to the fact that under the covers, Ruby is doing a bang-up job of allocating and freeing memory for your code to use. But it certainly couldn’t hurt to learn something about how Ruby garbage collection works.