I’ve been working on an application that works to match users together based on a complex set of criteria (read: big slow database query and in-memory processing). The core usage of the application revolves around these user matches, so I want to make sure that either the algorithm will run very fast or can be cached so that it’s not run every time a user visits their matches page.
The most important requirement for our matches is reciprocation. To solve this problem and meet all of the requirements, we can create a bi-directional, self-referential, self-syncing, many-to-many association between users using a
has_many :through association with a join model to keep track of a user’s matches.
Editing an existing commit in history with an interactive rebase, reset, and amend.
We need to make getting up and running with our Rails apps easier. Here’s my attempt.
Moving our SaaS conversion tracking from Google Analytics to KISSmetrics was a great decision, but there were a few things I learned that I wish I would have known before jumping in that would have saved time.
Using espresso-intents for testing Android Activity Intents
For those of us who use the popular distributed job queueing system Sidekiq, it’s a common problem: a Sidekiq instance containing a pool of workers dies, and the only way you find out about the problem is by checking the Sidekiq dashboard and seeing that you’ve got a ton of jobs backed up and fewer busy workers than expected. Luckily, there’s an easy way to get email alerts when one of your instances goes down, using Dead Man’s Snitch and a little bit of code inspired by the
The pluck method is a performant option to query columns from one or more tables. The ability to pass valid SQL directly makes it all the more handy.
I love writing gems. Lately, I’ve been particularly interested in tackling the big, important problems in math, like how can a computer generate a truly random number. I took this challenge head-on when I developed the fair_dice_roll gem.