DEV Community: Kevin Murphy

Rails Controller Callback Order With Concerns

Kevin Murphy — Tue, 20 May 2025 00:08:28 +0000

How can I help you today?

We're building an app to display the prompts from an automated phone system. The system will read these out when people call our technical support phone number. We use a callback to set the list of prompts to read. Whether you're calling for details about consuming our GraphQL endpoints or looking for tips on charging your phone battery, you're going to hear these messages first.

Our controller action renders that list.

class TechSupportPromptsController < ApplicationController
  before_action :set_prompts

  def show
    render inline: "<%= @prompts.join(' - ') %>"
  end

  private

  def set_prompts
    @prompts = []
    @prompts << "Thank you for calling technical support."
    @prompts << "Call volume is higher than expected."
    @prompts << "Press 9 to receive a call back when an agent is available."
  end
end

If you're curious about avoiding a view for rendering, you can read more about it in the Rails Guides. Pay attention to the part where it advises against using it in most cases! I'm doing it here for brevity, which I'm now diminishing the value of by spending a paragraph explaining it.

Making a test call

We want to make sure that this is working as expected, so let's write a test.

it "displays the prompts in the proper order" do
  get tech_support_prompt_path

  expect(response.body.split(" - ")).to eq [
    "Thank you for calling technical support.",
    "Call volume is higher than expected.",
    "Press 9 to receive a call back when an agent is available."
  ]
end

This test passes, so we ship it.

Sharing the call (Party Line)

We're preparing for our next feature. We will display the prompts for our general customer support phone number. After reading the requirements, we see some consistency. When calling tech support or customer support, we end by telling the caller how to request a callback.

Before starting on this, we're going to prepare the tech support display for some reuse. We want to share the code that adds these common prompts at the end of the interaction. As a starting point, we separate these later prompts to a separate method. We then invoke it in a separate before action.

class TechSupportPromptsController < ApplicationController
  before_action :set_prompts
  before_action :add_callback_notices

  def show
    render inline: "<%= @prompts.join(' - ') %>"
  end

  private

  def set_prompts
    @prompts = []
    @prompts << "Your call is important to us."
  end

  def add_callback_notices
    @prompts << "Call volume is higher than expected."
    @prompts << "Press 9 to receive a call back when an agent is available."
  end
end

Our test passes, because these callbacks are invoked in the order in which they're written.

When using before_action, the filters are called in the order that they are defined

Our next step to reuse these is to move these common prompts into a concern. This will allow us to access the prompts in different controllers. Even better, we surmise, the concern itself can define the before_action. Now all the controller needs to do is include the concern.

module Callbackable
  extend ActiveSupport::Concern

  included do
    before_action :add_callback_notices
  end

  private

  def add_callback_notices
    @prompts << "Call volume is higher than expected."
    @prompts << "Press 9 to receive a call back when an agent is available."
  end
end

And now we include the concern in the controller.

class TechSupportPromptsController < ApplicationController
  include Callbackable

  before_action :set_prompts
end

Running our test doesn't pass. Instead it raises an exception!

NoMethodError:
  undefined method `<<' for nil
  # ./app/controllers/concerns/callbackable.rb:6:in `block (2 levels) in <module:Callbackable>'

The concern is attempting to shovel a message onto a variable that is currently nil. nil does not respond to <<. The @prompts variable is not initialized at this point. The rule about callback order applies here for the concern as well.

We include the concern before calling the callback which initializes @prompts. Therefore @prompts has no value.

We can correct for that by including the concern after the callback.

class TechSupportPromptsController < ApplicationController
  before_action :set_prompts
  include Callbackable
end

Our test passes again.

Calling our taste into question

That may not sit well with you. Maybe it offends your sensibilities. Perhaps there are other include statements for your controller. You may want to put them all together, right after defining the class for the controller. However, the order of this include is important. It must be after the other before_action.

Even if you're totally fine with the include being anywhere, it's unclear that it needs to be after the callback. Luckily we have a test that will catch if someone inadvertently moves it. Even with the test, it's not obvious that the ordering is important. We have no idea what the concern does without looking at it. We don't know there's a callback running in it.

Alternatively, we can modify the concern to not specify the callback. It still defines the add_callback_notices method.

module Callbackable
  extend ActiveSupport::Concern

  private

  def add_callback_notices
    @prompts << "Call volume is higher than expected."
    @prompts << "Press 9 to receive a call back when an agent is available."
  end
end

In our controller, we have access to the method by including the concern. However, it's again our responsibility to call it. We do so by adding a second callback, just like we did when this method existed in the controller.

class TechSupportPromptsController < ApplicationController
  include Callbackable

  before_action :set_prompts
  before_action :add_callback_notices
end

In this scenario, we still need to know the rule about what order Rails applies these callbacks. I personally find it more clear to see the callback defined in the controller anyway. It also gives you the freedom to include the concern anywhere. Perhaps with the rest of the modules you're including! You don't need to be concerned with the order of includes.

Give me a call to let me know what you think.

Preserving Flash Messages in Rails

Kevin Murphy — Tue, 18 Mar 2025 00:35:56 +0000

Flash Sale!

We're offering our best deals on select products for a limited time. We're going to link to this flash sale from many different pages on our site. The call-to-action (CTA) we display at the top of the flash sale page will change based on which page you access the flash sale from.

We're going to store that text in a flash message. For example, let's say you're looking for the contact information for everyone at the shop. If you click a link on that page to visit the flash sale, we reference that you were just on the contact page.

class ContactsController < ApplicationController
  def index
    if FlashSale.on?
      flash[:sale] = "Thanks to you for looking to contact us"
    end
  end
end

Keep in mind this sale may be over in...a flash. In between loading the contacts page and clicking the link to view the flash sale, it may be over. If that's the case, we still want to show the CTA. However, we'll send you to the general products page, rather than the flash sale page.

We sample some of our requests to log information about them. If we're sampling this request, and they're getting redirected because the flash sale is over, we want to log what CTA brought them there. That way we can figure out what page they were on.

class FlashSalesController < ApplicationController
  def index
    if FlashSale.off?
      if AttemptLogger.log?
        Rails.logger.info "CTA '#{flash[:sale]}' used to access flash sale after it's over"
      end

      redirect_to products_path and return
    end

    @products = [
      donner_red_hss_starter_kit,
      martin_junior_acoustic,
      squier_affinity_strat_junior_hss,
    ]
  end
end

The view for the products page displays the flash message. We still have the experience of referencing the page they came from. Even if it isn't our best deals.

<h1>All Products</h1>

<% if flash[:sale].present? %>
  <p> <%= flash[:sale] %> </p>
<% end %>

Gone In A Flash

Let's confirm this behavior by writing some system tests. We'll start by verifying the redirect when the flash sale ends before they can view the deals.

it "redirects to the products page with the flash message when the flash sale has ended" do
  allow(FlashSale).to receive(:on?).and_return(true)
  visit contacts_path

  allow(FlashSale).to receive(:off?).and_return(true)
  click_link "View Deals"

  expect(page).to have_selector "h1", text: "All Products"
  expect(page).to have_content "Thanks to you for looking to contact us"
end

Our test passes!

⇒ rspec spec/system/flash_sales_spec.rb:8
Run options: include {:locations=>{"./spec/system/flash_sales_spec.rb"=>[8]}}
.

Finished in 0.12213 seconds (files took 1.89 seconds to load)
1 example, 0 failures

Next we'll iterate on this by verifying the same user behavior when we log the CTA.

it "logs the flash message when the flash sale has ended and the log sampler wants the message" do
  allow(FlashSale).to receive(:on?).and_return(true)
  visit contacts_path

  allow(FlashSale).to receive(:off?).and_return(true)
  allow(AttemptLogger).to receive(:log?).and_return(true)
  click_link "View Deals"

  expect(page).to have_selector "h1", text: "All Products"
  expect(page).to have_content "Thanks to you for looking to contact us"
end

Unfortunately, we have a different result here.

⇒ rspec spec/system/flash_sales_spec.rb:17
Run options: include {:locations=>{"./spec/system/flash_sales_spec.rb"=>[17]}}
F

Failures:

  1) Flash Sale logs the flash message when the flash sale has ended and the log sampler wants the message
     Failure/Error: expect(page).to have_content "As thanks to you for looking to contact us"
       expected to find text "As thanks to you for looking to contact us" in "All Products"
     # ./spec/system/flash_sales_spec.rb:26:in `block (2 levels) in <top (required)>'

Finished in 0.21189 seconds (files took 1.98 seconds to load)
1 example, 1 failure

Failed examples:

rspec ./spec/system/flash_sales_spec.rb:17 # Flash Sale logs the flash message when the flash sale has ended and the log sampler wants the message

Our flash message is nowhere to be found. For an almost identical test. After searching through the documentation, we find this:

Anything you place in the flash will be exposed to the very next action and then cleared out.

That leaves us even more confused. Our first test passed, even though we went from the flash sale endpoint to the products endpoint. Is that two actions? And if not, why did it clear it before exposing it to the user when we log the message?

Viewing Source In A Flash

That documentation tells us where to find the implementation for the flash: actionpack/lib/action_dispatch/middleware/flash.rb. We can use bundle open to explore the source code.

$ bundle open actionpack

We navigate to the flash file and look around. In there we see a method called commit_flash. Based only on the name, we guess that might have something to do with keeping the values of the flash. In one of our tests, we aren't keeping the values. Did we find a bug in Rails?

We drop a breakpoint in the method, changing Rails' source code (temporarily) for our application. Then we can run our tests again to investigate.

 def commit_flash
+  binding.irb # Added by us!
   return unless session.enabled?

   if flash_hash && (flash_hash.present? || session.key?("flash"))
     session["flash"] = flash_hash.to_session_value
     self.flash = flash_hash.dup
   end

   if session.loaded? && session.key?("flash") && session["flash"].nil?
     session.delete("flash")
   end
 end

A Flash In The Pan

We observe the following behavior when running our tests:

When we don't log the message in the FlashSalesController#index method, the value of flash_hash in commit_flash is nil at the end of processing the flash sale index action.
When we do log the message, flash_hash has a value.

That still seems backwards from the behavior we're seeing. When we try to show the flash message on the products page, it's not there when we log the message. But that's the scenario where flash_hash has a value. Now we need to take a detour to understand where this flash_hash comes from. We find it's a method.

def flash_hash
  get_header Flash::KEY
end

That leads us to wonder what can set that header. And we see just above:

def flash=(flash)
  set_header Flash::KEY, flash
end

As our eyes continue to look up, we find a method that calls flash=.

def flash
  flash = flash_hash
  return flash if flash
  self.flash = Flash::FlashHash.from_session_value(session["flash"])
end

This feels a bit circular in the beginning. We look to see if flash_hash is set and return that if so. But we're looking here to see how flash_hash could get a value. It is the last line that's setting the header that flash_hash uses. So, that's called when flash_hash doesn't have a value. The flash object is grabbed from the session and converted to a FlashHash.

That will store that FlashHash instance in the header. We can then access that by calling the flash_hash method.

We also see a comment above the flash method.

# Access the contents of the flash. Returns a ActionDispatch::Flash::FlashHash.

This is what we're calling when we call flash[:sale] in our logging message. FlashHash defines the [] method.

Flash Back

Let's revisit each conditional in commit_flash and explore how they relate to our test scenarios.

if flash_hash && (flash_hash.present? || session.key?("flash"))
  session["flash"] = flash_hash.to_session_value
  self.flash = flash_hash.dup
end

When this is called after the FlashSalesController#index action and we don't log a message, flash_hash is nil. That's because we never call flash, which would set the header that flash_hash reads from. flash never gets called, so the header never gets set. We never enter the conditional block in that scenario.

However, when we do log the message, the header is there, and flash_hash is present. That causes the contents of flash_hash to be converted to a session value and stored back in the session.

Converting a FlashHash instance to its session value does the following:

def to_session_value
  flashes_to_keep = @flashes.except(*@discard)
  return nil if flashes_to_keep.empty?
  { "discard" => [], "flashes" => flashes_to_keep }
end

When we make a flash from the session, we send all the keys as discard values. As a result, when we're converting back to the session, flashes_to_keep is empty. This returns nil. And that's what we set session["flash"] to.

The second conditional in commit_flash is:

if session.loaded? && session.key?("flash") && session["flash"].nil?
  session.delete("flash")
end

When we log the message, we load the session by calling flash[:sale]. That's because we're reading from the session to pass a value to FlashHash.from_session_value.

def flash
  flash = flash_hash
  return flash if flash
  self.flash = Flash::FlashHash.from_session_value(session["flash"])
end

Accessing the session loads the session for reading, which through the load! method sets the @loaded instance variable that is used to determine if a session is loaded.

Because the session is loaded, it has a flash key, and the value is nil (because converting it to a session value discarded all the keys), then we delete flash from the session entirely.

If we never invoke flash before redirecting, we never load it from the session, never convert it back to a session value, and never delete it from the session. It remains available when processing the ProductsController#index action.

When we do call flash to write the log message, we do delete it from the session, so ProductsController#index doesn't have it.

Flash Forward

This is great that we understand why this is happening. But none of this actually fixes our problem. We want our tests to pass. We don't want the flash removed from the session. We want the :sale key to still exist.

Recall the conditions by which the flash is deleted from the session:

if session.loaded? && session.key?("flash") && session["flash"].nil?
  session.delete("flash")
end

When we log the message, we need to load the session to access the flash, so we can't get around that. However, if the value of session["flash"] wasn't nil, that'd be enough to preserve it.

The reason session["flash"] is nil is because we didn't have any flashes to keep when converting the object to a session value.

def to_session_value
  flashes_to_keep = @flashes.except(*@discard)
  return nil if flashes_to_keep.empty?
  { "discard" => [], "flashes" => flashes_to_keep }
end

We do have an option to explicitly keep the entire flash (or a particular key). It's the aptly-named keep method. That removes keys from the @discard set, so they'll be retained.

Let's update our flash sale controller to use this.

 class FlashSalesController < ApplicationController
   def index
     if FlashSale.off?
       if AttemptLogger.log?
         Rails.logger.info "CTA '#{flash[:sale]}' used to access flash sale after it's over"
+        flash.keep(:sale)
       end

       redirect_to products_path and return
     end

     @products = [
       donner_red_hss_starter_kit,
       martin_junior_acoustic,
       squier_affinity_strat_junior_hss,
     ]
   end
 end

With that one call to keep, both of our tests pass. Whether we log the flash CTA or not, it's available for the ProductsController#index action to display.

An Illuminating Flash

Our goal was to preserve a flash message. Instead, it seems we learned more about the conditions by which we destroy the flash message. That allowed us to back up and explore options to fail that conditional.

The Rails source code is vast and dense, but it's also readily available. We discovered the reason behind the behavior we saw and a solution by being willing to explore it. Consider bundle opening the next dependency you're confused or interested by. See what you can learn. It may take a while, or you may have your answer in a flash.

What Is It (in Ruby 3.4)?

Kevin Murphy — Mon, 13 Jan 2025 20:12:03 +0000

This post may appear to be about new functionality in Ruby. However, it may instead be an attempt to write an article with the worst possible SEO.

Anyway, hit it.

What Is It?

As of Ruby 3.4, it is another way to refer to the first parameter in a block. This may be more obvious by way of an example.

["What is it?"].map { it + " It's it" } * 4

=>
[
  "What is it? It's it",
  "What is it? It's it",
  "What is it? It's it",
  "What is it? It's it",
]

The block we pass to map does not define a name for the parameter to represent the variable we're manipulating in each iteration. Instead, Ruby knows it refers to that variable.

Starting in Ruby 2.7, we had access to numbered parameters in a block with an underscore. We can write that same example using numbered parameters.

["What is it?"].map { _1 + " It's it" } * 4

=>
[
  "What is it? It's it",
  "What is it? It's it",
  "What is it? It's it",
  "What is it? It's it",
]

Before Ruby 2.7, we would define the name of a variable in a block, which we can still do with more recent versions of Ruby.

["What is it?"].map { |i| i + " It's it" } * 4

=>
[
  "What is it? It's it",
  "What is it? It's it",
  "What is it? It's it",
  "What is it? It's it",
]

Handling nested calls

Should you have nested blocks that refer to it, Ruby will take it to refer to the parameter of the innermost block.

[
  "You want it all, but you can't have it",
  "Yeah",
  "It's in your face, but you can't grab it",
  "Yeah",
]
  .map { it == "Yeah" ? [it, it, it].map { it.upcase }.join(", ") : it }

=>
[
  "You want it all, but you can't have it",
  "YEAH, YEAH, YEAH",
  "It's in your face, but you can't grab it",
  "YEAH, YEAH, YEAH",
]

The same is not possible with numbered parameters. An exception is raised due to the ambiguity of what _1 refers to.

[
  "You want it all, but you can't have it",
  "Yeah",
  "It's in your face, but you can't grab it",
  "Yeah",
]
  .map { _1 == "Yeah" ? [_1, _1, _1].map { _1.upcase }.join(", ") : _1 }

syntax error found (SyntaxError)
  5 |   "Yeah",
  6 | ]
> 7 | ... _1.upcase }.join(", ") : _1 }
    |     ^~ numbered parameter is already used in outer block

Method names in scope

Ruby also will infer that it refers to the block parameter should there be a method called it in scope.

def it = "This isn't it"

[
  "Can you feel it, see it, hear it today?",
  "If you can't, then it doesn't matter anyway",
]
  .map { it.gsub("it", "IT") }

=>
[
  "Can you feel IT, see IT, hear IT today?",
  "If you can't, then IT doesn't matter anyway",
]

Variable names in scope

However, if there is a variable defined as it, that will take precedence over the block parameter in the block.

it = "This isn't it"

[
  "You will never understand it, 'cause it happens too fast",
  "And it feels so good, it's like walking on glass",
]
  .map { it.gsub("it", "IT") }

=>
[
  "This isn't IT",
  "This isn't IT",
]

You've got to share it, so you dare it

If you want to learn more about this new feature, check out the proposal and the documentation. Read the Ruby 3.4 changelog to discover all the fun available in Ruby 3.4.

You can touch it, smell it, taste it, so sweet

But it makes no difference 'cause it knocks you off your feet

That's it.

RSpec Stubs The Object In Memory

Kevin Murphy — Mon, 16 Sep 2024 12:05:00 +0000

Publish or Perish

Let's say we've been sitting on a handful of blog posts that are ready to publish, but we haven't released yet. This is a fictional story that in no way mirrors reality of any particular writer. Certainly not the author writing this post now. In a spirit of inspiration, we decide to write a small class to publish all these posts that exist in our system.

class DraftPost
  def self.publish_all
    Post.draft.map(&:publish)
  end
end

Rather than actually publish them, we've successfully procrastinated. We have a way to publish them, eventually. While we're busy not actually publishing them, let's test this method works.

Prolonged Publication Procrastination

We want to verify that we send the publish message to each of these posts. We don't actually want to execute the publish method. Perhaps that integrates with a third-party API. We don't want to manage testing that interaction here.

Instead, we'll stub out the response using RSpec mocks.

With that goal, we write our test.

it "publishes all draft posts" do
  draft = Post.create(draft: true)
  allow(draft).to receive(:publish)

  DraftPost.publish_all

  expect(draft).to have_received(:publish)
end

This test fails. We put a breakpoint in our test. We confirm that a post with the same database ID as draft does get the publish method called on it.

Even though these objects pass the equality check, the issue is that they are not the same object in memory. Compare the object_id of the draft object to the object pulled out of the database. They're different. The post published in DraftPost.publish_all does not have the stub applied to it.

The stub operates on that draft object in memory, and only that object. Even though the other object is equal to the draft object, it is not the same as the draft object. Because of that, our assertion does not pass.

Any Instance Of

At this point, we may try to instead test what's returned from publish_all while still not having the publish method called on the posts.

it "publishes all draft posts" do
  draft = Post.create(draft: true)

  allow_any_instance_of(Post).to receive(:publish).and_return("called publish")

  expect(DraftPost.publish_all).to eq ["called publish"]
end

Our test now passes. However, we have some drawbacks. First off, RSpec itself considers using allow_any_instance_of to be suspect.

This feature is sometimes useful when working with legacy code, though in general we discourage its use for a number of reasons

Now, this doesn't mean it's wrong. But, I'd argue to only use it after carefully considering other options.

The other thing we changed here is our testing philosophy. Now we're testing what's returned by the method, rather than what the method does. And we did this by stubbing out what any Post should return when we call the publish method on it.

That again may be fine, but it may not test that we publish all the draft posts, which is our goal. Instead, it confirms what the publish_all method returns.

This may be hyperbolic, but if we changed the implementation to look like this:

class DraftPost
  def self.publish_all
    ["called publish"]
  end
end

Now our test that asserts this method is calling publish still passes, but we're definitely not publishing any posts.

Change the Implementation

Let's change publish_all so we pass all the posts to publish into it.

class DraftPost
  def self.publish_all(posts)
    posts.map(&:publish)
  end
end

Now we can use the RSpec mock as we want.

it "publishes all draft posts" do
  draft = Post.new(draft: true)
  allow(draft).to receive(:publish)

  DraftPost.publish_all([draft])

  expect(draft).to have_received(:publish)
end

This test passes, and as a bonus, we don't need to access the database in our test anymore. What a speed improvement!

Once again, this choice comes with some careful consideration. First off, modifying the implementation to satisfy the way we want to test it may be undesirable. I do want to point out that I don't think this is true generally. I do believe in using your tests as your first consumer of your code. If something is tough to test, it may be hard to use or confusing to understand. There's value in receiving that signal and deciding to change the code's design or structure in that case.

Stepping back here, passing in the posts makes the name of this class pretty meaningless. This should only work on draft posts. However, we can pass any kind of post (really, anything that responds to publish) and this will still work.

Maybe we want something that'll generically publish any kind of post. If so, we probably shouldn't have that inside a DraftPost class. If this should only operate on draft posts, then this may not be the choice we want to make.

Passing in the posts allows our stub to work. Passing in the posts may allow us to achieve some purity of using dependency injection. Passing in the posts may make this method less usable. Enough to the point where perhaps it shouldn't exist at all.

Stub the DB Interaction

We still want to use the mock. We don't want to use RSpec features that the core team themselves recommend against. We don't want to change the implementation. It turns out we like the benefit of not needing to access the database. We can achieve all those goals by also stubbing out the database call.

it "publishes all draft posts" do
 draft = Post.new(draft: true)
 allow(Post).to receive(:draft).and_return([draft])
 allow(draft).to receive(:publish)

 DraftPost.publish_all

 expect(draft).to have_received(:publish)
end

Finally Publishing The Post

We confirm that we send the right message (publish) without invoking its implementation. We do give up some confidence in that we don't know for sure that Post.draft works how we expect. We can regain that confidence by having other tests specific for that method.

One could argue this gives us more flexibility. If the implementation of Post.draft changes, this test will continue to work. It can get posts from a database or third-party API. Our method doesn't care.

On the flip side, one could also argue that this test is tying us to a particular implementation. If DraftPost.publish_all changed to instead use Post.where(draft: true), then this test will no longer work. Even though using the scope or using where will retrieve the same records from the database.

Unfortunately, there is no right answer. We must consider the trade-offs we're willing to make to achieve our goal. What ✨magic✨ you're interested in maintaining is up to you.

Keep in mind that RSpec mocks only work on that particular object in memory. If the implementation pulls the same record fresh out of the database, the mock will not apply. When using RSpec mocks in your tests, objects in memory may be farther than they appear.

Access Request Headers in a Rails Controller

Kevin Murphy — Tue, 16 Jul 2024 23:43:47 +0000

Heads Up

A coworker presented a failing request spec. They asked if they were passing headers incorrectly in the test.

it "reports to be a teapot when asked to brew coffee" do
  headers = { "X-COMMAND" => "brew coffee" }
  get drinks_url, headers: headers

  expect(response.status).to eq 418
end

They wrote the test exactly like I'd expect. But, rather than providing the 418, a 200 OK was the status code. I then looked at the controller this request spec was accessing.

def index
  if headers["X-COMMAND"] == "brew coffee"
    head 418
  end

  @drinks = Drink.all
end

Nothing obvious caught my attention. But now that I'd been effectively nerd sniped, I had to figure out what was going on.

Heading In For a Closer Look

I added a breakpoint inside the controller to inspect the headers when the test was running.

irb:001:0> headers
=>
{"X-Frame-Options"=>"SAMEORIGIN",
 "X-XSS-Protection"=>"0",
 "X-Content-Type-Options"=>"nosniff",
 "X-Download-Options"=>"noopen",
 "X-Permitted-Cross-Domain-Policies"=>"none",
 "Referrer-Policy"=>"strict-origin-when-cross-origin"}

As expected, given the failing test, the X-COMMAND header was nowhere to be found. But luckily, they did seem familiar to me. They looked to be Rails' default headers. But those default headers are for the response, not the request.

I still had my console session with my breakpoint, so I asked what kind of headers we were interacting with.

irb:002:0> headers.class
=> ActionDispatch::Response::Header

This confirmed we were dealing with the response, not request, headers.

Heads Down

I needed to trace my way backwards from what I have or know. I asked what defines the headers method by asking for the source location. That'll tell me the file and line number.

irb:003:0> method("headers").source_location
=> [".../gems/actionpack-7.0.3.1/lib/action_controller/metal.rb", 147]

That line shows headers delegated to an internal attribute @_response.

delegate :headers, :status=, :location=, :content_type=,
         :status, :location, :content_type, :media_type, to: "@_response"

That internal attribute is accessible in the controller by calling response. We can see that from the attr_internal definition on line 145.

attr_internal :response, :request

response isn't the ONLY internal attribute on that line though. There's ALSO a request. In our console, let's see what that request is.

irb:004:0> request.class
=> ActionDispatch::Request

That class also responds to headers, providing the request headers.

Heading In For The Close

The change to get our test to pass is small. We don't want the response headers, which is what the headers variable is. We need the request headers, which are accessible at request.headers.

def index
  if request.headers["X-COMMAND"] == "brew coffee"
    head 418
  end

  @drinks = Drink.all
end

Now that we're accessing the headers of the request our test passes.

Naming is hard. Asking for a controller's headers could be either the request or the response headers. Turns out, Rails will give you the response headers. To access the request headers, explicitly ask for them from the request object.

Four Things To Take Away From RailsConf 2024

Kevin Murphy — Tue, 14 May 2024 21:19:46 +0000

RailsConf 2024

Now that RailsConf 2024 is behind us, I want to share some key takeaways that I left Detroit with. I also have a full recap available of what I saw while I was there.

1. #RubyFriends Is More Than A Hashtag

I cannot overstate the importance of your professional network. In the Ruby community, we talk a lot about Ruby Friends. How you build and cultivate that group is up to you. Conferences have been a main driver of that for
me.

The reason I was on the Program Committee is because of the conference relationships I’ve built. I congratulated Ufuk on joining the Ruby Central board at RubyConf last year. I (sincerely) told him to keep me in mind if I can help in the future. He immediately said, "program committee?" And then he remembered when putting together RailsConf's committee. I'm thankful to him for the opportunity.

The conference is an excuse to connect with my friends before, during, and after the actual event. I can check in on speaker friends throughout the process. This year I developed meaningful relationships with fellow Program Committee members. That persists throughout the conference. And after we can reminisce and recall all those moments.

And sure, hopefully I'm being helpful to my Ruby Friends, much like I know they'll help me. But really what I appreciate most is having something to reach out to them about.

2. Ruby ❤️ Rails

Rails benefits greatly from the tooling and improvements of Ruby itself. John Hawthorn demonstrated how Vernier can help profile Ruby code. That benefits all our Rails applications. Aaron Patterson described existing and future changes in Ruby. Each one improves our Rails applications. To take advantage of them, we need to stay up-to-date with those changes.

3. Build with Rails? Build With Rails.

The theme at RailsConf was "Building with Rails". We heard from people who built businesses with Rails. Built teams with Rails. Built technical advances with Rails. Built careers with Rails. Nadia talked to us about The StoryGraph. I took away an appreciation of how many risks and unknowns you take on starting and running a business. By keeping the tech simple and known, you can allocate your risk budget elsewhere.

Irina also surveyed various earlier-stage founders on their use of Rails. Hearing what they appreciate about the ecosystem was reaffirming. Learning what they're missing was informative and helpful.

Marco also called attention to Rails-adjacent projects, like Turbo and Stimulus Reflex. His talk provided a great history lesson on these projects. He gave exciting introductions to new tooling. He shared learning resources. Marco gave many options for how we can leverage this all in our Rails applications.

4. It's (Almost) Over

Yes, RailsConf 2024 is definitely over. However, RailsConf itself is also almost over. RailsConf 2025 is the last planned RailsConf. Ruby Central will continue supporting RubyConf.

This will free RubyCentral up to focus their efforts. There are many other important benefits they provide the community. I know for a long time I thought of Ruby Central as the group the puts on the conferences. I took for granted the work they do. I didn’t consider how vital they are. They support the bedrock tooling for our community: Bundler and RubyGems. I hope this shift will help others be more awareness to the rest of the ways Ruby Central supports Ruby.

But we're not done yet. Ruby Central needs your help shaping RailsConf 2025. Fill out this survey to tell them where you're excited to see RailsConf. That's right, there isn't a date or location yet. Wherever it is, I hope I see you there.

Making a (Sidekiq) Batch Recipe

Kevin Murphy — Mon, 15 Apr 2024 12:00:00 +0000

The Right Number of Cooks in the Kitchen

Today we're going to make a stew. The recipe has three steps that can all run independently. But when they're done, their output needs to come together to finish the stew.

We'll set each step up as a separate Sidekiq job. The details of each step aren't important for this demonstration.

class GetRawVeggiesWorker
  include Sidekiq::Worker

  def perform; end
end

class GetBaconWorker
  include Sidekiq::Worker

  def perform; end
end

class GetCupOfSoupWorker
  include Sidekiq::Worker

  def perform; end
end

We can enqueue these to run by themselves no problem. However, we need to know when they're all done so we can finish our recipe. We can group these together using a Sidekiq Pro feature: batches.

We'll write a series of RSpec tests to explore how to use batches to make our recipe.

Tracking Kitchen Progress

We'll start by creating a batch, and adding our recipe steps to it as jobs. Just like a Sidekiq job has a jid (job ID), a batch has a bid (batch ID). We can use that bid to check on the batch's status thanks to the aptly-named Batch::Status class.

it "adds jobs to a batch" do
  recipe = Sidekiq::Batch.new

  recipe.jobs do
    GetRawVeggiesWorker.perform_async
    GetBaconWorker.perform_async
    GetCupOfSoupWorker.perform_async
  end

  batch_status = Sidekiq::Batch::Status.new(recipe.bid)

  expect(batch_status).to have_attributes(
    total: 3,
    pending: 3,
    complete?: false,
  )
end

After making our batch and checking on the status, we see there are three jobs, but none of them ran. That is because this is in a test, and we're using the Sidekiq fake adapter by default.

Let's update our test to run the batch jobs inline:

it "runs the workers in the batch in inline mode" do
  recipe = Sidekiq::Batch.new

  Sidekiq::Testing.inline! do
    recipe.jobs do
      GetRawVeggiesWorker.perform_async
      GetBaconWorker.perform_async
      GetCupOfSoupWorker.perform_async
    end
  end

  batch_status = Sidekiq::Batch::Status.new(recipe.bid)

  expect(batch_status).to have_attributes(
    pending: 0,
    complete?: true,
    total: 5,
  )
end

The jobs executed and the batch is complete. Note that the total number of jobs is five, even though we enqueued three jobs. Interesting! Let's leave that aside as we explore what to do now that we have a batch that completes.

Calling (back) next steps

The reason we created a batch was so we could do something with the results of our jobs when they finished. We wanted them to run independently, so we can take advantage of parallel execution. But we need to have the system take action once they're all done.

Sidekiq batches respond to callbacks. We'll focus on two of the three available callbacks: complete and success.

class ActingLessonCallback
  def on_complete(status, options)
    puts "#{options['name']} went to Craft Services"
  end

  def on_success(status, options)
    puts "Baby, you've got a stew goin'"
  end
end

Each callback method accepts two arguments. One for the status, and another for a set of options. We're using those options in the on_complete callback to pass a name to the status message.

Also, I'm sorry I misled you earlier. This isn't really about a recipe. It's an acting lesson.

Getting an audition callback

Now we know how to use a callback and we created a class to house our callbacks. Let's put it to use by telling our batch about it, and seeing how they get used.

it "runs a callback" do
  acting_lesson = Sidekiq::Batch.new
  acting_lesson.on(:complete, ActingLessonCallback, "name" => "Kevin")
  acting_lesson.on(:success, ActingLessonCallback)

  Sidekiq::Testing.inline! do
    expect do
      acting_lesson.jobs do
        GetRawVeggiesWorker.perform_async
        GetBaconWorker.perform_async
        GetCupOfSoupWorker.perform_async
      end
    end
    .to output("Kevin went to Craft Services\n"\
               "Baby, you've got a stew goin'\n").to_stdout
  end
end

We registered our callbacks with the batch using the on method.

Remember those two additional jobs in the prior example? Where we enqueued three jobs, but the total count was five? Those extra jobs were these callbacks firing. Even though we didn't register any callbacks, the events still fired.

In this test our batch executed, triggering both callback events. As expected, the callbacks output their message. Completion! Success!

A complete definition of success

While success and complete may sound similar, they have specific and different meanings. The success callback is perhaps the more obvious one. It triggers when the jobs in the batch have completed successfully.

That means that a batch can complete and not be successful - leading us to the on_complete callback. That fires when all the jobs have executed. Some of the jobs could have failed. Some may be in the retry queue. But they have run at least once.

To show this, let's create a few more Sidekiq jobs. We'll join the steps of our acting lesson together in one job. And we'll create one more that always fails.

class ActingLessonWorker
  include Sidekiq::Job

  def perform; end
end

class HugeMistakeWorker
  include Sidekiq::Job
  sidekiq_options retry: false

  def perform
    raise "I think I'd like my money back"
  end
end

Now we'll run another test, creating a batch with these two jobs. At the end, we'll check the status of the batch.

it "completes once each job has run once, regardless of success" do
  drama_coach = Sidekiq::Batch.new

  Sidekiq::Testing.inline! do
    expect do
      drama_coach.jobs do
        ActingLessonWorker.perform_async
        HugeMistakeWorker.perform_async
      end
    end.to raise_error "I think I'd like my money back"
  end

  batch_status = Sidekiq::Batch::Status.new(drama_coach.bid)

  expect(batch_status).to have_attributes(
    complete?: true,
    total: 4,
    pending: 1,
    failures: 1,
    success_pct: 75.0,
  )
end

Even though not all the jobs were successful, the batch still reports itself as complete. We can see the failure, and the job that failed as pending. We can also look at the success percentage of the batch to understand that not all the jobs succeeded.

Dress rehearsal implications

Something to be mindful of when running your batches in tests is when the callback will fire. To really have some fun, let's do something I don't reach for often: use a global variable.

$global = 0

We'll create a job that increments the global.

class CounterWorker
  include Sidekiq::Job

  def perform
    $global += 1
  end
end

We'll have a callback after the batch succeeds. It outputs how many times the jobs incremented the counter.

class BatchCallback
  def on_success(status, options)
    puts "Jobs run: #{$global}"
  end
end

In our test, we have a batch that fires the callback and enqueues the counter job twice.

 it "runs the success callback after the first job is run with inline test mode" do
  batch = Sidekiq::Batch.new
  batch.on(:success, BatchCallback)

  Sidekiq::Testing.inline! do
    expect do
      batch.jobs do
        CounterWorker.perform_async
        CounterWorker.perform_async
      end
    end.to output("Jobs run: 1\n").to_stdout
  end

  expect($global).to eq 2
end

Our global says both jobs ran; however, the output from our callback says only one ran. Both are correct - at different points in time! Remember, these jobs in this test are performed inline. The first counter job was enqueued and run, incrementing the counter. Then Sidekiq checked to see if any other jobs were in the batch. At this point there aren't, so it triggers the callbacks. The success callback outputs that one job ran.

Then, the second job in the batch was enqueued and run, incrementing the counter. The end of our test verifies that the global variable is currently set to two. The callback is not executed again because it already ran.

If you're running batches in tests, want to test the callback of a batch, and the callback depends on the state or results of all the jobs in the batch, you may end up with a surprising result.

Bulking up mid-rehearsal

If you really need to test this, you could work around this by changing how you enqueue the jobs in your batch. Using bulk queueing will get you the result you expect.

it "runs the success callback after all jobs run when pushed in bulk with inline test mode" do
  batch = Sidekiq::Batch.new
  batch.on(:success, BatchCallback)

  Sidekiq::Testing.inline! do
    expect do
      batch.jobs { CounterWorker.perform_bulk([[], []]) }
    end.to output("Jobs run: 2\n").to_stdout
  end

  expect($global).to eq 2
end

This also enqueues two jobs. When run with the inline test adapter, they both run before the batch callbacks fire. So, both the callback and the global are consistent.

I point this out to show you can do this, and also to perhaps introduce bulk queueing to you. However, if your tests rely on this, I would advocate to reconsider your testing strategy. Test the callback in isolation to verify that part of your code. Trust Sidekiq to manage the orchestration of firing the callback for the batch.

A draining performance

You may recall that our first test didn't run the jobs because we were using the fake test adapter. I have one other word of caution to point out that I noticed using the fake adapter. Draining the queue that the jobs are enqueued in for a batch later in the test also does not trigger the callbacks.

it "doesn't run the success callback of a batch when draining the queue in fake test mode" do
  batch = Sidekiq::Batch.new
  batch.on(:success, BatchCallback)

  batch.jobs do
    CounterWorker.perform_async
    CounterWorker.perform_async
  end

  expect { CounterWorker.drain }.not_to output("Jobs run: 2\n").to_stdout

  expect($global).to eq 2
end

Lastly on testing, to have these callbacks fire in tests, you must add middleware to your tests.

around(:example) do |example|
  Sidekiq::Testing.server_middleware do |chain|
    chain.add Sidekiq::Batch::Server
  end

  example.run

  Sidekiq::Testing.server_middleware do |chain|
    chain.remove Sidekiq::Batch::Server
  end
end

Curtain call

This has been an introduction to Sidekiq's batch functionality. It also provides a valuable life lesson on acting. Batches can be a great option to parallelize work and report the result of, or combine, those pieces. You can also use it to build complex workflows. Dig into batches in more detail on Sidekiq's wiki.

Tracks Not At RailsConf 2024

Kevin Murphy — Mon, 18 Mar 2024 00:33:13 +0000

RailsConf 2024

I'm on the RailsConf 2024 Program Committee. We just released the program for this year's event, and I hope you'll join us!

One thing we don't have are formally-themed tracks. In past years, our CFP might have included prompts for different topics. Or we'd group some talks in publicly-shared and advertised ways.

We aren't doing that this year. That lets us focus on the overall conference theme: building with Rails. However, that didn't stop me from brainstorming a list of possible tracks, in case we did want to add them in.

The following is a list of what could have been, but will not be: tracks that are not part of the RailsConf 2024 program.

Lend an Enginear

Story Time! Gather round to hear harrowing tales of software development. Was the bug coming from inside the framework? What can we learn from these experiences? Follow the hero's journey of these presenters. Listen to adventures both imagined and too strange for fiction.

Rails Train-ing

Unlock new perspectives on using the Rails toolbox. Talks in this track will help you level up on Rails functionality. They'll build up a stronger understanding of framework features.

Rails Engine-uity

This track highlights people combining Rails with other concepts. This may include a variety of front-end tools. It may show connecting with different data sources. I'm sure there are things I can't even imagine that submitters would surprise us with.

Railway Maintenance

We're all about setting ourselves up for long-haul success here. How can we prevent future pain in managing our applications? How can we get ourselves out of sticky situations? What tools, systems, and mindsets make our apps more amenable to change? How can we otherwise make our apps better in the future?

Express Rail

Here is a one-way ticket to building foundational Rails knowledge. Talks in this track assume no prior experience for the audience. This track will bring you up to speed quickly.

Freight Transport

This is where all the heavy technical talks combine in one long train traveling down the same track. Talks may dig into details on Rails source code. They could explore dreams for the future.

Passenger Train

The Ruby community is so delightful because of the people in it. These talks highlight that. They provide insight on how to improve our human connection, to code and each other.

Tunnel Vision

Talks in this track are deep dives on specific topics. Here is a chance for speakers to get into intense detail. Share the knowledge that it feels like only you know. Combine the wisdom of the community on one area in a tight package.

RailsConf 2024 Program

While those tracks aren't in this year's program, we have lots of amazing sessions that are. Get your ticket today!

There may also be some subtle ordering to the schedule. What themes do you see? What sessions are you looking forward to? Let me know!

RubyConf 2023 Recap

Kevin Murphy — Mon, 20 Nov 2023 23:05:49 +0000

RubyConf 2023

RubyConf recently wrapped up in San Diego, California. This post is meant to highlight the great work from all involved. I hope you'll seek out the full videos of all the sessions that interest you once they are available. Unfortunately, I couldn't be everywhere, so this covers what I saw.

Preparing

This is a weird brag, but this is the first conference I've attended in a long time as an attendee. It's been a while since I haven't been a speaker or on the speaker waiting list. Being a wait-listed speaker means you prep and have a talk ready. You only get to give it if you need to substitute for another speaker on short notice.

This left me with a lot more free time during the conference. More importantly, I had more time before the conference. I still had the "conference season" itch though. So I channeled that energy in a few different directions.

CFP Coaching

First, just as I did for RailsConf, I joined Ruby Central members for the CFP coaching sessions. We helped others with their proposals in small groups. This was a great opportunity to meet with prospective speakers and workshop ideas to submit for the conference. I'm glad that Ruby Central has started organizing these events. I hope they continue.

Podcasting about RubyConf

After the CFP process wound down, I joined Brittany Martin as a temporary co-host of The Ruby On Rails podcast. We talked with Allison McMillan and Chelsea Kaufman about the plan for RubyConf 2023. I hope that it helped get people excited about the conference. Even better if it helped convince someone to come after listening.

I also joined Julie and Andrew on the Ruby for All podcast. The discussion centered around conference speaking.

Writing

I expanded on my blog post from last year where I shared past proposals. I turned it into a series on preparing for conferences. I wrote about my process for turning an accepted proposal into a talk. I followed that up with how I practice and prepare for the stage.

Helping Speakers

Lastly, I had more time to help friends who were speaking with their talk preparation. Notably, I was a speaker mentor for the first time. I've been hesitant to do it in the past when I've had a talk of my own to prepare. I was really happy to have the time to devote to this. I paired with Paul Reece. Paul gave a great talk about Ruby Polars. Paul was very prepared and definitely made the process easy for me. It was super fun to see the evolution of the talk over time from an outsider's perspective.

Community Day

Even after talking about this on The Ruby on Rails podcast, I'll admit that I was still pretty unsure how this would all go. I didn't attend any of the workshops as I wanted to see the implementation of the hack space events.

After an introduction from Allison McMillan and Chelsea Kaufman, the group separated into workshops and the hack space. I spent my day in the hack space. In the morning I spent time at the Hanami table. I'll be honest, I didn't do much of any Hanami work, but I had a great conversation there.

After lunch, I parked at the Ruby LSP table. I worked with Julie and Drew on HEREDOC endings. We also found an issue that we spent some time digging into, but ran out of time before we had a solution. It was fun spelunking through the code with friends. Ufuk joined us in looking at the cursor indentation issue. His sage wisdom helped us navigate through an unfamiliar codebase.

I enjoyed my time at Community Day. For me, I'm not sure if it's worth removing a full day of talks. I'm a person that really enjoys talks at conferences. I'm a person who will gladly join talks in person. But, I have a difficult time committing to watching recorded talks after. I'm also biased, because I'm a potential speaker (I did not submit to RubyConf this year). One fewer day and fewer tracks means less opportunity for people to have an accepted talk.

That said, I talked to a handful of people who organized sessions after. And the vibe I got from them was that it was a positive time. They were happy to work with the community directly, in-person, on their project. They liked meeting new people interested in helping and giving them a starting push. They enjoyed the experience and what it meant for their project.

I'm not sure what the right mix is here. At the least, I think moving Community Day to later in the conference makes sense. That way the organizers can communicate in person with attendees on expectations. Any talks about subjects that will be at Community Day can turn into a call to action to join the hack space.

Could there be a hack space throughout the conference that people could join? That would have a similar cost that workshops have in the past, where people need to miss other sessions to join. It would mean having another room at the conference that Ruby Central needs to rent. Maybe having it spread out throughout the conference would mean a smaller room? It would be a bit like the hallway track, but structured towards particular goals.

Like I said, unfortunately, I have no solid answers here. And I recognize that the way I enjoy conferences is different from many others. I heard resounding praise for Community Day at the conference!

I do like that Ruby Central is responding to feedback and trying out new experiences. I'm interested to hear a retrospective from them. How do they feel about Community Day and what form(s) it might take going forward?

Day 2

Opening Keynote

Yukihiro "Matz" Matsumoto started the conference after the opening remarks. This was a pre-recorded message. He talked about learning from the history of language design and evolution, to inform the future of Ruby.

Which Time Is It?

Joël Quenneville started the talk sessions. He provided a distinction between looking at a moment in time versus a duration of time. He cautions to think through what types of time can interact with each other (the way that you want or expect). Consider the operator you're using and what it means. Catch the full session to learn more about why you can't add two time instances together.

Get your Data prod ready, Fast, with Ruby Polars!

Paul Reece gave an introduction to the Polars library. This started with an introduction to the Series and Data Frame data structures. Paul then walked through data cleaning operations available in Polars. He shared a repository of resources and code samples at the end of his session.

Ruby Content Creators

During Community Day, Peter Cai asked me to participate in this open space session. I sat at the written content table with other bloggers and authors. There were other tables for podcasts, live streaming, and pre-recorded videos. The written content table talked through our processes. We lamented over the difficulties in getting feedback. We shared how to build sustainable writing habits.

The Future of Understanding Ruby Code

Kevin Newton talked about Prism, a new Ruby parser. He discussed the challenges that come with parsing Ruby. He shared what's next, and what we can and should expect from our Ruby tooling in the future. He ended with an impassioned discussion about building a contributor community around a single tool.

The Unbreakable Code Whose Breaking Won WWII

Aji Slater took us back to Bletchley Park to model an Enigma machine with object-oriented principles. This session features monumentally brilliant illustrations and fantastic storytelling.

Closing Keynote

Sharon Steed ended the first day of talks with a keynote on actionable empathy. We heard about its relationship with vulnerability and how trust is the bedrock to empathy.

Day 3

Opening Keynote

Saron Yitbarek opened the last day of RubyConf discussing our superpower. Loving what we do is an underrated source of competitive advantage for us to wield.

Meet the Pragmatic Bookshelf

Noel Rappin joined Dave Thomas and Dave Copeland for a panel discussion on writing. This particularly focused on books with Pragmatic Programmers. We heard about the entire process, from proposal to publication.

One note I found interesting was how the voice of their books changes over time. It intentionally starts with an authoritative tone, telling the reader what to do. As the book progresses and the reader is more familiar with the domain, the tone shifts. Now the tone is more collaborative. The author consults with the reader and uses "we" more.

The Secret Ingredient: How To Understand and Resolve Just About Any Flaky Test

Alan Ridlehoover walked through a progression of steps to resolve tests failing due to non-determinism, order dependence, and race conditions. With an eye to keeping specs to have one, and only one, reason to exist, he proposes tools and methodologies to trace down these test failures.

Livin’ La Vida Hanami

Tim Riley introduced Hanami as the everything framework. The framework is not our app, but enables our application logic through its layers. While it has support for web essentials, you can choose to not include them and still benefit from the underlying framework benefits.

Open Source Ruby

In this open space session I sat at the Sidekiq table. Mike Perham held an informal chat. We discussed open source sustainability and succession planning. There were tables representing other projects, but I'm not sure what they covered.

Closing

Adarsh Pandit wrapped up RubyConf. We learned that RubyConf 2024 will be in Chicago in the fall. That's following a visit to Detroit in the spring for RailsConf.

Appreciation

Thank you to my employer, Pubmark, for supporting my attendance this year.

Thank you Ruby Central for your work to organize these events and supporting the Ruby community all year round.

Thank you to the Program Committee, Scholarship Committee, volunteers, and venue staff for bringing this conference to life.

Thank you sponsors for supporting the Ruby community and making it possible for us to come together.

Thank you Jonan Scheffler and Marty Haught for your years of service and dedication on the Ruby Central board.

Thanks to all the #RubyFriends, old and new, that I met in San Diego.

Thank you for reading to the end. Maybe we met at RubyConf 2023. Maybe we didn't. I hope to see you in 2024. I hear Chicago is lovely in November.

Preparing Conference Talk Delivery

Kevin Murphy — Tue, 17 Oct 2023 00:28:45 +0000

A conference accepted my proposal and I've built a slide deck. I still have a lot to do before hitting the stage!

Practice

At this point, I have a continual routine to get more familiar and comfortable with the material. It's also an opportunity to exercise the content on a continuous basis. The editing process isn't over here. However, it's more constrained and specific. I may be toying with the layout of a specific slide. Fighting with exactly the right word to describe a concept. Determining how to best highlight one aspect of what I'm saying.

I get the hint to make those targeted edits through practicing. I close the door to my office, stand up, and deliver the talk to an empty room. No more than once a day, and not every day, starting about a month out from the conference. And I time it, just like before.

I keep track of those times. That helps me reflect on knowing if I'm struggling to get through one section and need to tighten it up. It helps me know if I'm giving each section its appropriate focus. And looking back over the last few practices, it helps me see where I've gotten into a comfortable groove.

Each practice will have a bit of variation, because I don't follow an exact script. Over time, I'll see that I'm being more consistent in how long each area is taking (plus/minus 10 seconds or so per section). That tells me that I'm able to repeatedly deliver.

The stage is a different experience, but this preparation lets me draw from all the practice. It's not like I black out or go on auto-pilot mode, but I'm able to leverage all that work on stage. No one else in the audience knows what I'm going to say next as well as me, and that gives me comfort. People may be smarter than me. People may be more familiar with the topic. No one is going to say it the same way as I am right now, and that gives me confidence.

For the talk from the spreadsheet above, I logged 20 practice sessions.

Practice

I find other places to practice separated from my slides. When I would commute to work, I would practice (in my head) on the train ride in or back from work. I practice the full talk or sections while on walks. Some times, I run through ideas for my intro or conclusion as I'm drifting off to sleep.

I tell myself I want to be able to deliver my talk without the help of the slides. In case the power goes out and I need to entertain everyone in the dark, or outside, I can. Note that almost happened at RubyConf Mini 2022, when my laptop wouldn't connect to the projector.

When I’m practicing, I tell myself I need to prepare enough to give my talk without any slides or notes. I practice on walks, away from my material. I practice looking the other direction (checking occasionally to make sure I’m clicking to the right slide). In those moments on stage, I was wondering if my preparation would become necessary. Would I have to give my full talk without any slides?

Thanks Drew Bragg for unflinchingly handing me his laptop from the front row, letting me git clone the repo that has my slides on it. I ran the presentation from his computer, having never used it before.

Even without that dramatic scenario coming to light, practicing without slides helps me. I'm not tied to my slides. I don't need to read them. I can focus on the audience.

Practice

I find a real audience before the conference to practice with. Most times, that ends up being at work. There are also local meetup groups I could request to speak at. I could gather a group of friends.

My main goal is to give me the experience of delivering the talk for other people. It can help me know what beats might get laughs (rare, but I try). I might be able to see where people are more or less interested. I'll admit, that's hard for me to focus on while I'm also delivering the talk. It's to help me get more comfortable.

It's also a natural place for feedback, if you want it. Feedback can be very helpful and very dangerous. You're putting yourself out there and are being vulnerable. You may not like, or want, the feedback. That's something you need to decide for yourself. I consider the feedback I get, but I do not incorporate all of it. That doesn't mean it's bad - it may be objectively right. But if I can't find a way to incorporate it in a way that makes me comfortable on stage, I ignore it. If it takes away from my goals of what I want the presentation to deliver, I leave it be. I've given it the time and consideration, and thoughtfully chosen to do something else. That's hard to do, but I've gotten better at it, as I've gotten more comfortable knowing what my style is on stage.

Final Preparation

I store my slides in a GitHub repo, even while I'm developing it. That repo is public, which has the added benefit of being shareable, should I need to use another computer. I prefer using Keynote to any online tools, but that does limit the ease of access. Something new, given my RubyConf Mini issue, is to have a buddy with the slide deck on their laptop PRIOR. That may be a conference organizer. That way it's already set up, and I can confirm it looks exactly how I want. I use custom fonts and colors, and I want to make sure those get installed and are available too.

Going back to RubyConf Mini, I was very relieved to use Drew's computer, but it wasn't the experience I wanted it to be. We were installing it live on stage. I didn't have the time (or foresight) to install the fonts and colors I built the deck with. It's a touch that only I could have noticed, and didn't take away too much (I hope) from the experience. But it was still frustrating. It wasn't the exact visual presentation I had spent the time preparing for the audience.

I build a page on my website about each of my talks now. At the end of the presentation, I share that link. That can provide information about the talk. I include the proposal, the slides, code examples, and related blog posts. Some times I put details about the slides themselves, like photo credits and fonts used.

Once I'm confident they won't change, I publish my slides for the audience to access. I use Speaker Deck to host my slides.

Packing

Here are some things I bring to a conference in service of the talk. Even if I'm not speaking, I carry these with me, in case another speaker could use them. So, if you're at a conference I'm at and you're looking for one of these, come find me!

A button-up shirt - I wear these shirts so the wire of the lav mic can hide inside the shirt. Then I don't hit it if I'm waving my hands around or something.
Water bottle - Water is good. You should drink some before and during the talk...but not too much.
Clear plastic cup - I usually take this from my hotel room. I may not want to fumble with taking the cap on and off my water bottle, so I pour some water in the cup on stage.
Slide advancer - I like to walk a bit away from the podium in a small box. Holding this gives me the freedom to do that without needing to hop back to the computer to get to the next slide.
Extra batteries - It'd be a real shame if I couldn't advance the slides from my fancy slide advancer because I used up the batteries with all my practicing.
Laptop power cable - Especially if you practice with your laptop plugged in, give the talk with your laptop plugged in. You don't want some unexpected power saver setting surprising you on stage.
A/V connection or cables - The venue or organizers may say they'll have some, and you may need to use them, but better to have one of your own in case.
Throat lozenges - I put one in my mouth about an hour before I'm on stage, whether I need it or not.

At The Conference

I find the room I'm speaking in well before my time. Ideally a day before. At the very least, it resolves the immediate stress of needing to know where to go. I also ask to plug in my computer and make sure it works. This is a great chance to meet the A/V team that'll be helping you. I introduce myself and ask their names. I ask them if there's anything I can do to make their jobs easier. I let them know if I'm playing any audio on my computer. I tell them I'm likely to walk around (a little) on stage, and ask if that's any concern for them.

I go to the slide that has the smallest font, or most dense visuals on it, and then run (ok, walk) to the back of the room. I ensure it looks legible to me.

That is the only time I would consider making any changes to my slides, content, or delivery this late. Anything else would be detrimental to the experience. I've already practiced so much with it another way I do not feel comfortable making any other changes.

It may turn out there's a giant chandelier that obscures some of the projection. It's probably a good idea to take that into account for your audience.

If the schedule allows, I also see a talk in that room before my session. I sit in the back.

I practice the night before, by myself, in my hotel room. And only once. That rule still applies. Other speakers may form groups to do a run through or practice. I'm happy to attend those and support others, but it doesn't work for me to practice that way. It's a lot of energy for me to speak in front of a crowd, so I save it for the stage.

Day Of

As hard as it is, I try not to think too much about my talk before I give it. I've already practiced dozens of times. At this point, it is as good as it's going to be. This is easier said than done, but the goal is to not focus on it.

Be mindful of the schedule. Is there a short break before the talk? If so, then I stay in that room for the prior session, even if there's somewhere else I'd rather be. Whether there's a long or short break before, plan on people opening the door(s) and coming in late. That makes it less surprising when it happens.

If given the choice, I do not take questions from the large group. I'm happy to talk to anyone and everyone afterwards individually. I let the audience know where I'll be right after the talk. That's usually right next to the stage, but again, I'm mindful of the schedule. Is there's another talk right after? I want to cede that space to the next speaker to not interrupt their preparation.

After you're done, listen to your body. Do you need to go disappear and be by yourself? Do that! Do you need the affirmation of others? Find someone in the audience and go talk to them! You did it! Think about the special dessert you'll get at dinner to celebrate, even if that's alone in your hotel room.

Building Conference Talk Content

Kevin Murphy — Mon, 18 Sep 2023 12:52:28 +0000

Have you recently had a conference proposal accepted? Congratulations! Are you wondering, "what do I do now?" Here is the process I follow to turn my proposal into a full-length talk.

Content Generation

My first step is to gather all the content I want to talk about as quickly as possible. I know that sounds reductive. Oh, the first step is JUST to put together all your content? How easy! I might as well tell you how to draw an owl next.

But, here's the thing - for a conference talk, I'm not starting from scratch. I've already put a lot of time, and thinking, into the proposal. For me, that almost always includes a full outline. So I start by revisiting that and seeing what I need to add.

I completed most of my research in the proposal, but I may need to brush up on some details. There may be a book or research paper that I skimmed that I need to go back to and dig into.

Will I be using code examples to demonstrate some points? I'll start writing some code samples, in my usual code editor, that show what I want. I'll make sure they run. At this point, I'm not concerned about how terse or verbose they are. I'm not worried what the domain is. I need something that shows the point I want to make. I will admit that sometimes this code generation process is procrastination. I try to call myself out on that and not put too much effort into it at this point.

Shameless Green

My next step is to put my thoughts together on slides. I use the default theme. White background with black text. Whatever the default font is. I do not care about slide design at all at this point.

Some slides are one word. Some are an emoji. Some are a dense block of code. Some start as bullet points. Sometimes it's a thought about what I want the slide to eventually be, like, "insert picture of an owl". Everything is a placeholder at this point.

I call this process "Shameless Green". I borrowed this term from the book "99 Bottles of OOP" by Sandi Metz, Katrina Owen, and TJ Stankus. It doesn't match exactly, but it's stuck in my head, so I continue to use it. Intentionally reminding myself to be shameless gives me more license to do that. There's no polish here. This isn't even a first draft; it's only for me - there's no chance of another human seeing this.

First Delivery

After this, I deliver the talk. No, I don't get on stage with it. I don't have an audience. I close the door to my office, stand up, and speak out loud as if I were on a stage - with my slides in front of me on my computer.

This will be rough. I'll feel uncomfortable. I stop to write down when those feelings hit. Not enough to pull me out of my rhythm, but I don't want to forget it.

Some things I might write:

Slide 7 - awkward intro
Slide 13 - example doesn't work
Slide 16 - missing context
Slide 32 - repeating info from earlier

After I've gone through everything, I take a few minutes to review my notes. Only to make sure everything is legible and makes sense. I take the time to add more details where needed.

And then I walk away. I'll revisit it later with a fresh perspective.

Editing

I take a few hours to a day away from my initial attempt. I then review the notes while iterating through the slides. What I'm looking for here is any structural changes I need to make.

Is there a different order I should present information in? Maybe the section in Slide 32 needs to happen closer to Slide 16. That'll add more context immediately and eliminate the need to repeat myself later on.

If there are any transitions that feel awkward, I dig into why. Am I missing information? Do I have unnecessary information? Do I need to reorder the content? Is there a connection that I need to make more explicit, for myself and the audience?

These changes likely don't get done in one sitting. I revisit a section, or a transition, at a time. Then I review everything in total again. That might spark another round of smaller sections to focus on.

Theme

Now I'm comfortable with the general flow of information I want to share with the audience. Next, I build my theme. I still don't mean slide design here. I mean the real or imaginary world that my talk will be about. Some talks have a theme as part of their proposal. For others, I need to develop it at this point.

A theme is important for me in a talk because it turns my presentation into a story. I have a hard time delivering information over that period of time in hard, technical terms. Other people can, and that's great! It doesn't work for me. I need to have some real or imaginary scenario that the content relates to. Most of the time, this involves creating an imaginary product or company. That will illustrate the topics I'm sharing with the audience.

I may need to change all my examples to match the theme. The code samples now should reflect that theme. Let's say a talk is using a theme of managing scientific study participants. Code that was using ActiveRecord callbacks to send an email is now sending an informed consent document.

Second Delivery

I've reworked my transitions, moved sections around, and built up a story around my content. Now it's time to run through the presentation again. This time, I take fewer notes, but I also add something.

In this practice session, I start timing the presentation. Where I have discernible sections, I track those as splits/laps (depending on your timer of choice). Talks need to fit within a defined schedule. This is nowhere near polished. Still, the timing gives me a helpful sign of how far off I am from where I need to be.

Most of the time, I discover I'm way over on time.

Editing

In this editing session, I'm incorporating the same process from the first edit, but I'm adding to it. What am I going to cut entirely? Usually at this point I know what I want to say will take too long and I need to remove pieces. Even if I'm on time, I may recognize that there are pieces that don't complement my goal.

This is why I focus on "shameless green" to start. I haven't invested in picking colors or graphics for my slides. I haven't pored over detailed animations and visuals. Getting rid of content isn't easy, but it's harder (for me) the more work I've put into it.

This doesn't mean you've lost all that work you cut forever. First off, it was necessary to get what remains to where it is now. You learned something as part of putting that together that'll help you.

You can also reuse it elsewhere. I've turned sections of presentations I've had to cut into entirely different talks. Some have become blog posts. If you're not willing to let it go, but it doesn't fit in this format, it doesn't need to be the end. It needs to go somewhere else.

Slide Design

I am by no means a designer, but I do my best to deliver pleasant slides. Here are some things I look for.

Does the slide complement what I'm saying? My speech and the slide should work together, but not be the same. They should highlight what's important without being repetitive. How can I replace words with visuals? I've turned sentences of text into a single emoji. I've replaced them with a picture. I try to limit the text on the screen. I want my audience mostly listening to what I'm saying, not reading what's behind me.

Are the slides cohesive? I use slide templates to use consistent fonts, color schemes, and layouts. This also makes incorporating large design changes easier later on. Rather than needing to change 80 slides individually, I change the template.

Are my slides accessible? I run my color scheme through a contrast checker. I strive for a WCAG AAA level of contrast between my colors. I typically pick no more than four colors. A consistent background color. A consistent text color. No more than two colors for highlighting or drawing attention to parts of the slide.

Are my slides readable to the audience? I avoid putting any information you need the audience to see on the bottom third of the slides. Someone's head might be in the way. I distill code down to the essentials, even if that means it isn't syntactically valid or complete. I use as large of a font size and as few words as necessary.

I have what's showing on the slide be what you want the audience to focus on. Not what you're going to tell them in two more minutes. I don't have the entire code method on the slide. I have the one line that I'm talking about right now. Then the next slide adds the second line to it.

If I ever use any slide builds, each build is a separate slide. I don't use an animation that happens within one slide. It makes it easier to go back and forth between slides, if necessary.

Next Steps

I have my slides built at this point, but my work isn't over. Next I go through the laborious, repetitive process to provide a consistent delivery.

Keeping Up With Ruby News All Week Long

Kevin Murphy — Tue, 22 Aug 2023 00:44:58 +0000

I read a lot of Ruby news throughout the week. When someone asks me what they should follow, I first suggest that they not follow exactly the same blogs I do. Then I share the RSS feeds I follow just in case. But what I do suggest is starting with the following places. These highlight the work of others on a weekly basis. I then suggest they keep up with what resonates with them inside these round-ups.

Sunday

As you get ready to start your work week, what's new out there that can get you excited to write some code? Check out the Ruby Radar newsletter. The format shows two social media posts, two articles, two podcasts, two videos, and two code updates (commits, releases, projects).

Monday

Waiting in your inbox as you start your week is the Short Ruby Newsletter. Naming is hard, and this is the most comprehensive round-up of information I follow. Lucian curates a highlighted list of information about our community, events, code and Ruby, gems and libraries, and related (not Ruby specific) updates.

If that's not enough for you, there's more. That's followed with a list of other newsletters, podcasts, videos, and articles of the week. You'll likely have a lot of tabs open after getting through a full edition of Short Ruby.

Tuesday

After all that, you might need a break from reading. Instead, catch up with the newest episode of The Bike Shed podcast. While not Ruby-specific, the current hosts Joël Quenneville and Stephanie Minn frequently discuss Ruby topics. This thoughtbot podcast discusses what's new in these consultant's worlds from week to week.

Wednesday

You can continue with a podcast today with a new episode of The Ruby On Rails Podcast. It's hosted by Brittany Martin and a rotating panel of co-hosts. This is typically structured as an interview with a guest.

Thursday

Thursday is a big day for Ruby news. The Ruby Weekly newsletter comes out on this day. On top of the hottest news and updates of the week, this highly-curated newsletter provides a sample of tutorials, articles, videos, code, and tools that updated throughout the week.

Later in the day, dig in to the Awesome Ruby newsletter with more popular news and articles, followed with trending projects.

There is also the Ruby for All podcast. The topics can sometimes seem targeted to early-career developers. I've found that makes it an engaging conversation for everyone to follow and learn from.

Friday

You can check out a summary of commits and PRs specific to Rails with the This Week In Rails newsletter.

Entertain yourself at the end of the week with the Remote Ruby podcast. Andrew Mason, Chris Oliver, and Jason Charnes discuss the latest in what they're working on or interested in. Occasionally there are guests. Other times the panel of hosts are conversing amongst themselves.

Saturday

Take a break if you need to. Or use the time to catch up on what you've missed from these places throughout the week.

Weekly Reflection

After taking in the information, decide what sources from these curated experiences to keep up with. If you enjoyed what someone had to say, their latest won't always be in these round-ups. Follow podcast guests on social media. Add blogs you enjoy to your RSS reader. Join writer's newsletters. This is how I've cultivated my list of sources that I follow, whether they end up highlighted in a weekly review or not.