Jared Rader


TIL - GIN Indexes

Been meaning to post about this for a while, but I recently learned about Generalized Inverted Indexes. According to the Postgres docs:

GIN indexes are “inverted indexes” which are appropriate for data values that contain multiple component values, such as arrays. An inverted index contains a separate entry for each component value, and can efficiently handle queries that test for the presence of specific component values.

I plan to write a longer post about my exploration into this, including the pros and cons of denormalization, but I’ll give a short overview of a problem I was trying to solve and how the GIN index came into play.

At Reflektive, I’ve been working on a user profile feature that gives each person a personalized newsfeed of the feedbacks they have sent or received.

Over time, the types of feedback we have in Reflektive has grown, and with each type of feedback, specific rules around who can see the feedback. For example, a user can give somebody private feedback, and only those two individuals should be allowed to see it. Or, Person A can write a private note about Person B, and not share it with Person B. While this is still stored as a Feedback in our database, and Person B is the recipient, Person B should not be allowed to see that Feedback.

In total, we have 9 different types of feedbacks, and unless the feedback is public, the feedback is private and shared with, at most, 3 people.

From Service Objects To Interactors

This post first appeared on the Reflektive Engineering Blog

If you’ve worked on any large Rails app, you’ve probably come across the service object pattern, a useful abstraction for handling business logic.

Recently, we’ve been playing with a particular implementation of this pattern using the Interactor gem.

To understand the benefits of interactors, it’s helpful to first talk about service objects and how they’re often used in Rails.

In the context of Rails, a service object is simply a Ruby object used for a specific business action. This code usually doesn’t belong in the controller or model layer, because it might involve multiple data models, or it hits a third-party API.

TIL - Ruby Array Multiplication

Today I learned that if you call a multiplication operator on a Ruby array, it duplicates each element of the array by the multiplier.

So for example:

>> [1,2,3] * 3
=> [1, 2, 3, 1, 2, 3, 1, 2, 3]

>> ['Jared Rader'] * 3
=> ["Jared Rader", "Jared Rader", "Jared Rader"]

Thoughts on Ruby Inheritance Patterns

Developers writing code in object-oriented languages like Ruby and JavaScript have a complicated relationship with inheritance. I have seen opinions stating that class inheritance is absolutely evil and should be avoided in all circumstances, and those who favor composition over inheritance, but don’t discount class inheritance entirely.

Those that are against class inheritance entirely often favor composing classes with modules to add behavior. The funny thing here is that including modules functions pretty much exactly the same as class inheritance. If a method is not defined in the class, Ruby looks up the inheritance tree, starting with the modules included.

The favor for composition comes from the fact that composing classes with modules is more flexible than what a class hierarchy offers and classes can essentially achieve multiple inheritance through module inclusion.

I decided to take the idea to its extreme recently in a project at work. After students enroll in courses at Bloc, they are taken through an onboarding workflow where they create a profile, select their mentor, create a schedule of appointments, etc. We created a neat class called OnboardWorkflow that defined a series of determined steps so that students would go through onboarding in the order we wanted them to.

Refactoring Fat Models with DCI

Rails developers are familiar with the maxim “fat models, skinny controllers”. If logic starts creeping into our controllers, most developers seem content to push that logic into a model. But obese models can make for painful development. At Bloc, we’ve reached the point where this has become painful enough that I decided something needed to be done about it. After reading through Jim Gay’s fantastic Clean Ruby, I identified many areas in which our application could benefit from the DCI (data, context, interaction) design pattern.

DCI, according to that wikipedia link above, “separates the domain model (data) from use cases (context) and Roles that objects play (interaction)”. In Clean Ruby, Jim Gay illustrates this concept with transferring money between two accounts. The domain model is an account, which takes on the role of a transferrer of money from itself to another account, in the context of transferring money.

The situation I came across in the Bloc application involved populating a progress bar with data related to a student’s enrollment. This used to be fairly straightforward, but after introducing our Track products, in which students can take a track of two courses, it became a little more complicated.

Practical Object-Oriented Refactoring

This post first appeared on the Bloc blog in January 2015

As code bases grow, the need to refactor grows with it. A couple weeks ago, I saw an opportunity to refactor Bloc’s scheduled emails, which we activate in a Rakefile.

The Rakefile looked something like this:

task :send_greeting_email => :environment do
  Enrollment.starting_in_the_next_two_weeks.each do |enrollment|


task :send_get_started_emails => :environment do
  starting_enrollments = Enrollment.where('course_start_date > ? AND course_start_date < ?', Time.now, Time.now).where(sent_get_started_email: false)

  starting_enrollments.each do |enrollment|

task :send_final_day_email => :environment do
  Enrollment.active.graduating_on(Date.today).each do |enrollment|

Plus several more notifications.

I wanted to test the code in this file, but as it is, it’s not very friendly to testing. However, there was a pattern among all these scheduled emails - grabbing specific enrollments and performing certain email actions. Sounds like a great use case for a service object.

A Functional Approach to Verbal Math in Ruby

Inspired by my functional approach to solving the verbal math problem in JavaScript, I decided to implement a similar approach in Ruby.

My first solution took advantage of Ruby’s everything-is-an-object nature, sending number objects symbols and values, which made solving the problem pretty easy.

However, it’s possible to take a functional approach in Ruby that is nearly equivalent to how you could solve this problem in JavaScript. And then, you can even combine this with Ruby’s object-oriented nature and metaprogramming capabilities to create a truly elegant solution.

While JavaScript has anonymous functions, Ruby has something similar in blocks, procs, and lambdas.

Here’s a language conversion to illustrate how you can achieve very similar functionality in Ruby and JavaScript (Check out my last post where I explain the JavaScript function in-depth):


function plus(amount) {
  function add(number) {
    return number + amount;
  return add;

Verbal Math in JavaScript

I’m a fan of this fluent calculator exercise (I covered my solution using Ruby in my last blog post), and on another flight, I decided to implement a solution in JavaScript. Ruby’s object-oriented nature and metaprogramming capabilities made the task fairly simple; how would it go in JavaScript?

Recall that this exercise requires one to be able to verbally enter math operations, i.e. one(plus(one())), and return the correct integer result.

In Ruby, because most everything is an object, I was able to call methods on my integers, like 1.send(:+, 1). In JavaScript, integers are just primitive data types - not objects that can receive messages. But JavaScript’s ability to return functions allows us to achieve the same ability.

Again, I started off with the one() function. I knew one() would need to optionally take an argument, which would be an operator function. If no operator function was passed, I simply return 1. Otherwise, I need to return an operation on 1:

function one(opFunc) {
  if (opFunc == undefined) {
    return 1;
  } else {
    // as yet unwritten code

Verbal Math In Ruby

Came across an interesting code challenge on Code Wars a while back. It involved defining methods in a way to be able to type mathematical operations verbally, i.e. one plus one which would return 2.

I pondered over this for a while, and on a flight back from San Francisco came up with a neat solution and even learned a couple interesting things about metaprogramming.

I started with defining one. I know that I’ll want to potentially pass an argument to one. If I don’t have an argument, I’ll just want to return the integer 1. Simple enough. I can just give my method definition argument a default value of nil, check whether I have an operator, and if I don’t, simply return the integer 1:

def one(operator_method = nil)
  if operator_method
    # as yet undefined code

Ok, so what should happen when I get an operator? I decided to find a way to implement plus.