I attended the PHPNW conference for the fifth year running this year, back in the Manchester Conference Centre. The conference really seems to have stepped up a gear this year, delivering great quality talks throughout, and tackling content that is not always down the beaten PHP track.
From the opening keynote, Lorna Mitchell (presenting with Ivo Jansch across two rooms connected by video link that worked surprisingly well) highlighted that as software engineers we’re not defined by the language we write and should always endeavour to learn, even at a cursory level, other programming languages. Different languages tackle the same problems in different ways, and it’s good to understand the ways in which those problems can be tackled, even if that’s looking at how we can bring the approach into PHP. PHP is an evolving language and techniques not possible some years ago can now be achieved with the introduction of features such as anonymous functions and traits. Many of the tools we use are written in other languages. For example vagrant and knife are written in Ruby. Knowing a bit of Ruby helps us understand the cookbook recipes, etc.
Jeremy Quinton, presenting the “The future of the PHP development environment”, looked at how PHP development has evolved from being the simple LAMP stack (if it ever really was) to being a full server environment with PHP possibly running with a Varnish front-end proxy in front of an Apache HTTP server, or possibly on an nginx server with memcached as a fast caching engine, backing onto a NoSQL database, or any number of other permutations. Essentially, the environment(s) that we are building on have evolved beyond simply being Linux, Apache, MySQL and PHP. Jeremy showed we can use vagrant to build a virtualised development environment to match (or at least be somewhat similar to) the production environment we are developing for. I feel the real point here is we can no longer take it for granted that the applications we are building will or should run on a specific architecture, and we should consider what other software is out there that may be more suitable for the application we’re building.
It’s not just the server architecture that has changed. As PHP has evolved, implementing design patterns common in other languages has become easier in PHP as the language supports true(r) object-oriented syntax and features. Perhaps inevitably, due to the way the web service method has been conceptualised, MVC has become the standard pattern for building web applications. However, as Marcus Deglos expressed in the “Drupal has come back to the fold. It’s time to pay attention” talk, MVC is not the only pattern out there for delivering application data to the user. Over the earlier versions of Drupal, the community has existed in it’s own little bubble, doing things their own way and not considering where the rest of the PHP community is at with development techniques and design patterns. The point of Marcus’ talk was to highlight how Drupal 8 is taking on implementing things in a way that is more familiar to the larger PHP community. However, he also explained how earlier Drupal versions implemented a display pattern that is closer to Presentation Abstraction Control (PAC). As developers we should be aware of more patterns, and not get stuck in the mentality that one approach is the only right way to do it.
We should also consider the paradigm of the web service as a whole. As a result of how application development has evolved over the years, it is easy for us to think of submitting a request from a browser, the web server loads the application, loads all the dependencies, instantiates all the classes, loads all the data, builds up a webpage and delivers it back to the browser. This loading process takes a long time, in CPU terms, and may not be the only approach we can take. Akihoto Koriyama and Richard McIntyre presented the BEAR.Sunday framework. This builds upon the triangle of DI, AOP and REST for building the application, which is serialised and stored in APC to be returned and unserialised in subsequent requests, thus leading to much shorter load times. The framework requires further investigation as to how it can be used to build better and faster applications, and more careful consideration on making them truly stateless, but it does show us how it is possible to think about the web service process and how we might approach it a little differently.
In Dan Rathbone’s talk “Making PHP go fast” he showed us what they have done to address issues with their website performance. It is easy for us as developers to become dependent on the frameworks we use, and whilst they do make it easier and faster to build up a web application that flexibility does come at a cost. Generic and more flexible libraries are inevitably slower. In websites that may serve many hundreds, even thousands, of requests per second that performance hit can become a real issue. Sometimes it is necessary to strip back everything to the bare minimum and implement only what you need.
Between these different elements this adds up to an overall theme that as software developers we need take a step back and think about the tools and techniques that we use and the way that we use them. Over the last decade or more the PHP community has developed a mentality of using a LAMP stack, and that any website we develop must use the MVC architecture pattern. When we start a new project our first step is to initialise the base application skeleton of our favourite framework and then start building up the rest of the application. We need to start considering whether this is the right approach, whether LAMP is the environment we will run on, and think about other ways we might address the problems we have.
Of course, there are many other views we can take away from these talks and from the conference as a whole, and others will take away their own. If you’d like to share your feedback, leave a comment below.