blog banner alt

Adventure at PHP South Coast 2017 – Day One

Last updated Jun 17, 2017

Over the weekend of June 9th and June 10th, I went to Portsmouth to attend my first PHP community conference, and it is definitely the best conference I have ever been too!

And I know, this blog is about one week too late…but that’s okay!

If you are reading this blog post, and you are a PHP developer who has never been to a community conference before, I would really encourage you to give it a try and attend one of these. You will be meeting many friendly people, who are very knowledgeable. I have really learned a lot from many people at the conference. The PHP community is really something very special!

This blog post is mostly summary of the speeches from the conference, with little surprises I have found.


So if you weren’t there and are curious, read on!


Day one!

The first day of the conference are separated into two groups, one is in the Spectrum IT room, and the other one is in Jetbrain Room.

PHP south coast 2017 day one schedule
Figure 1: phpsc day one schedule

As you can see from the above, I have attended the ticked the ones I went to (actually, it’s not completely true..)

Here is the list of talks I went to (click to jump to section!):

Some link might not work, Still waiting for the speakers to give me the link to the slides! :)


Test Driven Laravel

By Amo Chohan ( @amo_chohan ); Slides Link

This is actually quite an entertaining speech, as the speaker Amo had done a live coding session of Laravel TDD!

TDD is becoming essential in our development process, especially when we want to refactor existing code to make our program more efficient but with the same result / output. With a test in place, we don’t have to remember all the steps to manual test if our code still works. As Amo said, TDD is a design activity.


The idea behind TDD is:

  • Write test code before writing any application code. (Although this is not entirely true, as this is more of a going back and forth and a continuous process, more like test code -> application code -> test code again and so forth)
  • Use the test code to drive our application code
  • Clarify the idea behind our application code
  • Grants feedback to our design ideas

Three Types of Tests involved:

  • Acceptance tests (business features)
    • Think of this as an overview, which is just simple code on how we can visualize the entire user journey, and this usually does not call any code from API, but with a mockup.
  • Integration tests
    • This is when you connect the test with your API, or your database. Making sure it still works as expected.
  • Unit test
    • Testing single components in a class in complete isolation.


All three types all follow the same anatomy – AAA:

  • Arrange - Given
  • Act – When
  • Asset – Then


Process of TDD::

process of TDD
Figure 2: process of TDD



Don’t Work for PHPCS, Make PHPCS work for you

Juliette Reinders Folmer ( @jrf_nl ); Slides Link

Juliette made this presentation very interesting, describing our application or code base as a garden, which makes a lot of sense to me. This talk really opened my eyes about PHP CodeSniffer! Before, I only knew that PHPSC can restyle your code to a specific standard, such as PSR.

There is a lot more to what PHPCS can do aside from code style, such as code compatibility, documentation, best practices, code smells, code metrics.

Also, it doesn’t just check the PHP code, but also JavaScript and CSS code!


PHPSC build-in standards include:  

PEAR, PSR1, PSR2, Zend, MySource, PHPCS, Squiz


Something that really blew my mind though, is the fact you can make custom standards!

This is what you can do for making a custom standard:

  • Combining different standards together
  • Excluding parts of existing standard and combining with other standards;
  • Take part of the existing standard and combining them

If you are confused about what I meant, here is it:

custom phpsc rules
Figure 2: custom phpsc rules

PHPCS can also be automated with Travis CI, one of the very important tip that Juliette mentioned about preference for “before_install” Instead of “before_script” for Travis script, as before_script would show the application as failed if anything goes wrong, while before_installed shows as errored.

And yes Juliette, I was thinking of fixing my Travis script at that time. :P