Posts

“The goal is not always meant to be reached, but to serve as a mark for our aim.” –Joseph Joubert Set goals that are directly measurable Example: Speed up test suite to run under two minutes on our CI server The gold standard of goals! Total clarity on what I’m trying to do, and whether or not the goal has been accomplished. A measurable goal is an achievable goal. But sometimes the measurement is difficult, prohibitively expensive, or truly impossible.

We’re starting on a new version of the internal PrettyQuick API that powers our native clients and AJAX. The original version was based largely on what our consumer iOS app needed, but going forward we want to build a more general API to better support multiple clients for multiple constituencies. Luckly, Heroku has thoughtfully prepared a list of API best practice recommendations. I’ve logged my thoughts and usage notes below as I work through each of the items on their list.

There’s been renewed discussion recently about cultural fit, what it means, and its place in your hiring process. This pendulum has been swinging for years, because there are strong arguments both for and against. As usual, the answer lies between the extremes. A thoughtful cultural interview, as one component of a comprehensive hiring process, can provide some of the positives while avoiding the worst negatives. But how? Here are a few guidelines for approaching cultural criteria.

Much like code smells, there are conversation smells. Words that should be a red flag, words that often indicate something bad is happening. Here are some words I watch out for in dev meetings. Obviously The fastest way to shut someone down is to make them feel stupid. Saying “Obviously” prevents me from asking questions about what you said. If it’s not so “obvious” to me, maybe I’d like to dig a little deeper - but you’ve set up a situation where I look stupid in front of the group because I can’t immediately grasp the full meaning of what you said.

I’d like to share a personal revelation in case it applies to you too. Mo' Developement Mo' Problems I’m a developer in large part because I enjoy solving problems. I like how there are so many aspects of solving a problem. Defining and redefining. Looking from different perspectives. Empathizing with users. Thinking about various approaches. Testing those approaches. Determining metrics of success. Measuring results. Learning and iteratively refining. And I like how development provides me with interesting new problems every day.

Very early in my career, I was setting up some pressure sensors. The sensors had tiny wires coming off them, which someone had soldered to shielded co-axial cable running back to the data acquisition board/laptop. My task was to fasten the sensors to a frame, which I completed quickly and thoroughly. My boss checked in, complimented my framed sensors, and mentioned that the way the tiny wires connected to the co-ax was too flimsy for our application.

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.