Troubleshooting is a critical skill for developers and DevOps. As our software grows more sophisticated, our problems do too. The cloud adds a new layer of complexity since we need to know how to find a problem that doesn’t occur locally, but has cropped up on a remote system.
Because Ruby is an object-oriented language, we tend to model the world as a set of objects. We say that two integers (x and y) are a Point, and a Line has two of them. While this approach is often useful, it has one big problem. It privileges one interpretation of the data over all others. It assumes that x, and y will always be a Point and that you'll never need them to act as a Cell or Vector. What happens when you do need a Cell? Well, Point owns the data. So you add a your cell methods to Point.
Using the right Ruby interpreter to run your programs can make all the difference. Unfortunately, it can be tough to find resources about different Ruby interpreter options, or about how to choose the right one.
There are many things to praise about the Ruby language: adherence to the object orientation paradigm, simplicity, elegance, and powerful meta-programming capabilities. Unfortunately, performance isn’t top of mind when people think about the many qualities of the language.
Around 1996, when I attended my first programming classes, C++ was the language of choice if you wanted to have a job in this industry. The Internet was young and not as widely available as it is now. Ruby and Python were still in their infancy. Now, in 2018, both have evolved and matured well enough to be in the top 10 most in-demand programming languages. In this article, I’m going to highlight features and contrasts between Python and Ruby.
As reported on Issue #228, if scout_apm is disabled on a node via the configuration monitor = false, we don't intend to install any instruments, but a few snuck in anyway. Since the rest of the agent isn't running, they (slowly but steadily) built up recorded info, but didn't purge it, causing a slow memory leak that became clear over the course of a week or two. We've stopped the offending instruments from installing themselves when Scout is disabled.
When Ruby support on AWS Lambda was announced yesterday, I was so excited about it that I had to try it right away. We've been using Lambda for a while at Honeybadger, and I have longed to be able to write our functions in Ruby. Having played with the new Ruby support for a few hours, I'm feeling confident we'll be spending less time with Node, Go, and Python. :)
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).
Our new RubyGems.org public dataset is now available — use it to analyze global download traffic of all gems hosted on RubyGems!
Last week we released version 4.0.0 of the honeybadger Ruby gem. This release includes a long-awaited feature which makes it even easier to customize your error reports before they are sent to Honeybadger. We also did some much-needed refactoring, and made a few removals and deprecations for good measure. Don't worry, though—most of the API remains unchanged, so upgrading should be a relatively painless process for most users.
