Optimist's Guide to Pessimistic Library Versioning
18 Apr 2016Upgrading 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.
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 Ruby code using nothing but 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.
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!
SemVer is simple. Well…until you start publishing libraries, and accidentally break a metric ton of apps on accident. I’ve never caused any mass scale melt downs, however I’ve made my fair share of screw-ups. I maintain gems with over 200 million downloads. I wish I had this guide available to me when I first got in the library authorship game. Let’s take a look at what SemVer is and how to use it as a maintainer.
Sometimes in programming, the smallest things are the most helpful. I remember wowing a co-worker when I hit CTRL+A and my cursor jumped to the beginning of a long terminal command. Since then, I’ve vowed that no tip is too small to share. Today, my tip is for getting Rails SQL statements and Cache behavior in production logs locally. It’s pretty simple. If you’re using rails_12factor
gem to output your logs to standard out, then all you need to do is boot up your server with LOG_LEVEL=debug
, like this: