Fueling Curiosity, One Insight at a Time

* The Problem:* I had an existing Elixir app with a users table that used password_digest field, but Devise expects encrypted_password by default.

Devise's Default Password Field:

# Devise expects this by default:
class User < ApplicationRecord
  devise :database_authenticatable
  # Uses 'encrypted_password' column automatically
end

Our Existing Schema:

# Uses password_digest
create_table :users do |t|
  t.string :password_digest, null: false  # ← Different field name!
  # ... other fields
end

The Override Solution:

# Devise calls: user.encrypted_password
# Our override returns: user.password_digest

class User < ApplicationRecord
  devise :database_authenticatable, :registerable, :validatable

  # Tell Devise to use our existing password_digest field
  def self.encrypted_password_column
    :password_digest
  end

  # Override the getter method
  def encrypted_password
    read_attribute(:password_digest)
  end

  # Override the setter method  
  def encrypted_password=(value)
    self.password_digest = value
  end
end

So we can simply override Devise's password field by:
1. Telling Devise which column to use (encrypted_password_column)
2. Creating getter/setter bridges (encrypted_password methods)
3. Using read_attribute to avoid method conflicts
#devise #auth

What does model: resource actually do in form_with?

model: resource is the bridge between our form and the data object. It makes forms smart - they remember values, show errors, and handle the complex Rails form lifecycle automatically.

Example:

<%= form_with model: resource, as: resource_name, url: session_path(resource_name), local: true, class: "space-y-6" do |f| %>

model: resource tells Rails:
• Which object to bind the form to
• Where to get field values from
• Where to send validation errors to
• What HTTP method to use (POST for new, PATCH for existing)
In Devise Context:
resource is a Devise helper that returns:
• New User object (for signup) - User.new
• New User object (for signin) - User.new (usually empty, not pre-populated)
Without model: resource:
• Form fields are always empty
• No automatic error handling
• Manual parameter naming required
• No automatic HTTP method detection
#CU6U0R822 #devise

To understand network sockets locally, you can try this simple demo with two terminal tabs:
1. In the first tab run ns -l 1234 : This starts a small server process that listens for TCP connections on your computer’s address (localhost / 127.0.0.1) at port 1234.
2. In the second tab run ns localhost 1234 : This connects a client to the server on 127.0.0.1:1234 , creating a TCP connection between the two processes.
Now type text in one terminal and press Enter you’ll see the same text appear in the other terminal and vice-versa. 🚀

#sockets

Filtering API logs with path params in OpenSearch

When querying logs in OpenSearch Dashboards, paths with dynamic segments (like IDs) often don’t match with the usual search bar syntax because the field is mapped as text instead of keyword.

Problem:
• Queries like

json.req.url: "/api/bankAccounts/*/debit"

return no results.
• .keyword may not exist (json.req.url.keyword) if the field wasn’t mapped that way at ingestion.
Solution:
Use Query DSL with a wildcard or regexp query.

✅ Wildcard query (matches any value in the middle):

{
  "query": {
    "wildcard": {
      "json.req.url": {
        "value": "/api/bankAccounts*/debit"
      }
    }
  }
}

✅ Regex query (restricts the middle part to numbers):

{
  "query": {
    "regexp": {
      "json.req.url": "/api/bankAccounts/[0-9]+/debit"
    }
  }
}

#opensearch #logs

You can mark methods as deprecated in Rails using ActiveSupport::Deprecation. This warns developers that a method will be removed in future versions.

class User < ApplicationRecord
  def full_name
    "#{first_name} #{last_name}"
  end

  # Mark full_name as deprecated
  deprecate :full_name, deprecator: ActiveSupport::Deprecation.new("2.0", "MyApp")
end

DEPRECATION WARNING: full_name is deprecated and will be removed from MyApp 2.0

💡 Might be especially useful in larger codebases, where many developers might be using the same method and you want to safely signal that it will be removed without breaking things immediately.
#Rails

In Prisma, there’s a big difference between directly setting a foreign key and using connect when creating related records.

// ❌ Directly setting the foreign key
users: {
  create: {
    userId: testUser.id,
  },
}

// ✅ Using relation API
users: {
  create: {
    user: {
      connect: { id: testUser.id },
    },
  },
}

• Direct assignment just writes the raw foreign key value — Prisma doesn’t check if the user actually exists.
• connect uses Prisma’s relation API, validates that the record exists, and safely links them.

#prisma

Nx has a built-in command to remove libraries

Nx provides the @nx/workspace:remove generator that can remove a library from our workspace.

The command:

npx nx g @nx/workspace:remove 

What it does automatically:
• Deletes the library folder and all its files
• Removes the project from nx.json and workspace configuration
• Checks for dependencies and warns if other projects still use it
We can use --forceRemove flag if we want to remove a library even when other projects depend on it (though this can break the build).
#nx #monorepo

WITH (NOLOCK) is often used to speed up queries by avoiding shared locks, which means the query won’t block other reads or writes. This can improve performance on busy systems, but it comes at the cost of data accuracy.

When using NOLOCK, SQL Server may:
• Read uncommitted (dirty) data that could later be rolled back.
• Return missing or duplicate rows due to page splits and concurrent writes.
• Show inconsistent values within the same row if columns are updated mid-read.
In short: NOLOCK trades reliability for speed. It’s fine for dashboards, reports, or monitoring where approximate numbers are acceptable, but it should be avoided for financial or critical business logic where accuracy is essential.

#sql

Prisma --create-only

npx prisma migrate dev --create-only --name <migration_name>

Creates a migration file with the SQL changes but does not apply them to the database.

Why this is useful:

✅ Safe inspection – lets you review the generated SQL before running it, especially helpful for destructive operations like drops or PK changes.

✅ Manual adjustments – you can tweak the SQL (e.g., add a USING clause for type casting or backfill data before dropping a column).

✅ Separation of responsibilities – you can generate migrations while DBAs/ops review and apply them in controlled environments.

Key takeaway:

👉 --create-only is like a dry run for migration generation – you get the recipe, but the dish isn't cooked yet 🍳.

#postgres

Rails has a built-in way to reduce repetition in associations—with_options.
When multiple has_many relationships share the same option (like dependent: :destroy), repeating it clutters your model:

class Account < ApplicationRecord
  has_many :customers, dependent: :destroy
  has_many :products,  dependent: :destroy
  has_many :invoices,  dependent: :destroy
  has_many :expenses,  dependent: :destroy
end

Using with_options, you can group them under one block:

class Account < ApplicationRecord
  with_options dependent: :destroy do
    has_many :customers
    has_many :products
    has_many :invoices
    has_many :expenses
  end
end

This makes the intent clearer—all these associations share the same rule.
It's easier to read, less error-prone, and keeps your model DRY ✨
#Rails