Just a Twitter account I've been enjoying lately. Small worlds posts a tiny sci-fi story every day (with lovely visuals!)

Follow @smllrworlds on Twitter.

When building a CRUD interface in an event sourced system, you'll come across the dilemma of how granular your events should be. Should you have a large PostUpdated event, or granular TitleUpdated, ContentUpdated, and AuthorUpdated events?

The main benefit of single, large events are how straightforward they are. Little code required. One event, one method on the aggregate root, one projector.

Besides that, granular events win.

Large events store unnecessary data. A single event always stores all data, even when unchanged. If I update a post's title, the PostUpdated event will contain the content and author as well. Granular events only contain the data that changed.

Large events can be difficult to change. If you add a property, you need to ensure old events don't break when they're deserialized. Granular events change less often. You'd add a new event for a new property, or stop dispatching an event for an old one.

Large events are difficult to react to. If I want to react to a title change, the PostUpdated event is not enough, as I don't know if the title actually changed. To know whether something changed, you need to query the current state in the aggregate root or projections. Granular events are only dispatched when something changed.

If the data is not critical or most importantly you don't plan to react to, large events are fine. Otherwise, granular events are the more versatile choice.

Personal websites are often blogs these days: a chronological stream of thoughts, news, and articles. However, some content is worth more than a post stuck and lost in time.

If I need to publish content about an emerging API, I need a couple of things. I need reference documentation so that people who want to try it out understand how to use it. This reference is evergreen content, and I will update it as the API changes. It is helpful to have, right up front, information about the last time we updated the content and the version of the spec, or browser to use for testing. I also want to let people know that we’ve shipped this experiment, so I need a news post pointing to my reference material, explaining that this thing is here, and asking people to try it out and give us some feedback. I will not update the news post; what I might do, however, is write another news post when the spec and implementation changes to let people know the progress. These news posts are my paper trail.

Food for thought for my own site. I have a bunch of old articles I wish were more discoverable as pages outside of the “blog” format.

At Laracon US we announced we’re working on a new course at Spatie: Full Stack Artisan.

In Full Stack Artisan, we’ll dive into building Laravel applications with Inertia, React, TypeScript, view models, our Laravel Data package, and more.

Last week I took a break from working on course content to set up branding and a landing page.

Just a website

For now, we needed a landing page with a Mailcoach subscription form. No PHP or static site generator, long live index.html & site.css!

public/
└ img/
└ …
└ favicon.ico
└ index.html
└ site.css

Our index.html is only 50 lines long, the majority being meta tags. Little HTML requires little CSS, so it wasn’t worth introducing a build step to minify. All view-sourceable like it’s 2008!

Modern goodies

The header and background graphics are encoded in WEBP, a modern image format for the web. It’s the first time I’ve actively used it, and oh my is it lean. The 180 KB background image shrunk down to 28 KB after converting from JPEG to WEBP using Squoosh.

I used the new-ish aspect-ratio property in CSS to define the header’s aspect ratio, so the layout doesn’t shift when the image starts loading.

.banner {
aspect-ratio: 480 / 340;
}

I also had some fun with the CSS :target selector. Our subscription form redirects to https://full-stack-artisan.dev/#subscribed to display a flash message after a visitor subscribes.

#subscribed {
display: none;
}
#subscribed:target {
display: block;
}

I wrote a more in-depth article about :target on the Mailcoach blog.

In the coming months, Freek, Ruben, and I will be experimenting, writing, and recording the course. I look forward to share more on the thought process soon.

Personal websites are often blogs these days: a chronological stream of thoughts, news, and articles. However, some content is worth more than a post stuck and lost in time.

If I need to publish content about an emerging API, I need a couple of things. I need reference documentation so that people who want to try it out understand how to use it. This reference is evergreen content, and I will update it as the API changes. It is helpful to have, right up front, information about the last time we updated the content and the version of the spec, or browser to use for testing. I also want to let people know that we’ve shipped this experiment, so I need a news post pointing to my reference material, explaining that this thing is here, and asking people to try it out and give us some feedback. I will not update the news post; what I might do, however, is write another news post when the spec and implementation changes to let people know the progress. These news posts are my paper trail.

Food for thought for my own site. I have a bunch of old articles I wish were more discoverable as pages outside of the "blog" format.