When developing new applications, it’s typical to run into a variety of competitors with similar goals. This is one reason why it is not enough to create an application without ways to monitor and manage it. In fact, usually market leaders emerge rather quickly. So who are these market leaders?
Logging provides critical value to applications with insight to usage, stats, and metrics, and saves us when debugging a problem. But we often leave logging to poorly implemented afterthoughts. So what should we know to get the most out of our logging? We will look at the Rails logger and some logging best practices.
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).
