Why You Should Use Asynchronous PHP


The Difference Between Synchronous vs. Asynchronous Programming

Before we discuss the merits of asynchronous PHP, let’s quickly review the differences between the synchronous and asynchronous programming models. Synchronous code is sequential. Individual tasks must be completed before you can start another one. In asynchronous code, multiple tasks can be completed simultaneously, which can dramatically boost application performance and user experience.

BigQuery: Using multiple cursors / rectangular selection in BigQuery UI – Pascal Landau

Multiple keyboard shortcuts usable in the BigQuery UI are listed in the
official documentation, though the one for
using multiple cursors is missing:

ALT + left-mouse-button-drag

Using multiple cursors in the BigQuery UI via ATL + left mouse drag

Instructions

  • keep the ALT key pressed first and then click the left mouse button and drag it up or down vertically
  • the same hotkeys can be used to draw a rectangular selection (aka column selection)
    Rectangular / column selection in BigQuery
  • using ALT + LEFT and ALT + RIGHT will position one (or all) cursors at the beginning respectively end of the line

Use cases

We often deal with multiple datasets and tables that have the exact same structure, e.g. due to sharding. In those cases it’s
often required to modify different parts of the query in the exact same way so that multiple cursors come in handy.

Routing in Slim 4 – Rob Allen

Routing in Slim 4 works pretty much exactly the same as in Slim 3. They are used to map a URL that the browser requests to a specific handler that executes the code for that particular page or API endpoint. You can also attach middleware that will only be run when that route is matched.

The route in the slim4-starter looks like this:

$app->get('/[{name}]', HomePageHandler::class);

It is made up of the method, the pattern and the handler.

The method

Slim’s App object contains a number of helper methods for defining routes. The important ones are:

$app->get($pattern, $handler) For responding to an HTTP GET request
$app->post($pattern, $handler) For responding to an HTTP POST request
$app->put($pattern, $handler) For responding to an HTTP PUT request
$app->delete($pattern, $handler) For responding to an HTTP DELETE request
$app->map(['GET', 'POST'], $pattern, $handler) For responding to more than one HTTP method with the same handler

You can probably spot the naming convention!

The pattern

The $pattern parameter contains the path that you want to match. Internally, Slim uses FastRoute and the pattern syntax comes from there. This is a regex based system and has a number of ways to match:

Literal '/news' Matches the string as typed
Placeholder '/news/{id}' Use braces to create a placeholder that is a variable available to your handler
Placeholder pattern match '/news/article-{id:[0-9]+}' Only matches if the text for the placeholder matches the regular expression (digits only in this example)
Optional '/news[/{year}[/{month}]]' Use square brackets for optional segments. These can be nested.

The slim4-starter route’s pattern is ''/[{name}]'> This will match / and also any other string that does not contain a /, such as /rob.

The handler

The $handler parameter is the code that will be called when the route is matched. This can be any PHP callable or a string.

If it is a string, then it needs to be either the name of a class or the name of a key in your dependency injection container’s configuration. The class class should implement PSR-15’s RequestHandlerInterface though it can also be any class that implements __invoke().

If you are using a DIC, then Slim will try and retrieve your handler from it, so that you can ensure that any dependencies that the handler needs can be injected. If the DIC cannot provide the handler or you’re not using a DIC, then Slim will instantiate it directly.

The HomePageHandler class in slim4-starter is a PSR-15 RequestHandler and looks like this:

<?php declare(strict_types=1); namespace App\Handler; use Psr\Http\Message\ResponseInterface;
use Psr\Http\Message\ServerRequestInterface;
use Psr\Http\Server\RequestHandlerInterface;
use Psr\Log\LoggerInterface;
use Slim\Psr7\Response; class HomePageHandler implements RequestHandlerInterface
{ private $logger; public function __construct(LoggerInterface $logger) { $this->logger = $logger; } public function handle(ServerRequestInterface $request): ResponseInterface { $this->logger->info('Home page handler dispatched'); $name = $request->getAttribute('name', 'world'); $response = new Response(); $response->getBody()->write("Hello $name"); return $response; }
}

In this case the handle() method is called by Slim and we must return a PSR-7 Response. We’re using a dependency injection container (PHP-DI) and it injects a logger into our handler so that we can log what we’re doing when we handle a request.

The route object

When you add a route to Slim, a route object is returned. There’s a few useful things you can do with it.

Firstly you can set a name for the route:

$route = $a

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

PHP 7.2.26 Released – PHP: Hypertext Preprocessor

The PHP development team announces the immediate availability of PHP 7.2.26. This is a security release which also contains several minor bug fixes.All PHP 7.2 users are encouraged to upgrade to this version.For source downloads of PHP 7.2.26 please visit our downloads page, Windows source and binaries can be found on windows.php.net/download/. The list of changes is recorded in the ChangeLog.

PHP 7.4.1 Released! – PHP: Hypertext Preprocessor

PHP 7.4.1 Release AnnouncementThe PHP development team announces the immediate availability of PHP 7.4.1. This is a security release which also contains several bug fixes.All PHP 7.4 users are encouraged to upgrade to this version.For source downloads of PHP 7.4.1 please visit our downloads page, Windows source and binaries can be found on windows.php.net/download/. The list of changes is recorded in the ChangeLog.

PHP 7.3.13 Released – PHP: Hypertext Preprocessor

The PHP development team announces the immediate availability of PHP 7.3.13. This is a security release which also contains several bug fixes.All PHP 7.3 users are encouraged to upgrade to this version.For source downloads of PHP 7.3.13 please visit our downloads page, Windows source and binaries can be found on windows.php.net/download/. The list of changes is recorded in the ChangeLog.

Defining a custom filter and sorter for Sculpin content types – Matthias Noback

This blog runs on Sculpin, a static site generator. The generator itself runs on Symfony, which for me makes it easy to extend. However, I find that if you want something special, it can usually be done, but it may take several hours to get it right. In the end though, the solution is often quite elegant.

A custom content type for events

One custom feature I wanted for this website was a list of events (conference talks, trainings, etc.). Sculpin’s documentation suggests using a custom content type for that. This allows you to create a directory with files, each of which will be considered an “event”.

Setting up a custom content type is usually quite easy:

# in app/config/sculpin_kernel.yml sculpin_content_types: events: permalink: event/:year/:month/:slug_title

The default configuration values that Sculpin calculates for this setup are good in this case (it will look in source/_events/ for the html or Markdown files describing the events; it will look for the _layouts/event.html file for the layout of each event’s page, etc.). However, I wasn’t interested in how “detail” pages were generated for each event; I just wanted a list of all events. The html for the events page would have to look something like this:

---
layout: default
title: Events
use: [events] # load the collection of "events"
--- <h2>Events</h2> {% for event in data.events %} {{ event.content|raw }}
{% endfor %}

A sample event file would look something like this (front matter first, allowing some meta-data to be provided, then the content of the page):

# in source/_events/php-benelux-2020-workshop-decoupling-from-infrastructure.html ---
title: Decoupling from infrastructure
date: 2020-01-24
--- <p>Most application code freely mixes domain logic [...]</p>

This, again, just works great out-of-the-box.

Custom sorting

But now I wanted to change the sort order for the events. The default sorting is on date, descending. This doesn’t feel like a natural ordering for upcoming events, which would show events far in the future first.

I didn’t find a way to configure the sorting of events in app/config/sculpin_kernel.yml, so I looked at the source code of the SculpinContentTypesExtension class. I found out that the easiest thing to manually configure sorting would be to override the sorter service that Sculpin automatically defines for every content type:

services: # This sorter overrides the one Sculpin automatically configures for "events" sculpin_content_types.types.events.collection.sorter: class: Sculpin\Contrib\ProxySourceCollection\Sorter\MetaSorter arguments: - 'date' - 'desc' # I don't know why but "desc" works (I expected "asc")

The MetaSorter ships with Sculpin. I figured out the name of the service by reading through the code in SculpinContentTypesExtension. As you can see, I provide 'desc' as the second argument, even though I would expect the correct value to be 'asc'; 'desc' had the desired effect of showing the earliest events first.

Creating two filtered collections: upcoming and past events

I then realised it would be useful to have a list of upcoming events, sorted by date, ascending, and a list of past events, sorted by date, descending (oldest last). Upon regenerating the site, past events should automatically move to the list of past events. I figured I’d have to define two content types now: upcoming_events and past_events. These collections should both load the files in source/_events/, so the resulting configuration looks like this:

# in app/config/sculpin_kernel.yml sculpin_content_types: upcoming_events: permalink: event/:year/:month/:slug_title path: event/ layout: event past_events: permalink: event/:year/:month/:slug_title path: event/ # same path as "upcoming_events" layout: event

Which events end up in which collection should be determined by some kind of filter based on the current timestamp. Again, it turned out that Sculpin already has a built-in type for defining filters (FilterInterface), but it doesn’t provide easy ways of setting it up for your custom content types.

The way I did it was write a compiler pass that modified Sculpin’s own f

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