PHP: Hypertext PreprocessorPHP 7.2.0 Alpha 2 Released (22.6.2017, 00:00 UTC)
The PHP development team announces the immediate availability of PHP 7.2.0 Alpha 2. This release contains fixes and improvements relative to Alpha 1. All users of PHP are encouraged to test this version carefully, and report any bugs and incompatibilities in the bug tracking system.THIS IS A DEVELOPMENT PREVIEW - DO NOT USE IT IN PRODUCTION!For information on new features and other changes, you can read the NEWS file, or the UPGRADING file for a complete list of upgrading notes. These files can also be found in the release archive.For source downloads of PHP 7.2.0 Alpha 2 please visit the download page, Windows sources and binaries can be found on third and final alpha will be released on the 6th of July. You can also read the full list of planned releases on our wiki.Thank you for helping us make PHP better.
Voices of the ElePHPantInterview with Heather White (21.6.2017, 17:29 UTC) Link
SitePoint PHPWhat Is Snapshot Testing, and Is It Viable in PHP? (21.6.2017, 16:00 UTC)

A vector image of a polaroid glued to a transparent background

Ah-ha moments are beautiful and rare in programming. Every so often, we're fortunate enough to discover some trick or facet of a system that forever changes how we think of it.

For me, that's what snapshot testing is.

You probably write a lot of PHP code, but today I want to talk about something I learned in JavaScript. We'll learn about what snapshot testing is and then see how it can help us write better PHP applications.

Building Interfaces

Let's talk about React. Not the kick-ass async PHP project, but the kick-ass JavaScript project. It's an interface-generation tool in which we define what our interface markup should look like as discrete parts:

function Tweet(props) {
  return (
    <div className="tweet">
      <img src={props.user.avatar} />
      <div className="text">
        <div className="handle">{props.user.handle}</div>
        <div className="content">{props.content}</div>

function Tweets(props) {
  return (
    <div className="tweets">
      {, i) => {
        return (
          <Tweet {...tweet} key={i} />

This doesn't look like vanilla Javascript, but rather an unholy mix of HTML and Javascript. It's possible to create React components using regular Javascript syntax:

function Tweet(props) {
  return React.createElement(
    { className: "tweet" },
    React.createElement("img", { src: props.user.avatar }),
      { className: "text" },
        { className: "handle" },
        { className: "content" },

To make this code, I pasted the Tweet function (above) into the Babel REPL. That's what all React code is reduced to (minus the occasional optimization) before being executed by a browser.

Before I talk about why this is cool, I want to address a couple of issues...

"Why Are You Mixing HTML and Javascript?!"

We've spent a lot of time teaching and learning that markup shouldn't be mixed with logic. It's usually couched in the phrase "Separation of Concerns". Thing is, splitting HTML and the Javascript which makes and manipulates that HTML is largely without value.

Splitting that markup and Javascript isn't so much separation of concerns as it is separation of technologies. Pete Hunt talks about this in more depth in this video.

"This Syntax Is Very Strange"

That may be, but it is entirely possible to reproduce in PHP and works out the box in Hack:

class :custom:Tweet extends :x:element {
  attribute User user;
  attribute string content;

  protected function render() {
    return (
      <div class="tweet">
        <img src={$this->:user->avatar} />
        <div class="text">
          <div class="handle">{$this->:user->handle}</div>
          <div class="content">{$this->:content}</div>

I don't want to in detail about this wild syntax except to say that this syntax is already possible. Unfortunately, it appears the official XHP module only supports HHVM and old versions of PHP...

Testing Interfaces

There are many testing approaches – some more effective than others. An effective way to test interface code is by faking (or making) a web request and inspecting the output for the presence and content of specific elements.

Perhaps you've heard of things like Selenium and Behat? I don't want to dwell too much on them. Let's just say that Selenium is a tool we can use to pretend to be a browser, and Behat is a business-friendly language for scripting such pretense.

Unfortunately, a lot of browser-based testing can be brittle. It's tied to the exact struct

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

Rob AllenSimple way to add a filter to Zend-InputFilter (21.6.2017, 10:02 UTC)

Using Zend-InputFilter is remarkably easy to use:

use Zend\InputFilter\Factory as InputFilterFactory;

// set up InputFilter
$specification = [
    'my_field' => [
        'required' => false,
        'filters' => [
            ['name' => 'StringTrim'],
$factory = new InputFilterFactory();
$inputFilter = $factory->createInputFilter($specification);

// use InputFilter on some data
$data['my_field] = 'Some string';
if ($inputFilter->isValid()) {
    Return false;
return $inputFilter->getValues(); // my_field is now trimmed

How do you add your filter to it though?

This is the world's most simple filter that does absolutely nothing: We'll call it MyFilter and store it in App\Filter\MyFilter.php:

namespace App\Filter;

use Zend\Filter\AbstractFilter;

class ToString extends AbstractFilter
    public function filter($value)
        // do something to value here
        return $value;

Now you have a couple of choices:

Extend Zend\InputFilter\Factory

I needed to add my own filter in the least invasive way that I could and so I created App\InputFilter\Factory which extends Zend\InputFilter\Factory:

namespace App\InputFilter;

use App\Filter\MyFilter;
use Zend\InputFilter\Factory as BaseFactory;
use Zend\InputFilter\InputFilterPluginManager;
use Zend\ServiceManager\Factory\InvokableFactory;

class Factory extends BaseFactory
     * @param InputFilterPluginManager $inputFilterManager
    public function __construct(InputFilterPluginManager $inputFilterManager = null)

        // register our own filters
        $filterPluginManager = $this->getDefaultFilterChain()->getPluginManager();
        $filterPluginManager->setFactory(MyFilter::class, InvokableFactory::class);
        $filterPluginManager->setAlias('MyFilter', MyFilter::class);

This class extends the standard Factory class and registers our filter into the filter chain's plugin manager. Note that we have to register the factory for the fully qualified filter classname and also we register an alias for the short form ('MyFilter') as that's much nicer to use in the specification.

To use our new factory, we change the use statement to use our new factory:

use App\InputFilter\Factory as InputFilterFactory;

Now we can use 'MyFilter' in our specification:

$specification = [
    'my_field' => [
        'required' => false,
        'filters' => [
            ['name' => 'StringTrim'],
            ['name' => 'MyFilter'],

Update your container's factory

If you're already injecting the InputFilter's Factory to the class that's specifying the InputFilter, then it's easier to update that factory. For Pimple, this looks something like:

use App\Filter\MyFilter;
use Zend\InputFilter\Factory;
use Zend\ServiceManager\Factory\InvokableFactory;

$container['InputFilterFactory'] = function ($c) {
    $factory = new Factory();

    // register our own filters
    $filterPluginManager = $factory->getDefaultFilterChain()->getPluginManager();
    $filterPluginManager->setFactory(MyFilter::class, InvokableFactory::class);
    $filterPluginManager->setAlias('MyFilter', MyFilter::class);
    $inputFilter = $factory->createInputFilter($specification);

    return $factory;

We don't need to change anything else and we can use 'MyFilter' in our specification:

$specification = [
    'my_field' => [
        'required' => false,
        'filters' => [
            ['name' => 'StringTrim'],
            ['name' => 'MyFilter'],
Matthias NobackHow to make Sculpin skip certain sources (20.6.2017, 19:30 UTC)

Whenever I run the Sculpin generate command to generate a new version of the static website that is this blog, I notice there are a lot of useless files that get copied from the project's source/ directory to the project's output/ directory. All the files in the output/ directory will eventually get copied into a Docker image based on nginx (see also my blog series on Containerizing a static website with Docker). And since I'm on a hotel wifi now, I realized that now was the time to shave off any unnecessary weight from this Docker image.

My biggest mistake was not googling for the quickest way to skip certain sources from getting copied to output/. Instead, I set out to hook into Sculpin's event system. I thought it would be a good idea to create an event subscriber and make it subscribe to the Sculpin::EVENT_BEFORE_RUN event. Event subscribers for this event will receive a so-called SourceSetEvent, allowing them to mark certain sources as "should be skipped".

Sculpin is built on many Symfony components and it turned out to be quite easy to set up a traditional event subscriber, which I called SkipSources:

final class SkipSources implements EventSubscriberInterface
     * @var string[]
    private $patterns = [];

    public function __construct(array $patterns)
        $this->patterns = $patterns;

    public function skipSourcesMatchingPattern(SourceSetEvent $event): void
        // see below

    public static function getSubscribedEvents(): array
        return [
            Sculpin::EVENT_BEFORE_RUN => ['skipSourcesMatchingPattern']

You can create your own Symfony-style bundles for a Sculpin project, but in this case defining a simple service in sculpin_kernel.yml seemed to me like a fine option too:

# in app/config/sculpin_kernel.yml

        class: SculpinTools\SkipSources
            # more about this below
            - ["components/*", "_css/*", "_js/*"]
            - { name: kernel.event_subscriber }

Due to the presence of the kernel.event_subscriber tag Symfony will make sure to register this service for the events returned by its getSubscribedEvents() method.

Looking for a way to use glob-like patterns to filter out certain sources, I stumbled on the fnmatch() function. After that, the code for the skipSourcesMatchingPattern() method ended up being quite simple:

foreach ($event->allSources() as $source) {
    foreach ($this->patterns as $pattern) {
        if (fnmatch($pattern, $source->relativePathname())) {

It matches a source with each of the patterns based on the source's relative pathname, as nothing outside of the source/ directory is relevant anyway. The patterns themselves are passed in as the event subscriber's first constructor argument. It's simply a list of glob-like string patterns.

My solution turned out to be quite an effective way to mark certain files as "should be skipped", which was my goal.

La grande finale

Just like in my previous blog post, I finally ran into another possible solution, that's actually built in to Sculpin - a simple ignore configuration key allowing you to ignore certain sources using glob-like patterns. It does use a rather elaborate pattern matching utility based on code from Ant. Not sure if this library and fnmatch() have "feature parity" though.

Turns out, all my extra work wasn't required after all. A simple Google search would have sufficed!

So I removed all of this code and configuration from my project. But I still wanted to share my journey with you. And who knows, it could just be useful to have an example lying around of how to register an event subscriber and hook into Sculpin's build lifecycle...

Matthias NobackMaking a Docker image ready for use with Swarm Secrets (19.6.2017, 19:30 UTC)

Here's what I wanted to do:

  • Run the official redis image as a service in a cluster set up with Docker Swarm.
  • Configure a password to be used by connecting clients. See also Redis's AUTH command. The relevant command-line option when starting the redis server would be --requirepass.

This is just a quick post, sharing what I've figured out while trying to accomplish all of this. I hope it's useful in case you're looking for a way to make a container image (an official one or your own) ready to be used with Docker Secrets.

I started out with this docker-compose.yml configuration file, which I provided as an option when running docker stack deploy:

version: '3.1'

        image: redis
        command: redis-server --requirepass $(cat /run/secrets/db_password)
            - db_password

        file: db_password.txt

This configuration defines the db_password secret, the (plain text) contents of which should be read from the db_password.txt file on the host machine. The (encrypted) secret will be stored inside the cluster. When the redis service gets launched on any node in the cluster, Docker shares the (decrypted) secret with the container, by means of mounting it as a file (i.e. /run/secrets/db_password) inside that container.

The naive solution above looked simple and I thought that it might just work. However, I got this error message:

Invalid interpolation format for "command" option in service "redis": "redis-server --requirepass $(cat /run/secrets/db_password)"

Docker Compose does variable substitution on commands and thinks that $(...) is invalid syntax (it's expecting ${...}). I escaped the '$' by adding another '$' in front of it: redis-server --requirepass $$(cat /run/secrets/db_password). New errors:

Reading the configuration file, at line 2
>>> 'requirepass "$(cat" "/run/secrets/db_password)"'
Bad directive or wrong number of arguments

Bad stuff. I thought I'd just have to wrap the values into quotes: redis-server --requirepass "$(cat /run/secrets/db_password)". Now, everything seemed to be fine, the Redis service was up and running, except that the password wasn't set to the contents of the db_password. Instead, when I tried to connect to the Redis server, the password seemed to have become literally "$(cat /run/secrets/db_password)"...

At this point I decided: let's not try to make this thing work from inside the docker-compose.yml file. Instead, let's define our own ENTRYPOINT script for a Docker image that is built on top of the existing official redis image. In this script we can simply read the contents of the db_password file and use it to build up the command.

The Dockerfile would look something like this:

FROM redis:3.2.9-alpine
COPY /usr/local/bin/

And the script mentioned in it could be something like this:

#!/usr/bin/env sh -eux

# Read the password from the password file

# Forward to the entrypoint script from the official redis image redis-server --requirepass "${PASSWORD}"

Building the image, tagging it, pushing it, and using it in my docker-compose.yml file, I could finally make this work.

I was almost about to conclude that it would be smart not to try and fix everything in docker-compose.yml and simply define a new image that solves my uses case perfectly. However, the advantage of being able to pull in an image as it is is quite big: I don't have to rebuild my images in case a new official image is released. This means I won't have to keep up with changes that make my own modifications break in some unexpected ways. Also, by adding my own entrypoint script, I'm ruining some of the logic in the existing entrypoint script. For example, with my new script it's impossible to run the Redis CLI.

La grande finale

Then I came acr

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

SitePoint PHPHello, Laravel? Communicating with PHP through Phone Calls! (19.6.2017, 16:00 UTC)

Vector icon of smartphone with weather icon overlay

Twilio is a SaaS application which enables developers to build telephone applications using web technologies. In this two-part series, we will leverage Twilio to build a weather forecast app that is accessed using the telephone system. The backend will be written with the Laravel framework (an exploratory video course is available for purchase here, or in the form of written tutorials here).

In this part, we will create a simple program that will allow a user to call a phone number that we buy from Twilio, enter a zipcode, and receive the current weather forecast. The user can also get the weather for any day of the week via the voice menu prompts. In the second part of this series, we will leverage what was built in this article to allow the user to interact with the app via SMS (text message).


Development Environment

This article assumes Homestead Improved is installed. It is not necessary to use it, but the commands might differ slightly if you use a different environment. If you are not familiar with Homestead and want to produce similar results as this article aims to produce, please visit this SitePoint article that shows how to set up Homestead, and if you need a crash course in Vagrant, please see this post. Additionally, if this whets your appetite and you feel like exploring PHP development environments in depth, we have a book about that available for purchase.


We will create a new Laravel project and then add the Twilio PHP SDK and Guzzle HTTP client library to the project:

cd ~/Code
composer create-project --prefer-dist laravel/laravel Laravel 5.4.*
cd Laravel
composer require "twilio/sdk:^5.7"
composer require "guzzlehttp/guzzle:~6.0"


Let's go through all the steps, one by one.


Open up the routes/web.php file and add the following ones:

Route::group(['prefix' => 'voice', 'middleware' => 'twilio'], function () {
    Route::post('enterZipcode', 'VoiceController@showEnterZipcode')->name('enter-zip');

    Route::post('zipcodeWeather', 'VoiceController@showZipcodeWeather')->name('zip-weather');

    Route::post('dayWeather', 'VoiceController@showDayWeather')->name('day-weather');

    Route::post('credits', 'VoiceController@showCredits')->name('credits');

In this app, all requests will be under the /voice path. When Twilio first connects to the app, it will go to /voice/enterZipcode via HTTP POST. Depending on what happens in the telephone call, Twilio will make requests to other endpoints. This includes /voice/zipcodeWeather for providing today's forecast, /voice/dayWeather, for providing a particular day's forecast, and /voice/credits for providing information on where the data came from.

Service Layer

We are going to add a service class. This class will hold a lot of the business logic that will be shared between the voice telephone app and the SMS app.

Create a new sub-folder called Services inside the app folder. Then, create a file called WeatherService.php and put the following content into it:


namespace App\Services;

use Illuminate\Support\Facades\Cache;
use Twilio\Twiml;

class WeatherService

This is a large file in the project, so we will build it piece by piece. Put the following pieces of code in this section inside our new service class:

    public $daysOfWeek = [

We will use this array to map a day of the week to a number; Sunday = 1, Monday = 2, etc.

    public function getWeather($zip, $dayName)

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

SitePoint PHPBeing a Full Stack Developer (16.6.2017, 15:00 UTC)

Jack of all trades

A full stack developer who can get from a prototype to full MVP (minimum viable product) is often considered a jack of all trades, master of none, and with good reason. To define the modern full stack developer, we first need to focus on what the full stack developer used to be.

Full Stack Developers Then

Long ago, circa 2000 (in Internet-time, 17 years is a very long time ago), a full stack developer was someone who could:

  • whip up a web page in some Adobe tools like Photoshop or Fireworks
  • turn this design into HTML, CSS, and hotspots on images (aw, remember those?)
  • write some basic PHP 4.0 scripts (no object oriented PHP was on the horizon back then) to handle the server-side of the logic
  • store all dynamic data into MySQL, maybe do a bit of optimizing
  • upload it all to a server via FTP and collect the paycheck

Note that we're talking about PHP here - a full stack Flash or Coldfusion developer had a different (but only slightly different) workflow.

Those were simple times, life was good. One-man agencies were a dime a dozen, and people still had time to spend with their family after work.

What about now?

What Does a Full Stack Developer Need to Know Now?

These days, we have horrors like these happening - how did it come to this?

App developer doesn't see his kids due to schedule

To succeed in a now-saturated market, we developers - who are often perfectionists - hesitate to delegate and often live by the "if you want something done right" motto. This forces us into a corner where we have to learn everything, so that being a full stack developer often ends up encompassing the following.

Server Admin / Devops

A developer must know how to do basic server management. This includes but is not limited to:

  • connecting to remote servers through the terminal, in non-GUI environments
  • basic shell scripting
  • managing users and groups on a server
  • managing server programs like Apache and Nginx for serving apps
  • managing firewalls and permissions
  • installing new software and updating the distribution


Apart from these basics, a developer should know how to create good, healthy, isolated development environments, in either Docker or virtual machines like with Vagrant. If all of the above is something you're unfamiliar with, we have an excellent book about it for sale here.

The developer should also be intimately familiar with version control systems in order to be able to reliably produce backups and shareable, collaborative collections of code, tracked for changes across time. No modern developer workflow is complete without version control these days. We have a fantastic video course about this for purchase here.


Apart from actual managed or virtualized servers, a developer might need to know about the cloud - hosting on platforms like Heroku, Google Cloud, Azure, AWS, and others.


There's a fair bit to be said about platforms and tools that are more hype than immediately useful, but being familiar with the services everyone is talking about can come in handy in the long run - a client could demand a switch of providers any day now, and it pays to be ready. Luckily, we have the

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

Voices of the ElePHPantInterview with Oscar Merida (14.6.2017, 17:45 UTC) Link
SitePoint PHPHow to Build a Cryptocurrency Auto-Trader Bot with PHP? (14.6.2017, 16:00 UTC)

This tutorial will walk you through the full process of building a bitcoin bot with PHP - from setup, on to your first execution of an automated trade, and beyond.


I should not need to tell you but, a couple of months ago you could buy the cryptocurrency Ether for $11, it rapidly went up to $43 (I bought in between those prices) and has now gone to over $335 as of June 2017. Those kinds of gains are nearly unbelievable to a traditional investor and yet these are across the board in this space.
Excited yet? So here is a scenario:

You made a ton of money on cryptocurrencies and have some concerns about shuffling it through your bank because of potential capital gains tax issues. There are places that have a solution for you if you want to be able to use this money for other investments. These places won’t make you photograph your license and send it in, just use an email and they provide you with a BTC deposit wallet, demo accounts, APIs, then when you are ready, you send money in and it’s ‘go time’, you can trade everything from treasury bonds to Forex using Cryptocurrencies as your base monetary instrument.

But, you say, I am a coder who likes to automate things, surely we can fire up some BTCbot and we can have it just do the work for us, it will make us millions in our sleep, right?

Probably not.

My solution

I don’t want to write a bot and publish it with a single strategy and just say “here, use this”, I don’t think that is helpful to anyone, I would rather give you the tools and show you how to write strategies yourself, show you how to set up data collection for the strategies and how to implement them in a trading system and see the results.

Also, I don’t want to create this in a new or arcane language, I want this written in PHP which the biggest number of people are familiar with and in a framework (Laravel - here's a great premium course for sale, and a bunch of free articles if you're not familiar with it) that is simple to use but powerful enough to let you can create what you need. If you think PHP is just for web pages, read on, this should surprise you.

I like to build systems. I have been working on this post for a while and it represents a good deal of non-derivative custom work. If you have read some of my other tutorials you know that I like to write tutorials that “I wish that I had found instead of having to to write”, so you are in for a thorough read, with a lot of copy-paste style recipes.

Let’s get started.

Steps we are going to take:

  • Get boilerplate/framework installed.
  • Walk through the core parts of the system, see what is where.
  • Install and configure the software we need.
  • Account creation at the brokerages we will be using, setting up the API keys for the scripts.
  • Run tests and examples.
  • Set up websocket streams to get data.
  • Finding strategies for our automated agents.
  • Deep dive into Indicators and Candles available to us.
  • Coding up our first agent.
  • Testing the agent.
  • A few closing words about the risks you are taking.

Get boilerplate/framework installed (Bowhead)

You can find the repository for the Bowhead boilerplate at it’s Github repository. It's a full application already, but we'll be using its functionality to get the stuff in this post done.

It is recommended you use the extremely Laravel-friendly Homestead Improved Vagrant box for a good, isolated development environment you can get started with in under 5 minutes. If you're unfamiliar with Vagrant, here's an excellent re-introduction, and if you'd like to dig deeper, this premium book will teach you amazing things.

git clone
cd bowhead
composer install
cp .env-example .env
sudo pecl install trader
echo "" | sudo tee /etc/php/7.1/mods-available/trader.ini
sudo phpenmod trader

Now let's explain the the current folder structure of the app.


This is where all our console commands are located.

  • BitfinexWebsocketCommand.php - Stream market data from Bitfinex
  • CoinbaseWebsocketCommand.php - Stream market data from GDAX
  • Ex

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

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