PHP

Most of the time, installing tools using Homebrew works flawlessly, including PHP these days. However, having to work in a client environment requiring a proxy, the PHP 8.1 post-install failed when updating Pear/Pecl channels, although the usual http_proxy and https_proxy were set and worked normally, including for the other Homebrew tasks. What could be going on ?

Some late Drupal 7 projects use Composer for project structure and tooling, even though they don't use Composer for the Drupal requirements proper. In that case, the normal Drupal 8/9 patching process using cweagans/composer-patches is not available, since dependencies are not handled with Composer. So is there a way to apply patches cleanly from Composer ? Sure there is! Let's see how.

The opening talk as DrupalCamp Paris 2019 was a presentation given by Thomas Jolliet (FranceTV) and yours truly about how we rebuilt FranceTV Sport to a Symfony 4 / headless Drupal 8 combo.

The most salient points of the talk are probably the "defense in depth" mechanisms we built for scalability and fault tolerance, and the business results, like -85% full page load time, -65% speed index, or +50% iOS app traffic.

In 2014, I created a PHP version of the Munin plugins for Beanstalkd introduced by AirBnB, but originally created in Python.

Fast forward four years, and after being adapted for compliances with the PHP-FIG PSR1, PSR2 and PSR12 standards, as well as the Zend coding standards, and with extra documentation, I published the first "stable" version 1.0.0 of the package today under the Apache APL-2.0 license.

Yesterday, Seldaek committed PSR-4 support to Composer, as his New Year's Day gift to the PHP community.

So, since I always supported PSR-4 in FIG discussions, and after the tl;dr discussion about it regarding autoloading in Drupal 8, I jumped on the occasion and converted the code base for PlusVite to PSR-4 to get an idea of how PSR-4 "felt" in practice.

Over the last few days, I finally decided to revisit the old OSInet PHP library, to dust it off somehow, and convert the class-based parts to PSR0 and the whole to what seems to be liable to become PSR1 at some point.

This library contains a zoo of function helping with PHP-GTK development, and three packages with their demo application:

Class Grapher

Build a graph of inheritance and interface implementations on a directory (and subdirectories) of PHP code

This package uses the Drupal Grammar Paser to parse code, and includes a Drush 5 plugin for easy use within a Drupal site, but can also be used to parse non-Drupal code, as long as the Grammar Parser - which does not depend on Drupal either - is installed in the include path.

It is a more complete version of the Drupal-only Class Grapher sandbox on drupal.org.

In the current version, graphs are generated using GraphViz. An extension to a client-side visualization tool like the Infovis toolkit should come someday. Suggestions for other client-side libraries welcome (please comment!).

Open Document Calc reader

This package provides a few classes and methods to extract the content of OpenDocument (LibreOffice, OpenOffice.org, ...) spreadsheets.

Finite State Machine

This package is used to build applications designed around a finite state machine, and is mostly intended for use in PHP-GTK applications, to provide asynchronous processing.

The demo application uses the PHP FTP extension to expose its asynchronous notifications in a PHP-GTK UI

Every so often, I get asked about whether it is really worth it to chase double quotes and constructs like print "foo $bar baz", and replace them with something like echo 'foo', $bar, 'baz', or even to remove all those big heredoc strings so convenient for large texts.

Of course, most of the time, spending hours to fine comb code in search of this will result in less of a speedup than rethinking just one SQL query, but the answer is still that, yes, in the infinitesimal scale, there is something to be gained. Even with string reformatting ? Yes, even that. But only if you are not using an optimizer.

Just don't take my word for it, Sara Golemon explained it years ago with her "How long is a piece of string" post, in 2006.

In case you somehow managed to miss today's announcement, Facebook's Hip-Hop is now available, along with a wiki to show how to build it, and an issue tracker, all on Github.

Most of the time, when working on some piece of code, I'll resort to the configured debugger in my current Zend Studio configuration. And you probably do too :-)

However, I often have to access debug-type information on live sites where installing a debugger is out of the question, and I find myself often resorting to parameter dumps like the following:

<?php// lazy version for simple casesfunction foo_bar($x, $y, $z) {  dsm(func_get_args());  // [...]// less lazy version for more hairy casesfunction foo_baz($x, $y, $z) {  dsm(array('in foo_baz, x' => $x, 'y' => $y, 'z' => $z));  // ...?>

You've probably being using it too and, of course, after the first few dozen times, it becomes a bit used. So here's a tiny snippet that makes such dumps simpler to type and use :

For a recent case, I had to define the behaviour of a system with a lot of independent conditions to check, which could trigger any number of a set of messages and actions on data, and all of this based on a plain english (i.e. non algorithmic) description of the data, which only covered the most commons scenarios for these conditions, leaving lots of undefined combinations of inputs. What's one to do in such cases ?