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.

In a recent post, we talked about Docker containers, and what you should know about them. Hopefully we cleared up any confusion you might have had about the Docker ecosystem. Perhaps with all that talk, it got you thinking about trying it out on one of your own applications? Well in this post we’d like to show you how easy it is to take your existing Ruby on Rails applications and run them inside a container.

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.

Have you ever been confused about the different ways to handle missing data in the Ruby language? I know I have, and I’m sure I’m not alone in that. The options Ruby offers come in the form of several methods: “present?”, “blank?”, “nil?”, and “empty?”. There are all somewhat related since all of them check for the absence of data in some way.

Authentication for web apps is a difficult problem. Anyone who’s ever tried to create their own authentication system will tell you that there are a lot of unexpected edge cases. What’s more, your authentication system is an externally-facing part of your application. This means if someone is trying to hack into your application, your login system’s security will be one of the first places they check.

A Rails migration is a tool for changing an application’s database schema. Instead of managing SQL scripts, you define database changes in a domain-specific language (DSL). The code is database-independent, so you can easily move your app to a new platform. You can roll migrations back, and manage them alongside your application source code.