I had a small gotcha that derailed my afternoon. Hopefully, a Google search (or via our new AI overloads) will tell you if you hit the same.

First, here is the method I am trying to mock: identifier.call(transcript:)

My initial approach looked like this:

mock_identifier = Minitest::Mock.new
mock_identifier.expect :call, ["abc"], [{transcript: "some text"}]

But I kept getting an error like this: mocked method :call expects 1 arguments, got []

Eventually, via some debugging (binding.irb for the win), I found that I could call my mock like this:

identifier.call(:transcribe => "some text")

So that led me to believe something was getting confused with the mock + method signature.

I tried to double-splat the arguments but ended up with the same error.

mock_identifier = Minitest::Mock.new
mock_identifier.expect :call, ["abc"], [**{transcript: "some text"}]

Finally, I went with an alternative way to set and verify the arguments of the mock:

mock_identifier = Minitest::Mock.new
mock_identifier.expect :call, ["abc"] do |args|
   args == {transcript: "some text"}
end

And we are back in business...well, onto the next issue. But we are almost all ✅ now. 😀

For someone who thoroughly enjoys the Ruby language, one of the more rewarding aspects of using tools like Cursor and Supermaven has been exposure to some interesting Ruby methods I have not seen before.

Today, it was Enumerable#chunk_while.

The docs say:

Creates an enumerator for each chunked elements. The beginnings of chunks are defined by the block. This method splits each chunk using adjacent elements, elt_before and elt_after, in the receiver enumerator. This method split chunks between elt_before and elt_after where the block returns false. The block is called the length of the receiver enumerator minus one

Yes, that meant nothing to me as well. But here is a sample that should help. Let's take a grocery list in JSON and group all the items by the aisle they are found.

# Sample grocery shopping list
shopping_list = [
  { aisle: 'Produce', item: 'Apples' },
  { aisle: 'Produce', item: 'Bananas' },
  { aisle: 'Dairy', item: 'Milk' },
  { aisle: 'Dairy', item: 'Cheese' },
  { aisle: 'Canned Goods', item: 'Chickpeas' },
  { aisle: 'Canned Goods', item: 'Tomato Sauce' },
  { aisle: 'Snacks', item: 'Chips' },
]

chunked_items = shopping_list.chunk_while do |item1, item2|
  item1[:aisle] == item2[:aisle]
end

grouped_items = chunked_items.map do |aisle_group|
  {
    aisle: aisle_group.first[:aisle],
    items: aisle_group.map { |item| item[:item] }
  }
end

In the end, we have an array that looks like this:

[
 {:aisle=>"Produce", :items=>["Apples", "Bananas"]}
 {:aisle=>"Dairy", :items=>["Milk", "Cheese"]}
 {:aisle=>"Canned Goods", :items=>["Chickpeas", "Tomato Sauce"]}
 {:aisle=>"Snacks", :items=>["Chips"]}
]

Ruby has a built-in helper on Enumerable called - each_with_index

# An array of fruits
fruits = ["Apple", "Banana", "Cherry", "Date"]

# Using each_with_index to print each fruit with its index
fruits.each_with_index do |fruit, index|
  puts "#{index}: #{fruit}"
end

Unfortunately, there is no equivalent for the Enumerable#map.

['a','b'].map_with_index {|item,index|} # => undefined method map_with_index'`

There are easy ways to work around this, but the cleanest is by chaining with_index to .map

fruits = ["Apple", "Banana", "Cherry", "Date"]

result = fruits.map.with_index do |fruit, index|
  "#{index}: #{fruit}"  # Format the output with index
end

Why? My guess is to keep the number of methods smaller over time. Technically each_with_index could be deprecated since Enumerable#each.with_index is available. This way, we do not need a _with_index for everything on Enermable.

(1..100)
   .select
   .with_index {|n, index| (n % 2 == 0) && (index % 5 == 0)}

# [6, 16, 26, 36, 46, 56, 66, 76, 86, 96]

In the never-ending pursuit of optimal App/Window/Space management on my computer, I recently switched to AeroSpace

AeroSpace bills itself as:

an i3-like tiling window manager for macOS

If you are like me and have never used i3, you may be asking, what is this?

Honestly, it is hard to describe, but in a nutshell, it has replaced my usage of three different applications:

1. OS X Spaces (grouping of windows/projects/etc)
2. Magnet - window spacing
3. Alt+Tab - intelligent, quick app switching

These three apps work as expected (and I have nothing but praise for Magnet, which always did its job), but I find I work in a much more consistent and repeatable environment and spend far less time navigating between apps.

I recommend checking out this video for a detailed overview.

While adding revisions (auto-save and version history) to PhrontPage, I needed a way to add a new element to the page. Using turbo_stream#append, turbo_stream#update, etc. would work, but only if there is an element on the page with a known dom id. Eventually, I would like this item (a toast component) to be more generally available, so I did not want to need to have anything hardcoded on the page.

In addition to append, update, etc., there are matching methods append_all, update_all, etc., that allow targeting one or more items with more flexible query selectors.

Append to the targets in the dom identified with targets either the content passed in or a rendering result determined by the rendering keyword arguments, the content in the block, or the rendering of the content as a record append_all

In my case, the Toast is added to the page, displays, and then removes itself.

Hattip to Matt Swanson for highlighting the returning component for the turbo_stream response.

  def render_success_toast
    component = Admin::Toast::Component.new(text: "Your changes have been saved")
    render turbo_stream: turbo_stream.append_all("body", component)
  end

Kudos for the super helpful error message:

I have a constraint on the route, and I was passing "posts" instead of "posts.

delete "/orphans/:type/:uid", to: "orphans#delete", as: "delete_orphaned_items", constraints: {type: /(post|page)/}

GitHub - bensheldon/activerecord-has_some_of_many

Optimized top-N-per-group Active Record associations using lateral joins

This is the kind of query you write inefficiently just to get it done on every app.

Introduction to Minitest Mocks

Test doubles likes mocks and stubs can help us with isolating code under test with the rest of the system. Here’s how to mock in Minitest.

I am working on the Revision¹ functionality for PhrontPage (autosave + history). After getting the main pieces in place, I realized that you likely do not want revisions on new content until you reach a short minimal threshold (starting at 30 characters). So I added a quick check for the length of the markdown field, but that felt dirty hardcoding a specific field.

Next, I added a target(s) to my Stimulus controller. Now, any field with the target applied can be evaluated—there are no hardcoded field names, etc.

However, I could not for my life see why the following function was not returning true.

hasFieldsWithoutMinimalLength() {
  this.minimalLegthFieldTargets.forEach(field => {
    if (field.value.length < this.minimalLengthValue) {
      return true
    }
  })
  return false
}

In the golden age of programming (6 months or so ago), this would have resulted in a Google search or two, scrolling through Stack Overflow, or perhaps the X/Twitter hail mary. However, today, I can ask Claude via SuperMaven

(me) The function that starts on line #37, hasFieldsWithoutMinimalLength appears to iterate fine, but the return in line 40 is not stopping the function from returning false

And you get the following:

(Claude) You're correct in identifying the issue with the hasFieldsWithoutMinimalLength function. The problem is that the return true statement is inside the forEach loop, which doesn't actually stop the function's execution or return from the outer function. Instead, it only returns from the callback function passed to forEach.

I know there are folks generating whole applications, etc., but for me, this is a sweet spot. I enjoy writing code, the journey, and the act of creating². Having AI there to point out my obvious or sometimes subtle bugs is an amazing boost to my productivity.

For those curious, here is the fix and why.

hasFieldsWithoutMinimalLength() {
  return this.minimalLegthFieldTargets.some(field =>
    field.value.length < this.minimalLengthValue
  )
}

The some() method of Array instances tests whether at least one element in the array passes the test implemented by the provided function. It returns true if, in the array, it finds an element for which the provided function returns true; otherwise, it returns false. It doesn't modify the array.

It hurts my feelings when one flaky system test causes the whole bar to turn red.