Evert Pot207 Multi-Status (21.8.2018, 14:00 UTC)

207 Multi-Status is used primarily by WebDAV servers. I don’t think it’s used much outside of WebDAV, if at all.

The WebDAV specification describes this statuscode as an indicator to a client that multiple operations happened, and that the status for each operation can be found in the body of the response.

So unlike other 2xx codes, getting a 207 doesn’t necessarily mean the operation succeeded. It just means that the client should inspect the body to get the true information about the operation.

The most common WebDAV example is that it has a feature to get information about multiple resources all at once via the PROPFIND HTTP method. The server can then report information about each individual resource via this code.

Here’s an example of a typical 207 response:

HTTP/1.1 207 Multi-Status
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx

<d:multistatus xmlns:d="DAV:">
            <d:status>HTTP/1.1 200 OK</d:status>
            <d:status>HTTP/1.1 200 OK</d:status>

In the preceeding response, 2 resources are reported and for each a getetag WebDAV property is reported. Fully explaining the WebDAV model is outside the scope of this article.

You could imagine that 207 might be repurposed by some JSON-based API. For example, if a client made some kind of batch request, and a server wants to report back on the success of each individual item.

Perhaps this response looks somewhat like this:

HTTP/1.1 207 Multi-Status
Content-Type: application/json
Content-Length: xxxx

  "results": [
      "href": "/batch/5/item/1",
      "status": 200
      "href": "/batch/5/item/2",

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

Matthias NobackImproving your software project by being intolerant (21.8.2018, 09:00 UTC)

During the holiday I read a book mentioned to me by Pim Elshoff: "Skin in the game", by Nassim Nicholas Taleb. Discussing this concept of "skin in the game" with Pim had made me curious about the book. It's not such a fat book as one of Taleb's other books, which is possibly more famous, called "Antifragile". "Skin in the game" is a much lighter book, and also quite polemic, making it an often uncomfortable, but fun reading experience. I can easily see how people could get mad about this book or aggressive towards its author (not that I'm encouraging or approving of that aggression!). While reading it, it reminded me of Nietzsche, and his despise of the "common man", who Taleb calls "the intellectual" - someone who has no "skin in the game", let alone "soul in the game". Taleb's ideas are interesting, just like Nietzsche's are, but they could easily be abused, and probably so by misinterpreting them.

Intolerance wins

Something that's controversial, yet interesting for me as a developer in a team - from Chapter 2, "The Most Intolerant Wins: The Dominance of the Stubborn Minority":

Society doesn't evolve by consensus, voting, majority, committees, verbose meetings, academic conferences, tea and cucumber sandwiches, or polling; only a few people suffice to disproportionately move the needle. All one needs is an asymmetric rule somewhere—and someone with soul in the game. And asymmetry is present in about everything.

Taleb, Nassim Nicholas. Skin in the Game: Hidden Asymmetries in Daily Life (p. 83). Penguin Books Ltd. Kindle Edition.

This made me aware of something that I had observed several times before, whenever I was part of a software development team - or "software development society": the biggest impact on quality (to be interpreted in many different ways) isn't made by reaching consensus, or voting, or being tolerant to other people's opinions or ways of coding at all. What makes the biggest impact is the opposite: being intolerant of all those different styles, approaches, and being stubborn about your own way. As the title of the chapter says: "the most intolerant wins".

For example, how do you improve the coding style of a project? Maybe by discussing which styles you all like, and agreeing on one, then agreeing that all of you will apply it from now on? No, you can only achieve a consistent coding style by enforcing it everywhere and being very intolerant about it (that is, only allowing commits that conform to this particular style).

Another example: would you leave it up to your fellow developers to decide whether they will use static methods to fetch dependencies, or they inject all dependencies as constructor arguments? If you allow both, the result will be a mess. You can't even rely on a single class using either of these options - a class may even use both at the same time! (See also "Negative architecture, and assumptions about code"). You will be considered a tolerant developer, but it's not for the good of the project. Again, intolerance is needed to drastically improve and guard the quality of your project.

One more example: if you know that the project would be better off with a Docker setup, do you ask management for permission to make it so? Do you vote? You won't get the minority vote, let alone get scheduled time for it during regular work hours. It may very well be that you have the biggest chance of success when you just do it. There's one rule though: if things become messy, take full responsibility and adapt: you made a mistake, just roll it back (or don't roll it out in the first place). This is where you make sure you have skin in the game.

Do more than you talk

This leads me to quoting Taleb again:

[...] always do more than you talk. And precede talk with action. For it will always remain that action without talk supersedes talk without action.

Taleb, Nassim Nicholas. Skin in the Game: Hidden Asymmetries in Daily Life (p. 122). Penguin Books Ltd. Kindle Edition.

Over the past 20 years I've had lots of conversations with developers and managers, that eventually turned out to be just talk, no action. I don't know about your experiences (would love to hear about them though!), but this is a very common characteristic of "conversations in tech"; lots of meetings, lots of discussions, cool ideas, great plans, but none of it is going to happen. For many reasons of course, like:

  • The managers in the meeting just want to keep the developers happy, so they allow them to make great plans, which will never be executed.
  • The developers are not happy about their job anymore, so the

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

PHP: Hypertext PreprocessorPHP 7.1.21 Released (17.8.2018, 00:00 UTC)
The PHP development team announces the immediate availability of PHP 7.1.21. This is a bugfix release. All PHP 7.1 users are encouraged to upgrade to this version. For source downloads of PHP 7.1.21 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: Hypertext PreprocessorPHP 7.3.0.beta2 Released (16.8.2018, 00:00 UTC)
The PHP team is glad to announce the release of the sixth PHP 7.3.0 version, PHP 7.3.0beta2. The rough outline of the PHP 7.3 release cycle is specified in the PHP Wiki. For source downloads of PHP 7.3.0beta2 please visit the download page. Windows sources and binaries can be found on windows.php.net/qa/. Please carefully test this version and report any issues found in the bug reporting system. THIS IS A DEVELOPMENT PREVIEW - DO NOT USE IT IN PRODUCTION! For more information on the new features and other changes, you can read the NEWS file, or the UPGRADING file for a complete list of upgrading notes. Internal changes are listed in the UPGRADING.INTERNALS file. These files can also be found in the release archive. The next release would be Beta 3, planned for August 30th. The signatures for the release can be found in the manifest or on the QA site. Thank you for helping us make PHP better.
Voices of the ElePHPantInterview with Adam Culp (15.8.2018, 12:00 UTC)

This episode is sponsored by


The post Interview with Adam Culp appeared first on Voices of the ElePHPant.

Nomad PHPWebsockets in PHP (14.8.2018, 13:09 UTC)

October - US
Presented By

John Fansler
October 18, 2018
20:00 CDT

The post Websockets in PHP appeared first on Nomad PHP.

Evert Pot206 Partial Content (14.8.2018, 10:00 UTC)

206 Partial Content is used for range requests. It’s possible for a HTTP client to request only portions of a resource using range requests.

Examples of this might include a large log resource for which a client only wants the last n bytes. Or maybe a video and the client doesn’t want to buffer more data than needed, or maybe a user is seeking through the video by fast-forwarding.

If a client issued a range request, and the server is able to handle this feature, it can indicate to the client that it’s sending back only certain ranges with the 206 Partial Content status, and Content-Range headers.

The following request asks the server for a portion of a video:

GET /video.mp4 HTTP/1.1
Range: bytes=1048576-2097152

A server supporting this could respond as follows:

HTTP/1.1 206 Partial Content
Content-Range: bytes 1048576-2097152/3145728
Content-Type: video/mp4


If a server doesn’t support Range requests, it will just return a 200 OK and send back the entire video. A client will know that the server didn’t support it via this status code and the omission of the Content-Range header.


  • RFC7233 - (HTTP/1.1): Range Requests
Matthias NobackMore code comments (13.8.2018, 12:10 UTC)

Recently I read a comment on Twitter by Nikola Poša:

He was providing us with a useful suggestion, one that I myself have been following ever since reading "Clean Code" by Robert Martin. The paraphrased suggestion in that book, as well as in the tweet, is to consider a comment to be a naming issue in disguise, and to solve that issue, instead of keeping the comment. By the way, the book has some very nice examples of how comments should and should not be used.

The code comment as a naming issue

I think in most cases, indeed, we don't need comments. Common suggestions are, like Nikola suggests as well:

  • Introduce a variable with a meaningful name, which can hold the result of a complicated expression.
  • Introduce a method with a meaningful name, which can hide a piece of complicated logic.

The "hiding" that a method does, provides you with two interesting options:

  1. The method name can summarize a number of statements.
  2. The method name can represent a concept that is of a higher level than the lower-level things that are going on inside the method.

Option 1 is useful, but if you can go for option 2, it'll be the most valuable option.

Consider Nikola's example:

if ($date->hour < 9 || $date->hour > 17) { //Off-hours?

Option 1 would entail something like:

if ($this->hourIsBetween9And17($date->hour)) { //Off-hours?

Option 2 would be much more interesting and useful:

if ($this->isAnOffHour($date->hour)) {

This introduces abstraction, where the client doesn't care about the concrete details of determining whether or not a certain hour is an off-hour, but only wants to know if the given hour is indeed an off-hour.


I realized I'm always applying the following rule: if I feel like writing a comment, I look for a way in which I can change the code so that I don't have to write a comment anymore. Also, when I encounter a comment in an existing code base, I apply the same rule, and look for ways to remove the comment. Because, as you may know, code can't lie, but comments can, so let's get rid of them before they become a risk.

However, contrary to my own advise, I also realized that I've actually been writing more and more comments over the past few months. So what's going on?

A little soul-searching revealed that I've been adding code comments that can be categorized as follows:

  1. Explanatory comments: ~70%
  2. TODO comments: ~20%
  3. WTF comments: ~10%

Explanatory comments

I've been adding explanatory comments to parts in the code that need an explanation, or a canonical description of the situation. Most often these comments can be found near a couple of statements in the domain model. The comment then explains why a certain business rule should be applied, and how the code beneath the comment actually accomplishes this. Of course, I try to match the words in the comment with the words in the code itself, so they are tied together.

Before adding an explanatory comment, I often try to rephrase the explanation as a test first. This is usually the better option, since it will make sure that the code and its documentation will never diverge. The test is the documentation that describes a piece of the code, and if the code is no longer truthful to that description, the test will fail. An even better option is to apply behavior-driven development, where tests can actually be written as stories with examples, and they will serve as automated tests at the same time.

Still, some things just need a whole paragraph of explaining, and in that case, I happily put the explanation in the code, and take my time (and a long-form commenting style like /* ... */) to explain what's going on.

"Here's a question: why don't you create a separate document, instead of a code comment?"

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

PHP-GTK CommunityBeanstalkd Munin PHP 1.0.0 (12.8.2018, 19:10 UTC)
Logo Munin monitoring

Créé en 2014 sur la base des plugins Munin d'AirBnB pour Beanstalkd en Python, le package OSInet beanstalk-munin-php est dorénavant disponible en version 1.0.0.

Ces plugins pour Munin 2.x permettent la surveillance des métriques suivantes:

  • bs_cmd_rate.php : fréquence des commandes put, reserve, reserve_timeout, delete, touch, release et bury
  • bs_connections.php : gauge des connexions ouvertes
  • bs_jobs_rate.php : dérivée du nombre total de travaux traités
  • bs_queue_age.php : gauge de la durée d'attente des travaux dans les tubes (files)
  • bs_queue_size.php : gauge du nombre de travaux par état: ready, urgent, reserved, delayed, buried
  • bs_timeouts.php : dérivée du nombre de timeouts par unité de temps

Ces plugins sont publiés sous licence Apache APL-2.0, et conformes aux normes PHP-FIG: PSR1, PSR2, PSR12 et au standard de codage Zend.

Voices of the ElePHPantInterview with Chris Rowe (8.8.2018, 14:07 UTC)

This episode is sponsored by


The post Interview with Chris Rowe appeared first on Voices of the ElePHPant.

LinksRSS 0.92   RDF 1.
Atom Feed   100% Popoon
PHP5 powered   PEAR
ButtonsPlanet PHP   Planet PHP
Planet PHP