Rails 5 will be the easiest release ever to get running on Heroku. You can get it going in just five lines:
Upgrading software is much harder than it could be. Modern versioning schemes and package managers have the ability to help us upgrade much more than they do today.
Want to speak at a conference? First you’ll have to get a proposal accepted. To date, I’ve helped pick talks for Keep Ruby Weird since it started, and this year I reviewed for RailsConf 2016. I’ve also written a number of proposals, some that have been accepted, some that haven’t.
If you maintain a gem and aren’t using Bundler’s release rake tasks you’re missing out. If you have a well maintained gem, then the best practice is to tag a release every time you push a new gem version to RubyGems.org. This helps users to see differences between versions. For example you can compare releases on the Heroku Ruby Buildpack https://github.com/heroku/heroku-buildpack-ruby/compare/v142…v143. Bundler comes with a Rake task that simplifies tagging a release and pushing a version to RubyGems.
The asset pipeline is the slowest part of deploying a Rails app. How slow? On average, it’s over 20x slower than installing dependencies via
$ bundle install. Why so slow? In this article, we’re going to take a look at some of the reasons the asset pipeline is slow and how we were able to get a 12x performance improvement on some apps with Sprockets version 3.3+.
Unlike pulling a rabbit out of a hat, “magic” in programming is often performed under the guise of productivity. In this post, we’ll look at what defines a magical programming experience for better or worse. If you were in Rails around 2007 you might be quick to describe it as “auto-magical,” and this was a good thing. Magic meant freedom from the tyranny of endless boilerplate, freedom from hours of tedious configuration, freedom to be productive.
Rails 5 has been brewing for more than a year. To take advantage of new features, and stay on the supported path, you’ll need to upgrade. In this post, we’ll look at the upgrade process for a production Rails app, codetriage.com. The codebase is open source so you can follow along. Special thanks to Prathamesh for his help with this blog post.
This document is all about deciphering behavior of complicated Ruby code. I recommend you get familiar with a debugger like pry-debugger, this doc doesn’t go into debuggers because they’re not always available, and only focuses on Ruby’s ability to introspect its own code.
In this two part series I talk about the in and outs of debugging Ruby memory with heap dumps. The first section covers what a heap dump is, how to get one, and how to analyze it. The second section focuses on getting a heap dump off of a Heroku dyno. We then use that data to debug a production memory problem. These were originally published in December 2015, sorry for the delay in linking. Enjoy!