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.
We recently removed webpacker from our Rails 5 application. While it was a great way to bootstrap a new Rails app with a significant amount of Javascript we encountered some serious performance problems that we felt really impacted our productivity. We build our application images after every git push and we’d like to be able to deploy them quickly.
Ruby on Rails makes writing web applications a pleasure. It’s a powerful and intuitive platform, built on an equally powerful and intuitive language. But that doesn’t mean it’s not worth taking the time to check your code for bottlenecks and performance problems before you ship. In this post, I’ll cover how to use Rack Mini Profiler to profile your Rails application.
