The PHP UK Conference was a demonstration of pragmatism, honesty and progression; something that I feel we’re fortunately starting to see at many conferences now. A number of the talks I attended reflected this. The conference talks demonstrated an acceptance and understanding that not all applications can be built on the bleeding edge of front and back-end technologies. Yet there were also talks on ReachJS, API tools like Apigility and a keynote on “The Future of Programming” (including a demo of a tool that reminded me of noflo). There was also an honest and open acknowledgement that the conference didn’t have as diverse a range of delegates as everybody would hope. In response – and to try and improve things further – PHP London have launched a diversity programme.
To illustrate these three points I’m going to mainly reference my three favourite talks from the event: Lorna Mitchell on New Wave PHP, Ricard Clau talking about Modern Software Architectures and Chris Hoult of DataSift on Your API is UI.
But First: PHP is Everywhere
Most people in technology are aware of the criticism that PHP is receiving. But what we really need to remember is that much of the Internet is built upon PHP. Schools, colleges and universities continue to teach PHP because many businesses exist and thrive upon it and need developers to maintain and improve those applications.
You could argue that for website development PHP is the easiest language to get started with. Not just because of the language’s forgiving nature, simple syntax and structure, but also because the runtime is everywhere and the tooling is simple to use e.g. selecting files to upload in an FTP program’s UI is easier for a somebody who is getting started than installing a hosting provider toolbelt, jumping to the commandline and executing a build and deploy command.
Since PHP is prolific, has been around for a long time, the language has suffered periods of stagnation, there are many “legacy” websites and applications, and there’s an acceptance about what PHP is good for and what it’s not, it means developers who use PHP are pretty pragmatic.
In Lorna Mitchell‘s talk she covered new features in PHP 5.4, 5.5 and 5.6 from simple changes like the removal of
register_globals, improved timezone settings, changes to call-by-reference usage and easy password hashing (clearly a common use case). Lorna also provided some practical upgrading tips and answered questions with a level of understanding of what may and may not be achievable in real-world app scenarios. Lorna didn’t cover PHP7 at all even though progress is being made on it – itself a very pragmatic decision because it can’t be used right now.
Ricard Clau warned against blindly following trends, over-engineering solutions and avoiding NIH syndrome. He covered the practicalities of scaling infrastructure at a high-level and clearly defined distributed systems, CAP theorem (in regard to databases), SOA and Microservices, and some basics on data analysis and real-time streaming.
The PHP pros and cons section of Ricard’s talk covered how PHP is great for horizontal scaling of traditional web applications and how existing companies demonstrate this. Of particular interest to me was that WebSockets – and real-time processing in general – were highlighted as not being suited to PHP applications. This has long been my opinion and it also demonstrates why Pusher is such a great fit for developers who want to integrate realtime functionality into their PHP apps.
In Ricard’s closing slides he stated “Architectures… and life… are full of tradeoffs” and emphasised the importance of reading the docs and choosing the right tool for the job. It reminded me of my recent 10 Minute Guide to Choosing a Real-Time Framework from ForwardJS.
Over the coming months I’m going to dig further into real-time APIs. This includes giving a talk at APIStrat Berlin on the decisions you have to make when building real-time APIs and a talk at WaitConf in Manchester on identifying and exposing real-time data in your apps. So, Chris Hoult‘s talk about how Your API is a UI was of particular interest to me. He covered clearly important areas of considering including identify your users, clarifying what your API use case is and the importance of keeping the API focused and simple. He also spent time going through the API Hierarchy of Needs.
Chris had a slide with the title “Pragmatism” accepting that “Best Practice” can’t always be followed or indeed achieved, but should be strived for. I particularly like the fact he highlighted “RESTlike” since our REST API isn’t strictly RESTful, yet the term “REST” clearly identifies that we offer a server-side Web API, so we stick with it.
PHP is moving forward. After years of infrequent releases things are improving. PHP7 is on the horizon and the language offers many constructs that help you build out a clean codebase – although there’s still a vast emphasis on developers doing the right thing.
The more progressive talks at the conference covered things such as ReactJS (which was so busy I couldn’t even get in the door), Silex MVVM with AngularJS, HHVM at Etsy, there were plenty of talks on API development and, as already mentioned, Nate Abele gave a talk on the Future of Programming.
One of the positives that Ricard highlighted was that PHP has libraries for everything. This means that almost all databases are an option for your PHP apps.
This is of course a blessing and a curse. But Ricard went on to help by providing details on which DB to choose based on your distributed DB system needs: Availability v Consistency v Partition Tolerance.
He provided some solid advices on building and testing microservices. Then went on to cover the need for data analysis, about modern stream processing and real-time Firehoses of events and technologies such as Kafka, Amazon Kinesis, RabbitMQ or NSQ. He suggested that in some situations 60 seconds from the event being generated and triggered to being delivered was enough. But stressed that when building social features or games that 60 seconds was nowhere near enough.
Our < 250ms delivery is certainly good enough for the majority of use cases – phew!
Finally, he encouraging developers to look beyond PHP where required. For example, he suggested languages like Erlang, Go and Scala were good options for building real-time systems and encouraged PHP developers to consider those if they need to self-build. I obviously asked the question about offloading some of the functionality that isn’t suited to PHP to hosted services – such as using Pusher as your real-time infrastructure.
The title Chris’ talk, “You API is a UI”, represents progressive thinking and since he works at DataSift the ideas clearly work and should be considered progressive too. In particular, I thought his ideas around recording real user API calls and then replaying them as part of your functional testing was a fantastic idea. It reminded me of how I’ve done that in the past as part of the development process when building real-time APIs where it can be a pain to replay events.
The benefits of real-time analysis were also covered. Chris showed us an image of the dashboard they have at DataSift and explained how important they are in understanding exactly what’s going on with your API right now,
At the end I asked a couple of questions – I couldn’t help myself. In particular, I asked Chris his thoughts on the benefits of using the same APIs that you are offering customers as part of your own product development. If I’m honest, I thought this was a no-brainer and that he would say it was a great idea. However, he highlighted that there are pros and cons of “dog-fooding”. Although the idea is generally a good one there may be a conflict between functionality that you wish to use internally and that which you wish to offer your customers. You need to be cautious of exposing things you wouldn’t want to expose to customers.
I much prefer talks where people share honestly and openly about things they’ve done and things they believe in. I’m sure we all do. That stood out in all the talks I attended. A funny example of this openness is when Lorna shared how the decision was made to delete the PHP6 branch after a night in the pub – there will be no PHP6 and the next major version of PHP will be 7. I’m still not sure if this was a joke or not!
The type of honesty I’m really referring to was more obviously reflected in the opening address on the 2nd day by Johanna Cherry and Sam Bell. They shared a stat about the break down of gender attendance, emphasised how they were so disappointed with the figure and that they were trying to do more to increase the involvement of all marginalised groups with the PHP UK Conference Scholarship Programme.
— Phil Leggetter (@leggetter) February 20, 2015
The theme of openness continued in Jenny Wong‘s keynote on Integrating Communities. Jenny spoke about problems that she had experienced that made her almost quit programming before getting started, her obsession with meetups and shared her thoughts on how different technology communities should integrate.
PHP UK 2016
I really enjoyed attending PHPUK 2015 and I’m very hopeful that Pusher can be involved more generally in the event in 2016. Whether that’s having a booth or getting involved in the hackathon as we did in 2013.
I’ll certainly be looking out for the CFP and already have ideas floating around my head about identifying real-time data in your PHP apps, integrating real-time functionality into your Laravel apps and why you can build real-time web apps in PHP.
Between now and then we’re also on the look out to get involved in other PHP events. So, please get in touch if you’d like us to talk at an event or get involved in some other way.
For reference, here are the slides for the talks in this post: