Rails has several popular options for queuing or scheduling tasks. When I was looking at the alternatives for my app TimeVault I was faced with something of a difficult choice. Two of the most popular libraries, Resque and Sidekiq, require Redis. At the time, I didn’t want to mess around with an additional component to deploy, so I used Delayed::Job instead.

Imagine you have the following models in a Rails app:

class Car
  has_many :wheels
end

class Wheel
  belongs_to :car
end

You could instantiate and save a new car with wheels like so:

car = Car.create
4.times { car.wheels.create }

What if we want to save the car and its wheels to the database as a single transaction?

A typical Rails CRUD app will have an index. The index will list a collection of resources, like blog posts. In our index.html.erb view, we might do this:

<% @posts.each do |post| %>
  <%= post.title %>
<% end %>

This will list out the titles for each of our blog posts. However, there is a more elegant way which leverages Rails’ defaults.

The job interview marathon continues, and consequently this will be a short one. But I feel that I omitted a critical, seemingly obvious piece of information in my previous post:

Technical interviewing is a skill like any other, and it is built with practice. It is a mistake, at least for me, to assume that since I can build awesome stuff I therefore must possess good technical interviewee skills. In my experience, the two skills seem almost orthogonal. Here’s how I’ve been building my technical interview chops.

This week has been a job interview marathon. Tech interviews are an utterly different beast from the job interviews I’m used to. For one, they are much longer than non-technical interviews. Some companies have had me speak to half a dozen employees, from engineers to HR to management. The main differentiator, of course, is the technical portion of the interview itself.