PHPBenelux Conference 2013
25 - 26 Jan 2013 at Ter Elst

Very solid (no pun intended :D) workshop on improving your code to make it more testable. Too bad it was really too short, I wouldn't have minded to continue hacking on a testable tic-tac-toe game in the afternoon to get that little extra.

Can we have a stressball fight again next year?

Good and approachable overview. Made me understand the architecture of ZF2 although (unfortunately) I haven't worked with it, nor with ZF1.

Good one for a first timer. Good explanation, clear slides, keep up the good work!

I knew about Sonar, but didn't pay much attention to it just yet. It's an interesting tool, but with all those metrics: there's some theory behind every metric. If you know what you're doing (you know what the metrics stand for) this can be a powerful tool. The last part of the demo was a little bit chaotic and could've used some more structure.

I especially liked the beginning of the presentation: the psychological part, seeing developers as actual people and holding them a kind of mirror for some good old self-reflection :-)

Am I the only one who actually found this talk quite interesting? I found the start not that inviting, but after that I found it very informative. If I know HOW it works, I know what to extend and why particular behavior occurs. That was what this talk provided to me. The overview on the CMF architecture and which Symfony parts you've changed was great to see!
Before this talk I've played with the demo from which you can't see or guess that the code behind it is technically advanced stuff. I've worked with RDF earlier (protein sets) in Bioinformatics, but I've never seen RDF put to work combined with Javascript. That opened my eyes that sometimes I should look further than the 'common' techniques we all use on a daily basis.

Seeing how to get started with it was on my list for some time, and this talk gave me the info I needed. Thanks!

I agree with all above: a complete and good overview. Clear explanations, implications and examples. Very good and really useful!
One thing: the sound volume was quite high. Don't know if it was the setting of the mic or just your voice.

This indeed was a listing of tools. But it was a good one! Such talks are part of the reason why I go to conferences: I want to hear about (new or already familiar) tools, what they provide and a quick code example to give me that offset I need to get started. After that I'll figure it out myself.

I have mixed feelings with this talk. It was definitely aimed at beginners with little to no experience with design patterns. I think the general approach to the subject is actually quite good, but the content could use a little bit of work. I think that the delivery was excellent.

As far as the content:

I feel that the treatment of the Facade pattern left a lot to be desired. The way it was described by Hugo personally wasn't bad, but the example showed was not really good for understanding the Facade pattern, down to the point that the way it was presented basically implies that any class is a Facade since it abstracts functionality. The traditional definition of the Facade pattern ( http://sourcemaking.com/design_patterns/facade ) is more that it abstracts a series of other classes, providing a simpler interface. Since the provided "Facade" example only called methods on itself, it really just felt like a regular class, and not abstracting other classes. This created quite a confusing message that I feel did the pattern disjustice. I would have preferred to see other external classes being called to enforce the message that it's abstracting a series of classes, not just functinality...

The treatment of the Adapter pattern ( http://sourcemaking.com/design_patterns/facade ) I also felt left something to be desired. I feel that it should have been made clearer the relationship of adapters to groups of code. The way the example was presented, where the final class depended on an instance of the WeatherServiceAdapter blurs this line further. In a proper Adapter implementation, the adapter adapts one interface to another. Not to itself. So a clearer example may have depended on an implementation of a WeatherService interface, which the adapter resolved. This makes it clear that you're not depending on receiving an "adapter", but an interface that can be an adapter, or a concrete dependency directly. While this may seem like a minor point, I think it's extremely fundamental to the understanding of an Adapter. It converts one *interface* to *another*. So it's an abstraction that neither class (the class you pass it into, and the class/layer it "wraps") should ever know about or depend upon.

I think the Template Method pattern was dealt with quite nicely.

I also feel the Strategy pattern was handled well.

The Decorator pattern I felt missed a bit. The UML that was displayed was basically identical to Bridge, considering that the root element wasn't distinguished that it was an interface, not a class. This made it rather confusing in the context (to me). Additionally, the cons listed for the Decorator also leave a bit to be desired IMHO, as the opposite usually applies (construction becomes easier, and testing becomes easier).

I think the treatment of the Composite pattern was absolutely excellent. The use of the form example I feel fit really nicely and it clearly showed the usefulness of the pattern. In my opinion, it's a pattern that's pretty easy to explain, but quite hard for most people to grasp the benefits. But the way you presented the example, and the pattern was really good, and worked well for me.

I felt that the treatment of the template method was pretty good as well. The only suggestion that I have there is to provide one final example slide bringing it together (showing why it's useful). One thing that I found confusing with the example was the interchange between "file" and "document". The factory's method was "newDocument", but the factory classes were named "ImageFile" and "TextFile". This felt off, as a File is usually a special instance, or a serialization of a document. So perhaps I'm just getting hung up on the names, but something that could be cleared up (again, not a major issue)...

The coverage of Observer was pretty good. The only issue that I had is that you mentioned "Symfony's Event Dispatcher is an Observer". It's not. It's an implementation of the Mediator pattern. It's a very similar concept, but they have very different semantics. The Observer requires listeners to bind directly on the object that raises events. With the mediator, you have a middle layer that handles and "routes" events. An observer couples the object instances together, where the mediator decouples them. Therefore, the Event Dispatcher in Symfony 2 is a mediator by definition.

So definitely a talk with a lot of potential.