When Heroku launched in 2007 there was only a single Ruby version that could be used on the platform. In 2012 Heroku began to support multiple Ruby versions. Since then, we've had a holiday tradition of releasing the new versions of Ruby on the same day they come out, which always happens on Christmas day (December 25th).

If you're new to the community, you might be curious about where releasing a new minor version on Christmas comes from. To help answer that question, we interviewed Matz's, who works as the Chief Ruby Architect at Heroku in 2015. In his own words:

Ruby was originally my pet project, my side project. So releases usually happened during my holiday time. Now,...

This blog post is adapted from a lightning talk by Ben Fritsch at Ruby on Ice 2019.

There can be a number of reasons why your application performs poorly, but perhaps none are as challenging as issues stemming from your database. If your database's response times tend to be high, it can cause a strain on your network and your users’ patience. The usual culprit for a slow database is an inefficient query being executed somewhere in your application logic. Usually, you can implement a fix in a number of common ways, by:

• reducing the amount of open locks (or more detail about database lock debugging in this other blog post by Heroku Engineer Richard Schneeman, The Curious Case of the...

Update: On closer inspection, the lock type was not on the table, but on a tuple. For more information on this locking mechanism see the internal Postgresql tuple locking documentation. Postgres does not have lock promotion as suggested in the debugging section of this post.

I maintain an internal-facing service at Heroku that does metadata processing. It's not real-time, so there's plenty of slack for when things go wrong. Recently I discovered that the system was getting bogged down to the point where no jobs were being executed at all. After hours of debugging, I found the problem was an UPDATE on a single row on a single table was causing the entire table to lock, which...

This blog post is adapted from a talk given by Julián Duque at NodeConf EU 2019 titled "Let it crash!."

Before coming to Heroku, I did some consulting work as a Node.js solutions architect. My job was to visit various companies and make sure that they were successful in designing production-ready Node applications. Unfortunately, I witnessed many different problems when it came to error handling, especially on process shutdown. When an error occurred, there was often not enough visibility on why it happened, a lack of logging details, and bouts of downtime as applications attempted to recover from crashes.

Today, many people with diabetes are choosing to manage their condition using devices called continuous glucose monitors (CGMs). Not only do they replace the need for most finger prick testing, but they also provide a stream of data round the clock. However, like all data, it’s only as useful as the tools that analyze it.

That’s where Sugarmate comes in. Created by serial entrepreneur Josh Juster to help manage his own condition, Sugarmate combines a Heroku back-end with web, mobile, and smartspeaker apps to provide life-changing alerts and analysis for people living with diabetes.

Alexa, what’s my blood sugar level?

For 26 years, Josh has himself been living with type 1 diabetes, and...