I personally prefer conferences around a wide subject, in order to list to more variety of talks, spreading across the whole area of the technology. This one was a 2 days conference around a single framework, so I was expecting to get a bit bored, and I was right. Lots of talks around minor functionalities on the framework that I can easily read online, or things I already know. Some talks were fortunately more general therefore more of my interest. And that’s because I want a talk to inspire me, giving me clues, tips, but not repeating what the online documentation says.

Talks

Some talks around the Symfony 3.3 new features, SensioCloud (a kind of heroku for Symfony that smells a bit commercial and coupled with Symfony at first glance), PHP 7 improvements I missed (static variables persisted in memory among requests), PHP types (things I’ve already heard many times, but good to hear them again, with updates on latest PHP updates).

One of the talk I like the most was about when to abstract, where lots of useful concepts were mentioned. Concepts that I knew already, but I always found it difficult to explain to other younger developers or the business.

Predicting patterns should be done very carefully, we can’t really know how the business logic is evolving, and a premature abstraction leads to difficulty to change the product. The risk is facing an over-engineered or over-architected product at the time you have to make changes. In this talk is suggested to develop first with duplication, abstract later. Completely agreed;

Refactor is not only and improvement, but the best way to let the business patterns and logic emerge from your code, in case you don’t fully know it. I knew that, but I never though of explaining to the business that way. I understand “refactor” sounds scary to the business, like the builders in your house say “we need a paid (by you) day to refactor the wall we are building” when you clearly saw the were half way through after 2 days.

A code rewrite, instead, means losing some of the domain rules. In the talk it was mentioned 40%, but I think it depends, it was much less in my experience, also considering that some functionalities are not needed anymore, so it’s good to lose unknown and useless functionalities, and re-implemented the updated version if the users and business require those;

API should be optimised for stability, projects (what you build with a framework for example) for change, products (e.g. Symfony /Wordpress) for stable core. Agreed, again.

I spoke to guys in the sponsor stands. Interesting to see blackfire.io in action, that I’ll definitely try out next time I need to optimise an app. Interesting to see heroku to basically deploy and handle the “devops” part of an application (create server instances, install packages, manage servers, watch logs) entirely from the command line without a single SSH command inside the box. I wasn’t particularly lured by the whole SensioCloud idea, as I never felt the need for something like that, also not sure I want to use a platform created by the framework creator, that I’m not sure I can (easily) use with other frameworks.