Announcing Platform API for Partners

Heroku has always made it easy for you to extend your apps with add-ons. Starting today, partners can access the Platform API to build a more secure and cohesive developer experience between add-ons and Heroku.

Advancing the Add-on User Experience

Several add-ons are already using the new Platform API for Partners. Adept Scale, a long-time add-on in our marketplace that provides automated scaling of Heroku dynos, has updated its integration to offer a stronger security stance, with properly scoped access to each app it is added to. Existing customer integrations have been updated as of Friday May 12th. All new installs of Adept Scale will use the more secure, scoped Platform API.

Opbeat, a performance monitoring service for Node.js developers, is using the Platform API in production to sync their user roles to match Heroku. It is also synchronizing metadata, so that its data stays in sync

Continue reading “Announcing Platform API for Partners”

Heroku CI Is Now Generally Available: Fast, Low Setup CI That’s Easy to Use

Today we are proud to announce that Heroku CI, a low-configuration test runner for unit and browser testing that is tightly integrated with Heroku Pipelines, is now in General Availability.


To build software with optimal feature release speed and quality, continuous integration (CI) is a popular and best practice, and is an essential part of a complete continuous delivery (CD) practice. As we have done for builds, deployments, and CD, Heroku CI dramatically improves the ease, experience, and function of CI. Now your energy can go into your apps, not your process.

With today's addition of Heroku CI, Heroku now offers a complete CI/CD solution for developers in all of our officially supported languages: Node, Ruby, Java, Python, Go, Ruby, Scala, PHP, and Clojure. As you would expect from Heroku, Heroku CI is simple, powerful, visual, and prescriptive. It is intended to provide the features and flexibility to be the


Continue reading “Heroku CI Is Now Generally Available: Fast, Low Setup CI That’s Easy to Use”

A Typical Day at Hashrocket

What is a typical day like for you at Hashrocket?

This is a question people ask. If you've never worked with a
consultancy, what happens on the inside can be mysterious. We're
consultants… does that mean we write code? We're developers…
does that mean we only take projects in languages and frameworks we know very
well? And perhaps most importantly: do we have a ping-pong table?

Today I aim to answer some of these questions the best way I can, by describing my
typical day as a developer at Hashrocket in Chicago. I hope this gives insight into consulting,
and how one person can find their place in the industry.

My typical day flows through team standup, client standups, development,
lunch, development again, and individual contributions, not always in that

Team & Client Standups

At Hashrocket, a vital part of our process is standing up together every day,

Continue reading “A Typical Day at Hashrocket”

The Hashrocket Apprenticeship

The Hashrocket apprenticeship is currently open. We hire one apprentice at a
time and typically only one per year. We receive many applications for this
position every week, but few are qualified, because few have the professional
experience in Ruby on Rails we require. You may read this and think "Yes this
is for me", if so, please apply.

Our Apprenticeship Program is not a First Job

It's not really an apprenticeship. "Apprentice" is the easiest term to
describe what we have, which is an opportunity to learn web development and
consulting in a great, supportive environment. What distinguishes this position
from other apprenticeships is that we are specifically looking for developers
who already have some professional development experience.

At Hashrocket we sell senior web development expertise to our clients. The
goal of our apprenticeship is to hire someone who already has some
experience with Ruby and Rails and in

Continue reading “The Hashrocket Apprenticeship”

The Future of Ember.js: An Interview With Tom Dale at EmberConf – Part Two

This is the second of a two-part transcript from a recent interview with Tom Dale of Ember.js. In part one we discussed the history and direction of the Ember.js project. Continuing the discussion of the future for Ember.js, this post includes the rest of the interview, primarily focused on the Glimmer.js project. Some of the questions were omitted from these transcriptions for brevity, so we’re also releasing the nearly hour long audio file of the entire interview. Enjoy!

Jonan: Let’s talk about Glimmer 2. If I understand correctly it's released now and it entirely supplants Ember. So how are you planning to gracefully sunset the project?

Terence: I think locks (Ricardo Mendes) talked about how people already have five years of Ember experience, they can now move on to this Glimmer thing, right?

Tom: That's right, yeah. You can put five years of Glimmer experience on

Continue reading “The Future of Ember.js: An Interview With Tom Dale at EmberConf – Part Two”

Agile Web Development with Rails 5.1, Upgrade Details

The History of Ember.js: An Interview With Tom Dale at EmberConf – Part One

At EmberConf Terence Lee and I had a chance to sit down with Tom Dale and chat about the history of Ember.js and where it’s headed now, including some details on the newly extracted Glimmer.js rendering engine. This post details a lot of the history of Ember, including some of the motivation that led the framework to what it is today. Watch the blog for the second portion of this interview with all of the details on Glimmer.js. The next post will also include the full audio of the interview, with many questions we opted to omit from the transcription to save valuable bytes.

Jonan: So, we're at EmberConf speaking with Tom Dale, who gave a keynote today with some important announcements. We're going to dig into those in just a minute here, but I’d like you to introduce yourselves please.

Tom: Sure. Hey, I'm Tom. I

Continue reading “The History of Ember.js: An Interview With Tom Dale at EmberConf – Part One”

Hello RedBeat: A Celery Beat Scheduler

The Heroku Connect team ran into problems with existing task scheduling libraries. Because of that, we wrote RedBeat, a Celery Beat scheduler that stores scheduled tasks and runtime metadata in Redis. We’ve also open sourced it so others can use it. Here is the story of why and how we created RedBeat.


Heroku Connect, makes heavy use of Celery to synchronize data between Salesforce and Heroku Postgres. Over time, our usage has grown, and we came to rely more and more heavily on the Beat scheduler to trigger frequent periodic tasks. For a while, everything was running smoothly, but as we grew cracks started to appear. Beat, the default Celery scheduler, began to behave erratically, with intermittent pauses (yellow in the chart below) and occasionally hanging (red in the chart below). Hangs would require manual intervention, which led to an increased pager burden.


Out of the


Continue reading “Hello RedBeat: A Celery Beat Scheduler”

The Heroku-16 Stack is Now Generally Available

Your Heroku applications run on top of a curated stack, containing the operating system and other components needed at runtime. We maintain the stack – updating the OS, the libraries, and ensuring that known security issues are resolved, so that you can focus on writing code.

Today we're announcing the general availability of Heroku-16, our curated stack based on Ubuntu 16.04 LTS. In addition to a new base operating system, Heroku-16 is updated with the latest libraries. If you’re a Ruby or Python developer, Heroku-16 includes 15% more development headers at build time, making it easier to compile native packages on Heroku. Finally, Heroku-16 offers a better local development experience when using Docker, because of its smaller image size.

Since its beta in March, Heroku-16 has been tested on thousands of applications and is now ready for production on both Common Runtime and Private Spaces apps. Heroku-16 will become

Continue reading “The Heroku-16 Stack is Now Generally Available”

Exploring Hashrocket’s Vimbundle: Vim Hashrocket

Hashrocket committed to Vim early in our history, and it's been a crucial decision. When we set up a new development machine, we
install the Dotmatrix, a library of
configurations that includes our favorite, must-have Vim plugins. This blog
post is part of a series exploring some of those plugins, focusing on Vim Hashrocket.

Vim Hashrocket

Vim Hashrocket is a collection
of settings our team shares. Spend enough time
writing code with Vim on a shared machine, and you'll find that the Vim configuration
file in the root directory (.vimrc) swells to hundreds of lines,
as each developer adds their own favorite settings. Vim Hashrocket codifies that into a plugin. It's a neatly organized
junk drawer that reflects many of our evolving goals as a development team.

Here are a few noteworthy settings in the 227-LOC hashrocket.vim plugin.


:NotRocket (line 36) is one of those

Continue reading “Exploring Hashrocket’s Vimbundle: Vim Hashrocket”

On Building Tools for Developers: Heroku CI

How we built Heroku CI: our product intuition checked against what the market wants (we surveyed ~1000 developers to figure out the latter, and the results were surprising)

Two approaches to building any product are often in tension: designing from inspiration, and designing from information. On the pure inspiration side, you just build the product you dream of, and trust that it will be so awesome and useful, that it will succeed in the market. On the pure information side, you build exactly what the market is asking for, as best you can tell (think: surveys, top customer feature requests, consultants, customer panels).

Our initial design for Heroku CI (currently in public beta) was nearly pure inspiration, in large part from our engineering staff. We had a good idea of our dream CI product, and many of the raw materials to build it (Heroku apps, our build process,


Continue reading “On Building Tools for Developers: Heroku CI”

A Module By Any Other Name: Aliases in Elixir

Modules provide a way for us to organize our code and compose complex

"A module is a collection of functions, something like a namespace. Every
Elixir function must be defined inside a module. To call a function of a
module, you use the syntax ModuleName.function_name(args)."

— Elixir in Action, pg. 22, Saša Jurić

Any module, whether part of the standard library or defined by us,
is available if it has been loaded into memory or is on the BEAM's code
path. It is easy to see this in practice within an IEx session. For
instance, the String and Enum modules are readily accessible.

> "1 2 3"
  |> String.split()
  |> -> String.to_integer(x) * 10 end)
[10, 20, 30]

Enum and String are aliases. They are a convenient syntax

Continue reading “A Module By Any Other Name: Aliases in Elixir”

Embrace the Database with Ecto

The database is a hugely important, and often times underappreciated, part
of the development stack we use to build most web applications.

Web frameworks, such as Ruby on Rails, and their database adapter layers can
sometimes lull us into a false understanding of the world. They leave us so
far removed from the actual database that we sometimes forget it is even
there. It becomes a mysterious black box that we can shovel data into and
then ask very rigid standard questions to get that data back out. When we
treat the database in this way — as a dumb data store — we miss out on all
it has to offer. However, if we seek to understand the database and how to
fully utilize it, we can harness guarantees about the correctness of our
data, build a solid data model, and write expressive, powerful, and highly
performant queries.


Continue reading “Embrace the Database with Ecto”

Running Out Of IDs

People have fingerprints. Products have bar codes. Cars have vehicle
identification numbers (VINs). Internet connected devices have IP
addresses. Anything that needs to be uniquely identifiable tends to have a
mechanism for uniquely identifying it. It makes sense. This is particularly
important for the data that we store as part of the applications we build.
Every user, every product, every financial transaction should all have
some kind of identifier that we can use to uniquely identify it.

The limits of these identifiers is the subject of this post.

Though we can utilize fancier schemes like UUIDs and composite keys, the
most common approach to uniquely identifying records is an id — an
integer that we guarantee is unique. But where do these unique integer ids
come from?

A Sequence

In PostgreSQL, we generally create an id column as a primary key using

create table products (
  id serial 
Continue reading "Running Out Of IDs"

The Glimmer VM: Boots Fast and Stays Fast

Great web applications boot up fast and stay silky smooth once they’ve started.

In other contexts, applications can choose quick loading or responsiveness once they’ve loaded. Great games can get away with a long loading bar as long as they react instantly once the gamer gets going. In contrast, scripting languages like Ruby, Python or Bash optimize for instant boot, but run their programs more slowly.

To optimize for boot time, scripting languages use interpreters and avoid expensive compilation steps. To optimize for responsiveness, games pre-fill their caches and do as much work up front as they can get away with. The web demands that we do both at the same time: users coming from search results pages must see content within a second on modern devices, but also demand 60fps once the application gets going.

Over the years, web browsers have responded to this requirements with more JIT tiers

Fast Updates in Ember

Continue reading “The Glimmer VM: Boots Fast and Stays Fast”

Encryption with gpg, a story (really, a tutorial)

GPG is a compatible replacement of PGP. That, in and of itself, is confusing.

That each acronym is sufficiently obtuse on its own is enough to prompt a less
privacy minded developer to give up. GPG stands for Gnu Privacy Guard and PGP
stands for Pretty Good Privacy. Pretty Good Privacy came first and prompted
the government to prosecute the creator, Phil Zimmerman, for exporting
munitions illegally. He published the code in a book, and then he was
exporting a book not munitions.

The first thing to understand about gpg is that it is not like openssl.
openssl takes inputs and delivers outputs and maintains no state inbetween
requests. gpg, on the other hand, functions as a key server along with
encrypting, decrypting and key generation. It runs in the background, a
daemon, and manages your private keys and the public keys of others. It is a

Continue reading “Encryption with gpg, a story (really, a tutorial)”

Sockets in a Bind

Back on August 11, 2016, Heroku experienced increased routing latency in the EU region of the common runtime. While the official follow-up report describes what happened and what we've done to avoid this in the future, we found the root cause to be puzzling enough to require a deep dive into Linux networking.

The following is a write-up by SRE member Lex Neva (what's SRE?) and routing engineer Fred Hebert (now Heroku alumni) of an interesting Linux networking "gotcha" they discovered while working on incident 930.

The Incident

Our monitoring systems paged us about a rise in latency levels across the board in the EU region of the Common Runtime. We quickly saw that the usual causes didn’t apply: CPU usage was normal, packet rates were entirely fine, memory usage was green as a summer field, request rates were low, and socket usage was well within the acceptable

Continue reading “Sockets in a Bind”

N+1 Queries or Memory Problems: Why not Solve Both?

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:

<% @posts.each do |post| %>
  <%= link_to(post, post.title) %>
  <%= teaser_for(post) %>
  <%= "#{post.comments.count} comments"
<% end %>

<%= pagination(@posts) %>

See any problems with this? We have to make a single query to return all the posts – that's where the @posts comes from. Say that there are N posts returned. In the code above, as the view iterates over

Continue reading “N+1 Queries or Memory Problems: Why not Solve Both?”