PHP

One of the many pieces of advice for a long-term sustainable code base is to keep code small. The larger a code base is, the more effort it takes to understand all the moving parts. Your brain can only keep so much mental model of your code in it at once, and if the code you're looking at is too large then what you can fit in your own "active memory" at once then you will have an increasingly hard time understanding it.

Most useful applications tend to grow larger than what the typical human can fit in their active memory, however, so you need a way to break up your code so you can load a relevant piece into your brain at once to understand and debug it. Usually that takes the form of encapsulation, coupling, cohesion, and other common object-oriented vernacular.

But what about just a pure function?

A pure function is a function that:

In early 2019, the PHP Framework Interoperability Group (PHP-FIG) released PSR-14, the Event Dispatcher specification. At the time I posted a long series of blog posts detailing PSR-14 in all its glory.

After discussing with a few other FIG folks, I've decided to release that blog series as a small ebook. Mainly that is to provide an easy single-point-of-reference for those who want to really understand PSR-14. Also, it serves as a simple fundraiser.

Calling all PHP developers! Want to wrap your brain around functional programming? Are you sick of reading tutorials about this magic "monad" thing but having no idea how to read Haskell? Then this book is for you.

Announcing Thinking Functionally in PHP, by yours truly, available now on LeanPub.

PHP 7.4's introduction of short-lambdas is a game changer for functional PHP. While it doesn't make anything new possible, it makes a lot of things suddenly practical. That's what this book is about: What is now practical to do in PHP in terms of functional programming.

There have been a number of RFCs and discussions in recent months all circling a a very similar problem space, or rather some closely related problem spaces. Many of them have struggled to gain traction for various reasons, not the least of which is that their problem spaces overlap but individual, piecemeal solutions have a tendency to help one problem at the expense of another, or fall short of helping another.

To try and resolve these issues, I want to take a step back and try to consider the related problem spaces together; at the very least to document them explicitly, and hopefully to provide some guidance on how we can address as many as possible with as limited a syntax impact as possible. This writeup should be considered an "essay" in the classical sense, that is, I am trying to think through the problem by writing about it.

One of the nice features of Rust is the match keyword. match is similar to switch, but with two key differences:

1. It requires an exhaustive match, that is, every possible value must be accounted for or a default must be provided.
2. match is an expression, meaning you can assign the return value of one of its branches to a variable.

That makes match extremely useful for ensuring you handle all possibilities of an enumerated type, say, if using an Optional or Either for error handling. Which... is something I've been experimenting with in PHP.

It's hard to make a PHP equivalent of match that forces an exhaustive match, as PHP lacks enumerated types. However, emulating an expression match turns out to be pretty easy in PHP 7.4, and kind of pretty, too.

Being a conference organizer is hard. Like, seriously. Aside from the obvious logistics, and the not-at-all-obvious logistics, you're in a position to create a social gathering, not just a technical one. That comes with a lot of baggage and challenges, many of them often competing and incompatible, that need to be balanced. One in particular is ensuring that the speakers are an eclectic lot that are representative both of the community as it is and as you want it to be. That can take a lot of work.

Earlier this year the organizers of the PHP Central Europe conference (PHP.CE) approached me and asked me to submit sessions for the PHP.CE conference in Dresden this October. I rather enjoy speaking at conferences so I of course did so, and this past week they announced their speaker selections, including me with 2 sessions.

Yesterday, a VC posted a Twitter thread about "10x engineers and how to spot them.'' It is a frankly terrible thread, and predictably, it became the latest Internet Pile On(tm), which we all know is Twitter's favorite pastime. I added my own thoughts in another thread, which I want to replicate here for posterity and then expand on a bit more now that I have a real keyboard and not just my phone.

First, here's my original thread, lightly edited for clarity, paragraphs, and links:

Hi. Senior engineer with 20 years experience, including "lead a multi year effort to overhaul and modernize a massive code base involving hundreds of developers.". I'm sure some would call me a 10x dev.

I have some comments here...

Back in January 2017, the PHP Framework Interoperability Group (FIG) reviewed and passed PSR-11, the "Container Interface" specification. It was a very simplistic 2-method interface for Dependency Injection Containers, which had been worked on for some time by a small group. (This was before FIG had formal Working Groups, but "container-interop" was one of the effectively proto-Working Groups that were floating about.)

PSR-11 passed overwhelmingly, 23 to 1 out of the FIG member projects at the time. The lone holdout was Drupal, for which at the time I was the voting representative.

Two and a half years later, I will say I was wrong, and PSR-11 has been a net-win for PHP.

At the time, my reasons for voting against PSR-11 were threefold:

So far we've looked at a number of complete, practical examples of using PSR-14 Events in various ways, both conventional and unconventional. In our final (probably) installment, I want to offer a highly unconventional but still practical use of PSR-14 that really shows off just how flexible Events can be: Layered caching.

"But wait, isn't caching the realm of PSR-6 and PSR-16?" Yes. Yes it is. But neither of those offer a built-in way to compose multiple cache backends together. It's certainly possible, but doing so is left as an exercise for the implementer. Let's use PSR-14 to get some exercise.

We continue our exploration of PSR-14's potential with a guest post. Cees-Jan Kiewiet was the Sponsor of PSR-14 (meaning the member of the Core Committee who bridged from the Working Group to the Core Committee), and is on the core team for ReactPHP. One wouldn't think there's any use cases for PSR-14 in an async environment like React, but one would be wrong.

Here's Cees-Jan with an explanation: