🐥 YellowDuck.be

🐥 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

🔗 No management needed: anti-patterns in early-stage engineering teams

2026-05-13T13:00:00Z

Early-stage founders waste time on management that doesn't yet matter. Instead of motivating engineers through 996-style cultures or hiring managers, founders should focus on hiring inherently motivated people and maintaining a lightweight, transparent environment. The key is avoiding premature organizational structure—keeping all engineers under one technical leader until reaching 20-50 people, while resisting the temptation to copy Google's management innovations. Culture should develop through shipping speed, not clever feedback systems.

Continue reading on www.ablg.io

#reading-list #development

🔗 SQLite features you didn’t know it had: JSON, text search, CTE, STRICT, generated columns, WAL

2026-05-13T08:00:00Z

Modern SQLite packs powerful features that most developers overlook. The database supports JSON querying, full-text search via FTS5, window functions and CTEs for analytics, strict typing enforcement, generated columns for derived data, and write-ahead logging for improved concurrency. These capabilities eliminate the need for separate specialized tools, letting teams keep data in a single file while maintaining sophisticated functionality traditionally associated with heavier database systems.

Continue reading on slicker.me

#reading-list #database #best-practice #sql #sqlite

🔗 Thinking Elixir Podcast 303: The Taming of the Slop

2026-05-12T17:00:00Z

EEF 2026 election candidates are out, Elixir-Vibe launches tools to fight AI code slop, erlang_python 3.0.0 embeds CPython into the BEAM, ElixirConf EU 2026 videos are dropping, and more!

Continue reading on podcast.thinkingelixir.com

#reading-list #elixir #phoenix

🔗 Intelligent curation tagging for creative workflows

2026-05-12T13:00:00Z

I struggled with organizing 14,000 photos and wanted an AI to help identify the ones matching my aesthetic. Initially, I relied on a vision model to classify them based on a prose description, but the results were inconsistent and resource-intensive, spiking RAM usage to 15GB. The new architecture focuses on learning from my feedback instead of static prompts. Using CLIP embeddings and a preference model, it tracks my ratings to improve selection. The ingestion process involves measuring technical image qualities and extracting metadata before sending photos to the AI worker. This staged pipeline lets each component fail and retry independently, providing a smooth curation experience. After running just a few sessions, I managed to surface 214 meaningful images out of 3,600 processed. The entire backlog could be managed within a week at this rate!

Continue reading on qwelian.com

#reading-list #development #tools #ai

🔗 Common CORS errors and how to fix them

2026-05-12T08:00:00Z

Cross-Origin Resource Sharing (CORS) provides browser security by managing requests across different origins. CORS errors arise when the server does not send back the expected headers, leading to blocked requests in the browser's console.

This article outlines common CORS errors, including missing headers and preflight issues, and offers detailed solutions. Developers are advised to configure their server settings correctly to allow cross-origin interactions while maintaining secure API access.

Continue reading on workos.com

#reading-list #frontend #best-practice #http

🐥 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

🔗 Shell tricks that actually make life easier (and save your sanity)

2026-05-11T13:00:00Z

The post is a practical roundup of shell shortcuts and habits that make command-line work faster and less frustrating. It highlights useful editing, navigation, and safety tips for Bash/Zsh users, plus a few portable tricks that work across POSIX shells as well.

Continue reading on blog.hofstede.it

#reading-list #tools #best-practice #terminal

🔗 Anti-frameworkism: Choosing native web APIs over frameworks

2026-05-11T08:00:00Z

Today’s browsers can handle most issues that frontend frameworks were created to solve. Developers often still opt for frameworks like React, Angular, or Vue, which can increase page weight, hurt performance, and affect SEO despite native web APIs being sufficient for many tasks.

This article identifies the disparity between "frameworkism" and "anti-frameworkism." It emphasizes that frameworks are not always necessary and advocates for a native API-first approach where developers rely on native browser capabilities before turning to frameworks.

Continue reading on blog.logrocket.com

#reading-list #javascript #frontend #best-practice #html

🔗 Laravel raised money and now injects ads directly into your agent

2026-05-10T17:00:00Z

Did Laravel really need to change their agent documentation to push Laravel Cloud? After raising a $57M Series A, it's clear they want to monetize effectively. The latest PR suggests agents should default to Laravel Cloud for deployments, sparking complaints from users about the perceived bias towards Laravel's commercial platform. This shift raises questions about the erosion of community trust and the balance between monetization and quality support. Interestingly, many still recommend Laravel Cloud without the need for forceful promotion. However, it prompts a broader discussion about how ads within development tools might impact user experience and community sentiment. If Laravel's commercial segment is doing well, why risk alienating devoted users?

Continue reading on techstackups.com

#reading-list #development #laravel #announcement

🔗 Migrating from DigitalOcean to Hetzner: from $1,432 to $233/month with zero downtime

2026-05-10T13:00:00Z

I saved over $1,200 per month by migrating from DigitalOcean to Hetzner. Previously, I paid $1,432/month for a droplet, while the Hetzner AX162-R costs only $233/month. Managing 248 GB of MySQL data across 30 databases and hosting 34 Nginx sites meant careful planning to avoid downtime. I implemented a six-phase strategy that included live MySQL replication using mydumper for fast data export and loading, and a well-scripted DNS cutover that reduced TTL to allow for quick switching. After the move, I noticed significant performance improvements thanks to MySQL 8.0's enhancements. The process involved meticulous configuration of services and a thorough testing phase before the final switch-over. The transition was seamless, with all traffic constantly routed during migration, solidifying the importance of planning when moving critical infrastructure.

Continue reading on isayeter.com

#reading-list #database #best-practice #mysql #devops #linux

🔗 pg_textsearch: How we built a BM25 search engine on Postgres pages

2026-05-10T08:00:00Z

Building a BM25 search engine on Postgres required addressing significant limitations of the built-in ts_rank. As I learned, the lack of inverse document frequency and term frequency saturation affected the relevance and scalability of searches. By creating pg_textsearch, they implemented real BM25 scoring via a native indexing solution in C integrated with Postgres.

The design included a hybrid architecture with a write-optimized memtable and immutable disk segments. Notably, they achieved fast query performance through optimizations like Block-Max WAND, allowing for much quicker retrieval of top results without scoring every match. With extensive benchmarks, they showed pg_textsearch can outperform existing tools like ParadeDB, achieving up to 6.5x speed increases on 138 million document queries. This combination of efficiency and native integration makes it a compelling option for teams needing robust search capabilities within Postgres.

Continue reading on www.tigerdata.com

#reading-list #development #database #tools #best-practice #postgresql

🐥 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

🔗 Finding my way with AI coding agents

2026-05-09T13:00:00Z

The author initially disliked AI coding assistants, finding inline autocomplete intrusive and distracting from their work. After exploring GitHub Copilot Pro agents in Zed, they realized the core problem: AI agents operate at the wrong abstraction layer, viewing static code rather than the running application.

Tidewave, an Elixir-based tool by José Valim, runs directly inside applications at runtime and lets agents see what developers see. The author's workflow involves connecting Tidewave to Copilot, using Gemini 3.1 Pro to implement features while watching the agent test changes in the browser, then manually refactoring the generated code in Zed before committing.

This approach resolves the abstraction layer problem and keeps the developer engaged with their codebase. The author maintains manual control over code quality and structure, avoiding the pitfalls of fully autonomous agents while still leveraging AI's capabilities effectively.

Continue reading on fabrithedev.com

#reading-list #development #tools #ai #elixir

🔗 Every layer of review makes you 10x slower

2026-05-09T08:00:00Z

Every layer of approval in a process makes it approximately 10x slower in wall-clock time, primarily due to waiting and coordination overhead. A simple bug fix takes 30 minutes to code, 5 hours to peer review, a week for design approval, and 12 weeks if another team must schedule it.

Sustainable speed improvement requires fewer reviews rather than faster reviewers, as AI cannot overcome latency bottlenecks in approval pipelines. Quality improvement should focus on system-wide engineering practices and trust, following Deming's philosophy, rather than adding more QA layers that create perverse incentives and reduce actual quality.

Continue reading on apenwarr.ca

#reading-list #development #best-practice

🔗 EXPLAIN's other superpowers

2026-05-08T17:00:00Z

Did you know that the EXPLAIN command in PostgreSQL has several lesser-known options that can significantly enhance your troubleshooting capabilities? The BUFFERS option shows where your data was sourced—whether from shared buffers or disk—helping you diagnose cache issues or memory constraints. You can then track memory usage during query planning with MEMORY. For write-heavy operations, the WAL option reveals detailed logging metrics, useful for bulk loads or updates. Want to replicate your environment? The SETTINGS option outlines your configuration settings, while the VERBOSE flag provides an expanded view of the query planner's operations. Combine these options, like EXPLAIN (ANALYZE, BUFFERS, WAL, SETTINGS), for a comprehensive picture of your query execution and database health.

Continue reading on richyen.com

#reading-list #database #best-practice #postgresql

🔗 Thinking Elixir Podcast 302: BEAM in Your Pocket

2026-05-08T13:00:00Z

News includes Mob bringing BEAM-on-device native mobile dev to Elixir, Folio for print-quality PDFs via Rustler NIF, Oban v2.22 & Pro v1.7.0 released, LiveVue v1.1 with Node-less SSR, and more!

Continue reading on podcast.thinkingelixir.com

#reading-list #elixir #phoenix

🔗 Most devs ignore git worktree. Here's why they're wrong

2026-05-08T08:00:00Z

I used to dread the inefficiency of branch switching in Git. Switching branches often disrupted my workflow, forcing me to stash changes and lose my train of thought. Then I discovered git worktree, which transformed my experience by allowing multiple clean working directories for the same repository. With git worktree add, I could create a new folder for a branch, eliminating the need to stash or lose context. This approach enables parallel development, so I could run tests in one directory while coding in another, minimizing context switches. Yet, many developers ignore it, thinking it’s only for advanced users, even as they spend hours on outdated workflows. After using git worktree, I could never go back. It’s not flashy, but it’s incredibly effective.

Continue reading on dev.ongoro.top

#reading-list #development #tools #best-practice #git

🐥 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

🔗 PHP attributes in Laravel 13: The ultimate guide (36 new attributes!)

2026-05-07T13:00:00Z

New Laravel 13 went all-in on PHP attributes. Properties like $fillable, $guarded, and $hidden that you've been defining on models for years can now be declared as class-level attributes: #[Fillable], #[Guarded], and #[Hidden]. The same applies to job configuration, console command signatures, middleware, and more.

In this article, I'll walk you through every PHP attribute available in Laravel 13 — both the new ones and those that existed before — with practical code examples for each.

Important notice: those attributes are optional, and you may use the old syntax in all those cases. The attributes are NOT breaking changes, just the new alternatives.

Continue reading on laraveldaily.com

#reading-list #laravel #php

🔗 Debugging slow ecto queries with AppSignal

2026-05-07T08:00:00Z

A sports car can only be driven as fast as the road it's on. In Phoenix applications, the database often becomes that bottleneck, impacting performance. AppSignal aids in detecting slow Ecto queries by auto-instrumenting them. It allows developers to pinpoint the specific queries causing performance issues. The tool highlights slow queries in the performance section, showing them ranked by impact based on frequency and duration. To resolve issues, ensuring tables are indexed properly and avoiding unbounded queries are key strategies. For common problems like N+1 queries, employing techniques such as limiting query results or offloading work to materialized views can greatly enhance performance. After making adjustments, it’s crucial to verify that these changes effectively reduce latency by checking AppSignal's insights post-deployment.

Continue reading on blog.appsignal.com

#reading-list #database #tools #elixir #phoenix

🔗 Did contexts kill Phoenix?

2026-05-06T17:00:00Z

The author reflects on the challenges faced by the Phoenix framework, particularly how the introduction of contexts may have hindered its adoption among new developers.

Continue reading on arrowsmithlabs.com

#reading-list #development #best-practice #elixir #phoenix

🔗 On knowing what code to throw away

2026-05-06T13:00:00Z

This article discusses a shift in coding practices due to the emergence of agentic coding tools. The emphasis has moved from merely writing code to knowing what to remove, as the ability to generate code has become abundant while the skill of effective curation remains scarce.

The article compares this change to Michelangelo's sculpting process, where the focus is on revealing the form within the marble rather than adding more material. As a result, software engineers now face the challenge of discerning which elements are essential, recognizing that the skill of editing is more crucial than the act of building itself.

Continue reading on matthewsinclair.com

#reading-list #development #best-practice #ai

🔗 What I learned from nearly 1,000 interviews at Amazon

2026-05-06T08:00:00Z

I spent over a decade as an Amazon Bar Raiser, interviewing nearly 1,000 candidates across all levels. A surprising trend emerged: technical skills mattered less than how candidates presented themselves. Many who excelled technically still failed due to poor storytelling in behavioral interviews. While preparation for technical skills is concrete and quantifiable, non-technical preparation can be neglected entirely. I found that spending even a small portion of your prep time on crafting clear, concise personal stories can dramatically improve your interview performance. Ultimately, interviews should be viewed as auditions for teamwork rather than exams to be passed, emphasizing the importance of fit and personality in hiring decisions.

Continue reading on alifeengineered.substack.com

#reading-list #best-practice

🐥 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

🐥 YellowDuck.be

🐥 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

🔗 No management needed: anti-patterns in early-stage engineering teams

🔗 SQLite features you didn’t know it had: JSON, text search, CTE, STRICT, generated columns, WAL

🔗 Thinking Elixir Podcast 303: The Taming of the Slop

🔗 Intelligent curation tagging for creative workflows

🔗 Common CORS errors and how to fix them

🐥 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

🔗 Shell tricks that actually make life easier (and save your sanity)

🔗 Anti-frameworkism: Choosing native web APIs over frameworks

🔗 Laravel raised money and now injects ads directly into your agent

🔗 Migrating from DigitalOcean to Hetzner: from $1,432 to $233/month with zero downtime

🔗 pg_textsearch: How we built a BM25 search engine on Postgres pages

🐥 Make your shell scripts' environment variables overridable

The Problem

The Fix: ${VAR:-default}

Why This Matters

Variants Worth Knowing

A Real-World Example

🔗 Finding my way with AI coding agents

🔗 Every layer of review makes you 10x slower

🔗 EXPLAIN's other superpowers

🔗 Thinking Elixir Podcast 302: BEAM in Your Pocket

🔗 Most devs ignore git worktree. Here's why they're wrong

🐥 Using generators for PHPUnit data providers

Why use generators instead of arrays?

A simple example

Making test cases more expressive

Composing generators

When to prefer generators

Final thoughts

🔗 PHP attributes in Laravel 13: The ultimate guide (36 new attributes!)

🔗 Debugging slow ecto queries with AppSignal

🔗 Did contexts kill Phoenix?

🔗 On knowing what code to throw away

🔗 What I learned from nearly 1,000 interviews at Amazon

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

What's happening?

The fix

Do you need a newer nginx?

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