PHP

When testing stateful code, you have to first set up all of the explicit and implicit state that a given piece of code depends on. If the object you're testing has many dependencies that could be complex, or references global variables, or calls many other routines with their own dependencies, you may be looking at a lot of complex setup that makes testing hard to do effectively.

Pure functions greatly reduce that problem.

A pure function is a function that:

• has no inputs other than those explicitly specified;
• has no effect on any value other than the value it returns.

That means there is, by definition, only one place to inject dependencies: the call itself. And there's only one effect to validate: the return value of the function. No need to call a function and check what the effect was on some other value or piece of code: by definition, the only effect is the return value.

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...

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.