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.
For the past thirteen years, I've been either consuming Zend Framework or directly contributing to it. Since 2009, I've operated as project lead, and, since then, shepherded the version 2 and 3 releases, added Apigility to the ZF ecosystem, and helped bring middleware paradigms to the mainstream by assisting with the creation of Stratigility and coordination of the Expressive project. As I write this, the various ZF packages have been downloaded over 300 MILLION times, with 200 million of those being in the past 18 months!
Have you used Node.js?
For those of my readers unfamiliar with Node.js, it's a server-side JavaScript framework that provides the ability to create, among other things, network services. To do so, it provides an event loop, which allows for such things as asynchronous processing.
In the PHP ecosystem, a group of Chinese developers have been creating an extension that provides many of the same capabilities as Node.js. This extension, called Swoole, allows you to create web servers with asynchronous capabilities. In many cases, the asynchronous capabilities are handled via coroutines, allowing you to write normal, synchronous code that still benefits from the asynchronous nature of the system event loop, allowing your server to continue responding to new requests as they come in!
We've been gradually adding and refining our Swoole support in Expressive, and recently issued a stable release that will work with any PSR-15 request handler. In this post, I'll enumerate what I feel are the reasons for considering Swoole when deploying your PHP middleware application.
The last week has been my first foray into GraphQL, using the GitHub GraphQL API endpoints. I now have OpinionsTM.
The promise is fantastic: query for everything you need, but nothing more. Get it all in one go.
But the reality is somewhat... different.
Yesterday, following a unanimous vote from its Core Committee, PHP-FIG formally accepted the proposed PSR-15, HTTP Server Handlers standard.
This new standard defines interfaces for request handlers and middleware. These have enormous potential impact on the PHP ecosystem, as they provide standard mechanisms for writing HTTP-facing, server-side applications. Essentially, they pave the way for developers to create re-usable web components that will work in any application that works with PSR-15 middleware or request handlers!
I faced an interesting question recently with regards to middleware: What happens when we go from a convention-based to a contract-based approach when programming?
Convention-based approaches usually allow for duck-typing; with middleware, it means you can write PHP callables — usually closures — and just expect them to work.
Contract-based approaches use interfaces. I think you can see where this is going.