Sometimes when you do everything right, things still go wrong. I previously talked about how bad I am at spelling and grammar in “The Four Year Typo”, which reminded me of my first major production failure at Heroku.
I’m a horrible speller. I often joke that I got into programming because it doesn’t matter how you spell your variables, as long as you spell them consistently. Even so, I spend a good portion of my days writing: writing docs, writing emails, writing commit messages, writing issue comments, and of course writing blogs. Before I publish an article, I run my work by an editor, which makes this typo even more exceptional.
The memory use of a healthy app is like the heartbeat of a patient - regular and predictable. You should see a slow steady climb that eventually plateaus, hopefully before you hit the RAM limit on your server:
What happens when “don’t do that” turns into “it worked before”? This is exactly the scenario I was faced with recently. We had a string of tickets in under two days with the same weird error message. This frequency normally indicates that something changed, but the error was in a weird place, didn’t seem to be related to any new code. Here’s the error people were reporting on Heroku:
This post is going to help save you money if you’re running a Rails server. It starts like this: you write an app. Let’s say you’re building the next hyper-targeted blogging platform for medium length posts. When you login, you see a paginated list of all of the articles you’ve written. You have a Post model and maybe for to do tags, you have a Tag model, and for comments, you have a Comment model. You write your view so that it renders the posts:
An application doesn’t have one type of configuration, it has two. In Rails, it’s confusing since we muddle these two together under a giant switch statement powered by RAILS_ENV. Let’s start with some definitions.
Polish is what distinguishes good software from great software. When you use an app or code that clearly cares about the edge cases and how all the pieces work together, it feels right. Unfortunately, this is the part of the software that most often gets overlooked, in favor of more features or more time on another project. Recently, I had the opportunity to work on an integration between Rails and Puma and I wanted to share that experience in the context of polish and what it takes to make open source work.
Heroku bumped its Bundler version to 1.13.7 almost a month ago, and since then we’ve had a large number of support tickets opened, many a variant of the following:
Update: There’s a great resource for dealing with timeouts in Ruby called The ultimate guide to Ruby Timeouts, via @codefolio. Also there’s some good dicussion on Reddit around the possibility of maybe using
Thread.handle_interuptin gems, read the comments. Also I added a feature to “SIGTERM” on timeout in rack-timeout that can help mitigate (but not fix) the issue term on timeout documentation.
How does an asset get compiled? It’s less of a pipeline and more of a recursive ball of, well assets. To understand the process we will, start off with an asset with no directives (no require at the top). We’ll then walk through all the steps Sprockets goes through until a usable asset is loaded into memory. For this example we will use a js.erb file to see how a “complex” file (i.e. multiple extensions) type gets compiled. All examples are with Sprockets 4 (i.e. master branch). Here’s the file:
