Today I switched from RVM to rbenv. This ThoughtBot post was a great starting point.
I ran into a couple hitches. Here’s how I got through it. Do this stuff before you start the ThoughtBot stuff.
First, brew doctor. I ran it a bunch of times and followed the steps until it was clean.
The hardest step was XCode. I was running 4.2.1 and brew wanted 4.6.3. I downloaded the new 4.6 version through the app store, but brew was still using my old standalone 4.
Here’s what Heroku says about dyno memory usage:
Dynos are available in 1X or 2X sizes and are allocated 512MB or 1024MB respectively.
Dynos whose processes exceed their memory quota are identified by an R14 error in the logs. This doesn’t terminate the process, but it does warn of deteriorating application conditions: memory used above quota will swap out to disk, which substantially degrades dyno performance.
If the memory size keeps growing until it reaches three times its quota, the dyno manager will restart your dyno with an R15 error.
SUMMARY: This is a step-by-step overview of how to get Oink installed in your Rails app on Heroku, and use it to analyze your memory usage. Starts with a brief description of the problem space, skip down if you just want to get on with your Oink integration.
My stack includes these technologies: Rails 3, Unicorn, NewRelic, Heroku, Hodel3000CompliantLogger, and now Oink.
Why is understanding memory usage important? For me, it’s because Heroku routes traffic to my dynos randomly.
Make a file called epoch.rb in your project (I put mine in config/initializers). Use it to store constants that represent the times when big dev events happened. For example:
CART_RELEASE = Time.local(2013, 04, 22, 13, 45) We released our shopping cart at 1:45pm on 4/22. Fast forward to today: some of our stats are messed up, for deals that were live across the cart release. I need to fix the stats, but I only want to do it for the affected deals.
I gave a 10-minute intro to table_print at ChicagoRuby this week. The video turned out nicely, check it out in the ChicagoRuby video archives!
All the lightning talks from the evening are in a single video, but I’m up first.
Imagine: you open a rails console and type User.limit(100). The output shows your database call, then… ACTIVE RECORD GUT PUNCH!!! Your screen is overrun with an inscrutable wall of text.
I hated it. I had some coping mechanisms, but they were cumbersome. For example, the map-and-print:
puts User.all.map { |u| "#{u.id}, #{u.email}, #{u.bio}" }.join("\n"); 0 This still sucked. Tons of typing, mid-line typos, forgetting to start with ‘puts’, accidentally returning the whole array - and the output was better but still not great.
UPDATE: I made a gem! Just add gem "marco-polo" to your gemfile to see your app name and environment in your console prompt.
I hate when I have a bunch of consoles open and I don’t know which one is local, which is staging, and which is production. I could potentially do a lot of damage by using the wrong one. I find myself typing Rails.env over and over, to figure out which environment I’m in.
The Problem This technique came from my work on table_print, an irb tool for showing ruby objects in tables. I wanted to let people configure its output on a process-wide basis; eg, a default date format so sll their dates are shown consistently in the way they prefer. Additionally, I wanted a simple, easy-to-remember interface and a clean global namespace.
The Solution Here’s a basic syntax example for table_printing:
# prints all the authors, along with their book titles and photo captions > tp Author.
Pulled this out of a talk by Avdi. This technique is described at 16:00 in the video.
It’s nice for the user of a library to be able to catch any error coming out of the library, but at the same time, it’s nice for a library to pass through basic error types like HTTPError. To solve the problem, you can “tag” the HTTPError with your own error class, essentially raising both types of error:
I attended the Chicago Ruby Hack Night meetup last tuesday. The theme was IronMQ, a message queue web service. You can post/get/delete messages through a set of super simple HTTP endpoints, and they handle the tricky (or at least boring) stuff like storage, retries, etc.
Honestly, I almost didn’t go. I know that exposure to new technologies is good for me, but usually I have a hard time justifying messing around with something that doesn’t relate to a bigger project (be it professional or personal).