DEV Community: Zil Norvilis

MVT vs MVC: Understanding Django Through a Rails Lens

Zil Norvilis — Fri, 05 Jun 2026 18:14:39 +0000

If you are a Rails developer, you are used to the "Omakase" experience. Everything is chosen for you, and there is a very specific "Rails Way" to do things.

But sometimes, a project requires Python - maybe because of a specific AI library or a client’s existing infrastructure. When you first open a Django project, it feels like walking into a house where all the furniture is in the wrong room. The concepts are the same, but the names are all different.

Django is essentially the Python cousin of Rails. It values batteries-included development and clean architecture. Here is the translation guide to help you move between Ruby and Python without losing your mind.

1. The Pattern: MVT vs. MVC

Rails follows MVC (Model-View-Controller).
Django follows MVT (Model-View-Template).

This is the biggest point of confusion for Rails devs. In Django:

The Model is exactly the same as Rails.
The View is actually the Controller. It’s where the logic lives.
The Template is the View. It’s the HTML/ERB equivalent.

Rails Concept	Django Equivalent
Model	Model
Controller	View
View (ERB)	Template

2. The CLI: `manage.py` is your `bin/rails`

In Rails, you use the rails command for everything. In Django, every project comes with a script called manage.py that handles the same tasks.

Start the server:
- Rails: bin/rails s
- Django: python manage.py runserver
Database Console:
- Rails: bin/rails dbconsole
- Django: python manage.py dbshell
The Interactive REPL:
- Rails: bin/rails c
- Django: python manage.py shell

3. The ORM: Django ORM vs. ActiveRecord

ActiveRecord is famous for its "magic." You don't have to import models; they are just there. Django is more explicit. You have to import your models at the top of every file.

Querying:

# Rails
@users = User.where(active: true).order(:created_at)

# Django
from .models import User
users = User.objects.filter(active=True).order_by('created_at')

Migrations:
Rails migrations are timestamped files where you write the change. Django does this in two steps:

python manage.py makemigrations: Django looks at your models.py, compares it to the last version, and automatically generates the migration file for you.
python manage.py migrate: This actually runs the changes on the database.

4. Routing: `urls.py` vs. `routes.rb`

Rails uses a DSL for routing. Django uses a list of path objects and regex-like patterns.

# Rails routes.rb
get '/products/:id', to: 'products#show'

# Django urls.py
from django.urls import path
from . import views

urlpatterns = [
    path('products/<int:id>/', views.product_detail),
]

5. The "Superpower": Django Admin

In Rails, we usually install a gem like Avo or ActiveAdmin to get an internal dashboard. In Django, this is built-in.

By adding two lines of code to admin.py, you get a professional, secure CRUD interface for your models. This is the single biggest reason Rails developers often feel "Admin Envy" when looking at Python projects.

6. Dependency Management

Instead of a Gemfile and Gemfile.lock, Django developers traditionally used a requirements.txt file. However, modern Python development has moved to Poetry or uv, which uses a pyproject.toml file—this feels much more like the Bundler experience you are used to.

Summary

If you can write a Rails app, you can write a Django app. You just have to remember that Django Views = Rails Controllers.

The transition is mostly about getting used to Python’s explicit nature. While Rails loves to hide things to make code look "pretty," Django prefers that you see exactly where everything is coming from.

💡 Don't forget to test!
Whether you are building in Ruby or Python, the most important thing is a reliable test suite. If you want to see how I handle testing for solo projects to ensure they actually work in production, check out Wise Testing: The Solo Developer's Guide to Rails Testing. It’s the pragmatic approach to shipping fast.

The $5 VPS Reality: My Honest Math on Moving to Kamal 2

Zil Norvilis — Thu, 04 Jun 2026 18:14:39 +0000

I remember the day I got my first $200 bill from a PaaS provider (Platform as a Service).

I only had a few side projects running. None of them were making much money, but because I needed a "Standard" database for one and an extra "Worker" for another, the costs just started stacking up. I felt like I was paying a "Laziness Tax" just to avoid managing a server.

In 2026, the trend has reversed. Tools like Kamal 2 and Rails 8 have made it incredibly easy to leave the expensive "managed" clouds and host everything yourself on a cheap VPS.

But is it actually cheaper? Most people only look at the monthly bill, but they forget about the "Time Tax." Here is my honest breakdown of the true cost of running your own cloud empire.

1. The Financial Math (The "Win")

Let’s look at a typical Rails setup for a small SaaS.

The Heroku/Render Way:

Web Service (2GB RAM): $25
Postgres Database (Managed): $30
Redis (for Sidekiq): $15
Total: $70/month

The Self-Hosted Way (Hetzner/DigitalOcean):

One VPS (ARM, 8GB RAM, 4 vCPUs): $10
Backups (S3/R2): $1
Total: $11/month

Savings: $59 per month / $708 per year.
If you have 5 different apps, you are saving over $3,500 a year. For a solo developer living in Europe, that is a huge amount of money that can be spent on marketing or better coffee.

2. The Maintenance Tax (The "Hidden Cost")

This is where the PaaS providers justify their high prices. When you self-host, you are the CEO, the Developer, and now the System Administrator.

Security: You are responsible for OS updates. If a new Linux vulnerability comes out, you have to run apt-get upgrade.
Backups: On Heroku, you click a button. On a VPS, you have to ensure your database is being streamed to S3 (using Litestream or a cron job). If your script fails and the server dies, your business is gone.
Monitoring: If your server runs out of disk space at 3:00 AM, there is no support team to fix it. You need to set up your own alerts (like UptimeRobot or health checks).

True Cost: About 1–2 hours of "Server Maintenance" per month.

3. The "One-Person" Secret: Docker & Kamal 2

The reason self-hosting is viable in 2026 is because we stopped managing servers manually.

In the old days, you had to install Ruby, Nginx, and Postgres on the server. It was a nightmare. Today, we use Docker. Your server is just a "dumb" box that runs containers.

With Kamal 2, deploying to a $5 VPS feels exactly like deploying to Heroku. You type kamal deploy, and it handles the SSL, the zero-downtime switch, and the health checks.

The "Learning Tax" to master Kamal takes about a weekend. Once you pay that tax, you never have to pay the "PaaS Tax" again.

4. The Stability Myth

People fear that a cheap VPS is less stable than AWS or Heroku.

The truth? Modern VPS providers like Hetzner or Akamai have 99.9% uptime. Most "crashes" in a Rails app aren't caused by the hardware; they are caused by bad code (N+1 queries, memory leaks, or unhandled exceptions).

Whether you pay $7 or $700, a bug in your Ruby code will still crash the app.

Summary: Should You Switch?

If you are a solo developer, here is my recommendation:

Stay on a PaaS (Render/Fly.io) if you are in the first 48 hours of an idea. Don't waste time on infrastructure until you know the idea is worth it.
Switch to Self-Hosting (Kamal + VPS) the moment your app starts making even $10 a month.

The $50+ you save every month covers your AI subscription (Cursor/ChatGPT), your domain names, and your email marketing tools.

Building your own "Cloud Empire" isn't just about saving money; it’s about Ownership. When you own the server, you have total control. And in the world of indie hacking, control is freedom.

From Coder to Architect: How to Learn Rails When AI Writes the Code

Zil Norvilis — Wed, 03 Jun 2026 18:14:28 +0000

I recently realized that the way I learned Ruby on Rails ten years ago is now completely obsolete.

Back then, I spent hundreds of hours watching tutorials like Railscasts or reading books to memorize syntax. I had to learn exactly how to write a has_many :through association or how to structure a nested form. I was a Writer. My value was my ability to produce correct code.

In 2026, syntax is a commodity. With tools like Cursor and GitHub Copilot, the AI is the writer. I can prompt: "Add a tagging system to my posts with a many-to-many relationship," and the code is written in seconds.

But here is the problem: AI is a great writer, but a terrible architect.

If you don't know where the code should go, the AI will dump it in the easiest place, usually making your controllers and models huge and messy. To survive in this "Post-Tutorial Era," you need to stop focusing on syntax and start focusing on Architecture.

Here is how to learn the "Rails Way" when you aren't the one typing the code.

1. Move from "How" to "Where"

When you follow an old-school tutorial, it teaches you how to write a method. In 2026, you should be asking where that method belongs.

If the AI suggests putting logic that talks to the Stripe API inside your User model, you need to be able to say: "No, that belongs in a Service Object in app/services."

How to learn this: Study the Rails Sidecar pattern. Look at how modern apps use:

Service Objects: For third-party API logic.
ViewComponents: For complex UI logic.
Jobs: For anything that takes more than 100ms.

2. Audit the AI (The "Why" Test)

Don't just hit "Tab" to accept AI suggestions. Every time the AI generates a block of code, perform a manual audit. Ask yourself: "Why did it use a callback instead of a background job?"

If you don't know the answer, ask the AI to explain the trade-offs:

"Why is an after_create callback dangerous here compared to a background job?"

This is how you learn architecture today. You treat the AI as a junior developer and yourself as the Editor-in-Chief. By forcing the AI to justify its architectural choices, you learn the underlying principles of the framework.

3. Learn "Omakase" Constraints

Rails is an "Omakase" framework (the chef chooses the ingredients). It is built on Convention over Configuration.

The reason AI is so good at writing Rails code is because Rails has very strict conventions. If you try to be "clever" and invent your own folder structure or naming patterns, the AI will get confused and start hallucinating.

The Strategy: Lean into the defaults. The more you follow the standard Rails 8 patterns (Solid Queue, Hotwire, etc.), the more the AI becomes a superpower. Architecture in 2026 is about keeping the "wiring" of your app so standard that the AI can perfectly navigate it.

4. Read the Rails Source Code

Since you aren't spending time memorizing syntax anymore, use that extra brainpower to read the actual rails/rails source code on GitHub.

If you understand how ActiveJob actually works under the hood, you will know exactly how to architect your background tasks. You don't need a tutorial to show you a "To-Do List" app; you need to understand the Core Patterns of the framework.

Summary

The era of the "Tutorial-Driven Developer" is over. If you only know how to follow instructions, an AI can already do your job.

To be a valuable developer in 2026, you must become an Architect.

Stop memorizing syntax. The AI handles that.
Learn patterns. Know when to use a Concern vs. a Service.
Enforce standards. Use .cursorrules or RuboCop to keep the AI on track.
Understand the "Why." Always ask the AI for the trade-offs of its suggestions.

The code is now free. The Taste and Vision of how that code fits together is where the money is.

Stop Using JS for Everything: Harnessing the Power of Pure CSS in 2026

Zil Norvilis — Tue, 02 Jun 2026 18:14:28 +0000

I remember when building a simple dropdown menu or a sticky header required a library like jQuery. Later, we moved to writing Stimulus controllers or React hooks for every single tiny interaction on the screen.

As a developer, my instinct was always: "If it moves, write JavaScript."

But in 2026, the browser has changed. CSS has evolved so much that many of the things we used to do in JS are now built natively into the stylesheet. Moving this logic to CSS isn't just about being "cool" - it makes your site significantly faster, reduces "layout shift," and means you have less code to maintain.

Here is how I’ve started replacing JavaScript with pure CSS in my Rails 8 projects.

1. The "Parent" Selector (`:has`)

For decades, we wanted a way to style an element based on what was inside it.

The Old Way (JS):
You would write a script to check if a checkbox was ticked, then add a class like .is-active to the parent container.

The 2026 Way (CSS):
We now have the :has() selector. It is a game-changer.

/* Style the card only if it contains a checked checkbox */
.card:has(input[type="checkbox"]:checked) {
  background-color: #f0fdf4;
  border-color: #22c55e;
}

This replaces hundreds of lines of "state-toggling" JavaScript. You can use it for form validation, menu states, and complex grid layouts.

2. Native Popovers (The `popover` Attribute)

Tooltips and dropdowns are usually the first things people use JavaScript for. In 2026, we don't need a JS library for this anymore.

The Modern Way:
You use the HTML popover attribute and target it with CSS.

<button popovertarget="my-menu">Open Menu</button>

<div id="my-menu" popover class="p-4 rounded-lg shadow-xl">
  <p>This is a pure CSS/HTML dropdown!</p>
</div>

With zero lines of JavaScript, the browser automatically handles:

Showing/hiding the element.
"Light dismiss" (closing when you click outside).
Putting the menu on the "top layer" so it isn't cut off by parent containers.

3. Container Queries (No more JS Resize Listeners)

We used to use JavaScript ResizeObserver to change a component's layout if its container got too small (like a sidebar moving to the bottom).

The 2026 Way:
Container queries allow an element to style itself based on its own size, not the size of the whole browser window.

.card-container {
  container-type: inline-size;
}

@container (max-width: 400px) {
  .card {
    flex-direction: column;
    padding: 1rem;
  }
}

This is perfect for Rails developers using ViewComponents. Your component can now be "smart" and responsive no matter where you drop it in your layout.

4. Scroll-Driven Animations

I used to hate writing JS scroll listeners. They are terrible for performance and often feel "janky" on mobile phones.

In 2026, we can link animations directly to the scroll position using pure CSS. Want a progress bar at the top of your blog post?

@keyframes grow-progress {
  from { transform: scaleX(0); }
  to { transform: scaleX(1); }
}

.progress-bar {
  animation: grow-progress auto linear;
  animation-timeline: scroll();
}

The browser handles the math. It is buttery smooth and consumes zero CPU cycles compared to a JS scroll event.

5. Native Smooth Scrolling and Snap

If you are building a landing page with a carousel or a "back to top" button, you might be tempted to use a JS library.

Don't.

html {
  scroll-behavior: smooth;
}

.carousel {
  display: flex;
  overflow-x: auto;
  scroll-snap-type: x mandatory;
}

.carousel-item {
  scroll-snap-align: center;
}

This gives you that premium, "app-like" sliding feel natively.

Summary: Why this matters for Rails 8

When we use Hotwire and Turbo, we want to keep the "State" on the server as much as possible. Every time we add a custom Stimulus controller for a tiny UI animation, we are adding "Client-side State" that we have to manage.

By using these 2026 CSS features:

Your HTML is cleaner.
Your JavaScript bundle is smaller.
Your UX is more resilient (CSS doesn't "crash" like JS does).

Next time you are about to run rails generate stimulus, ask yourself: "Can I do this with :has() or a container query instead?" Most of the time, the answer is now yes.

The Developer's Way to Track Traffic: Self-Hosting Ackee or Plausible

Zil Norvilis — Mon, 01 Jun 2026 18:14:41 +0000

I recently took a long look at my Rails projects and realized I was carrying around a piece of technical debt that was actually hurting my user experience: Google Analytics (GA4).

As a developer living in the EU (Lithuania), using Google Analytics is a headache. Between the complex GDPR compliance rules, the legal uncertainty of sending data to US servers, and that massive, ugly cookie banner I was forced to show every visitor, it just didn't feel "clean" anymore.

Plus, let’s be honest: GA4 is bloated. I don't need 500 different reports to tell me how many people visited my pricing page today. I just want to see my traffic, my referrers, and my conversion rate without selling my users' souls to an advertising giant.

In 2026, the best move for a solo developer is to self-host your own privacy-first analytics. Here is how I moved to Ackee and Plausible, and why you should too.

1. Why Self-Host?

When you self-host your analytics, you own the data. It lives on your server, in your database.

No Cookie Banners: Tools like Plausible and Ackee don't use cookies and don't track personal data. Under GDPR, this means you can often remove those annoying "Accept Cookies" popups entirely.
Performance: The Google Analytics script is heavy. Self-hosted alternatives are usually tiny (under 1KB), which helps your site load faster and score higher on Google Lighthouse.
Ad-Blocker Friendly: Because you are serving the script from your own subdomain (like stats.yourdomain.com), many ad-blockers won't catch it, giving you more accurate data than Google.

2. The Contenders: Ackee vs. Plausible

There are two main players I recommend for the Rails community.

Ackee (The Minimalist)

Ackee is built on Node.js and is incredibly beautiful. It is perfect if you just want the "vibe" of your traffic. It shows you views, referrers, and duration in a very clean, dark interface.

Pros: Very lightweight, easy to run in a Docker container.
Cons: Doesn't track "Goals" (like button clicks) as easily as Plausible.

Plausible (The Professional)

Plausible is the gold standard for privacy-first analytics. It is written in Elixir and is incredibly fast.

Pros: Supports goal tracking, custom events, and even integrates with Google Search Console so you can see your keywords.
Cons: A bit more complex to self-host because it requires a ClickHouse database for the stats.

3. Deployment with Kamal 2

If you followed my previous articles, you know I use Kamal 2 to build my "Cloud Empire" on cheap VPS servers. Deploying a self-hosted analytics tool is just another Docker container in your cluster.

Here is a simplified deploy.yml example for running Ackee on a subdomain:

service: my-stats
image: electerious/ackee

servers:
  web:
    - 123.45.67.89 # Your VPS IP

proxy:
  ssl: true
  host: stats.zil.com

env:
  secret:
    - ACKEE_PASSWORD
  clear:
    ACKEE_MONGODB: mongodb://db_user:pass@your-db-ip:27017/ackee

Once deployed, you get a small JavaScript snippet to paste into your Rails layout.

4. Integrating with Rails

You don't need a heavy gem for this. Just put the script in your <head>.

<!-- app/views/layouts/application.html.erb -->
<% if Rails.env.production? %>
  <script 
    async 
    src="https://stats.zil.com/tracker.js" 
    data-ackee-server="https://stats.zil.com" 
    data-ackee-domain-id="your-uuid-here">
  </script>
<% end %>

If you want to track custom events (like when someone clicks "Subscribe"), you can trigger it from a Stimulus controller:

// app/javascript/controllers/analytics_controller.js
import { Controller } from "@hotwired/stimulus"

export default class extends Controller {
  trackClick() {
    // Ackee custom action
    ackeeTracker.action('button_clicked', { key: 'Join', value: 1 })
  }
}

Summary

Moving away from Google Analytics was one of the best decisions I made for my side projects.

My sites load faster.
My users' privacy is respected.
I don't have to deal with complex GDPR legal paperwork.
My dashboard is actually fun to look at again.

If you are a solo developer, stop giving your data away for free. Rent a $5 VPS, spin up a Docker container, and take control of your own metrics.

Count, Length, or Size? Avoiding ActiveRecord Performance Traps

Zil Norvilis — Sun, 31 May 2026 18:15:47 +0000

I remember when I first started with Rails, I thought .count, .length, and .size were exactly the same thing. I used them interchangeably in my views and controllers. If I wanted to know how many users were in the database, I would just pick one and move on.

But then, as my app grew and I started checking my server logs, I realized I was making a huge performance mistake. While these three methods look identical, they behave completely differently under the hood. One of them hits your database every single time, one of them might crash your server’s memory, and one of them is "smart" enough to choose the best path.

Here is the breakdown of when to use which so you can keep your Rails app fast.

1. `.count` (The Database Hitter)

When you call .count, ActiveRecord ignores any records you might already have loaded in memory. It goes straight to the database and runs a specific SQL query: SELECT COUNT(*) FROM users.

users = User.where(active: true)
users.count # SQL: SELECT COUNT(*) FROM users WHERE active = true

When to use it: Use this when you only need the number and you have no intention of using the actual data.
The Trap: If you call .count and then immediately loop through the records with .each, you are doing double work. You hit the DB for the count, and then you hit it again to get the users.

2. `.length` (The Memory Loader)

Calling .length is the equivalent of saying: "Give me everything."

ActiveRecord will fetch every single column for every single record in that query and load them all into your computer's RAM. Only after everything is loaded does it count how many items are in the array.

users = User.where(active: true)
users.length # SQL: SELECT * FROM users WHERE active = true
# Every user object is now sitting in your RAM.

When to use it: Use this only if you have already loaded the records (for example, if you already called @users.to_a).
The Trap: If you have 100,000 users and you just want to show a number in the navbar, calling .length will try to load all 100,000 users at once. This is the fastest way to get an "Out of Memory" error and crash your production server.

3. `.size` (The "Smart" Manager)

This is the method I recommend for 90% of use cases. It is the "omakase" choice because it adapts to the situation.

If the records are already loaded in memory, it acts like .length (it just counts the items in the array without touching the database).
If the records are not loaded, it acts like .count (it runs the efficient SELECT COUNT(*) query).

users = User.where(active: true)

# Records aren't loaded yet, so it runs a COUNT query
users.size 

# Later in the view...
users.each { |u| ... } # Data is loaded here

# Records are now loaded, so .size doesn't hit the DB again!
users.size

When to use it: This should be your default choice. It protects you from making mistakes in your views and ensures you aren't hammering the database with redundant queries.

Summary: The Decision Matrix

Method	Behavior	Best for...
`.count`	Always runs `SELECT COUNT(*)`	One-off checks when you don't need the data.
`.length`	Always runs `SELECT *`	When data is already loaded in an array.
`.size`	Smart: Choice depends on state	Almost everything. It’s the safest default.

As a solo developer, you want to spend your time building features, not debugging slow database queries. Switching your habit from .count to .size is a 1-second change that can save you a lot of headache in the future.

From ERB to Phlex: 5 Steps to Pure Ruby Views

Zil Norvilis — Sat, 30 May 2026 18:15:47 +0000

I love Rails, but I’ve always found ERB to be a bit messy. You spend your whole day jumping between the "Backend" (clean Ruby code) and the "Frontend" (a mixture of HTML and weird <% %> tags).

It is annoying to manage indentation, and if you make a typo inside an ERB tag, you usually don't find out until the page crashes in the browser.

In 2026, many solo developers are moving to Phlex. Phlex is a view framework that lets you write your HTML in Pure Ruby. It is 10x faster than ERB and allows you to use standard Ruby tools (like Mixins and inheritance) to build your UI.

If you want to try it out, here is how to move from ERB to Phlex in 5 easy steps.

STEP 1: Installation

First, add the gem to your project:

bundle add phlex-rails

Then, run the generator to create the basic folder structure:

bin/rails g phlex:install

This creates an app/views/layouts/application_view.rb file which acts as the base for all your new views.

STEP 2: The Mental Model (Syntax Translation)

Before we convert a file, you need to understand the translation. In Phlex, every HTML tag is just a Ruby method.

ERB: <h1>Hello</h1>
Phlex: h1 { "Hello" }
ERB: <div class="container">...</div>
Phlex: div(class: "container") { ... }

You don't need to worry about closing tags or escaping HTML. Ruby handles it all automatically.

STEP 3: Converting a Simple Template

Let's take a standard "Show" page and convert it.

The Old ERB (app/views/posts/show.html.erb):

<div class="p-8">
  <h1><%= @post.title %></h1>
  <p><%= @post.body %></p>
  <%= link_to "Edit", edit_post_path(@post) %>
</div>

The New Phlex View (app/views/posts/show_view.rb):

class Views::Posts::ShowView < ApplicationView
  def initialize(post:)
    @post = post
  end

  def view_template
    div(class: "p-8") do
      h1 { @post.title }
      p { @post.body }

      # You can still use Rails helpers!
      helpers.link_to "Edit", helpers.edit_post_path(@post)
    end
  end
end

STEP 4: Handling Loops and Logic

The cool thing about Phlex is that loops are just... Ruby loops. You don't need special syntax.

def view_template
  ul do
    @posts.each do |post|
      li { post.title }
    end
  end

  # Standard Ruby IF statement
  if @user.admin?
    button { "Delete Everything" }
  end
end

STEP 5: Rendering from the Controller

Now that your view is a Ruby class, you need to tell your controller to use it. In Rails 8, this is very clean.

# app/controllers/posts_controller.rb
def show
  @post = Post.find(params[:id])

  # Instead of 'render :show', we render the Ruby object
  render Views::Posts::ShowView.new(post: @post)
end

Why is this better?

Speed: Phlex doesn't have to "parse" a text file like ERB does. It just executes Ruby methods. It is incredibly fast.
Organization: You can use Ruby Modules to share pieces of UI. No more messy partials.
Testing: Since your view is a class, you can test it like a normal Ruby object without booting a whole browser.
No Context Switching: You stay in "Ruby Mode" all day. Your brain doesn't have to switch between HTML rules and Ruby rules.

Summary

Moving to Phlex feels a bit strange for the first hour, but once you realize that you have the full power of the Ruby language in your views, you won't want to go back.

Start small. Convert one simple "Settings" page or a "Profile" page. You can run ERB and Phlex side-by-side in the same app without any problems.

UUID v7 vs. ULID: Which Sortable ID Should You Choose?

Zil Norvilis — Fri, 29 May 2026 19:58:40 +0000

For a long time, if you wanted a primary key that was both unique and chronological, you reached for ULID. It was the perfect "indie" solution to the randomness of UUID v4. It gave us fast database inserts and clean, copy-pasteable URLs.

But the world of standards moves fast. In 2024, the IETF officially published RFC 9562, which introduced UUID v7. It does almost exactly what ULID does: it embeds a timestamp into the first part of the ID.

If you are starting a new Rails 8 app today, you might be wondering: "Is ULID still relevant, or should I switch to the 'official' UUID v7?"

I’ve looked at both, and while they serve the same purpose, the choice usually comes down to a battle between Native Performance and Developer Experience (Readability). Here is the breakdown.

The Side-by-Side Look

First, let's look at how they appear in your logs or your browser address bar:

ULID: 01J7Z3P7W9K2Q4R5S6T7V8W9X0 (26 characters, Case-insensitive)
UUID v7: 0191eb5d-79e0-7174-8b01-382a937a4697 (36 characters, Hexadecimal)

Both represent the exact same amount of data (128 bits). Both are "lexicographically sortable," meaning your database can sort them by time without a separate created_at column.

1. The "Native" Win (Why UUID v7 wins on Performance)

This is the biggest argument for UUID v7. Because it is an official standard, database engines like PostgreSQL 17+ and MariaDB are building native support for it.

When you use UUID v7 in Postgres:

Storage: It is stored as a native uuid type (16 bytes).
Indexing: The database knows exactly how to optimize the B-Tree index for this specific format.
Interoperability: Almost every language (Python, Go, Java) now has a native UUID v7 generator in its standard library.

In contrast, ULID is usually stored as a string or text in Postgres. A string takes up more space and is slower to query than a native uuid type.

2. The "Copy-Paste" Win (Why ULID wins on DX)

If you are a solo developer who spends all day looking at your own URLs and database rows, ULID is much nicer to work with.

The Double-Click Rule:
If you try to copy a UUID from a terminal or a text editor, a double-click usually only selects one "chunk" between the dashes. You have to carefully click and drag to copy the whole thing.
With ULID, a double-click selects the entire string every time. It sounds small, but when you do it 100 times a day, it matters.

The Crockford Base32 Alphabet:
ULIDs use a specific set of characters that exclude confusing letters like I, L, O, and U. This makes them much safer to read over the phone or type manually if you ever have to do customer support.

3. Implementation in Rails 8

Rails 8 has made switching to UUIDs (including v7) very easy. You don't even need an external gem anymore if your database supports it.

Step 1: Migration

When creating your table, just specify the type.

create_table :posts, id: :uuid do |t|
  t.string :title
  t.timestamps
end

Step 2: Model Configuration

If your database doesn't generate v7 by default, you can tell Rails to do it using the uuid gem (which now supports v7).

# app/models/post.rb
class Post < ApplicationRecord
  # Rails 8 can handle this via default_random_uuid() in PG 
  # or you can set it manually:
  before_create { self.id ||= UUID7.generate }
end

Summary: Which one should you pick?

Choose UUID v7 if:

You want the highest possible performance in PostgreSQL.
You are building a high-volume app with millions of writes per day.
You want to follow "Official Standards" so your data plays nice with other systems.

Choose ULID if:

You value Readability and Developer Happiness above all else.
Your app is an internal tool or a standard SaaS where the "string vs native uuid" performance gap is too small to notice.
You hate dashes in your URLs.

My Verdict:
I’m a pragmatist. For my core business data (Users, Invoices, Orders), I’ve switched to UUID v7 because I want that native Postgres efficiency. But for things like "Slug" replacements or public-facing tokens, I still use ULID because it just looks better.

Stop Making Ugly Apps: Simple Tailwind Tricks for Backend Developers

Zil Norvilis — Thu, 28 May 2026 18:27:55 +0000

I know the feeling of opening a blank index.html.erb file and having no idea how to make it look "premium." You have the Rails backend working perfectly, but the frontend looks like a website from 2005.

You don't need to be an artist to build a professional-looking SaaS. Professional design is mostly about consistency, spacing, and subtle details.

After building dozens of projects with Tailwind, I’ve found five patterns that work every single time. If you follow these, your app will instantly look like it was built by a real design team.

1. The "Subtle Shell" (The Card Pattern)

The most common mistake is making borders too dark or shadows too heavy. Professional UI is all about being "subtle."

If you need a container for a form or a list, use this combination:

<div class="bg-white border border-slate-200 rounded-xl shadow-sm p-6">
  <!-- Your content here -->
</div>

The Trick:

Use rounded-xl (or 2xl) instead of just rounded. Large radius corners make an app feel modern and "soft."
Use shadow-sm. If the shadow is too big, it looks like a cheap 90s website.

2. Never Use Pure White on Pure White

If your website background is white (bg-white), and your cards are also white, the page looks "flat" and confusing.

The secret to depth is using a very light gray for the page background.

<!-- In your application layout -->
<body class="bg-slate-50 text-slate-900">

  <!-- Inside your view -->
  <div class="bg-white border border-slate-200 ...">
    This card now "pops" off the background.
  </div>

</body>

The Trick: bg-slate-50 is just enough to create a contrast that makes your white cards look clean and intentional.

3. Hierarchy through Color, Not Just Size

When developers want to emphasize text, they usually just make it BOLD or BIG. Designers use color to create hierarchy.

If you have a list of items, don't make everything black. Make the secondary information lighter.

<div>
  <h3 class="text-slate-900 font-semibold">User Name</h3>
  <p class="text-slate-500 text-sm">Joined 2 days ago</p>
</div>

The Trick: By using text-slate-500 for the date, you tell the user’s brain: "Look at the name first, the date is secondary." This makes the interface much easier to read.

4. The "Soft" Action (Secondary Buttons)

Every app has a "Delete" or "Cancel" button. Usually, developers make these bright red or blue. This creates too much "visual noise."

If an action isn't the primary goal of the page, use a "Ghost" or "Soft" button style.

<!-- Primary Action -->
<button class="bg-indigo-600 text-white px-4 py-2 rounded-lg font-medium hover:bg-indigo-700">
  Save Changes
</button>

<!-- Secondary Action -->
<button class="bg-slate-100 text-slate-700 px-4 py-2 rounded-lg font-medium hover:bg-slate-200">
  Cancel
</button>

The Trick: Using a light gray background (bg-slate-100) for secondary actions makes your primary button (the "Money" button) stand out much more.

5. Pro-Level Inputs (The Focus Ring)

The default browser focus (the blue outline when you click an input) looks terrible. Tailwind makes it easy to create a professional focus state that feels like a premium app (like Stripe or Linear).

<input type="email" 
       class="w-full border-slate-300 rounded-lg shadow-sm focus:border-indigo-500 focus:ring-4 focus:ring-indigo-500/10 outline-none transition-all" 
       placeholder="you@example.com">

The Trick:

focus:ring-4: This creates a large, soft outer glow.
focus:ring-indigo-500/10: The /10 makes the ring 10% transparent. This is the secret to that "premium" glowing effect.

Summary

You don't need to reinvent the wheel. Just stick to these five rules:

Big rounding (xl), small shadows.
Light gray background (slate-50) for the whole page.
Light gray text (slate-500) for secondary info.
Soft gray buttons for secondary actions.
Transparent rings (/10) for input focus states.

If you apply these to your next Rails project, you will be surprised at how "designed" it feels, even if you never opened Figma.

The Better Primary Key: A Guide to ULIDs for Rails Developers

Zil Norvilis — Wed, 27 May 2026 18:06:27 +0000

In a previous article, I talked about Snowflake IDs. They are great, but they require a bit of configuration because you need to manage "Worker IDs."

If you want something simpler that gives you the same benefits - secure URLs and fast database sorting—you should look at ULIDs (Universally Unique Lexicographically Sortable Identifiers).

Why not just use UUIDs?

Most developers switch from auto-incrementing integers to UUIDs because they want to hide their business volume. If your order ID is order/550e8400-e29b..., no one knows if you have 1 customer or 1 million.

But UUIDs have a major problem: they are completely random.
When you insert millions of random UUIDs into a database, the "B-Tree" index gets fragmented and slow. Your database has to jump all over the hard drive to find where to put the new data.

ULIDs fix this.
A ULID is 128 bits (just like a UUID), but the first part of the ID is a timestamp. This means ULIDs are chronological. They are unique like a UUID, but they sort like an Integer.

Here is how to implement ULIDs in your Rails 8 app in 4 easy steps.

STEP 1: Install the Gem

We will use the ulid gem to generate the strings. Add this to your Gemfile:

gem "ulid"

Run bundle install in your terminal.

STEP 2: The ULID Concern

We want to make it very easy to add ULIDs to any model. The best way to do this is with a Concern. This code will ensure that every time we create a new record, a ULID is generated and assigned to the ID.

Create a new file at app/models/concerns/has_ulid.rb:

# app/models/concerns/has_ulid.rb
module HasUlid
  extend ActiveSupport::Concern

  included do
    # Before we save to the DB, generate the ULID
    before_create :set_ulid
  end

  private

  def set_ulid
    # ULID.generate creates a string like: 01ARZ3NDEKTSV4RRFFQ69G5FAV
    self.id ||= ULID.generate
  end
end

STEP 3: The Migration

When you create a new model, you need to tell Rails that the id is a string, and you must disable the default auto-increment logic.

rails g model Product name:string

Open the migration file and modify it like this:

# db/migrate/XXXXXXXXXXXXXX_create_products.rb
class CreateProducts < ActiveRecord::Migration[8.0]
  def change
    # id: false stops the automatic integer ID
    create_table :products, id: false do |t|
      # We use string for ULID primary key
      t.string :id, primary_key: true
      t.string :name

      t.timestamps
    end
  end
end

STEP 4: Update the Model

Now, just include the concern we wrote in Step 2.

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

STEP 5: See it in action

Open your Rails console (bin/rails c) and create a few products:

Product.create(name: "Laptop")
Product.create(name: "Monitor")
Product.create(name: "Keyboard")

# Check the IDs
Product.pluck(:id)
# => ["01HQV...", "01HQV...", "01HQV..."]

If you look closely, the IDs all start with the same characters because they were created in the same minute. Because they are sortable, you can still run Product.order(:id) and they will be in the correct chronological order!

Why I like ULIDs for Rails

Better Performance: Because the IDs are sortable, PostgreSQL (or SQLite) can append them to the end of the index. This is much faster for "Write-Heavy" apps than random UUIDs.
Readability: ULIDs use a special alphabet (Crockford's Base32) that excludes confusing letters like "I", "L", and "O". This makes them easier to read if a user has to type one in.
No Setup: Unlike Snowflake IDs, you don't need to configure server IDs or worker nodes. You just install the gem and go.

That's pretty much it. It’s a small architectural change that makes your app feel much more professional and scalable.

Stop Chasing Hype: Why I Chose Postgres Over 'New-Age' Databases

Zil Norvilis — Tue, 26 May 2026 22:24:42 +0000

I’ve lost count of how many times I’ve been tempted by a "revolutionary" new database.

Every few months, a new tool pops up on Hacker News promising infinite scalability, a schema-less paradise, or native AI capabilities that make everything else look like a calculator from the 80s. For a solo developer, these promises are like siren songs. You think: "If I use this new DB, I'll never have to worry about migrations again!"

But after a decade of building Rails apps, I’ve learned a hard lesson: Boring tech is a competitive advantage.

In 2026, my default choice for every single project is PostgreSQL. While everyone else is busy debugging edge cases in a database that’s only two years old, I’m shipping features. Here is why "boring" Postgres is actually the most exciting tool in my stack.

1. It is 10 Databases in One

The biggest myth about Postgres is that it is "just" a relational database for tables and rows. In reality, Postgres has eaten the features of almost every trending niche database.

Need Document Storage? Use JSONB. It’s faster and more reliable than MongoDB for 99% of use cases.
Need Full-Text Search? Use GIN indexes and TSVector. You can build a great search engine without installing Elasticsearch.
Need AI Vector Search? Use the pgvector extension. You don't need a separate subscription for Pinecone.
Need a Key-Value Store? Use unlogged tables or just a simple HSTORE.

By sticking to Postgres, my "infrastructure map" stays tiny. I don't have to manage five different services; I just manage one very powerful elephant.

2. ACID Compliance and Peace of Mind

There is a specific kind of stress that only developers know: the "Data Corruption" stress.

Many trending databases trade off ACID compliance (Atomicity, Consistency, Isolation, Durability) for speed or "flexibility." They tell you that "eventual consistency" is fine.

It’s not fine. Not when you are handling a user's money, their private notes, or their business records. Postgres is built like a tank. It is designed to never lose your data, even if the power goes out in the middle of a write. As a solo dev, I want to spend my nights sleeping, not manually repairing corrupted database clusters.

3. The Rails 8 "Solid" Movement

If you are following the Rails 8 era, you know that the community is moving toward Database-Backed everything.

Solid Queue moves your background jobs into Postgres.
Solid Cache moves your caching into Postgres.
Solid Cable moves your WebSockets into Postgres.

The Rails team realized that for a "One-Person Framework" to work, we need to stop adding external dependencies like Redis. Because Postgres is so fast and reliable on modern NVMe drives, it can handle all these tasks easily. My entire production stack is now just Linux + Postgres. That is incredibly beautiful.

4. The "Ask Anyone" Ecosystem

When you use a trending database that was released last year, and you hit a weird bug at 2:00 AM, you are in trouble. The only place to find help is a small Discord channel or a half-finished documentation page.

When you have a problem with Postgres, the answer has already been written ten times on StackOverflow. Every AI model (Cursor, ChatGPT, Claude) was trained on decades of Postgres knowledge. Every tool - from BI dashboards to backup utilities—supports Postgres on Day One.

You aren't just buying a database; you are buying into the largest knowledge base in the software world.

Summary: Shipping is the Only Metric

As an indie hacker or solo developer, you are not a "Database Researcher." You are a Product Builder.

Every hour you spend learning a new query language or figuring out how to back up a "revolutionary" new NoSQL store is an hour you didn't spend talking to users or polishing your UI.

Postgres is "boring" because it works. It’s boring because it’s predictable. And in the chaotic world of startups, predictability is a superpower.

n8n vs ByteChef: Which Automation Engine Should You Self-Host?

Zil Norvilis — Sun, 24 May 2026 18:10:41 +0000

Automating the "glue work" of a SaaS business is a survival skill for a solo developer. You need to sync Stripe payments to your database, send Discord alerts for new sign-ups, and maybe trigger AI summaries for incoming emails.

For a long time, n8n has been the undisputed king of self-hosted automation. It’s the tool I’ve recommended for years because it lets you escape the high costs of Zapier while keeping your Rails monolith clean.

But recently, a new challenger called ByteChef has started gaining traction in the open-source community. It promises a more "developer-first" approach to low-code integrations.

If you are looking to set up an automation server on a $5 VPS this weekend, which one should you choose? Here is the breakdown.

1. n8n: The Versatile Giant

n8n is the "Photoshop" of automation. It is built on Node.js and uses a beautiful, flexible node-based interface where you can drag and drop connections in any direction.

The Strength: The Ecosystem
In 2026, n8n has over 400 native integrations. Whether you need to talk to a niche Lithuanian shipping API or a major player like OpenAI, n8n probably already has a node for it.

The Coder’s Edge: JavaScript Nodes
If a built-in node doesn't do exactly what you want, you can drop in a "Code Node" and write raw JavaScript. Since n8n runs on Node.js, you have access to the entire NPM ecosystem.

// A simple n8n code node example
const items = $input.all();

for (let item of items) {
  item.json.slug = item.json.name
    .toLowerCase()
    .replace(/ /g, '-');
}

return items;

The Catch: Because n8n is so flexible, complex workflows can eventually look like a "bowl of spaghetti" with wires crossing everywhere.

2. ByteChef: The Structured Alternative

ByteChef is the newer kid on the block. While n8n focuses on the "Canvas" feel, ByteChef is built with a focus on Integration Management. It’s designed for people who want to build and manage hundreds of different integrations without losing their mind.

The Strength: Multi-Step Logic and Performance
ByteChef is built on a Java-based stack (Spring Boot), which makes it incredibly performant for heavy data processing. It feels more "rigid" than n8n, but in a way that encourages better organization. It’s less of a "playground" and more of an "engine."

The Coder’s Edge: Component Building
ByteChef allows you to build your own components using a very structured schema. If you are an engineer who likes to define strict inputs and outputs for your automations, ByteChef's approach will feel very professional.

The Catch: The community is much smaller. You might find yourself having to write custom connectors for services that n8n already supports out of the box.

Side-by-Side Comparison

Feature	n8n	ByteChef
Language	Node.js (JavaScript)	Java / TypeScript
UI Vibe	Infinite Canvas (Freeform)	Structured Workflows
Integrations	400+ (Huge)	Growing
Self-Hosting	Very Easy (Docker)	Easy (Docker)
Custom Code	JavaScript everywhere	TypeScript / Java

Why I’m Sticking with n8n (For Now)

As a solo developer using the "One-Person Framework" philosophy, n8n is still the winner for 2026.

Community Support: If you have a weird error in an n8n workflow, a quick Google search usually finds a forum post with the solution. ByteChef is still building that knowledge base.
The "Vibe" Factor: n8n's visual debugging is incredible. You can see the data moving through the wires in real-time. When you're "Vibe Coding" with AI assistance, being able to see the failure point instantly is a huge time-saver.
Low Overhead: If you are already a web developer, you probably know enough JavaScript to fix anything in n8n. Learning the ByteChef component structure feels like a bigger "homework" assignment.

Summary

Choose n8n if you want the most reliable, well-documented, and flexible tool available. It is perfect for 99% of solo-dev automation needs.
Choose ByteChef if you are building an automation-heavy product where you need to manage complex, high-performance data pipelines and you prefer a more "engineered" feel over a "drawing" feel.

Regardless of which tool you pick, the most important thing is to stop writing custom Ruby scripts for third-party integrations. Get those tasks out of your Rails app and into a dedicated automation engine.

DEV Community: Zil Norvilis

MVT vs MVC: Understanding Django Through a Rails Lens

1. The Pattern: MVT vs. MVC

2. The CLI: manage.py is your bin/rails

3. The ORM: Django ORM vs. ActiveRecord

4. Routing: urls.py vs. routes.rb

5. The "Superpower": Django Admin

6. Dependency Management

Summary

The $5 VPS Reality: My Honest Math on Moving to Kamal 2

1. The Financial Math (The "Win")

2. The Maintenance Tax (The "Hidden Cost")

3. The "One-Person" Secret: Docker & Kamal 2

4. The Stability Myth

Summary: Should You Switch?

From Coder to Architect: How to Learn Rails When AI Writes the Code

1. Move from "How" to "Where"

2. Audit the AI (The "Why" Test)

3. Learn "Omakase" Constraints

4. Read the Rails Source Code

Summary

Stop Using JS for Everything: Harnessing the Power of Pure CSS in 2026

1. The "Parent" Selector (:has)

2. Native Popovers (The popover Attribute)

3. Container Queries (No more JS Resize Listeners)

4. Scroll-Driven Animations

5. Native Smooth Scrolling and Snap

Summary: Why this matters for Rails 8

The Developer's Way to Track Traffic: Self-Hosting Ackee or Plausible

1. Why Self-Host?

2. The Contenders: Ackee vs. Plausible

Ackee (The Minimalist)

Plausible (The Professional)

3. Deployment with Kamal 2

4. Integrating with Rails

Summary

Count, Length, or Size? Avoiding ActiveRecord Performance Traps

1. .count (The Database Hitter)

2. .length (The Memory Loader)

3. .size (The "Smart" Manager)

Summary: The Decision Matrix

From ERB to Phlex: 5 Steps to Pure Ruby Views

STEP 1: Installation

STEP 2: The Mental Model (Syntax Translation)

STEP 3: Converting a Simple Template

STEP 4: Handling Loops and Logic

STEP 5: Rendering from the Controller

Why is this better?

Summary

UUID v7 vs. ULID: Which Sortable ID Should You Choose?

The Side-by-Side Look

1. The "Native" Win (Why UUID v7 wins on Performance)

2. The "Copy-Paste" Win (Why ULID wins on DX)

3. Implementation in Rails 8

Step 1: Migration

Step 2: Model Configuration

Summary: Which one should you pick?

Stop Making Ugly Apps: Simple Tailwind Tricks for Backend Developers

1. The "Subtle Shell" (The Card Pattern)

2. Never Use Pure White on Pure White

3. Hierarchy through Color, Not Just Size

4. The "Soft" Action (Secondary Buttons)

5. Pro-Level Inputs (The Focus Ring)

Summary

The Better Primary Key: A Guide to ULIDs for Rails Developers

Why not just use UUIDs?

STEP 1: Install the Gem

STEP 2: The ULID Concern

STEP 3: The Migration

STEP 4: Update the Model

STEP 5: See it in action

Why I like ULIDs for Rails

Stop Chasing Hype: Why I Chose Postgres Over 'New-Age' Databases

1. It is 10 Databases in One

2. ACID Compliance and Peace of Mind

3. The Rails 8 "Solid" Movement

4. The "Ask Anyone" Ecosystem

Summary: Shipping is the Only Metric

n8n vs ByteChef: Which Automation Engine Should You Self-Host?

1. n8n: The Versatile Giant

2. The CLI: `manage.py` is your `bin/rails`

4. Routing: `urls.py` vs. `routes.rb`

1. The "Parent" Selector (`:has`)

2. Native Popovers (The `popover` Attribute)

1. `.count` (The Database Hitter)

2. `.length` (The Memory Loader)

3. `.size` (The "Smart" Manager)