Introduction à Sysdig : slides de ma présentation à Lyon, le 26 septembre 2016

26 septembre 2016 slides, sysdig, afup, aperophp

J’ai eu la chance d’être invité mercredi 26 septembre par l’antenne lyonnaise de l’AFUP, pour parler de sysdig, en introduction à une conférence sur le monitoring donnée ensuite par Rachid Zarouali.

Sur une douzaine de minutes, j’ai présenté rapidement l’outil et, surtout, montré des exemples d’utilisation que j’en ai, sur des cas réels rencontrés au boulot : des projets principalement en PHP, exécutés sur mon environnement de développement, dans des containers docker.


Les slides que j’ai utilisés comme support sont disponibles en ligne1 : Sysdig : une introduction, AFUP Lyon, 21 septembre 2016.


Merci à @AFUP_Lyon pour l’organisation et l’accueil, ainsi qu’à Rachid Zarouali pour sa conférence !



  1. Pour ceux qui voudraient plus d’informations que les slides en eux-même, j’ai noté quelques points dans les notes du présentateur, accessibles via la touche s

PHP 7.1: a few bc-breaks and conclusion

September 16, 2016 php, php-7.1, engligh

Cet article est aussi disponible en français.
This is the 11th — and last — post in a series about PHP 7.1.


To conclude this series of posts about PHP 7.1 I started two weeks ago, I will list a few points that could, especially if your code is a bit legacy, slow down upgrading.


A few BC-breaks?

In the mind of many of us, a minor version should not bring any change that breaks compatibility: code running on PHP 7.0 should work the same way on PHP 7.1 and this new version should only bring new features and bug fixes.

This principle is also written down in the Release Process RFC:

Backward compatibility must be respected with the same major releases, for example from 5.2 to 5.6.


Still, we often consider as OK for a minor version to add new E_DEPRECATED or E_NOTICE warnings, to highlight features that will be removed in the next major version or points that could be linked to bugs in our code — I even wrote about this yesterday.


That being said, behavior of some things — quite specific and rarely used — will change with PHP 7.1. I’ll list them here, as they could be of interest if your code was depending on those.


Warn about invalid strings in arithmetic

PHP is a weakly typed language, and we can do numerical calculations on strings: they are converted to integers, following the rules specified in the manual. For example, "10 pommes" can be interpreted as the number 10.

This means the following piece of code actually adds two numerical values:

var_dump('10 apples' + '5 oranges');
// int(15)


This approach was fitting well in PHP’s mindset some years ago, but is now often thought as surprising.

PHP 7.1 still accepts this syntax, but will generate a E_NOTICE warning each time such a conversion is done automatically, to get the developer’s attention:

// Notice: A non well formed numeric value encountered in .../01-warn-invalid-string-arithmetic.php on line 7
// Notice: A non well formed numeric value encountered in .../01-warn-invalid-string-arithmetic.php on line 7

If you really want this kind of conversion, you can still use explicit type-casting like (int)"10 apples".


Another case has been changed for PHP 7.1, when a string is converted to a numeric while it didn’t contain one:

var_dump(10 + "plop");
// int(10)

Instead of a E_NOTICE, this case, more surprising and probably caused by an error, now raises a E_WARNING warning:

// Warning: A non-numeric value encountered in .../01-warn-invalid-string-arithmetic.php on line 12

Note this is a warning and not a TypeError exception, which would have a much higher impact on compatibility.

‣ The RFC: Warn about invalid strings in arithmetic


Fix inconsistent behavior of $this variable

Up to PHP 7.0, we could in some situations redefine the $this variable, using a variable variable:

class MaClasse
{
    public function method()
    {
        $var = 'this';
        $$var = "plop !";
        var_dump($this);
        $this->otherMethod();
    }

    public function otherMethod()
    {
        var_dump(__METHOD__);
    }
}

$obj = new MaClasse();
$obj->method();

This portion of code, run with PHP 7.0, leads to the following output:

string(6) "plop !"
string(21) "MaClasse::otherMethod"

The first var_dump() show $this has been redefined and now contains "plop !", but the second var_dump() proves calling $this->otherMethod() still works!


As this behavior is quite surprising, this kind of redefinition of $this is not accepted by PHP 7.1 anymore and will cause an Error exception:

Fatal error: Uncaught Error: Cannot re-assign $this in .../02-fix-inconsistent-this.php:8

‣ The RFC: Fix inconsistent behavior of $this variable


Replace "Missing argument" warning with "Too few arguments" exception

With current versions of PHP, we can call a function, passing it less arguments than it expects:

function my_function($a, $b)
{
    var_dump($a, $b);
}

my_function(10);

Until PHP 7.0, this was causing a E_WARNING warning, and unspecified parameters were set to NULL:

Warning: Missing argument 2 for my_function(),
    called in .../03-missing-argument-exception.php on line 9
    and defined in .../03-missing-argument-exception.php on line 3
int(10)
NULL

As the second parameter is declared in the function’s prototype, we rarely take the time to check if it’s been received — which can lead to strange behaviors.


With PHP 7.1, this warning is transformed to an Error exception; which is much harder to just ignore!

Fatal error: Uncaught Error: Too few arguments to function my_function(),
    1 passed in .../03-missing-argument-exception.php on line 8
    and exactly 2 expected in .../03-missing-argument-exception.php:3

‣ The RFC: Replace “Missing argument” warning with “Too few arguments” exception


Forbid dynamic calls to scope introspection functions

PHP gives us a few functions that manipulate their caller’s scope: extract(), compact(), parse_str(),… They all have access, in read or write mode, to variables defined in the function from which they are called.

For example:

function my_function()
{
    $vars = [
        'a' => 123,
        'plop' => 'Hello',
    ];

    $func = 'extract';
    call_user_func($func, $vars);

    var_dump($a, $plop);
}

my_function();

With PHP 7.0, this portion of code gets us the following output:

int(123)
string(5) "Hello"

Still, with dynamic calls like call_user_func() or the $func() syntax (or other approaches), the way these functions behave is not always clearly defined — I was almost lucky it did what I wanted; here…


With PHP 7.1, dynamic calls to functions that manipulate scope are not allowed anymore and will result in a E_WARNING warning:

Warning: Cannot call extract() dynamically in .../04-dynamic-call-scope-introspection-functions.php on line 11
NULL
NULL

‣ The RFC: Forbid dynamic calls to scope introspection functions


PHP 7.1, conclusion

To conclude this series of almost a dozen posts about PHP 7.1, what can I say?


This second minor version of the PHP 7 branch, which is going to be released about one year after PHP 7.0, brings its share of new stuff — including features I find interesting and will use, like:

  • nullable types
  • The iterable pseudo-type
  • The Closure::fromCallable() method
  • A few small enhancements to syntax and consistency

It is also, clearly, an evolution and not a revolution: this should make migrating from PHP 7.0 quite easy.


Still, I’m a bit sad seeing several bc-breaks, which don’t all seem justified to me for this minor version. Even if they should not have much impact on the applications I’m working on, they might scare less adventurous developers and slow down adoption of this new version.


And, finally, one reminder: take a loot at the Supported Versions page every now and then. You’ll for example notice active support for PHP 7.0 ends in about one year, leaving place to PHP 7.1 ;-)


PHP 7.1 : quelques bc-breaks et conclusion

16 septembre 2016 php, php-7.1

This post is also available in English.
Ceci est le onzième — et dernier — article d’une série à propos de PHP 7.1.


Pour terminer cette série d’articles, commencée il y a deux semaines, je vais essayer de lister quelques points qui pourraient, en particulier si votre code est un peu legacy, ralentir la montée de version.


Quelques BC-breaks ?

Dans l’esprit de beaucoup d’entre nous, une version mineure ne devrait pas apporter de changement cassant la compatibilité : du code qui tourne sous PHP 7.0 devrait fonctionner à l’identique sous PHP 7.1 et seuls des ajouts de fonctionnalités et de corrections de bugs devraient caractériser cette nouvelle version.

On retrouve d’ailleurs ce principe dans la RFC Release Process :

Backward compatibility must be respected with the same major releases, for example from 5.2 to 5.6.


Il est toutefois généralement considéré comme acceptable pour une version mineure que de nouveaux avertissements de niveau E_DEPRECATED ou E_NOTICE soient ajoutés, pour identifier des fonctionnalités qui seront supprimées d’une version majeure suivante ou des points qui sont fort susceptibles d’être liés à des bugs dans notre code — j’en ai d’ailleurs parlé hier.


Cela dit, le comportement de quelques points — assez spécifiques et rarement utilisés — va changer avec PHP 7.1 ; je vais tâcher de les lister ci-dessous, la liste peut vous intéresser si votre code en dépendait.


Warn about invalid strings in arithmetic

PHP est un langage au typage souple, qui permet d’effectuer des calculs numériques sur des chaines : elles seront converties en entier selon les règles spécifiées dans la documentation. Par exemple, "10 pommes" peut être interprété comme le nombre 10.

Ainsi, l’écriture suivante revient à additionner deux numériques :

var_dump('10 apples' + '5 oranges');
// int(15)


Cette approche, qui était assez dans la philosophie de PHP il y a quelques années, est plus souvent considérée comme surprenante aujourd’hui.

PHP 7.1 supporte toujours cette écriture, mais accompagnera les conversions effectuées automatiquement d’un avertissement de niveau E_NOTICE, pour attirer l’attention du développeur :

// Notice: A non well formed numeric value encountered in .../01-warn-invalid-string-arithmetic.php on line 7
// Notice: A non well formed numeric value encountered in .../01-warn-invalid-string-arithmetic.php on line 7

Si vous comptiez réellement sur ces conversions, vous pouvez passer par des transtypages explicites comme (int)"10 apples".


L’autre cas revu pour PHP 7.1 est celui où une chaine est convertie en numérique alors qu’elle n’en contenait même pas :

var_dump(10 + "plop");
// int(10)

Au lieu d’une E_NOTICE, ce cas, plus surprenant et plus probablement causé par une erreur, lève désormais un avertissement de niveau E_WARNING :

// Warning: A non-numeric value encountered in .../01-warn-invalid-string-arithmetic.php on line 12

Notez qu’il s’agit d’un avertissement et pas d’une levée de TypeError, qui aurait un impact nettement plus important sur la compatibilité.

‣ La RFC : Warn about invalid strings in arithmetic


Fix inconsistent behavior of $this variable

Jusqu’à PHP 7.0 inclus, il était possible, dans certains cas, de redéfinir la variable $this, en passant par une variable variable :

class MaClasse
{
    public function method()
    {
        $var = 'this';
        $$var = "plop !";
        var_dump($this);
        $this->otherMethod();
    }

    public function otherMethod()
    {
        var_dump(__METHOD__);
    }
}

$obj = new MaClasse();
$obj->method();

La portion de code ci-dessus, exécutée avec PHP 7.0, donnait la sortie suivante :

string(6) "plop !"
string(21) "MaClasse::otherMethod"

Le premier var_dump() montre que la variable $this a été redéfinie et qu’elle vaut désormais "plop !", mais le second var_dump() montre que l’appel de méthode $this->otherMethod() a tout de même fonctionné !


Ce comportement étant fort surprenant, ce type de redéfinition de $this n’est plus supporté par PHP 7.1 et mènera à la levée d’une exception de type Error :

Fatal error: Uncaught Error: Cannot re-assign $this in .../02-fix-inconsistent-this.php:8

‣ La RFC : Fix inconsistent behavior of $this variable


Replace "Missing argument" warning with "Too few arguments" exception

Historiquement, PHP permet d’appeler une fonction en lui passant moins de paramètres qu’elle n’en attendait :

function my_function($a, $b)
{
    var_dump($a, $b);
}

my_function(10);

Jusqu’à PHP 7.0 inclus, cet appel levait un avertissement de niveau E_WARNING et les paramètres non spécifiés recevaient la valeur NULL :

Warning: Missing argument 2 for my_function(),
    called in .../03-missing-argument-exception.php on line 9
    and defined in .../03-missing-argument-exception.php on line 3
int(10)
NULL

Le second paramètre étant déclaré dans le prototype de la fonction, il est rare qu’on prenne la peine de vérifier qu’il a bien été reçu ; et cela peut mener à des comportements étranges.


Avec PHP 7.1, cet avertissement est transformé en une exception de type Error ; il devient donc nettement plus difficile de l’ignorer !

Fatal error: Uncaught Error: Too few arguments to function my_function(),
    1 passed in .../03-missing-argument-exception.php on line 8
    and exactly 2 expected in .../03-missing-argument-exception.php:3

‣ La RFC : Replace “Missing argument” warning with “Too few arguments” exception


Forbid dynamic calls to scope introspection functions

PHP fournit plusieurs fonctions qui manipulent le scope de leur appelant : extract(), compact(), parse_str(),… Elles accèdent toutes, en lecture ou en écriture, aux variables définies dans la fonction où elles sont appelées.

Par exemple :

function my_function()
{
    $vars = [
        'a' => 123,
        'plop' => 'Hello',
    ];

    $func = 'extract';
    call_user_func($func, $vars);

    var_dump($a, $plop);
}

my_function();

Avec PHP 7.0, cette portion de code mènera à la sortie suivante :

int(123)
string(5) "Hello"

Toutefois, en cas d’appels dynamiques via call_user_func() ou la syntaxe $func() (ou d’autres approches), la façon dont ces fonctions vont se comporter n’est pas toujours clairement définie — j’ai presque eu de la chance que ça fasse ce que je voulais, ici…


Avec PHP 7.1, les appels dynamiques aux fonctions de manipulation de scope ne sont plus permis et mèneront à un avertissement de niveau E_WARNING :

Warning: Cannot call extract() dynamically in .../04-dynamic-call-scope-introspection-functions.php on line 11
NULL
NULL

‣ La RFC : Forbid dynamic calls to scope introspection functions


PHP 7.1, en conclusion

Pour conclure cette série d’une bonne dizaine d’articles sur PHP 7.1, que dire ?


Cette seconde version mineure de la branche PHP 7, qui arrive environ un an après la sortie de 7.0, apporte son lot de nouveautés — y compris des fonctionnalités qui me semblent intéressantes et que j’utiliserai, comme :

  • Les nullable types
  • Le pseudo-type iterable
  • La méthode Closure::fromCallable()
  • Quelques petites améliorations de syntaxe et de cohérence

Il s’agit aussi, clairement, d’une évolution et pas d’une révolution : cela devrait grandement faciliter la mise à jour depuis PHP 7.0.


Toutefois, je suis triste de voir apparaitre plusieurs bc-breaks, qui ne me semblent pas tous réellement justifiés sur cette version mineure. Même s’ils ne devraient avoir que peu d’impact sur les applications sur lesquelles j’interviens, elles risquent d’effrayer certains développeurs moins téméraires et de ralentir l’adoption de cette nouvelle version.


Pour terminer, un rappel : pensez à consulter la page Supported Versions de temps en temps. Vous verrez ainsi que le support actif de PHP 7.0 se termine dans un an, pour laisser la place à PHP 7.1 ;-)


PHP 7.1: the road towards PHP 7.2 and PHP 8.0

September 15, 2016 php, php-7.1, english

Cet article est aussi disponible en français.
This is the 10th post in a series about PHP 7.1.


PHP 7.1 is only the second minor version of the PHP 7 branch, but some are already thinking about what’s next: the next minor release, PHP 7.2; and the next major version, what might become PHP 8.0.


Some removal for PHP 8.0

There are not (yet?) any deep changes in the engine, but the idea for now is to start adding some E_DEPRECATED or E_NOTICE warning on features you should not be using with PHP 7.x — and, then, to remove them in PHP 8.0.

Eval option of mb_ereg_replace()

The /e modifier of preg_replace() has been removed with PHP 7.0 (‣RFC), but it still exists for mb_ereg_replace().

To make things more consistent, using this dangerous modifier for functions mb_ereg_replace() and mb_eregi_replace() with PHP 7.1 will raise a E_DEPRECATED warning.

Instead, use mb_ereg_replace_callback().

This modifier should later be removed, with PHP 8.0.

‣ The RFC: Deprecate mb_ereg_replace() eval option


The end of mcrypt?

The mcrypt extension is based on a library that’s not been maintained for years — which is a bit of a problem, considering it’s related to security!

When PHP 7.0 was in development, there were talks about removing this extension. But, as many developers are still using it, it’s not been done.

To facilitate migration and leave more time to developers, mcrypt will be flagged as deprecated starting from PHP 7.1: using it will cause E_DEPRECATED warnings.

The mcrypt extension should then be removed for PHP 8.0.

‣ The RFC: Deprecate (then Remove) Mcrypt


And for PHP 7.2?

As the release of PHP 7.1 is getting close, adding features to this version is not possible anymore — it’s not been permitted for a few months now, actually.

No surprise: a couple of ideas are already being discussed, for what might become the next version: PHP 7.2.


Here are a few RFCs resulting from these ideas.

As always, some of those will follow the process until the voting phase, a few will pass, and many will be forgotten:

Once again: the fact an RFC has been written does not mean the corresponding idea will lead to a new feature for PHP!


PHP 7.1: actually… No!

September 15, 2016 php, php-7.1, english

Cet article est aussi disponible en français.
This is the 9th post in a series about PHP 7.1.


These past few days, I wrote about the new features we’ll soon get in PHP 7.1. That being said, during about one year of development, a great number of other ideas have been discussed, many other RFCs have been written.

Some of these RFCs went to the voting phase and have been rejected, others didn’t go that far in the process, some might have been canceled… Well, many ideas have been discussed, and I’ll try listing them all here.

First, here are some RFCs that have been rejected, but caught my eyes when I recently re-read their titles:

And now, here are other proposals that have been discussed, even if the corresponding RFCs didn’t go as far as the voting phase (I think) — which means they weren’t rejected, but didn’t pass either:

Some of these were rather interesting… And even if the majority will not make a come back later, we can reasonably think a few will be re-discussed in the future!