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.
Link
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.
Link
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.

Link
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.

Link
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.

References

  • RFC7233 - (HTTP/1.1): Range Requests
Link
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.

#NoComments?

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)

Link
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.

Link
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.

Link
Evert Pot205 Reset Content (7.8.2018, 15:00 UTC)

205 Reset Content is somewhat similar to 204 No Content. It’s especially meant for hypertext applications.

Imagine if a user is filling in a HTML form, and this form gets submitted to the server.

If the server sends back a 204, a browser could act on this by telling the user the form submission was successful and NOT refresh the page.

If the server sent back a 205, a browser can reset the form, similar to a a reset button a HTML form:

<input type="reset" />

Browsers could implement this, but at least according to an article from 2008 by Ben Ramsey, they don’t. Implementing this status by a HATEOAS client could definitely still make sense though.

Example response:

HTTP/1.1 205 Reset Content
Server: foo-bar/1.2
Connection: close

References

Link
Pascal LandauHow to setup PhpStorm with Xdebug on Docker [Tutorial Part 2] (6.8.2018, 12:00 UTC)

In the second part of this tutorial series on developing PHP on Docker we're taking a good hard look at PhpStorm, Xdebug and how to run and debug scripts from within PhpStorm on Docker.

And just as a reminder, the first part is over at Setting up PHP, PHP-FPM and NGINX for local development on Docker.

Note: The setup that I am going to use is for demonstration purposes only! I do not recommend that you use it "as is" as your development setup. Some problems that I won't solve here include:

  • everything is owned by root (no dedicated user; that will in particular be problematic for linux users)
  • SSH login credentials are hard-coded in the container (inherently insecure)
  • host.docker.internal will only exist for Windows and Mac users, NOT for unix users

There will be a another part of this series that will deal with all of those (and some more common) problems and aims at providing a consistent development environment for all developers in a team (regardless of the OS they are using). Please subscribe to the RSS feed to get automatic notifications when that part comes out :)

Table of contents

Setup: The docker containers

We will only need the php-cli container for this part. Luckily, we already have a good understanding on how to create the container, although we'll need to make some adjustments to make everything work smoothly with PhpStorm. I'm gonna walk you through all the necessary changes, but I'd still recommend to clone the corresponding git repository docker-php-tutorial (unless you've already done that in part 1), checkout branch part_2 and build the containers now.

As in part 1, I'm assuming your codebase lives at /c/codesbase:

cd /c/codebase/
git clone https://github.com/paslandau/docker-php-tutorial.git
cd docker-php-tutorial
git checkout part_2
docker-compose docker-compose build

Further, make sure to open /c/codebase/docker-php-tutorial as a project in PhpStorm.

In general, there are two ways to run PHP from PhpStorm using Docker:

  1. via the built-in Docker setup
  2. via Deployment Configuration (treating docker more or less like a VM)

Run PHP via built-in Docker setup

This is the "easier" way and should mostly work "out of the box". When you run a PHP script using this method, PhpStorm will start a docker container and configure it automatically (path mappings, network setup, ...). Next, the script in question is executed and the container is stopped afterwards.

Enable docker to communicate on port 2375

Open the Docker Setting in tab "General" and activate the checkbox that says "Expose daemon on tcp://localhost:2375 without TLS".

Enable docker to communicate on port 2375

Configure Docker Server in PhpStorm

In PhpStorm, navigate to File |

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

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