Blog Posts
On Deprecating ServiceLocatorAware
A month or two ago, we pushed a new release of zend-mvc that provides a number of forwards-compatibility features to help users prepare their applications for the upcoming v3 release.
One of those was, evidently, quite controversial: in v3, zend-servicemanager no
longer defines the ServiceLocatorAwareInterface, and this particular release
of zend-mvc raises deprecation notices when you attempt to inject a service
locator into application services, or pull a service locator within your
controllers.
The arguments go something like this:
- "Dependency injection is too hard to understand!"
- "This feature simplifies development!"
- "If this is so bad, why was it in there in the first place?"
These are usually followed by folks:
- saying they'll switch frameworks (okay, I guess?);
- asking for re-instatement of the feature (um, no);
- asking for removal of the deprecation notices (why? so you can delay your pain until upgrading, when you'll ask for re-instatement of the feature?); or
- asking for a justification of the change.
So, I've decided to do the last, justify the change, which addresses the reasons
why we won't do the middle two, and addresses why the assumptions and assertions
about ServiceLocatorAware's usefulness are mostly misguided.
Serve PSR-7 Middleware Via React
Automating GitHub Pages Builds with MkDocs
One of the final tasks in prepping for the Expressive 1.0 release was setting up the documentation site. We'd decided to use GitHub Pages for this, and we wanted to automate builds so that as we push to the master branch, documentation is deployed.
The process turned out both simple and bewilderingly difficult. This post is intended to help others in the same situation.
Expressive 1.0 in the Wild!
A few hours ago, we pushed Expressive 1.0.
This is a huge milestone for the ZF3 initiative; I've even called it the cornerstone. It signals a huge shift in direction for the project, returning to its roots as a component library. Expressive itself, however, also signals the future of PHP applications we envision: composed of layered, single-purpose PSR-7 middleware.
Secure PHAR Automation
For a variety of reasons, I've been working on a utility that is best distributed via PHAR file. As has been noted by others (archive.is link, due to lack of availability of original site), PHAR distribution, while useful, is not without security concerns, and I decided to investigate how to securely create, distribute, and update PHAR utilities as part of this exercise.
This is an account of my journey, as well as concrete steps you can take to secure your own PHAR downloads.
On 10 Years at Zend
10 years ago, as I write this, I was on a plane from Burlington, VT, to San Jose, CA, where I'd be starting work at Zend Technologies the next day as a PHP Developer.
Fixing Version Issues When Running Composer from a Branch
For the Zend Framework component repositories, we occasionally need to backport changes to the 2.4 LTS releases. This requires checking out a branch based off the last LTS tag, applying patches (often with edits to translate PHP 5.5 syntax to PHP 5.3), and running tests against PHP 5.3 and 5.4.
Of course, to run the tests, you need the correct set of dependencies installed.
If you have any component dependencies, that means running a composer update
to ensure that you get the 2.4 versions of those components.
And that's where my story begins.
On PSR7 and HTTP Headers
Yesterday, a question tagged #psr7 on Twitter caught my eye:
#psr7
Request::getHeader($name)return array of single string instead of strings in #Slim3? cc: @codeguy pic.twitter.com/ifA9hCKAPs
The image linked provides the following details:
When I call
$request->getHeader('Accept')for example, I was expected that I'll get something like this:Array( [0] => text/html, [1] => application/xhtml+xml, [2] => application/xml, )but, in reallity I got this:
Array( [0] => text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 )Is it correct?
In this post, I'll explain why the behavior observed is correct, as well as shed a light on a few details of header handling in PSR-7.
PHP is 20!
Today, 20 years ago, Rasmus Lerdorf publicly released PHP. Ben Ramsey has issued a call-to-action for people to blog the event and the impact PHP has had on their lives and careers; this is my entry.
PSR-7 Accepted!
I'm pleased to announce that as of 22:00 CDT on 18 May 2015, http://www.php-fig.org/psr/psr-7 PSR-7 (HTTP Message Interfaces) has been accepted!