🐥 YellowDuck.be

🐥 Installing Claude Code on macOS with Homebrew (and getting the latest version)

2026-04-02T17:00:00Z

If you’re installing Claude Code on macOS using Homebrew, the official instruction currently suggests:

brew install claude-code

While this works, it installs the latest stable version, not the latest available version. Depending on your use case, that can leave you behind on features and fixes.

Install the latest version

To install the most recent release, you should explicitly use:

brew install claude-code@latest

This ensures you’re running the newest version instead of the lagging stable cask.

Fix an existing installation

If you already installed claude-code using the default command, you’ll need to replace it:

brew uninstall claude-code && brew install claude-code@latest

That removes the stable version and installs the latest one cleanly.

Why this matters

Homebrew distinguishes between:

Stable casks → default installs (claude-code)
Versioned or alternative casks → explicit installs (claude-code@latest)

In this case, the naming is a bit misleading because @latest is not the default. This has already caused confusion in the community and is being discussed upstream.

More context

Issue discussion: https://github.com/anthropics/claude-code/issues/42176
Homebrew PR: https://github.com/Homebrew/homebrew-cask/pull/255221

Takeaway

If you want the newest Claude Code features and fixes, don’t rely on the default install. Use:

brew install claude-code@latest

and you’ll avoid running an outdated version without realizing it.

#tools #announcement #mac

🐥 Taming scrollbars in a Phoenix app

2026-03-31T17:00:00Z

One of those tiny UI details that quietly annoys users more than you'd expect: scrollbars that flash in and out of existence, causing the page layout to jump around. This week I finally cleaned it up in my Phoenix app and the fix was surprisingly elegant.

The problem

The original root.html.heex had this on the element:

<html lang="en" class="[scrollbar-gutter:stable]">

scrollbar-gutter: stable is a CSS property that reserves space for the scrollbar even when it isn't needed — the idea being to prevent layout shifts when content height changes. It's a reasonable approach, but it has a side effect: on macOS with "Show scroll bars: Always", you end up with a permanent empty gutter on pages that don't scroll. On Windows, where scrollbars are visible by default, the gutter is always there. Depending on your layout, that reserved space can look odd.

The solution

I removed the Tailwind utility class from the tag and instead reached for a small CSS snippet:

/* Only show scrollbars when content actually overflows */
* {
  scrollbar-width: thin;
  scrollbar-color: transparent transparent;
}

*:hover {
  scrollbar-color: rgba(0, 0, 0, 0.2) transparent;
}

What this does:

scrollbar-width: thin — uses the browser's thin scrollbar variant, which is less visually heavy than the default.
scrollbar-color: transparent transparent — hides the scrollbar thumb and track by making them fully transparent. The scrollbar doesn't disappear from the DOM; it just becomes invisible when you're not interacting with the element.
*:hover { scrollbar-color: rgba(0,0,0,0.2) transparent } — fades the scrollbar thumb in (as a subtle translucent grey) only when the user hovers over the element. This gives a clean overlay-style scrollbar feel, similar to what macOS does natively.

Why this feels better

The end result is a UI that looks clean and uncluttered at rest, but still gives users a clear scrollbar affordance the moment they move their cursor over a scrollable area. No layout jump, no reserved gutter space, and no permanently visible chrome competing for attention.

It's a two-file change — one CSS block and the removal of a single Tailwind class — but the visual impact is noticeable, especially on pages with sidebars or nested scrollable containers.

Browser support

scrollbar-width and scrollbar-color are part of the CSS Scrollbars Specification and have solid support in Firefox and Chromium-based browsers. Safari added support in version 18.2. For older Safari versions the scrollbar will just render with its default appearance — a perfectly acceptable fallback.

Small change, cleaner app. Sometimes that's all it takes.

#css #elixir #phoenix #html

🐥 A better way: Using mkcert for HTTPS in Phoenix on macOS

2026-03-30T17:00:00Z

In a previous post, I showed how to use mix phx.gen.cert to set up HTTPS in Phoenix development. While that approach works in theory, in practice it's a minefield: OpenSSL 3.x generates PKCS12 bundles that macOS's security command rejects, browsers send cryptic Decode Error alerts, and manually trusting certificates in Keychain Access often has no effect at all.

There's a much better tool for this: mkcert.

What makes mkcert different?

mkcert creates a local Certificate Authority (CA) on your machine and registers it with macOS's system trust store, Firefox, and Chrome in one command. Any certificate you generate from it is automatically trusted — no manual Keychain fiddling required.

Step 1: Install mkcert and register the local CA

brew install mkcert
mkcert -install

The -install step is what makes everything work. It adds mkcert's root CA to your system keychain so all browsers trust it going forward.

Verify it landed:

security find-certificate -c "mkcert"

Step 2: Generate a certificate for localhost

From your Phoenix project root:

mkcert -cert-file priv/cert/selfsigned.pem \
       -key-file priv/cert/selfsigned_key.pem \
       localhost 127.0.0.1 ::1

This generates a certificate valid for localhost, 127.0.0.1, and ::1, signed by your local CA.

Step 3: Configure Phoenix for HTTPS

Update config/dev.exs:

config :your_app, YourAppWeb.Endpoint,
  https: [
    port: 4001,
    cipher_suite: :strong,
    certfile: "priv/cert/selfsigned.pem",
    keyfile: "priv/cert/selfsigned_key.pem"
  ],
  check_origin: false,
  code_reloader: true,
  debug_errors: true

Start your server:

mix phx.server

Visit https://localhost:4001 — no browser warnings, no certificate errors, no Keychain gymnastics.

What about the cert files in version control?

The generated priv/cert/ files are already in .gitignore when using mix phx.gen.cert, and should stay there with mkcert too. Each developer on your team runs mkcert -install and generates their own certificate locally.

Upgrading from the old approach

If you followed the previous post, you can replace the existing cert files in place — the Phoenix config stays the same since you're still pointing at priv/cert/selfsigned.pem and priv/cert/selfsigned_key.pem. Just regenerate them with mkcert and restart your server.

#development #tools #elixir #phoenix #terminal

🐥 Fixing a race condition in Oban job counting with telemetry

2026-03-29T17:00:00Z

When building a LiveView dashboard that shows how many background jobs are still processing, a subtle race condition can make the count permanently off by one. Here's how I ran into it and how Oban's telemetry system solved it cleanly.

The Setup

The app has an Oban worker — ProcessExternalLinkWorker — that fetches a URL, extracts content, and creates a post. The LiveView index page shows a "X post(s) currently being processed" banner while jobs are in flight.

The job count is a straightforward Oban query:

from(j in Job,
  where: j.state not in ["completed", "discarded"] and j.worker == ^worker
)
|> Repo.aggregate(:count, :id)

The LiveView subscribes to a "posts" PubSub topic and refreshes this count whenever a "post_updated" message arrives. That message is broadcast from inside Posts.create_post/1, which is called from within the worker.

The Bug

Here's the execution sequence that causes the problem:

Oban picks up a job — state transitions to executing
The worker calls ProcessExternalLink.process_url/1
That calls Posts.create_post/1, which broadcasts "post_updated"
The LiveView receives the broadcast and re-queries the job count
The job is still executing — it hasn't returned :ok yet
The count includes this job, showing 1 item "still processing" even though the work is done
The worker returns :ok, Oban marks the job completed — but no one tells the LiveView

The post list refreshes correctly, but the processing counter stays at 1 until the next page load.

Subtracting 1 from the count isn't a fix — with multiple concurrent jobs, you'd need to know exactly how many are in this "just finished broadcasting but not yet completed" state, which is unknowable from the outside.

The Fix: Oban Telemetry

Oban emits telemetry events throughout the job lifecycle. The key one here is [:oban, :job, :stop], which fires after the job state has been updated to completed in the database. There's also [:oban, :job, :exception] for failed jobs.

The fix is to decouple the job count refresh from the "post_updated" broadcast. Instead, attach a telemetry handler that broadcasts a separate "jobs_updated" message when a job finishes:

defmodule MyWebApp.ObanTelemetryHandler do
  require Logger

  def attach do
    :telemetry.detach("oban-job-lifecycle")

    :telemetry.attach_many(
      "oban-job-lifecycle",
      [[:oban, :job, :stop], [:oban, :job, :exception]],
      &__MODULE__.handle_event/4,
      nil
    )
  end

  def handle_event([:oban, :job, event], _measurements, meta, _config) do
    Logger.debug("Oban job #{event}: worker=#{meta[:worker]}")
    Phoenix.PubSub.broadcast(MyWebApp.PubSub, "posts", %{event: "jobs_updated"})
  end
end

Two design decisions worth noting:

detach before attach: Calling attach_many with a handler ID that's already registered raises an ArgumentError. In development, a full server restart re-runs application.ex and would hit this error on the second start. Calling detach first makes attach/0 idempotent at the cost of one no-op call.

No worker filter: An earlier version filtered on the worker name in the handler's pattern match. That's redundant — the Ecto query in the LiveView already scopes the count to the specific worker. Removing the filter keeps the handler simpler and avoids fragility around how Oban formats the worker name in telemetry metadata.

Call attach/0 in application.ex after the supervisor starts:

{:ok, pid} = Supervisor.start_link(children, opts)
MyWebApp.ObanTelemetryHandler.attach()

Then handle the new event in the LiveView, separate from "post_updated":

def handle_info(%{event: "jobs_updated"}, socket) do
  worker = inspect(MyWebApp.Workers.ProcessExternalLinkWorker)

  num_processing =
    from(j in Job,
      where: j.state not in ["completed", "discarded"] and j.worker == ^worker
    )
    |> Repo.aggregate(:count, :id)

  {:noreply, assign(socket, :num_processing, num_processing)}
end

Why This Works

The "post_updated" broadcast still fires mid-job and the post list still refreshes correctly — that part was never broken. But the job count is now only refreshed in response to the telemetry event, which is guaranteed to fire after the state change has been committed. The LiveView queries at the right moment.

It also handles failure correctly. If the worker raises an exception, [:oban, :job, :exception] fires, the LiveView refreshes the count, and any retryable or discarded jobs show up accurately.

Takeaway

When displaying counts or status derived from job state, don't trigger the refresh from within the job itself. The job is still running at that point. Instead, hook into Oban's telemetry events, which fire at well-defined points in the lifecycle after state transitions have been committed.

#development #pattern #database #elixir #phoenix

🐥 TIL: filtering GitHub PRs that are ready for review and not yours

2026-03-28T18:00:00Z

When reviewing pull requests in GitHub, I often want a clean list of PRs that:

are open
are not drafts
are not created by me

Here’s the filter I use:

sort:updated-desc is:pr is:open -author:username draft:false

What this does

sort:updated-desc → most recently updated PRs first
is:pr → only pull requests
is:open → only open PRs
-author:username → exclude your own PRs
draft:false → exclude draft PRs (only show ready-for-review)

This gives a focused, high-signal list of PRs that are actually actionable.

Bonus: explore more filters

GitHub’s search syntax is surprisingly powerful. You can filter by labels, review status, checks, branches, and more.

Check out the full reference here: https://docs.github.com/en/search-github/searching-on-github/searching-issues-and-pull-requests

A few useful additions:

review-requested:@me → PRs requesting your review
status:success → only PRs with passing checks
label:bug → filter by label
-is:merged → exclude merged PRs

Once you start combining these, you can build very tailored review dashboards directly in GitHub.

#development #github

🐥 Enforcing polymorphic integrity in PostgreSQL with num_nonnulls

2026-03-27T18:00:00Z

Polymorphic associations are common when a single table can reference multiple other tables. A typical implementation is one table with multiple nullable foreign keys:

CREATE TABLE my_poly_assocs (
  id bigserial PRIMARY KEY,
  assoc_a_id bigint REFERENCES assoc_a(id),
  assoc_b_id bigint REFERENCES assoc_b(id),
  assoc_c_id bigint REFERENCES assoc_c(id)
);

The intent is simple: each row should reference exactly one of these associations. But the database won’t enforce that automatically. Without extra constraints, you can end up with:

No association set (all NULL)
Multiple associations set (invalid state)

PostgreSQL has a clean solution for this.

The `num_nonnulls` function

PostgreSQL provides a built-in function called num_nonnulls. It returns the number of arguments that are not NULL.

That makes it perfect for enforcing “exactly one” semantics:

ALTER TABLE my_poly_assocs
ADD CONSTRAINT exactly_one_assoc_referenced
CHECK (num_nonnulls(assoc_a_id, assoc_b_id, assoc_c_id) = 1);

This constraint guarantees:

At least one foreign key is set
No more than one foreign key is set

If a row violates the rule, the insert or update fails immediately.

Why this is better than application-level checks

You could enforce this rule in your application layer, but that leaves room for:

Race conditions
Multiple services writing to the same database
Future code paths forgetting the rule

A CHECK constraint keeps the invariant inside the database, where it belongs.

Variations

If your requirement is “at most one” instead of “exactly one”, you can adjust the constraint:

CHECK (num_nonnulls(assoc_a_id, assoc_b_id, assoc_c_id) <= 1)

If you later add a new polymorphic target, you must update the constraint to include the new column.

When to use this pattern

This approach works well when:

You need strict relational integrity.
The set of polymorphic targets is finite and known.
You want predictable query performance without an additional type column.

If your targets are dynamic or numerous, a more classic polymorphic design (e.g. target_type + target_id) may be more flexible, though it trades off referential integrity.

Conclusion

num_nonnulls is a small but powerful feature in PostgreSQL. It allows you to enforce a subtle but important invariant with a single CHECK constraint, keeping your polymorphic associations consistent and safe at the database level.

It’s one of those features that feels obvious once you know it exists.

#pattern #database #postgresql #sql

🐥 Request validation in Phoenix: the Laravel FormRequest approach

2026-03-25T18:00:00Z

Developers coming from Laravel are used to FormRequest classes that encapsulate request validation and authorization. A typical FormRequest contains validation rules, optional authorization logic, and automatically provides validated input to the controller.

Phoenix takes a slightly different approach. Instead of request-focused validation objects, validation is typically handled using Ecto changesets. This approach moves validation closer to the data model and keeps controllers thin.

This article explains how validation works in Phoenix and how to implement reusable custom validation rules similar to Laravel.

Validation with Ecto changesets

In Phoenix, validation is usually implemented inside an Ecto changeset. A changeset handles three responsibilities:

casting incoming parameters
validating data
collecting validation errors

A typical schema with validations looks like this:

defmodule MyApp.Accounts.User do
  use Ecto.Schema
  import Ecto.Changeset

  schema "users" do
    field :email, :string
    field :name, :string
  end

  def changeset(user, attrs) do
    user
    |> cast(attrs, [:email, :name])
    |> validate_required([:email, :name])
    |> validate_format(:email, ~r/@/)
  end
end

Incoming request data is passed to the changeset through a context function:

def create_user(attrs) do
  %User{}
  |> User.changeset(attrs)
  |> Repo.insert()
end

The controller then handles the result:

def create(conn, params) do
  case Accounts.create_user(params) do
    {:ok, user} ->
      json(conn, user)

    {:error, changeset} ->
      conn
      |> put_status(:unprocessable_entity)
      |> json(%{errors: changeset.errors})
  end
end

This already provides most of the functionality developers expect from Laravel FormRequests.

Writing custom validation rules

Custom validation logic in Phoenix is implemented as functions that operate on a changeset. These functions can be private helpers or reusable validation utilities.

Field-level custom validation

The most common tool for custom rules is validate_change/3.

defp validate_company_email(changeset) do
  validate_change(changeset, :email, fn :email, email ->
    if String.ends_with?(email, "@company.com") do
      []
    else
      [email: "must be a company email"]
    end
  end)
end

You can include this in a changeset pipeline:

def changeset(user, attrs) do
  user
  |> cast(attrs, [:email])
  |> validate_required([:email])
  |> validate_company_email()
end

If the validation fails, an error is added to the changeset.

Reusable validation helpers

If validation logic should be reused across schemas, it can be extracted into a module.

defmodule MyApp.Validations do
  import Ecto.Changeset

  def validate_company_email(changeset, field) do
    validate_change(changeset, field, fn ^field, email ->
      if String.ends_with?(email, "@company.com") do
        []
      else
        [{field, "must be a company email"}]
      end
    end)
  end
end

Usage inside a changeset:

import MyApp.Validations

def changeset(user, attrs) do
  user
  |> cast(attrs, [:email])
  |> validate_required([:email])
  |> validate_company_email(:email)
end

This pattern is similar to reusable validation rules in Laravel.

Cross-field validation

Some rules depend on multiple fields. In these cases, the changeset can be inspected directly.

For example, validating a date range:

def validate_date_range(changeset) do
  start_date = get_field(changeset, :start_date)
  end_date = get_field(changeset, :end_date)

  if start_date && end_date && Date.compare(start_date, end_date) == :gt do
    add_error(changeset, :start_date, "must be before end date")
  else
    changeset
  end
end

Used inside a changeset:

def changeset(event, attrs) do
  event
  |> cast(attrs, [:start_date, :end_date])
  |> validate_required([:start_date, :end_date])
  |> validate_date_range()
end

Database-backed validation

Some validation rules depend on the database. For example, checking whether an email already exists.

While this can be implemented manually, the preferred approach is to rely on database constraints.

|> unique_constraint(:email)

This requires a unique index in the database and prevents race conditions that can occur with manual checks.

Key building blocks

Custom validation in Ecto is built on a few core functions:

validate_change/3
add_error/3
get_field/2
validate_required/2
validate_length/3
validate_format/3
validate_number/3
validate_inclusion/3

Most complex validation logic can be composed from these primitives.

Comparing Laravel and Phoenix validation

Laravel focuses validation around the HTTP request, while Phoenix places validation closer to the data layer.

Laravel:

FormRequest
  ↓
Validator
  ↓
Controller

Phoenix:

Controller
  ↓
Context
  ↓
Changeset

This design makes validation reusable across:

HTTP APIs
Phoenix HTML forms
LiveView forms
background jobs
internal application logic

By attaching validation to the data structure instead of the request, Phoenix ensures consistent validation regardless of where data enters the system.

Conclusion

Phoenix does not provide a direct equivalent to Laravel FormRequests, but Ecto changesets offer a powerful and flexible alternative.

Validation rules live alongside the data structure, are easily composable, and can be reused across different parts of the application. Custom rules are implemented as simple functions that transform changesets, making them easy to test and reuse.

For developers moving from Laravel, the key mindset shift is moving validation from the request layer to the data layer. Once adopted, this pattern results in clean controllers, reusable validation logic, and consistent data integrity across the entire application.

#laravel #php #database #http #elixir #phoenix

🐥 Making Oban workers reusable with job arguments

2026-03-23T18:00:00Z

When you first write an Oban worker, it's tempting to hardcode its configuration directly in the module. A worker that fetches an RSS feed might embed the URL as a module attribute. It works fine — until you need to do the same thing for a second feed, and suddenly you're copy-pasting a nearly identical module.

There's a better way.

The Problem: One Worker, One Purpose

A typical first pass at a feed-fetching worker looks something like this:

defmodule MyApp.Workers.FetchThinkingElixirFeedWorker do
  use Oban.Worker, queue: :default, max_attempts: 1

  @feed_url "https://www.yellowduck.be/posts/feed"
  @tags ["elixir", "phoenix"]

  @impl Oban.Worker
  def perform(%Oban.Job{}) do
    # fetch and process @feed_url, apply @tags...
  end
end

This is completely fine for one feed. But the moment you want to add a second feed, you're either duplicating the module or reaching for inheritance patterns that don't belong here.

The Fix: Pass Configuration as Job Args

Oban jobs carry an args map that gets persisted alongside the job. Instead of hardcoding configuration in the module, move it into those args:

defmodule MyApp.Workers.FetchFeedWorker do
  use Oban.Worker, queue: :default, max_attempts: 1

  @impl Oban.Worker
  def perform(%Oban.Job{args: %{"feed_url" => feed_url, "tags" => tags}}) do
    # fetch and process feed_url, apply tags...
  end
end

Now the worker is a generic mechanism. The what (which feed, which tags) is data — not code.

Using It for Scheduled Jobs

The Oban cron plugin supports passing args directly to scheduled workers, so you get the same ergonomics for recurring jobs:

{Oban.Plugins.Cron,
  crontab: [
    {"0 * * * *", MyApp.Workers.FetchFeedWorker,
    args: %{"feed_url" => "https://www.yellowduck.be/posts/feed",
            "tags" => ["elixir", "phoenix"]}},
    {"0 * * * *", MyApp.Workers.FetchFeedWorker,
    args: %{"feed_url" => "https://changelog.com/podcast/feed",
            "tags" => ["programming", "open-source"]}}
  ]}

Two cron entries, one worker module. Adding a third feed is a config change, not a code change.

Inserting One-Off Jobs

The same pattern works for manually enqueued jobs:

%{"feed_url" => "https://example.com/rss", "tags" => ["news"]}
|> MyApp.Workers.FetchFeedWorker.new()
|> Oban.insert()

Why This Matters

Less code to maintain. One module handles all feeds. Bug fixes and improvements apply everywhere automatically.

Clearer separation of concerns. The worker encodes how to process a feed. The job args encode which feed to process. These are genuinely different things and should live in different places.

More observable. Because args are stored in the database with each job, you can see exactly what configuration ran — useful when debugging why a particular job behaved a certain way.

Easier to extend. Want to add a max_items option? Add it to the args map and pattern match on it with a default. No new module required.

When to Keep Workers Specific

This pattern isn't always the right call. If two "similar" workers actually have meaningfully different logic — different parsing strategies, different retry behaviour, different side effects — a shared module can become a tangle of conditionals. In that case, separate modules with a shared private helper or a behaviour is often cleaner.

But when the logic is truly the same and only the inputs differ, push the inputs into args and let the worker be a function.

#development #pattern #database #elixir #phoenix

🐥 Understanding Agent, GenServer, Task, and ETS in Elixir

2026-03-21T18:00:00Z

When building concurrent systems in Elixir, you have several OTP abstractions available. Two of the most commonly discussed are Agent and GenServer, but in real systems developers also frequently use Task, ETS, and sometimes GenStage or Broadway.

Understanding when to use each abstraction is important for building systems that remain simple, scalable, and maintainable.

This article explains the differences and ends with a common GenServer anti-pattern to avoid.

Agent: a simple state container

An Agent is the simplest abstraction for managing shared state in a process.

It wraps a process that holds state and provides helper functions to read or update that state.

Example:

{:ok, pid} = Agent.start_link(fn -> [] end)

Agent.update(pid, fn state -> ["hello" | state] end)

Agent.get(pid, fn state -> state end)

Characteristics:

Stores state in a separate process
Minimal API (get and update)
No message handling
No lifecycle callbacks
Very small abstraction

Typical use cases:

Small in-memory caches
Counters
Temporary shared state
Test helpers

Example:

Agent.start_link(fn -> %{} end, name: MyCache)

Agent.update(MyCache, &Map.put(&1, key, value))
Agent.get(MyCache, &Map.get(&1, key))

An Agent is essentially a lightweight wrapper around a process holding state.

GenServer: a full OTP server abstraction

A GenServer is a behaviour for implementing long-running server processes.

It provides a structured way to handle messages, maintain state, and react to events.

Example:

defmodule Counter do
  use GenServer

  def start_link(initial) do
    GenServer.start_link(__MODULE__, initial, name: __MODULE__)
  end

  def increment do
    GenServer.cast(__MODULE__, :increment)
  end

  def value do
    GenServer.call(__MODULE__, :value)
  end

  def init(state) do
    {:ok, state}
  end

  def handle_cast(:increment, state) do
    {:noreply, state + 1}
  end

  def handle_call(:value, _from, state) do
    {:reply, state, state}
  end
end

Characteristics:

Structured callbacks (init, handle_call, handle_cast, handle_info)
Supports synchronous and asynchronous communication
Integrates with supervision trees
Can schedule work and handle system messages

Typical use cases:

Stateful services
Resource managers
Background workers
Caches with logic
Rate limiters
Schedulers

A GenServer is best thought of as a stateful actor that encapsulates behaviour.

Why many developers skip Agent

Although Agents are simple, many production systems grow beyond their capabilities.

Two common limitations are:

Business logic leaks outside the process

With Agents, the caller often contains the business logic:

Agent.update(cache, fn state ->
  Map.update(state, key, 1, &(&1 + 1))
end)

With a GenServer, the process owns the behaviour:

def increment(key) do
  GenServer.cast(__MODULE__, {:increment, key})
end

def handle_cast({:increment, key}, state) do
  {:noreply, Map.update(state, key, 1, &(&1 + 1))}
end

This makes the process behave like a service with a well-defined API.

Limited extensibility

Real systems often need:

periodic work
cache expiration
telemetry
retries
batching

These are difficult to implement with Agents but natural in a GenServer.

Because of this, many developers default to GenServer.

Task: concurrency for short-lived work

Task is designed for temporary concurrent work.

Example:

task = Task.async(fn -> fetch_feed(url) end)

Task.await(task)

For parallel workloads:

urls
|> Task.async_stream(&fetch_feed/1, max_concurrency: 10)
|> Enum.to_list()

Typical use cases:

parallel HTTP requests
data processing
CPU-bound work
concurrent API calls

Tasks should be used for short-lived processes, not long-running services.

ETS: extremely fast shared memory

ETS (Erlang Term Storage) is an in-memory storage system optimized for concurrent access.

Example:

:ets.new(:cache, [:set, :public, :named_table])

:ets.insert(:cache, {:key, value})
:ets.lookup(:cache, :key)

Characteristics:

extremely fast
concurrent reads
shared memory
no process bottleneck

A common pattern is:

GenServer
   ↓
ETS table

The GenServer manages lifecycle and policies, while ETS stores the data.

A common GenServer anti-pattern

One of the most common mistakes in Elixir systems is turning a GenServer into a global bottleneck.

Example:

def handle_call({:fetch_url, url}, _from, state) do
  result = HTTP.get(url)
  {:reply, result, state}
end

Problem:

The GenServer becomes responsible for slow work such as:

HTTP requests
file IO
database queries

Because a GenServer processes one message at a time, every request queues behind the previous one.

This can severely limit concurrency.

Better approach

Use the GenServer for coordination, not heavy work.

Example:

def handle_cast({:fetch_url, url}, state) do
  Task.start(fn -> fetch_and_store(url) end)
  {:noreply, state}
end

Now the GenServer remains responsive while tasks perform the expensive work.

Choosing the right abstraction

A simple decision guide:

Problem	Recommended abstraction
Simple shared state	Agent
Stateful service or coordination	GenServer
Parallel short-lived work	Task
Ultra-fast shared memory	ETS
Streaming pipelines	GenStage
Message ingestion pipelines	Broadway

Conclusion

Elixir provides multiple abstractions for building concurrent systems, each designed for a specific purpose.

In practice:

GenServer is the most common building block
Task handles concurrent work
ETS provides high-performance shared memory
Agent is useful for very small state containers

Choosing the correct abstraction helps avoid bottlenecks and keeps systems simple as they grow.

#pattern #database #http #elixir

🐥 Monitoring the progress of creating an index in PostgreSQL

2026-03-08T18:00:00Z

Creating an index on a large table can take minutes or even hours. For GIN, trigram, or multi-million row tables, it can feel like nothing is happening at all.

PostgreSQL provides built-in visibility into index creation progress. You don’t need external tools — just the right system view.

The `pg_stat_progress_create_index` view

PostgreSQL exposes index build progress via:

PostgreSQL

The key view is:

SELECT *
FROM pg_stat_progress_create_index;

This shows all currently running CREATE INDEX operations.

If nothing is building, it returns zero rows.

Example output explained

A typical query looks like this:

SELECT
    pid,
    datname,
    relid::regclass AS table_name,
    index_relid::regclass AS index_name,
    phase,
    lockers_total,
    lockers_done,
    blocks_total,
    blocks_done,
    tuples_total,
    tuples_done
FROM pg_stat_progress_create_index;

Important columns:

`phase`

Tells you what stage the build is in. Examples:

initializing
building index
waiting for writers before validation
index validation
waiting for old snapshots

If you're using CREATE INDEX CONCURRENTLY, you’ll see additional validation phases.

`blocks_total` and `blocks_done`

These indicate:

Total table blocks to scan
How many have been processed

Progress percentage:

(blocks_done::float / NULLIF(blocks_total, 0)) * 100

This is usually the most reliable indicator during the scan phase.

`tuples_total` and `tuples_done`

Shows:

Estimated total rows
Rows processed so far

Useful, but block progress is often more stable.

Monitoring concurrent index builds

When using:

CREATE INDEX CONCURRENTLY ...

PostgreSQL performs multiple scans and validation steps.

You’ll see phases like:

building index
waiting for writers before validation
index validation
waiting for old snapshots

If it appears stuck in:

waiting for old snapshots

That usually means a long-running transaction is preventing completion.

You can inspect active transactions:

SELECT pid, state, query, xact_start
FROM pg_stat_activity
WHERE state != 'idle'
ORDER BY xact_start;

Calculating progress percentage

A simple progress query:

SELECT
    relid::regclass AS table_name,
    index_relid::regclass AS index_name,
    phase,
    ROUND(
        100.0 * blocks_done / NULLIF(blocks_total, 0),
        2
    ) AS progress_percent
FROM pg_stat_progress_create_index;

This gives you a clean percentage during the main build phase.

When progress appears frozen

Common reasons:

Very small maintenance_work_mem
Disk I/O saturation
WAL bottlenecks
Waiting on long-running transactions (concurrent builds)
CPU-heavy index types (e.g. GIN with trigrams)

If blocks aren’t increasing, check:

SELECT wait_event_type, wait_event
FROM pg_stat_activity
WHERE pid = <index_pid>;

This tells you whether it’s waiting on:

Lock
IO
WAL
Buffer pin
etc.

Estimating total duration

A rough estimate during build:

SELECT
    blocks_done,
    blocks_total,
    now() - backend_start AS elapsed
FROM pg_stat_progress_create_index
JOIN pg_stat_activity USING (pid);

You can extrapolate remaining time from block progress.

Version requirement

pg_stat_progress_create_index is available since:

PostgreSQL 12

If you’re on an older version, you won’t have native progress tracking.

Practical workflow

When building a large index in production:

Run CREATE INDEX (or CONCURRENTLY)
Monitor pg_stat_progress_create_index
Watch for blocking transactions
Track I/O saturation
Increase maintenance_work_mem if needed

This gives you visibility instead of guessing.

Final thoughts

Large index builds are expensive operations. Monitoring progress:

Reduces uncertainty
Helps detect blockers
Allows time estimation
Makes concurrent builds safer in production

If you regularly build large GIN or trigram indexes, having a monitoring query ready in your toolbox saves a lot of stress.

#database #tools #postgresql #sql

🐥 Why prefer const arrow functions over function declarations in TypeScript?

2026-03-05T18:00:00Z

In modern TypeScript codebases, you’ll often see functions defined like this:

const doSomething = (): void => {};

instead of:

function doSomething(): void {}

Both are valid. But there are good reasons why many teams prefer the const + arrow function style as a default.

Predictable execution order

Function declarations are hoisted:

doSomething(); // Works

function doSomething(): void {}

This can hide ordering problems and make large modules harder to reason about.

Arrow functions assigned to const are not callable before initialization:

doSomething(); // ReferenceError

const doSomething = (): void => {};

This makes execution order explicit and avoids subtle refactoring issues.

Immutability by default

Using const makes it clear the function reference should not change:

const doSomething = () => {};

Treating functions as immutable values aligns well with modern TypeScript practices and reduces accidental reassignment.

Safer `this` behavior

Arrow functions use lexical this, meaning they capture this from the surrounding scope.

class Example {
  value = 42;

  method() {
    setTimeout(() => {
      console.log(this.value); // Works
    });
  }
}

With a traditional function, this would be undefined or unexpected unless manually bound. Arrow functions eliminate an entire class of common JavaScript bugs.

Better fit for functional patterns

Arrow functions integrate naturally with higher-order functions:

const double = (x: number) => x * 2;
const result = numbers.map(double);

This style scales well in functional and compositional code.

When to use function declarations

Function declarations still make sense when:

You intentionally rely on hoisting
You want a clearly named recursive function
You define class methods

They’re not wrong — just more situational.

Conclusion

Using const with arrow functions promotes:

Explicit execution order
Immutability
Safer this semantics
Consistency across modern codebases

For most TypeScript projects, it’s a sensible default. Use function deliberately when its behavior is exactly what you need.

#javascript #typescript

🐥 Optimizing nested array operations in PHP: from O(3n) to O(n)

2026-03-01T18:00:00Z

TL;DR: Learn how replacing Laravel's Arr::dot() and Arr::undot() with a recursive approach can make your nested array filtering ~3x faster while keeping the code clean and testable.

The Problem

Imagine you're building an API that returns user data with nested relationships. For privacy reasons, you need to strip out sensitive fields like password_hash from all nested objects, but you want to preserve them at the root level for administrative views.


$userData = [
    'id' => 1,
    'name' => 'John Doe',
    'password_hash' => '$2y$10$...', // Keep at root
    'profile' => [
        'bio' => 'Developer',
        'password_hash' => 'leaked!', // Remove this!
    ],
    'posts' => [
        [
            'title' => 'My Post',
            'author' => [
                'name' => 'John',
                'password_hash' => 'leaked!', // Remove this too!
            ],
        ],
    ],
];

The Naive Approach (Slow)

Laravel developers often reach for Arr::dot() and Arr::undot() for this kind of operation:


use Illuminate\Support\Arr;
use Illuminate\Support\Str;

private function sanitizeData(array $data): array
{
    // Flatten the entire array
    $dotted = collect(Arr::dot($data))
        // Filter out nested password_hash keys
        ->filter(fn ($value, $key) =>
            Str::contains($key, '.password_hash.') === false
        )
        ->toArray();

    // Rebuild the nested structure
    return Arr::undot($dotted);
}

Why This Is Slow

Arr::dot() - Flattens entire array: O(n)
filter() - Iterates all keys: O(n)
Arr::undot() - Rebuilds structure: O(n)
Total: O(3n) with significant overhead

For a typical nested structure with 1,000 elements, you're doing 3,000 operations plus the memory allocation for the flattened array.

The Optimized Approach (Fast)

Instead, use a single recursive pass:


private function sanitizeData(array $data): array
{
    return $this->removeNestedKey($data, 'password_hash', isRoot: true);
}

private function removeNestedKey(array $data, string $keyToRemove, bool $isRoot): array
{
    $result = [];

    foreach ($data as $key => $value) {
        // Skip the sensitive key if not at root level
        if ($key === $keyToRemove && !$isRoot) {
            continue;
        }

        // Recursively process nested arrays
        if (is_array($value)) {
            $processed = $this->removeNestedKey($value, $keyToRemove, isRoot: false);

            // Only include non-empty results
            if (!empty($processed)) {
                $result[$key] = $processed;
            }
        } else {
            $result[$key] = $value;
        }
    }

    return $result;
}

Why This Is Fast

Single pass through the data: O(n)
No temporary arrays - processes in-place
Lower memory usage - no flattened intermediate structure
~3x faster in real-world scenarios

Real-World Performance Test

Let's create a test with a realistic nested structure:


public function test_handles_large_nested_structure_efficiently(): void
{
    // Simulate API response with 100 users, each with nested data
    $users = [];
    for ($i = 0; $i < 100; $i++) {
        $users[] = [
            'id' => $i,
            'name' => "User {$i}",
            'password_hash' => '$2y$10$...',
            'profile' => [
                'bio' => str_repeat('Lorem ipsum ', 50),
                'settings' => [
                    'password_hash' => 'should_be_removed',
                    'notifications' => ['email', 'push'],
                ],
            ],
            'posts' => array_fill(0, 10, [
                'title' => 'Post title',
                'author' => [
                    'password_hash' => 'should_be_removed',
                    'name' => 'Author',
                ],
            ]),
        ];
    }

    $sanitized = $this->sanitizeData(['users' => $users]);

    // Verify root-level password_hash is preserved
    $this->assertArrayHasKey('password_hash', $sanitized['users'][0]);

    // Verify nested password_hash keys are removed
    $this->assertArrayNotHasKey('password_hash',
        $sanitized['users'][0]['profile']['settings']);
    $this->assertArrayNotHasKey('password_hash',
        $sanitized['users'][0]['posts'][0]['author']);
}

Complete Test Suite

Here's a comprehensive test suite covering edge cases:


 declare(strict_types=1);

namespace Tests\Unit\Services;

use App\Services\DataSanitizer;
use PHPUnit\Framework\Attributes\Test;
use Tests\TestCase;

final class DataSanitizerTest extends TestCase
{
    #[Test]
    public function it_removes_nested_sensitive_keys(): void
    {
        $data = [
            'name' => 'John',
            'relations' => [
                'password_hash' => 'should_be_removed',
                'email' => 'john@example.com',
            ],
        ];

        $sanitizer = new DataSanitizer();
        $result = $sanitizer->sanitize($data);

        $this->assertArrayHasKey('relations', $result);
        $this->assertArrayNotHasKey('password_hash', $result['relations']);
        $this->assertArrayHasKey('email', $result['relations']);
    }

    #[Test]
    public function it_preserves_root_level_sensitive_keys(): void
    {
        $data = [
            'password_hash' => 'keep_this',
            'name' => 'John',
        ];

        $sanitizer = new DataSanitizer();
        $result = $sanitizer->sanitize($data);

        $this->assertArrayHasKey('password_hash', $result);
        $this->assertEquals('keep_this', $result['password_hash']);
    }

    #[Test]
    public function it_handles_deeply_nested_structures(): void
    {
        $data = [
            'level1' => [
                'level2' => [
                    'level3' => [
                        'password_hash' => 'should_be_removed',
                        'safe_data' => 'keep_this',
                    ],
                ],
            ],
        ];

        $sanitizer = new DataSanitizer();
        $result = $sanitizer->sanitize($data);

        $this->assertArrayNotHasKey('password_hash',
            $result['level1']['level2']['level3']);
        $this->assertEquals('keep_this',
            $result['level1']['level2']['level3']['safe_data']);
    }

    #[Test]
    public function it_removes_empty_parent_keys(): void
    {
        $data = [
            'name' => 'John',
            'metadata' => [
                'password_hash' => 'only_content',
            ],
        ];

        $sanitizer = new DataSanitizer();
        $result = $sanitizer->sanitize($data);

        // metadata should be removed entirely since it becomes empty
        $this->assertArrayNotHasKey('metadata', $result);
        $this->assertArrayHasKey('name', $result);
    }

    #[Test]
    public function it_handles_arrays_of_objects(): void
    {
        $data = [
            'users' => [
                ['id' => 1, 'password_hash' => 'remove'],
                ['id' => 2, 'password_hash' => 'remove'],
            ],
        ];

        $sanitizer = new DataSanitizer();
        $result = $sanitizer->sanitize($data);

        $this->assertCount(2, $result['users']);
        $this->assertArrayNotHasKey('password_hash', $result['users'][0]);
        $this->assertArrayNotHasKey('password_hash', $result['users'][1]);
    }
}

Generic Implementation

Here's a reusable class you can drop into any Laravel project:


 declare(strict_types=1);

namespace App\Services;

final class DataSanitizer
{
    /**
     * Remove sensitive keys from nested data structures
     *
     * @param array $data
     * @param string|array $keysToRemove
     * @return array
     */
    public function sanitize(
        array $data,
        string|array $keysToRemove = 'password_hash'
    ): array {
        $keys = is_array($keysToRemove) ? $keysToRemove : [$keysToRemove];

        $result = $data;
        foreach ($keys as $key) {
            $result = $this->removeNestedKey($result, $key, isRoot: true);
        }

        return $result;
    }

    /**
     * Recursively remove a key from nested arrays
     */
    private function removeNestedKey(
        array $data,
        string $keyToRemove,
        bool $isRoot
    ): array {
        $result = [];

        foreach ($data as $key => $value) {
            if ($key === $keyToRemove && !$isRoot) {
                continue;
            }

            if (is_array($value)) {
                $processed = $this->removeNestedKey(
                    $value,
                    $keyToRemove,
                    isRoot: false
                );

                if (!empty($processed)) {
                    $result[$key] = $processed;
                }
            } else {
                $result[$key] = $value;
            }
        }

        return $result;
    }
}

Bonus: Elixir Implementation

If you're curious how this pattern translates to functional languages, here's the Elixir equivalent:

defmodule DataSanitizer do
  @doc """
  Remove sensitive keys from nested data structures
  """
  def sanitize(data, key_to_remove \\ "password_hash") do
    remove_nested_key(data, key_to_remove, true)
  end

  # Root level map - preserve the key
  defp remove_nested_key(data, key_to_remove, true) when is_map(data) do
    for {k, v} <- data, into: %{} do
      {k, remove_nested_key(v, key_to_remove, false)}
    end
    |> remove_empty_maps()
  end

  # Nested map - remove the key if found
  defp remove_nested_key(data, key_to_remove, false) when is_map(data) do
    data
    |> Map.reject(fn {k, _v} -> k == key_to_remove end)
    |> Enum.map(fn {k, v} -> {k, remove_nested_key(v, key_to_remove, false)} end)
    |> Enum.into(%{})
    |> remove_empty_maps()
  end

  # List - recursively process each element
  defp remove_nested_key(data, key_to_remove, _is_root) when is_list(data) do
    Enum.map(data, &remove_nested_key(&1, key_to_remove, false))
  end

  # Primitive value - pass through
  defp remove_nested_key(data, _key_to_remove, _is_root), do: data

  defp remove_empty_maps(map) when is_map(map) do
    map
    |> Enum.reject(fn {_k, v} -> is_map(v) and map_size(v) == 0 end)
    |> Enum.into(%{})
  end
end

Key Takeaways

Think about complexity - Just because Laravel provides a helper doesn't mean it's the most efficient for your use case
Measure real-world performance - Test with realistic data sizes
Recursive solutions are often more efficient than flatten-filter-rebuild patterns
Write comprehensive tests - Edge cases matter, especially with nested data
Make it reusable - Generic implementations pay dividends across projects

When to Use Each Approach

Use Arr::dot() / Arr::undot() when:

Working with small datasets (< 100 elements)
Code clarity is more important than performance
One-off operations in migrations or seeders

Use recursive approach when:

Processing large nested structures
Operation runs frequently (API responses, event processing)
Performance matters (real-time systems, high-traffic APIs)

#pattern #laravel #php #elixir

🐥 Cumulative monthly growth queries in MySQL, PostgreSQL, and Phoenix Ecto

2026-02-22T18:00:00Z

When reporting growth over time, grouping by month alone is usually not enough. For charts and dashboards you typically want:

Missing months to appear explicitly with a count of 0
A cumulative total to show growth over time

Below are idiomatic solutions for MySQL, PostgreSQL, and Phoenix Ecto.

MySQL 8+

MySQL does not have a built-in series generator, so we use a recursive CTE.

WITH RECURSIVE months AS (
  SELECT DATE_FORMAT(MIN(created_at), '%Y-%m-01') AS month
  FROM your_table

  UNION ALL

  SELECT DATE_ADD(month, INTERVAL 1 MONTH)
  FROM months
  WHERE month < DATE_FORMAT(CURDATE(), '%Y-%m-01')
),
monthly_counts AS (
  SELECT
    DATE_FORMAT(created_at, '%Y-%m-01') AS month,
    COUNT(*) AS monthly_count
  FROM your_table
  GROUP BY month
)
SELECT
  m.month,
  COALESCE(mc.monthly_count, 0) AS monthly_count,
  SUM(COALESCE(mc.monthly_count, 0))
    OVER (ORDER BY m.month) AS cumulative_count
FROM months m
LEFT JOIN monthly_counts mc USING (month)
ORDER BY m.month;

Notes

Requires MySQL 8.0+
Recursive CTE generates missing months
Window function calculates the running total

PostgreSQL

PostgreSQL provides generate_series, which makes this much simpler.

WITH months AS (
  SELECT generate_series(
    date_trunc('month', MIN(created_at)),
    date_trunc('month', CURRENT_DATE),
    interval '1 month'
  )::date AS month
  FROM your_table
),
monthly_counts AS (
  SELECT
    date_trunc('month', created_at)::date AS month,
    COUNT(*) AS monthly_count
  FROM your_table
  GROUP BY month
)
SELECT
  m.month,
  COALESCE(mc.monthly_count, 0) AS monthly_count,
  SUM(COALESCE(mc.monthly_count, 0))
    OVER (ORDER BY m.month) AS cumulative_count
FROM months m
LEFT JOIN monthly_counts mc USING (month)
ORDER BY m.month;

Notes

generate_series replaces the recursive CTE
date_trunc('month', ...) is the idiomatic grouping method

Phoenix Ecto (PostgreSQL)

Ecto does not have a native abstraction for time series generation, but PostgreSQL’s strengths can still be used via fragment/1.

Example schema

Assume a schema with a created_at timestamp:

schema "items" do
  timestamps()
end

Monthly counts with missing months and cumulative total

query =
  from m in fragment("""
    SELECT generate_series(
      date_trunc('month', (SELECT MIN(created_at) FROM items)),
      date_trunc('month', CURRENT_DATE),
      interval '1 month'
    )::date AS month
  """),
  left_join: c in fragment("""
    SELECT
      date_trunc('month', created_at)::date AS month,
      COUNT(*) AS monthly_count
    FROM items
    GROUP BY 1
  """),
  on: fragment("? = ?", m.month, c.month),
  select: %{
    month: m.month,
    monthly_count: coalesce(c.monthly_count, 0),
    cumulative_count:
      fragment(
        "SUM(COALESCE(?, 0)) OVER (ORDER BY ?)",
        c.monthly_count,
        m.month
      )
  },
  order_by: m.month

Repo.all(query)

Notes for Ecto

Uses PostgreSQL-specific SQL via fragment/1
Keeps the time series generation in the database
Returns a clean structure ready for charts or LiveView updates

Summary

Across MySQL, PostgreSQL, and Phoenix Ecto, the core idea is the same:

Generate a complete month series
Aggregate real data per month
Left join and fill missing values with zero
Use a window function for cumulative growth

Once you have this pattern in place, producing accurate growth charts becomes straightforward and reliable.

#database #elixir #phoenix #postgresql #mysql #sql

🐥 Working with date ranges in Elixir: a practical guide

2026-02-15T18:00:00Z

When building applications, you often need to iterate over a range of dates—whether it's for generating reports, scheduling tasks, or processing time-series data. If you're coming from languages like PHP or Ruby, you might reach for external libraries. In Elixir, the solution is elegantly built into the standard library.

The basics: `Date.range/2`

Elixir provides Date.range/2 out of the box, which creates an enumerable range of dates. Here's the simplest example:

start_date = ~D[2026-01-26]
end_date = ~D[2026-02-08]

dates = Date.range(start_date, end_date) |> Enum.to_list()
# => [~D[2026-01-26], ~D[2026-01-27], ..., ~D[2026-02-08]]

The ~D sigil creates a Date struct at compile time, making it both performant and type-safe.

Iterating over dates

Since Date.range/2 returns an enumerable, you can use all your favourite Enum functions:

Date.range(start_date, end_date)
|> Enum.each(fn date ->
  IO.puts("Processing #{date}")
  # Your business logic here
end)

This lazy evaluation means you're not creating a massive list in memory—Elixir generates each date as needed.

Practical use case: Phoenix mix task

Here's how you might use this in a real Phoenix application, perhaps for a scheduled job that needs to backfill data:

defmodule MyApp.Mix.Tasks.BackfillReports do
  use Mix.Task

  @shortdoc "Backfill reports for a date range"
  def run(_args) do
    Mix.Task.run("app.start")

    ~D[2026-01-01]
    |> Date.range(~D[2026-01-31])
    |> Enum.each(fn date ->
      MyApp.Reports.generate_daily_report(date)
      IO.puts("✓ Generated report for #{date}")
    end)
  end
end

Advanced patterns

Stepping through dates

Need every other day? Or every week? Just add a step parameter:

# Every 7 days (weekly)
Date.range(start_date, end_date, 7)
|> Enum.to_list()

# Backwards iteration
Date.range(end_date, start_date, -1)
|> Enum.to_list()

Filtering weekdays

Want to process only business days? Chain with Enum.filter/2:

Date.range(start_date, end_date)
|> Enum.filter(fn date ->
  Date.day_of_week(date) in 1..5  # Monday = 1, Sunday = 7
end)
|> Enum.each(&process_business_day/1)

Parsing from user input

When working with dynamic dates from APIs or user input:

with {:ok, start_date} <- Date.from_iso8601("2026-01-26"),
      {:ok, end_date} <- Date.from_iso8601("2026-02-08") do
  Date.range(start_date, end_date)
  |> Enum.to_list()
else
  {:error, _} -> {:error, "Invalid date format"}
end

Performance considerations

One of the beautiful things about Date.range/2 is its lazy evaluation. When you write:

Date.range(~D[2020-01-01], ~D[2026-12-31])
|> Enum.take(10)

Elixir only generates the first 10 dates, not all ~2500 dates in the range. This makes it memory-efficient even for large ranges.

Comparison with Other Languages

Coming from PHP/Laravel? This is your CarbonPeriod:


$period = CarbonPeriod::create($start, $end);

This translates to Elixir as:

period = Date.range(start_date, end_date)

From Ruby/Rails? This replaces manual iteration:

(start_date..end_date).each { |date| ... }

In Elixir, this is essentially the same:

Date.range(start_date, end_date)
|> Enum.each(fn date -> ... end)

Conclusion

Elixir's standard library provides powerful, memory-efficient date range functionality without needing external dependencies. The combination of Date.range/2 and the Enum module gives you all the tools you need for date manipulation in a functional, composable way.

Next time you need to iterate over dates in your Phoenix app, remember: it's just Date.range/2 away.

#laravel #php #tools #elixir #phoenix

🐥 Checking whether an IP address is internal

2026-02-08T18:00:00Z

When building SaaS applications, it is common to treat internal (private or reserved) IP addresses differently from public ones. Typical examples are rate limiting, audit logging, or skipping geo-IP lookups for localhost traffic.

This post shows how to check whether an IP address is internal, starting from an Elixir example and then translating the same idea to PHP.

The Elixir way

In Elixir, the standard library provides :inet.parse_address/1 to validate IP addresses. From there, you can pattern match on the octets to exclude private and reserved ranges.

defmodule IPUtils do
  def public_ipv4?(ip) when is_binary(ip) do
    case :inet.parse_address(String.to_charlist(ip)) do
      {:ok, {a, b, _c, _d}} ->
        not private_or_reserved?(a, b)

      _ ->
        false
    end
  end

  defp private_or_reserved?(10, _), do: true
  defp private_or_reserved?(127, _), do: true
  defp private_or_reserved?(192, 168), do: true
  defp private_or_reserved?(172, b) when b >= 16 and b <= 31, do: true
  defp private_or_reserved?(_, _), do: false
end

IPUtils.public_ipv4?("127.0.0.1") # false
IPUtils.public_ipv4?("8.8.8.8")   # true

Pattern matching keeps the intent clear and makes it easy to extend this logic later if you want to support IPv6 or additional ranges.

The PHP approach

PHP ships with a very convenient helper: filter_var. Combined with the right flags, it allows you to validate only public IPv4 addresses.


$user_ip = '127.0.0.1';

$is_public = filter_var($user_ip, FILTER_VALIDATE_IP, FILTER_FLAG_IPV4 | FILTER_FLAG_NO_PRIV_RANGE | FILTER_FLAG_NO_RES_RANGE);

if ($is_public === false) {
    // Internal, private, or reserved IP
} else {
    // Public IPv4 address
}

What this does:

FILTER_VALIDATE_IP checks that the value is a valid IP address.
FILTER_FLAG_IPV4 restricts the check to IPv4.
FILTER_FLAG_NO_PRIV_RANGE excludes private ranges such as 10.0.0.0/8 and 192.168.0.0/16.
FILTER_FLAG_NO_RES_RANGE excludes reserved ranges like 127.0.0.0/8.

If the function returns false, the IP is either invalid or internal/reserved.

Closing thoughts

PHP’s filter_var is hard to beat for conciseness, but the same idea translates cleanly to other ecosystems:

Validate the IP address first.
Explicitly exclude private and reserved ranges.
Treat everything else as public.

Keeping this logic centralized (for example in a small utility module) helps ensure consistent behavior across your application, regardless of the language you are using.

#pattern #php #logging #elixir

🐥 Using pdftoppm from Elixir to convert PDF files to images

2026-02-01T18:00:00Z

When you need to convert PDF files to images on a Linux server, pdftoppm (from the Poppler utilities) is a fast and reliable tool. In this post, we’ll look at how to invoke pdftoppm from Elixir and how to run multiple conversions in parallel to improve throughput.

Installing pdftoppm

On most Linux distributions, pdftoppm is part of the poppler-utils package, on macOS, it's simply poppler.

# Debian / Ubuntu
sudo apt install poppler-utils

# Alpine
apk add poppler-utils

# macOS
brew install poppler

You can verify the installation with:

pdftoppm -h

Basic pdftoppm usage

To convert a PDF to JPEG images at 150 DPI:

pdftoppm -jpeg -r 150 input.pdf output/page

This produces files like:

output/page-1.jpg
output/page-2.jpg

Each page becomes a separate image.

Writing image data to stdout with pdftoppm

In some setups it is useful to avoid temporary files and let pdftoppm write the rendered image directly to stdout. From Elixir, you can then capture that output and persist it yourself. This post shows how to do this cleanly, while keeping stdout and stderr separated so errors are easy to handle.

pdftoppm writes images to files by default, but if you don't pass the PPM-file-prefix it will write the image data to stdout.

To render a single page as JPEG to stdout:

pdftoppm -jpeg -r 150 -f 1 -l 1 -jpegopt quality=85 -aa yes -aaVector yes input.pdf

On success:

stdout contains the binary JPEG data
stderr is empty

On failure:

stdout is empty
stderr contains the error message

This makes it a good fit for piping and programmatic use.

Why `System.cmd/3` is not enough

System.cmd/3 can redirect stderr to stdout, but it cannot capture them separately. Since we explicitly want:

image data from stdout
error messages from stderr

we need to use a Port.

Converting a single page from Elixir

The function below renders a single page to JPEG, saves the image to disk, and returns structured errors when something goes wrong.

defmodule PdfToImage do
  def convert_page(pdf_path, page, output_file, opts \\ []) do
    dpi = Keyword.get(opts, :dpi, 150)

    args = [
      "pdftoppm",
      "-jpeg",
      "-jpegopt", "quality=85",
      "-aa", "yes",
      "-aaVector", "yes",
      "-r", to_string(dpi),
      "-f", to_string(page),
      "-l", to_string(page),
      pdf_path
    ]

    port =
      Port.open(
        {:spawn_executable, System.find_executable("pdftoppm")},
        [:binary, :exit_status, args: tl(args)]
      )

    collect_output(port, output_file, <<>>, <<>>)
  end

  defp collect_output(port, output_file, stdout, stderr) do
    receive do
      {^port, {:data, data}} ->
        collect_output(port, output_file, stdout <> data, stderr)

      {^port, {:exit_status, 0}} ->
        File.write!(output_file, stdout)
        :ok

      {^port, {:exit_status, status}} ->
        {:error, {status, stderr}}
    after
      30_000 ->
        Port.close(port)
        {:error, :timeout}
    end
  end
end

Usage:

PdfToImage.convert_page(
  "input.pdf",
  1,
  "output/page-1.jpg",
  dpi: 200
)

Parallelizing page conversion

Because each page conversion is independent, this approach works well with Task.async_stream/3.

pages = 1..10

Task.async_stream(
  pages,
  fn page ->
    PdfToImage.convert_page(
      "input.pdf",
      page,
      "output/page-#{page}.jpg"
    )
  end,
  max_concurrency: System.schedulers_online(),
  timeout: :infinity
)
|> Enum.to_list()

Each task spawns its own pdftoppm process, captures binary image data from stdout, and only writes a file once rendering succeeds.

Error handling characteristics

On success, only stdout is used and written to disk
On failure, no file is created
The returned error contains the full stderr output from pdftoppm
This makes it suitable for background jobs and structured logging

Conclusion

By letting pdftoppm write image data to stdout and capturing it via a Port, you gain full control over I/O, error handling, and parallel execution. This avoids temporary files, keeps failure cases clean, and integrates well with Elixir’s concurrency primitives.

#pdf #tools #elixir #linux

🐥 Extracting unique IDs from JSON arrays in MySQL

2026-01-20T18:00:00Z

When working with MySQL, it’s common to store arrays of IDs as JSON inside a column. For example, you might have a table that caches data and keeps a list of related IDs in a JSON column. Over time, you might want to extract a unique list of all these IDs across the table.

Consider a generic table like this:

CREATE TABLE `example_cache` (
  `id` BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
  `entity_id` BIGINT UNSIGNED NOT NULL,
  `cache_key` VARCHAR(191) NOT NULL,
  `related_ids` JSON DEFAULT NULL,
  `created_at` TIMESTAMP NULL DEFAULT NULL,
  `updated_at` TIMESTAMP NULL DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `example_cache_entity_id_cache_key_unique` (`entity_id`, `cache_key`),
  KEY `example_cache_entity_id_index` (`entity_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

Here, the related_ids column contains arrays of IDs:

[101, 102, 103, 104, 105]

In MySQL 8.0+, the cleanest way to get a unique list of IDs is to use JSON_TABLE with DISTINCT:

SELECT DISTINCT jt.related_id
FROM example_cache ec
JOIN JSON_TABLE(
  ec.related_ids,
  '$[*]' COLUMNS (
    related_id BIGINT PATH '$'
  )
) AS jt
WHERE ec.related_ids IS NOT NULL;

How it works

JSON_TABLE(... '$[*]') converts each JSON array into individual rows. Each element becomes a row in the virtual table jt.
DISTINCT ensures duplicate IDs across multiple rows are removed.
WHERE ec.related_ids IS NOT NULL filters out rows without any IDs.

If you want unique IDs for a specific entity:

SELECT DISTINCT jt.related_id
FROM example_cache ec
JOIN JSON_TABLE(
  ec.related_ids,
  '$[*]' COLUMNS (
    related_id BIGINT PATH '$'
  )
) AS jt
WHERE ec.entity_id = 42
  AND ec.related_ids IS NOT NULL;

You can also aggregate the results back into a single JSON array:

SELECT JSON_ARRAYAGG(DISTINCT jt.related_id) AS related_ids
FROM example_cache ec
JOIN JSON_TABLE(
  ec.related_ids,
  '$[*]' COLUMNS (
    related_id BIGINT PATH '$'
  )
) AS jt
WHERE ec.related_ids IS NOT NULL;

Considerations

This approach requires MySQL 8.0.4+.
If your related_ids arrays grow large, consider normalizing them into a separate join table. Querying and indexing will be more efficient than querying JSON.
JSON_TABLE provides a clean way to explode arrays without relying on string manipulation.

This method is a practical and idiomatic way to extract and deduplicate JSON array elements in MySQL.

#database #mysql #sql

🐥 Creating relative URLs from absolute URLs in Elixir

2026-01-15T18:00:00Z

When working with redirects, internal links, or LiveView navigation, you often want to turn an absolute URL into a relative one. Given a URL like:

https://example.com/some/path?page=2#section

the goal is to end up with:

/some/path?page=2#section

The non-idiomatic approach

A common first attempt is to manually concatenate path, query, and fragment after parsing the URL. While this works, it pushes URL semantics into string logic and is easy to get wrong.

Elixir’s standard library gives us a cleaner option.

The idiomatic solution using `URI`

The URI module is designed so that parsing and serialization are inverse operations. The trick is to parse the URL, drop the parts you don’t need, and convert it back to a string.

url = "https://example.com/some/path?page=2#section"

relative =
  url
  |> URI.parse()
  |> Map.take([:path, :query, :fragment])
  |> then(&struct(URI, &1))
  |> URI.to_string()

This produces:

"/some/path?page=2#section"

Why this approach works well

No manual handling of ? or #
Correct behavior when query or fragment is missing
Clear intent: keep only the parts relevant for a relative URL
Uses only Elixir’s standard library

A small helper function

If you need this in more than one place, wrapping it in a helper keeps your codebase tidy:

def relative_url(url) do
  url
  |> URI.parse()
  |> Map.take([:path, :query, :fragment])
  |> then(&struct(URI, &1))
  |> URI.to_string()
end

This pattern keeps URL handling declarative and avoids brittle string manipulation, which is exactly what the URI module is there for.

#pattern #elixir #phoenix

🐥 Using Tailwind CSS group hover to style child elements

2026-01-08T18:00:00Z

Tailwind CSS provides the group and group-hover utilities to conditionally apply styles to child elements based on the state of a parent. This is especially useful when you want to change the appearance of nested elements when a container is hovered, focused, or active.

In plain CSS, styling a child element based on the hover state of its parent typically requires a selector like this:

.card:hover .card-icon {
  color: red;
}

With utility-first CSS, you want to avoid custom selectors and keep everything inline in your markup.

The `group` utility

Tailwind solves this with the group class. You mark the parent element as a group, and then reference that state from any descendant using group-hover:*.

<div class="group p-4 border rounded">
  <span class="text-gray-400 group-hover:text-red-500">
    Hover me
  span>
div>

When the parent div is hovered, the span receives the text-red-500 class.

The group class itself does not add any styles. It only acts as a named hook that allows child elements to react to the parent’s state. Tailwind expands group-hover:text-red-500 into a CSS selector that targets the child when the parent is hovered.

This keeps your behavior explicit in the markup without writing custom CSS.

Beyond hover

The same pattern works for other state variants:

<div class="group focus-within:border-blue-500">
  <input class="border p-2" />
  <p class="text-sm text-gray-400 group-focus-within:text-blue-500">
    Input is focused
  p>
div>

Commonly used variants include:

group-hover
group-focus
group-focus-within
group-active

Named groups

When you have nested groups, you can give them explicit names to avoid conflicts:

<div class="group/card">
  <h3 class="group-hover/card:underline">
    Card title
  h3>
div>

This makes it clear which parent controls which child styles.

Conclusion

Tailwind’s group utilities let child elements respond to parent state changes without custom CSS. By marking a parent as a group and using group-hover (or related variants) on descendants, you can build rich interactive components while staying within Tailwind’s utility-first approach.

#css #pattern #html

🐥 Sorting case insensitive in SQLite with COLLATE NOCASE

2026-01-06T18:00:00Z

SQLite sorts text using a collation. By default this is case sensitive, which often leads to surprising orderings when data contains mixed casing. SQLite provides a built-in solution for simple use cases: COLLATE NOCASE.

Basic usage

You can apply COLLATE NOCASE directly in an ORDER BY clause:

SELECT name
FROM users
ORDER BY name COLLATE NOCASE;

This sorts Alice, bob, and charlie as you would typically expect, regardless of their original casing.

You can also use it in comparisons:

SELECT *
FROM users
WHERE name = 'pieter' COLLATE NOCASE;

Defining it at column level

If a column is almost always queried case-insensitively, you can define the collation in the schema:

CREATE TABLE users (
  id INTEGER PRIMARY KEY,
  name TEXT COLLATE NOCASE
);

All comparisons and sorting on name will now default to case-insensitive behavior.

Indexes and performance

Indexes are collation-aware in SQLite. If you sort case-insensitively, make sure your index uses the same collation:

CREATE INDEX users_name_nocase_idx
ON users(name COLLATE NOCASE);

Without this, SQLite may ignore the index for ORDER BY name COLLATE NOCASE.

Limitations to be aware of

COLLATE NOCASE is ASCII-only. It handles A–Z and a–z, but does not perform full Unicode case folding. Characters like é or ß are not handled correctly.

If you need proper internationalized sorting, you have a few options:

Normalize and store a secondary, lowercased column
Use ORDER BY LOWER(name) (simple but index-unfriendly)
Compile SQLite with the ICU extension and use ICU collations

When to use it

COLLATE NOCASE is a pragmatic choice when:

Your data is primarily ASCII
You want predictable, simple case-insensitive sorting
You care about index-backed performance

For many applications, it is the right balance between correctness and simplicity.

#database #sql #sqlite

🐥 Be aware of 1Password breaking syntax highlighting

2026-01-05T18:00:00Z

You might have noticed that the syntax highlighting of the code snippets on this site don't always work correctly.

After spending a couple of hours figuring out what happened, it turns out that the culprit is 1Password's browser extension.

Hey everyone! I want to thank everyone who called our attention to this and explain what happened and what we’re doing about it.

What happened: Prism.js is a syntax-highlighting library we use for our Labs Snippets feature. While optimizing our build to reduce bundle size, we unintentionally bundled Prism.js into the extension in a way that caused it to run on pages where it shouldn’t, which interfered with code formatting on certain sites. We apologize for the inconvenience this caused.

What we’re doing about it: We’ve completed the fix and submitted it to the Chrome Web Store, along with Firefox, Edge, and our other supported extension storefronts. Rollout timing depends on each store’s review process, but we expect it to land over the next few days.

We want to emphasize that vault security was not impacted. At 1Password, protecting our customers’ privacy, passwords, and credentials is our highest priority.

We’ll be publishing a postmortem covering what went wrong, the timeline, and the concrete changes we’re making to how we build and release future browser extension updates.

source

In the meantime, the problem is fixed on their end and an updated browser extension should be available shortly. However, there is no indication on which version actually contains the fix.

#html

🐥 Adding a second CSS and JS bundle to a Phoenix application

2025-12-31T18:00:00Z

Phoenix ships with a single asset pipeline by default, but real-world applications often need more. An admin area or backoffice is a common case where separate CSS and JS bundles keep concerns isolated. This post shows how to add a second bundle, including Tailwind configuration and dev-time watchers.

Default Phoenix asset setup recap

A standard Phoenix app includes:

assets/js/app.js
assets/css/app.css
Tailwind and esbuild wired via config/config.exs
Dev watchers for live rebuilding
A single layout loading app.css and app.js

We’ll extend this setup without affecting the default bundle.

Adding a second JavaScript entry point

Create a new JS entry:

assets/js/admin.js

console.log("Admin bundle loaded");

This becomes the root of the admin bundle.

Adding a second CSS entry point

Create a new stylesheet:

assets/css/admin.css

For Tailwind:

@tailwind base;
@tailwind components;
@tailwind utilities;

This allows full Tailwind usage without leaking styles into the main app.

Updating Tailwind build configuration

Open config/config.exs and extend the :tailwind config:

config :tailwind,
  version: "4.1.16",
  default: [
    args: ~w(
      --input=css/app.css
      --output=../priv/static/assets/app.css
    ),
    cd: Path.expand("..", __DIR__)
  ],
  admin: [
    args: ~w(
      --input=css/admin.css
      --output=../priv/static/assets/admin.css
    ),
    cd: Path.expand("..", __DIR__)
  ]

You now have two independent Tailwind builds.

Updating esbuild configuration

Still in config/config.exs, add a second esbuild profile:

config :esbuild,
  version: "0.25.11",
  default: [
    args:
      ~w(js/app.js --bundle --target=es2022 --outdir=../priv/static/assets --external:/fonts/* --external:/images/* --alias:@=.),
    cd: Path.expand("../assets", __DIR__),
    env: %{"NODE_PATH" => [Path.expand("../deps", __DIR__), Mix.Project.build_path()]}
  ],
  admin: [
    args:
      ~w(js/admin.js --bundle --target=es2022 --outdir=../priv/static/assets --external:/fonts/* --external:/images/* --alias:@=.),
    cd: Path.expand("../assets", __DIR__),
    env: %{"NODE_PATH" => [Path.expand("../deps", __DIR__), Mix.Project.build_path()]}
  ]

Wiring both bundles into Mix aliases

Ensure both Tailwind and esbuild profiles run during deployment by editing mix.exs:

defp aliases do
  [
    "assets.deploy": [
      "tailwind default --minify",
      "tailwind admin --minify",
      "esbuild default --minify",
      "esbuild admin --minify",
      "phx.digest"
    ]
  ]
end

Adding dev watchers

Without watchers, the second bundle won’t rebuild in development. Update config/dev.exs:

config :my_app, MyAppWeb.Endpoint,
  watchers: [
    esbuild: {Esbuild, :install_and_run, [:default, ~w(--sourcemap=inline --watch)]},
    esbuild_admin: {Esbuild, :install_and_run, [:admin, ~w(--sourcemap=inline --watch)]},
    tailwind: {Tailwind, :install_and_run, [:default, ~w(--watch)]},
    tailwind_admin: {Tailwind, :install_and_run, [:admin, ~w(--watch)]}
  ]

Each watcher maps cleanly to a build profile.

Referencing the admin assets in a layout

Include the admin bundle:

<link phx-track-static rel="stylesheet" href={~p"/assets/admin.css"} />
<script defer phx-track-static type="text/javascript" src={~p"/assets/admin.js"}>script>

Why this setup works well

Tailwind scanning stays fast and precise
Admin styles and JS are fully isolated
Dev experience remains identical to the default setup
Adding a third bundle follows the same pattern

This approach fits naturally into Phoenix’s asset pipeline while keeping growth manageable.

#javascript #css #elixir #phoenix #html

🐥 Validating webhook signatures in Phoenix

2025-12-30T18:00:00Z

When exposing a webhook endpoint, signature validation is essential. It ensures that incoming requests actually originate from the expected provider and that the payload has not been tampered with in transit.

Phoenix provides all the building blocks needed to implement this cleanly and generically, without coupling your code to a specific webhook provider.

This post shows a reusable pattern you can adapt to any HMAC-signed webhook.

The general webhook signature pattern

Most webhook providers follow a similar approach:

They send a signature in a request header
The signature is an HMAC of the raw request body
A shared secret is used as the HMAC key
The receiver must recompute the signature and compare it securely

While header names and algorithms may differ, the structure remains the same.

Capturing the raw request body

Signature verification requires access to the raw request body, before JSON decoding occurs. Phoenix parses the body eagerly, so you need to explicitly capture it.

Configure a custom body reader in your endpoint.

# endpoint.ex
plug Plug.Parsers,
  parsers: [:json],
  pass: ["application/json"],
  json_decoder: Jason,
  body_reader: {MyAppWeb.BodyReader, :cache_raw_body, []}

defmodule MyAppWeb.BodyReader do
  def cache_raw_body(conn, opts) do
    {:ok, body, conn} = Plug.Conn.read_body(conn, opts)
    conn = Plug.Conn.assign(conn, :raw_body, body)
    {:ok, body, conn}
  end
end

The raw payload is now available as conn.assigns[:raw_body] for later validation.

A generic signature validation plug

Instead of hardcoding provider-specific details, you can write a reusable plug that accepts configuration options such as:

Header name
Hash algorithm
Shared secret
Optional encoding or prefix handling

Below is a minimal but flexible implementation for HMAC-based signatures.

defmodule MyAppWeb.Plugs.WebhookSignature do
  import Plug.Conn

  def init(opts) do
    %{
      header: Keyword.fetch!(opts, :header),
      secret: Keyword.fetch!(opts, :secret),
      algorithm: Keyword.get(opts, :algorithm, :sha256)
    }
  end

  def call(conn, %{header: header} = opts) do
    with [signature] <- get_req_header(conn, header),
         raw_body when is_binary(raw_body) <- conn.assigns[:raw_body],
         true <- valid_signature?(raw_body, signature, opts) do
      conn
    else
      _ ->
        conn
        |> send_resp(:unauthorized, "Invalid signature")
        |> halt()
    end
  end

  defp valid_signature?(payload, signature, %{secret: secret, algorithm: algorithm}) do
    expected =
      :crypto.mac(:hmac, algorithm, secret, payload)
      |> Base.encode16(case: :lower)

    Plug.Crypto.secure_compare(expected, signature)
  end
end

This plug makes no assumptions about the webhook provider beyond the use of an HMAC.

Applying the plug per webhook endpoint

Different webhook providers can now be configured independently at the router level.

# router.ex
pipeline :webhook_provider_a do
  plug MyAppWeb.Plugs.WebhookSignature,
    header: "x-webhook-signature",
    secret: Application.fetch_env!(:my_app, :provider_a)[:secret]
end

pipeline :webhook_provider_b do
  plug MyAppWeb.Plugs.WebhookSignature,
    header: "x-signature",
    secret: Application.fetch_env!(:my_app, :provider_b)[:secret],
    algorithm: :sha512
end

scope "/webhooks", MyAppWeb do
  pipe_through [:api, :webhook_provider_a]
  post "/provider-a", ProviderAController, :create
end

This keeps validation close to routing and avoids leaking security concerns into controllers.

Keeping controllers focused

With signature validation handled by a plug, controllers can assume authenticity and focus purely on business logic.

def create(conn, params) do
  json(conn, %{status: "ok"})
end

Common pitfalls

Validating against parsed JSON instead of the raw request body
Comparing signatures without a constant-time function
Hardcoding secrets instead of injecting them via configuration
Applying the plug after the request body has already been consumed

Conclusion

Webhook signature validation is a cross-cutting concern that fits naturally into Phoenix plugs. By capturing the raw request body and using a configurable, generic validation plug, you can support multiple webhook providers with minimal duplication while keeping your controllers clean and secure.

#pattern #http #elixir #phoenix

🐥 Using the lockf command on Linux and macOS

2025-12-29T18:00:00Z

The lockf command is a small but useful Unix utility for applying advisory file locks from the shell. It is commonly used in scripts to prevent multiple instances of a process from running at the same time.

What `lockf` does

lockf applies a POSIX advisory lock on an open file descriptor. As long as the process holds the lock, other processes attempting to acquire a conflicting lock will either block or fail, depending on how lockf is invoked.

This is most often used for:

Preventing concurrent cron jobs
Serializing access to shared resources
Implementing simple process-level mutexes in shell scripts

The locking is advisory, meaning all cooperating processes must also use locking for it to be effective.

Basic usage

The most common pattern is wrapping a command:

lockf /var/lock/myjob.lock my_command

This:

Opens (and creates if needed) the lock file
Acquires an exclusive lock
Executes my_command
Releases the lock when the command exits

Non-blocking locks

To fail immediately if the lock is already held, use -n:

lockf -n /var/lock/myjob.lock my_command || exit 0

This is ideal for cron jobs where you want to skip execution if another instance is still running.

Timeout-based locking

On Linux, you can specify a timeout with -t:

lockf -t 10 /var/lock/myjob.lock my_command

This waits up to 10 seconds to acquire the lock before failing.

Note: this option is not available on macOS.

Exit codes

lockf uses meaningful exit codes:

0: command executed successfully
1: invalid arguments or usage error
2: lock acquisition failed (for example with -n)

This makes it easy to integrate into scripts with conditional logic.

Differences between Linux and macOS

While the core behavior is similar, there are a few differences worth knowing:

Implementation
- Linux: typically part of util-linux
- macOS: BSD-derived implementation
Options
- Linux supports -t (timeout)
- macOS does not support timeouts
Lock semantics
- Both use advisory locks backed by fcntl
- Locks are released automatically when the process exits or the file descriptor is closed

For portable scripts, avoid Linux-only options like -t.

Common pattern for scripts

A widely used idiom looks like this:

#!/bin/sh
lockfile="/tmp/myjob.lock"

lockf -n "$lockfile" sh -c '
  echo "Running job"
  sleep 30
'

This ensures only one instance of the script runs at a time, regardless of how often it is triggered.

When not to use `lockf`

lockf is not suitable when:

You need mandatory locking
Locks must survive process crashes or reboots
Coordination is required across NFS in unreliable setups

In those cases, higher-level coordination mechanisms or external systems are a better fit.

Summary

lockf is a simple and effective tool for process synchronization in shell scripts. When used carefully, it provides a clean solution to avoid concurrent execution on both Linux and macOS, with only minor portability considerations.

#tools #terminal #linux #mac

🐥 TIL: Removing old PHP versions after an upgrade

2025-12-23T18:00:00Z

After upgrading PHP on a Debian or Ubuntu system, it’s a good idea to clean up old PHP versions once you’ve confirmed the new installation works correctly. This helps reduce clutter and avoids accidentally running outdated binaries or services.

You can remove all packages belonging to a specific PHP version using apt purge with a wildcard:

sudo apt purge '^php8.3.*'

This command purges all installed PHP 8.3 packages, including configuration files. Adjust the version number to match the PHP release you want to remove.

As a final step, you may want to run:

sudo apt autoremove

to clean up any remaining unused dependencies.

#php #terminal #linux

🐥 YellowDuck.be

🐥 Installing Claude Code on macOS with Homebrew (and getting the latest version)

Install the latest version

Fix an existing installation

Why this matters

More context

Takeaway

🐥 Taming scrollbars in a Phoenix app

The problem

The solution

Why this feels better

Browser support

🐥 A better way: Using mkcert for HTTPS in Phoenix on macOS

What makes mkcert different?

Step 1: Install mkcert and register the local CA

Step 2: Generate a certificate for localhost

Step 3: Configure Phoenix for HTTPS

What about the cert files in version control?

Upgrading from the old approach

🐥 Fixing a race condition in Oban job counting with telemetry

The Setup

The Bug

The Fix: Oban Telemetry

Why This Works

Takeaway

🐥 TIL: filtering GitHub PRs that are ready for review and not yours

What this does

Bonus: explore more filters

🐥 Enforcing polymorphic integrity in PostgreSQL with num_nonnulls

The num_nonnulls function

Why this is better than application-level checks

Variations

When to use this pattern

Conclusion

🐥 Request validation in Phoenix: the Laravel FormRequest approach

Validation with Ecto changesets

Writing custom validation rules

Field-level custom validation

Reusable validation helpers

Cross-field validation

Database-backed validation

Key building blocks

Comparing Laravel and Phoenix validation

Conclusion

🐥 Making Oban workers reusable with job arguments

The Problem: One Worker, One Purpose

The Fix: Pass Configuration as Job Args

Using It for Scheduled Jobs

Inserting One-Off Jobs

Why This Matters

When to Keep Workers Specific

🐥 Understanding Agent, GenServer, Task, and ETS in Elixir

Agent: a simple state container

GenServer: a full OTP server abstraction

Why many developers skip Agent

Business logic leaks outside the process

Limited extensibility

Task: concurrency for short-lived work

ETS: extremely fast shared memory

A common GenServer anti-pattern

Better approach

Choosing the right abstraction

Conclusion

🐥 Monitoring the progress of creating an index in PostgreSQL

The pg_stat_progress_create_index view

Example output explained

phase

blocks_total and blocks_done

tuples_total and tuples_done

Monitoring concurrent index builds

Calculating progress percentage

When progress appears frozen

Estimating total duration

Version requirement

Practical workflow

Final thoughts

🐥 Why prefer const arrow functions over function declarations in TypeScript?

Predictable execution order

Immutability by default

Safer this behavior

The `num_nonnulls` function

The `pg_stat_progress_create_index` view

`phase`

`blocks_total` and `blocks_done`

`tuples_total` and `tuples_done`

Safer `this` behavior

The basics: `Date.range/2`

Why `System.cmd/3` is not enough

The idiomatic solution using `URI`

The `group` utility