Mike Raimondi

Queuing and Scheduling in Rails with Delayed::Job

Wed, 14 Aug 2013 00:00:00 -0400

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.

Delayed::Job (DJ) supports multiple backends. Most importantly for our purposes, it has solid support for ActiveRecord. There are performance reasons for choosing Redis over ActiveRecord, but for a small learning app these are typically safe to ignore.

TimeVault allows users to set Pomodoro timers and receive alerts when they are complete. Each timer has one or more Intervals with a start and stop time. When a timer starts, an Interval is created, which then creates an IntervalWorker:

def create_interval_worker
  Delayed::Job.enqueue(IntervalWorker.new(id), run_at: when_to_run)
  save
end

DJ supplies an enqueue class method. Here, I’m passing in a new IntervalWorker and using the run_at option to delay instantiation of the worker until the interval expires. DJ expects enqueued objects to have a perform method that will be called on execution. Here, the IntervalWorker calls complete! on the interval that created it.

class IntervalWorker
  def initialize(interval_id)
    @interval_id = interval_id
  end

  def perform
    interval = Interval.where(id: @interval_id).first
    interval.complete! if interval.present?
  end
end

complete! ends the interval by setting its end attribute to the current time. Note how the service object, IntervalWorker, is quite simple. All the actual logic is built into the model, Interval. This is an example of separation of concerns. Modifying the Interval is not a concern of the IntervalWorker.

I highly recommend the Delayed::Job RailsCast to get started with DJ. Good luck!

Smart ActiveRecord Saves

Mon, 29 Jul 2013 00:00:00 -0400

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? This might be important if we never want a car to be saved to the database without wheels. Makes sense, right? Here’s how we could do that:

car = Car.new
4.times { car.wheels.build }
car.save

The build method instantiates and associates new wheel objects, but does not persist them to the database. ActiveRecord is smart about deferring persistence in this way. When you call save on the parent object, car, ActiveRecord will also call save on the child objects. A handy pattern to use with closely coupled objects!

Render Collections Easily With Rails

Fri, 26 Jul 2013 00:00:00 -0400

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. If we instead do this:

<%= render @posts %>

Rails will look for a partial in the app/views/posts directory with a name equal to the model name. If the model name is Post, Rails would look for a file named _post.html.erb. We might write it like this:

<%= post.title %>

By default, Rails provides us with a local variable with the same name as the partial. For more information, check out the documentation.

Technical Interview Redux

Mon, 22 Jul 2013 00:00:00 -0400

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.

Develop a system. I found this post about breaking down interview questions to be quite helpful.
Drill, drill, drill. The previous link mentions Topcoder as a good source of practice material. I actually prefer the Dailyprogrammer subreddit. The comments tend to be highly educational, with solutions in a variety of languages.
Warm up just before the interview. Lately I’ve been doing a problem or two on Dailyprogrammer just prior to the interview. Typically, I’ll choose an intermediate or easy problem, just to build confidence.

Technical Interview Brainfreeze

Fri, 19 Jul 2013 00:00:00 -0400

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.

Technical questions in the interview setting can be extremely tricky. Typically I’m already a bit edgy from meeting so many new people, and the additional mental strain of being so highly invested in a positive outcome is just too much. My creative faculties seem to just shut down, and when I’m faced with a challenging question and no creative juices it leads to a panic response. I’m desperately reaching out for resources that should be there, but in the interview room there’s…nothing. It is disconcerting, to say the least.

Once the process starts, it becomes self-reinforcing. Every passing second of staring at the empty whiteboard becomes an additional reason to doubt my capabilities. This downward spiral is very, very difficult to break. Here are a few strategies that have either worked for me, or are next on my list to try:

Go with what you know. Sometimes it can be a better strategy to answer a different, but related, problem that I’m already familiar with; then struggle unproductively with the problem I want to answer. If I can clearly walk through a familiar solution to a related problem, and articulate how it is related to the problem at hand, I’m expressing an understanding of the problem while building self-confidence.
Honesty. Sometimes I’ll just explain that I’m feeling nervous and ask for help. This won’t earn me any technical points, but it (hopefully) will let me recover from the downward spiral. Once I’m confident again, and the interviewer has a more accurate view of my skills, the earlier episode will be put in the proper context.
Ask questions. Questions serve two purposes. They clarify the problem, of course. More importantly for me, they buy time for my panic response to subside. If I can engage my interviewer in clarifying dialogue, it may distract my limbic system from the emergency it perceives. Once the limbic response is reduced, I can turn back to the problem with a clearer mind.
Breathing exercises. One of the most effective ways of dialing down a panicky limbic system is with slow, steady breathing. The key is to fully exhale with each breath. Done properly, you should feel a slight tension in the diaphragm at the end of each exhalation. Five repetitions is usually enough to start feeling more relaxed.

Give a shout in the comments if you’ve used any other strategies for working through technical interview brainfreeze.

When (not) to Nest Resources in Rails

Mon, 15 Jul 2013 00:00:00 -0400

In Rails, nested resources allow us to generate RESTful routes for heirarchical resources. If we were designing a blog, there might be a posts and a comments resource. We might have this in our routes.rb:

resources :posts do
  resources :comments
end

Rails will then generate paths like this: posts/1/comments/1. This is all great and useful stuff, but what about something like users and dashboards? We might be tempted to nest the dashboards resource under users, because dashboards are so closely related to users. There is an important question we must ask ourselves before we implement this scheme, and that is: “Do I expect this resource to be publicly available?”. In the case of dashboards, do we intend for users to publicly share their dashboards? In most cases, probably not.

We would prefer to keep our paths as simple as possible. If we do not intend for users to share their dashboards, then there is no good reason to nest. A novice developer might nest under a user resource and use the params of the URL to determine the currently logged in user. However, this presents a security problem, as anyone could pose as any user simply by modifying the URL. Authentication gems like Devise provide us with helper methods that return the logged in user, which we should be using exclusively if they’re available.

The Inflection Point

Fri, 12 Jul 2013 00:00:00 -0400

Something strange happened over the past 10 weeks at Launch Academy. Invisibly, imperceptibly, I’ve turned from a software hobbyist into a software developer. This fact only came to light a few days ago, and I’d like to share the story of how that happened.

It has been a challenging week. I’ve been working extremely hard to bring my project to a point where it is presentable. As a result, working on the project had become more of a chore than the pleasant exploration it usually is. Arriving home after another long day, I found that a friend had sent me a postcard with a Ruby cellular automaton algorithm written on the back. (Yes, I have awesome friends). Of course, I implemented it right away as a command line application, but I was immediately struck by the ways it could be adapted to function in a web app. Users could save and view lists of cellular automata, sorted by the initial conditions.

Building and deploying the app took under an hour. It is nothing special, but the capability to casually toss out such a thing is, to me, magical. I certainly couldn’t, or at least wouldn’t, have done it prior to Launch Academy. Even though it might have been in my technical capabilities to do so, the activation level was too high. That is, the amount of initial effort required to implement would have been too great.

The change from a hobbyist to a developer is more subtle, though. For example, I probably would have used a scaffold if I had attempted the app 10 weeks ago (Rails scaffolds are generally a sign of inexperience). I wouldn’t have known when a private method was appropriate. All these little pieces of knowledge converge into the capability to write not just functional software, but robust software,

As someone who loves to build things, I cannot adequately express the value of what I’ve learned over the past 10 weeks. Not just in terms of what I can build, but what I will build.

Mildly Complex Rails Seeding with YAML

Mon, 08 Jul 2013 00:00:00 -0400

It’s crunch time here at Launch Academy. Our projects have to be up and running with databases that will, you know, actually show off the functionality that we’ve worked 10 weeks to achieve. This means seeding, and depending on the complexity of our models and associations, seeding can go from a simple one-line script to, well, something like this:

module Seeders
  module Lessons
    class << self
      def seed
        Lesson.destroy_all
        lessons = []

        base_path = 'db/seed_data'
        Dir.glob(Rails.root.join(base_path, 'lessons', '*.yml')) do |file|
          lesson = YAML.load_file(file)
          this_lesson = Lesson.create(title: lesson['title'], summary: lesson['summary'])
          lessons << this_lesson
          lesson['activities'].each_with_index do |activity, index|
            completable = []

            if activity['type'] == 'Assignment'
              completable = Assignment.create do |assignment|
                assignment.title = activity['title']
                assignment.summary = activity['summary']
                assignment.instructions = activity['instructions']
                assignment.url = activity['url']
                assignment.assignment_type = activity['assignment_type']
              end
            elsif activity['type'] == 'Challenge'
              completable = Challenge.create do |challenge|
                challenge.title = activity['title']
              end
              activity['cards'].each do |card|
                new_card = Card.create do |c|
                  c.title = card['title']
                  c.instructions = card['instructions']
                  c.problem = card['problem']
                  c.solution_type = card['solution_type']
                  c.snippet = card['snippet'] if card['snippet'].present?
                end
                card['solutions'].each do |solution|

                  if card['solution_type'] == 'string'
                    sol = new_card.solution_strings.create do |solution_string|
                      solution_string.regex = solution['regex']
                      solution_string.canonical = true if solution['canonical']
                    end
                  elsif card['solution_type'] == 'position'
                    sol = new_card.solution_positions.create do |solution_position|
                      solution_position.start_position = solution['start_position']
                      solution_position.end_position = solution['end_position']
                    end
                  end

                  completable.cards << new_card
                end
              end
            end

            Activity.create do |lesson_activity|
              lesson_activity.completable = completable
              lesson_activity.lesson = this_lesson
              lesson_activity.position = index + 1
            end
          end
        end

        lessons
      end
    end
  end
end

This is the seeder for my project: Memworks. A major part of the app is lessons, each of which has assignments and challenges. There’s a lot of content, and my first approach was to just shove it all in big Ruby objects and require the relevant source files. I decided to shift to a YAML approach when the Ruby hashes became so large as to become unwieldy.

Since YAML supports arrays, we can leverage this to indicate associations in our models. Memworks lessons are YAML files with a structure like this:

title: "some title"
summary: "some summary"

assignments:
-
  title: "first assignment"
-
  title: "second assignment"

My script iterates through these YAML arrays and associates the assignments with their parent lesson. This is extremely handy with multiply nested hierarchies like mine, because YAML files are easily read and easily edited. Also, there’s great support for multiline strings. Multiline strings in YAML are smart about their indent level, so unlike Ruby, you don’t have to de-indent your big blocks of text.

Happy seeding!

Getting Started with Backbone.js on Rails

Sat, 06 Jul 2013 00:00:00 -0400

Going from near-zero experience with front-end MVC frameworks to a functional Backbone app has been something of a rough ride. I thought I’d share some lessons I’ve learned along the way. Keep in mind that I’m still learning, so much of this will be wrong. Corrections are welcome.

Setup It is relatively easy to download and manually install Backbone by copying the relevant files to your javascripts directory. I chose to use the backbone-on-rails gem instead, for reasons I’ll describe in a moment. This is not to be confused with backbone-rails which I avoided because it vendors an older version of Backbone.

Using the gem hooks up Backbone to the asset pipeline, which should improve page load times in production. It also provides us with a nice generator. After adding backbone-on-rails to the Gemfile, we can execute the following:
```
bundle install
rails g backbone:install
rails g backbone:scaffold MODEL
```
Passing in the name of the model, the generator will construct a directory structure and boilerplate files under app/assets/javascripts.
We put an MVC in your MVC The generated directories have a familiar structure, coming from Rails. Models is fairly self-explanatory. Views in Backbone are a little different and a fair bit more complex than in Rails. They tend to hold much more logic than a Rails view should. Further, they delegate presentation to a template. Backbone-on-Rails sets us up with a JST template for each view.

Confusingly, JavaScript templates are much more like a traditional Rails view than Backbone views. You’ll find the generated template in app/assets/templates, since JavaScript templates are not themselves JavaScript files. The final two directories are routers and collections, which I’ll go over next.
Collections and routers Backbone collections have no direct analogue in the Rails world. They are, basically, arrays of Backbone models. Since a major function of Backbone is syncing remote objects with the front end, collections are an important tool for keeping our objects organized.

The generator has also given us a router. Routers in Backbone are similar to Rails controllers. Unlike a Rails controller, there’s very little magic to make our lives easier. These two lines are critical to understanding how a router works:
```
view = new App.Views.ModelAction(collection: @someCollection, model: @someModel)
$('.container').html(view.render().el)
```
The first line is instantiating a new view, and passing in a collection and model. Note that collection and model are special keywords. They will be made available to the view directly, whereas passing in arbitrary key-value pairs can and will result in hair-pulling.

The second line is calling jQuery to update the DOM, replacing the contents of the .container element with the return value from view.render(). What that will be depends upon how we write the render function in the view. Typically, the render function will invoke the template, which will then be inserted into the DOM.

Phew! This just scratches the surface of Backbone.js. If you’d like to learn more, there are two excellent (and paywalled, unfortunately) RailsCasts: #323 and #325 that were incredibly helpful to me. Good luck!

Tick-Tock Synthesis

Mon, 01 Jul 2013 00:00:00 -0400

Synthesis is the phase of learning where we apply what we have learned in new ways. It is the point when we begin to understand how what we have learned connects with what we already know, and how those connections can be used to apply our new learning differently. I consider synthesis to be the most important part of my education at Launch Academy, so I’m extremely deliberate in the way I approach synthesizing new knowledge.

My approach can be compared with Intel’s famous “Tick-Tock” methodology. Every year, Intel with either “tick” by shrinking the size of the transistors on their processors, or they will “tock” by introducing a new architecture. The tick-tock approach limits the novelty, and hence the complexity, of each iteration.

by pbosakov

When I’m synthesizing a new, major piece of knowledge, I’ll “tick” by implementing the new knowledge in a safe environment. Safe, in this sense, means that poor implementation is acceptable and breaking stuff is strongly encouraged. In Launch Academy, my “tick” synthesis occurs in my side project: TimeVault. The freedom of the “tick” phase allows me to more quickly experiment and make inevitable mistakes.

The “tock” phase of synthesis involves implementing the new learning in fashion more consistent with industry best practices. In Launch Academy, my “tock” project has been Memworks. During the “tock”, my objective has been to meet or exceed what would be expected of a junior-level professional. The reasoning for this is twofold:

Becoming familiar with best practices, particularly in a field such as web development, is critical for quality output.
I will often use the result of my “tock” synthesis as reference material later on. The source for my “tock” project will serve as a yardstick against which I will measure future efforts.

I’m constantly looking for new ways to improve synthesis. If you have any tips, please give a shout in the comments!