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.

About a decade ago, the Ruby programming language made a big splash in the software engineering industry thanks to the Ruby on Rails web framework. The terse and friendly syntax of Ruby and the “they thought of everything” feeling of Rails offered web startups the ability to move quickly and nimbly.

If you’re a Rails developer, then you’ve probably used Rails Logger on at least one occasion or another. Or maybe you have used it without even realizing, like when you run ‘rails server’ and it prints information to the terminal window, for example. Rails Logger provides us with a powerful way of debugging our applications and gives us an insight into understanding errors when they occur.

It’s the night before a big deadline, and just before you press the button to deploy, you notice a small but important bug! You open a terminal, type in the command to run the code—and all you see is a page of errors. It’s these palm-sweating moments that make us wonder whether we made the correct career decision. Configuring our systems and keeping them working is a struggle most of us deal with regularly. Ruby Version Manager (RVM) attempts to solve this problem.