DEV Community: Jess Alejo

Connecting GitLab MCP to Claude Code Without Putting Your Token in the Config

Jess Alejo — Tue, 08 Sep 2026 04:40:56 +0000

If you want your AI coding assistant to read GitLab issues, review merge requests, or check pipeline status, it needs API access.

The zereight/gitlab-mcp server provides exactly that over MCP.

The problem is that most setup examples put your personal access token directly into a JSON config file.

I wanted to avoid that.

Instead, this setup keeps the token in your shell environment and lets the MCP configuration reference it.

Same goal, but the secret does not have to be manually pasted into the configuration. It also makes rotating the token much easier.

This guide walks through the entire setup, including two problems that commonly cause this configuration to fail.

Prerequisites

You will need:

Node.js 18.17 or newer
A GitLab account on gitlab.com or a self-hosted GitLab instance
An MCP client. I am using Claude Code here, but the general configuration approach is portable.

Step 1: Create a Personal Access Token

In GitLab, go to:

User Settings > Access Tokens

Create a new personal access token.

Choose the scope based on what you want the assistant to be able to do:

Scope	Gets you
`read_api`	Read-only access. Enough to read issues, merge requests, and pipelines
`api`	Full read and write access. Needed to post comments or update issues

Set an expiry date.

Make sure you copy the token when GitLab shows it. You will not be able to view the token again later.

Step 2: Work Out Your API URL

The MCP server needs the GitLab API endpoint, not your normal GitLab web URL.

The API URL ends with /api/v4:

https://gitlab.com/api/v4
https://gitlab.example.com/api/v4

For a self-hosted instance, if your GitLab URL is:

https://gitlab.example.com

then your API URL is:

https://gitlab.example.com/api/v4

This is an easy place to make a mistake.

Do not use the bare hostname and do not use the project URL. The server needs the API endpoint.

Step 3: Export the Variables

Add both variables to your shell profile.

For Bash:

~/.bashrc

For Zsh:

~/.zshrc

For example:

export GITLAB_PERSONAL_ACCESS_TOKEN=glpat-xxxxxxxxxxxxxxxxxxxx
export GITLAB_API_URL=https://gitlab.example.com/api/v4

The `export` Is Important

This is probably the single most common way this setup fails.

Without export, you create a shell variable that exists only inside the shell where you defined it.

With export, you create an environment variable that is inherited by processes launched from that shell.

That distinction matters because MCP servers run as child processes.

So this:

FOO=bar
echo $FOO

works:

bar

But a child process will not see FOO unless it was exported:

FOO=bar
bash -c 'echo $FOO'

The result is empty.

You can verify the environment from a child process without printing the actual token:

bash -lic 'echo "token set: ${GITLAB_PERSONAL_ACCESS_TOKEN:+yes}"; echo "url: $GITLAB_API_URL"'

You want something like:

token set: yes
url: https://gitlab.example.com/api/v4

If the token line is blank, either:

You forgot export
You edited a profile file your shell does not actually read
You have not started a new shell after changing the profile

Step 4: Confirm the Token Works Before Involving MCP

Before troubleshooting MCP, make sure the GitLab credentials themselves work.

This takes about ten seconds and can save a lot of confusion.

If this request fails, the problem is your token or API URL. No amount of MCP configuration will fix it.

Run:

curl -s -H "PRIVATE-TOKEN: $GITLAB_PERSONAL_ACCESS_TOKEN" \
  "$GITLAB_API_URL/user"

You should get your GitLab user object back.

Then check that you can see the projects you expect:

curl -s -H "PRIVATE-TOKEN: $GITLAB_PERSONAL_ACCESS_TOKEN" \
  "$GITLAB_API_URL/projects?membership=true&per_page=20"

Take note of the numeric id of a project you care about.

It turns out to be more reliable than using the project path in some situations, which we will cover in the troubleshooting section.

Step 5: Install the Server

There are several ways to install the server.

Using npm:

npm install -g @zereight/mcp-gitlab

Or using Homebrew:

brew tap zereight/gitlab-mcp https://github.com/zereight/gitlab-mcp
brew install zereight/gitlab-mcp/zereight-mcp-gitlab

Both approaches give you the zereight-mcp-gitlab binary.

You can also skip installing it globally and let npx fetch it when it launches. That trades a little startup time for always getting the current package.

Check what you have installed:

command -v zereight-mcp-gitlab
npm ls -g --depth=0 | grep gitlab

Step 6: Register the MCP Server

Now for the interesting part.

The goal is to keep the token out of the MCP configuration itself.

With Claude Code:

claude mcp add -s user gitlab \
  -e 'GITLAB_PERSONAL_ACCESS_TOKEN=${GITLAB_PERSONAL_ACCESS_TOKEN}' \
  -e 'GITLAB_API_URL=${GITLAB_API_URL}' \
  -e 'GITLAB_PERMISSION_MODE=modify' \
  -- zereight-mcp-gitlab

There are three things worth paying attention to here.

1. The Single Quotes

Notice the single quotes around the ${...} values:

-e 'GITLAB_PERSONAL_ACCESS_TOKEN=${GITLAB_PERSONAL_ACCESS_TOKEN}'

The quotes prevent your shell from expanding the variable when you run the command.

The idea is for the literal ${GITLAB_PERSONAL_ACCESS_TOKEN} reference to be stored in the configuration, with the client resolving it when the server launches.

If you use double quotes instead:

-e "GITLAB_PERSONAL_ACCESS_TOKEN=$GITLAB_PERSONAL_ACCESS_TOKEN"

your shell expands the variable immediately.

That means today's token gets written into the configuration, which defeats the purpose of keeping the secret out of the config file.

There is an important caveat here, which we will revisit in Troubleshooting: variable expansion behavior can depend on how the MCP server is configured and launched.

2. Use User Scope

I am explicitly using:

-s user

rather than the default local scope.

A local-scope server is associated with the directory where you registered it.

That can become annoying when you open another repository and discover that the server is no longer available.

You may then register it again, potentially ending up with multiple copies of the same server configuration.

User scope registers the server once so it is available across your directories.

3. Set the Permission Mode

The command also includes:

GITLAB_PERMISSION_MODE=modify

We will look at the available modes in the next section.

Equivalent JSON Configuration

If you prefer editing the MCP configuration directly, the equivalent entry looks like this:

{
  "mcpServers": {
    "gitlab": {
      "type": "stdio",
      "command": "zereight-mcp-gitlab",
      "args": [],
      "env": {
        "GITLAB_PERSONAL_ACCESS_TOKEN": "${GITLAB_PERSONAL_ACCESS_TOKEN}",
        "GITLAB_API_URL": "${GITLAB_API_URL}",
        "GITLAB_PERMISSION_MODE": "modify"
      }
    }
  }
}

The important part is that the token value is a variable reference rather than the actual token.

Step 7: Choose a Permission Mode

The server defaults to full, which exposes every destructive tool it has.

I prefer setting the permission mode explicitly.

Mode	Read	Create and update	Delete
`readonly`	Yes	No	No
`modify`	Yes	Yes	Blocked
`full`	Yes	Yes	Yes

For most workflows, modify is a good middle ground.

It lets the assistant read issues, post review comments, and update descriptions while preventing delete operations.

If the assistant only needs to look things up, use:

readonly

I would avoid full unless you genuinely need the destructive operations.

Step 8: Restart and Verify

MCP servers are read by the client at startup, and a running client keeps the environment it was launched with.

This matters if you edited your shell profile in Step 3.

Your current Claude Code session may still have the old environment.

Start a fresh terminal and launch Claude Code again.

Then run:

claude mcp list
claude mcp get gitlab

You want to see the GitLab server connected without any missing-variable warning.

Finally, exercise the server.

Ask your assistant to fetch a real GitLab issue and verify that it can access the repository.

If you are using modify mode, also confirm that the delete tools are not available.

Trimming the Toolset

The server exposes 261+ tools.

That is a lot of surface area.

Depending on your context budget and workflow, exposing hundreds of tools can consume context that could otherwise be used for the actual task.

You can narrow the toolset if needed.

For example, only enable specific groups:

GITLAB_TOOLSETS=issues,merge_requests,pipelines

Or explicitly allow individual tools:

GITLAB_TOOLS=get_issue,list_issues,create_note

You can also use a deny-list:

GITLAB_DENIED_TOOLS_REGEX='^delete_'

My recommendation is to start broad and narrow the toolset only if it becomes a problem.

There is no need to optimize this upfront.

Troubleshooting

Server connects, but every call returns 401

Your token is probably not reaching the MCP process.

The most common cause is the missing export from Step 3.

Check it from a child process:

bash -lic 'echo ${GITLAB_PERSONAL_ACCESS_TOKEN:+set}'

You should get:

set

If you do not, check your shell profile and make sure the variable is exported.

`claude mcp list` warns about a missing variable

This means the ${VAR} reference did not resolve as expected.

Variable expansion is documented for .mcp.json and project-scoped servers, but whether the same behavior applies to user-scoped entries is not stated outright.

So this is something worth verifying rather than assuming.

If expansion fails, the configuration can still load while the literal string:

${GITLAB_PERSONAL_ACCESS_TOKEN}

gets passed to the server as the token.

The server can therefore appear healthy while every authenticated request fails with a 401.

If you run into this, you can interpolate the environment variable when adding the server instead:

claude mcp remove -s user gitlab

claude mcp add -s user gitlab \
  -e "GITLAB_PERSONAL_ACCESS_TOKEN=$GITLAB_PERSONAL_ACCESS_TOKEN" \
  -e "GITLAB_API_URL=$GITLAB_API_URL" \
  -e 'GITLAB_PERMISSION_MODE=modify' \
  -- zereight-mcp-gitlab

The tradeoff is that the actual secret is now written into the configuration.

You still keep a single user-scoped server entry, but you lose the benefit of keeping the secret out of the file.

`404 Project Not Found` for a project you can definitely see

GitLab's API accepts a URL-encoded project path such as:

group%2Fproject

However, some HTTP clients normalize %2F back into / before sending the request.

That can turn:

/projects/group%2Fproject/...

into:

/projects/group/project/...

which GitLab does not recognize as the intended project path.

curl --path-as-is can force the encoded form through, but the more durable solution is to use the numeric project ID from Step 4.

For example:

Using the numeric ID avoids the path-encoding problem entirely.

The server is missing in one repo but present in another

You probably registered it with local scope.

Re-register it at user scope:

claude mcp add -s user gitlab ...

Then clean up the old local entries from the directories where they were created:

(cd ~/code/some-project && claude mcp remove -s local gitlab)

Nothing changed after editing my shell profile

Start a new terminal and restart Claude Code.

The running client will not magically inherit environment changes made after it started.

Wrapping Up

The whole setup boils down to four things:

A GitLab personal access token with the right scope
An API URL ending in /api/v4
Both values exported into your environment
A single user-scoped MCP server entry

The most important detail is the environment variable.

If it is not exported, the MCP process cannot see it.

If the variable reference is not expanded by the client, the server may appear connected while authentication fails.

That is why I recommend verifying the environment from a child process and testing the GitLab API directly before involving MCP.

Once those pieces are correct, the rest tends to fall into place.

String#squish Quietly Changed My SQL

Jess Alejo — Sun, 12 Jul 2026 13:28:07 +0000

I use String#squish almost without thinking.

It's one of those little ActiveSupport helpers that keeps heredoc SQL readable in code and tidy in logs. You write a nicely indented query, call .squish, and end up with a clean one-liner.

sql = <<~SQL.squish
  SELECT *
  FROM orders
  WHERE status = 'active'
SQL

# => "SELECT * FROM orders WHERE status = 'active'"

I still love it.

Last week, though, it introduced a bug so subtle that I chased it through three layers of the stack before realizing the culprit had been sitting in plain sight the whole time.

The bug report

A reporting dashboard had an "Average Days to Ship" metric filtered by sales representative.

It worked perfectly for every rep except one.

Mary Jones

Notice the double space between her first and last name.

The report wasn't wrong. Her name really was stored with two spaces, and it displayed correctly everywhere else. Only this one metric always returned 0.

Note: The production query has been simplified and anonymized to protect sensitive data. The bug and the relevant code path are exactly the same.

The investigation

Suspect #1: The data

My first instinct was bad data.

SELECT sales_rep_name
FROM orders
WHERE sales_rep_name LIKE 'Mary%';

-- "Mary  Jones"

The database contained the double space exactly as expected.

Suspect #2: The params

Maybe the browser or Rails params had collapsed the whitespace.

I traced the value from the form, through the controller, into the query builder.

Still two spaces.

Suspect #3: The browser

HTML has its own whitespace rules, so I convinced myself the <select> element had to be responsible.

It wasn't.

The option was rendered with an explicit value="Mary Jones" attribute, and attribute values preserve internal whitespace.

Another dead end.

At that point, I finally did what I should have done from the beginning.

Instead of reasoning about where the value might have changed, I logged the final SQL string immediately before it was executed.

... WHERE "orders"."sales_rep_name" = 'Mary Jones' ...

One space.

The database had two.

The params had two.

The Arel-generated SQL fragment had two.

Somewhere during the final query construction, one of those spaces disappeared.

The reveal

Here's a simplified version of the method:

def sub_query
  <<~SQL.squish
    SELECT AVG(days) AS average_count
    FROM (
      SELECT ...
      FROM orders
      WHERE (#{apply_filter(Order.all).to_sql.split('WHERE').last})
    ) sub
  SQL
end

The important part is the order of operations.

apply_filter(...).to_sql produces a properly quoted SQL fragment:

"sales_rep_name" = 'Mary  Jones'

That fragment is interpolated into the heredoc.

At that point, the SQL string already contains the data value.

Then .squish runs.

And String#squish does exactly what it's designed to do: collapse every run of whitespace into a single space.

It doesn't know that some whitespace belongs to SQL formatting while other whitespace is part of a string literal.

To squish, they're all just whitespace.

You can reproduce it with a single line:

"WHERE name = 'Mary  Jones'".squish
# => "WHERE name = 'Mary Jones'"

The query now searches for a person who doesn't exist.

No rows match.

The metric ends up reporting 0.

Why this is such a good trap

Every individual piece of code is perfectly reasonable.

Building SQL with a heredoc.
Interpolating a properly quoted Arel fragment.
Using .squish to make the SQL compact.

The bug only appears when those three things are combined.

Even worse, it only appears when the data happens to contain adjacent whitespace.

Most names don't.

Most free-text values don't.

So the code can happily run for years, pass every test, and then one day someone named Mary Jones appears, or a product category is saved as Office Supplies, and one dashboard quietly starts reporting incorrect numbers.

Nothing crashes.

Nothing logs an error.

The result just looks... believable.

And that's the dangerous kind of bug.

A crash gets fixed.

A believable but incorrect number can live in production for months.

The fix

The fix turned out to be almost anticlimactic.

Don't apply a whitespace-normalizing transformation after you've already mixed data into the string.

Removing .squish solved the problem.

PostgreSQL doesn't care whether the query spans one line or twenty, so the SQL executes exactly the same.

The only difference is how it looks in the logs.

More importantly, avoid interpolating values into raw SQL whenever possible.

Let ActiveRecord and the database driver handle quoting and parameter binding instead.

The broader lesson

This isn't really about String#squish.

It's about applying text transformations after you've mixed structure and data into the same string.

Whether it's:

String#squish
strip
gsub(/\s+/, " ")
split.join(" ")
an HTML minifier
or any other "cleanup" step

they all operate on plain text.

They can't distinguish between formatting and content.

Once your data has been interpolated into the string, a transformation intended to clean up the structure can just as easily modify the data.

Normalize your templates before interpolation.

Normalize your data at the boundaries of your system.

But once structure and data have been combined into the same string, treat that string as read-only.

I still use String#squish almost every day.

I just make sure it's the last thing that touches my SQL template, not the first thing that touches my data.

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!

DEV Community: Jess Alejo

Connecting GitLab MCP to Claude Code Without Putting Your Token in the Config

Prerequisites

Step 1: Create a Personal Access Token

Step 2: Work Out Your API URL

Step 3: Export the Variables

The export Is Important

Step 4: Confirm the Token Works Before Involving MCP

Step 5: Install the Server

Step 6: Register the MCP Server

1. The Single Quotes

2. Use User Scope

3. Set the Permission Mode

Equivalent JSON Configuration

Step 7: Choose a Permission Mode

Step 8: Restart and Verify

Trimming the Toolset

Troubleshooting

Server connects, but every call returns 401

claude mcp list warns about a missing variable

404 Project Not Found for a project you can definitely see

The server is missing in one repo but present in another

Nothing changed after editing my shell profile

Wrapping Up

String#squish Quietly Changed My SQL

The bug report

The investigation

Suspect #1: The data

Suspect #2: The params

Suspect #3: The browser

The reveal

Why this is such a good trap

The fix

The broader lesson

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?

The `export` Is Important

`claude mcp list` warns about a missing variable

`404 Project Not Found` for a project you can definitely see

`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`?