Advent of Functional PHP: Day 8 – Larry Garfield

Advent of Functional PHP: Day 8

Advent of Code Day 8 was, to put it mildly, a pain in the ass. There’s a couple of reasons for that. It’s a naturally tricky problem, it’s hard to genericize, and it’s explained fairly badly. It took a while but with some help from others I was finally able to figure out (and refactor to) a good, functional solution to it. So let’s dive in.

The problem boils down to one of encryption. Our input is several lines that all look like this:

acedgfb cdfbe gcdfa fbcad dab cefabd cdfgeb eafb cagedb ab | cdfeb fcadb cdfeb cdbaf

Where each letter corresponds to one segment in an LED display for a number. Each number appears once on the left side, which is enough for you to figure out what letter corresponds to what segment. Then we need to use that knowledge to decode the numbers on the right and figure out what the number is.

20 December 2021 – 10:06am

Ep#366 – Interview with The PHP Foundation – Voices of the ElePHPant


Listen as hosts Cal Evans and Khayrattee Wasseem talk with Sara Golemon, Joe Watkins, and Sebastian Bergmann about the newly formed PHP Foundation.



This episode is sponsored by
RingCentral Developers

The post Ep#366 – Interview with The PHP Foundation appeared first on Voices of the ElePHPant.

Interview with The PHP Foundation – Voices of the ElePHPant

Listen and hosts Cal Evans and Khayrattee Wasseem talk with Sara Golemon, Joe Watkins, and Sebastian Bergmann about the newly formed PHP Foundation.

This episode is sponsored by
RingCentral Developers

The post Interview with The PHP Foundation appeared first on Voices of the ElePHPant.

PHP Internals News: Episode 96: User Defined Operator Overloads – Derick Rethans

PHP Internals News: Episode 96: User Defined Operator Overloads

In this episode of “PHP Internals News” I chat with Jordan LeDoux (GitHub) about the “User Defined Operator Overloads” RFC.

The RSS feed for this podcast is, you can download this episode’s MP3 file, and it’s available on Spotify and iTunes. There is a dedicated website:


Derick Rethans 0:14

Hi, I’m Derick. Welcome to PHP internals news, a podcast dedicated to explaining the latest developments in the PHP language. This is episode 96. Today I’m talking with Jordan, about a user defined operator overloads RFC that he’s proposing. Jordan, would you please introduce yourself?

Jordan LeDoux 0:33

My name is Jordan LeDoux. I’ve been working in PHP for quite a while now. This is the second time I have ventured to propose an RFC.

Derick Rethans 0:44

What was the first one?

Jordan LeDoux 0:45

The first one was the “never for parameter types”, which was much more exploratory. And we talked about it a little bit. And it generated a lot of good discussion that contributed to kind of the idea formation, which was what I hope to get out of it.

Derick Rethans 1:01

Okay, but that didn’t end up making it into a PHP release. As far as I understand, right?

Jordan LeDoux 1:07

No, I withdrew it actually, it was clear that the better way to approach the problem it was trying to solve was with a much more comprehensive solution. That particular solution was something that only required a seven line change to the engine. So I wanted to see if it was something people were okay with, or thought was a decent idea for that particular problem, much more comprehensive, like template classes, or something like that is probably the better route to go.

Derick Rethans 1:35

Well, I think the RFC that we’re talking about today, is going to require quite a bit more than seven lines of code?

Jordan LeDoux 1:41

Quite a bit more. Yeah.

Derick Rethans 1:42

So what is this RFC that we’re talking about today?

Jordan LeDoux 1:45

Well, user defined operator overloads is a way for PHP developers to define the ways in which objects interact with specific operators. So for instance, the plus operator, the plus sign. It’s a way for those objects to kind of define their own logic as far as how that’s handled, which right now, as of PHP 8.0, those were all switched to type errors. So it’s not possible currently to write any code that doesn’t result in a fatal error, where objects are used with operators.

Derick Rethans 2:25

Usually, I ask about every RFC, what problem are you trying to solve this? So what problem are you trying to solve this RFC?

Jordan LeDoux 2:31

The biggest problem that this solves is that objects contain, so objects in most programs represent a value or multiple values that have a program context. That’s the most powerful thing about objects is they’re contextual, and they understand the state, they understand what state the object is in, and sometimes even what state the whole program is in. And that’s necessary for a lot of things. Like for instance, if you’re tracking a distance, you know, you might measure that meters, and that would have a number you might have 30 meters of distance, but it also has a unit of meters. You could just represent that as an int. And

Truncated by Planet PHP, read more at the original (another 32660 bytes)

Advent of Functional PHP: Day 7 – Larry Garfield

Advent of Functional PHP: Day 7

Advent of Code Day 7 this year is another problem that’s more about the math than about the programming, so we won’t see much in the way of new functional techniques. Still, there’s some interesting bits in there.

Today we need to calculate the fuel costs of moving a bunch of crabs in submarines all into a line. (Don’t ask. Really, don’t ask.) Essentially we want to center-align a series of points using the least “cost” possible. Crab positions are represented by a single number, as crabs can only move horizontally. (Because crabs.)

The trick for today is realizing that the crabs don’t matter; it’s a distance-cost calculation. In part 1, the cost for a crab to move one space toward whatever alignment number we want to pick is 1.

Continue reading this post on PeakD.

7 December 2021 – 3:38pm

Xdebug Update: November 2021 – Derick Rethans

Xdebug Update: November 2021

In this monthly update I explain what happened with Xdebug development in this past month. These will be published on the first Tuesday after the 5th of each month.

Patreon and GitHub supporters will get it earlier, around the first of each month.

You can become a patron or support me through GitHub Sponsors. I am currently 46% towards my $2,500 per month goal. If you are leading a team or company, then it is also possible to support Xdebug through a subscription.

In November, I worked on Xdebug directly for only about 16 hours, with funding being around 24 hours. Please become a supporter of Xdebug through Patreon or GitHub.

Xdebug 3.1 and further

Since my last report, there were no more new issues reported with either functionality or crashes, and I have prepared for the Xdebug 3.1.2 release. Although I didn’t publish that in November, I did release it on December 1st.

It addresses a few crash bugs related to PHP 8.1 fibers, a crash bug when Xdebug can’t write a profiler file, and an issue with Xdebug’s var_dump() not using the magic __debugInfo method.

The full list of changes can be found on the updates page on the Xdebug website.

So what’s next? Xdebug’s profiler needs a rewrite. There are several design and implementation issues, that can only be resolved by a rewrite. To create less overhead it can also use PHP 8’s new Observer API as well.

But this is going to take a large amount of work, and with the current low, and decreasing, funding levels, I can not put a lot of effort behind this.

Xdebug Videos

I have published more videos on how to use Xdebug on my YouTube channel.

I will continue to create more videos, and also convert some of them to tutorials.

If you would like to suggest a topic for a 5 to 15 minute long video, feel free to request them through this Google Form.

Caddy as a Secure Reverse Proxy – Matthew Weier O’Phinney

I’ve been using Caddy as a front-end reverse proxy for several years now, on the advice of Marco Pivetta.
Somewhere along the line version 2 was released, and I updated at some point, but evidently didn’t quite understand some of its configuration options, particularly around HSTS support and providing your proxied application information about how the client tried to connect.

Caddy has always had a fairly declarative syntax, and tended towards sane defaults.
The syntax is like a hybrid of YAML and HCL, for better or worse, and includes placeholders for substituting in request or block-specific values.
Fortunately, you don’t have to write much to get the most common scenarios to work correctly.
And v2 now provides a JSON syntax as well.
The JSON syntax gives full access to all configuration options, and is particularly useful to learn if you want to be able to update the configuration on the fly via Caddy 2’s configuration API.
That said, the JSON syntax is incredibly verbose, and has quite a large set of nested members; I’ve found that for the bulk of my usage, the declarative HCL-like syntax tends to be easier to read and implement.

For instance, the documented way to create a reverse proxy to a service running on port 9000 of another machine, and that uses HTTPS by default is simply: { reverse_proxy machine-running-actual-service:9000

Boom, done.

Even better: Caddy can serve local IPs and addresses over HTTPS as well.
It will generate self-signed certificates using its own root certificate, which you then install into your system trust store.
The benefit is you can test your sites locally using TLS, which can help when testing JavaScript interactions, and reduce behavior differences with production.

Securing reverse proxies

That said, I’ve run into some small issues when running reverse proxies:

  • I assumed HSTS headers were in place.
    They were not.
    (This is true of any Caddy-served site, though, and not specific to reverse proxies.)
  • I assumed things like the X-Forwarded-Host and X-Real-IP request headers were in place.
    They were not.
    That said: by default, Caddy:

    • Passes the Host header intact to the proxy.
      This is actually quite handy, as most application frameworks will prefer the Host header when present anyways.
    • Adds the X-Forwarded-Proto header; this is the one most standardly consumed by other web servers and web application frameworks.
    • Adds or updates the X-Forwarded-For header, which is used by load balancers.

Fortunately, adding configuration for these are relatively straight-forward { reverse_proxy machine-running-actual-service:9000 { header_up X-Real-IP {remote} header_down Strict-Transport-Security max-age=31536000 }

If you have quite a number of reverse proxies, you likely don’t want to copy-paste those.
Caddy to the rescue again: configuration supports snippets.
These look like your host blocks, but the name will be in parentheses.
When a configuration block can re-use it, it can import it by name.

(reverseproxyheaders) { header_up X-Real-IP {remote} header_down Strict-Transport-Security max-age=31536000
} { reverse_proxy machine-running-actual-service:9000 { import reverseproxyheaders }

With these changes, my applications now:

  • can resolve the client IP correctly
  • provide HSTS headers to the client, helping protect users from MITM attacks

My own configuration defines three reverse proxies, two subdomains that redirect elsewhere, and defines one static site.
All in a total of 34 lines of configuration.

I’ll take it.


Why use Caddy, particularly if you’re comfortable and/or knowledgable with Apache or nginx?

For me, the decision comes down to sane defaults and ease of setup.
Setting up ACME with Apache or nginx, while it has become simpler, is not turn-key.
Caddy, however, assumes TLS by default, uses ACME to marshal a TLS certificate, and redirects non-TLS requests to TLS, all without requiring any additional configuration whatsoever.
Similarly, the fact that setting up a reverse proxy can often be as simple as pointing it to the proxy, and not require remembering to pass on common headers, sets it apart from the traditional web servers.
Finally, it’s built for speed, and I’ve found that the performance overhead of running it as a reverse proxy is essentially negligible.

Truncated by Planet PHP, read more at the original (another 816 bytes)

Advent of Functional PHP: Day 6 – Larry Garfield

Advent of Functional PHP: Day 6

Day 6’s challenge is a little fishy. Given what we’ve already done so far, it’s pretty simple. The only catch is making sure you do it in an efficient way.

Specifically, we’re asked to model the growth patterns of fictional lantern fish. In this silly model, we start with a list of fish at various ages. Each fish spawns a new fish every 7 days, and a newborn fish takes an extra 2 days before it starts spawning new fish. Fish also never die. (Someone warn the AI people that we’ve found the paperclip optimizer.)

Part 1 asks us how many fish there are after 80 days, all around the world, given the start data. Let’s find out, but let’s do so efficiently.

Continue reading this post on PeakD.

6 December 2021 – 12:43pm