Blog

Testing regex patterns before committing them? Don’t fire up a whole test suite. Use tinker --execute for instant validation.

The Fast Way

Laravel’s tinker has an --execute flag that runs code and exits. Perfect for one-liner regex tests:

php artisan tinker --execute="var_dump(preg_match('/^(?=.*cat)(?=.*dog)/', 'cat and dog'))"

Output: int(1) (match found)

Try another:

php artisan tinker --execute="var_dump(preg_match('/^(?=.*cat)(?=.*dog)/', 'only cat here'))"

Output: int(0) (no match)

Why It’s Better

No need to:

• Write a test file
• Create a route
• Open an interactive REPL session
• Fire up PHPUnit

Just run, check output, adjust pattern, run again. Fast feedback loop.

Takeaway

Use tinker --execute for quick regex (and other code) validation. It runs in your app context with all your dependencies loaded. Way faster than writing throwaway test files.

Here’s a fun edge case: WSL2 can boot faster than Windows services start. Your boot script tries to mount a network drive? Fails. Connect to a VPN? Not running yet. Access a Windows service? Still loading.

The Race Condition

WSL2 starts almost instantly when Windows boots. Windows services? They take their sweet time. If your WSL boot script depends on them, you’ll get random failures on startup.

The Fix: Retry Loop

Instead of hoping the service is ready, add a retry loop with exponential backoff:

#!/bin/bash
MAX_RETRIES=5
RETRY=0

while [ $RETRY -lt $MAX_RETRIES ]; do
    if mount_network_drive; then
        echo "Mounted successfully"
        break
    fi
    RETRY=$((RETRY + 1))
    sleep $((2 ** RETRY))  # 2, 4, 8, 16, 32 seconds
done

Takeaway

WSL2 boot scripts can’t assume Windows is fully ready. Add retries with backoff for anything that depends on Windows services. Your future self will thank you when it works on the first boot after a restart.

You’re building a workflow. When an order is cancelled, you need to process a refund. The straightforward approach: call the refund service directly.

But that creates coupling you’ll regret later.

The Tight-Coupling Trap

Here’s what most developers write first:

class CancelOrderService
{
    public function __construct(
        private RefundService $refundService
    ) {}
    
    public function cancel(Order $order): void
    {
        $order->update(['status' => 'cancelled']);
        
        // Directly call refund logic
        if ($order->payment_status === 'paid') {
            $this->refundService->process($order);
        }
    }
}

This works. But now:

• CancelOrderService knows about refunds
• Adding more post-cancellation logic (notifications, inventory updates, analytics) means editing this class every time
• Testing cancellation requires mocking refund logic

You’ve tightly coupled two separate concerns.

Event-Driven Decoupling

Instead, dispatch an event and let listeners handle side effects:

class CancelOrderService
{
    public function cancel(Order $order): void
    {
        $order->update(['status' => 'cancelled']);
        
        // Broadcast what happened, don't dictate what happens next
        event(new OrderCancelled($order));
    }
}

Now the cancellation service doesn’t know or care what happens after. It announces the cancellation and moves on.

Listeners Do the Work

Register listeners to handle post-cancellation tasks:

// app/Providers/EventServiceProvider.php

protected $listen = [
    OrderCancelled::class => [
        ProcessAutomaticRefund::class,
        NotifyCustomer::class,
        UpdateInventory::class,
        LogAnalytics::class,
    ],
];

Each listener is independent:

class ProcessAutomaticRefund
{
    public function __construct(
        private RefundService $refundService
    ) {}
    
    public function handle(OrderCancelled $event): void
    {
        $order = $event->order;
        
        if ($order->payment_status === 'paid') {
            $this->refundService->process($order);
        }
    }
}

Now you can:

• Add listeners without touching the cancellation logic
• Remove listeners when features are deprecated
• Test independently — cancel logic doesn’t know refund logic exists
• Queue listeners individually for better performance

When to Use Events

Use events when:

• Multiple things need to happen: One action triggers several side effects
• Logic might expand: You anticipate adding more post-action tasks
• Cross-domain concerns: Orders triggering inventory, notifications, analytics
• Async processing: Some tasks can be queued, others need to run immediately

Skip events when:

• Single responsibility: Only one thing ever happens
• Tight integration required: Caller needs return values or transaction control
• Simple workflows: Over-engineering a two-step process

Bonus: Queue Listeners Selectively

Make slow listeners async:

class NotifyCustomer implements ShouldQueue
{
    public function handle(OrderCancelled $event): void
    {
        // Runs in background, doesn't slow down cancellation
        Mail::to($event->order->customer)->send(new OrderCancelledEmail());
    }
}

Now critical listeners (refund) run immediately, while optional ones (email) queue in the background.

The Takeaway

Stop calling side effects directly. Dispatch events instead. Your code becomes more modular, testable, and flexible. When requirements change (they always do), you add a listener instead of refactoring core logic.

Events aren’t overkill — they’re how you build systems that scale without breaking.