Progress has been happening at a furious pace on the Zend Framework to Laminas transition, with major changes still dropping even now.
Most recently, we decided to rename the subprojects. Apigility will become the Laminas API Tools, and Expressive will become Mezzio.
For more background, read the Zend by Perforce blog post.
Due to disorganization on my part, I accidentally booked php[world] 2019 to coincide with a family commitment.
Update
As of 2019-10-01, I am once again employed full-time. Thank you everyone who reached out!
Fourteen years ago, almost to the day, I received a job offer from Zend to join their nascent eBiz team, where I started contributing almost immediately to the yet-to-be-announced Zend Framework. Two years later, I joined the Zend Framework team full-time. A year later, I was promoted to Architect. A year after that, I was promoted to Project Lead of Zend Framework, a role I kept for the next ten years. Over the years, Zend was acquired by RogueWave Software, which was in turn acquired by Perforce earlier this year.
Two months ago, almost to the day, was my last day with Zend/RogueWave/Perforce.
I'm now looking for a new adventure.
Last week, I did some system updates, and then decided to compile the most recent PHP releases. I've used phpbrew to manage multiple PHP releases for a number of years, and having it install a new version is fairly routine.
Except this time, it wasn't. Due to updates I installed, I was getting errors first with compiling the GD extension, then with ext-intl:
If you want Freetype support in ext-gd, you are expected to install the
package libfreetype-dev. On Ubuntu, this now installs libfreetype6-dev, which
no longer includes the freetype-config
binary that PHP's configure
script
uses to determine what features it supports.
Similarly, ext-intl depends on the package libicu-dev. Ubuntu's package now
omits the icu-config
binary used by PHP to determine feature support.
I searched for quite some time to find packages that would resolve these problems. I could have found the source code and compiled it and linked to that, but that would mean keeping that up-to-date on top of my PHP installs.
I even looked in the ondrej/php PPA, as that repository has multiple PHP versions already, including source packages.
And then I thought: why not try using those instead of phpbrew?
The rest of this post is how I made that work.
Ten years ago this month, I was involved in a couple of huge changes for Zend Framework.
First, I helped spearhead integration of the JavaScript library Dojo Toolkit into Zend Framework, and finalized the work that month. I'd worked closely with the two developers who had been leading that project at the time, and one thing that came up during our discussions was that they had helped create an open source foundation for the project, to ensure its continuity and longevity, and to ensure the project can outlive the ups and downs of any commercial company. This idea intrigued me, and has stuck in the back of my mind ever since.
The other thing that happened that month was that I was promoted to Project Lead of Zend Framework. I've held that position ever since.
Today, I get to announce another change: Zend Framework is transitioning to an open source project under the Linux Foundation!
I am a long-time gnome-shell user. I appreciate the simplicity and elegance it provides, as I prefer having a minimalist environment that still provides me easy access to the applications I use.
That said, just as with any desktop environment, I've still run into problems now and again. One that's been plaguing me since at least the 18.04 release is with display of app indicators, specifically those using legacy system tray APIs.
Normally, gnome-shell ignores these, which is suboptimal as a number of popular
programs still use them (including Dropbox, Nextcloud, Keybase, Shutter, and
many others). To integrate them into Gnome, Ubuntu provides the gnome-shell
extension "kstatusnotifieritem/appindicator support" (via the package
gnome-shell-extension-appindicator
). When enabled, they show up in your
gnome-shell panel. Problem solved!
Except that if you suspend your system or lock your screen, they disappear when you wake it up.
Now, you can get them back by hitting Alt-F2
, and entering r
(for "restart")
at the prompt. But having to do that after every time you suspend or lock is
tedious.
Fortunately, I recently came across this gem:
$ sudo apt purge indicator-common
This removes some packages specific to Ubuntu's legacy Unity interface that interfere with how appindicators are propagated to the desktop. Once I did this, my appindicators persisted after all suspend/lock operations!
In Expressive, we have standardized on a file named
config/routes.php
to contain all your route registrations. A typical file
might look something like this:
declare(strict_types=1);
use Zend\Expressive\Csrf\CsrfMiddleware;
use Zend\Expressive\Session\SessionMiddleware;
return function (
\Zend\Expressive\Application $app,
\Zend\Expressive\MiddlewareFactory $factory,
\Psr\Container\ContainerInterface $container
) : void {
$app->get('/', App\HomePageHandler::class, 'home');
$app->get('/contact', [
SessionMiddleware::class,
CsrfMiddleware::class,
App\Contact\ContactPageHandler::class
], 'contact');
$app->post('/contact', [
SessionMiddleware::class,
CsrfMiddleware::class,
App\Contact\ProcessContactRequestHandler::class
]);
$app->get(
'/contact/thank-you',
App\Contact\ThankYouHandler::class,
'contact.done'
);
$app->get(
'/blog[/]',
App\Blog\Handler\LandingPageHandler::class,
'blog'
);
$app->get('/blog/{id:[^/]+\.html', [
SessionMiddleware::class,
CsrfMiddleware::class,
App\Blog\Handler\BlogPostHandler::class,
], 'blog.post');
$app->post('/blog/comment/{id:[^/]+\.html', [
SessionMiddleware::class,
CsrfMiddleware::class,
App\Blog\Handler\ProcessBlogCommentHandler::class,
], 'blog.comment');
}
and so on.
These files can get really long, and organizing them becomes imperative.
We pioneered a pattern for exception handling for Zend Framework back as we initially began development on version 2 around seven years ago. The pattern looks like this:
ExceptionInterface
for each package.What this gave users was the ability to catch in three ways:
I've been running redis in Docker for a number of sites, to perform things such as storing session data, hubot settings, and more.
I recently ran into a problem on one of my systems where it was reporting:
Can't save in background: fork: Out of memory
I've been working on building PHP Docker images for the purposes of testing, as well as to potentially provide images containing the Swoole extension. This is generally straight-forward, as the official PHP images are well-documented.
This week, I decided to see if I could build Alpine-based images, as they can greatly reduce the final image size. And I ran into a problem.