Meet the Honeycomb Beeline for Ruby. Like our Beelines for Go and Node, it understands the common packages you’re using and automatically instruments them to send useful events to Honeycomb. Then once you’ve got a chance to explore your app’s behavior, you can add custom fields specific to your app with just one line of code.

You’ve always been able to get observability for your Ruby apps by instrumenting them with our SDK, affectionately known as libhoney. Unfortunately, instrumenting code you’ve already written is nobody’s favourite job. If only there were some way to automate the repetitive parts, so you could get instant insight into what your app is doing in production, and then focus your effort on augmenting that insight with the information that’s unique to your app!

Browser development tools - like Chrome Dev Tools - are vital for debugging client-side performance issues. However, server-side performance metrics have been outside the browser's reach. That changes with the Server Timing API. Supported by Chrome 65+, Firefox 59+, and more browsers, the Server Timing API defines a spec that enables a server to communicate performance metrics about the request-response cycle to the user agent.

For the past six months or so I've been working an NES emulator in Rust. As you might expect, I've learned a lot about rust, and even more about NES internals. But the experience has also changed the way I look at Ruby. Specifically, it's made me more than a little paranoid about methods that return nil.

Ruby is an opinionated language with inbuilt Ruby logging options that will serve the needs of small and basic applications. Whilst there are fewer alternatives to these than say, the JavaScript world, there are a handful, and in this post, I will highlight those that are active (based on age and commit activity) and help you figure out the options for logging your Ruby (and Rails applications).