There’s a lot of information available about ways to improve performance in Ruby on Rails applications. I’ve even written about it myself. But one thing that’s often skipped over is exactly how you are supposed to benchmark your performance improvements, particularly if you want to do a full end-to-end speed comparison. Benchmarking vs Profiling A quick refresher; to profile code (in performance terms) is to figure out which parts of the code are causing a slowdown.

Ruby 2.7+ deprecates the ability to automatically translate between a hash and keyword arguments for the last argument in a method invocation. This will be removed in Ruby 3.0 due to some ambiguity in various cases. For a more in-depth rundown, you can check the writeup on ruby-lang.org. This post is more about a simple way to solve deprecation warnings of existing code if you are upgrading to Ruby 2.7.

A previous project I worked on was to create an abstraction around various command-line invocations, the context here was automated testing on different platforms. The idea is pretty simple, rather than having to keep track of command-line flags and options, you just call this CLI and get a nice JSON formatted response. I knocked out a handful of commands, as did several other developers, and that’s where things got interesting. Despite being both a young project and a simple one, discrepancies had already crept in.

What is Memoization? When developing applications we often have methods that run slowly. Perhaps they need to query the database, or hit an external service, both of which can cause them to slow down. We could call the method every time we need that data and just accept the overhead, but if performance is a concern we have some options. For one, we can assign the data to a variable and re-use it, which would speed up the process.

What is Memoization? When developing applications we often have methods that run slowly. Perhaps they need to query the database, or hit an external service, both of which can cause them to slow down. We could call the method every time we need that data and just accept the overhead, but if performance is a concern we have some options. For one, we can assign the data to a variable and re-use it, which would speed up the process.

So you’ve been tinkering away at your side project web app and are now ready to launch it to the world. You fire up a Heroku account, push up the source code et voilà, you’re on the internet. The thing is now you’re running in “production” mode, so you’re going to want to set up some infrastructure for your application. I’m going to be using Ruby on Rails here but the general ideas will be the same for virtually any web application on any framework.