Paul M. Jones

Don't listen to the crowd, they say "jump."

Qiq Templates for PHP 8

I'm happy to announce the first release of Qiq, a template system for developers who prefer native PHP templates -- but with a light dusting of syntax sugar when you want it. It offers partials, layouts, sections, and a wide range of HTML helpers for tags and forms, along with explicit but concise escaping.

I don't like compiled templates or specialized template languages. Smarty, Twig, etc., are all just too heavy-handed. I don't need a new language, and I don't need to "secure" my templates against designers on my team. I am generally happy with plain PHP as a template language.

However, I do find escaping tedious -- necessary, and easy enough, but tedious. A template helper to output escaped HTML, like this ...

<?= $this->h($var) ?>

... is not that bad -- but even so, it could be a little easier. Imagine this little bit of syntax sugar:

{{h $var }}

All that happens is that {{h ... }} is replaced with <?= $this->h(...) ?>.

Once that is in place, it becomes easy to support helpers, control structures, and other code, all while keeping native PHP as the fallback syntax, because the {{ ... }} tags are essentially stand-ins for PHP tags.

Qiq is PHP -- just with some syntax sugar. Try it out on your next project!

Beating Back Cancel Culture

Some high points from a successful virtual beat-down of SJWs:

Know what to expect. The cancel crowd has its own bullet-point playbook. And they’ll respond aggressively to any symbolic act that threatens their status, or erodes the impression that they are the ones calling the shots. Remember that behind the social-justice veneer lies the brutal logic of power and ego.

  • To maximize the pain you feel, they’ll tag activist groups on social media to inflate their numbers and reach.

  • They’ll bombard every organization you’re part of with demands to censure, discipline, disown, fire, or expel you—often phrasing their appeals in the passive aggressive guise of “concern” and “disappointment.”

  • At other times, they will insult, taunt, and, threaten you in a manner resembling middle-school children having a recess meltdown.

    • In my case, the ringleader called me “a full on misogynist and racist,” “shameful bigot,” “hypocrite,” “clueless,” “tone-deaf,” “snowflake,” and “soulless troll.”

    • She assailed my “privilege and patriarchy,” “lack of basic empathy and ethics,” and “zero self-awareness.”

    • She also questioned whether I’m really a human, and called on NeurIPS to ban me, and for my department to expunge me.

    • Her goal, in short, was to ruin my life.

  • The cancelers will dig up anything they can from your past. And if they can’t find any, they’ll make it up.

This will all seem terrifying, but much less so if you realize that you’re just the latest victim in what is basically a mechanical and dehumanizing process. Insofar as you don’t actually get fired from your job or suffer some other equivalent setback, these are all just words, and they don’t define who you are.


Don’t back down. Don’t apologize. Don’t make clarifications, and don’t try to appease the mob. All of these will only be taken as concessions, and embolden the mob to demand more. The real Achilles’s Heel of the cancel crowd is its short attention span. Once they bully someone into submission, they move on to the next victim. It’s a system designed for quick wins. If you don’t back down, they’ll raise the pitch as far as they can—but eventually they’ll be at a loss for what to do next, and all but the most fanatical will lose interest. The few that remain, now bereft of their backup, are just what you need to teach all of them a lesson, as we did in my case.


Turn their weapons against them. You may find this to be the most controversial principle, but it’s also arguably the most crucial—as the cancelers won’t stop until they fear that they’ll endure the same consequences that they seek to impose on others. In my case, I watched as investors and customers leaned on the ringleader’s company to rein her in. Even companies that posture heavily in the area of social justice don’t actually want to be stained by the disgraceful behavior of mob leaders. Indeed, I have no doubt that it was an ultimatum from her employer that finally led the ringleader to stop her Twitter outbursts and apologize publicly to her victims, for all to see. Some will say that once we resort to this step, we become as bad as the cancelers. But that’s a false equivalence. The cancel crowd tries to ban people because of their views. We try to stop bullying—behavior that is reprehensible regardless of ideology.

(Edited for formatting.)

See also the Social Justice Attack Survivial Guide.

Capsule 3: Clean, Concise, Composable Dependency Injection

I'm happy to announce that I have released Capsule 3.2.0, an autowiring dependency injection system for PHP 8. (Earlier 3.x releases started a couple of weeks ago, but this is the first proper announcement.)

Capsule works a little bit differently from other autowiring DI systems. The biggest difference is that configuration entries are stored as dynamic public properties on a Definitions object. That makes it very easy to obtain and modify not only object definitions, but also primitive values such as arrays. There are also quite a few lazy-resolution features built in, as well as a definition provider system.

For a comparison with other autowiring DI containers, please see capsulephp/comparison.

While Capsule does offer the ability to ...

  • create, modify, retain, and return objects and values via autowiring;
  • configure and define that creation, modification, and retention logic;
  • inject those objects and values into their dependent objects; and,
  • lazy-resolve values and objects at instantiation time;

... it does not offer:

  • Annotations. Annotations tend to couple a service to a particular container implementation; I think that kind of coupling is wise to be avoid on principle.

  • Caching and compiling. These are nominally performance enhancers, but in my experience they are rarely necessary, and in those rare cases the available speed increases are miniscule compared to other opportunities for optimization (e.g. database queries).

  • File-based configuration. Capsule configuration is defined exclusively via object-oriented PHP code, not via Neon/YAML/XML files or PHP arrays. (As a corollary, there is no special configuration notation to learn for Capsule, only class methods.)

  • In-flight container modification. This means you cannot set or reset new object or value definitions once a Capsule container is instantiated. (There are ways to subvert this restriction, in which case you will get what you deserve.)

  • Invocation injection. Also called method-call injection or action injection, I think this feature lies outside the scope of a DI/IOC system.

  • Tagging. I am ambivalent toward tagging; while I think it is little outside the scope of a DI/IOC system, I can see where others might find it useful. Perhaps a future version of Capsule may include it.

These missing features may be deal-breakers for some developers, in which case they have hundreds of autowiring and non-autowiring DI/IOC systems to choose from, including ...

... among other DI and IOC packages.

AutoRoute 2.0.0 Released, With Value Object Support

I am proud to announce that I have released AutoRoute 2.0.0, now for PHP 8. As an alternative to regex and annotation-based routers, AutoRoute eliminates the need for route definitions by automatically mapping the HTTP action class hierarchy to the HTTP method verb and URL path, reflecting on typehinted action method parameters to determine the dynamic portions of the URL. It presumes that the action class names conform to a well-defined convention, and that the action method parameters indicate the dynamic portions of the URL. This makes the implementation both flexible and relatively maintenance-free.

Of special importance, you can now use value objects as action parameters, and AutoRoute will automatically instantiate them for you. This means things like self-validating value objects, including DDD Identity value objects, are now trivial to work with in your action classes.

For example, whereas you might have done something like this previously ...

// GET /company/1
class GetCompany
    public function __invoke(int $id)
        $companyId = new CompanyId($id);
        $company = $this->serviceLayer->fetchCompany($companyId);
        // ...

... AutoRoute can now instantiate the CompanyId for you from the appropriate path segment:

// GET /company/1
class GetCompany
    public function __invoke(CompanyId $companyId)
        $company = $this->serviceLayer->fetchCompany($companyId);
        // ...

AutoRoute 2.0.0 is still faster than FastRoute, though not by as much as the 1.x series; it has dropped from about three times as fast to about two times as fast. (This is due to some internal rework to support value objects as action arguments.) Even so, remember that routing is only one small part of your HTTP user interface, and is unlikely to be a bottleneck in any case.

AutoRoute is 3x Faster Than FastRoute

When I first published AutoRoute in April 2019, I benchmarked it out of habit, to see how it compared to the fastest routing system I knew, FastRoute. The benchmark results at that time typically looked like this on PHP 7.2:

AutoRoute Runtime: 0.11443305015564
FastRoute Runtime: 1.9010598659515
FastRoute Cached:  0.12522411346436

It turned out that AutoRoute was very slightly faster than FastRoute; I was pleased, but surprised. Getting anywhere close to FastRoute was enough for me.

Lately, though, I've been working on the 2.x version of AutoRoute, and I compared 2.x to the 1.x benchmark. I was very unhappy with the results: 2.x was something like 6x slower than 1.x. While investigating the causes, I noticed that I had XDebug turned on. Turning it off brought the comparative benchmark to something much more reasonable.

It turns out that I made the same oversight when benchmarking 1.x against FastRoute, so I have corrected my error and updated the 1.x AutoRoute benchmarks. I am even more surprised now: the scenario reports that AutoRoute is about 3x faster than FastRoute:

AutoRoute Runtime: 0.027965068817139
FastRoute Runtime: 0.21157002449036
FastRoute Cached:  0.10321187973022

Now, remember: routing is only a tiny part of your overall application performance. Using AutoRoute over FastRoute will not triple the speed of your applications. Still, it is satisfying to find better performance where you can.

Why Each Programmer Thinks He Is The Best

I write code that is easy to read and uses intuitive data structures. Everyone else uses weird solutions and writes them poorly.

My innovations are clever responses to unusual circumstances. Everyone else’s are obviously weird.

Every time I have to fix someone’s code, their code is terrible. I never hear about my own code being terrible and in need of fixing. Every time I need to touch my own code again it is because it is so good my customers want to make another use of it.

If someone uses my software it is because it is good code. If they use competing software it is because of their clever marketing.

If I copy code from Stack Exchange I’m being efficient. If someone else does it they couldn’t do it themselves.

If I use an obscure language or library, I’m leveraging my unusual skillset. If someone else does it, they’re prioritizing their own convenience over maintainability.

If someone like John Carmack is just better than me at programming in every way it is because they are in a special heroic reference class that it would be unfair to compare me to but that I obviously aspire to.

Lifted entirely from with light editing and reformatting. (You should read the parent article as well.)

See also The Devil's Dictionary for Developers.

DDD, Authentication, and Credential Exchange

In a typical DDD layered architecture, the Application layer will almost always need to know who is using it, even if only to help determine authorization. This is not a problem of authentication per se. Instead, it is a problem of taking the identification values provided by a prior authentication (such as a JWT or a session ID) and matching them to a Domain layer User object. Further, the problem must be solved in a way that does not tie the Application or Domain layers to any particular Presentation (User Interface) layer.

The Credential Exchange technique identifies the Domain layer User by passing the identifying information from the Presentation (User Interface) layer into the Application layer, and letting the Application layer coordinate the creation of the Domain layer User instance via Infrastructure implementations.

This technique eliminates any Presentation (User Interface) layer logic related to discovering the Domain layer User; for example, there is no need for error handling and other conditionals. The Application layer can capture any errors from Domain layer User identification into a Domain Payload for return back to the Presentation layer. The Domain layer can continue to depend only on its own interfaces for User modeling, independent of any other layer.

The components and collaborations in this technique are essentially a specialized variation on the Query Bus pattern, with the Credential as a Query, the CredentialExchange as a QueryBus, and the CredentialHandler as a QueryHandler.

You can read more about the Credential Exchange technique here, including source code examples.

Why Rationality Fails

Specifically, Bayesian rationality:

Rationality is a real thing. It says, “Use these formulas, from math and logic, in this way without error.” That’s fine and sure advice. But — here’s the big but — rationality is silent on what goes into the formulas. What goes in is what’s it’s all about.

There is no way to bootstrap rationality. All thought has to begin in inspiration, sometimes called intuition, of which there are many kinds, none of them rational.

That is, all rational processes begin at a non-rational starting point: a world-view, if you will, that filters which facts are relevant to the rational calculation. Different world-views accept different (and equally true!) facts as relevant, and so can arrive at widely different conclusions -- all completely rational.

Via Why Moldbug/Yarvin/Alexander’s Bayesian Rationality Fails.

Application and Domain Service Naming Conventions

In which a correspondent asks about Application Services, Domain Services, and the interactions between them.


The word "service" is everywhere in my codebase. Can you suggest a naming convention, or directory structure, or other advice, regarding Application Services?

I hear you on the word Service popping up everywhere. Using the same word everywhere for different things makes it hard to differentiate between them.

Having that trouble myself, I have started using the term "Use Case" instead of "Application Service". Further, I do only one thing per Use Case, instead of doing several things in an Application Service.

I have a directory structure something like this in one project:


Note that the naming is "human" and does not have "UseCase" suffixed on it. (More on that in a bit.)


I'm struggling to know exactly what goes in the blog Application Service and blog non-application service. Where does user authorization ("can this user create a blog?") go? Where does validation ("is the title long enough? is the publish date in the future?") go? Are those application or non-application services?

This is where the idea of a Domain Service (cf. the DDD books by Vernon and Evans) comes into play. They say those non-application services are called Domain Services.

If a non-application service is injected into other non-application services, should all this be moved out of the Application Service? If so, the Application Service don't really then contain anything as far as I can see.

Whereas an Application Service presents a face to the world outside the Domain, the Domain Service is internal to the Domain. As such, it's totally fine to have that non-application Domain Service get injected into different Application Services (and for Domain Services to be used by other Domain Services).

And yes, that means eventually the Application Service may then contain almost nothing at all except calls to coordinate different Domain Services. I think this is part of a natural progression:

  • You used to put everything in a Controller method or Action class; then you extracted the domain logic into an Application Service.

  • Next, different Application Services needed to do the same things over and over; you extracted the shared logic to different Domain Service classes.

  • Finally, you realized that your Application Service could just use one or more Domain Service objects in a lot of cases.

Voila: all non-trivial logic is down in the Domain now. The Application Service coordinates between one or more of those Domain Services, then presents a Domain Payload back to the user interface.

And how would I name those non-application services?

I have started keeping my Domain Services grouped with their "main" entity or aggregate. For example:


Note how the naming is still "human", but does have a "Service" suffix.

The problem I ran into was that, because they did not have differentiating suffixes, the "PublishDraft" Use Case had the same class name as the "PublishDraft" Domain Service. That caused local name conflicts when they were both used together. I would have had to alias one or the other in the use statement, so I figured I might as well give one (or the other) a class name suffix, to preempt name conflicts.

In this project I went with a suffix on the Domain Service, but might just as well have gone with a "UseCase" suffix on the Use Cases instead. (You get to pick your tradeoffs here.)


How do you suggest I communicate these possible failures between two different Domain Services? One option is to use the Domain Payloads, but again I think they are only for returning to the action, not between domain services. So the only other option I see really is domain-specific custom exceptions, but I've always felt a bit weird about domain specific exceptions. Do you have any thoughts on this? Any obvious option I'm missing?

I would say: definitely not via Domain Payload while within the Domain. The Domain Payload is always-and-only for reporting back across the boundary to the User Interface layer. Instead, use Exceptions within the domain, and/or some other domain-specific notification or messaging system while within the domain.

Also, to keep domain-level exceptions from escaping to the User Interface layer, the Application Services should have a catchall for exceptions emanating from the Domain. For example, add some wrapper or decorator logic on your Application Services to catch all exceptions from Domain activity, and that catchall can return a Payload (with the error in it) back to the calling User Interface code.

See the Reddit conversation about this post here.