Ilia AlshanetskyKitchener - FrontEdge - Browser Performance Slides (31.7.2015, 03:25 UTC)
My slides from the FrontEdge user group talk on Browser Performance are available here. Thanks to everyone who attended and I especially enjoyed the many engaging questions ;-)
Davey ShafikAn Exceptional Change in PHP 7.0 (31.7.2015, 01:53 UTC)

With PHP 7 errors and exceptions are undergoing major changes. For the first time, the PHP engine will start to emit exceptions instead of standard PHP errors for (previously) fatal, and catchable fatal errors. This means that we can now handle them much more gracefully with try... catch.

But with this change, comes a whole new exception hierarchy:

View this code snippet on GitHub.

At the top we now have an interface, \Throwable, which the original \Exception implements. Earlier versions did not have the interface and the root of the hierarchy was \Exception. We then have the new \Error exception, which is a sibling of \Exception as opposed to extending it, which also implements the new interface.

The reason \Error does not extend \Exception is so that the new exceptions will not get accidentally caught by legacy catch-all statements (catch (\Exception $e) { }) — and just like in older PHP versions, an uncaught exception is still a regular fatal error, preserving backwards compatibility.

If the ability to create a real catch-all is desired, you can catch the \Throwable interface. This means that to catch both regular exceptions, and engine exceptions, you would use catch (\Throwable $e) { } instead.

Error Exceptions

As you can see above, there are four new error exceptions, each one used for a different purpose:


Standard PHP fatal, and catchable-fatal are now thrown as \Error exceptions. These will continue to cause a “traditional” fatal error if they are uncaught.


With PHP 7, we also have enhancements to assertions, using the assert() function, with the addition of zero-cost assertions, and the ability to have them throw exceptions. To enable this, you should simply set assert.exception to 1 in your php.ini (or via ini_set()).

These exceptions are (you guessed it) \AssertionError exceptions.


Thanks to error exceptions, you can now handle includes with parse errors, and eval() parse errors, as both now throw \ParseError exceptions:

View this code snippet on GitHub.


With the introduction of scalar, and (especially) strict types in PHP 7, these will also throw exceptions when a type mis-match occurs. It is important to understand that this does not apply only to scalar type hints, but to traditional type hints such as class/interface names, callable and array.

Catchable Fatal Errors

Another important change in PHP 7 is with catchable fatal errors. Previously, these would have been caught and handled using set_error_handler(). However, with PHP 7, they are now \Error exceptions, which, because an uncaught exception is now a real fatal error, will no-longer be catchable in set_error_handler().

This is a backwards compatibility break and means that to work in both PHP 5.x and 7, you need to use both set_error_handler() and try... catch.

This is considered a minor BC break due to limited usage.

\Throwable and Userland

It would not be a big jump to conclude that now we have a common interface, we could create our own branches in the exception hierarchy for completely custom exceptions by simply implementing the \Throwable interface. Unfortunately, due to the fact that exceptions are magical under the hood, to be able to do things like capture line/file and stack trace information — this means that you still must still extend either \Exception or \Error, and cannot directly implement \Throwable alone.

Trying to implement \Throwable results in the following:

View this code snippet on GitHub.

However, this is not the full story. You can extend \Throwable and then — while still extending \Error or \Exception — you can implement your extended interface:

View this code snippet on GitHub.


As alluded to in the (pun intended) title of this post, these changes are actually quite big, allowing us to gracefully handle almost all previously fatal errors. The fact that the core team were able to maintain almost complete backwards compatibility while doing so is astounding. Kudos to them!

PHP ClassesReview: MongoDB and PHP (30.7.2015, 02:14 UTC)
MongoDB and PHP
Jose Gomez
PHP books
Steve Francia
MongoDB and PHP is a great book that obviously describes how to use MongoDB with PHP. The target readers of this book are PHP programmers. It introduces MongoDB as document based database, how to install MongoDB drivers, perform simple queries and aggregation like MapReduce. This book also enumerates mappers, tools and frameworks.

So it is well recommended to all those that want or need to learn about how to use MongoDB with PHP.
SitePoint PHPUsing Selenium with PHPUnit (29.7.2015, 16:00 UTC)

Testing is a really wide subject, whether it be unit testing, functional testing, acceptance testing, etc. In this article, we’re going to see how you can do acceptance testing using Selenium. I will use a practical example to illustrate a real use case. I will assume that you already know how to do unit testing using PHPUnit, or that you at least have a grasp of what it’s all about. Let’s get started.

Image of some checkboxes being checked

What Is Acceptance Testing?

Acceptance testing is the process of telling user stories through tests, and I love this quote to describe it:

A formal test conducted to determine whether or not a system satisfies its acceptance criteria and to enable the customer to determine whether or not to accept the system.

What Is Selenium?

Selenium is a tool to automate user interface testing. It helps with testing your application against the browser. The process could be described like so:

  • Go to the page
  • Assert the page contains a list of 20 videos.
  • Click number two on the pagination.
  • Assert the page contains a list of 20 videos.
  • Quit the browser.

You may be wondering: “How does it manipulate the web page using the described tests?”

The answer is “it depends”. If you’re using Selenium RC (previously named Selenium 1), it will inject auto generated JavaScript code to the page to perform the desired actions. Selenium RC is deprecated and is only supported in maintenance mode; you should be using Selenium WebDriver.

When using Selenium WebDriver (Selenium 2), the tests are translated into commands and passed to the Selenium server (more about that in a moment), then passed to the browser using the web browser native API.

Continue reading %Using Selenium with PHPUnit%

Matthias NobackBehind the scenes at Coolblue (29.7.2015, 08:57 UTC)

Leaving Qandidate, off to Coolblue

After I had a very interesting conversation with the developers behind the Broadway framework for CQRS and event sourcing the day wasn't over for me yet. I walked about one kilometer to the north to meet Paul de Raaij, who is a senior developer at Coolblue, a company which sells and delivers all kinds of - mostly - electrical consumer devices. Their headquarters are very close to the new and shiny Rotterdam Central station. The company itself is doing quite well. With 1000+ employees they keep needing more office space.

Paul showed me around all departments and offices, which nowadays span three floors. There's developer teams everywhere. It's not a PHP-only company. Though PHP is well represented, there are also .NET and Delphi developers. Coolblue runs on quite a lot of software and hardware.


Developers at Coolblue have learnt to call the legacy software they maintain "heritage". "Legacy software" often has a negative sound to it, while in fact, it's what enables the company itself to be so successful, so it doesn't really deserve that negative image. I don't fully agree with this approach since most of the relevant literature about this subject speaks of "legacy software", which, to me personally, doesn't mean anything bad. I'm well aware that anything I write today will be "legacy" tomorrow, because, literally, other people inherit that piece of code and need to maintain it. In my dictionary, "legacy software" isn't a bad thing (though I know that it often is, so I understand this little play of words).

New things: microservices

Paul mentioned that there is an ongoing struggle amongst developers who rather want to try "new" things, while they feel stuck in the "old" way of doing things. Paul argues that it's always possible to try something "new" in an older project as well. The infrastructure may not be there for it yet, but introducing it might therefore be even more challenging, as well as more satisfying. I fully agree with Paul on this, and I also like to work on an older code-base and introduce new concepts to it. Anyway, in my personal experience, thinking that you're better off working on a green-field application, because you can do everything "the right way", often turns out to be quite a fallacy. I'm sure you'll recognize this sentiment as well.

At Coolblue, "new things" currently means event sourcing and microservices. They have introduced several microservices so far. Microservices are one of these things Coolblue developers have been wanting to introduce for quite some time. It turned out to be not that hard, but, according to Paul, the key was to keep it small at first. They started by extracting several smaller and less crucial parts from the main application into microservices. You can read about some of their experiences on

New things: event sourcing

Paul and others have done quite some research with regard to event sourcing as well. They haven't taken the step yet to implement it in their software. Take a look at this slide deck to get an impression of what it might look like for them when they do.

Paul made an interesting observation with regard to "new things": there is often a mismatch between what a developer thinks of themselves, and what that same developer thinks of other developers. When listening to meetup or conference talks, you may start thinking that you're way behind on current developments in the world of (PHP) software development. Paul at first felt the same, but noticed that when you actually talk to developers about what you're doing, it might just as well turn out that you're doing fine.


Developer teams at Coolblue are separated based on the features they work on. There is a team working on "pre-cart", i.e. everything related to the presentation of the products, their categories, etc. Then there's a "post-cart" team, which works on actually making the sale, payment, etc. Paul himself is moving from team to team mostly, helping everyone solve any issues that they may be facing. This way, he gets a nice overview which enables him to take knowledge from each team to other teams. This also helps preventing the same mistakes from being made in different teams.

Walking through the corridors, we pass a lot of "team rooms". Walls are made of glass, but each team is still nicely separated from the others. They can see, but not hear each other, meaning that they can focus on what they're working on, while still feeling part of the organization. It appears that each team consists of about

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

PHP ClassesWhat You Should Do Before Pushing PHP Code to your Production GIT Repository (29.7.2015, 04:31 UTC)
By Suresh Kumar
Every time you commit new code to a Git repository, there is a great chance that the code has problems that were not detected with your usual batch of tests.

Read this article to learn how to integrate PHP Code Sniffer with your project Git commit process to inspect your PHP code automatically and prevent that code with problems is committed.
Cees-Jan KiewietComposer cache on Travis (28.7.2015, 22:00 UTC)

Ever since the Test lowest, current, and highest possible on Travis post I wanted to dive into caching composers cache and vendor on Travis. My experiments started the day after that post.

Docker Composer Packagist Travis Hybrid

Matthew Weier O'PhinneyOn PSR7 and HTTP Headers (28.7.2015, 14:00 UTC)

Yesterday, a question tagged #psr7 on Twitter caught my eye:

#psr7 Request::getHeader($name) return array of single string instead of strings in #Slim3? cc: @codeguy

@feryardiant (tweet)

The image linked provides the following details:

When I call $request->getHeader('Accept') for example, I was expected that I'll get something like this:

    [0] => text/html,
    [1] => application/xhtml+xml,
    [2] => application/xml,

but, in reallity I got this:

    [0] => text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8

Is it correct?

In this post, I'll explain why the behavior observed is correct, as well as shed a light on a few details of header handling in PSR-7.

Headers in PSR-7

When creating the PSR-7 specification, we had to juggle a fair number of details from the various HTTP specifications. Headers are one area that is particularly difficult, due to the flexibility and ambiguity in the specification.

The root of the ambiguity is that headers are allowed to have multiple values. Headers may have multiple values, but it's up to the specification for any given header.

Additionally how multiple values are represented is up to the given header. The HTTP specifications allow using multiple invocations for the same header:

X-Foo-Bar: baz
X-Foo-Bar: bat

The above would mean that the X-Foo-Bar header has two values, baz and bat. Assuming the header allows multiple values at all; if it doesn't, then it has a single value, and the last representation wins (bat, if you're paying attention).

The other way to represent multiple values is using a separator. The specifications indicate that if you want to have multiple values in the same header line, you should use a comma (,) as a separator. However, you may use any other separator you want. The SetCookie header is a prime example of a header allowing multiple values that uses a completely different separator (semicolon)!

So, to summarize:

  • A header may or may not allow multiple values.
  • Headers may be emitted more than once. If a header allows multiple values, then its value is the aggregate of each representation. If the header only allows one value, the last representation is the canonical value for that header.
  • Headers may use a separator character in a single line in order to separate multiple values. That character is suggested to be a comma, but it can vary per-header.

The other big ambiguity in the specification is that the specification is extensible, and specifically allows for custom headers.

This means that any general-purpose code representing HTTP, such as PSR-7, cannot possibly know the entire ruleset governing all possible HTTP messages, as it cannot know all potential header types, including whether they allow multiple values or not.

With these two facts in mind — headers may have multiple values, and custom headers are allowed — we made the following decisions with PSR-7:

All headers are collections

All headers are assumed to have multiple values. This gives consistency of usage, and puts the onus of knowing the semantics of any given header to the consumer.

For that reason, the most basic access for a given header, getHeader($name), returns an array. That array can have the following values:

  • It can be empty; this means the header was not, or will not be, present in the representation.
  • A single string value.
  • More than one string value.

Naive Concatenation

Since the majority of headers only allow single values, and since most existing libraries that parse headers only accept strings, we provided another method, getHeaderLine($name). This method guarantees return of a string:

  • If the header has no values, the string will be empty.
  • Otherwise, it concatenates the values using a comma.

We chose not to provide an argument indicating the separator to use, as the specifica

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

Rob AllenChecking your code for PSR-2 (28.7.2015, 06:45 UTC)

Most of the projects that I work on follow the PSR-2 coding style guidelines. I prefer to ensure that my PRs pass before Travis or Jenkins tells me, so let's look at how to run PSR-2 checks locally.


My preferred tool for checking coding styles in PHP is PHP_CodeSniffer. This is command line tool, phpcs, that you can run against any file.

PHP_CodeSniffer can test against a number of standards. The default is PEAR, so you must use the command line switch --standard=PSR2 in order for it to check against the right one.

Let's take an example from's web2 project:

$ phpcs --standard=PSR2 BaseApi.php 

 11 | ERROR | [x] Expected 1 space after closing parenthesis; found 9

Time: 70ms; Memory: 6Mb

This is the code that's wrong:

if (isset($config['apiUrl']))
    $this->baseApiUrl = $config['apiUrl'];

The opening brace is in the wrong place.

If there is a note that PHPCBF can fix some validations automatically, then you can run the phpcbf command line tool to automatically fix your code:

$ phpcbf --standard=PSR2 BaseApi.php 
Changing into directory .../joindin-vm/joindin-web2/app/src/Application
Processing BaseApi.php [PHP => 1452 tokens in 186 lines]... DONE in 52ms (1 fixable violations)
        => Fixing file: 0/1 violations remaining [made 3 passes]... DONE in 163ms
Patched 1 file
Time: 246ms; Memory: 8Mb

And phpcbf has changed the code to be compliant:

if (isset($config['apiUrl'])) {
    $this->baseApiUrl = $config['apiUrl'];

Obviously, not all violations can be automatically fixed, but a good number can be.

Automating with Phing

Generally you want to be able to run phpcs across all your source files without too much effort and also get your CI tool to do the same. My preferred choice here is to use Phing.

Each command within a Phing build.xml file is called a target. The PHP_CodeSniffer target for the web2 project is:

<target name="phpcs">
 <phpcodesniffer standard="PSR2"
      description="Run PSR2 standards over the codebase"
   <fileset dir="${basedir}/app">
     <include name="**/*.php"/>
   <fileset dir="${basedir}/tests">
     <include name="**/*.php"/>
   <formatter type="full" usefile="false"/>

With this target we run phpcs over all PHP files in the `app` and `tests` directories. We run it like this:

$ phing phpcs

As Phing is simply a build tool, the error output is the same format as earlier.

Editor integration

I use Vim and Sublime Text 3, which both have plugins for checking syntax.

Syntastic for Vim

Syntastic is a great plugin for Vim that checks syntax for any language that you can think of. Install it using your preferred method and then for PHP linting and PSR-2 checking set up in your .vimrc like this:

" Syntastic
let g:syntastic_php_checkers=['php', 'phpcs']
let g:syntastic_php_phpcs_args='--standard=PSR2 -n'

You can also add Syntastic summary information to the status line using %{SyntasticStatuslineFlag()}.

The display looks like this (Yes, I like white backgrounds for editing, sorry!):

Syntastic PSR2 checking

When you save the file, Syntactic runs the checkers that you've set up, php -l and phpcs --standard=PSR2 -n in this case and displays any errors with a red S> in the gutter and if you've enabled it, a summary in the status line. When your cursor is on that line, then the error is displayed at the very bottom.

SublimeLinter for Sublime Text 3

The SublimeLinter project does for Sublime Text 3. You need to install "SublimeLinter",

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

Cal EvansPHP South Coast Wrap-up (28.7.2015, 05:00 UTC) Link
LinksRSS 0.92   RDF 1.
Atom Feed   100% Popoon
PHP5 powered   PEAR
ButtonsPlanet PHP   Planet PHP
Planet PHP