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:
This is one of the most frequent questions I’m asked by Heroku Ruby customers: “How do I debug a memory leak?” Memory is important. If you don’t have enough of it, you’ll end up using swap memory and really slowing down your site. So what do you do when you think you’ve got a memory leak? What you’re most likely seeing is the normal memory behavior of a Ruby app. You probably don’t have a memory leak. We’ll work on fixing your memory problems in a minute, but we have to cover some basics first.
Have you ever wondered who out there is using a gem? Now there’s an easy way.
In a recent patch we improved Rails response time by >10%, our largest improvement to date. I’m going to show you how I did it, and introduce you to the tools I used, because.. who doesn’t want fast apps?
It started screaming for life. Sucking in air and yelling out with a beautiful pain. I couldn’t stop smiling.
Every program wants to live forever. What happens when a program is forced to exit before it’s done running, and why would we want to do that?
I’ve never met a developer who complained about code getting faster or taking up less RAM. In Ruby, memory is especially important, yet few developers know the ins-and-outs of why their memory use goes up or down as their code executes. This article will start you off with a basic understanding of how Ruby objects relate to memory use, and we’ll cover a few common tricks to speed up your code while using less memory.
When we moved into our house on the East Side, the interior walls were all supported by 1 inch thick long leaf pine. A builder looking at the material during a site visit casually mentioned he would make something out of it. This peaked my interests and set me down my recent woodworking path. The only problem was that I didn’t have many tools.
“Why exactly is RubyGems slow?” is the question that more than one developer has asked, but few have bothered to do anything about. Recently @mfazekas took up the task for profiling an especially slow case using dtrace. This resulted in several high profile pull requests to improve performance and drop memory allocations. These in turn lead me to ask the question, just what is Rubygems doing that takes so long? The short answer is, way more than you ever thought; for the long answer, keep reading.
