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.
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.
If you’re running a production application, you need metrics. There are great products out there that allow you to gain visibility into how your application is performing, give some nice graphs, and charge you for it. In the Rails community, this is commonly achieved by using NewRelic and Skylight. But for some of us, we achieve visibility by using Prometheus and Grafana that we build and host ourselves.
No matter how carefully coded, reviewed, and tested your Ruby code is, odds are good that at some point you’ll cause a catastrophic failure to at least one system you’re responsible for. How do you prepare yourself? You need a Ruby debugger. In this post, I’ll cover the whole Ruby debugger process—from finding the issue to determining the root cause. Use these instructions for debugging a single Ruby file, a Rails app, or a gem.
Most Rails developers should be pretty familiar with this work flow: open up a controller file in your editor, write some Ruby code inside an action method, visit that URL from the browser and the code you just wrote comes alive. But have you thought about how any of this works? How did typing a URL into your browser's address bar turn into a method call on your controllers? Who actually calls your methods?
Docker Compose is a great tool to develop your Ruby on Rails application locally. It allows you to easily isolate your ruby environment, database, and even Redis if you use something like Sidekiq.
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.
