Blog Title

Crumb Crusted Protein recipe

2026-05-13T01:59:38Z

Crumb Crusted Protein

You will need

1/2 cup bread crumbs
1/2 tsp House Salt
1 tsp italian seasoning
1/2 tsp grated Parmesan cheese product
2 portions of protein (chicken breast, pork chop, whatever floats your boat)

Instructions

Combine dry ingredients in a gallon-sized zip bag
Pat protein dry
Slather protein in Duke's Mayonnaise
Shake protein in zip bag with dry ingredients to coat.
Bake on a cooking rack over a baking sheet at 350 F until done. Use a thermometer to check doneness.

Optional changes

If you have the cheese in the green container, and you're in a hurry, go ahead and use it. Only you will know. Want to be cheesier? Add more.
Add a slice or two of provolone cheese to the chicken about 5 minutes before cooking is finished, top with your favorite tomato-based pasta sauce and serve on top of a bed of spaghetti.
Substitute Ranch Seasoning for the Italian seasoning and house salt.

House Salt

1/2 tbsp table salt
1/4 tbsp pepper
1/4 tbsp garlic powder.

Combine and store in a sealed container.

Make this in whatever volume you want, just know that the garlic powder may clump with the salt and pepper, so only make what you're going to use in a month.

My simple Baked Ziti recipe

2026-05-13T01:59:38Z

You will need

1 egg
15 oz ricotta cheese (whole milk best)
16 oz (1 lb) mozzarella cheese (shredded)
24 oz of your favorite pasta sauce
1 lb ziti

Instructions

Preheat oven to 350 F;
Grease a 13x9 baking pan
Prepare ziti according to instructions. Reduce cooking time by about 2 minutes. Pasta will finish cooking while baking;
Whisk 1 egg;
Combine whisked egg with Ricotta Cheese in a very large bowl;
Combine shredded mozzarella with egg/ricotta mixture;
Combine 3/4 pasta sauce with egg/cheese mixture;
Toss in some Italian Seasoning and some red pepper flakes;
Combine cooked ziti in sauce mixture;
Spread ziti mixture in the greased 13x9 baking pan;
Cover ziti with remaining pasta sauce;
Top with additional cheese of your choice or reserve some shredded mozzarella;
Bake in the preheated oven for 25-30 minutes;
Let cool until molten cheese does not melt your face;
Enjoy with your choice of garlic or cheese toast and your favorite salad and beverage.

Optional changes

Add some crumbled sausage or seasoned browned ground beef in the mixture.
Top it with some panko crumbs.
Add a small can of sliced black olives (drained).
Instead of tomato-based pasta sauce, use a béchamel sauce and sliced chicken.

Go ahead and keep it simple, though. If you're the kind of person who will make your own sauce, you probably shouldn't even be looking here.

Using a logged-in User in Tinker

2026-05-13T01:59:38Z

During Laravel testing, we can use the actingAs() method to authenticate a user into the testing environment.

class ExampleTest extends TestCase
{
    #[Test]
    public function authenticated_user_can_see_dashboard(): void
    {
        $this->actingAs(User::factory()->create())
           ->get('/dashboard')
           ->assertOk();
    }
}

I have an event in a model that requires the authenticated User:

class Organization extends Model
{
    #[\Override]
    protected static function booted(): void
    {
        static::created(static function (Organization $organization) {
            OrganizationCreatedEvent::dispatch($organization, Auth::user());
        });
    }
}

During testing, we use the actingAs() method to fill the Auth::user() model, but what happens when we need to create an Organization in the tinker shell?

> $o = Organization::factory()->create()

   TypeError  App\Events\OrganizationCreated::__construct(): Argument #2 ($user) must be of type App\Models\User, null given, called in vendor/laravel/framework/src/Illuminate/Foundation/Events/Dispatchable.php on line 15.

> $this->actingAs($user)

   Error  Using $this when not in object context.

We can't use $this-> because, like the error message says, we're not in an object.

But it's easy enough to add the user:

> $user = User::factory()->create();

[!] Aliasing 'User' to 'App\Models\User' for this Tinker session.
= App\Models\User {#8767
    name: "Mrs. Candace Runolfsdottir",
    email: "wauvot.kiara.borer@example.net",
    email_verified_at: "2026-05-08 14:43:37",
    #password: "\$2y\$12\$ehsEQzkwABxZiH37PT1zpuQsR5ncLR1A78hEYPYMTAL1gxr..9XV6",
    #remember_token: "lnVyiUqw6d",
    #two_factor_secret: null,
    #two_factor_recovery_codes: null,
    two_factor_confirmed_at: null,
    updated_at: "2026-05-08 14:43:37",
    created_at: "2026-05-08 14:43:37",
    id: 4,
  }

>  app('auth')->guard(null)->setUser($user);

= Illuminate\Auth\SessionGuard {#8687
    +name: "web",
  }

> $o = Organization::factory()->create()

[!] Aliasing 'Organization' to 'App\Models\Organization' for this Tinker session.
= App\Models\Organization {#9165
    name: "Reilly Ltd",
    updated_at: "2026-05-08 14:43:52",
    created_at: "2026-05-08 14:43:52",
    id: 2,
  }

Now the only thing I need to do is figure out how to fake or skip a Notification automatically while in the tinker console.

Remove TLS domains from Traefik

2026-05-13T01:59:38Z

When using Traefik as an application proxy, there is a minor shortcoming, and that is the fact that it uses the acme.json file to renew the domain names instead of using active HTTP Routers. Advantages and disadvantages to either one. I'm not in charge of that, so I can't change it, but what I can do is work around it.

I have some domains that I didn't renew, and domains that I have graduated to GitLab Pages, but traefik keeps trying to renew the domain. The way to make Traefik know to not renew the certificate is to remove it from the acme.json file.

Sure, you could use nano or your favorite text editor to modify acme.json, but the lines can get long, and it's easy to make errors. Luckly, there is jq to the rescue. So let's wrap it inside a nice BASH script so we don't break files and it's easy to remove domains that we don't want anymore.

#!/bin/bash
# remove-domain: Remove a domain from Traefik's acme.json
#
# Usage: ./remove-domain <domain-to-remove> [resolver]
#   - <domain-to-remove> : domain you want to remove from acme.json
#   - [resolver]         : top-level key in acme.json (defaults to 'lets-encrypt')
#                          This should match a key in your traefik.yml
# Example:
#   ./remove-domain www.example.com
#   ./remove-domain www.example.com valentinesresolver

set -e

# === Sanity check: Ensure jq is installed ===
JQ_CMD=$(command -v jq || true)
if [ -z "$JQ_CMD" ]; then
  echo "Error: jq is not installed or not in your PATH. Aborting."
  exit 1
fi

# === User-configurable variables ===

# Directory containing acme.json (must end with /)
ACME_DIR="/path/to/traefik/"
ACME_FILE_NAME="acme.json"
RESOLVER="${2:-lets-encrypt}"  # Default resolver; should match traefik.yml certificatesResolvers key

# certificatesResolvers:
#  lets-encrypt: <-- *this* should match $RESOLVER, or pass it as the second parameter.

# === End of user-configurable variables ===

# Check input
if [ -z "$1" ]; then
  echo "Usage: $0 <domain-to-remove> [resolver]"
  exit 1
fi

DOMAIN="$1"

TIMESTAMP=$(date +%Y%m%d%H%M)
BACKUP_FILE="${ACME_DIR}acme-${TIMESTAMP}.json"
ACME_FILE="${ACME_DIR}${ACME_FILE_NAME}"

# Backup acme.json
cp "$ACME_FILE" "$BACKUP_FILE"
echo "Backup created: $BACKUP_FILE"

# Remove domain from specified resolver
jq --arg domain "$DOMAIN" --arg resolver "$RESOLVER" '
  del(
    .[$resolver].Certificates[]
    | select(
        (.domain.main == $domain)
        or (.domain.sans // [] | index($domain))
      )
  )
' "$ACME_FILE" > "${ACME_FILE}.tmp"

# Replace acme.json with updated version and fix permissions
mv "${ACME_FILE}.tmp" "$ACME_FILE"
chmod 600 "$ACME_FILE"

echo "Domain '$DOMAIN' removed from $ACME_FILE under resolver '$RESOLVER'"
echo "You should restart Traefik because $ACME_FILE is not hot-reloadable."

Just a couple of caveats, though. This is not atomic; if you run this command when Traefik is creating or renewing a certificate, it might break. But it make a backup, so you're not going to be entirely hosed. Also, the acme.json file is not hot-reloadable; restart Traefik after modifing the acme.json file.

Rule 13

2026-05-07T00:00:00Z

Rule 13 states that when you give a document to someone else to proofread, always leave a simple, intentional error in the document. Don't make it obvious, like misspelling the very last word or the main title, but keep it in there somewhere.

If they don't tell you about the error, they probably didn't read it. Ask someone else to proofread your document.

Converting this site from Jekyll to eleventy

2026-03-17T00:00:00Z

The original template of this site was one that came with the script to convert a yaml array of my portfolio projects into a portfolio page. It was probably good back in the days when the template was originally designed, but I don't like it any more, so I'm switching to the eleventy static site generator, and their official starter. Obviously since it's the official starter, this has to look better, right?

Getting a clean working directory

Since I don't really want to lose all the existing git history, I'm starting with a git worktree and an orphan branch.

git worktree add ../11ty.jeffharris.us
cd ../11ty.jeffharris.us
git switch --orphan 11ty

Sweet. Now I copied the base blog files into my directory, added some scripts to my package.json file:

  "scripts": {
"test": "echo \"Error: no test specified\" && exit 1",
"build": "npx @11ty/eleventy",
"serve": "npx @11ty/eleventy --serve"
},

And fire up my npm run serve development server, making necessary changes to the _data/metadata.js file and updating my gitlab-ci.yml file. Static content transfers over easily.

Posts transfer over mostly the same, except for post categories. Maybe by the time you see this, it will be all set.

I did find that I had this code block that nunjucks comaplained about:

> $createdAt = Carbon::parse('2025-01-01 09:00:00', new DateTimeZone('America/New_York'))
= Carbon\Carbon @1735740000 {#5241
    date: 2025-01-01 09:00:00.0 America/New_York (-05:00),
  }

Do you see it? {#5241 looks to nunjucks like the beginning of a comment that never ends.

That's solved either by wrapping the blocks in a {% raw %}...{% endraw %} block, or by disabling Nunjucks on the page by adding frontmatter

templateEngineOverride: md

The things that need additional setup, that don't come right out of the box:

Portfolio page;
JavaScript on the front page gathering the local weather;
Category pages;
301 redirects that for some reason don't redirect the urls with a space. I'm sure Google will find the few of them and update things later.

Factory Methods

2025-10-24T00:00:00Z

There was a time that I was updating the printed label creation process in the huge monolith.

Label size varied based on the item it was attached to. The size constricted the label printer choices, and each label had its own view file governing the display. If I remember, two different labels had vastly different view files that created the same output.

Many items need a printed label with either a QR-Code or Code-39 Bar code. Each location in the warehouse had a specific human-readable location, based on its row, shelf, and bay, and it needed a bar code for the scanner. All that data was placed on a printed label and attached to the shelf.

A case of product arrives at the warehouse. That case needs a printed label on a specific label size so it can be scanned for inventory or found at a later date. At some point in the fulfillment process, the case will be opened and moved to a different location in the warehouse. That opened case needed a new label, indicating that the case did not include exactly 72 identical items. When the product sells, a product will be pulled from the opened case, and that product needs a new label, indicating the order that it will fulfill. There were other printed labels in the system, but this just shows some cases for the project.

Before I was updating the label creation, each developer had to duplicate the process of gathering the objects and sending each one through a PDF printing system. Sounds simple, but there were multiple duplicated steps before creating the PDF, pulling a list of printers, and sending the PDF to the print queue. There was nothing preventing the user from sending a 4x6 label to a 2x1 label printer.

I was able to simplify the creation of the labels by creating an Interface for the label actions. The first thing was to create a Labelable interface to govern which objects could be converted to a label. Questions were raised as to whether an empty interface should be used, but using an empty interface allows type checking. Using a static property would add some complexity to the factory method just to check that the

interface Labelable {}

class ProductCase implements Labelable {...}

Then we had a factory method. We weren't using PHP 8 at the time, so the match expression didn't yet exist. The factory method takes a Labelable and returns a child of the LabelFactory interface.

The GOF book might suggest a method named createLabels(), Laravel might suggest using the handle() method. I prefer execute(). By seeing that a method is execute(), I know that we are running a Userland method, one that I created and can be modified. When I see handle(), I know that the method is defined by Laravel and probably shouldn't be modified.

class LabelFactory {
        // Labelable class => child of LabelFactory::class
        private const array LABEL_MAP = [
        \App\Products\ShelfLocation::class => \App\Labels\ShelfLabel::class,
        \App\Products\ProductCase::class => \App\Labels\ProductCaseLabel::class,
        \App\Products\OpenProductCase::class => \App\Labels\OpenProductCaseLabel::class,
        \App\Products\Product::class => \App\Labels\ProductLabel::class,
    ];
    public static function execute(Labelable $labelable): LabelFactory {
        return new self::LABEL_MAP(get_class($labelable));
    }
}

No matter which object needs to print labels, we are returned a concrete instance of the LabelFactory class. I don't remember the specifics anymore, but the code could be vastly simplified using the power of abstraction.

... // $product is some fulfillment product.
$labelFactory = LabelFactory::execute($product);
$printers = $labelFactory->validPrinters($warehouseLocation);
// somehow the user chooses a printer from the list of printers
PrinterQueue::add($labelFactory->createPdf(), $chosenPrinter);

Matching in Enums

2025-10-23T00:00:00Z

Let's suppose we're working on a project in Laravel. We have a Post model that uses an Enum for the status property, let's suppose that it's indicating whether the Post is draft, published, moderated, or some other Post status. The actual cases don't matter, but the status property is used to determine whether the post can be seen, edited, or other actions.

namespace App\Models;
use App\Models\Enums\PostStatus;

class Post {
    protected function casts() {
        return ['status' => PostStatus::class];
    }
}

Usually, we would do something like:

public function publishPost(Post $post) {
    if ($post->status === PostStatus::Published) {
        abort(403, 'Already Published');
    }
    $post->status = PostStatus::Published;
    $post->save();
}

Let's make this a little better. We will use a PostState class to take control of all the conditionals based on the status property. We will write code like $post->state->publish(). Let's start by adding a state attribute on the Post model.

use Illuminate\Database\Eloquent\Casts\Attribute;

    /** @return Attribute<PostState, $this> */
    protected function state(): Attribute
    {
        return Attribute::make(
            get: fn(): PostState => $this->status->createPostStatus($this),
        );
    }

We already have a cast on the Post model's, status property to use the PostStatus Enum. Remember that an Enum is just a class, so we can add a mapping method on the PostStatus Enum.

enum PostStatus: string {
    case Published = 'published';
    case Draft = 'draft';
    case Moderated = 'moderated';

    public function createPostStatus(Post $post): PostState {
        return match ($this) {
            self::Published => new PublishedPostState($post),
            self::Draft => new DraftPostState($post),
            self::Moderated => new ModeratedPostState($post),
        };
    }
}

Now we can create our PostState classes:

abstract class PostState {
    public function __construct(protected Post $post) {}
    public function publish() {
        $post->status = PostStatus::Published;
        $post->save();
    }
}

class DraftPostState extends PostStatus {}

class ModeratedPostState extends PostStatus {}

class PublishedPostState extends PostStatus {
    public function publish() {
        abort(403, 'Already Published');
    }
}

Any Post action depending on the value of the Post's status should be added to the PostState hierarchy. All the logic is tucked away in organized classes.

Hope this helps.

Immutable DateTime in Laravel

2025-06-25T00:00:00Z

While developing my latest Laravel side project, I ran into an issue that I've seen before. When using a CarbonImmutable class as a value source for a Model, the time zone is silently removed and re-added, changing the time. Now, it seems to me that a regular mutable Carbon object also has an issue.

In my use case, I want to take a date/time in local time from the user, and add the user's local timezone to calculate an absolute timestamp to store in the database. It will be sent to the UI as a JavaScript timestamp, so end users will see the date time in their local timezone.

Let's start a simple new laravel installation with no starter kit:

cd ~/scratch
laravel new immutable
cd immutable
php artisan migrate
php artisan tinker

Instead of adding extra models, I'll just use the User model because the created_at and updated_at properties are already cast to a datetime object. Let's create a new User and modify the create_at property inside the tinker shell:

> use Carbon\Carbon
> $user = User::factory()->create()
[!] Aliasing 'User' to 'App\Models\User' for this Tinker session.
= App\Models\User {#5285
    name: "Marvin Yost",
    email: "nmurazik@example.net",
    email_verified_at: "2025-06-25 19:16:42",
    #password: "$2y$12$pcNdSipUh6Dd5.CevSJAN.OFkqYMbB8p9Ip2tRF1foMgKrq0aIdgm",
    #remember_token: "M5aro4eKwd",
    updated_at: "2025-06-25 19:16:43",
    created_at: "2025-06-25 19:16:43",
    id: 1,
  }

> $user->created_at
= Illuminate\Support\Carbon @1750879003 {#5242
    date: 2025-06-25 19:16:43.0 UTC (+00:00),
  }

Let's imagine that the user needs to modify the time of some event, and we'll use the created_at property as a stand-in for whatever property on whatever other model needs a modification. The user has passed a Y-m-d H:i:s formatted local time, and a timezone that we can parse into a Carbon object.

> $createdAt = Carbon::parse('2025-01-01 08:00:00', new DateTimeZone('America/New_York'))
= Carbon\Carbon @1735736400 {#5231
    date: 2025-01-01 08:00:00.0 America/New_York (-05:00),
  }

> $createdAt->toCookieString()
= "Wednesday, 01-Jan-2025 08:00:00 EST"

> $user->created_at = $createdAt
= Carbon\Carbon @1735736400 {#5231
    date: 2025-01-01 08:00:00.0 America/New_York (-05:00),
  }

> $user->save()
= true

> $user->created_at
= Illuminate\Support\Carbon @1735718400 {#6337
    date: 2025-01-01 08:00:00.0 UTC (+00:00),
  }

> $user->created_at->toCookieString()
= "Wednesday, 01-Jan-2025 08:00:00 UTC"

So why did the date change when we gave the model a time object?

First, a workaround: use the timestamp.

> $user->created_at = $createdAt->getTimestamp()
= 1735736400

> $user->save();
= true

> $user->created_at
= Illuminate\Support\Carbon @1735736400 {#6419
    date: 2025-01-01 13:00:00.0 UTC (+00:00),
  }

> $user->created_at->toCookieString()
= "Wednesday, 01-Jan-2025 13:00:00 UTC"

There is a problem with this. If you're using laravel-ide-helper and larastan, Stan may complain that the created_at doesn't take an integer. That can be solved by changing the docblock, but that cascades down the code, but Stan complains about using the created_at as a DateTime when it might be an integer.

Let's try a different technique.

> $createdAt = Carbon::parse('2025-01-01 09:00:00', new DateTimeZone('America/New_York'))
= Carbon\Carbon @1735740000 {#5241
    date: 2025-01-01 09:00:00.0 America/New_York (-05:00),
  }

> $user->created_at = $createdAt->setTimeZone(config('app.timezone'))
= Carbon\Carbon @1735740000 {#5241
    date: 2025-01-01 14:00:00.0 UTC (+00:00),
  }

Let's make a test that looks like it should pass, but fails because of time zones:

class dateTest extends \Tests\TestCase
{
    #[\PHPUnit\Framework\Attributes\Test]
    public function test_user_date(): void
    {
        $user = \App\Models\User::factory()->create();

        $createdAt = \Carbon\CarbonImmutable::parse('2025-01-01 08:00:00', 'America/New_York');
        $user->created_at = $createdAt;
        $user->save();
        $this->assertEquals($createdAt->getTimestamp(), $user->created_at->getTimestamp());
    }
}

Failed asserting that 1735718400 matches expected 1735736400.
Expected :1735736400
Actual   :1735718400

Stepping through the entire test, delving into the Laravel code, we come to the Illuminate\Database\Eloquent\Concerns\HasAttributes class. In the setAttribute($key, $value) method, the Carbon object is cast via the $value = $this->fromDateTime($value); line.

/**
 * Convert a DateTime to a storable string.
 *
 * @param  mixed  $value
 * @return string|null
 */
public function fromDateTime($value)
{
    return empty($value) ? $value : $this->asDateTime($value)->format(
        $this->getDateFormat()
    );
}

Passing the Carbon object through fromDateTime() returns "2025-01-01 08:00:00", which is the local time without any time zone data. That is then transferred to UTC time zone without any other adjustment, and is stored as "Wednesday, 01-Jan-2025 08:00:00 GMT+0000", or 1735718400.

Assigning a Carbon object to a 'datetime' cast, the timezone needs to be in config('app.timezone') time, which by default is set to UTC. If we put this back in the tinker shell, we can use it like this:

> use Carbon\CarbonImmutable
> $createdAt = CarbonImmutable::parse('2025-01-01 08:00:00', new DateTimeZone('America/New_York'))
= Carbon\CarbonImmutable @1735736400 {#5235
    date: 2025-01-01 08:00:00.0 America/New_York (-05:00),
  }

> $user = User::factory()->create();
[!] Aliasing 'User' to 'App\Models\User' for this Tinker session.
= App\Models\User {#5319
    name: "Khalil Reichel",
    email: "gretchen79@example.org",
    email_verified_at: "2025-06-26 03:29:51",
    #password: "$2y$12$aQsQz0T5xPsF3GqpoEo.hOEu6q4K2.lCneUXZ4UzMCe.owjBslSbC",
    #remember_token: "PI3TFktVQZ",
    updated_at: "2025-06-26 03:29:52",
    created_at: "2025-06-26 03:29:52",
    id: 2,
  }

> $user->created_at = $createdAt->setTimezone(config('app.timezone'))
= Carbon\CarbonImmutable @1735736400 {#5273
    date: 2025-01-01 13:00:00.0 UTC (+00:00),
  }

> $user->save()
= true

> $user->created_at->setTimeZone('America/New_York')->toCookieString()
= "Wednesday, 01-Jan-2025 08:00:00 EST"

Remember that no matter what time zone your Carbon object is, make sure it has the app default timezone before it is cast to a model attribute.

Why I Hate Bare Strings

2024-08-21T00:00:00Z

Back in a previous work life, I kept getting asked the same question every morning. Since I was developing the system for the business, I wrote some code to answer the question with an automated email every morning. Each day, we would send out shipment orders to pickup office machines. The question was "when is this particular machine arriving?"

Part of the system would contact the carriers every night to update the status of shipments. Some would be picked up and en route, some would have problems with the pickup and be on a will-advise status. This information was available on the dashboard, but showing information about the shipment and leasing company that owned the equipment, not specific machines. A user could open the page of a particular shipment and see the equipment list, shipment status, and when the office equipment was resold, the sale price of the equipment. Unfortunately, pressing a few extra buttons was apparently asking too much for some users, and they wanted to get updates about specific machines.

The code, which was probably some of the best PHP code ever written in the first decade of the 21st Century, would wait for the updates to complete, then search for the en route machines on the watch list and send an email to the watchers. I set up a bunch of watch alerts for equipment that had been picked up earlier in the day and went home. The next morning, no emails. I double checked the code, made some changes, and set up more watches. Again, the next morning, no email. Again, I look at the code, and think "Hmm, maybe this time it will be different, even though it's exactly the same," and it was the same. Night after night, I get no email, and chalk it up to "one of those things."

At the time, I had no test suite, and quite honestly, the code at that time was too spaghettified to allow proper testing without writing to the production database or hard-coding a specific tracking number from a specific carrier that I already knew to be in a specific status.

But then one day, I discovered how awesome class constants are. You get IDE autocompletion on a constant instead of a bare string, and the IDE will spell it correctly. You can click on a constant definition and see all its uses. So I started updating all my shipping statuses using Shipping class status constants. Then I started updating all my machine statuses using a Machine class status constant.

And that's when I found it. I had been running a query looking for a machine status of en route, but machines didn't have that status. The shipment had the en route status, and the machine wouldn't have a status until the shipment was delivered.

The proper use of a class constant, or even an Enum in today's code, would have told me that searching a machine table's status field for Shipping::EN_ROUTE would not be the correct search term. However, since it was a bare string en route, and the en route status existed (elsewhere) it looked fine to my eyes every single time. The perfect code was thwarted by a bare string that was correct, just not where it was.

And that's why I hate bare strings.