<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
    <channel>
        <atom:link href="https://mozex.dev/blog/feed" rel="self" type="application/rss+xml" />
        <title><![CDATA[Mozex Labs Blog]]></title>
        <link><![CDATA[https://mozex.dev/blog/feed]]></link>
        <description><![CDATA[Articles about Laravel, PHP, and web development by Mozex.]]></description>
        <language>en</language>
        <pubDate>Mon, 05 Oct 2026 14:00:00 +0300</pubDate>

                    <item>
                <title><![CDATA[Laravel Deadlocks: Queue Jobs That Already Ran End Up in failed_jobs]]></title>
                <link>https://mozex.dev/blog/31-laravel-deadlocks-queue-jobs-that-already-ran-end-up-in-failed-jobs</link>
                <description><![CDATA[I queued 2,000 jobs in a scratch Laravel 13.33.0 app and ran them through eight php artisan queue:work processes against MySQL 5.7. All 2,000 ran. When the workers stopped, 76 of them were still in the jobs table, reserved, and the log had lines that start like this one:
[2026-09-23 20:05:01] local.ERROR: SQLSTATE[40001]: Serialization failure: 1213 Deadlock found when trying to get lock; try restarting transaction (Connection: mysql, Host: 127.0.0.1, Port: 41357, Database: dl, SQL: delete from `jobs` where `id` = 1664)

About 90 seconds later a worker picked the 76 up and moved every one of them to failed_jobs with &quot;App\Jobs\Probe has been attempted too many times.&quot; None of them had failed. Each had finished its work before its row deadlocked.]]></description>
                <author><![CDATA[Mozex]]></author>
                <pubDate>Mon, 05 Oct 2026 14:00:00 +0300</pubDate>
                                    <category>Laravel</category>
                                    <category>PHP</category>
                                    <category>DevOps</category>
                                    <category>Database</category>
                            </item>
                    <item>
                <title><![CDATA[Migrate WordPress Users to Laravel Without a Password Reset]]></title>
                <link>https://mozex.dev/blog/30-migrate-wordpress-users-to-laravel-without-a-password-reset</link>
                <description><![CDATA[I built a WordPress site in Docker to see what a wp_users table holds after WordPress's move to bcrypt: WordPress 6.7.9 first, then an upgrade to 7.1.2, with users created on both versions. Then I copied its eight users, hashes intact, into a fresh Laravel 13.33 app on PHP 8.5 and tried to log each one in.
Seven of the eight logins threw RuntimeException: This password does not use the Bcrypt algorithm. The right password threw it, and so did a wrong one.
WordPress has hashed passwords with bcrypt since 6.8, and Laravel uses bcrypt too, so this looks like it should just work. It fails for two separate reasons, and one of them never shows an error. If you only need the fix, it's two steps: import the rows with the query builder, then register a hasher that knows WordPress's formats. Laravel then replaces each user's hash with a Laravel bcrypt hash on their first login.]]></description>
                <author><![CDATA[Mozex]]></author>
                <pubDate>Fri, 02 Oct 2026 14:00:00 +0300</pubDate>
                                    <category>Laravel</category>
                                    <category>PHP</category>
                                    <category>WooCommerce</category>
                            </item>
                    <item>
                <title><![CDATA[Laravel Tests Fail When Two Runs Overlap, Even With --parallel]]></title>
                <link>https://mozex.dev/blog/29-laravel-tests-fail-when-two-runs-overlap-even-with-parallel</link>
                <description><![CDATA[Whenever two test commands ran inside one of my projects at the same time, they failed, because one run would clear the database under the other. It happened especially when I asked a Claude Code session to hand work to sub-agents: each sub-agent ran the tests for its own change, the runs failed, and it became a loop of discovering the problem and running it again.
For this post I reproduced it on a fresh Laravel app whose phpunit.xml points at MySQL, with 1,201 tests, 1,200 of them using RefreshDatabase. Run alone, before any fix, the suite passes in under a minute. I started php artisan test twice at the same moment, three times. All six runs failed 1,167 to 1,200 of their 1,201 tests, and each took 3.5 to 4.4 minutes.
The fix is my package mozex/laravel-test-lanes. Install it with composer require mozex/laravel-test-lanes --dev and there's nothing else to set up. With it, those runs pass. Everything here ran on Laravel 13.33, PHP 8.5, PHPUnit 12.5 with ParaTest 7.20, and MySQL 8.4 on Windows 11, with version 1.1.1 of the package (Laravel 11 to 13, PHP 8.2+, MySQL, MariaDB and PostgreSQL).]]></description>
                <author><![CDATA[Mozex]]></author>
                <pubDate>Wed, 30 Sep 2026 14:00:00 +0300</pubDate>
                                    <category>Laravel</category>
                                    <category>PHP</category>
                                    <category>Testing</category>
                                    <category>Open Source</category>
                                    <category>Database</category>
                            </item>
                    <item>
                <title><![CDATA[Parallel Claude Code Sessions in Laravel: A Copied .env Shares Your MySQL Database]]></title>
                <link>https://mozex.dev/blog/28-parallel-claude-code-sessions-in-laravel-a-copied-env-shares-your-mysql-database</link>
                <description><![CDATA[I'd have a Claude Code session working in a project and want to get on with something else while it ran. A second session in the same checkout wasn't the answer: neither session would know the other was working, so they'd interfere with each other's work and end up reverting each other's changes. Running two test commands at once caused problems too, because both ran against one database.
Git worktrees fix the files: each session gets its own directory and branch. In a worktree with a copied .env, one migrate:fresh took the main checkout's users table in my test app from 1,000 rows to 0. I built mozex/laravel-worktree for this problem: one command gives each worktree its own database, test database, .env and Herd site. If you'd rather script it yourself, read the section on unsetting the parent's environment first, because the obvious Artisan command still emptied the main database in my test.
Everything here ran on a fresh Laravel 13.33 app with MySQL 8.4 and PHP 8.5, served by Laravel Herd 1.30 on Windows 11, with version 1.6.0 of the package (it supports Laravel 11 to 13, PHP 8.2+, MariaDB and PostgreSQL; WORKTREE_HERD=none skips Herd).]]></description>
                <author><![CDATA[Mozex]]></author>
                <pubDate>Mon, 28 Sep 2026 14:00:00 +0300</pubDate>
                                    <category>Claude Code</category>
                                    <category>Developer Tools</category>
                                    <category>Laravel</category>
                                    <category>PHP</category>
                                    <category>Open Source</category>
                            </item>
                    <item>
                <title><![CDATA[Laravel 12 to 13: The Config Sync That Logs Users Out and Breaks the Cache]]></title>
                <link>https://mozex.dev/blog/27-laravel-12-to-13-the-config-sync-that-logs-users-out-and-breaks-the-cache</link>
                <description><![CDATA[I upgraded a Laravel 12 app to 13 in two stages and recorded what each stage did to its cache, its sessions and its queue. The app came from the laravel/laravel 12.0.11 skeleton (June 2025), ran framework 12.69.2, and used Redis for all three. Before the upgrade it held 14 cached values, one logged-in visitor and one queued job.
composer update to 13.33.0 changed none of that. All 14 values read back, the visitor stayed logged in, the job waited. Then I copied the 13 skeleton's config/cache.php, config/session.php and config/database.php over the app's, one file at a time. Every cached key missed, the visitor was logged out, the job vanished from the worker's view, and a cached Eloquent collection came back as __PHP_Incomplete_Class.]]></description>
                <author><![CDATA[Mozex]]></author>
                <pubDate>Fri, 25 Sep 2026 14:00:00 +0300</pubDate>
                                    <category>Laravel</category>
                                    <category>PHP</category>
                                    <category>DevOps</category>
                            </item>
                    <item>
                <title><![CDATA[Laravel chunk vs lazy vs cursor: lazy() Is as Slow as chunk()]]></title>
                <link>https://mozex.dev/blog/26-laravel-chunk-vs-lazy-vs-cursor-lazy-is-as-slow-as-chunk</link>
                <description><![CDATA[I seeded a MySQL table with 1,000,000 orders and walked through every row with each of five Laravel methods for iterating a big query: chunk(), chunkById(), lazy(), lazyById() and cursor(). chunkById() finished in 21.9 seconds and lazyById() in 22.3, neither above 5.9 MB of PHP memory. chunk() and lazy() held just as little and took about six times as long. cursor(), which the Laravel docs offer as a way to &quot;significantly reduce your application's memory consumption&quot;, finished behind both ById methods and held 100.4 MB.]]></description>
                <author><![CDATA[Mozex]]></author>
                <pubDate>Wed, 23 Sep 2026 14:00:00 +0300</pubDate>
                                    <category>Laravel</category>
                                    <category>PHP</category>
                                    <category>Performance</category>
                                    <category>Database</category>
                            </item>
                    <item>
                <title><![CDATA[ShouldBeUnique vs WithoutOverlapping: Neither Sets a Lock Expiry for You]]></title>
                <link>https://mozex.dev/blog/25-shouldbeunique-vs-withoutoverlapping-neither-sets-a-lock-expiry-for-you</link>
                <description><![CDATA[Here's a key that was sitting in my Redis a few minutes ago:
$ redis-cli --scan --pattern &quot;*overlap*&quot;
laravel-database-laravel-cache-laravel-queue-overlap:App\Jobs\SyncFeed:feed

$ redis-cli TTL &quot;laravel-database-laravel-cache-laravel-queue-overlap:App\Jobs\SyncFeed:feed&quot;
-1

A TTL of -1 is Redis for &quot;this key exists and nothing will expire it&quot;. Its owner is a worker process I killed a minute earlier. The job it was protecting never finished and never will: it's in failed_jobs with a MaxAttemptsExceededException. Every later dispatch of SyncFeed fails the same way.
Laravel calls four different things a lock, and ShouldBeUnique and WithoutOverlapping are two of them. This post puts all four side by side in a scratch app on Laravel 13.32.0, PHP 8.5, with Redis 8 and the database store on SQLite: the key each one writes, the default expiry, where the lock is taken, where it's given back, and what can clear it when something goes wrong.]]></description>
                <author><![CDATA[Mozex]]></author>
                <pubDate>Mon, 21 Sep 2026 14:00:00 +0300</pubDate>
                                    <category>Laravel</category>
                                    <category>PHP</category>
                                    <category>DevOps</category>
                            </item>
                    <item>
                <title><![CDATA[Two Fixes Made Claude Code 15x Faster Per Command on Windows]]></title>
                <link>https://mozex.dev/blog/24-two-fixes-made-claude-code-15x-faster-per-command-on-windows</link>
                <description><![CDATA[I ran echo in Claude Code 178 times last week. Median time: 7,395 milliseconds.
Not a build. Not a test suite. A command that prints a word and exits. I'd filtered down to commands that do nothing at all, no pipes, no loops, no subshells, because I wanted to know what the tool costs when it isn't doing anything.
Claude Code had felt heavy for weeks. I'm on Windows 11 with Claude Code running through Git Bash, and I'd filed the sluggishness under &quot;the model is thinking.&quot; It wasn't the model. Two local fixes later, that same echo returns in under half a second and a file read went from 909 ms to 24 ms.]]></description>
                <author><![CDATA[Mozex]]></author>
                <pubDate>Mon, 03 Aug 2026 14:00:00 +0300</pubDate>
                                    <category>Claude Code</category>
                                    <category>Bash</category>
                                    <category>Developer Tools</category>
                                    <category>Performance</category>
                                    <category>Windows</category>
                            </item>
                    <item>
                <title><![CDATA[Anthropic Prompt Caching in Laravel: A Practical Guide]]></title>
                <link>https://mozex.dev/blog/18-anthropic-prompt-caching-in-laravel-a-practical-guide</link>
                <description><![CDATA[Running Sevantia, our AI chat product, I watched the same 2,800-token system prompt get re-billed on every single user message. Multiply that by thousands of conversations a day and you're paying Anthropic to re-read the same instructions into Claude's context over and over. Prompt caching fixes this. It took me longer than it should have to get the mental model right, and the docs skip over the parts that trip up most people.
This is the guide I wish I'd had when I first enabled it.]]></description>
                <author><![CDATA[Mozex]]></author>
                <pubDate>Mon, 20 Apr 2026 14:00:00 +0300</pubDate>
                                    <category>Laravel</category>
                                    <category>PHP</category>
                                    <category>AI</category>
                                    <category>Tutorial</category>
                                    <category>Anthropic</category>
                            </item>
                    <item>
                <title><![CDATA[5 Laravel Scheduler Failures That Only Show Up in Production]]></title>
                <link>https://mozex.dev/blog/17-5-laravel-scheduler-failures-that-only-show-up-in-production</link>
                <description><![CDATA[&quot;But it worked locally.&quot; The Laravel scheduler is the duct tape of every production app I've worked on. It triggers the reports, cleans up expired data, pings the health checks, rotates the tokens, sends the digests. It works quietly for weeks, then one morning the team realises nothing has run for six days and nobody got an alert.
If you've already read my queue worker version of this list, the scheduler has its own set of silent failure modes. Every one below cost me or a client real money or real trust. None of them show up in php artisan schedule:list. All of them are avoidable once you know where to look.
Examples target Laravel 11 and later (so routes/console.php and bootstrap/app.php). On Laravel 10 and earlier, the same calls live in the schedule() method of App\Console\Kernel.]]></description>
                <author><![CDATA[Mozex]]></author>
                <pubDate>Wed, 15 Apr 2026 20:25:00 +0300</pubDate>
                                    <category>Laravel</category>
                                    <category>PHP</category>
                                    <category>DevOps</category>
                            </item>
                    <item>
                <title><![CDATA[The Laravel Bug Your Tests Will Never Catch]]></title>
                <link>https://mozex.dev/blog/16-the-laravel-bug-your-tests-will-never-catch</link>
                <description><![CDATA[In a previous post, I listed &quot;your job runs before the data exists&quot; as one of five queue failures that only show up in production. I showed the afterCommit() fix and moved on.
But that post didn't answer the question that kept nagging me: why do your tests always pass when this bug is sitting right in your code? And where else in your app is this same timing problem hiding, beyond direct dispatch() calls?
This post digs into both.]]></description>
                <author><![CDATA[Mozex]]></author>
                <pubDate>Wed, 15 Apr 2026 12:00:00 +0300</pubDate>
                                    <category>Laravel</category>
                                    <category>PHP</category>
                                    <category>Testing</category>
                                    <category>Database</category>
                            </item>
                    <item>
                <title><![CDATA[How I Audit a New Laravel Codebase in 30 Minutes]]></title>
                <link>https://mozex.dev/blog/15-how-i-audit-a-new-laravel-codebase-in-30-minutes</link>
                <description><![CDATA[When a client asks me to look at their Laravel application, I don't start by reading code. I run a specific sequence of checks that tells me more in 30 minutes than reading source files for a full day would.
This isn't a full audit. It's triage. After working with Laravel for over a decade, I've found that a handful of structural checks reveal 80% of the problems. The patterns are surprisingly consistent.
Here's the exact process I follow.]]></description>
                <author><![CDATA[Mozex]]></author>
                <pubDate>Mon, 13 Apr 2026 12:00:00 +0300</pubDate>
                                    <category>Laravel</category>
                                    <category>PHP</category>
                                    <category>Architecture</category>
                                    <category>Code Review</category>
                            </item>
                    <item>
                <title><![CDATA[A Practical Guide to Database Indexing in Laravel]]></title>
                <link>https://mozex.dev/blog/14-a-practical-guide-to-database-indexing-in-laravel</link>
                <description><![CDATA[Your queries work fine in development. Fifty rows, instant responses, no complaints. Then you deploy to production, real data piles up, and a page that loaded in 200ms takes four seconds.
The problem usually isn't your Eloquent code. It's the indexes you forgot to add.]]></description>
                <author><![CDATA[Mozex]]></author>
                <pubDate>Thu, 09 Apr 2026 14:00:00 +0300</pubDate>
                                    <category>Laravel</category>
                                    <category>PHP</category>
                                    <category>Tutorial</category>
                                    <category>Performance</category>
                                    <category>Database</category>
                            </item>
                    <item>
                <title><![CDATA[Building a Production-Ready Laravel MCP Server]]></title>
                <link>https://mozex.dev/blog/13-building-a-production-ready-laravel-mcp-server</link>
                <description><![CDATA[Every Laravel developer has seen the MCP hype by now. Laravel's tagline changed to &quot;The clean stack for Artisans and agents.&quot; The laravel/mcp package landed, tutorials appeared overnight, and suddenly everyone's building weather tools.
But those tutorials stop right where real questions start. How do you authenticate AI clients hitting your server? What happens when an agent sends garbage to a tool that writes to your database? Should you even use MCP, or is your REST API already enough?
I've been digging into this for a project, and these are the decisions and patterns I wish someone had documented before I started.]]></description>
                <author><![CDATA[Mozex]]></author>
                <pubDate>Wed, 08 Apr 2026 14:00:00 +0300</pubDate>
                                    <category>Laravel</category>
                                    <category>PHP</category>
                                    <category>AI</category>
                                    <category>MCP</category>
                            </item>
                    <item>
                <title><![CDATA[5 Laravel Queue Failures That Only Show Up in Production]]></title>
                <link>https://mozex.dev/blog/12-5-laravel-queue-failures-that-only-show-up-in-production</link>
                <description><![CDATA[Your queue works perfectly in local. Every job dispatches, processes, and completes without a hitch. Then you deploy to production with real traffic, real concurrency, and real third-party APIs, and things start breaking in ways your test suite never predicted.
I've been running Laravel queues in production for years across multiple applications. Every failure on this list caught me off guard at least once. Not because the documentation doesn't cover them, but because you don't think about them until they bite you at 2 AM.]]></description>
                <author><![CDATA[Mozex]]></author>
                <pubDate>Tue, 07 Apr 2026 14:00:00 +0300</pubDate>
                                    <category>Laravel</category>
                                    <category>PHP</category>
                                    <category>DevOps</category>
                            </item>
                    <item>
                <title><![CDATA[Use Laravel's route(), url(), and asset() Helpers Inside Markdown]]></title>
                <link>https://mozex.dev/blog/11-use-laravels-route-url-and-asset-helpers-inside-markdown</link>
                <description><![CDATA[I had a Laravel project designed to be white-labeled. Swap an env file, change the domain, and the whole application launches as a completely different product.
The problem was the Markdown files.]]></description>
                <author><![CDATA[Mozex]]></author>
                <pubDate>Mon, 06 Apr 2026 14:00:00 +0300</pubDate>
                                    <category>Laravel</category>
                                    <category>PHP</category>
                                    <category>Open Source</category>
                                    <category>Markdown</category>
                            </item>
                    <item>
                <title><![CDATA[How a Rejected PR Became Laravel Scout Bulk Actions]]></title>
                <link>https://mozex.dev/blog/10-how-a-rejected-pr-became-laravel-scout-bulk-actions</link>
                <description><![CDATA[If you've used Laravel Scout on a project with more than a couple of searchable models, you know the drill. You change something in your toSearchableArray(), and now you need to flush and reimport every model's index. Two commands per model. Manually. One at a time.
On a project with ten searchable models, that's twenty commands to rebuild your search indexes.]]></description>
                <author><![CDATA[Mozex]]></author>
                <pubDate>Fri, 03 Apr 2026 14:00:00 +0300</pubDate>
                                    <category>Laravel</category>
                                    <category>PHP</category>
                                    <category>Open Source</category>
                            </item>
                    <item>
                <title><![CDATA[Why I Built a PHP Client for Anthropic's Claude API]]></title>
                <link>https://mozex.dev/blog/9-why-i-built-a-php-client-for-anthropics-claude-api</link>
                <description><![CDATA[In May 2024, I published the first version of anthropic-php, a PHP client for Anthropic's Claude API. Nearly two years later, when I wrote this post in April 2026, it had passed 370,000 downloads, more than any other dedicated Anthropic client for PHP at the time. This is the story of why I built it, what it can do, and why I think packages born from real necessity tend to be the good ones.]]></description>
                <author><![CDATA[Mozex]]></author>
                <pubDate>Thu, 02 Apr 2026 13:00:00 +0300</pubDate>
                                    <category>Laravel</category>
                                    <category>PHP</category>
                                    <category>Open Source</category>
                                    <category>AI</category>
                                    <category>Anthropic</category>
                            </item>
                    <item>
                <title><![CDATA[My Zero-Downtime Deployment Setup for Laravel]]></title>
                <link>https://mozex.dev/blog/8-my-zero-downtime-deployment-setup-for-laravel</link>
                <description><![CDATA[I've been deploying Laravel applications for over a decade. Started with custom bash scripts. Moved to Laravel Envoy. Then Laravel Envoyer, which worked great for a long time. Eventually moved away from it to Ploi.io so I could manage deployments and servers in one place.
Each tool taught me something the previous one didn't. And the biggest lesson wasn't about tools at all. It was about the small practices around deployment that separate &quot;mostly works&quot; from &quot;actually works every time.&quot;
Zero-downtime deployment is widely available now. Most hosting panels and deployment services support it out of the box. But to get the most out of it, there are practices you need to get right. That's what this post covers.]]></description>
                <author><![CDATA[Mozex]]></author>
                <pubDate>Wed, 01 Apr 2026 01:35:05 +0300</pubDate>
                                    <category>Laravel</category>
                                    <category>PHP</category>
                                    <category>Tutorial</category>
                                    <category>DevOps</category>
                            </item>
                    <item>
                <title><![CDATA[WooCommerce to Laravel Migration: The Parts Nobody Talks About]]></title>
                <link>https://mozex.dev/blog/6-woocommerce-to-laravel-migration-the-parts-nobody-talks-about</link>
                <description><![CDATA[If you've run a WooCommerce store long enough, you've felt the slowdown. Pages take longer to load. The admin panel becomes sluggish. Checkout starts timing out during traffic spikes. You throw caching at it, upgrade your hosting, install optimization plugins. It helps for a while. Then it doesn't.
I've been building with PHP and Laravel for over ten years, and I've migrated production WooCommerce stores to custom Laravel applications. Not as a theoretical exercise, but because the stores hit a wall that no amount of WordPress optimization could fix.
Here's what that process actually looks like, including the parts the generic migration guides conveniently skip.]]></description>
                <author><![CDATA[Mozex]]></author>
                <pubDate>Sun, 29 Mar 2026 20:44:35 +0300</pubDate>
                                    <category>Laravel</category>
                                    <category>PHP</category>
                                    <category>Architecture</category>
                                    <category>WooCommerce</category>
                            </item>
                    <item>
                <title><![CDATA[Which AI Package Should You Actually Use in Laravel?]]></title>
                <link>https://mozex.dev/blog/5-which-ai-package-should-you-actually-use-in-laravel</link>
                <description><![CDATA[Eighteen months ago, using Claude or GPT from a Laravel app meant writing raw HTTP calls or using whatever half-maintained wrapper you could find on Packagist. Today there are four solid options, all actively maintained, all with real download numbers behind them.
I maintain one of them. anthropic-php and its Laravel companion anthropic-laravel have a combined 597,000 installs on Packagist. I've been building and shipping AI features in PHP since before most of these packages existed. So when people ask me &quot;which one should I use?&quot;, I have opinions. They might surprise you.
Here's the honest breakdown.]]></description>
                <author><![CDATA[Mozex]]></author>
                <pubDate>Sat, 28 Mar 2026 17:37:39 +0300</pubDate>
                                    <category>Laravel</category>
                                    <category>PHP</category>
                                    <category>Open Source</category>
                                    <category>AI</category>
                            </item>
                    <item>
                <title><![CDATA[Why I Built My Own Laravel Modules Package]]></title>
                <link>https://mozex.dev/blog/4-why-i-built-my-own-laravel-modules-package</link>
                <description><![CDATA[In late 2023, I was working on a large Laravel project and hit a point where the app/ directory had become a mess. Models, controllers, services, policies, listeners, jobs, notifications, all thrown into flat directories with no logical grouping. Everything related to billing lived next to everything related to user management. Finding anything required memorizing file names instead of following a structure.
I knew the answer was modular architecture. Break the application into self-contained modules where each module owns its models, controllers, migrations, routes, views, and everything else related to that feature. I'd seen this pattern work in other frameworks and it made perfect sense for Laravel.
So I looked at what was available. I tried several packages. None of them clicked.
I started building my own solution inside that project. As it grew and I wanted the same structure in my other projects, I extracted it into an open-source package: mozex/laravel-modules.]]></description>
                <author><![CDATA[Mozex]]></author>
                <pubDate>Fri, 27 Mar 2026 03:38:21 +0300</pubDate>
                                    <category>Laravel</category>
                                    <category>PHP</category>
                                    <category>Open Source</category>
                                    <category>Architecture</category>
                            </item>
                    <item>
                <title><![CDATA[Wispr Flow: Why I Dictate Everything Instead of Typing]]></title>
                <link>https://mozex.dev/blog/3-wispr-flow-why-i-dictate-everything-instead-of-typing</link>
                <description><![CDATA[This is the first post in what I plan to be a collection of tools and software I use regularly. No sponsorships, no affiliate links, no partnerships. Just software that changed how I work, shared because I think you might benefit from it too.
Let's start with the one that had the biggest impact on my daily routine: Wispr Flow.]]></description>
                <author><![CDATA[Mozex]]></author>
                <pubDate>Tue, 24 Mar 2026 14:37:20 +0300</pubDate>
                                    <category>Developer Tools</category>
                                    <category>Productivity</category>
                            </item>
                    <item>
                <title><![CDATA[Fixing Pest Sharding for Modular Laravel Applications]]></title>
                <link>https://mozex.dev/blog/2-fixing-pest-sharding-for-modular-laravel-applications</link>
                <description><![CDATA[When Pest v4 dropped, one feature got my attention right away: test sharding. My CI pipelines were painfully slow, and splitting tests across parallel GitHub Actions runners seemed like the obvious fix.
I upgraded, configured the shards, pushed to CI, and waited.
Every shard ran every test. Shard 1 of 4? Full suite. Shard 3 of 4? Full suite. My &quot;optimization&quot; made things four times worse.]]></description>
                <author><![CDATA[Mozex]]></author>
                <pubDate>Tue, 24 Mar 2026 03:03:04 +0300</pubDate>
                                    <category>Laravel</category>
                                    <category>PHP</category>
                                    <category>Testing</category>
                                    <category>Pest</category>
                                    <category>GitHub Actions</category>
                            </item>
                    <item>
                <title><![CDATA[My Claude Code Status Line: Usage, Pace, and Context at a Glance]]></title>
                <link>https://mozex.dev/blog/1-my-claude-code-status-line-usage-pace-and-context-at-a-glance</link>
                <description><![CDATA[I've been using Claude Code as my daily driver for a while now. One thing that kept bugging me was not knowing where I stood with my usage limits until I actually hit them. Claude Code has a status line feature that lets you run a custom script and display whatever you want at the bottom of the terminal. I built one that shows me everything I care about in a single line.
Freek Van der Herten wrote a nice post about his own status line showing the repo name and context window percentage. That was my starting point, but I wanted more: rate limit tracking, reset countdowns, and a pace indicator that tells me whether I'm burning through my weekly budget too fast.]]></description>
                <author><![CDATA[Mozex]]></author>
                <pubDate>Sun, 22 Mar 2026 15:41:11 +0300</pubDate>
                                    <category>Claude Code</category>
                                    <category>Bash</category>
                                    <category>Developer Tools</category>
                            </item>
            </channel>
</rss>
