The other day the HB team was chatting and Ben, our dev-ops master, mentioned that he wished he'd used ULIDs instead of UUIDs for a particular system. Like any seasoned engineer, my reaction was to mumble something non-committal then sneak over to Google to try to figure out what the hell a ULID is. Two hours later I emerged with a thousand-yard stare and the realization that the world of unique identifiers is larger and more wondrous than I ever could have imagined.

When Honeybadger originally partnered with Slack, it was the dawn of a new era. Dev teams everywhere were thrilled that they could receive exception, uptime, and check-in alerts instantly from within their teams' Slack channels. That was, and still is, a lethal weapon. However, Honeybadger and Slack have partnered up again and have been hard at work pushing error monitoring to the limit. Why? Because bugs and exceptions don't rest, and neither do Honeybadger and Slack.

Because Ruby is an object-oriented language, we tend to model the world as a set of objects. We say that two integers (x and y) are a Point, and a Line has two of them. While this approach is often useful, it has one big problem. It privileges one interpretation of the data over all others. It assumes that x, and y will always be a Point and that you'll never need them to act as a Cell or Vector. What happens when you do need a Cell? Well, Point owns the data. So you add a your cell methods to Point.