DEV Community: Brian Kephart

Rendering Views through Action Cable with Devise and CanCanCan

Brian Kephart — Tue, 25 Aug 2020 20:53:00 +0000

This week I worked on rendering partials over websockets with Action Cable. I ran into a problem that tied into my authentication and authorization libraries (Devise and CanCanCan respectively).

In my app, Action Cable uses the following code to identify the current user. Something similar can be found in many articles about Action Cable authentication with Devise.

# app/channels/application_cable/connection.rb
module ApplicationCable
  class Connection < ActionCable::Connection::Base
    identified_by :current_user

    def connect
      self.current_user = env['warden'].user || reject_unauthorized_connection
    end
  end
end

When rendering views over Action Cable, for the most part I've been able to simply pass the current user as a local variable.

# app/channels/my_channel.rb
class MyChannel < ApplicationCable::Channel
  def subscribed
    stream_for current_user
  end
end

<!-- partial_with_local_variable.html.erb -->
Hello <%= current_user.name %>

# any ruby file
MyChannel.broadcast_to(
  current_user,
  ApplicationController.render(
    partial: 'partial_with_local_variable',
    locals: { current_user: current_user }
  )
)

# => "Hello Brian"

However, things get hairy when CanCanCan is involved.

<!-- partial_with_authorization.html.erb -->
<% if can?(:do_something, to_this_object) %>
  Here is the text I want to render.
<% end %>

# Any ruby file
MyChannel.broadcast_to(
  current_user,
  ApplicationController.render(partial: 'partial_with_authorization')
)

# => ActionView::Template::Error - Devise could not find the `Warden::Proxy` instance on your request environment. Make sure that your application is loading Devise and Warden as expected and that the `Warden::Manager` middleware is present in your middleware stack. If you are seeing this on one of your tests, ensure that your tests are either executing the Rails middleware stack or that your tests are using the `Devise::Test::ControllerHelpers` module to inject the `request.env['warden']` object for you.

The problem is related to the can? method. When called in a view, the call chain of that method includes the current_user method in the controller that renders the view. Since the method is called on the controller, setting a current_user variable in the view will not prevent this error.

The current_user method is defined by the Devise gem, which expects to have the variable request.env['warden'] set as a result of an HTTP request being passed through the Warden middleware. Since Action Cable communication is conducted over websockets instead of HTTP, this middleware is not used, the variable is not set, and the broadcast fails.

You might have noticed near the top of this post that there is a reference to env['warden'] in connection.rb. Since the Action Cable connection is established with an HTTP request, the Warden middleware is used and the environment variable we need is present at that time. The solution is to store that object as an attribute on the connection object and then pass it to the renderer when needed for subsequent communication over the websocket. There's a non-Action-Cable-specific description of how to do this in this article, but you can see my preferred version below.

# app/channels/application_cable/connection.rb
# updated from the version at the top of this post.
module ApplicationCable
  class Connection < ActionCable::Connection::Base
    identified_by :current_user
    attr_reader :warden

    def connect
      self.current_user = env['warden'].user || reject_unauthorized_connection
      @warden = env['warden'] if current_user
    end
  end
end

# app/channels/my_channel.rb
# also updated from the earlier example
class MyChannel < ApplicationCable::Channel
  def subscribed
    stream_for current_user
  end

  # This method will return ApplicationController.renderer with our Warden::Proxy instance added to the default environment hash.
  def renderer
    ApplicationController.renderer.tap do |default_renderer|
      default_env = default_renderer.instance_variable_get(:@env)
      env_with_warden = default_env.merge('warden' => connection.warden)
      default_renderer.instance_variable_set(:@env, env_with_warden)
    end
  end
end

# Any ruby file
MyChannel.broadcast_to(
  current_user,
  MyChannel.renderer.render(partial: 'partial_with_authorization')
)

# => Here is the text I want to render.

Collection Caching in Rails with Local Variables

Brian Kephart — Fri, 26 Jun 2020 20:20:42 +0000

Yesterday I was trying to improve the performance of collection rendering in my rails app. The page I was working on is a schedule, which renders many collections of various data types.

The basic method for rendering a collection in Rails using a specific view file is this:

<%= render partial: 'my_template', collection: 'my_collection' %>

For basic cases, you can add caching like this:

<%= render partial: 'my_template', collection: 'my_collection', cached: true %>

My problem is that different user have different permissions to act on items on the schedule, so the rendering is specific to the user. This requires caching the current_user as a local variable.

I could not find this anywhere in the Rails guides or docs, but I did find the option in the code. The syntax is this:

<%= render partial: 'my_template',
           collection: 'my_collection',
           cached: ->(collection_item) { [collection_item, current_user] } %>

If that syntax is unfamiliar, it's a lambda literal. It will be called for each item in the collection, using that item as an argument. I'm using the lambda to return an array that will be used to make the cache key. This works beautifully for my purposes.

Now, normally with Rails, any methods or syntax not in the guides or API docs are subject to change without deprecation, putting you on thin ice. You're at risk of relying on code that the framework maintainers consider an implementation detail, not public API. In this case, though, the git blame led me to this pull request in which it seems pretty clear that this feature was added for public use.

I'm posting this as a discussion to see if anyone else is using this feature, or knows its history, or knows a reason not to use it.

Mac users, recommend me a booklet printer!

Brian Kephart — Sat, 23 Mar 2019 04:15:33 +0000

The music school I work at currently uses a Konica Minolta Bizhub 364e. One of these:

Ever since MacOS Mojave came out, Apple's own apps are unable to use all of this printer's advanced features. The problem is, most of our curriculum books are laid out in Pages, which is one of the affected apps, so printing our books has become a pain.

At first I thought this was a bug that would be quickly fixed, but I learned here that it is due to an intentional change in the way Apple handles printer drivers. Many brands are affected. In the case of our printer, the manufacturer lists their 2016 driver as fully compatible, so it doesn't seem like they intend to change anything.

Can anyone recommend me a good multifunction booklet printer that fully supports Mojave?

The requirements:

Color laser.
Copier with flatbed and auto document feeder.
Scan to email.
4 paper trays, cardstock capable, sizes up to 11x17.
Booklet printing with center staple & fold.
Support for all printer features on all Apple apps, including Pages and Preview.

Many thanks!

75 people followed me yesterday. Why?

Brian Kephart — Tue, 26 Feb 2019 17:26:44 +0000

I used to get a few follows most days. That tapered off since I haven’t been posting lately. I haven’t had a new follow in weeks. In the past day, though, 75 people have followed me and I don’t know why. Has anyone else experienced this?

Don’t get me wrong, new followers are great, but the suddenness seems fishy.

Template design pattern in Ruby. Any reason not to use a module instead of a superclass?

Brian Kephart — Sat, 09 Feb 2019 21:13:53 +0000

The classic template design pattern uses inheritance to declare which methods its subclasses must define, like so:

class Template
  ABSTRACT_METHOD_ERROR = 'You forgot to define that method.'

  def method_defined_in_class
    raise ABSTRACT_METHOD_ERROR
  end

  def method_not_defined_in_class
    raise ABSTRACT_METHOD_ERROR
  end
end

class ObjectFromTemplate < Template
  def method_defined_in_class
    'You remembered! No errors here.'
  end
end

obj = ObjectFromTemplate.new

obj.method_defined_in_class # => 'You remembered! No errors here.'

obj.method_not_defined_in_class # => RuntimeError (You forgot to define that method.)

I have been wondering if there is a reason not to use a module for the template instead.

Module Template
  ABSTRACT_METHOD_ERROR = 'You forgot to define that method.'

  def method_defined_in_class
    raise ABSTRACT_METHOD_ERROR
  end

  def method_not_defined_in_class
    raise ABSTRACT_METHOD_ERROR
  end
end

class ObjectWithTemplate
  include Template

  def method_defined_in_class
    'You remembered! No errors here.'
  end
end

obj = ObjectWithTemplate.new

obj.method_defined_in_class # => 'You remembered! No errors here.'

obj.method_not_defined_in_class # => RuntimeError (You forgot to define that method.)

The second way seems obviously better to me (for all the reasons that composition is generally to be favored over inheritance), but I've never seen it done this way. Any thoughts or experiences to share?

Dropdowns Without Javascript

Brian Kephart — Tue, 28 Aug 2018 22:52:00 +0000

A few months ago I had to add a dropdown menu to a project that did not use a frontend framework with dropdown menus built in. I decided to see if I could make a dropdown menu without JavaScript. My approach is a hybrid of that found in these posts:

Click to Open

The menu I made requires a click to open. To accomplish something similar, create a hidden checkbox with a visible label. Here, we'll use the dev.to logo for the label. When the label is clicked, the checkbox will be checked, even though it remains hidden.

This code uses the CSS general sibling combinator ~ to select the #collapse-menu that follows the input:not(:checked) and scale its height to 0. When the input is checked, that style no longer applies, so the scaleY value returns to its default value of 1 and the menu appears. The transition is set to 0.3 seconds so that the menu opens gradually instead of instantly, and the transform-origin property ensures that the menu appears from the top down instead of expanding from the center.

Hover to Open

If you prefer that your menu opens when you hover over the icon, then there is no need for <checkbox> or <label> tags. Instead, scale the #collapse-menu to 0 to hide it when it is not hovered (implying that it will return to full height when hovered). You will also need to scale the #collapse-menu to 1 when the icon is hovered. We will use the general sibling combinator ~ again to accomplish that. Last, you should introduce a delay to the transition. Otherwise when the user moves their pointer from the icon to the list, the menu will begin to collapse and then re-open. A tiny delay (0.2 seconds in this example) smooths things out.

I have intentionally kept these examples simple for ease of learning, but don't forget to think about accessibility when using these elements! Don't rely on hover behavior alone unless you're sure all of your users can use that behavior. For example, the app I mentioned earlier adds the line &:focus-within { transform: scaleY(1); } to the CSS for the #collapse-menu, so users navigating the site with a keyboard will see the menu expand when they tab through to one of its options.

EDIT: There are comments below complaining about the accessibility of these solutions. These issues are addressed in one of the links posted above, which I'm re-posting here: https://css-tricks.com/solved-with-css-dropdown-menus/

There is a lot more that can be done with dropdown menus in pure CSS. Add your favorite tricks in the comments!

Adding Code Quality Checks To Your Ruby Test Suite

Brian Kephart — Wed, 15 Aug 2018 00:00:00 +0000

Over time I've integrated a few static analysis tools into my workflow. These have been extremely helpful in maintaining high quality code, but running them manually is tedious. For many projects, this would be automated in some kind of CI pipeline. For my current project, however, there is no automated CI pipeline. This app is deployed to Heroku straight from the command line. So, I decided to see if I could integrate these tools into my test suite, reducing manual quality checks to a single step.

Tool #1: Brakeman

Since I started learning Rails development, I have been using Brakeman to scan my code for security vulnerabilities. This tool uses static analysis to check for vulnerabilities to attacks like SQL injection and cross-site scripting. Brakeman was designed to be run from the command line, but a little digging into the docs revealed that it can be run as a Ruby library within an app. Following these instructions, I opened up a Pry console and ran:

require 'brakeman'
=> true
Brakeman.run Rails.root.to_s
=> #<Brakeman::Tracker:0x00007fde2d546da8 ... tons of output in this object

That object had way too much output to read. Next, I ran the same command, but stored the result as a variable...

result = Brakeman.run Rails.root.to_s
=> # same result as before

... so I could query its methods and attributes:

result.methods.sort
=> [:warnings] # There were tons of other methods in this array
result.warnings
=> []

result.instance_variables.sort
=> [:@errors] # Lots more here too
result.errors
=> [{:error=>"/Users/briankephart/Sites/some_app/app/jobs/some_job.rb:14 :: parse error on value \"**\" (error)",
   :backtrace=>["Could not parse /Users/briankephart/Sites/some_app/app/jobs/some_job.rb"]}]

As you can see, I had no security warnings, but one error due to Brakeman failing to parse a ** operator. This was helpful in showing me that the errors are readable in this form. Note that both the errors and warnings are returned as Arrays.

Using what I learned in my Pry console, I wrote the following test:

class BrakemanTest < ActiveSupport::TestCase
  require 'brakeman'

  test 'no brakeman errors or warnings' do
    result = Brakeman.run Rails.root.to_s
    assert_equal [], result.errors
    assert_equal [], result.warnings
  end
end

This worked perfectly. I could see the Brakeman output during my test run, and the test responded correctly to the error seen above.

Tool #2: RuboCop

I've recently been using RuboCop in a lot more of my work to check for syntax errors, good styling, and general readability. Like Brakeman, Rubocop is designed as a command line tool. Unlike Brakeman, the docs were not helpful to me in using it any other way. Instead, I had to dive into the source code. The most important line I found was here, in the file that defines the command line executable. The important points:

require 'rubocop'
cli = RuboCop::CLI.new
result = cli.run

What I needed to do was instantiate a RuboCop::CLI object and call its #run method. Looking at those files, I found that the #initialize method takes no arguments, while the #run method takes all arguments from the command line as an array (I usually run rubocop on the command line without arguments, though). Back to the Pry console:

require 'rubocop'
=> true

RuboCop::CLI.new.run
# Inspecting 397 files
# ...
#
# 397 files inspected, no offenses detected
=> 0

Notice that the return value is 0. Knowing this, I wrote the following test:

# Do not use this code
class RubocopTest < ActiveSupport::TestCase
  require 'rubocop'

  test 'no rubocop offenses' do
    assert_equal 0, RuboCop::CLI.new.run
  end
end

I noticed something strange, though. When I ran my full test suite, RuboCop checked all my files, but when I ran the test above on its own, RuboCop only checked that test file. The context in which I called the test became the context for RuboCop. The fix for this was to add a path argument to the run method, just as RuboCop allows a path argument on the command line.

# Use this instead of the code above
class RubocopTest < ActiveSupport::TestCase
  require 'rubocop'

  test 'no rubocop offenses' do
    cop = RuboCop::CLI.new
    args = [Rails.root.to_s]
    assert_equal 0, cop.run(args)
  end
end

Tool #3: Bundler Audit

Bundler Audit checks your Gemfile.lock for known-vulnerable versions of gems. This tool is pretty wedded to the command line, to the point where it proved easiest to just run system commands.

class RubocopTest < ActiveSupport::TestCase
  require 'bundler/audit/cli'

  test 'no vulns in bundle' do
    `bundle audit update -q` # Update vulnerability database
    result = `bundle audit`  # Run the audit
    code = `echo $?`.squish  # Returns '0' if successful, otherwise '1'

    # Print the scan result as the error message if it fails.
    assert_equal '0', code, result

    # If successful, output the success message
    puts "\nMessage from bundler-audit: #{result}"
  end
end

That's all! With these three small tests, I can check my code style and security whenever I run my test suite, with no extra steps.

Explain Generics Like I'm Five

Brian Kephart — Sun, 10 Jun 2018 19:17:20 +0000

I often see discussion about generics, but I've never really grasped what they are. I'm a Ruby/Rails developer, and the term doesn't seem to be used in that community.

Passing Arguments to StimulusJS Controllers

Brian Kephart — Fri, 08 Jun 2018 02:10:00 +0000

This week I installed StimulusJS into a Rails app that I've been developing. So far it seems like a good fit, helping me to organize and re-use Javascript functions without the hassle and overhead of a large framework. I'm a Rubyist at heart, so this minimal approach to Javascript fits me better than some of the other currently popular options. At least, that's my suspicion after using it for a few days.

If you haven't used StimulusJS, it revolves around controllers written in Javascript. These controllers access HTML elements specified by data attributes:

data-controller indicates which controller contains the relevant JS code,
data-target indicates that an HTML element is relevant to the JS code and gives it a name,
data-action indicates that a change to this element triggers a specific controller action.

Here's an example similar to one that I coded yesterday. Our business uses a variety of billing contract types, each with its own monthly cost. There is a contract type model that contains the default cost for contracts of that type. In my form for making a new contract, I wanted the monthly_cost of the Contract to change to the default_cost of the ContractType whenever a new ContractType is selected.

<!-- contracts/new.html.erb (not working) -->

<form data-controller="contracts">
  <select name="contract[contract_type]" id="contract_contract_type"
  data-target="contracts.contractType" data-action="contracts#updateCost">
    <!-- options for each contract type, containing name & id -->
  </select>
  <input type="number" name="contract[monthly_cost]" id="contract_monthly_cost"
  data-target="contracts.monthlyCost">
</form>

Here's the Stimulus contracts controller:

// contracts_controller.js (not working)

import { Controller } from "stimulus"

export default class extends Controller {
  static targets = [ "contractType", "monthlyCost" ]
  updateCost() {
    const contractTypeId = String(this.contractTypeTarget.value) // value from select box
    const monthlyCost = this.monthlyCostTarget // field to fill in
    const contractTypeCost = 'Uh-oh' // How do we get contractType's default cost?
    monthlyCost.value = Number(contractTypeCost).toFixed(2)
  }
}

A few things to notice:

The data-target elements from the HTML are listed in the controller's targets array, and each element of that array is available in the class by adding the Target suffix to the element's name. For example, data-target="contracts.contractType" is listed in the target array of the contracts controller as contractType, which is then accessed in the JS code as this.contractTypeTarget.
Stimulus watches for changes to DOM elements that have a data-action attribute, so when the select box value is changed, the contracts controller will execute the updateCost() function.
There is a problem. The default_cost of each ContractType is stored in the database and not immediately accessible to the client-side Javascript code. The select box only contains the name and id of each option. How could I fix this?

The first thing I tried to do was to pass parenthetical arguments via the data-action attribute. This did not work. Stimulus is not designed to be used in that way.

I considered setting up an API call to query the database, but that seemed like a lot of work. The primary purpose of frameworks is to make things simpler, and making additional HTTP requests to API endpoints that don't exist yet is not a simple solution.

Thankfully, there's a much easier way. I chose to add the relevant pricing information into the dataset of the select element.

First, I prepared the data in the Rails controller as a JSON object:

# contracts_controller.rb

# Create JSON object
# key = contract_type.id, value = contract_type.default_cost
@contract_types = ContractType.all.order :name
@contract_type_data = @contract_types.pluck(:id, :default_cost).to_h.to_json

... then I added it to the select box as a data-info attribute (there's nothing special about data-info; any unused data attribute would work):

<!-- contracts/new.html.erb -->

<form data-controller="contracts">
  <select name="contract[contract_type]" id="contract_contract_type"
  data-target="contracts.contractType" data-action="contracts#updateCost"
  data-info="<%= @contract_type_data %>">
    <!-- options for each contract type -->
  </select>
  <input type="number" name="contract[monthly_cost]" id="contract_monthly_cost"
  data-target="contracts.monthlyCost">
</form>

... and finally, here it is in the Stimulus controller:

// contracts_controller.js

import { Controller } from "stimulus"

export default class extends Controller {
  static targets = [ "contractType", "monthlyCost" ]
  updateCost() {
    const contractTypeId = String(this.contractTypeTarget.value) // value from select box
    const contractTypesInfo = JSON.parse(this.contractTypeTarget.dataset.info) // data object
    const monthlyCost = this.monthlyCostTarget // field to fill in
    const contractTypeCost = contractTypesInfo[contractTypeId]
    monthlyCost.value = Number(contractTypeCost).toFixed(2)
  }
}

Now when a user selects a ContractType in the select box, the value of that box is used as a key to access a JSON object containing the correct default_cost.

Is there any problem with this solution? Not from my perspective, although a large enough data object would look pretty strange crammed into an HTML data-info attribute. If there was a huge data object or sensitive data involved, then an API call with a narrower query to the database would probably be better so as to be more specific about which data reaches the client. In this case however, I'm pleased with this solution, as well as with Stimulus in general.

What hobby/skill do you wish you pursued more regularly?

Brian Kephart — Sun, 06 May 2018 18:41:44 +0000

Today I played my upright bass for the first time in a couple years. I'm always pleased to get it out and find that my skill on it isn't completely gone, but I'm always bummed that I don't get to give it the time that it deserves.

What skill/hobby do you always wish you were pursuing more regularly?

(My honorable mention: building guitar effects)

My Experience as a RailsConf Opportunity Scholar

Brian Kephart — Tue, 17 Apr 2018 23:24:00 +0000

The Ruby Central Opportunity Scholarship Program

Over the last four days I attended RailsConf as an Opportunity Scholar. Ruby Central offers these scholarships at both RailsConf and RubyConf. According to their website, the program is "open to anyone who would not normally attend, though we specifically encourage students, women, minorities, and other underrepresented groups in the technology sector to apply." The scholarship includes a free conference ticket, a guide to help you through your first conference experience, and a variety of activities to help scholars and guides build their relationships within the larger community of the conference.

I applied because I do not have much contact with other developers, I could not afford my own ticket, and I felt somewhat lost at the only previous conference I had attended. I am not a part of any underrepresented group, though many of the other scholarship recipients were.

From what I can tell, this program is not very widely known. I stumbled across a link to the description page on the day of the application deadline, and while writing this post I couldn't find the page on the site without googling it. Some of the conference attendees that I met who had been attending RailsConf for years didn't know about it. I write this in the hope that someone who didn't know about this program will be able to attend a conference for the first time because of it, or will choose to mentor a first-time attendee as their conference guide.

beginning_of_conference - 2.weeks

My guide was Ariel Caplan, founder of the Dev Empathy Book Club. He got in touch and set up a video chat for us to get to know each other. We spent about two hours breaking the ice and planning for the upcoming conference. This was great, because it meant I already knew one person before getting to RailsConf.

The scholars and guides were also invited to a Slack channel in the weeks before the conference. This was a good way to chat and ask questions. Some people made arrangements to share rides or accommodations. There were also a few planned Q & A sessions.

Day[0]

The conference took place Tuesday through Thursday, but scholars and their guides had a get-to-know-you session on Monday before the conference was in full swing. I got to meet quite a few people, some of whom I was familiar with from tech blogs, Twitter, Github, or other public arenas. I was pretty exhausted from travel, but it was nice to learn some names and faces for the upcoming events.

Day[1]

Scholars and guides have a reserved section during keynotes, so I was front row center for DHH's opening talk. I was expecting something about the direction of Rails now that development has begun on version 6, but the presentation was more philosophical than that, about how the mission of Rails is to empower developers to make better apps, in less time, with fewer barriers to entry than any other framework. This focus is why I got started in Rails development. It's also very necessary in a time when web development is getting continually more complicated. We in the Rails community are all going to be hearing a lot about "Conceptual Compression," and it started right here.

All day, I kept running into people I knew. Even though there were 1500+ people at this conference, I bumped into the one attendee that I know from my hometown four different times. I frequently encountered people that I had met at Monday's event as well.

At lunch I sat down with a couple of strangers. We were already getting to know each other when we were joined by several other people. Starting conversations is always a bit difficult for an introvert like me, but at a place like RailsConf, keeping them going is easy. Everyone there shares a common interest, and everyone I met was genuinely interested in my job, my application, and how I got into coding.

This includes DHH, to whom I was introduced by Ariel. I'm one of the developers empowered by Rails, and it was gratifying to get to tell him that. No one is off limits at RailsConf.

Tuesday night featured a jam session. Since I work at a music school, I knew I had to go, so I went and got to play music for hours with some other developers. One of them came because I had told him about the jam session at lunch earlier in the day.

After the jam session, I went to the hotel restaurant by myself for dinner. I spotted another lunch acquaintance at the bar and he joined me at my table, where we were later joined by two developers from California. Walking into a restaurant by myself turned into hours of conversation.

The theme of this entire day was that we are building a community of developers. You can feel it when you're here, where even in the course of a single day relationships are being built as you encounter people again and again who care about the things you make.

Day[2]

Wednesday opened with a keynote by Eileen Uchitelle. The topic was Rails 6, specifically the plan to make Rails 6 scalable by default. Two major bottlenecks to scaling an app are using a single database and running a large test suite, so the plan is to have Rails support multiple databases and parallel testing out of the box. I don't use multiple databases and don't plan to in any current project, but I'm excited about parallel tests. This is something I've tried (and failed) to implement in the past, so I can't wait to see it provided in a usable way.

After the keynote, the sponsor booths opened. It was fun to walk around the booths and bump into people I'd met during the previous two days. In addition to general conference sponsor swag, there was a massage station, and the Github booth had baristas serving espresso drinks.

The advice I received from the guides was to prioritize workshops over talks, and I found this to be generally good advice. The talks will eventually be available on Youtube, but the workshops are one-time participatory events. Wednesday's workshops were excellent, and I learned a lot about end-to-end testing and Progressive Web Apps.

In lieu of a keynote at the end of the day, there was a conference happy hour followed by lightning talks. My lack of sleep and general introvertedness caught up to me during happy hour, so I was less successful at mingling and holding conversations than I had been on the previous day. My guide and I did get a chance to plan for our activities the next day, though.

I missed the lightning talks to attend a dinner with a couple of family members who live in Pittsburgh. I'll note that a handful of lightning talk time slots are reserved for Opportunity Scholars, so the opportunity to give a five-minute presentation is available for those who want it. These talks are not necessarily about Rails, Ruby, or even programming at all (though they certainly can be).

Lightning talks were followed by #RubyKaraoke. Fun times!

Day[3]

Thursday's opening keynote was given by Sarah Mei, and was an updated version of the talk I heard her give last fall about making code livable. Even though I already heard it in its previous form, it was well worth hearing again. The most important point is that software isn't just code or just people, it's a system that includes them both. In a world where developers live in a codebase for an extended period of time, it's important that the code is livable, and that means the code is clean enough to use, add features, and refactor, but not with such rigidly enforced "clean" practices that it becomes inflexible. That summary doesn't do justice to her presentation, so please look it up if you are interested.

After the keynote, there were more talks and workshops. I got to meet Ben Halpern, the founder of Dev.to, in person at his talk.

I found out on the last day of the conference that there was a special section in the cafeteria set aside for scholars and their guides. This was announced in a Slack channel before the conference began, but I either did not see it or forgot about it, so on the previous two days I'd had lunch with strangers. That was great, since I met several new people with whom I continued to engage throughout the conference, but it meant that I did not spend as much time connecting with the other scholars as I would have liked. On Wednesday, though, I found the group at lunch. At this point the conference was winding down and the leaders of the Opportunity Scholar program were taking feedback about how the conference went.

After the afternoon activities, Aaron Patterson gave the closing keynote. His talk was highly technical and dealt with using Ruby tools to benchmark the performance of various Rails operations. The purpose behind it was that he wants measuring performance to be easier, to make fixing bottlenecks easier, to make scaling applications easier, to make scaling teams easier. Right now, performance measurement of this type is obscure, and Aaron wants to put it into the reach of generalists. His future is one in which you don't need a 10x Ruby guru to scale Rails, because Rails has tools that any developer can easily use to accomplish that.

Following the keynote, several of the scholars and guides went out for pizza. I had a great chance to get to know some of them better, since I had missed a couple of lunches with them earlier in the conference.

After dinner was the RailsConf board game night, a fun way to close out a great conference.

What I learned

I learned a lot of things about technical topics, but that was expected. It's not necessary to attend a conference hundreds of miles from home to learn technical concepts – we have Google and Youtube for that. I came to be immersed in the culture surrounding software development in general and Rails in particular.

The most important thing I learned is that I already know significant things. As a newer developer who is self-taught, it's easy to think that more experienced developers are way ahead of me. They're not. Throughout the week I heard many developers ask questions that I already knew the answers to. I attended some workshops where I had trouble keeping up, but the other developers around me had the same struggles. I talked to some of them afterwards, and they were relieved not to be the only ones that fell behind. Sharing my challenges made them feel better, and vice versa.

This is not to say that I've arrived, or that I have any particular level of skill. Rather, it's to say that in this field, which is both broad and deep with specialized skills, I'm in no worse position than anyone else. We all have some skills and knowledge that others don't, and we all have something to learn from those same people. Watching experienced developers go through the conference, having the same experiences I did, was hugely validating.

I also learned that the Rails community is full of caring people. Every time I met a new person, they asked me about my work, and not just in passing. There were follow-up questions and expressions of interest. By the last day I was starting to feel like a jerk, because frequently these questions would have me talking about my own projects until we were interrupted and I wouldn't get a chance to ask what the other person was working on. Everyone I met was genuinely more interested in talking about my project than their own.

I also learned that conferences are also exhausting for everyone. Not everyone goes to the evening events. Most people don't attend every single session. Breaks are okay. I tried to go to everything I could, but I attended a couple of mingling events while I was exhausted and skipped the lightning talks to spend time with family. You can't be at your most engaged for 3-4 days straight, plus evenings. There's more than enough in the course of the conference to make up for a missed activity.

I hope I get to return to RailsConf next year, and I hope to one day be a guide for a new Opportunity Scholar. If you haven't been to a RailsConf or RubyConf, apply to be an Opportunity Scholar. I will post a link on my Twitter account when it's available.

Testing Bidirectional Associations in Rails

Brian Kephart — Wed, 28 Mar 2018 13:36:00 +0000

One thing I've discovered about being (1) self-taught and (2) the only developer in my workplace is that when I learn a new technique, I'm never sure how common it is. Recently, I was discussing some tests that I wrote with a more experienced developer, and it turned out that the technique I used was one he hadn't seen before.

Some background

When I wrote these tests, I was in the early stages of building a large app for the music school where I work. At this time, we knew very little about what we wanted as far as user interface, screens, happy path, and so on. However, since the school is very well-established and the app is being built to support our current practices, I knew very well what data we needed to model and how the models should relate to one another. This put me in a strange position where, instead of building features top-to-bottom, my only path to productivity was to build our data models. This led to me creating several dozen models that don't do much of anything yet, but contain the structure of our data to support future feature development.

At this point, I had yet to use Test-Driven Development in any form, so I sought to employ it as I created these models. Most particularly, I wanted to use it to make sure the associations between my models were correct. I used the default Rails testing stack of Minitest with fixtures, no Rspec or factories.

The Problem

When making this many models, it would be easy to accidentally omit an association on one model that is present on an associated model, like so:

# app/models/parent.rb
has_many: :children

# app/models/child.rb
# OOPS! Nothing here. Should say has_one: :parent

I wanted to be able to write this in my tests:

class ParentTest < ActiveSupport::TestCase
  test "Parent associations" do
    check_bidirectional_associations Parent
  end
end

class ChildTest < ActiveSupport::TestCase
  test "Child associations" do
    check_bidirectional_associations Child
  end
end

I found an ActiveRecord method to help me: Model.reflect_on_all_associations (docs). This method would return an array of associations defined on the current model. Since I was using fixtures in my tests anyway, I could get the first instance of the associated model from the fixture file, then check to see if it had the inverse association defined on it as a method.

First, I have to make sure there is an instance of the model in the fixture file. Models are called in tests by using the model name as a singular constant. Example: SomeModel.first, not some_model.first or SomeModels.first

def check_bidirectional_associations(model)
  associations = model.reflect_on_all_associations
  associations.each do |assoc|
    # attempt to assign the first instance of model to a variable. Must first convert assoc[:name] to singular constant.
    assert associated_object = assoc.name.to_s.singularize.camelize.constantize.first
  end
end

Now, if there is no fixture, the test will fail. It needs an error message, though.

assert associated_object = assoc.name.to_s.singularize.camelize.constantize.first,
       "#{assoc.name.to_s.camelize} not present in fixtures. Check test/fixtures/#{assoc.name.to_s.pluralize.underscore}.yml"

That's better. Now if the fixture is missing, the test tells me which file to fix. On to the next step, checking the association. First, I need the model name as a method:

model_method = model.to_s.underscore

Now to see if the associated_object responds to model_method:

assert associated_object.respond_to?(model_method)

Of course, some associations are plural. Better make it:

assert associated_object.respond_to?(model_method) || associated_object.respond_to?(model_method.pluralize)

Better. Now for the error message when the test fails:

assert associated_object.respond_to?(model_method) || associated_object.respond_to?(model_method.pluralize),
       "#{associated_object.class.to_s.camelize} is not properly associated with #{model.to_s}. Check for the correct association in app/models/#{assoc.name.to_s.underscore}.rb."

Awesome! Now I have a test that will tell me when the relationship between two models is only defined on one of them. Here's the method, defined in test_helper.rb:

# test/test_helper.rb
class ActiveSupport::TestCase
  def check_bidirectional_associations(model)
    associations = model.reflect_on_all_associations
    associations.each do |assoc|
      assert associated_object = assoc.name.to_s.singularize.camelize.constantize.first,
             "#{assoc.name.to_s.camelize} not present in fixtures. Check test/fixtures/#{assoc.name.to_s.pluralize.underscore}.yml"
      model_method = model.to_s.underscore
      assert associated_object.respond_to?(model_method) || associated_object.respond_to?(model_method.pluralize),
             "#{associated_object.class.to_s.camelize} is not properly associated with #{model.to_s}. Check for the correct association in app/models/#{assoc.name.to_s.underscore}.rb."
    end
  end
end

Now it gets complicated

Of course, ActiveRecord has many types of associations. The test above won't work for all of them. Some cases are best skipped:

associations.each do |assoc|

  # not necessarily bidirectional
  next if assoc.options[:through].present?

  # polymorphic has_many or has_one
  next if assoc.options[:as].present?

  # polymorphic belongs_to
  next if assoc.options[:polymorphic].present?


  # test it

  end
end

And others need modification:

associations.each do |assoc|

  # stuff from previous example

  # self join (model has an association to the same model)
  if assoc.klass == model
    assert assoc.options[:inverse_of].present?,
           "Only half of a self-join association is defined in app/models/#{model.to_s.underscore}.rb. The inverse of :#{assoc.name} is not defined."
    assert model.first.respond_to? assoc.options[:inverse_of],
           "The inverse of :#{assoc.name} is not functioning correctly. Check app/models/#{model.to_s.underscore}.rb."

  # Explicitly defined inverse association. Must have an inverse defined in both models.
  elsif assoc.options[:inverse_of].present?
    assert associated_object = assoc.klass.first,
           "#{assoc.name.to_s.camelize} not present in fixtures. Check test/fixtures/#{assoc.name.to_s.pluralize.underscore}.yml.\nAssociation name: #{assoc.name}\nAssociated object: #{assoc.klass}"
    model_method = assoc.options[:inverse_of].to_s
    assert associated_object.respond_to?(model_method) || associated_object.respond_to?(model_method.pluralize),
           "#{associated_object.class.to_s.camelize} is not properly associated with #{model.to_s} via :#{model_method}. Check for the correct association in app/models/#{model.to_s.underscore}.rb."

  # Using an alias to reference another model. Should probably have inverse relationships explicitly defined.
  elsif assoc.name != assoc.klass
    assert associated_object = assoc.klass.first,
           "#{assoc.name.to_s.camelize} not present in fixtures. Check test/fixtures/#{assoc.name.to_s.pluralize.underscore}.yml"
    model_method = model.to_s.underscore
    assert associated_object.respond_to?(model_method) || associated_object.respond_to?(model_method.pluralize),
           "#{associated_object.class.to_s.camelize} is not properly associated with #{model.to_s} using :#{model_method} as the inverse of :#{assoc.name}. Check for the correct associations and :inverse_of attributes in app/models/#{assoc.klass.to_s.underscore}.rb and app/models/#{model.to_s.underscore}.rb."

  # Normal bidirectional association
  else
    # do the stuff from earlier
  end
end

The Good

This method was extremely helpful to me in defining my data structures. I was able to develop quickly, knowing that my tests would warn me if I didn't get my associations right, with helpful error messages about which files to check. All I had to do was add check_bidirectional_associations ModelName to each of my model test files.

The Less Good

That is a huge conditional statement! No really, I didn't even put the whole method up yet. Here:

def check_bidirectional_associations(model)
  associations = model.reflect_on_all_associations
  associations.each do |assoc|
    # not necessarily bidirectional
    next if assoc.options[:through].present?

    # polymorphic has_many or has_one
    next if assoc.options[:as].present?

    # polymorphic belongs_to
    next if assoc.options[:polymorphic].present?

    # self join
    if assoc.klass == model
      assert assoc.options[:inverse_of].present?,
             "Only half of a self-join association is defined in app/models/#{model.to_s.underscore}.rb. The inverse of :#{assoc.name} is not defined."
      assert model.first.respond_to? assoc.options[:inverse_of],
             "The inverse of :#{assoc.name} is not functioning correctly. Check app/models/#{model.to_s.underscore}.rb."

    # Explicitly defined inverse association. Must have an inverse defined in both models.
    elsif assoc.options[:inverse_of].present?
      assert associated_object = assoc.klass.first,
             "#{assoc.name.to_s.camelize} not present in fixtures. Check test/fixtures/#{assoc.name.to_s.pluralize.underscore}.yml.\nAssociation name: #{assoc.name}\nAssociated object: #{assoc.klass}"
      model_method = assoc.options[:inverse_of].to_s
      assert associated_object.respond_to?(model_method) || associated_object.respond_to?(model_method.pluralize),
             "#{associated_object.class.to_s.camelize} is not properly associated with #{model.to_s} via :#{model_method}. Check for the correct association in app/models/#{model.to_s.underscore}.rb."

    # Using an alias to reference another model. Should probably have inverse relationships explicitly defined.
    elsif assoc.name != assoc.klass
      assert associated_object = assoc.klass.first,
             "#{assoc.name.to_s.camelize} not present in fixtures. Check test/fixtures/#{assoc.name.to_s.pluralize.underscore}.yml"
      model_method = model.to_s.underscore
      assert associated_object.respond_to?(model_method) || associated_object.respond_to?(model_method.pluralize),
             "#{associated_object.class.to_s.camelize} is not properly associated with #{model.to_s} using :#{model_method} as the inverse of :#{assoc.name}. Check for the correct associations and :inverse_of attributes in app/models/#{assoc.klass.to_s.underscore}.rb and app/models/#{model.to_s.underscore}.rb."

    # Normal bidirectional association
    else
      assert associated_object = assoc.name.to_s.singularize.camelize.constantize.first,
             "#{assoc.name.to_s.camelize} not present in fixtures. Check test/fixtures/#{assoc.name.to_s.pluralize.underscore}.yml"
      model_method = model.to_s.underscore
      assert associated_object.respond_to?(model_method) || associated_object.respond_to?(model_method.pluralize),
             "#{associated_object.class.to_s.camelize} is not properly associated with #{model.to_s}. Check for the correct association in app/models/#{assoc.name.to_s.underscore}.rb."
    end
  end
end

Huge conditionals are generally regarded as a code smell. I'm not really concerned here, though, because these tests are explicitly designed to enable fast development and they did that extremely well. Once the models contain business logic that is under test, this method no longer serves a purpose. Anything that would cause this method to fail should cause other tests to fail as well. In other words, these are the kinds of tests I won't refactor if they turn red later on. I'll just delete them, and work on getting my other tests green.

Is this good practice? I'd say generally not. I doubt many developers need to make dozens of models that don't contain any significant logic to test. This was a solution to a specific problem, at a specific stage of development. It was a great learning experience, though, and it helped me get comfortable with the general practice of TDD. It was also gratifying to write a test helper method that I was able to reuse in all of my model tests, because the time I invested in it payed off many times over.