Blog

Automated testing is good. This is, I hope, not a controversial statement. Small, isolated tests are also good. This should also not be a controversial statement.

But sometimes, tests will need to talk to the database. It may be too difficult to mock, or you may be using an expensive-to-load fixture for an integration test. That's OK, and those tests absolutely have their place.

But it's also nice to not have to rebuild the world for such tests. Enter, trivially simple transaction-based isolation.

Conventional wisdom in software development is to avoid overengineering things. The YAGNI principle (You Ain't Gonna Need It) speaks to that, as do dozens of articles and blogs and conference talks from Big Name developers.

What is less often discussed, though, is the cost of under-engineering. A cost I recently paid rather severely.

You may notice some style changes around here. Like, a lot of style changes. That's not all that's changed, in fact.

This is the official launch of the third iteration of my personal website. This time, it is built almost entirely from scratch using my own tooling: MiDy. Which is, incidentally, now available for public use.

Earlier this week, Seifeddine Gmati, aka "azjezz," posted an RFC for PHP generics. It's the most robust and promising approach for that feature to come along to date, and it's generating a lot of buzz. The folks at ThePHP.cc asked me to blog about it so they had something to reference in their new PHPReads newsletter, so, here it is. :-)

This will be a bit more ranty than my usual articles. Fair warning. But I need to put this out there.

Recently, a video by Jeffrey Way of Tailwind/Laracast fame came across my feed. In less than 15 minutes, he managed to succinctly capture everything I absolutely detest about the current moment in the IT industry.

There are many different ways of modeling data. They all have their place, and all have places where they are a poor fit.

The spectrum of options below are defined mainly by the degree to which they differentiate between read and write models, and correspondingly how powerful-but-also-complex they are. "Model" in this case usually corresponds to a class, or a class with one or more composed classes.

It's amazing what you can do when someone is willing to pay for the time!

There have been two new releases of Crell/Serde recently, leading to the latest, Serde 1.5. This is an important release, not because of how much is in it but what major things are in it.

That's right, Serde now has support for union, intersection, and compound types! And it includes "array serialized" objects, too.

I am pleased to report that my latest side project, MiDy, is now available for alpha testing!

MiDy is short for Mildly Dynamic. Inspired by this blog post, MiDy tries to sit "in between" static site generators and full on blogging systems. It is optimized for sites that are mostly static and only, well, "mildly dynamic." SMB websites, blogs, agency sites, and other use cases where frankly, 90% of what you need is markdown files and a template engine... but you still need that other 10% for dynamic listings, form submission, and so on.

I've long kept my photo backups off of Google Cloud. I've never trusted them to keep them safe, and I've never trusted them to not do something with them I didn't want. Like, say, ingest them into AI training without telling me. (Which, now, everyone is doing.) Instead, I've backed up my photos to my own Nextcloud server, manually organized them, and let them get backed up from there.

More recently, I've decided I really need a proper photo album tool to carry around "wallet photos" of family and such to show people. A few years back I started building my own application for that in Symfony 4, but I ran into some walls and eventually abandoned the effort. This time, I figured I'd see what was available on the market for self-hosted photo albums for me and my family to use.

Strap yourself in, because this is a really depressing story (with a happy ending, at least).

Two of the biggest features in the upcoming PHP 8.4 are property hooks and asymmetric visibility (or "aviz" for short). Ilija Tovilo and I worked on them over the course of two years, and they're finally almost here!

OK, so now what?

Rather than just reiterate what's in their respective RFCs (there are many blog posts that do that already), today I want to walk through a real-world application I'm working on as a side project, where I just converted a portion of it to use hooks and aviz. Hopefully that will give a better understanding of the practical benefits of these tools, and where there may be a rough edge or two still left.

One of the primary use cases for hooks is to not use them: They're there in case you need them, so you don't need to make boilerplate getter/setter methods "just in case." However, that's not their only use. They're also really nice when combined with interface properties, and delegation. Let's have a look.