Unusual Case Statement Behavior

TIL something weird.

I expected this to print “Integer”, but it doesn’t:

mystery_class = Integer
case mystery_class
when Integer
  p "Integer"
else
  p "Unknown"
end
# => "Unknown"

This was weird because a similar example appears to behave differently:

mystery_instance = 0
case mystery_instance
when 0
  p "Y"
else
  p "N"
end
# => "Y"

Apparently this is because []case uses === under the hood](https://stackoverflow.com/a/3908411) and === has kind of silly behavior when comparing classes.

For example:

Array === Array # false
0 === 0         # true
Class === Array # true

apparently case also works different with ActiveRecord classes, since they’ll use is_a? instead which might also behave differently??? 😱

Anyway, if you want to use case with classes for ActiveRecord object you need to do this:

mystery_class = User.last
case mystery_class
when User
  p "User"
else
  p "Unknown"
end
# => "User"

Rails Rollback to Specific Migration

Occassionally, when working on an app with a lot of active branches that affect the database I run into an issue where I can’t rollback.

I’ll get an error like this:

rails aborted! ActiveRecord::UnknownMigrationVersionError:

No migration with version number 20230620205505.

This usually happens when I switch to another branch and I want to rollback a change I made to update/remove the migration. I assume the migration referenced in database doesn’t exist on the current branch.

If this happens, you can roll back to the last migration on the branch with:

rails db:migrate:down VERSION=n

where n is the timestamp from the latest migration (something like 20230607135355).

This is only applicable for non-sqlite3 databases, since the database doesn’t live in the project directory.

• Rails Guide
• SO answer

Hiccup with Rails 7 Generation

The server won’t work out of the box if you run the generate command with npm version < 7.1.

In particular, with < 7.1, you have to add the build commands to the package.json scripts yourself.

See this SO answer for more details.

I had mistakenly generated an app with a npm v6.8 b/c I used n to switch NodeJS versions to debug a student assignment and apparently never switched back.

I sure hope that hasn’t been the cause of other issues I ran into 😅

Redirecting stderr to stdout

Normally if you run a file from inside another script, it can be tricky to get get error message sometimes.

For example:

# test.rb



p("{}"

3.2.1 :001 > `ruby test.rb`
test.rb: --> test.rb
Unmatched `(', missing `)' ?          
> 4  p("{}"                           
test.rb:4: syntax error, unexpected end-of-input, expecting ')' (SyntaxError)
p("{}"                                
      ^                               
                                      
 => ""                                
3.2.1 :002 > 

The error message still is displayed in the shell, but it’s missing from the return value, which is the important thing if we’re running this inside another script/app.

The output is being displayed through stderr and not stdout.

There’s a trick you can do to merge stderr into stdout.

ruby test.rb 2>&1 which looks a little silly.

but now you get the error in the return value:

3.2.1 :004 > `ruby test.rb 2>&1`
 => "test.rb: --> test.rb\nUnmatched `(', missing `)' ?\n> 4  p(\"{}\"\ntest.rb:4: syntax error, unexpected end-of-input, expecting ')' (SyntaxError)\np(\"{}\"\n      ^\n\n" 

A breakdown of how it works:

File descriptor 1 is the standard output (stdout).

File descriptor 2 is the standard error (stderr).

At first, 2>1 may look like a good way to redirect stderr to stdout. However, it will actually be interpreted as “redirect stderr to a file named 1”.

& indicates that what follows and precedes is a file descriptor, and not a filename. Thus, we use 2>&1. Consider >& to be a redirect merger operator.

• SO answer

Better Rspec tests with shared examples

TIL about shared examples in Rspec!

They’re primarily good for reducing duplicate code.

They work well with subject and let.

This is a made up example:

describe "Todos" do
  context 'when on the edit page' do
    subject { Todo.create(title: "Day 1", body: "Hello, World!") }
    let(:path) { edit_todo_path(subject) }

    it "displays form" do
      visit path

      expect(page).to have_css("form")
    end
    
    it "redirects after submitting update form" do
      visit path

      click_on "Update #{subject.class}"

      expect(page.current_url).not_to be path
    end
  end
end

You could write very similar tests for other models.

With shared examples you could do something like this:

shared_examples_for "Editing a resource" do
  it "displays form" do
    visit path
    expect(page).to have_css("form")
  end

  it "redirects after submitting update form" do
    visit path
    click_on "Update #{subject.class}"
    expect(page.current_url).not_to be path
  end
end

describe "Todos" do
  context 'when on the edit page' do
    subject { Todo.create(title: "Day 1", body: "Hello, World!") }
    let(:path) { edit_todo_path(subject) }

    it_behaves_like "Editing a resource"
  end
end

Then in the future when you need a test that does something similar, you can make/reference a a shared example group.

• Shared Examples
• RSpec(Pt. 2): Hooks, Subject, Shared Examples