🐥 YellowDuck.be

🐥 Why crypto.getRandomValues() matters in JavaScript

2026-06-02T17:00:00Z

Generating random values sounds simple, until you need randomness that is actually secure.

A lot of JavaScript developers reach for Math.random() out of habit. While that works fine for visual effects, games, or non-critical IDs, it should never be used for anything security-sensitive.

That’s where the Web Crypto API comes in.

The problem with `Math.random()`

Math.random() is not cryptographically secure.

Its output is deterministic and predictable enough that an attacker may be able to reproduce or guess generated values under certain conditions.

That makes it unsuitable for:

Session tokens
Password reset links
API keys
CSRF tokens
Encryption keys
Secure identifiers

Example:

const id = Math.random().toString(36).slice(2)

This may look random, but it is not secure.

Using `crypto.getRandomValues()`

Modern browsers provide a secure random number generator through the Web Crypto API.

Example:

const bytes = new Uint8Array(16)

crypto.getRandomValues(bytes)

console.log(bytes)

This fills the typed array with cryptographically secure random bytes provided by the operating system.

Generating a secure random token

A common use case is generating secure tokens or identifiers.

function generateToken(length = 32) {
  const bytes = new Uint8Array(length)

  crypto.getRandomValues(bytes)

  return Array.from(bytes)
    .map(byte => byte.toString(16).padStart(2, "0"))
    .join("")
}

console.log(generateToken())

Example output:

4f8b7d3a1f9e0c8d7a2b6c5d4e3f1a9c

This is significantly safer than using Math.random().

Typed arrays are required

crypto.getRandomValues() only works with integer-based typed arrays.

Supported examples include:

new Uint8Array(32)
new Uint16Array(16)
new Int32Array(8)

This will fail:

crypto.getRandomValues([])

Because regular JavaScript arrays are not supported.

Browser and runtime support

crypto.getRandomValues() is widely supported in modern browsers.

It is also available in runtimes like:

Node.js
Deno
Bun

Example in Node.js:

const bytes = new Uint8Array(16)

crypto.getRandomValues(bytes)

console.log(bytes)

In older Node.js versions, developers typically used:

require("crypto").randomBytes(16)

UUID generation

If your goal is generating UUIDs, modern runtimes also support:

crypto.randomUUID()

Example:

550e8400-e29b-41d4-a716-446655440000

Internally, this also uses cryptographically secure randomness.

Things to remember

Use Math.random() for non-security-related randomness only
Use crypto.getRandomValues() for anything security-sensitive
Prefer crypto.randomUUID() when generating UUIDs
Always generate randomness using the operating system’s secure RNG

For modern JavaScript applications, crypto.getRandomValues() should be the default choice whenever security matters.

#javascript #best-practice #auth

🐥 How to find all Jira issues ever assigned to someone (even historical ones)

2026-05-31T17:00:00Z

If you've ever tried to pull up all the tickets that Sarah Mitchell worked on last year, you've probably started with the obvious query:

assignee = "sarah.mitchell@example.com"

And then realised it only shows her current tickets — not the ones she handed off to Tom Bergkamp or closed six months ago.

Here's the fix.

The `was` operator

Jira's JQL has a was operator that checks the change history of a field, not just its current value. So to find every issue Sarah was ever assigned to:

assignee was "sarah.mitchell@example.com"

Simple, but powerful.

Checking multiple people at once

Need to audit the work of an entire sub-team? Use was in with a list:

assignee was in ("sarah.mitchell@example.com", "tom.bergkamp@example.com", "priya.nair@example.com")

This returns any issue that was assigned to any of those three people at any point in time.

Scoping to a specific year

Combine it with the during clause to limit results to a time window — useful for annual reviews, retrospectives, or handover audits:

assignee was in ("sarah.mitchell@example.com", "tom.bergkamp@example.com") during ("2025-01-01", "2025-12-31")

This only matches issues where one of them was the assignee at some point during 2025 — even if the ticket has since been reassigned or closed.

Putting it all together

A full, practical query might look like this:

project = "PLATFORM"
AND assignee was in ("sarah.mitchell@example.com", "tom.bergkamp@example.com")
AND during ("2025-01-01", "2025-12-31")
ORDER BY updated DESC

The was operator works on other fields too — status was "In Progress", priority was "High", etc. — so it's worth keeping in your JQL toolkit whenever you need to query history rather than current state.

#tools #best-practice

🐥 Downloading external images as squares from a Phoenix app

2026-05-29T17:00:00Z

A common need in admin tools: click a button, download a remote image as a square JPEG. Simple enough — until CORS gets in the way.

The CORS problem

When fetching a cross-origin image and drawing it onto a , the browser marks the canvas as "tainted". The moment you call canvas.toBlob() to read the pixel data back out, it throws a security error. Unless the image server sends explicit CORS headers — which most don't — you can't do canvas operations on cross-origin images.

The fix: a server-side proxy

The solution is to proxy the image through the Phoenix app. From the browser's point of view the image comes from the same origin, so the canvas stays clean.

def image_proxy(conn, %{"url" => url}) do
  with true <- allowed_url?(url),
       {:ok, response} <- Req.get(url) do
    content_type =
      response.headers
      |> Map.get("content-type", ["image/jpeg"])
      |> List.first()
      |> String.split(";")
      |> hd()

    conn
    |> put_resp_content_type(content_type)
    |> send_resp(200, response.body)
  else
    false -> send_resp(conn, 400, "Invalid URL")
    _ -> send_resp(conn, 502, "Failed to fetch image")
  end
end

The allowed_url?/1 function validates the host against a known allowlist — an important SSRF guard so the proxy can't be abused to fetch arbitrary internal URLs.

Center-cropping to a square in the browser

Once the image loads from the proxy, a small Canvas API snippet handles the crop. The logic is straightforward: use the shorter dimension as the square size, then offset into the longer dimension by half the difference to take the center slice.

window.addEventListener("phx:download-square-image", (event) => {
  const { url, filename } = event.detail;
  const proxyUrl = `/image-proxy?url=${encodeURIComponent(url)}`;

  const img = new Image();
  img.onload = () => {
    const size = Math.min(img.naturalWidth, img.naturalHeight);
    const canvas = document.createElement("canvas");
    canvas.width = size;
    canvas.height = size;

    const ctx = canvas.getContext("2d");
    const offsetX = (img.naturalWidth - size) / 2;
    const offsetY = (img.naturalHeight - size) / 2;
    ctx.drawImage(img, offsetX, offsetY, size, size, 0, 0, size, size);

    canvas.toBlob((blob) => {
      const a = document.createElement("a");
      a.href = URL.createObjectURL(blob);
      a.download = filename;
      a.click();
      URL.revokeObjectURL(a.href);
    }, "image/jpeg", 0.95);
  };
  img.src = proxyUrl;
});

For a landscape image the left and right edges are trimmed, keeping the center. For a portrait image the top and bottom are trimmed instead. The full shorter dimension is always preserved — no upscaling, no padding.

Wiring it up in LiveView

The download is triggered from the template using Phoenix's JS.dispatch/2, which fires a custom DOM event with the image URL and filename as detail:

<button
  class="cursor-pointer"
  phx-click={
    JS.dispatch("phx:download-square-image",
      detail: %{url: @image_url, filename: "image.jpg"}
    )
  }
>
  Download
button>

No LiveView round-trip needed — JS.dispatch fires the event directly in the browser, the window listener catches it, and the download happens entirely client-side after the one proxy fetch.

Why `naturalWidth` instead of `width`?

img.width returns the CSS-rendered size, which is meaningless for an image that isn't attached to the DOM. img.naturalWidth always returns the actual pixel dimensions of the image data — the right value to use when doing pixel-level canvas operations.

#javascript #frontend #elixir #phoenix

🐥 The Tailwind `enabled:` selector trick for disabled buttons

2026-05-27T17:00:00Z

When you add a disabled attribute to a

🐥 Hide a layout section from a specific child view in Laravel Blade

2026-05-25T17:00:00Z

Sometimes you have a shared layout that renders a block — a promotional banner, a sidebar widget, an image — that makes sense on most pages but not all. Rather than duplicating the layout or reaching for JavaScript, you can solve this cleanly with two built-in Blade directives: @section and View::hasSection().

The problem

Say your login layout renders a decorative image at the bottom of every page:

{{-- resources/views/layouts/login.blade.php --}}
@php $loginImage = Contractify::loginImage(); @endphp
@if ($loginImage->src)
    
        src }}" alt="{{ $loginImage->alt }}">
    
@endif

This is fine for the login and registration pages, but on the OAuth authorization page it's visual noise you'd rather skip.

The solution

Step 1 — Wrap the block in the layout with @unless(View::hasSection(...)):

{{-- resources/views/layouts/login.blade.php --}}
@unless(View::hasSection('hide-login-image'))
    @php $loginImage = Contractify::loginImage(); @endphp
    @if ($loginImage->src)
        
            src }}" alt="{{ $loginImage->alt }}">
        
    @endif
@endunless

Step 2 — Declare the empty section in the child view that should opt out:

{{-- resources/views/vendor/passport/authorize.blade.php --}}
@extends('layouts.login')

@section('hide-login-image')@endsection

@section('content')
    {{-- ... --}}
@endsection

How it works

View::hasSection('hide-login-image') returns true if the currently-rendering child view has declared a section with that name — even an empty one. The @unless then skips the block entirely.

Every other view that extends the layout leaves that section undeclared, so hasSection returns false and the image renders as normal.

Why this is better than the alternatives

No layout duplication. You keep a single source of truth.
No conditionals based on route names or controller names. Those couple your layout to your routing.
The opt-out lives in the view that needs it. Easy to find, easy to remove.

It's a tiny pattern, but it keeps your layouts clean and your child views in control of their own presentation.

#frontend #laravel #best-practice

🐥 Scanning files with clamdscan and --fdpass

2026-05-23T17:00:00Z

When integrating antivirus scanning into a Linux application or upload pipeline, clamdscan is usually a much better choice than clamscan.

While clamscan starts a full standalone scan process and loads virus signatures every time, clamdscan talks to the long-running clamd daemon. This makes scans significantly faster and more suitable for production environments.

One particularly useful option is --fdpass.

What does --fdpass do?

Normally, clamd runs under its own user account, such as clamav. This can create permission issues when scanning files owned by another user or temporary upload files.

The --fdpass option solves this by passing the already opened file descriptor to the daemon instead of letting the daemon reopen the file itself.

This is especially useful for:

Upload processing
Temporary files
Restricted file permissions
CI/CD pipelines
Web applications

Installing ClamAV

On Debian or Ubuntu systems:

sudo apt update
sudo apt install clamav clamav-daemon

Update the virus definitions:

sudo freshclam

Enabling clamd on startup

To ensure the daemon automatically starts after a reboot:

sudo systemctl enable clamav-daemon
sudo systemctl start clamav-daemon

Verify the service is running:

sudo systemctl status clamav-daemon

On some distributions, the service may be named clamd instead.

Verifying the socket configuration

clamdscan communicates with the daemon through a Unix socket.

Check the configured socket path:

grep LocalSocket /etc/clamav/clamd.conf

Typical values are:

LocalSocket /run/clamav/clamd.ctl

or:

LocalSocket /var/run/clamav/clamd.ctl

You can also locate the socket manually:

sudo find /run /var/run -name "*.ctl"

Scanning a file

To scan a file quietly:

clamdscan --fdpass --quiet myfile.zip

If the file is clean, the command exits with status code 0.

If malware is detected, the exit code becomes 1.

Example in a shell script:

if clamdscan --fdpass --quiet upload.pdf; then
    echo "File is clean"
else
    echo "Virus detected"
fi

Why use clamdscan instead of clamscan?

clamdscan has several advantages:

Much faster scanning
Lower memory usage
Better suited for concurrent workloads
No repeated signature loading
Ideal for web servers and APIs

For applications handling many uploads or background jobs, using clamdscan --fdpass is generally the recommended setup.

Common error

If you encounter:

ERROR: Could not connect to clamd on LocalSocket

the daemon is usually not running.

Start it manually:

sudo systemctl start clamav-daemon

Then retry the scan command.

Understanding exit codes

When integrating clamdscan into an application or upload pipeline, it is important to distinguish between an actual virus detection and a technical failure.

Fortunately, clamdscan provides clear exit codes for this.

Exit code	Meaning
`0`	No virus found
`1`	Virus found
`2`	Scanner error or operational failure

This means you should avoid parsing stdout or stderr to determine the scan result. Instead, rely on the process exit code directly.

Example:

clamdscan --fdpass --quiet upload.pdf
result=$?

case $result in
    0)
        echo "File is clean"
        ;;
    1)
        echo "Virus detected"
        ;;
    2)
        echo "Scan failed"
        ;;
esac

This distinction is especially important in automated systems:

Exit code 1 means the scanner worked correctly and detected malware
Exit code 2 means something operational failed, such as:
- clamd not running
- socket connection failures
- permission issues
- corrupted scanner configuration

In production systems, a virus detection is usually a business-level validation failure, while exit code 2 should typically trigger retries, logging, monitoring, or alerts.

#tools #best-practice #devops #linux #sysadmin

🐥 TypeScript's Pick utility type: select what you need

2026-05-21T17:00:00Z

TypeScript ships with a set of built-in utility types that make working with existing types far more ergonomic. One of the most useful is Pick — a simple but powerful tool for carving out a subset of properties from a larger type.

What Is `Pick`?

Pick constructs a new type by selecting a specific set of properties (Keys) from an existing type (Type). Think of it as a projection: you have a big object shape, and you only want a slice of it.

type Pick<T, K extends keyof T> = {
  [P in K]: T[P];
};

A Practical Example

Suppose you have a User type across your application:

type User = {
  id: number;
  name: string;
  email: string;
  passwordHash: string;
  createdAt: Date;
  role: 'admin' | 'editor' | 'viewer';
};

When building a public-facing API response, you never want to expose passwordHash. And a user profile card in the UI might only care about id, name, and email. Instead of duplicating the shape or manually re-declaring those fields, reach for Pick:

type PublicUser = Pick<User, 'id' | 'name' | 'email'>;

// Equivalent to:
// type PublicUser = {
//   id: number;
//   name: string;
//   email: string;
// };

Now PublicUser stays in sync with User automatically. If you rename name to fullName on User, TypeScript will immediately flag any Pick references to 'name' as an error.

Real-World Use Cases

Form State

When a form only edits a subset of a model's fields, Pick keeps the shape accurate without duplication:

type UpdateProfileForm = Pick<User, 'name' | 'email'>;

function submitProfileUpdate(data: UpdateProfileForm): Promise<void> {
  return api.patch('/profile', data);
}

Component Props

Vue and React components often need just a few fields from a larger model. Pick makes this explicit in the prop type:

type AvatarProps = Pick<User, 'id' | 'name'> & {
  size?: 'sm' | 'md' | 'lg';
};

Service Layer Boundaries

When passing data between services, Pick enforces that only the relevant fields cross the boundary — a lightweight form of data encapsulation:

type EmailPayload = Pick<User, 'name' | 'email'>;

function sendWelcomeEmail(user: EmailPayload): void {
  mailer.send({
    to: user.email,
    subject: `Welcome, ${user.name}!`,
  });
}

Combining with Other Utility Types

Pick composes cleanly with other utilities. For example, Partial> gives you an optional subset — perfect for PATCH request bodies:

type PatchUserRequest = Partial<Pick<User, 'name' | 'email' | 'role'>>;

`Pick` vs `Omit`

Pick and Omit are mirror images of each other:

Utility	Approach	Best when…
`Pick`	Allowlist — name what you want	The desired set is small
`Omit`	Denylist — name what you don't want	The excluded set is small

If you want all fields except one or two, Omit is more concise. If you want just a handful of fields from a large type, Pick is cleaner.

// These are equivalent when User has exactly these five fields:
type WithoutPassword = Omit<User, 'passwordHash'>;
type SafeFields = Pick<User, 'id' | 'name' | 'email' | 'createdAt' | 'role'>;

// Prefer Omit here — fewer keys to list

Key Takeaways

Pick creates a new type with only the named properties from Type.
The Keys argument is validated against keyof Type at compile time — typos are caught immediately.
It keeps derived types in sync with their source; renames and removals surface as errors rather than silent mismatches.
It composes well with Partial, Required, Readonly, and Omit for expressive, minimal type definitions.

Whenever you find yourself re-declaring a handful of fields that already exist on another type, Pick is almost certainly the right tool.

#typescript #frontend #best-practice

🐥 Color-code your GitHub PR list with custom CSS

2026-05-19T17:00:00Z

If you spend a lot of time reviewing pull requests on GitHub, you've probably wished the PR list gave you more visual signal at a glance. Which PRs are approved and ready to merge? Which ones have a reviewer blocking them? Which are still drafts?

With the Refined GitHub browser extension and a few lines of custom CSS, you can color-code your PR list to answer all of those questions instantly.

What You'll Need

Refined GitHub — a browser extension for Chrome, Firefox, and Safari that enhances the GitHub UI with dozens of quality-of-life improvements. One of its lesser-known features is the ability to inject your own custom CSS.

Setting Up Custom CSS in Refined GitHub

Install Refined GitHub from your browser's extension store.
Click the Refined GitHub icon in your toolbar and open its Options page.
Scroll down to the Custom CSS section.
Paste the CSS below and save.

The CSS

/* Draft PRs — targets the draft octicon on the PR status icon */
.js-issue-row:has(svg.octicon-git-pull-request-draft) {
    border-right: 4px solid #e68934 !important;
    background-color: rgba(230,137,52,0.1);
}

/* At least one approving review */
.js-issue-row:has([aria-label*="review approval"]) {
    border-right: 4px solid #5eb4a7;
    background-color: rgba(94, 180, 167, 0.2);
}

/* Changes Requested */
.js-issue-row:has([aria-label*="review requesting changes"]),
.js-issue-row:has([title="Changes requested"]) {
    border-right: 4px solid #9b59b6;
    background-color: rgba(155,89,182,0.1) !important;
}

How It Works

GitHub's PR list uses SVG status icons and review-state badges to indicate a PR's current state. The CSS uses the :has() selector to look up from those indicators to the parent row and apply a colored right border and tinted background.

Selector	Meaning	Color
`svg.octicon-git-pull-request-draft`	Draft PR	Orange `#e68934`
`[aria-label*="review approval"]`	Approved	Teal `#5eb4a7`
`[aria-label*="review requesting changes"]`	Changes requested	Purple `#9b59b6`

The Result

Head to any GitHub PR list and you'll immediately see rows highlighted by status. Approved PRs glow teal, blocked ones turn purple, and drafts stand out in orange — no more scanning each row individually.

It's a small change, but when you're triaging dozens of open PRs every day, the visual grouping saves a surprising amount of time.

#css #tools #github

🐥 Why Dexter LSP doesn't autocomplete Elixir stdlib modules

2026-05-17T17:00:00Z

If you're using Dexter as your Elixir LSP in VS Code and wondering why String, Enum, and other standard library modules don't show up in autocomplete — the answer is likely a missing or misconfigured stdlibPath.

The Problem

Dexter needs access to the Elixir source files (.ex) to index the stdlib. When you install Elixir via Homebrew, only compiled .beam files are included — no source. So even if you point dexter.stdlibPath at something like:

"dexter.stdlibPath": "/opt/homebrew/opt/elixir/lib/elixir/lib"

...there's nothing for Dexter to index, and stdlib autocomplete silently doesn't work.

The Fix

Clone the Elixir source at the version matching your runtime:

elixir --version
git clone https://github.com/elixir-lang/elixir.git ~/elixir-src --depth=1 --branch v1.18.3

Then update your .vscode/settings.json:

"dexter.stdlibPath": "/Users/yourname/elixir-src/lib"

That lib/ directory contains subdirectories like elixir/lib/, mix/lib/, logger/lib/, etc. — all with proper .ex source files that Dexter can index for autocomplete.

After restarting VS Code, stdlib completions for String, Enum, Map, and friends should start appearing.

#development #best-practice #elixir #vscode

🐥 Keeping Elixir stdlib source in sync with your project

2026-05-15T17:00:00Z

When working with tools like Dexter for Elixir code intelligence in VS Code, it's useful to have the Elixir standard library source checked out locally. Dexter uses it to provide go-to-definition and hover docs for stdlib modules.

The naive approach — cloning it once by hand — breaks down the moment you upgrade Elixir. You forget to re-clone, the path is wrong, and suddenly your editor is jumping to source that doesn't match what's actually running.

Here's a small shell script that automates it.

The script

#!/usr/bin/env bash
set -euo pipefail

version=$(elixir --version | grep -oE 'Elixir [0-9]+\.[0-9]+\.[0-9]+' | head -1 | awk '{print $2}')

if [[ -z "$version" ]]; then
  echo "Error: could not determine Elixir version" >&2
  exit 1
fi

branch="v${version}"
dest="$(cd "$(dirname "$0")" && pwd)/.elixir_stdlib"

echo "Elixir version: ${version}"

if [[ -d "$dest" ]]; then
  if git -C "$dest" tag --points-at HEAD 2>/dev/null | grep -qx "$branch"; then
    echo "${dest} already at ${branch}, skipping."
    exit 0
  fi
  echo "Found ${dest} at a different version, removing for ${branch} ..."
  rm -rf "$dest"
fi

echo "Cloning branch ${branch} into ${dest} ..."
git -c advice.detachedHead=false clone https://github.com/elixir-lang/elixir.git "$dest" --depth=1 --branch "$branch"

What it does

Detects the running Elixir version. It calls elixir --version and extracts the version number, so there's no hardcoded version to keep in sync manually.

Clones into .elixir_stdlib next to the script. Using dirname "$0" makes the destination relative to the script itself, so it works regardless of your current working directory.

Skips the clone if already up to date. Before doing anything destructive, it checks whether the target tag (v1.19.5, for example) is among the tags pointing at HEAD in the existing clone. This matters because the Elixir repo uses floating tags like v1.19-latest that point at the same commit — a naive git describe would return that tag instead, causing a false version mismatch every time.

Wipes and re-clones on version change. If the installed Elixir version doesn't match what's checked out, the old folder is removed and the correct version is cloned fresh.

Suppresses the detached HEAD warning. Cloning a tag always results in a detached HEAD, which git warns about by default. Passing -c advice.detachedHead=false silences that noise without hiding anything useful.

Usage

Drop the script in your project root, make it executable, add .elixir_stdlib to .gitignore, and point your editor at ${workspaceFolder}/.elixir_stdlib/lib.

chmod +x clone-elixir-src.sh
./clone-elixir-src.sh

Run it again whenever you upgrade Elixir — it'll figure out the rest.

#development #tools #best-practice #elixir #terminal #vscode

🐥 Anti-Corruption Layer in Elixir/Phoenix - Keep your domain clean

2026-05-13T17:00:00Z

When you integrate an external service — a payment provider, a shipping API, a CRM — you face a quiet but persistent risk: the external system's model starts leaking into your own. Status strings, provider-specific IDs, and SDK structs end up scattered across your business logic. Changing providers later means touching code you should never have had to change.

The Anti-Corruption Layer (ACL) is a pattern from Domain-Driven Design that puts an explicit translation boundary between your domain and the external world. Everything provider-specific lives in one place. Your domain never knows it exists.

This post walks through implementing it in Elixir and Phoenix, using a payment integration as the running example.

The Problem

Suppose you're integrating Stripe directly. Without a boundary, it's easy to write something like this:

defmodule MyApp.Orders do
  def complete_order(order) do
    case Req.post("https://api.stripe.com/v1/payment_intents",
           auth: {:basic, stripe_key()},
           form: [amount: order.total_cents, currency: "eur", confirm: true]
         ) do
      {:ok, %{status: 200, body: %{"status" => "succeeded"} = intent}} ->
        Orders.mark_paid(order, intent["id"])

      {:ok, %{body: %{"error" => %{"message" => msg}}}} ->
        {:error, msg}
    end
  end
end

This works on day one. But now your Orders context knows that payments have a "succeeded" status string, that IDs come from intent["id"], and that Stripe's API lives at that specific URL. If you ever swap providers — or just want to test without hitting Stripe — you have to unpick all of this from business logic.

Core Concepts in Elixir

The ACL pattern maps cleanly to Elixir idioms:

DDD concept	Elixir equivalent
Domain model	Plain `defstruct` (not an Ecto schema)
Port / interface	A `@behaviour` module
ACL implementation	A module implementing the behaviour
Domain service	A context module that only calls the behaviour
Wiring	`Application.get_env/2` and config files

Step 1: Define Your Domain Structs

These live in your domain and use your language — not Stripe's.

defmodule Billing.PaymentResult do
  @type status :: :pending | :captured | :declined | :refunded

  @enforce_keys [:id, :status, :amount_cents, :currency]
  defstruct [:id, :status, :amount_cents, :currency]
end

defmodule Billing.PaymentEvent do
  @type type :: :payment_captured | :payment_declined | :payment_refunded

  @enforce_keys [:type, :payment_id, :amount_cents]
  defstruct [:type, :payment_id, :amount_cents]
end

No Stripe types, no raw maps, no magic strings. If you switch providers, these structs stay exactly as they are.

Step 2: Define the Port Behaviour

The behaviour declares what the domain needs — a contract, not an implementation.

defmodule Billing.PaymentGateway do
  @type charge_result :: {:ok, Billing.PaymentResult.t()} | {:error, String.t()}
  @type refund_result :: {:ok, Billing.PaymentResult.t()} | {:error, String.t()}

  @callback charge(amount_cents :: integer(), currency :: String.t(), source :: String.t()) ::
              charge_result()

  @callback refund(payment_id :: String.t()) :: refund_result()
end

The domain context will call through this behaviour. It never imports Stripe modules or touches raw HTTP responses.

Step 3: Implement the ACL

This is the only module allowed to know anything about Stripe. All HTTP calls and all translation logic live here.

defmodule Billing.Gateways.StripeGateway do
  @behaviour Billing.PaymentGateway

  @base_url "https://api.stripe.com/v1"

  @impl true
  def charge(amount_cents, currency, source) do
    response =
      Req.post!("#{@base_url}/payment_intents",
        auth: {:basic, secret_key()},
        form: [
          amount: amount_cents,
          currency: currency,
          payment_method: source,
          confirm: true,
          "automatic_payment_methods[enabled]": true,
          "automatic_payment_methods[allow_redirects]": "never"
        ]
      )

    case response.status do
      200 -> {:ok, translate_intent(response.body)}
      _ -> {:error, response.body["error"]["message"]}
    end
  end

  @impl true
  def refund(payment_id) do
    response =
      Req.post!("#{@base_url}/refunds",
        auth: {:basic, secret_key()},
        form: [payment_intent: payment_id]
      )

    case response.status do
      200 -> {:ok, translate_refund(response.body)}
      _ -> {:error, response.body["error"]["message"]}
    end
  end

  # --- Translation layer ---

  defp translate_intent(intent) do
    %Billing.PaymentResult{
      id: intent["id"],
      status: translate_status(intent["status"]),
      amount_cents: intent["amount"],
      currency: intent["currency"]
    }
  end

  defp translate_refund(refund) do
    %Billing.PaymentResult{
      id: refund["payment_intent"],
      status: :refunded,
      amount_cents: refund["amount"],
      currency: refund["currency"]
    }
  end

  defp translate_status("succeeded"), do: :captured
  defp translate_status("processing"), do: :pending
  defp translate_status("requires_payment_method"), do: :declined
  defp translate_status("canceled"), do: :declined
  defp translate_status(_), do: :pending

  defp secret_key, do: Application.fetch_env!(:my_app, :stripe_secret_key)
end

Pattern matching on translate_status/1 makes the translation explicit and exhaustive. Adding a new Stripe status is a one-line change in exactly one place.

Step 4: Write a Clean Domain Context

The Billing context only speaks the behaviour. It has no idea which gateway is wired up.

defmodule Billing do
  def process_payment(amount_cents, currency, source) do
    gateway().charge(amount_cents, currency, source)
  end

  def issue_refund(payment_id) do
    gateway().refund(payment_id)
  end

  defp gateway do
    Application.get_env(:my_app, :payment_gateway, Billing.Gateways.StripeGateway)
  end
end

Nothing in here ties you to Stripe. The context is pure business logic.

Step 5: Wire It Up in Config

# config/config.exs
config :my_app, :payment_gateway, Billing.Gateways.StripeGateway
config :my_app, :stripe_secret_key, System.get_env("STRIPE_SECRET_KEY")

# config/test.exs
config :my_app, :payment_gateway, Billing.Gateways.FakeGateway

Switching providers in production means changing one config line and shipping a new gateway module. Nothing else changes.

Handling Webhooks

Webhooks are where external models are most tempting to let through. A Phoenix controller should translate immediately and dispatch a domain event — it should not pass raw Stripe payloads any further.

defmodule MyAppWeb.StripeWebhookController do
  use MyAppWeb, :controller

  def handle(conn, params) do
    case translate_event(params) do
      {:ok, event} ->
        Billing.handle_payment_event(event)
        send_resp(conn, 200, "")

      {:error, :unhandled} ->
        send_resp(conn, 200, "")

      {:error, reason} ->
        send_resp(conn, 400, reason)
    end
  end

  defp translate_event(%{
         "type" => "payment_intent.succeeded",
         "data" => %{"object" => %{"id" => id, "amount" => amount}}
       }) do
    {:ok, %Billing.PaymentEvent{type: :payment_captured, payment_id: id, amount_cents: amount}}
  end

  defp translate_event(%{
         "type" => "payment_intent.payment_failed",
         "data" => %{"object" => %{"id" => id, "amount" => amount}}
       }) do
    {:ok, %Billing.PaymentEvent{type: :payment_declined, payment_id: id, amount_cents: amount}}
  end

  defp translate_event(_), do: {:error, :unhandled}
end

The controller is the ACL for inbound Stripe events. Once translated, Billing.handle_payment_event/1 receives only %Billing.PaymentEvent{} structs — never raw Stripe data.

Testing Without a Real Gateway

Because the gateway is a behaviour, you can swap in a fake implementation for tests without mocks or HTTP stubs.

defmodule Billing.Gateways.FakeGateway do
  @behaviour Billing.PaymentGateway

  @impl true
  def charge(_amount_cents, _currency, "fail_card") do
    {:error, "Card declined"}
  end

  def charge(amount_cents, currency, _source) do
    {:ok, %Billing.PaymentResult{
      id: "fake_#{System.unique_integer([:positive])}",
      status: :captured,
      amount_cents: amount_cents,
      currency: currency
    }}
  end

  @impl true
  def refund(payment_id) do
    {:ok, %Billing.PaymentResult{
      id: payment_id,
      status: :refunded,
      amount_cents: 0,
      currency: "eur"
    }}
  end
end

Your tests call Billing.process_payment/3 exactly as production code does — there is no test-only branch in the domain logic, and no HTTP traffic.

test "successful payment returns a captured result" do
  assert {:ok, %Billing.PaymentResult{status: :captured}} =
           Billing.process_payment(1999, "eur", "tok_visa")
end

test "declined card returns an error" do
  assert {:error, "Card declined"} =
           Billing.process_payment(1999, "eur", "fail_card")
end

Elixir-Specific Considerations

Behaviours vs. protocols. Use a @behaviour when you have multiple implementations of the same concept (payment gateways, SMS providers). Use a protocol when you want polymorphism across data types you don't control. For the ACL pattern, behaviours are the right tool.

Pattern matching is your translation engine. The translate_status/1 clauses above are cleaner than a case block or a map lookup. If Stripe adds a new status you haven't handled, the _ clause captures it safely, and you can add a specific clause when you care about it.

Keep Ecto schemas out of the ACL. It's tempting to map directly from a Stripe response onto an Ecto schema. Resist this. Plain structs are easier to reason about, test, and evolve independently from your database shape. Persist only after your domain logic has run.

Stateful gateways. If your gateway implementation needs its own process — say, to maintain an authenticated session or a connection pool — start it in your application's supervision tree. The behaviour contract stays the same; the implementation just has a start_link/1 that gets wired into the supervisor.

Common Pitfalls

Returning raw maps from the gateway. If charge/3 returns %{"id" => ..., "status" => "succeeded"}, you've moved the contamination rather than removed it. Always return your own structs.

Putting translation in the Phoenix controller for everything. The controller is the right place for webhook translation (it's the entry point). But if you're doing translation inside action handlers for outgoing calls, extract it into the gateway module where it belongs.

One ACL module for all external systems. If you add a shipping provider, create Shipping.Gateways.DHLGateway with its own behaviour. Don't grow StripeGateway into a general-purpose external-systems module.

Letting provider IDs become first-class domain concepts. Storing a Stripe payment intent ID as billing_stripe_id in your domain is a smell — the domain now knows about Stripe. Store it as external_payment_id or in a separate gateway-specific record that your ACL manages.

Conclusion

Elixir's behaviours give you a clean, compiler-checked way to define the boundary between your domain and the outside world. Pattern matching makes the translation logic readable and exhaustive. Swapping configs gives you test isolation without mocks.

The ACL pattern keeps your core business logic stable regardless of what external APIs do. When Stripe changes a status code or you decide to try a different provider, you update one module. Your domain, your tests, and everything that depends on them stays untouched.

#development #pattern #best-practice #elixir #phoenix

🐥 Restarting supervisord daemons by working directory on Linux

2026-05-11T17:00:00Z

When you run multiple instances of the same Laravel Horizon worker (or any supervisord-managed process) across different deployment directories, you'll quickly notice that supervisord assigns generic auto-generated names like daemon-282661:daemon-282661_00. There's no obvious way to tell which daemon belongs to which application directory — until you know the trick.

Finding the working directory of a process

On Linux, every running process exposes its current working directory as a symlink under /proc:

readlink /proc/<pid>/cwd

To check all your Horizon workers at once, grab their PIDs from supervisorctl status and loop over them:

for pid in 91286 91287 91288 91290; do
  echo "$pid: $(readlink /proc/$pid/cwd)"
done

Restarting daemons for a specific directory

Once you can map PIDs to directories, it's straightforward to build a script that restarts only the daemons running from a given path:

#!/bin/bash

TARGET_DIR="${1:?Usage: $0 }"
TARGET_DIR=$(realpath "$TARGET_DIR")

supervisorctl status | while read -r line; do
    echo "$line" | grep -q "RUNNING" || continue

    name=$(echo "$line" | awk '{print $1}')
    pid=$(echo "$line" | grep -oP 'pid \K[0-9]+')

    [[ -z "$pid" ]] && continue

    cwd=$(readlink "/proc/$pid/cwd" 2>/dev/null)

    if [[ "$cwd" == "$TARGET_DIR"* ]]; then
        echo "Restarting $name (pid $pid, dir $cwd)"
        supervisorctl restart "$name"
    fi
done

How it works

supervisorctl status lists all daemons with their current PIDs.
Non-RUNNING daemons are skipped (they have no PID to look up).
/proc//cwd resolves the actual working directory for each process.
Any daemon whose working directory matches the target path (or is a subpath of the target path) gets restarted.

Usage

chmod +x restart-daemons.sh
./restart-daemons.sh /home/forge/my-app/current

This is especially useful on servers running multiple deployments of the same application — for example, a staging environment with both a current and a previous release still running workers.

#laravel #devops #terminal #linux #sysadmin

🐥 Make your shell scripts' environment variables overridable

2026-05-09T17:00:00Z

When writing shell scripts, hardcoded values are a common source of friction. A script that works perfectly on your machine may need adjustments on a colleague's setup, in CI, or in production — and forcing people to edit the script itself is messy.

There's a simple Bash idiom that solves this cleanly.

The Problem

Consider a typical startup script:

PORT=8888
HOST=0.0.0.0

uvicorn myapp:app --host $HOST --port $PORT

The port is hardcoded. If you need to run two instances, or if 8888 is already taken, you have to edit the file.

The Fix: `${VAR:-default}`

Replace the hardcoded assignment with a default-value expansion:

PORT=${PORT:-8888}
HOST=${HOST:-0.0.0.0}

uvicorn myapp:app --host $HOST --port $PORT

The syntax ${VAR:-default} means:

Use the value of $VAR if it is set and non-empty; otherwise use default.

The script's behaviour is unchanged when no environment variable is provided — the default kicks in. But now callers can override it without touching the file:

PORT=9000 ./bin/start.sh

Or by exporting it beforehand:

export PORT=9000
./bin/start.sh

Why This Matters

No edits required. The script stays clean; overrides happen at call time.
CI-friendly. Most CI systems let you set environment variables per job. Your script picks them up automatically.
Self-documenting. The default value lives right next to the variable name, so readers immediately know what to expect.
Composable. You can layer overrides: a .env file, a CI variable, or a one-liner prefix — whatever fits the context.

Variants Worth Knowing

Syntax	Meaning
`${VAR:-default}`	Use `default` if `VAR` is unset or empty
`${VAR-default}`	Use `default` only if `VAR` is unset (empty string is kept)
`${VAR:=default}`	Use `default` and assign it back to `VAR` if unset or empty
`${VAR:?message}`	Abort with `message` if `VAR` is unset or empty

For most cases, ${VAR:-default} is the right choice. The := variant is useful when you want the variable available for the rest of the script without repeating the default.

A Real-World Example

Here's a before/after for a uvicorn startup script:

Before:

HOST=0.0.0.0
PORT=8888

uvicorn docai.api.app:app --host $HOST --port $PORT

After:

HOST=${HOST:-0.0.0.0}
PORT=${PORT:-8888}

uvicorn docai.api.app:app --host $HOST --port $PORT

Two characters added per line (${ and :-), zero behaviour change by default, and now fully overridable from the outside. A small habit with outsized payoff.

#best-practice #devops #terminal

🐥 Using generators for PHPUnit data providers

2026-05-07T17:00:00Z

When writing PHPUnit tests, data providers are one of the simplest ways to increase coverage without duplicating test logic. Most examples use arrays, but PHP generators (yield) are often a better fit: they’re more expressive, memory-efficient, and easier to extend.

This post walks through a clean, generic approach to using generators for PHPUnit data providers.

Why use generators instead of arrays?

A traditional data provider might look like this:


public static function provideCases(): array
{
    return [
        'case A' => ['input-a', 'expected-a'],
        'case B' => ['input-b', 'expected-b'],
    ];
}

This works, but generators give you a few advantages:

No need to build a full array in memory
Named cases are more natural with yield
Easier to compose or split into smaller logical chunks
Better readability when cases grow

A simple example

Imagine you’re testing a service that transforms input values:


final class ValueTransformer
{
    public function transform(string $value): string
    {
        return strtoupper($value);
    }
}

Instead of writing multiple test methods, you can use a generator-based data provider:


use PHPUnit\Framework\Attributes\DataProvider;
use PHPUnit\Framework\Attributes\Test;

final class ValueTransformerTest extends TestCase
{
    #[Test]
    #[DataProvider('provideTransformCases')]
    public function it_transforms_values(string $input, string $expected): void
    {
        $service = new ValueTransformer();

        $result = $service->transform($input);

        $this->assertSame($expected, $result);
    }

    public static function provideTransformCases(): \Generator
    {
        yield 'lowercase' => ['hello', 'HELLO'];
        yield 'mixed case' => ['HeLLo', 'HELLO'];
        yield 'already uppercase' => ['WORLD', 'WORLD'];
    }
}

Making test cases more expressive

Generators really shine when your inputs are objects instead of primitives.

For example, testing a query modifier:


final class QueryModifier
{
    public function apply(QueryBuilder $query, string $field, string $direction): QueryBuilder
    {
        return $query->orderBy($field, $direction);
    }
}

Your test can focus on behavior while the generator defines the variations:


#[Test]
#[DataProvider('provideSortingCases')]
public function it_applies_sorting(string $field, string $direction): void
{
    $query = Mockery::mock(QueryBuilder::class);
    $query->shouldReceive('orderBy')
        ->once()
        ->with($field, $direction)
        ->andReturnSelf();

    $modifier = new QueryModifier();

    $modifier->apply($query, $field, $direction);
}

public static function provideSortingCases(): \Generator
{
    yield 'sort by name' => ['name', 'asc'];
    yield 'sort by created_at desc' => ['created_at', 'desc'];
    yield 'sort by nested field' => ['user.email', 'asc'];
}

The test stays minimal, while the generator clearly documents the supported scenarios.

Composing generators

One underrated benefit is that generators can be composed. You can split cases into smaller methods and reuse them:


public static function provideSortingCases(): \Generator
{
    yield from self::basicFields();
    yield from self::nestedFields();
}

private static function basicFields(): \Generator
{
    yield 'name asc' => ['name', 'asc'];
    yield 'created_at desc' => ['created_at', 'desc'];
}

private static function nestedFields(): \Generator
{
    yield 'user email' => ['user.email', 'asc'];
}

This keeps large test suites maintainable without sacrificing clarity.

When to prefer generators

Generators are especially useful when:

You have many test cases
Test data is constructed dynamically
You want to group or reuse subsets of cases
Memory usage might become a concern

For small, static datasets, arrays are perfectly fine. But once your data providers grow, generators tend to scale much better.

Final thoughts

Using generators in PHPUnit data providers is a small change that improves readability and flexibility. Tests become easier to extend, and the intent of each case is clearer thanks to named yields.

If you’re already relying on data providers, switching from arrays to generators is a low-effort improvement that pays off quickly in larger test suites.

#php #best-practice #testing

🐥 Fixing the Ondrej Nginx PPA 403 error on Laravel Forge servers

2026-05-05T17:00:00Z

If you're running Ubuntu 22.04 on a Laravel Forge-managed server, you may have recently started seeing this error during apt update:

Err:7 https://ppa.launchpadcontent.net/ondrej/nginx/ubuntu jammy InRelease
  403  Forbidden
E: The repository 'https://ppa.launchpadcontent.net/ondrej/nginx/ubuntu jammy InRelease' is no longer signed.

What's happening?

Forge historically added the ondrej/nginx PPA to its servers to get newer versions of nginx. Ondrej Surý (the maintainer) has since moved this PPA to a paid subscription model, so unauthenticated access now returns a 403. Your server still has the old PPA entry, but it can no longer reach it.

You'll notice the ondrej/php PPA still works fine — that one remains freely available.

The fix

Step 1: Find the file that references the broken PPA:

grep -r "ondrej/nginx" /etc/apt/sources.list.d/

Step 2: Remove it (the filename will match what grep returned above):

sudo rm /etc/apt/sources.list.d/ondrej-ubuntu-nginx-jammy.list
sudo rm -f /etc/apt/sources.list.d/ondrej-ubuntu-nginx-jammy.list.distUpgrade

Note: add-apt-repository --remove ppa:ondrej/nginx won't work here — Launchpad returns a 403 before it can resolve the PPA name.

Step 3: Run apt update again. If you need a newer version of nginx than Ubuntu's default (1.18.x), add the official nginx.org repository instead:

curl -fsSL https://nginx.org/keys/nginx_signing.key | sudo gpg --dearmor -o /usr/share/keyrings/nginx-archive-keyring.gpg

echo "deb [signed-by=/usr/share/keyrings/nginx-archive-keyring.gpg] http://nginx.org/packages/ubuntu jammy nginx" \
  | sudo tee /etc/apt/sources.list.d/nginx.list

sudo apt update
sudo apt install nginx

Do you need a newer nginx?

For most Laravel applications, Ubuntu's default nginx is perfectly adequate. Unless you have a specific reason to run a cutting-edge nginx version, removing the PPA and sticking with the default is the simplest and most stable path.

#laravel #best-practice #devops #linux #sysadmin

🐥 Upgrading firebase/php-jwt to v7 in a Laravel App (transitive dependency trap)

2026-04-24T17:00:00Z

A few weeks ago we upgraded firebase/php-jwt from v6 to v7 in our app. It sounds like a routine dependency bump — update the version constraint in composer.json, run composer update, done. But there was a catch: one of our other packages, socialiteproviders/microsoft, had a hard constraint on the old version. This is the classic transitive dependency conflict, and if you haven't run into it before, you will.

Here's how we handled it and how you should too.

What's a transitive dependency conflict?

Your composer.json only lists the packages you directly depend on. But each of those packages has its own composer.json, listing their dependencies — and those packages have their own, and so on. This tree is your full dependency graph.

A transitive dependency conflict happens when you want to upgrade Package A, but Package B — which you also require — has a hard constraint that prevents it from working with the new version of A.

In our case:

We wanted: firebase/php-jwt: ^7.0
socialiteproviders/microsoft (v4.7.1) declared: "firebase/php-jwt": "^6.8"

These two constraints are mutually exclusive. Composer can't install a version of firebase/php-jwt that satisfies both ^7.0 and ^6.8 simultaneously, so it would refuse — with a dependency resolution error.

Step 1: Understand the dependency graph before touching anything

The first move is to inspect what the problematic package actually requires:

composer show socialiteproviders/microsoft

This outputs the requires section:

requires
php ^8.0
ext-json *
firebase/php-jwt ^6.8
socialiteproviders/manager ^4.4

There it is. Before writing a single line, you know exactly what needs to change.

Step 2: Validate with a dry run

Rather than guessing whether a combination of versions will resolve, ask Composer directly using --dry-run:

composer require --dry-run "firebase/php-jwt:^7.0" "socialiteproviders/microsoft:^4.9"

Composer will either:

Print a clean resolution plan with the exact versions it would install, or
Print an error telling you exactly which package is blocking and why

In our case it resolved cleanly:

Lock file operations: 0 installs, 3 updates, 0 removals
  - Upgrading firebase/php-jwt (6.x-dev => v7.0.5)
  - Upgrading socialiteproviders/microsoft (4.7.1 => 4.9.1)

Nothing was written to disk. We just confirmed the upgrade path works.

Step 3: Update both packages in a single command

This is the part people get wrong. If you only update firebase/php-jwt:

# ❌ This will fail — socialiteproviders/microsoft still requires ^6.8
composer update firebase/php-jwt

Composer will refuse because the new firebase/php-jwt v7 conflicts with the installed socialiteproviders/microsoft v4.7.1. You must update both in one pass so Composer can solve the graph holistically:

# ✅ Composer solves both constraints together
composer update firebase/php-jwt socialiteproviders/microsoft

Output:

- Upgrading firebase/php-jwt (6.x-dev => v7.0.5): Extracting archive
- Upgrading socialiteproviders/microsoft (4.7.1 => 4.9.1): Extracting archive
No security vulnerability advisories found.

Step 4: Bump the constraint in composer.json

Don't forget to update your version constraints in composer.json to reflect the new minimums:

"firebase/php-jwt": "^7.0",
"socialiteproviders/microsoft": "^4.9",

Why ^4.9 instead of leaving it at ^4.1? Because ^4.9 documents intent: "we need at least 4.9, because that's the version that supports firebase/php-jwt v7." If you leave it at ^4.1, a future composer update could theoretically resolve back to 4.7.x in some edge case and silently reintroduce the conflict.

Step 5: Check your own code for API breakage

A major version bump means potential breaking changes. Grep for every place you use the package:

grep -r "Firebase\\JWT" app/ --include="*.php" -l

For firebase/php-jwt specifically, JWT::encode() kept the same signature in v7 — the only notable change was a stricter PHP type hint on the $key parameter (OpenSSLAsymmetricKey|OpenSSLCertificate|string vs the old loosely-typed $key). Since we pass strings (shared secrets and RSA private keys), there was nothing to change in our ZendeskJwtTokenBuilder or DocuSignJwtTokenBuilder.

Step 6: Run the affected tests

XDEBUG_MODE=off php artisan test --compact \
  tests/Unit/Domains/Tokens/JwtTokenBuilderTest.php \
  tests/Feature/Authentication/MicrosoftLoginTest.php

Tests:    27 passed (106 assertions)
Duration: 10.44s

Green. Ship it.

The general playbook

Whenever you hit a transitive dependency conflict in Composer:

Step	What to do
1	`composer show` — find the conflicting constraint
2	`composer require --dry-run "a:^X" "b:^Y"` — validate resolution without touching files
3	`composer update a b` — update all conflicting packages in one pass
4	Tighten the version constraint in `composer.json` to document the new minimum
5	Grep for usages, read the changelog for breaking API changes
6	Run the affected tests

The core insight: Composer's constraint solver needs to see the full picture. If you update one package at a time when there's a conflict, you're fighting the solver instead of working with it.

#development #laravel #php #best-practice

🐥 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

🐥 YellowDuck.be

🐥 Why crypto.getRandomValues() matters in JavaScript

The problem with Math.random()

Using crypto.getRandomValues()

Generating a secure random token

Typed arrays are required

Browser and runtime support

UUID generation

Things to remember

🐥 How to find all Jira issues ever assigned to someone (even historical ones)

The was operator

Checking multiple people at once

Scoping to a specific year

Putting it all together

🐥 Downloading external images as squares from a Phoenix app

The CORS problem

The fix: a server-side proxy

Center-cropping to a square in the browser

Wiring it up in LiveView

Why naturalWidth instead of width?

🐥 The Tailwind `enabled:` selector trick for disabled buttons

The problem

The fix: enabled:

Why this matters

In practice (Phoenix / LiveView)

🐥 Hide a layout section from a specific child view in Laravel Blade

The problem

The solution

How it works

Why this is better than the alternatives

🐥 Scanning files with clamdscan and --fdpass

What does --fdpass do?

Installing ClamAV

Enabling clamd on startup

Verifying the socket configuration

Scanning a file

Why use clamdscan instead of clamscan?

Common error

Understanding exit codes

🐥 TypeScript's Pick utility type: select what you need

What Is Pick?

A Practical Example

Real-World Use Cases

Form State

Component Props

Service Layer Boundaries

Combining with Other Utility Types

Pick vs Omit

Key Takeaways

🐥 Color-code your GitHub PR list with custom CSS

What You'll Need

Setting Up Custom CSS in Refined GitHub

The CSS

How It Works

The Result

🐥 Why Dexter LSP doesn't autocomplete Elixir stdlib modules

The Problem

The Fix

🐥 Keeping Elixir stdlib source in sync with your project

The script

What it does

Usage

🐥 Anti-Corruption Layer in Elixir/Phoenix - Keep your domain clean

The Problem

Core Concepts in Elixir

Step 1: Define Your Domain Structs

Step 2: Define the Port Behaviour

Step 3: Implement the ACL

Step 4: Write a Clean Domain Context

Step 5: Wire It Up in Config

Handling Webhooks

Testing Without a Real Gateway

Elixir-Specific Considerations

Common Pitfalls

Conclusion

🐥 Restarting supervisord daemons by working directory on Linux

Finding the working directory of a process

Restarting daemons for a specific directory

How it works

Usage

The problem with `Math.random()`

Using `crypto.getRandomValues()`

The `was` operator

Why `naturalWidth` instead of `width`?

The fix: `enabled:`

What Is `Pick`?

`Pick` vs `Omit`

The Fix: `${VAR:-default}`

The `num_nonnulls` function