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.
Continue reading this post on PeakD
One of the nice features of Rust is the match keyword. match is similar to `switch`, but with two key differences:
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.
Unfortunately, some fellow speakers pointed out that their speaker selections for this year included zero women. There were numerous speakers with 2 sessions (myself included) or a workshop and a session, but no women at all.
Continue reading this post on SteemIt.
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:
Continue reading this post on SteemIt.
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.
Continue reading this post on SteemIt.
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.
Continue reading this post on SteemIt.
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:
Continue reading this post on SteemIt.
One of the long-running debates while designing PSR-14 was how to handle events that were inherently mono-directional. Often, a library will trigger an Event that is, from its point of view, entirely informational. The Event object it fires has no mutator methods so Listeners have no way to interact with each other, which means that the order Listeners run in is irrelevant. It also means Listeners can pass no data back to the emitting library, which means the result of the Event can have no impact on the Emitter's further logic.
This special case opens up more options for how to execute the Listeners. Because there is guaranteed no communication from Listener to Listener or from Listener to Emitter, it's safe to run the Listeners concurrently. In fact, it's safe to run the Listeners concurrently with the Emitter. The Emitter doesn't even need to wait for the Listeners to fire before continuing.
Continue reading this post on SteemIt.
In Content Management Systems and similar highly-configurable applications, a common pattern is to have a registration mechanism of some sort. That is, some part of the system asks other parts of the system "give me a list of your Things!", and then modules/extensions/plugins (whatever the system calls them) can incrementally build up that list of Things, which the caller then does something with. Those Things can be defined by the extension, or they can be defined by user-configuration and turned into a Thing definition by the module. Both are valid and useful, and can be mixed and matched.
This pattern lends itself very well to an Event system like PSR-14, and in fact the "give me a list of Things" pattern was one of the explicit use cases the Working Group considered. Today let's look at how one could easily implement such a mechanism.
Continue reading this post on SteemIt.
So far in our 5 part series we've dug into the details of Events, Dispatchers, and Providers. An awful lot of flexibility can be had from just three simple methods. But how does it work out in practice?
In today's installment I want to start showing examples of real-world (ish) use cases that can benefit from this design. For these examples I will be using Tukio, my stand-alone PSR-14 implementation, but all will work just as well with any PSR-14 implementation, by design.
A common "extension point" in many systems is access control, especially in a configurable CMS. You want to limit access to various operations, but which users should have access to what operations could vary based on a wide variety of special-case conditions that you want to allow individual site owners to control.
Continue reading this post on Steemit.