Ipc Spring 2019 Part 1Posted 17 Jun 2019 by Gareth Pelly

Introduction

The International PHP Conference has been running for more than 10 years and consistently attracts high quality speakers to present on very interesting topics. This was my second time attending the main conference (workshops are provided on other days) in Berlin and it was once again well worth attending.

Introduction to Architectural Katas

Frank Sons - Agile Software & Code Qualität

Rather than this being a technical presentation, Frank talked about getting from the requirements stage to the technical stuff. He began by describing some of the pitfalls of jumping into the coding of a solution before having the full picture of the requirements.

He quoted Martin Fowler who said “Software Architecture is those decisions that are hard to change”. If decisions are taken based on missing information then it can be extremely difficult to change these later. If you make assumptions then things can turn out wrong.

He spoke of a typical experience as being one where engineers start coding and believe they can figure out exactly what is needed… “Weeks of coding can save you hours of planning”.

He described some sessions that he has moderated where the participants took part in such katas. He covered the basic idea of it, how groups of people were organised (3-5 per group is better), the process itself is:

Introduction > Planning > Presentation > Feedback

He outlined the “rules” and that ultimately the exercise was not designed to produce a concrete solution but rather a rough vision and to be prepared to defend questions about the approach.

One of the example problems he used was the following:

• A local radio station wants to connect DJs more closely to their audience, so audience members can request songs, vote on songs planing tight now , vote on the DJs daily play list and so on
• Users: unsure; whatever the local music community is
• Requirements: near real time synced with the music on the air, user voting mechanism, mobile device accessibility

Frank described how using a whiteboard is a must and that the first few versions will be thrown away or elements of it iterated upon. One suggestion he gave was to look at Container Diagrams for visualising Software Architecture.

I thought the talk was very interesting and could prove quite useful in helping engineers to become better at architecting solutions by providing a safe place to fail and learn. As one of the slides said “How are we supposed to get great Architects if they only get the chance to architect fewer than half a dozen times in their career”

Why you shouldn’t care about Security

Ben Dechrai - Auth0

A first for me, where I attend a session where the speaker wore a kilt! Go Ben! In all seriousness, Ben is a very good speaker and his balance of slides, straw polls and snippets of humour were very welcome.

Ben spoke about how security has developed organically, with organisations creating their own login page, managing the user passwords and so. When scaling comes into the equation, then we need an API, scopes need to be managed etc etc. All this just for authentication and identity management.

Auth0 was introduced as a way to make the whole process better. Using an identity provider would mean that the organisation would not store the credentials, instead a user would be redirected to a login form on the provider where authentication would be performed and the user redirected back to the main application.

He live demo’d a simple application showing us how the setup and customer flow occurs using the Auth0 PHP SDK.

PHP to Hack, an incrementally typed Adventure at Slack

Scott Sandler, Senior Staff Engineer

A really detailed talk by Scott on Slack’s journey from PHP to HHVM to Hack. This was one of those sessions where you need to sit back and listen rather than take any notes and that’s just what I did :)

There are some interesting pros to using Hack but there are also some cons that you should be conscious of (can you say goodbye to composer for instance?). Hopefully we’ll see some of the features of Hack moving into mainstream PHP.

I recommend you take a look at the slides from this very interesting presentation

PHPUnit Best Practices

Sebastian Bergmann, thephp.cc

Sebastian is the creator of the defacto php unit testing tool and, having attending some of his previous talks on various topics at conferences over the years, it’s always worth making sure you are in attendance. I was looking forward to finding out more about ways to ensure we are getting the most out of our unit testing.

One of the first recommendations Sebastian made was an obvious one, use a supported version of PHP. He went on to show the current supported timelines for various versions of PHP and urged people to ensure they kept up to date.

This brought us naturally to the next recommendation, to use a supported version of PHPUnit itself. PHPUnit 7 is the lowest version currently with support which ends in February 2020.

He explained one of his biggest frustrations regarding the use of PHPUnit and that was how when folks start using a new version of it that they suddenly find that “it doesn’t work”. There are a couple of reasons as to why this happens:

• Unbound version constraints in composer.json
  • Unbound examples:
    • “>=8.0”
    • “dev-master”
    • “*” aka. Death Star
  • Using "^8.0" does not lead to surprises
  • He shared with us that he, in fact, does not use composer to install a tool but instead uses a PHAR. This ensures that a tools dependency won’t conflict with the actual software’s dependencies.
  • Global installation of PHPUnit
  • Not reading the changelog when updating to a new version.
    • PHPUnit is updated in February each year
    • All the changes are known in advance
    • There really shouldn’t be any great surprises for people if they have understood any potential impact/change the new version brings.

Next he walked us through configuring PHP to ensure PHPUnit “properly yells at us”.

• php.ini
  • error_reporting=-1
    • To see all errors/warnings/notices when test are run
  • log_errors_max_len=0
    • To allow the entire error message in the error log, rather than one truncated to the default 1024 characters.
  • xdebug.show_exception_trace=0
    • Prevents Xdebug exception traces while tests are executed.
  • zend.assertions=1 and assert.exception=1
    • If you use assert() statement, this ensures they are evaluated and will raise exceptions
  • memory_limit=-1
    • Code coverage collection/generation can require more memory than PHP is allowed to use by default.
  • (BTW these can also be added to the phpunit.xml file if you would rather not adjust your PHP settings globally)

Sebastian then took us through a sensible phpunit.xml configuration. There is also the possibility to use a --generate-configuration CLI option to output a phpunit.xml file with suggested settings.

We then saw some useful examples/tips for PHPUnit and writing tests:

• Running:
  • All tests
  • By test suite (ie. unit or integration)
• --testdox CLI option
  • A really nice way to have test results displayed and shared with non-tech people.
  • (BTW, if you have properly named test functions that read like sentences then you will get much more sensible and clear output with testdox)
• Using @dataProvider
  • Using @testdox to output clearer information about the datasets in a provider
• Test code should be readable!
• Code Coverage
  • Please use the @covers annotation to focus coverage collection on the code you are actually testing in a test rather than the related code.
  • He spoke about the speed of coverage collection and how work has been done to try to reduce the time taken (PHPDBG and PCOV)

This was a really interesting session and it’s always interesting to hear directly from the creator of a tool that we use on a daily basis.

You can find the second part of the blog post covering my second day here