Forem: Zil Norvilis

It Looks Like Ruby, But It’s Not: How to Understand Elixir

Zil Norvilis — Wed, 15 Apr 2026 23:16:57 +0000

If you write Ruby, you will eventually get curious about Elixir. The creator of Elixir, José Valim, was a huge figure in the Ruby on Rails community. Because of this, when you look at Elixir code for the first time, it feels very familiar. It has def, do, and end.

But here is the trap: Elixir is not Ruby.

Very often I see Ruby developers try to write Elixir as if it was Ruby. They get frustrated because things don't work the way they expect. Ruby is Object-Oriented. Elixir is Functional.

To learn Elixir, you don't need to learn a crazy new syntax. You just need to rewire how you think about data. Here is a simple guide translating Ruby concepts into Elixir concepts.

1. Classes vs Modules

In Ruby, everything is an Object. You create a Class, initialize an object, and that object holds its own data (state).

# ruby
class User
  attr_accessor :name

  def initialize(name)
    @name = name
  end

  def upcase_name!
    @name = @name.upcase
  end
end

user = User.new("zil")
user.upcase_name!
puts user.name # Outputs: ZIL

In Elixir, there are no objects and no classes. Data is just data, and functions are just functions. They live separately. Instead of Classes, you group functions together inside Modules.

# elixir
defmodule User do
  # We just take data in, and return new data out
  def upcase_name(user_map) do
    Map.update!(user_map, :name, &String.upcase/1)
  end
end

user = %{name: "zil"}
# We pass the data into the module's function
new_user = User.upcase_name(user)
IO.puts new_user.name # Outputs: ZIL

2. Method Chaining vs The Pipe Operator

Ruby developers love method chaining. You take an object and call methods on it in a row.

# ruby
"hello world".upcase.split(" ").join("-")
# Outputs: "HELLO-WORLD"

Because Elixir doesn't have objects, you can't call .upcase on a string. You have to pass the string into a String module. Doing this normally looks very messy and nested: Enum.join(String.split(String.upcase("hello world"), " "), "-").

To fix this, Elixir uses the Pipe Operator (|>). It takes the result of the left side and passes it as the very first argument to the function on the right side.

# elixir
"hello world"
|> String.upcase()
|> String.split(" ")
|> Enum.join("-")
# Outputs: "HELLO-WORLD"

Once you get used to the Pipe Operator, you will actually miss it when you go back to Ruby. It makes reading the flow of data incredibly easy.

3. Hashes vs Maps

In Ruby, we use Hashes everywhere to store key-value data.

# ruby
user = { name: "Zil", role: "admin" }
puts user[:name]

In Elixir, the equivalent is called a Map. The syntax is almost identical, except you put a % sign in front of it.

# elixir
user = %{name: "Zil", role: "admin"}
IO.puts user.name

The big difference: In Ruby, you can just change the hash later (user[:role] = "user"). In Elixir, data is immutable. You cannot change the map once it is created. You have to create a brand new map with the updated value.

# elixir
user = %{name: "Zil", role: "admin"}
# This creates a completely new map in memory
updated_user = %{user | role: "user"}

4. The Equals Sign is a Lie (Pattern Matching)

This is the hardest part for Rubyists to grasp.

In Ruby, = means assignment. You are saying "Put this value into this variable."

# ruby
name = "Zil"

In Elixir, = is actually the Match Operator. It is like an algebra equation. It tries to make the left side match the right side.

# elixir
name = "Zil" # This works, Elixir binds "Zil" to name to make it match.

# But you can also do this:
%{name: user_name} = %{name: "Zil", role: "admin"}

IO.puts user_name # Outputs: "Zil"

In that second example, Elixir looks at the right side, sees the map, and says: "To make the left side match, I need to extract the value of :name and put it into the user_name variable."

This is called Pattern Matching. It is the most powerful feature in Elixir. You use it everywhere - to extract data from APIs, to handle errors, and to route web requests.

Summary

Learning Elixir when you already know Ruby is a really fun experience. You don't have to fight with ugly brackets or semicolons.

Just remember the golden rules of Elixir:

Data never changes (Immutability).
Data and Functions live separately.
Use |> to push data through your functions.

That's pretty much it. Even if you never build a production app in Elixir, learning how functional programming works will absolutely make you a better, cleaner Ruby developer.

Pundit vs CanCanCan vs Action Policy: Which Rails Auth Gem Wins?

Zil Norvilis — Tue, 14 Apr 2026 23:17:20 +0000

Sometimes I find myself starting a new Rails project, and almost immediately, I hit a wall: User Permissions.

Guests can read posts, users can edit their own posts, and admins can delete everything. You need an authorization system to manage this. If you try to write this logic directly inside your controllers or views with a bunch of if/else statements, your code will become an unreadable mess within a week.

For a long time, the Rails community was divided. Today, we have three main gems to handle this: CanCanCan, Pundit, and the newer Action Policy.

Here is my honest breakdown of how they work, the pros and cons of each, and which one you should actually use for your next app.

1. CanCanCan (The Legacy Giant)

If you learned Rails 5 or 6 years ago, you probably used CanCanCan (a community continuation of the original cancan gem).

How it works:
It is highly centralized. You define absolutely every permission for your entire application inside one single file called the Ability class.

# app/models/ability.rb
class Ability
  include CanCan::Ability

  def initialize(user)
    user ||= User.new # guest user

    if user.admin?
      can :manage, :all
    else
      can :read, Post
      can :update, Post, user_id: user.id
    end
  end
end

Then, in your controller, you just call authorize! :update, @post.

The Good: For a very small app, it is incredibly fast to set up. You can see all the rules in one place.
The Bad: As your app grows, the Ability file becomes a nightmare. I have seen production apps with an ability.rb file that is 2,000 lines long. It becomes impossible to test and incredibly slow to load, because Rails has to evaluate that entire massive file on every single request.

2. Pundit (The Object-Oriented Standard)

Pundit was created to solve the "giant file" problem of CanCanCan. It threw away the custom syntax and went back to plain, simple Ruby.

How it works:
Instead of one big file, you create a separate "Policy" class for every single model in your app.

# app/policies/post_policy.rb
class PostPolicy
  attr_reader :user, :post

  def initialize(user, post)
    @user = user
    @post = post
  end

  def update?
    user.admin? || post.user_id == user.id
  end
end

In your controller, you use the same authorize @post method, and Pundit automatically looks for the PostPolicy and calls the update? method.

The Good: It is incredibly clean. Because it is just plain Ruby objects returning true or false, writing tests for your policies is super easy. It scales perfectly with huge applications.
The Bad: It can feel a bit repetitive. You end up writing a lot of boilerplate initialize methods for every single policy file.

3. Action Policy (The Modern Speed Demon)

Action Policy is the newest challenger, built by the team at Evil Martians. It looked at Pundit and said: "This is great, but we can make it faster and require less typing."

How it works:
It looks very similar to Pundit, but it gives you a base class to inherit from, which removes the need to write initialize methods. It also adds powerful features right out of the box.

# app/policies/post_policy.rb
class PostPolicy < ApplicationPolicy
  # We can alias methods so we don't repeat code!
  alias_rule :edit?, :destroy?, to: :update?

  def update?
    user.admin? || record.user_id == user.id
  end
end

The Good:

Performance: It is heavily optimized. It caches authorization results during a request. If you check if a user can update a post 50 times in a view loop, Action Policy only calculates it once. Pundit calculates it 50 times.
Less Code: Features like alias_rule save you from writing duplicate methods.
GraphQL Integration: If you are building a modern API with Ruby-GraphQL, Action Policy integrates flawlessly.

The Bad: It has a slightly larger learning curve if you want to use its advanced caching and scoping features compared to the absolute simplicity of Pundit.

Summary: Which one should you pick?

Don't overcomplicate your decision. Here is the golden rule I follow today:

Do not use CanCanCan for new projects. It is great for legacy codebases, but the centralized design pattern is an anti-pattern for modern, scalable web apps.
Use Pundit if you want the most "standard" approach. Almost every Rails developer knows how to read Pundit code, and the documentation is everywhere.
Use Action Policy if you are building a highly performant app, an API, or if you just hate writing boilerplate code.

Personally, I have completely switched to Action Policy for all my new Rails 8 apps. The built-in caching and the cleaner syntax make it the absolute winner for modern Ruby development.

Wise Testing: What to Test (and Ignore) as a Solo Rails Developer

Zil Norvilis — Mon, 13 Apr 2026 23:22:57 +0000

Solo founders fail for a completely preventable reason. It’s not because their idea was bad, and it’s not because they couldn't code. It’s because they spent 4 weeks writing unit tests for a product that had zero paying customers.

In the enterprise world, 100% test coverage is an insurance policy. In the startup world, as a One-Person Team, 100% test coverage is a death sentence. You will run out of momentum and quit before you launch.

But you can't just ship with zero tests, or you will be too terrified to deploy updates on a Friday.

You need Wise Testing. This is the art of getting 90% confidence with 10% of the code. By sticking to Rails defaults (Minitest and Fixtures), you can build a safety net that protects your business without slowing down your MVP.

Here is my exact guide on what to test, and more importantly, what to completely ignore.

RULE 1: What NOT to Test (The Time Wasters)

The biggest mistake beginners make is testing the Rails framework. Rails has thousands of contributors who already tested ActiveRecord. You do not need to test it again.

Do NOT test validations:

# A useless test
test "user is invalid without an email" do
  user = User.new(email: nil)
  assert_not user.valid?
end

If you wrote validates :email, presence: true in your model, trust that Rails works.

Do NOT test basic CRUD controllers:
Don't write isolated controller tests just to check if the index action returns a 200 status code. It is a massive waste of time. Your System Tests will catch if the page crashes.

Do NOT test third-party UI:
If you are using Tailwind UI or a component library, don't write tests to ensure a button is blue.

RULE 2: The "Golden Path" System Tests (High ROI)

If you only have time to write one type of test, write System Tests.

A system test boots up a real browser (using Capybara and Selenium/Playwright), navigates your app, and clicks buttons like a real human.

Why is this the best use of your time? Because one system test implicitly tests your routing, your controller, your database, and your view rendering all at once.

Identify the "Golden Paths" of your app. These are the 2 or 3 flows that must work for your business to survive.

For a SaaS, the Golden Path is usually:

User signs up.
User creates the core resource (e.g., a "Project").
User upgrades to a paid plan.

# test/system/onboarding_test.rb
require "application_system_test_case"

class OnboardingTest < ApplicationSystemTestCase
  test "user can sign up and create a project" do
    # 1. Sign up
    visit new_user_registration_path
    fill_in "Email", with: "founder@example.com"
    fill_in "Password", with: "secret123"
    click_on "Sign Up"

    # 2. Core Business Action
    click_on "New Project"
    fill_in "Name", with: "My Awesome MVP"
    click_on "Save"

    # 3. Verify Success
    assert_text "Project was successfully created."
    assert_text "My Awesome MVP"
  end
end

If this single test passes, you have a 90% guarantee that your app is functional.

RULE 3: Surgical Unit Tests (The Money and the Math)

You skipped testing basic models and controllers. So when do you write unit tests?

You write them for Custom Business Logic. If a method calculates a tax rate, processes a Stripe webhook, or filters sensitive data, you must test it in isolation.

Always extract this complex logic into Plain Old Ruby Objects (Service Objects), and test those.

# test/services/commission_calculator_test.rb
require "test_helper"

class CommissionCalculatorTest < ActiveSupport::TestCase
  test "calculates 10 percent commission for standard affiliates" do
    # Standard math logic that MUST be right
    calculator = CommissionCalculator.new(amount: 100_00, rate: 0.10)
    assert_equal 10_00, calculator.payout
  end

  test "returns zero if order is refunded" do
    calculator = CommissionCalculator.new(amount: 100_00, rate: 0.10, refunded: true)
    assert_equal 0, calculator.payout
  end
end

Test the things that would cause you to lose money or leak private data if they broke.

RULE 4: Embrace Rails Fixtures (Skip FactoryBot)

The RSpec world loves FactoryBot. Factories are great, but they dynamically generate and insert database records on every single test run. As your app grows, this makes your test suite agonizingly slow.

Rails defaults to Fixtures. Fixtures are simply YAML files that get loaded into your test database once when the test suite boots.

# test/fixtures/users.yml
zil:
  email: zil@example.com
  encrypted_password: <%= User.new.send(:password_digest, 'password') %>
  plan: pro

# Inside your tests, you just reference the name:
user = users(:zil)

For a solo developer, Fixtures are the ultimate speed hack. Your Minitest suite will run in a fraction of a second, meaning you will actually run it frequently while coding.

💡 Want the complete system?
If this pragmatic approach resonates with you and you want to see exactly how I set up my test suites from scratch, I’ve put my entire testing workflow into a comprehensive guide. Check out Wise Testing: The Solo Founder's Guide to Rails Quality to learn how to test Stripe webhooks, handle complex fixtures, and set up lightning-fast CI pipelines.

Summary: The Wise Testing Checklist

Before you write a test, ask yourself: "If this breaks, does the business fail, or does it just look a little weird?"

Do not test Rails. (Validations, associations, simple controllers).
Write 3-5 System Tests. Cover the absolute critical paths (Signup, Core Value, Checkout).
Write Surgical Unit Tests. Only test complex math, money, and security logic.
Use Minitest and Fixtures. Keep your test suite boring, fast, and dependency-free.

Ship the MVP. Let the users find the small bugs. Use your automated tests to protect the big ones.

Stop AI Spaghetti: Enforcing Rails Architecture in 2026

Zil Norvilis — Sun, 12 Apr 2026 23:12:24 +0000

We are fully in the era of autonomous coding. If you use tools like Cursor, Windsurf, or Copilot Workspace, you know how fast you can move. You type a prompt, and the AI generates an entire feature - controllers, models, and views—in 10 seconds.

But there is a dark side to this speed.

The AI does not know your personal architectural standards. If you don't watch it closely, it will put complex business logic directly into your ActiveRecord callbacks. It will make raw API calls from your ERB views. Give it a few months, and your beautiful Rails app will turn into an unmaintainable "Big Ball of Mud."

When you are generating code this fast, you cannot rely on willpower to keep things clean. You need automated guardrails. Here is how to ensure autonomously generated code stays consistent with your Rails architecture over time.

STEP 1: The Context File (`.cursorrules`)

The easiest way to fix bad AI code is to prevent it before it is written.

Modern AI code editors look for hidden context files in your project root (like .cursorrules or .windsurfrules). This file tells the AI how you expect it to behave in this specific repository.

Instead of typing "Use a service object" in every single prompt, you define your architectural boundaries once.

Create a .cursorrules file in your Rails root:

# Rails Architecture Guidelines for this Project

1. **Fat Models, Skinny Controllers are BANNED.** Controllers should only handle HTTP routing and params. Models should only handle database associations and strict validations.
2. **Business Logic:** ALL business logic must go into Plain Old Ruby Objects (POROs) inside `app/services/`. Do not use ActiveRecord callbacks (`after_save`, `after_create`) for business logic like sending emails or calling external APIs.
3. **Views:** Use Tailwind CSS for styling. Extract complex UI elements into `ViewComponent` classes instead of using Rails `_partials`.
4. **Testing:** Write Minitest System Specs for all new features. Do not write granular unit tests for private methods.

Now, when you tell the AI to "Build a user onboarding flow," it automatically knows to generate a UserOnboardingService instead of dumping 200 lines of code into the UsersController.

STEP 2: Ruthless Linting with RuboCop

AI is notoriously bad at code formatting. It will mix single and double quotes, mess up indentation, and write methods that are 50 lines long.

You need to enforce style programmatically. In Ruby, this means RuboCop. But you need to turn on the strict Rails-specific rules.

Add these to your Gemfile:

group :development, :test do
  gem 'rubocop', require: false
  gem 'rubocop-rails', require: false
  gem 'rubocop-performance', require: false
end

Create a .rubocop.yml file and set your boundaries. For example, if you want to stop the AI from writing massive, complex methods, enforce the MethodLength and Metrics/AbcSize cops.

# .rubocop.yml
require:
  - rubocop-rails
  - rubocop-performance

Metrics/MethodLength:
  Max: 15

Metrics/ClassLength:
  Max: 100

Rails/SkipsModelValidations:
  Enabled: true # Stops AI from using .update_attribute and skipping your validations

The Pro Move: Set your editor to "Auto-Fix on Save." When the AI generates a messy file, you just hit Cmd+S, and RuboCop instantly rewrites the syntax to match your standard.

STEP 3: Enforcing Boundaries (Packwerk)

If your app is growing large, the AI will eventually try to cross-wire different domains. It will make the Billing module call private methods inside the Inventory module.

To stop this structurally, you can use Shopify's Packwerk gem. Packwerk allows you to define strict boundaries between folders in your Rails app.

You create a package.yml file in your folders:

# app/services/billing/package.yml
enforce_privacy: true
enforce_dependencies: true

If the AI generates code in the Orders controller that tries to call an internal class inside the Billing package, Packwerk will throw a static analysis error before you even run the code. It literally blocks the AI from creating spaghetti dependencies.

STEP 4: System Tests over Unit Tests

When you use AI, your internal code changes very fast. You might ask the AI to refactor a Service Object, and it will completely rename all the internal methods.

If you have 100 granular Unit Tests checking those specific method names, your test suite will break every time you prompt the AI. You will spend hours fixing tests instead of shipping features.

To survive the AI era, you must rely on System Tests (Integration Tests).

# test/system/onboarding_test.rb
require "application_system_test_case"

class OnboardingTest < ApplicationSystemTestCase
  test "user can sign up and reach the dashboard" do
    visit new_user_registration_path
    fill_in "Email", with: "test@example.com"
    fill_in "Password", with: "password123"
    click_on "Sign up"

    assert_text "Welcome to your Dashboard"
  end
end

System tests don't care how the AI wrote the backend logic. They don't care if the AI used a Service Object or a background job. They only care that the user can click the button and get the result.

By writing System tests, you give the AI the freedom to refactor and optimize the internal architecture without breaking your test suite, while giving yourself 100% confidence that the app still works.

Summary

In 2026, your job is no longer just typing code. Your job is acting as the Editor-in-Chief for an incredibly fast, slightly reckless junior developer.

Give Context: Use .cursorrules to define your architecture up front.
Auto-Format: Use RuboCop to enforce syntax rules on save.
Set Boundaries: Use static analysis (like Packwerk) to prevent tangled dependencies.
Test the Output: Rely on System Tests to verify behavior, not internal implementation.

If you set up these guardrails on day one, you can let the AI run wild, knowing your Rails app will stay clean, modular, and easy to maintain.

How to Fix N+1 Queries in Rails Like a Pro

Zil Norvilis — Sat, 11 Apr 2026 23:11:25 +0000

There are Rails applications that run incredibly fast on a developer's laptop, but the moment they are deployed to production, they crawl to a halt. The pages take 3 seconds to load, and the database CPU is at 100%.

Almost every single time, the culprit is the exact same thing: The N+1 Query Problem.

ActiveRecord is amazing because it hides the complex SQL from you. But because it is so easy to use, it is also very easy to accidentally hammer your database with hundreds of unnecessary queries.

Here is exactly what the N+1 problem is, how to fix it using .includes, and how to handle complex nested data like a senior Rails developer.

The Problem: What is N+1?

Imagine you have a Post model and a User model (the author). You want to list 50 posts on your homepage and show the author's name next to each one.

You write this in your controller:

# app/controllers/posts_controller.rb
def index
  @posts = Post.limit(50)
end

And you write this in your view:

<!-- app/views/posts/index.html.erb -->
<% @posts.each do |post| %>
  <h2><%= post.title %></h2>
  <p>By: <%= post.user.name %></p>
<% end %>

This looks perfectly fine. But if you look at your terminal logs, you will see a nightmare.

Rails runs 1 query to fetch the 50 posts.
Then, as it loops through the HTML, it hits post.user.name. It doesn't have the user data in memory, so it asks the database: "Hey, get me the user for post 1."
Then it asks: "Get me the user for post 2."
It does this 50 times.

You just ran 51 queries to load a single webpage. If you have 1,000 posts, you run 1,001 queries. This is the N+1 problem.

LEVEL 1: The Basic Fix (`includes`)

To fix this, we need to tell ActiveRecord to fetch all the related data before we start looping in the view. We do this using Eager Loading via the .includes method.

Change your controller to this:

# app/controllers/posts_controller.rb
def index
  # We tell Rails: "Fetch the posts, AND fetch their users right now."
  @posts = Post.includes(:user).limit(50)
end

Now, look at your server logs. Rails will only run 2 queries:

SELECT * FROM posts LIMIT 50
SELECT * FROM users WHERE id IN (1, 2, 3, 4...)

Rails grabs all 50 users in one big query, and stitches them together in memory. The speed difference is massive.

LEVEL 2: Nested Includes (Going Deeper)

What if your data is more complex?
Let's say you want to show the Post, the User's name, the User's Profile picture, AND a list of all the Comments on the post.

If you just do .includes(:user), the comments and the profile will still trigger N+1 queries. You have to pass a Hash to .includes to load nested relationships.

def index
  @posts = Post.includes(
    comments: :author,    # Loads comments, AND the author of each comment
    user: :profile        # Loads the post user, AND the user's profile
  ).limit(50)
end

Using arrays and hashes, you can build a perfectly optimized data tree with a single line of code.

LEVEL 3: includes vs preload vs eager_load (The Pro Stuff)

When you use .includes, Rails does something very clever. It looks at your query and decides the best way to fetch the data. But as you get more advanced, you should know exactly what is happening under the hood.

ActiveRecord actually has three different methods for eager loading:

1. .preload (The Default)
This is what .includes usually does behind the scenes. It ALWAYS runs two separate queries.
SELECT * FROM posts and then SELECT * FROM users WHERE id IN (...).
It is very fast and uses less memory. But, you cannot use a where clause on the preloaded table. If you try Post.preload(:user).where(users: { active: true }), your app will crash.

2. .eager_load (The Giant Join)
This forces Rails to use a LEFT OUTER JOIN. It grabs all the posts and all the users in one single, massive query.
You use this when you specifically need to filter by the associated table:
Post.eager_load(:user).where(users: { active: true })

3. .includes (The Smart Manager)
.includes is the safe middle ground. By default, it acts like .preload. But if Rails sees that you added a .where referencing the joined table, it automatically switches to acting like .eager_load.

Rule of thumb: Just stick to .includes 90% of the time, and let Rails do the thinking.

LEVEL 4: Strict Loading (The Ultimate Safety Net)

Even senior developers accidentally introduce N+1 queries. You might add a new helper method in a view months later and forget to update the controller's .includes.

To prevent this from ever reaching production, modern Rails has a feature called Strict Loading.

If you turn this on, Rails will literally crash your app (raise an error) the moment it detects an N+1 query. It forces you to fix it immediately.

You can do this on a single record:

@post = Post.strict_loading.first
@post.user # => Raises ActiveRecord::StrictLoadingViolationError!

Or, you can do what I do and turn it on globally for your development and test environments.

# config/environments/development.rb
config.active_record.strict_loading_by_default = true

Now, you can never accidentally write a view that triggers an N+1 query without your local server screaming at you to add .includes. It is the best performance habit you can build.

Summary

ActiveRecord makes database interactions feel like magic, but you always have to pay attention to the logs.

Check your terminal. If you see the same SELECT statement repeating 50 times in a row, you have an N+1 problem.
Use .includes in your controller to fetch the data upfront.
Use Hashes for deeply nested associations.
Turn on strict_loading in development to catch the bugs before your users do.

That's pretty much it. Fixing N+1 queries is usually the easiest way to make a slow Rails app feel 10x faster.

Building a World-Class Search Engine in Rails with Searchkick

Zil Norvilis — Fri, 10 Apr 2026 23:03:11 +0000

Stop Using SQL LIKE: A Step-by-Step Guide to Elasticsearch in Rails

When you build a standard Rails app, searching your database usually starts with a simple ActiveRecord query: Product.where("name ILIKE ?", "%#{params[:q]}%").

This works fine when you have 100 products. But when you have 100,000 products, it gets very slow. Even worse, if a user searches for "iphne" instead of "iphone", your database returns zero results. Users expect Google-level search with auto-complete and typo forgiveness. Postgres can do basic Full Text Search, but setting it up perfectly is painful.

This is where Elasticsearch comes in.

Elasticsearch is essentially a secondary, NoSQL database completely optimized for searching text. Integrating it with Rails sounds intimidating, but thanks to an amazing gem called Searchkick, you can build enterprise-grade search in about 10 minutes.

Here is the step-by-step guide to adding Elasticsearch to your Rails app without losing your mind.

STEP 1: The Setup

First off, you need Elasticsearch running on your computer. The absolute easiest way to do this without messing up your Mac or Linux machine is to use Docker. Run this in your terminal to start a local server:

docker run -p 9200:9200 -e "discovery.type=single-node" docker.elastic.co/elasticsearch/elasticsearch:8.13.0

Now, let's add the gems to your Rails app. We need the official client and the Searchkick wrapper.

# Gemfile
gem 'elasticsearch'
gem 'searchkick'

Run bundle install.

STEP 2: Tell Your Model to Listen

Elasticsearch does not magically read your Postgres database. It is a separate engine. We need to tell our Rails model to sync its data to Elasticsearch.

Open your model (let's use a Product model) and add one word:

# app/models/product.rb
class Product < ApplicationRecord
  searchkick
end

That's it. From now on, whenever you create, update, or destroy a Product, Searchkick will automatically send a background request to Elasticsearch to keep the search index perfectly in sync with your database.

STEP 3: Index Your Existing Data

Because you just added the gem, Elasticsearch is currently empty. It doesn't know about the products you created yesterday.

You need to push your existing database records into Elasticsearch. Open your Rails console (rails c) and run:

Product.reindex

You will see a progress bar as Searchkick grabs all your products and sends them to the search engine. Anytime you make massive database changes (like a raw SQL bulk update), you should run this command.

STEP 4: The Search Query

Now for the fun part. Let's replace that ugly ILIKE query in our controller.

Searchkick gives us a .search method that feels just like ActiveRecord, but it queries Elasticsearch instead of Postgres.

# app/controllers/products_controller.rb
class ProductsController < ApplicationController
  def index
    query = params[:q].presence || "*"

    @products = Product.search(query, 
      fields: [:name, :description],
      match: :word_start,
      misspellings: { edit_distance: 2 }
    )
  end
end

Look at how powerful this is:

fields: We tell it to only look at the name and description.
match: :word_start allows for auto-complete. If they type "lap", it matches "laptop".
misspellings: This is the magic. If they type "lpatop", Elasticsearch knows they meant "laptop" because the "edit distance" (number of wrong letters) is within our limit.

STEP 5: Customizing the Index (The Pro Move)

By default, Searchkick sends every single column of your database to Elasticsearch. If you have a secret_cost column or a user_password column, you absolutely do not want that in your search index.

You should always control exactly what data gets indexed. You do this by overriding the search_data method in your model.

# app/models/product.rb
class Product < ApplicationRecord
  searchkick

  belongs_to :category

  def search_data
    {
      name: name,
      description: description,
      price: price,
      # We can even index associated data!
      category_name: category.name,
      in_stock: stock_count > 0
    }
  end
end

Now, when you run Product.reindex, only this specific JSON block is sent to Elasticsearch. Because we included category.name, users can now type "Electronics" in the search bar, and it will return the products belonging to that category, without doing any complex SQL JOIN queries.

Summary

That's pretty much it. Adding Elasticsearch used to require hundreds of lines of configuration and complex JSON mapping files.

With Searchkick, the workflow is incredibly simple:

Add the gem.
Add searchkick to your model.
Run Model.reindex.
Use Model.search("query").

If your app relies heavily on user discovery - like an e-commerce store, a directory, or a massive blog—ditching SQL for a dedicated search engine is the biggest UX upgrade you can make.

The Easiest Way to Add Drag and Drop to Your Rails App

Zil Norvilis — Thu, 09 Apr 2026 23:13:05 +0000

Building Drag and Drop in Rails 8 with SortableJS and Importmaps

Very often I find myself building apps where users need to reorder things. Maybe it is a list of tasks, a gallery of images, or steps in a project.

In the old days, we used jQuery UI for this. Then we moved to complex React drag-and-drop libraries. But if you are using modern Rails with Hotwire, adding drag and drop is actually incredibly simple. We don't even need Node.js or Webpack.

We can use a lightweight library called SortableJS, load it via Importmaps, and connect it to our database using a single Stimulus controller.

Here is exactly how to do it in 5 steps.

STEP 1: The Database Setup

First off, our database needs to know the order of our items. Let's assume we have a Task model. We need to add a position column to it.

Run this migration in your terminal:

rails g migration AddPositionToTasks position:integer
rails db:migrate

Pro tip: I highly recommend adding the acts_as_list gem to your Gemfile. It handles all the annoying math of shifting positions up and down in the database automatically.

If you use the gem, just add this to your model:

# app/models/task.rb
class Task < ApplicationRecord
  acts_as_list
end

STEP 2: Pin SortableJS (Importmap)

Because we are using Importmaps, we do not need to run npm install. We just pin the library directly from the CDN.

Run this in your terminal:

bin/importmap pin sortablejs

This will automatically add the correct URL to your config/importmap.rb file.

STEP 3: The HTML View

Now let's build the list in our view. We need to wrap our tasks in a div or ul and attach a Stimulus controller to it. We also need to give each item a data attribute so our Javascript knows which Task ID is being dragged.

<!-- app/views/tasks/index.html.erb -->

<h1>My Tasks</h1>

<!-- We attach the 'sortable' controller here -->
<ul data-controller="sortable">
  <% @tasks.order(:position).each do |task| %>

    <!-- We store the task ID on the list item -->
    <li data-id="<%= task.id %>" class="p-4 bg-white border mb-2 cursor-move">
      <%= task.name %>
    </li>

  <% end %>
</ul>

STEP 4: The Stimulus Controller

Next, we generate our Stimulus controller:

rails g stimulus sortable

Open the newly created file at app/javascript/controllers/sortable_controller.js. This is where the magic happens. We import SortableJS, initialize it, and tell it to send a network request to Rails whenever the user drops an item.

// app/javascript/controllers/sortable_controller.js
import { Controller } from "@hotwired/stimulus"
import Sortable from "sortablejs"

export default class extends Controller {
  connect() {
    // Initialize Sortable on the HTML element this controller is attached to
    this.sortable = Sortable.create(this.element, {
      animation: 150,
      onEnd: this.updatePosition.bind(this)
    })
  }

  updatePosition(event) {
    // Get the dragged item's ID and its new index in the list
    const id = event.item.dataset.id
    const newIndex = event.newIndex + 1 // ActsAsList is 1-indexed, JS is 0-indexed

    // Grab the CSRF token so Rails doesn't block our request
    const csrfToken = document.querySelector("[name='csrf-token']").content

    // Send an AJAX request to our Rails controller
    fetch(`/tasks/${id}/move`, {
      method: "PATCH",
      headers: {
        "Content-Type": "application/json",
        "X-CSRF-Token": csrfToken
      },
      body: JSON.stringify({ position: newIndex })
    })
  }
}

STEP 5: The Rails Controller & Route

The Javascript is sending a PATCH request to /tasks/:id/move. Let's create that route and the controller action to handle it.

Update your routes:

# config/routes.rb
resources :tasks do
  member do
    patch :move
  end
end

And finally, update the database in your TasksController:

# app/controllers/tasks_controller.rb
class TasksController < ApplicationController
  def move
    @task = Task.find(params[:id])

    # If you are using the acts_as_list gem, it is this simple:
    @task.insert_at(params[:position].to_i)

    # We don't need to render a view, just tell JS it was successful
    head :ok
  end
end

Summary

That's pretty much it!

We pinned the library via Importmap.
We initialized SortableJS in a 10-line Stimulus controller.
We used a standard fetch request to update the position in the database.

No massive React setups, no JSON API wrappers, and absolutely zero Webpack configurations. Just plain HTML, a tiny bit of Javascript, and standard Rails routing. This is why the modern Hotwire stack is so incredibly fast for building features.

AdonisJS vs Ruby on Rails: Which MVC Framework Wins?

Zil Norvilis — Wed, 08 Apr 2026 23:12:07 +0000

Very often I see JavaScript developers getting tired of building backend APIs with Express.js. Express is incredibly fast, but it has zero structure. You have to figure out where to put your routes, how to connect to the database, and how to handle authentication completely by yourself.

Eventually, these developers discover AdonisJS.

Adonis is literally famous for being the "Ruby on Rails of Node.js". It gives you a beautiful MVC (Model-View-Controller) structure, an ORM for the database, and everything comes pre-configured. It is, without a doubt, the best backend framework in the JavaScript ecosystem.

But if it is so good, why do I still use Ruby on Rails in 2026?

I have built projects with both. While Adonis is a massive upgrade for Node.js developers, here is my honest breakdown of why Rails is still the ultimate tool for getting things done.

1. The Language: Ruby vs TypeScript

AdonisJS is built entirely with TypeScript. For a lot of people, this is a huge plus. TypeScript catches errors before you even run your code, which is great for massive teams.

But for a solo developer or a small startup, TypeScript can feel like wearing handcuffs. You have to define types, write interfaces, and constantly satisfy the compiler. It slows down your prototyping.

Ruby, on the other hand, was built for Developer Happiness. It is expressive and reads almost like plain English.

# ruby
3.days.ago
users.map(&:name)
if user.active? && user.subscribed?

When I write Ruby, I feel like I am just writing down my thoughts. When I write TypeScript, I feel like I am filling out legal paperwork.

2. The ORM: ActiveRecord vs Lucid

Adonis comes with a fantastic ORM called Lucid. It is heavily inspired by Rails and Laravel. It handles migrations, models, and relationships very well.

// adonis (TypeScript)
const users = await User.query()
  .where('is_active', true)
  .orderBy('created_at', 'desc')

It is very good. But ActiveRecord in Rails is simply magic. It has been polished for over 20 years. The sheer amount of built-in features, scopes, and association helpers in ActiveRecord makes querying the database effortless.

# rails
@users = User.active.order(created_at: :desc)

Plus, Rails handles database migrations slightly better. If you need to roll back a migration, Rails almost always knows how to reverse it automatically. In Adonis, you often have to write the "up" and "down" logic manually.

3. The Frontend Setup

AdonisJS pairs beautifully with Inertia.js (which lets you build your frontend in React, Vue, or Svelte without an API). If you love the Javascript ecosystem, this is a dream setup.

But it still means you have a complex build step. You still have a package.json file with 50 dependencies. You still have to wait for Vite or Webpack to compile your frontend code.

Rails 8 takes a completely different path. With Hotwire and Importmaps, Rails eliminates the build step entirely.

You write standard HTML (ERB) views, and Hotwire makes the page feel as fast as a React app without writing any custom JavaScript. If you want to add a library, you just pin it with Importmaps. Your computer's hard drive isn't clogged with massive node_modules folders, and your app boots instantly.

4. The Ecosystem and "The Rails Way"

The NPM (Node Package Manager) registry is huge. You can find a package for literally anything.
The problem? A lot of NPM packages are tiny, abandoned, or don't play nicely together.

In the Ruby world, gems are usually built specifically for Rails.

Need authentication? Use devise or has_secure_password.
Need an admin panel? Use avo.
Need background jobs? Rails 8 has solid_queue built right in.

Because Rails enforces "The Rails Way" (Convention over Configuration), almost every gem plugs into your app perfectly. You don't have to waste a weekend writing glue code to make a library work with your framework.

Summary: Which one should you use?

I have a lot of respect for AdonisJS. It brings much-needed sanity to the chaotic Node.js world.

Choose AdonisJS if you already know TypeScript, you absolutely love React/Vue, and you want to use a single language (Javascript) across your entire stack. It is the best choice in the Node ecosystem.
Choose Ruby on Rails if you value your time above everything else. If you are a solo founder, an indie hacker, or you just want to take an idea and turn it into a profitable product as fast as humanly possible, Rails is still undefeated.

I tried the "Rails of Node", but it turns out, I just prefer the real thing.

How to Accept Crypto Payments in Your Rails 8 App

Zil Norvilis — Tue, 07 Apr 2026 23:11:38 +0000

When users reach out asking: "Can I pay with Bitcoin or USDC?"

In the past, my answer was always no. The thought of setting up a Bitcoin node, managing private keys, and constantly checking the blockchain for confirmations sounded like an absolute nightmare for a solo developer.

But in 2026, accepting crypto is exactly like accepting credit cards. You do not need to touch the blockchain directly. You just use a payment gateway (like Coinbase Commerce, NowPayments, or BTCPay Server) that handles the wallet generation and gives you a simple REST API and webhooks.

Here is how to integrate a crypto payment gateway into your Rails 8 app in 4 easy steps. I will use the standard API approach, which works for almost any major crypto provider.

STEP 1: The Database Setup

First off, we need a way to track the payment. When a user clicks "Pay with Crypto", the gateway will generate a unique payment ID. We need to save this ID in our database so we can update the order when the user actually sends the funds.

Let's generate a simple Order model:

rails g model Order user:references amount_in_cents:integer status:string crypto_charge_id:string
rails db:migrate

In our model, we can set a default status:

# app/models/order.rb
class Order < ApplicationRecord
  belongs_to :user

  # Statuses: pending, unconfirmed, completed, failed
  after_initialize :set_default_status, if: :new_record?

  def set_default_status
    self.status ||= 'pending'
  end
end

STEP 2: Creating the Charge (The API Call)

When the user clicks the checkout button, we need to tell our crypto provider to generate a payment page with the exact amount and currency.

We don't need a heavy SDK for this. We can just use the http gem to make a fast POST request to the provider's API (in this example, I'll use the Coinbase Commerce API structure, as it is the industry standard).

# app/controllers/crypto_checkouts_controller.rb
require 'http'

class CryptoCheckoutsController < ApplicationController
  def create
    @order = current_user.orders.create!(amount_in_cents: 50_00) # $50.00

    # 1. Call the Crypto Gateway API
    response = HTTP.headers(
      "X-CC-Api-Key" => ENV['CRYPTO_API_KEY'],
      "X-CC-Version" => "2018-03-22",
      "Content-Type" => "application/json"
    ).post("https://api.commerce.coinbase.com/charges", json: {
      name: "Pro Subscription",
      description: "One year of Pro access",
      local_price: {
        amount: "50.00",
        currency: "USD"
      },
      pricing_type: "fixed_price",
      metadata: { order_id: @order.id } # We pass our internal ID here!
    })

    # 2. Parse the response
    charge_data = JSON.parse(response.body)["data"]

    # 3. Save their unique charge ID
    @order.update!(crypto_charge_id: charge_data["id"])

    # 4. Redirect the user to the generated Crypto payment page
    redirect_to charge_data["hosted_url"], allow_other_host: true
  end
end

STEP 3: The View

This is the easiest part. You don't need to build a complex UI with QR codes. The gateway handles that for you. You just need a button.

<!-- app/views/pricing/index.html.erb -->

<div class="pricing-card">
  <h2>Pro Plan - $50</h2>

  <!-- Credit Card Button -->
  <%= button_to "Pay with Stripe", stripe_checkout_path %>

  <!-- Crypto Button -->
  <%= button_to "Pay with Crypto", crypto_checkouts_path, class: "btn-crypto" %>
</div>

When the user clicks this, they are redirected to a secure, hosted page where they can pick their coin (BTC, ETH, USDC), scan the QR code with their wallet, and send the money.

STEP 4: The Webhook (The Magic)

Crypto transactions take time. Bitcoin can take 10 minutes to confirm. Because of this, the user might close their browser before the payment finishes.

To solve this, the crypto gateway will send a background Webhook (a POST request) to your Rails app the moment the blockchain confirms the money has arrived.

We need to create a controller to catch this request, verify it is actually from the gateway (and not a hacker), and update our order.

# app/controllers/webhooks/crypto_controller.rb
class Webhooks::CryptoController < ApplicationController
  # We must skip the CSRF token check because this request comes from an external server
  skip_before_action :verify_authenticity_token

  def create
    payload = request.body.read
    signature = request.headers['X-CC-Webhook-Signature']

    # 1. Verify the signature (Crucial Security Step!)
    # We use OpenSSL to generate a hash using our secret key and the payload
    digest = OpenSSL::Digest.new('sha256')
    computed_signature = OpenSSL::HMAC.hexdigest(digest, ENV['CRYPTO_WEBHOOK_SECRET'], payload)

    unless ActiveSupport::SecurityUtils.secure_compare(computed_signature, signature)
      render plain: "Invalid signature", status: 400
      return
    end

    # 2. Process the event
    event = JSON.parse(payload)
    event_type = event.dig("event", "type")

    # The gateway passes back the metadata we gave it in Step 2
    order_id = event.dig("event", "data", "metadata", "order_id")
    order = Order.find_by(id: order_id)

    if order
      case event_type
      when "charge:pending"
        order.update!(status: 'unconfirmed')
      when "charge:confirmed", "charge:resolved"
        order.update!(status: 'completed')
        # Here you would trigger an email or grant access to the product
      when "charge:failed"
        order.update!(status: 'failed')
      end
    end

    # 3. Always return a 200 OK so the gateway knows we got the message
    head :ok
  end
end

Don't forget to add the route for this webhook:

# config/routes.rb
namespace :webhooks do
  post 'crypto', to: 'crypto#create'
end

Summary

That's pretty much it! Integrating cryptocurrency payments into Rails is no different than integrating Stripe or PayPal.

You create an order in your database.
You ask the API for a checkout URL.
You redirect the user.
You wait for the Webhook to tell you the payment was successful.

By using a hosted gateway, you completely avoid the legal and technical nightmares of holding private keys or managing blockchain nodes. You just write clean Ruby code and let the provider handle the heavy lifting.

The Ultimate Guide to Universal Linux Apps: Snap, Flatpak, and AppImage

Zil Norvilis — Mon, 06 Apr 2026 23:11:51 +0000

Very often I find myself remembering the "bad old days" of Linux. If you wanted to install a simple app, you had to add a random PPA repository, run apt-get update, and pray that it didn't break your system dependencies. If you used Arch Linux instead of Ubuntu, you had to hope someone made an AUR package for it.

Today, the Linux desktop is much better. We have "Universal Package Managers". They bundle the app and all its dependencies into one single package that runs on any Linux distribution.

But now we have a new problem. There are three competing standards: Snap, Flatpak, and AppImage.

I have used all of them extensively over the years. Here is my honest breakdown of how they work, the pros and cons of each, and which one you should actually use.

1. AppImage (The Portable USB Drive)

AppImage is the simplest of the three. It is the closest thing Linux has to a Windows .exe file or a macOS .dmg file.

How it works:
You don't actually "install" an AppImage. You just go to a website, download a single file, make it executable, and double-click it.

# Download the file
wget https://example.com/cool-app.AppImage

# Make it executable
chmod +x cool-app.AppImage

# Run it
./cool-app.AppImage

The Good:

You don't need root (sudo) privileges to run it.
You can put it on a USB drive and run it on any Linux computer instantly.
It leaves your system completely clean. If you want to delete the app, you just delete the file.

The Bad:

There is no central "App Store" to update them. If a new version comes out, you have to go to the website and download the new file manually.
It doesn't automatically add a shortcut to your desktop menu (unless you install a third-party tool like AppImageLauncher).

2. Snap (The Corporate Monolith)

Snap was created by Canonical (the company behind Ubuntu). It was designed to solve package management for both servers and desktop computers.

How it works:
You install it via the terminal, similar to standard package managers.

sudo snap install spotify

The Good:

It handles background services and CLI tools very well. If you need to install a database or a server utility, Snap is actually pretty great.
Auto-updates are forced in the background, so you are always on the latest version.

The Bad:

Proprietary Backend: The client is open source, but the server that hosts the Snaps is closed source and controlled 100% by Canonical. The Linux community generally hates this.
Clutter: Snaps mount themselves as virtual hard drives. If you type lsblk in your terminal, you will see a massive, ugly list of "loop devices" clogging up your screen.
Performance: Historically, Snaps have been very slow to start up. They have improved recently, but they still feel heavier than the alternatives.

3. Flatpak (The Community Winner)

Flatpak was developed with backing from Red Hat. Unlike Snap, it was built specifically and exclusively for Desktop GUI applications.

How it works:
You add the Flathub repository, and then you can install apps either through your graphical software center or the terminal.

# Install an app
flatpak install flathub com.spotify.Client

# Run the app
flatpak run com.spotify.Client

The Good:

Decentralized: Flathub is the main store, but anyone can host their own Flatpak repository. It is truly open source.
Sandboxing: This is the killer feature. Flatpak isolates apps from your main system. An app cannot read your personal files or access your webcam unless you give it permission.
Flatseal: There is a fantastic GUI app called Flatseal that lets you toggle permissions (like Network, Filesystem, Microphone) for every Flatpak app with simple switches.

The Bad:

Because apps are sandboxed, sometimes they struggle to integrate with system themes or custom cursors.
File sizes can be large at first, because it has to download shared "runtimes" (like the GNOME or KDE base files). However, once you have the runtimes, future apps install very fast.

Summary: Which one should you use?

If you are setting up a Linux workstation for development or daily use, here is the golden rule I follow:

Use Flatpak as your default. If a GUI app like Discord, Spotify, or VSCode is available on Flathub, use the Flatpak version. It is secure, updates easily, and respects your system.
Use AppImage for quick tests. If I just need to use a tool once (like a crypto wallet or a specialized video editor) and don't want to install it permanently, I grab the AppImage.
Avoid Snap unless absolutely necessary. Unless I am setting up an Ubuntu server and need a specific CLI tool that is only packaged as a Snap, I remove snapd from my system entirely.

That's pretty much it. The universal package war was messy for a few years, but in 2026, the community has spoken, and Flatpak is the clear winner for the Linux desktop.

Why Ruby on Rails is the Secret Weapon for AI Startups

Zil Norvilis — Sun, 05 Apr 2026 23:11:49 +0000

Everyone knows that Python is the king of training AI models. But if you want to actually build a web app that uses AI (like an AI copywriter, a smart chatbot, or a document analyzer), you don't need Python. You need a web framework.

Very often I see developers jumping into complex JavaScript setups (like Next.js + a separate backend) just to build a simple AI wrapper. They spend a week just gluing the database, the API, and the frontend together.

In 2026, building AI apps is all about speed. And surprisingly, the best tool for the AI era is one of the oldest: Ruby on Rails.

Here is why Rails is the absolute best framework for building AI products today.

REASON 1: AI Loves Conventions

If you use AI tools like Cursor, GitHub Copilot, or ChatGPT to write code, you know they can sometimes get confused. If your project has a custom folder structure and weird configuration files, the AI will hallucinate and put code in the wrong place.

Rails is built on Convention over Configuration.
Every Rails app looks exactly the same. Models go in app/models, controllers go in app/controllers, and database changes happen in db/migrate.

Because Rails is so standardized and has been around for 20 years, AI models are incredibly good at writing Rails code. If you tell an AI, "Create a User model that has many Documents", it knows exactly what to do. It generates the perfect migration, the perfect model associations, and the perfect routes without you having to explain your folder structure.

REASON 2: AI Calls are Slow (Solid Queue)

When you make a request to OpenAI or Anthropic, it takes time. Sometimes it takes 2 seconds, sometimes it takes 15 seconds.

If you put that API call directly inside your web controller, your app will freeze. The user will sit there staring at a loading spinner, and the browser might even timeout. You must use background jobs for AI.

In other frameworks, setting up background workers is a headache. You have to install Redis, configure workers, and manage separate processes.

In Rails 8, background jobs are built-in by default using Solid Queue.

# app/jobs/generate_summary_job.rb
class GenerateSummaryJob < ApplicationJob
  queue_as :default

  def perform(document_id)
    document = Document.find(document_id)

    # Call the slow AI API
    response = OpenAiClient.generate_summary(document.text)

    document.update(summary: response)
  end
end

You just call GenerateSummaryJob.perform_later(@document.id) in your controller, and Rails handles the rest perfectly.

REASON 3: Real-Time Streaming (Hotwire)

When using AI, users expect to see the text typing out on the screen chunk by chunk, just like ChatGPT.

To do this in React or Vue, you usually have to set up WebSockets, manage complex frontend state, and write a lot of boilerplate code to append text to a div.

With Rails and Hotwire (Turbo Streams + ActionCable), this is ridiculously easy. You don't need to write any custom JavaScript.

When your background job gets a chunk of text from the AI, you just broadcast it directly to the HTML:

# Inside your job or service
Turbo::StreamsChannel.broadcast_append_to(
  "document_#{@document.id}", 
  target: "ai_output", 
  html: "<p>#{ai_text_chunk}</p>"
)

The browser automatically receives the HTML and updates the page instantly. It feels like magic, and it saves you hours of frontend work.

REASON 4: The Database is Everything

Most AI apps today use RAG (Retrieval-Augmented Generation). This means you take user data from your database, mix it with a prompt, and send it to the AI.

To do this well, your database interactions need to be flawless. ActiveRecord is still the most powerful and easiest-to-use ORM in the world.
Need to grab a user's last 5 completed projects and pass their titles to the AI?

prompt_data = @user.projects.completed.last(5).pluck(:title).join(", ")

It is one line of plain English. Trying to write that in raw SQL or a clunky JavaScript ORM takes way more mental energy.

Also, with the neighbor gem, you can even store and query AI vector embeddings directly inside your standard PostgreSQL database using ActiveRecord.

Summary

The AI era is not about inventing new web technologies. It is about taking an AI API and wrapping it in a solid, reliable product.

As a solo developer, you want to focus 100% of your time on the AI prompt logic and the user experience. Rails gives you the database, the background jobs, the real-time UI, and the structure out of the box.

That's pretty much it. While everyone else is fighting with Webpack and API endpoints, you can use Rails to launch your AI startup in a weekend.

Stop Using RVM: The Ultimate Guide to Ruby Version Managers

Zil Norvilis — Sat, 04 Apr 2026 23:11:50 +0000

rbenv vs rvm vs asdf vs mise vs chruby vs direnv

Very often I see beginners getting completely stuck trying to install Ruby on their Mac or Linux machine. You read one tutorial, and it tells you to install RVM. You read another, and it tells you to use rbenv. Then someone on Twitter tells you to use asdf.

It is very confusing. Why do we even need these tools?

Because different Rails projects require different Ruby versions. If you try to run a legacy Rails 6 app on Ruby 3.3, it will crash. You need a tool to quickly switch between Ruby versions depending on which project folder you are in.

Here is my honest breakdown of all the popular version managers, how they work, and which one you should actually use today.

1. RVM (The Dinosaur)

RVM (Ruby Version Manager) is the oldest tool on this list.

How it works: It overrides your terminal commands (like cd) to switch Ruby versions automatically. It also has a feature called "gemsets" to keep your gems separated.
The Verdict: Do not use this.
In the past, RVM was amazing. But today, Bundler handles gem isolation for us, so "gemsets" are useless. RVM is too heavy, messes with your shell too much, and is generally considered outdated.

2. rbenv (The Reliable Standard)

This is probably the most popular choice in the Ruby community right now.

How it works: It uses "shims". A shim is a fake executable. When you type ruby -v, rbenv catches that command, checks if you have a .ruby-version file in your current folder, and then passes the command to the correct physical Ruby installation.

# .ruby-version
3.3.0

The Verdict: Highly Recommended.
It is lightweight, does exactly one thing, and stays out of your way. If you only write Ruby code, this is a perfectly safe choice.

3. chruby (The Minimalist)

If you hate "magic" and fake executables, chruby is for you.

How it works: It does not use shims. When you switch Ruby versions, it simply modifies your computer's $PATH variable to point directly to the correct Ruby folder.

# Terminal command to switch versions
chruby ruby-3.3.0

The Verdict: Great, but manual.
It is incredibly fast and clean. The only downside is that it doesn't automatically switch versions when you enter a directory unless you install a secondary tool (like auto.sh or direnv).

4. asdf (The All-In-One)

Eventually, you will realize you don't just need to manage Ruby. You also need to manage Node.js versions, Python versions, and maybe Postgres versions.

How it works: asdf uses a plugin system. You install the tool once, and then add plugins for whatever languages you need. It uses a file called .tool-versions instead of .ruby-version.

# .tool-versions
ruby 3.3.0
nodejs 20.0.0

The Verdict: Good, but getting slow.
It is extremely useful to have one tool for all languages. However, asdf is written in Bash, and when you have many plugins, it can actually make your terminal commands noticeably slower.

5. mise (The New King)

Previously known as rtx, this is taking over the developer world right now.

How it works: mise is basically a clone of asdf, but it is written in Rust. This makes it blazing fast. It doesn't use shims like rbenv or asdf, it modifies your $PATH like chruby.

The best part? It is backwards compatible. It automatically reads your old .ruby-version, .nvmrc, and .tool-versions files and just works.

# Installing ruby with mise
mise install ruby@3.3.0
mise use ruby@3.3.0

The Verdict: The Best Choice Today.
If you are setting up a new computer, install mise. It manages all your languages, it is incredibly fast, and you don't have to deal with slow terminal boot times.

6. direnv (The Sidekick)

I added this to the list because people often get confused by it. direnv is not a Ruby version manager.

How it works: It is an environment variable manager. You put a .envrc file in your project folder, and when you cd into that folder, direnv automatically loads those variables into your terminal (like API keys or Database URLs).

# .envrc
export STRIPE_KEY="sk_test_123"

People often pair direnv with chruby or rbenv to trigger the Ruby version switch automatically. But if you use mise, you don't really need direnv anymore, because mise manages environment variables too!

Summary: What should you pick?

If you want the industry standard and only care about Ruby: Use rbenv.
If you want to manage Ruby, Node, and Postgres and want the fastest tool available: Use mise.
If you have RVM installed: Uninstall it and pick one of the two above.

That's pretty much it. Setting up your environment is annoying, but once you pick a modern tool like mise or rbenv, you never have to think about it again.

Forem: Zil Norvilis

It Looks Like Ruby, But It’s Not: How to Understand Elixir

1. Classes vs Modules

2. Method Chaining vs The Pipe Operator

3. Hashes vs Maps

4. The Equals Sign is a Lie (Pattern Matching)

Summary

Pundit vs CanCanCan vs Action Policy: Which Rails Auth Gem Wins?

1. CanCanCan (The Legacy Giant)

2. Pundit (The Object-Oriented Standard)

3. Action Policy (The Modern Speed Demon)

Summary: Which one should you pick?

Wise Testing: What to Test (and Ignore) as a Solo Rails Developer

RULE 1: What NOT to Test (The Time Wasters)

RULE 2: The "Golden Path" System Tests (High ROI)

RULE 3: Surgical Unit Tests (The Money and the Math)

RULE 4: Embrace Rails Fixtures (Skip FactoryBot)

Summary: The Wise Testing Checklist

Stop AI Spaghetti: Enforcing Rails Architecture in 2026

STEP 1: The Context File (.cursorrules)

STEP 2: Ruthless Linting with RuboCop

STEP 3: Enforcing Boundaries (Packwerk)

STEP 4: System Tests over Unit Tests

Summary

How to Fix N+1 Queries in Rails Like a Pro

The Problem: What is N+1?

LEVEL 1: The Basic Fix (includes)

LEVEL 2: Nested Includes (Going Deeper)

LEVEL 3: includes vs preload vs eager_load (The Pro Stuff)

LEVEL 4: Strict Loading (The Ultimate Safety Net)

Summary

Building a World-Class Search Engine in Rails with Searchkick

Stop Using SQL LIKE: A Step-by-Step Guide to Elasticsearch in Rails

STEP 1: The Setup

STEP 2: Tell Your Model to Listen

STEP 3: Index Your Existing Data

STEP 4: The Search Query

STEP 5: Customizing the Index (The Pro Move)

Summary

The Easiest Way to Add Drag and Drop to Your Rails App

Building Drag and Drop in Rails 8 with SortableJS and Importmaps

STEP 1: The Database Setup

STEP 2: Pin SortableJS (Importmap)

STEP 3: The HTML View

STEP 4: The Stimulus Controller

STEP 5: The Rails Controller & Route

Summary

AdonisJS vs Ruby on Rails: Which MVC Framework Wins?

1. The Language: Ruby vs TypeScript

2. The ORM: ActiveRecord vs Lucid

3. The Frontend Setup

4. The Ecosystem and "The Rails Way"

Summary: Which one should you use?

How to Accept Crypto Payments in Your Rails 8 App

STEP 1: The Database Setup

STEP 2: Creating the Charge (The API Call)

STEP 3: The View

STEP 4: The Webhook (The Magic)

Summary

The Ultimate Guide to Universal Linux Apps: Snap, Flatpak, and AppImage

1. AppImage (The Portable USB Drive)

2. Snap (The Corporate Monolith)

3. Flatpak (The Community Winner)

Summary: Which one should you use?

Why Ruby on Rails is the Secret Weapon for AI Startups

REASON 1: AI Loves Conventions

REASON 2: AI Calls are Slow (Solid Queue)

REASON 3: Real-Time Streaming (Hotwire)

REASON 4: The Database is Everything

Summary

Stop Using RVM: The Ultimate Guide to Ruby Version Managers

rbenv vs rvm vs asdf vs mise vs chruby vs direnv

1. RVM (The Dinosaur)

2. rbenv (The Reliable Standard)

3. chruby (The Minimalist)

4. asdf (The All-In-One)

5. mise (The New King)

6. direnv (The Sidekick)

Summary: What should you pick?

STEP 1: The Context File (`.cursorrules`)

LEVEL 1: The Basic Fix (`includes`)