One thing I do to help the PHP project is help other people write RFCs. For those that don't know, RFCs are the way that the PHP language and core libraries are changed.
Some of the reasons
A couple of times I've seen a weird error when rebuilding docker boxes.
The error looks like there is an error in the repository for where the packages are stored, with at least one of the packages missing.
Some programming patterns I follow are slightly unorthodox, at least in the sense that they are not patterns followed by the majority of PHP programmers. One of these unorthodoxies is that I do not believe controller should be aware of HTTP Request objects.
Instead I use 'interface segregation' to make it so that the controllers can be decoupled from Request objects.
I want to get something off my chest; I am not a big fan of PSR-7, the PSR about 'HTTP message interfaces'.
Although I do use it, I do so in a way where my code is barely aware of it at all, and so I can swap to using a different representation very easily.
PHP has supported variadics since version 5.6. Recently the question of how to support them in dependency injection containers such as Auryn was raised; should they be supported in a way similar to how Auryn handles scalar parameters?
Although supporting the ability to inject parameters by name is a useful thing to do (even if it is a bit of a hack), supporting injecting variadic parameters is a different kettle of fish entirely. One that would, in my opinion, be a bad choice.
A common anti-pattern (aka mistake) people make when trying to write re-usable code, is to try and force either an interface or abstract class where it isn't appropriate. The question below is paraphrased from a Stackoverflow question
Some people I have interacted with online have left me feeling...unhappy. It's not that they were trolling (particularly hard) or that they were seeking to antagonise me. Some of them are even trying to help me! by suggesting ways I can do things better! I wasn't necessarily asking for that advice, but they weren't deliberately trying to make me feel bad.
The below is a repost of a Slashdot comment by JustinOpinion that I thought was too great to not repost. It's in response to the question, "How do you prove software testing saves money".
As much as I like arguing on the Internet, one thing that irritates me is when people repeatedly claim facts with no basis in reality about why Apple has 'special' advantages sellings it's products that other companies don't have.
Nginx is awesome. PHP-FPM is awesome. Nginx with PHP-FPM is really awesome. However the documentation for how to link the two of them up through the config files is not particularly awesome.
PHP has a pretty good system for including class based code that uses the class namespace and name to define the possible file names that should be searched to auto(matically)-load the class. However PHP has a really crappy system for including functional code, the require/include system.
So this works.
Because I keep forgetting and having to remind myself every couple of years, here is to properly setup an image for anti-aliasing in PHP using the GD library. You need to create an image and give it a proper background colour, even if that background colour is transparent. This makes the image library use a proper alpha-channel (which is the only sensible way of doing alpha blending) rather than using an indexed based alpha, where only one 'colour' is transparent and all the others are fully opaque.The code below produces an image like this:
There are too many frameworks. Here is a quick reference list:
Just so that I can reference it in future, here is a Composer naming convention for libraries I publish.
After realising that I need to be able to post code samples on my blog, and looking at how annoying that would be to do under blogger, I've manned up and moved my blog back to my own site.