PHPDay, the Italian PHP conference 2016, notes

veronaThis year I decided to take a couple of days off work and attend the 2016’s Italian PHP conference.

I was curious to see what the Italians audience thought of talks from international speakers, where the business is normally different. In Italy, according to my freelance experience in 2002-2008 and confirmed by the conference’s attendees, there is a majority of very small businesses requiring small/medium CMSes, often serving tourism needs (e.g. booking platforms), with a small budget, sometimes requiring to maintain old platforms and obliging developers to share their time doing multiple roles: devops, backend and frontend, sometimes design too, SEO and marketing) and/or working for lots of clients with different (sometimes legacy) platforms.

What I observed is that the backend world is more or less the same as the previous years. Basics are still the same. I even re-heard some recommendations read in the old 1994’s OOP bible book .

But there were some interesting points and tools. I would group the talks this way:

PHP 7

php 7In summary much more performances by just upgrading PHP to the version 7, a very few backwards incompatibilities, a few language improvements. Interesting to see some stats from the PHP’s creator himself: WordPress and composer seem to be hugely faster now, and use much less memory (I don’t remember the numbers for each but at least 2x). Tips about smem (a tool to better measure memory consumption excluding shared memory), settings tuning (realpath_cache_sizecommand_buffer_too_small, DocumentRoot in tmpfs), considerations about multiprocessors and NUMA.

I attended a talk from badoo – the widest dating/social network site, so quite a lot of servers – that switched to PHP 7 and implemented the needed upgrades to all the used extensions. A viable solution for a big company, whereas a small one would probably not afford that and would be obliged to wait for the stable repositories and extensions upgrades before switching. Pinba (MySQL storage engine to accumulate PHP profiling info sent over UDP, similarly to a local NewRelic setup) was used for some measuring. Runkit was used to modify constants, user-defined functions and classes in 60k tests, and – since it was not supported in PHP 7 – they ended up developing their own mock framework  and distributing it for free on GitHub (well, thanks !).

Docker

A bit too “DevOps” for a PHP conference, but since it replicates the platform architecture locally, and simplifies the deployment, I guess it’s becoming a MUST. At MOJ, fortunately, we already use it, thanks to your dedicated DevOps team. Nothing new to learn for me, apart from the pipeline jenkins plugin suggested in this talk, that I might play with when I have time, instead of simply using job triggering.

Event sourcing

That basically means storing DB changes and be able to query on those changes. I’ve already implemented something similar in the past using doctrine listeners, and IMO a great approach when the data to save is connected to entity operations. I didn’t like how the argument was covered but good to hear and become curious to learn more during the talk, ending up reading the Martin Fowler’s article about event sourcing, play with Prooph framework for it, along with doctrine and mongo adapters. The Command Query Responsibility Segregation (in short, different models for updating and displaying) pattern was also mentioned, but IMO not necessarily connected to event sourcing as I heard.

Doing something already existing, but in PHP

Interesting talk about the fann extension, for Artificial neural networks, and an application example of machine learning in this talk, where the “intelligence” was recognising PHP code from human language in code comments, by initially defining what a code normally contains (“$”, “->” and “;” symbols), then launching it on many inputs (=code comments), and using an iterative approach to improve the results.

Another talk about Raspberry PI and  PHP libs (alternative here) to pilot it. Not something developers normally do for their clients, but good to hear something refreshing and different. Raspberry PI’s OS is a Debian distribution, so a web server with PHP could be installed on it, and pilot a huge variety of sensors. Good to know. I might use it to recognise pigeons on my balcony and pilot a plastic bullet BB Gun to shoot at them !

 

Others

  • Packing and distribution: Lots of useful tips from this talk, thanks to which I found a useful skeleton for new projects, refreshed the semantin version concepts, a tool to select a licence, conventions and other stuff;
  • Middleware, ways of glueing software. I’ll create a specific post for this, ZF3 and other frameworks like slim have a support for the idea;
  • PPI framework: to load and bootstrap multiple frameworks. I normally include libs with composer, so never had the need to use this framework, but I might play with it in the future;
  • API recommendations: in this talk, some recommendations, most of which I have already heard, but good to brush up. Among the most useful ones: revoking permissions will break/alter the client’s behaviour, so better to start with restricted permissions, and open them little by little (increasing permission will not break the consumers’ code). Good suggestion about not being 100% “perfect”, better to have a “RESTlike” working API than a 100%-compliant over-engineered and difficult to understand one. Loved the definition of pragmatism as cutting corners safely and be realistic. Interesting the Maslow pyramid from usability (base) to creativity (top);
  • PHPSpec for TDD. I skipped those talks. I already heard of it more than once in the past. I already do BDD with Behat, and TDD with PHPUnit that always proved to be a great combination of tools to guarantee application stability and maintainable code thanks to safe refactors. I haven’t found PHPSpec useful so far. IDEs also help a lot with code generation, so I don’t need more TDD/OOP tools. I personally prefer to spend my time on other aspects of software development (both frontend and DevOps) and business.

What I didn’t hear

No talks about unit testing, maybe because there is no much more to say ?

No talk about functional testing, one of the most underrated thing to discuss IMHO. The sSoftware has to respond to business’ needs, be reliable and bug-free. We should never forget and stop improving on this side. I hear developers talking and focusing too much on speed and performances, without even knowing the optimise-measure iterative process. Also I hear tools and framework adoptions based on personal preferences or by just trusting what’s new and sold “better” without objectively comparing the alternatives.

Summary

  • London’s environment, developers, community (and – as a consequence – clients) are always at the top in terms of framework and tools choices, so apparently no new technologies/approaches to learn from Italy;
  • No big news in terms of new frameworks and way of developing. One the reason I don’t spend too much time learning new frontend frameworks. The JS community seems to jump from a framework to another too often, a sign that things need more time to become mature before being worth spending lots of time on them. The only JS stable adoption seems to be JQuery, that pragmatically solves most of the problems elegantly (when JS is only an enrichment layer on the top of the application and not uniquely used as a front-end renderer).
  • Code distribution on GitHub and composer.json is definitely an emerging habit among developers, always good to share and stop re-inventing the wheel. Very few people in other professions think so broadly;
  • PHP 7 is a huge improvement from the past by 2x or more, for free, without coding (unless fixing a very few backwards compatibilities). That means fewer costs to host PHP apps, happier clients, happier users, happier developers. Never heard a so big improvement for other open source technologies. Not sure JAVA or .NET or even Python or Ruby communities we’ll hear one day that the new compiler/interpreter version is 2-5 times faster. Probably because they were already optimised from the start, you might say, at which I would add: if PHP made a long way without being optimised, it must have been able to listen to devs and business needs more than all the others;
  • PHP is somehow a language proving the  “Premature optimisation is the root of all evil” and lean startup rules. It started simple as a very simple scripting language, so developers started coding solutions quickly, and businesses liked it for its low costs and quick response to the market needs. Frameworks and tools were built and with time, both languages and framework grew and improved, more people and business moved to it gradually, and further improvements were added. Now the stack of tools available for PHP developers has nothing to envy from Java and .NET. Also, I noticed businesses preferring open source to closed platforms. The former have proved to be less risky, for example by avoiding the vendor lock-in problem. If I had the opportunity to work with PHP for a gov.uk service, it’s also thanks to this winning approach.