performance
I have talked about limiting everything [https://www.johnnunemaker.com/database-performance-simplified/] before, but I love examples, so I thought I would start bringing some out of the woodwork. How many times have you whipped out backticks or one of the million other ways you can shell out in Ruby? If
performance
By day, I am a mild mannered owner/programmer at Box Out Sports [https://boxoutsports.com]. By no means do you need to understand all that we do there or how we do it, but recently I fixed a tricky N+1 query and thought I should write it up.
flipper
I will be honest with you. I really miss writing. There is something about organizing the ideas and work swirling around in your head into a blog post that makes the abstract concrete and the chaotic organized. I mean shoot, I remember the days of old on RailsTips [http://railstips.
flipper
Two months ago I wrote up a doozy of a post about flippin’ feature at runtime [https://www.johnnunemaker.com/flippin-features-at-runtime/]. Since then, the contributions to Flipper [https://github.com/jnunemaker/flipper] from myself and the community have continued. Easy migration from Rollout [https://github.com/fetlife/rollout] , bug fixes
flipper
I have moleskines full of ideas. When I worked at Notre Dame [https://www.nd.edu] (circa 2006), making products was all the rage. I spent all my free time thinking up and working on new apps. They never went anywhere, but were great fun and, more importantly, great practice.
flipper
Since it has been nearly a year since I’ve written about Flipper [http://www.railstips.org/blog/archives/2016/12/08/flipper-preloading/] (a ruby gem for turning parts of your application on or off at runtime), I thought I’d share some of what I (and other contributors) have
performance
For the second half of 2014 and 2015, most of my time at GitHub was spent working on moving the notifications feature off the primary MySQL cluster on to a new MySQL cluster and making the feature resilient to failure of that cluster. When all your data is stored in
performance
Sometimes I feel developers think that performance is a dark art. It is not. In my experience, well performing systems come down to this: fewer and faster. If you are doing something a lot, do it fewer times. If you are doing something that is slow, make it faster. It
randoms
The Error Model [http://joeduffyblog.com/2016/02/07/the-error-model/]. I’ve been doing a lot of resiliency related things lately and that means dealing with errors. This post is one of the longest (and also best) summary of error handling on the planet. Write code that is easy to
randoms
Fail at Scale [http://queue.acm.org/detail.cfm?id=2839461] Great post about failure at Facebook. My favorite parts were controlled delay and adaptive LIFO. > These two data points seem to suggest that when Facebook employees are not actively making changes to infrastructure because they are busy with
performance
de•cay noun - the state or process of rotting or decomposition. Let us kick off the new year with a lovely post on decay. All systems decay. Even when you continually work on improving the system, it decays. That said, in my experience, not all decay is equal with
performance
A general model (or guidelines to live by) that won’t solve all your problems, but will keep you from getting into trouble overly quickly.