DEV Community: Jess Alejo

TIL: How to Fix a PostgreSQL Collation Version Warning in a Kamal-Deployed Rails App

Jess Alejo — Fri, 16 Jan 2026 03:24:48 +0000

Today I learned how to properly fix this PostgreSQL warning in production:

WARNING: database "myapp_production" has a collation version mismatch
DETAIL: The database was created using collation version 2.36,
but the operating system provides version 2.41.

This typically appears after an OS or glibc upgrade. Your Rails app will continue to work, but PostgreSQL warns that text sorting and indexes may be inconsistent.

Why this matters

Collation affects:

ORDER BY
LIKE / ILIKE
indexes on text and varchar

Ignoring the warning can lead to subtle bugs, not crashes.

The fix (safe & recommended)

Since the app is deployed with Kamal, I ran the maintenance commands from inside the app container.

1. Exec into the running container and open the database console

kamal app exec -i "bin/rails dbconsole"

Rails handles the correct connection details and avoids Unix socket issues.

2. Refresh the collation version

ALTER DATABASE myapp_production REFRESH COLLATION VERSION;

This updates PostgreSQL's metadata to acknowledge the new OS collation rules.

3. Rebuild indexes

REINDEX DATABASE myapp_production;

⚠️ This briefly locks tables, so run it during low-traffic hours.

4. Verify

bin/rails console

The warning should no longer appear.

Takeaways

This is a PostgreSQL maintenance task, not a Rails bug
OS upgrades can require manual DB follow-up
Kamal is perfectly fine for running one-off production maintenance
Always rebuild indexes after refreshing collation

Short, practical, and now future-me won’t panic the next time I see that warning 😄

Pagy 9.1 to 43.0? What have Changed?

Jess Alejo — Sun, 16 Nov 2025 07:31:23 +0000

If you've noticed a massive version bump for the Pagy gem, you're not seeing things! The Pagy team skipped straight to Version 43.0.0, calling it a "leap version" to signal that this isn't just a new major release—it’s a complete overhaul and redesign of the best Ruby pagination gem.

Here is a look at the critical changes and exciting improvements that make Pagy v43 simpler, faster, and smarter.

1. The Critical Change: A Complete Redesign for Simplicity 🛠️

The core philosophy behind v43 is "more... with less."

This release represents a fundamental refactoring and redesign of the code, API, and usage. While this is a breaking change (you must check the upgrade guide!), the result is a massively streamlined experience:

Dramatically Simpler API: The mental load is gone. You now primarily need just the pagy method and the resulting @pagy instance to handle pagination for any collection type.
99% Reduction in Configuration: Pagy is now smarter out of the box, requiring far less manual setup than ever before.
Intelligent Autoloading: Say goodbye to unnecessary overhead. Methods are now autoloaded only if you use them, ensuring near-zero memory consumption for unused features.

2. 🚀 Performance and New Techniques

Pagy v43 pushes the boundaries of fast pagination techniques, offering options for every scenario.

The star of the show is the introduction of Keynav Pagination.

New Keynav: This exclusive Pagy technique is the next generation of keyset (cursor-based) pagination. It combines the extreme performance of keyset—which avoids slow OFFSET and COUNT queries—with all of Pagy's powerful frontend helpers.
Technique Versatility: Pagy now fully supports a comprehensive suite of pagination techniques, letting you choose the fastest method for your data:
- KEYNAV (The new fastest choice)
- KEYSET (Cursor-based)
- OFFSET (Traditional)
- COUNTLESS (For huge collections)
- CALENDAR (For time-based data)

3. 🪄 Better DX with New Interactive Dev-Tools

The new version includes features specifically designed to improve the developer experience (DX):

New PagyWand: This interactive tool helps you integrate Pagy’s CSS with your app's themes in real-time. It’s a huge win for styling and customization.
Pagy AI: A unique interactive AI is now available directly within the docs and your application to help you with specific Pagy usage questions.
Automatic I18n Loading: Internationalization is now handled automatically, saving you setup time.
Simplified JavaScript Setup: The process of setting up client-side rendering is now much easier.

Ready to Upgrade?

Pagy v43 is a powerful step forward. While the redesign is significant, the commitment to simplicity means your day-to-day coding will be cleaner and faster.

Be sure to check out the Upgrade Guide on the Pagy documentation to make your transition smooth!

Neat trick to Stop Retyping Arguments

Jess Alejo — Sun, 14 Sep 2025 01:31:38 +0000

It’s a quiet Sunday morning, and I’m tinkering with my side project. As I look at the service object I’m writing, I catch myself seeing the same pattern… again.

# This is what I keep doing.
class UserService
  def self.create(name:, email:, permissions:)
    new(name: name, email: email, permissions: permissions).save
  end

  def initialize(name:, email:, permissions:)
    @name = name
    @email = email
    @permissions = permissions
  end

  def save
    puts "Saving user #{@name}..."
  end
end

See that self.create method? All I’m really doing is grabbing arguments and passing them straight to new. It works, but it feels clunky. Every time I add a new argument to initialize, say an age parameter, I have to update it in two places. It’s a small hassle today, but tomorrow it’s a classic recipe for bugs.

Somewhere along the way I read about Ruby’s argument forwarding syntax (...). I need to burn this into my brain because it makes life so much easier.

Here’s the rewrite for my future self:

# This is how I should be doing it.
class UserService
  def self.create(...)
    new(...).save # <-- So much better
  end

  def initialize(name:, email:, permissions:)
    @name = name
    @email = email
    @permissions = permissions
  end

  def save
    puts "Saving user #{@name}..."
  end
end

The self.create(...) says, “Grab whatever comes in,” and new(...) replies, “Pass it all along.” Clean. Simple. Done.

Why this is better

It’s DRY. No more repeating name:, email:, permissions: twice. Less typing, less clutter.
It’s resilient. If I add age: to initialize, self.create doesn’t need a single change. Argument forwarding takes care of it automatically.
It covers everything. Positional args, keyword args, even blocks. The ... operator forwards it all.

And if I ever need to intercept just one argument while passing along the rest, say for logging, that’s easy too:

def self.create(name:, ...) # grab `name`, forward the rest
  puts "About to create a user named #{name}..."
  new(name: name, ...)
end

Memo to self

Use ... for forwarding arguments. It keeps code cleaner, avoids duplication, and saves future-me from unnecessary headaches.

What If Ruby Didn’t Have Syntactic Sugar?

Jess Alejo — Thu, 17 Jul 2025 03:09:40 +0000

If Ruby didn’t implement syntactic sugar, the language would still work just fine, but it wouldn’t be the Ruby we love. It would be less elegant, less expressive, and frankly, less enjoyable to use.

So what exactly would we be missing? Let’s take a closer look.

🍬 What Is Syntactic Sugar?

Syntactic sugar refers to language features that don’t add new functionality but make the code more concise, readable, and pleasant to write.

It’s like a shortcut or a smoother path to express something that’s otherwise more verbose or awkward.

🧱 Without Syntactic Sugar: More Verbose, Less Joy

Let’s explore how Ruby would look with and without some of its syntactic sweetness:

Example 1: Looping

With syntactic sugar:

5.times { puts "Hello" }

Without:

(0...5).each do |i|
  puts "Hello"
end

Example 2: Safe navigation (&.)

With syntactic sugar:

user&.email

Without:

user.nil? ? nil : user.email

Example 3: Conditional execution

With syntactic sugar:

puts "Welcome!" if logged_in

Without:

if logged_in
  puts "Welcome!"
end

🧠 Even Operators Are Methods in Ruby

Here's something that surprises many beginners: operators like +, -, and [] are just methods under the hood.

So when you write:

1 + 1

Ruby actually sees:

1.+(1)

Yes, even the + is a method being called on the 1 object. Here's a side-by-side of other common operators:

10 - 5              # 10.-(5)
10 / 5              # 10./(5)
10 * 5              # 10.*(5)
10 % 5              # 10.%(5)
10 ** 5             # 10.**(5)

Arrays too!

array = [*1..5]     # array = [1, 2, 3, 4, 5]
array << 6          # array.<<(6)
array[3]            # array.[](3)
array[4] = "five"   # array.[]=(4, "five")

Ruby makes these look natural, but under the hood, they’re all method calls.

Bottom Line:

Without syntactic sugar, Ruby would still be capable—but it would feel a lot more like Java or C: more boilerplate, less expression, and definitely less joy.

What sets Ruby apart isn’t just what it can do, but how naturally you can express your intent. That’s by design.

As Ruby’s creator Yukihiro “Matz” Matsumoto once said:

"I want to make Ruby natural, not simple... I want to minimize the human effort, not the computer's."

That vision is brought to life through syntactic sugar—making code feel like poetry, not machinery.

Fixing the “Could not find a valid mapping” Error in Rails 8 Tests

Jess Alejo — Tue, 24 Jun 2025 10:06:10 +0000

While writing RSpec tests for a model that references User, I encountered this error:

RuntimeError:
  Could not find a valid mapping for #<User ...

At first glance, it seemed like a Devise misconfiguration. But after digging deeper, I found the root cause: Rails 8 now lazy loads routes by default, and this behavior breaks Devise's internal logic during test runs if the routes haven't been loaded yet.

The Fix

To solve it, simply add this snippet in your spec/rails_helper.rb:

ActiveSupport.on_load(:action_mailer) do
  Rails.application.reload_routes_unless_loaded
end

This ensures routes are loaded before tests relying on Devise or User mappings run.

Why This Happens

Devise needs access to routes to resolve model mappings (like for authentication or email delivery). Since Rails 8 defers route loading for performance, Devise can’t find the route it needs during test boot, unless you force it.

Reference

Big thanks to Alvin Crespo for documenting this!

Comparing params.expect to params.require and params.fetch

Jess Alejo — Sat, 24 May 2025 16:31:31 +0000

I recently started using params.expect in my new Rails 8 project. It looked cleaner and more convenient than the usual require(...).permit(...) approach I’d been using. While it worked well in my code, I wanted to take a step back and understand how it actually compares to the older methods like params.require and params.fetch.

`params.require`

params.require(:user).permit(:first_name, :last_name)

This is the standard approach in Rails versions before 8. It explicitly requires that the :user key exists in the parameters. If it doesn't, Rails raises an ActionController::ParameterMissing error. After that, it permits only the specified attributes.

Pros:

Fails loudly if the expected key is missing.
Helps protect against mass-assignment vulnerabilities.
Well-documented and widely used in the Rails community.

Cons:

Slightly verbose, especially for nested structures.
Requires chaining requires and permit, which can feel repetitive.

`params.fetch`

params.fetch(:user, {}).permit(:first_name, :last_name)

This approach attempts to fetch the :user key. If it's not found, it returns and empty hash instead of raising an error. It's more forgiving method, but it has trade-offs.

Pros:

Avoids exceptions when the key is missing.
Useful in cases where the key is optional.

Cons:

Silently fails back to an empty hash, which can hide bugs.
Not recommended when strict validation is needed.

`params.expect` (Rails 8+)

params.expect(user: [:first_name, :last_name])

This method was introduced in Rails 8 as a more concise and strict way to handle parameters. It combines both the presence checking and attribute whitelisting in a single method call.

How it works:

Checks that :user exists in the parameters.
Ensures that only the listed attributes are allowed.
Raises an error if the structure does not match expectations.

Pros:

Cleaner syntax with less chaining.
Strict validation by default.
Easier to read, especially for nested or deeply structured parameters.

Cons:

Only available in Rails 8 and later.
May be unfamiliar to developers who haven't used the latest Rails versions.

Conclusion

If you are working on a Rails 8+ project, params.expect offers a more concise and expressive way to handle strong parameters. It replaces the need to separately call require and permit, while also enforcing strict structure validation.

For older version of Rails, or for developers who prefer explicit method chaining, params.require(...).permit(...) remains the reliable and well-understood approach.

Use params.fetch only when you have a clear reason to allow missing keys without raising an error; and be cautious about the risks it introduces.

This comparison helped me clarify when and why to use each method. I hope it helps others make more informed choices when writing controller logic in Rails.

readonly vs disabled in Rails Forms

Jess Alejo — Wed, 21 May 2025 22:54:44 +0000

Today I found out that disabling a form field in Rails means it won't be submitted at all. I used disabled: true thinking I could show a value that users can’t change — and I could — but the downside is that the value doesn’t get sent to the controller.

I learned that if I want the value to be shown but not editable and still be passed in the form data, the correct attribute to use is readonly: true.

This small difference between disabled and readonly matters when you're depending on that data in your controller.

It’s not a Rails issue; it’s how forms work in general.

Quick Example

<%= form_with model: @user do |form| %>
  <!-- This won't send the value -->
  <%= form.text_field :email, disabled: true %>

  <!-- This will send the value -->
  <%= form.text_field :email, readonly: true %>
<% end %>

This was a helpful thing to learn today. Hopefully it saves someone else a bit of time too.

Mastering Ruby's String Concatenation with the Backslash (`\`)

Jess Alejo — Fri, 04 Apr 2025 06:36:10 +0000

Have you ever struggled with long strings in Ruby that stretch way beyond the recommended 80-character line limit? Fear not—Ruby has a clever trick up its sleeve: the backslash (\). This handy tool lets you split long strings across multiple lines, keeping your code clean and readable without sacrificing functionality.

Let’s dive into how this works and why it’s such a game-changer for developers!

What Exactly Does the Backslash Do?

In simple terms, placing a backslash (\) at the end of a line tells Ruby, “Hey, this string isn’t done yet—it continues on the next line!” Ruby then stitches those lines together into one seamless string.

This is especially useful when dealing with long blocks of text, like SQL queries or error messages, where readability matters just as much as functionality.

How It Works in Practice

Here’s an example to make things crystal clear:

long_string = "This is a very long string that exceeds the 80 character limit " \
              "and we want to split it across multiple lines for better readability."

In this snippet:

The backslash (\) at the end of the first line signals that the string continues on the next line.
Ruby combines the two parts into one continuous string.
Notice that no extra space is added between the lines unless you explicitly include one (like the space after limit in this example).

The result? A single, easy-to-read string that doesn’t clutter your codebase.

When Should You Use This Technique?

The backslash method shines in scenarios where you’re working with lengthy text or complex queries. For instance, consider this SQL query inside a Rails scope:

scope :with_name_or_email, lambda { |name|
  if name.present?
    where(
      "LOWER(last_name) LIKE :name OR LOWER(first_name) LIKE :name OR " \
      "email LIKE :name",
      name: "%#{name.downcase}%"
    )
  end
}

Breaking the query into multiple lines makes it easier to read and debug. Without the backslash, you’d either have to cram everything into one long line (ugh!) or use awkward concatenation methods like +. The backslash keeps things neat and tidy.

Why You’ll Love Using the Backslash

Here are the top reasons to embrace this technique:

Readable Code: Long lines can be overwhelming and hard to maintain. Splitting them up improves clarity.
Better Formatting: Whether you’re writing SQL queries, error messages, or user prompts, breaking strings into logical chunks makes your code more professional.
No Extra Syntax: Unlike other languages where you might need to use + or other operators, Ruby handles it all automatically. Just add the backslash, and you’re good to go!

Key Things to Keep in Mind

While the backslash is incredibly useful, there are a few rules to remember:

No Automatic Spaces: Ruby won’t insert spaces between the lines unless you explicitly add them. For example:

   "Hello " \
   "world!"  # => "Hello world!"

Here, the space after "Hello " ensures the final output reads correctly.

Backslash Placement Matters: The backslash must always appear at the end of the line. If there’s anything after it—even a space—you’ll get a syntax error.

Wrapping Up

Using the backslash for string concatenation is a small but mighty tool in your Ruby toolkit. It helps you write cleaner, more maintainable code while adhering to best practices for line length. Whether you’re crafting SQL queries, formatting error messages, or simply managing long strings, this technique will save you time and headaches.

So next time you find yourself wrestling with a long string, remember: let the backslash do the heavy lifting. Your future self—and your teammates—will thank you!

Happy coding! 🚀

Why 0.1 + 0.2 Doesn’t Equal 0.3?

Jess Alejo — Fri, 28 Mar 2025 18:31:31 +0000

As developers, we often assume that basic arithmetic will always work as expected. For example, adding 0.1 and 0.2 should give us 0.3, right? But when you run this calculation in Ruby (or many other programming languages), you might be surprised by the result:

puts 0.1 + 0.2
# Output: 0.30000000000000004

Why doesn’t 0.1 + 0.2 equal exactly 0.3? Let’s break it down in simple terms.

The Problem: Computers Use Binary

Computers represent numbers in binary (base 2), but some decimal numbers can’t be perfectly represented in binary. For example:

The decimal number 0.1 is like 1/3 in base 10—it becomes a repeating fraction in binary.
Similarly, 0.2 also has a repeating binary representation.

When you add these imprecise binary representations together, tiny rounding errors occur. That’s why the result of 0.1 + 0.2 ends up being something like 0.30000000000000004 instead of exactly 0.3.

Why Does This Matter?

While the difference between 0.3 and 0.30000000000000004 might seem small, it can cause problems in situations where precision is important. For example:

if 0.1 + 0.2 == 0.3
  puts "Equal"
else
  puts "Not Equal"
end
# Output: Not Equal

This happens because the tiny error makes the numbers not exactly equal.

How to Fix It in Ruby

If you need precise results, here are two simple solutions:

1. Use BigDecimal for Exact Arithmetic

Ruby provides the BigDecimal class, which allows you to perform precise decimal calculations:

require 'bigdecimal'

a = BigDecimal("0.1")
b = BigDecimal("0.2")
result = a + b

puts result.to_s # Output: "0.3"

By using strings to initialize BigDecimal, you avoid the inaccuracies of floating-point numbers.

2. Round the Result

If you don’t need extreme precision, you can round the result to a reasonable number of decimal places:

result = 0.1 + 0.2
rounded_result = result.round(1)

puts rounded_result # Output: 0.3

This approach works well for most everyday cases.

Conclusion

The reason 0.1 + 0.2 doesn’t equal 0.3 is due to how computers represent decimal numbers in binary. While this can lead to unexpected results, tools like BigDecimal or rounding can help you get the answers you expect.

So next time you see 0.30000000000000004, remember—it’s just a quirk of how computers handle numbers!

Happy coding! 🚀

Simulating GCash's Lucky Load Game with Minimal Ruby Code

Jess Alejo — Wed, 26 Mar 2025 04:07:28 +0000

If you've ever participated in a lottery, raffle, or lucky draw, you might have wondered how many possible outcomes exist. In Ruby, three powerful methods—product, combination, and sample—make calculating and generating these possibilities simple. In this post, we'll explore how to use these methods to simulate games like GCash Lucky Load and the Super Lotto 6/49 lottery. By the end, you'll understand how to efficiently model scenarios like selecting 6 unique pairs from a set of options or picking 6 numbers out of 49 for a lottery.

Understanding `product`, `combination`, and `sample`

`product`: Generating All Possible Combinations

The product method in Ruby creates all possible pairings (or combinations) of elements from multiple arrays. This is particularly useful when combining two distinct sets of options, such as colors and icons.

For example, given an array of colors and an array of icons, product generates every possible color-icon pair:

colors = %w[Green Orange Red Purple Teal]
icons = %w[Crown Diamond Gift Thumb Ticket Trophy]

combinations = colors.product(icons)
puts combinations.inspect
#=> [["Green", "Crown"], ["Green", "Diamond"], ...]

This results in 30 unique color-icon pairs (5 × 6).

`combination`: Selecting Unique Groups

Once you've generated all possible pairs, combination(n) allows you to create unique groups of n items where the order doesn’t matter. This is perfect for simulating draws where only a subset of items is chosen.

draws = combinations.combination(6).to_a
puts "Total possible 6-draw combinations: #{draws.size}"
#=> Total possible 6-draw combinations: 593,775

`sample`: Simulating Random Draws

The sample method is useful for randomly selecting a single winning draw, simulating a real-world lottery or prize selection:

winning_draw = combinations.combination(6).to_a.sample
puts "Winning Draw: #{winning_draw.inspect}"
#=> [["Orange", "Gift"], ["Red", "Crown"], ...]

Now that we understand these methods, let’s apply them to simulate a GCash Lucky Load game.

Simulating GCash's Lucky Load Game

Step 1: Define the Available Choices

We set up two arrays: one for colors and another for icons.

colors = %w[Green Orange Red Purple Teal]
icons = %w[Crown Diamond Gift Thumb Ticket Trophy]

Step 2: Generate All Possible Color-Icon Combinations

Using product, we generate every possible pairing:

all_pairs = colors.product(icons)
puts "Total unique color-icon pairs: #{all_pairs.size}"
#=> Total unique color-icon pairs: 30

Step 3: Simulate a 6-Pair Lucky Draw

To simulate a game round, we randomly select 6 unique pairs from the 30 available.

draws = all_pairs.combination(6).to_a
winning_draw = draws.sample
puts "Winning combination: #{winning_draw.inspect}"

Step 4: Display the Winning Draw in a Grid

For better visualization, we format the output:

col_width = 8
puts " " * col_width + colors.map { |c| c.center(col_width) }.join

icons.each do |icon|
  row = icon.ljust(col_width)
  colors.each do |color|
    mark = winning_draw.include?([color, icon]) ? 'x' : 'o'
    row += mark.center(col_width)
  end
  puts row
end

puts "\nWinning selection:"
winning_draw.each { |color, icon| puts "x #{color}-#{icon}" }

This outputs a clear representation of the winning draw.

         Green   Orange   Red    Purple   Teal  
Crown      o       o       o       o       o    
Diamond    o       x       o       o       x    
Gift       o       o       o       x       o    
Thumb      o       x       o       o       o    
Ticket     o       o       x       x       o    
Trophy     o       o       o       o       o    

Winning selection:
x Orange-Diamond
x Orange-Thumb
x Red-Ticket
x Purple-Gift
x Purple-Ticket
x Teal-Diamond

Applying This to Other Games

These methods extend beyond just color-icon games. Here are some additional applications:

Lotto (Pick 6 out of 49 Numbers)

Ever wondered about your odds in a standard Super Lotto 6/49 game? With 13,983,816 possible combinations, here’s how to generate a winning draw:

numbers = (1..49).to_a
winning_draw = numbers.combination(6).to_a.sample
puts "Winning Lotto Draw: #{winning_draw.inspect}"

Fantasy Sports Drafts

Use combination to simulate drafting teams of players from a pool.

Card Games

Generate random hands by combining cards from a deck.

Prize Draws

Ensure fairness by randomly selecting winners from a list of participants.

Why Use `product`, `combination`, and `sample`?

Ruby’s product, combination, and sample methods offer efficient ways to generate, analyze, and randomly select from large sets of possibilities. Whether you're designing a game, running a raffle, or calculating probabilities, these methods allow you to:

Quickly calculate total possible outcomes.
Simulate random draws or selections.
Test different scenarios without manually listing all possibilities.

Conclusion

Ruby’s product and combination methods are powerful tools for simulating real-world games and scenarios. By combining them with sample, you can efficiently generate all possible outcomes and calculate probabilities. Whether you're designing a lucky draw, organizing a raffle, or building a card game, these methods make the process straightforward and fun.

Try experimenting with different sets and numbers to see how the odds change—and let us know what creative applications you come up with!

Final Notes:

The example above uses a 6-pair draw, but you can adjust this based on your game’s rules.
For larger datasets, consider using lazy evaluation (lazy) to optimize memory usage.

Happy coding!

Understanding `#model_name` in Rails

Jess Alejo — Mon, 24 Mar 2025 03:49:50 +0000

Rails is known for its developer-friendly conventions and built-in helpers that simplify common tasks. One such helper is the #model_name method, which provides a clean and idiomatic way to retrieve metadata about an ActiveRecord model's name. Whether you're working with singular, plural, or human-readable versions of a model's name, #model_name has got you covered.

What is `#model_name`?

The #model_name method is available on all ActiveRecord models and returns an instance of ActiveModel::Name. This object provides several useful methods to access different representations of the model's name, making it a versatile tool for various use cases. Some of the most commonly used methods include:

singular: Returns the singular form of the model's name (e.g., "admin_user").
plural: Returns the pluralized version of the model's name (e.g., "admin_users").
human: Returns a human-readable version of the name, often formatted for display purposes (e.g., "Admin user" instead of "AdminUser").
param_key: Returns the parameterized version of the model's name, which is particularly useful for form submissions (e.g., "admin_user").

These methods abstract away the need for manual string manipulation, ensuring consistency and reducing potential errors.

Examples in Action

Let’s consider a simple example with a namespaced model:

class Admin::User < ApplicationRecord
end

When we call model_name on this model, here’s what we get:

Admin::User.model_name.singular  # => "user"
Admin::User.model_name.plural    # => "users"
Admin::User.model_name.human     # => "User"
Admin::User.model_name.param_key # => "admin_user"

Notice how #model_name intelligently handles namespacing, returning the correct values for each context. For instance, while the class name includes the namespace (Admin::User), the singular and plural methods return only the base name ("user" and "users"), while param_key includes the namespace in a format suitable for URLs or forms ("admin_user").

Why Use `#model_name`?

Manually manipulating class names using .class.name.underscore.to_sym or similar approaches can be error-prone and less readable. Instead, leveraging #model_name ensures that your code remains clean, maintainable, and idiomatic.

For example, instead of writing:

current_user.class.name.underscore.to_sym

You can simply use:

current_user.model_name.singular.to_sym

This approach is especially valuable when dealing with namespaced models, as #model_name automatically accounts for the namespace without requiring additional logic.

Practical Use Cases

Here are some real-world scenarios where #model_name shines:

Form Helpers: When building forms, param_key is invaluable for generating the correct parameter names. For example:

   <%= form_with model: @admin_user do |form| %>
     <!-- Automatically uses param_key -->
   <% end %>

I18n (Internationalization): The human method integrates seamlessly with Rails' internationalization features, allowing you to display localized model names in your views.
Dynamic Routing: When dynamically generating routes or breadcrumbs, singular and plural help ensure consistency across your application.
Namespaced Models: As shown earlier, #model_name handles namespaced models gracefully, saving you from manually parsing or adjusting namespaces.

Final Thoughts

While #model_name might seem like a small feature, its ability to streamline model name retrieval cleanly and consistently makes it a valuable tool in any Rails developer's toolkit. By abstracting away the complexities of string manipulation and namespacing, it helps you write more maintainable and readable code.

Next time you find yourself needing a model's name in different formats, remember to reach for #model_name—it’s a small detail that can make a big difference! 🚀

Suggestions for Further Exploration

Dive deeper into the ActiveModel::Name class to explore additional methods and their use cases.
Experiment with how #model_name interacts with custom inflections in your Rails application.
Consider how #model_name can be extended or customized for specialized requirements in your app.

😊

Smart Defaults in Ruby: Setting Method Arguments Dynamically

Jess Alejo — Thu, 27 Feb 2025 20:20:39 +0000

In Ruby, method arguments can have default values, including values based on other arguments, constants, or even instance variables. This is a powerful feature that allows for flexible method definitions.

Static Default Values

The most common way to set default values in Ruby is by assigning a static value to a method argument. This ensures that if the caller does not provide a value, the method will use a predefined fallback.

def order_coffee(size:, milk: "almond milk")
  puts "You ordered a #{size} coffee with #{milk}."
end

Example Usage

order_coffee(size: "small")
# Outputs: You ordered a small coffee with almond milk.

order_coffee(size: "large", milk: "oat milk")
# Outputs: You ordered a large coffee with oat milk.

Here, milk defaults to "almond milk" unless explicitly specified.

Default Values Based on Arguments

Now, let's make the default value dynamic by basing it on the size parameter. If you don’t specify a milk preference, the barista might default to a milk type based on the coffee size.

def order_coffee(size:, milk: DEFAULT_MILK[size])
  puts "You ordered a #{size} coffee with #{milk}."
end

Example Usage

Suppose we define the DEFAULT_MILK constant like this:

DEFAULT_MILK = {
  "small" => "regular milk",
  "medium" => "almond milk",
  "large" => "oat milk"
}

Calling order_coffee(size: "medium") will automatically use:

puts "You ordered a medium coffee with almond milk."

Difference Between Dynamic and Static Defaults

Key Differences:

Using milk: DEFAULT_MILK[size] dynamically assigns the default based on the size parameter. This allows for flexible defaults based on input.
Using milk: "almond milk" sets a static default. If the caller does not specify a milk type, it will always default to "almond milk," regardless of the coffee size.

Dynamic defaults (using a hash or lookup table) are useful when the default value depends on other arguments. Static defaults work well when the default should be the same for all cases.

Using Instance Variables as Default Values

If you want to use instance variables instead of constants, be aware that instance variables are not available at the time the method is defined. However, you can work around this by using self or setting the value inside the method:

class CoffeeOrder
  def initialize
    @default_milk = {
      "small" => "regular milk",
      "medium" => "almond milk",
      "large" => "oat milk"
    }
  end

  def order_coffee(size:, milk: nil)
    milk ||= @default_milk[size]
    puts "You ordered a #{size} coffee with #{milk}."
  end
end

order = CoffeeOrder.new
order.order_coffee(size: "large")
# Outputs: You ordered a large coffee with oat milk.

Key Takeaways

You can use method arguments as default values for other arguments.
Static defaults apply a fixed fallback value regardless of other parameters.
Dynamic defaults (e.g., using a constant lookup) allow for context-aware default values.
Instance variables cannot be directly used as default values, but you can assign them within the method using ||=.

You can write more concise and maintainable Ruby code by leveraging these patterns. Happy coding!

DEV Community: Jess Alejo

TIL: How to Fix a PostgreSQL Collation Version Warning in a Kamal-Deployed Rails App

Why this matters

The fix (safe & recommended)

1. Exec into the running container and open the database console

2. Refresh the collation version

3. Rebuild indexes

4. Verify

Takeaways

Pagy 9.1 to 43.0? What have Changed?

1. The Critical Change: A Complete Redesign for Simplicity 🛠️

2. 🚀 Performance and New Techniques

3. 🪄 Better DX with New Interactive Dev-Tools

Ready to Upgrade?

Neat trick to Stop Retyping Arguments

Why this is better

Memo to self

What If Ruby Didn’t Have Syntactic Sugar?

🍬 What Is Syntactic Sugar?

🧱 Without Syntactic Sugar: More Verbose, Less Joy

Example 1: Looping

Example 2: Safe navigation (&.)

Example 3: Conditional execution

🧠 Even Operators Are Methods in Ruby

Arrays too!

Bottom Line:

Fixing the “Could not find a valid mapping” Error in Rails 8 Tests

The Fix

Why This Happens

Reference

Comparing params.expect to params.require and params.fetch

params.require

params.fetch

params.expect (Rails 8+)

Conclusion

readonly vs disabled in Rails Forms

Quick Example

Mastering Ruby's String Concatenation with the Backslash (`\`)

What Exactly Does the Backslash Do?

How It Works in Practice

When Should You Use This Technique?

Why You’ll Love Using the Backslash

Key Things to Keep in Mind

Wrapping Up

Why 0.1 + 0.2 Doesn’t Equal 0.3?

The Problem: Computers Use Binary

Why Does This Matter?

How to Fix It in Ruby

1. Use BigDecimal for Exact Arithmetic

2. Round the Result

Conclusion

Simulating GCash's Lucky Load Game with Minimal Ruby Code

Understanding product, combination, and sample

product: Generating All Possible Combinations

combination: Selecting Unique Groups

sample: Simulating Random Draws

Simulating GCash's Lucky Load Game

Step 1: Define the Available Choices

Step 2: Generate All Possible Color-Icon Combinations

Step 3: Simulate a 6-Pair Lucky Draw

Step 4: Display the Winning Draw in a Grid

Applying This to Other Games

Lotto (Pick 6 out of 49 Numbers)

Fantasy Sports Drafts

Card Games

Prize Draws

Why Use product, combination, and sample?

Conclusion

Understanding `#model_name` in Rails

What is #model_name?

Examples in Action

Why Use #model_name?

Practical Use Cases

Final Thoughts

Suggestions for Further Exploration

Smart Defaults in Ruby: Setting Method Arguments Dynamically

Static Default Values

Example Usage

Default Values Based on Arguments

Example Usage

`params.require`

`params.fetch`

`params.expect` (Rails 8+)

Understanding `product`, `combination`, and `sample`

`product`: Generating All Possible Combinations

`combination`: Selecting Unique Groups

`sample`: Simulating Random Draws

Why Use `product`, `combination`, and `sample`?

What is `#model_name`?

Why Use `#model_name`?