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.

A few days ago I got involved in a chat about the usage of Object-oriented design patterns. I brought up the problematic of their usage when not needed, that ends up in adapting the code to the pattern and altering it, risking to increase its complexity. I mentioned an example of usage of the Observer design pattern, that I’ve seen used even where one object A (Subject) just needed to keep an array of reference of objects B (Observers), but B didn’t actually need to refer back to A.

From Wikipedia: The observer pattern is a software design pattern in which an object, called the subject, maintains a list of its dependents, called observers, and notifies them automatically of any state changes, usually by calling one of their methods.

In this post, I’ll expose a case where the usage of that pattern is very simple to understand: a Newsletter system, with senders (Subject) and subscribers (Observers).

In this example, we have two users, John and Mike who both subscribe to the NewsletterSender (Subject). When the email is sent, both are notified by NewsletterSender::notifySubscribers() that iterates the users and call their update() passing its reference. Via this reference, the users will then be able to call the getter to read the email. So, John and Mike will both receive the reference to the NewsletterSender, John will print out the email text, but Mike only decides to say that there is an email (different implementation).

See the comment near each method with the classes and method names of the corresponding PHP interfaces SplObserver and SplSubject