I enjoyed the interaction with the speaker. Teaching PHP in the academic world is apparently frowned upon, whereas there are plenty of job vacancies. To Clinton Imgrams: perhaps you can also post your situation on http://programmers.stackexchange.com/ I'm sure you'll be able to find some sympathizers.
I like the idea for this talk but I would have loved to see some more examples. I don't think analyzing the DPC website is a very realistic example; it's aiming waaaay too high. The kind of websites 'developers' make are sites like your phpDocumentor. Choosing the right fonts and colors only becomes important on the very high end websites. I think the focus should be more on content, structure and interaction.
I liked the example and the iterative build-up. I didn't like that you ended the example right when it became interesting: dependency injection. Moving the settings to a static settings.conf file would be a logical step, and adding a factory for creating the mailer resource.
Also, through the many refactorings you lost track of your original requirements. I think it's important to always go back to your requirements - unless your goal is to write a very generic mailer wrapper. Your requirements were quite humble in comparison and a simple dependency injection example, with static settings would have sufficed. The TransportLayer abstraction is technically interesting but perhaps not an ideal candidate for a stand-up presentation. Also I think dependency injection is really 'beautiful' and it suits your chosen example well.
Great talk! :)
A good introduction to Seperation of Concerns. I would have loved to see more emphasis on the conceptual benefits of adding a layer of abstraction in this manner. Adding more abstractions and complexity to your code has to come with a benefit.
The (facebook/twitter API) example was well chosen.
Joshua was "fabulous (tm)", good thing Stephan was there to keep him in check! :P
Great content, great presentation skills! Very positive and inspiring. Here is someone who has a story to tell and tells it well. I loved your short anecdotes, it gives you credibility and it's very entertaining.
"Cure first, prevent later" is a motto that applies more to Operations than Developers though, but seeing as that is your background: great!
Will you be back next year? :)
I liked the opening slides of 'what is a dependency'.
I do feel like the real-world examples were unnecessary. The interface mistake in Symfony looks more like a bad refactor (find-replace) than a real mistake. And Zend\Crypt just looks poorly designed.
I think you could add some made up examples that look like cases you found in the real-world, but are simplified. We just want to know how to spot the smells, not rant at how bad other people's code is.
I like how you handled questions from the audience.
I did notice a lack of a promised 'physical reaction' to seeing bad code, but I'll chalk that up to good presentation skills ;)
You can not squish 3 hours of material in 45 minutes.
Your opening slide looked absolutely horrendous (but I suppose that was the point?). It's fine to say you don't like Powerpoint but then you have to come up with something better. What you used instead looked like it was designed by a 15 year old who learned some 'cool CSS tricks' back in 2005 when rounded corners were hip. I understand you may need some functionality that Powerpoint doesn't have, but this was just not very good at all.
Live demos are hard to do well. We don't really care that your query ran in exactly 0.14s, we'll take your word for it, just show us how you did it. Show us the difference between `big1` and `big2`.
You seem to have a lot of expert knowledge on database systems, show us more of that and less messing about copy pasting queries in a command line.
Maybe change the title to 'API driven design'? If you're not keen on the term 'Service Oriented Architecture'. I think you were correct in identifying that PHP programmers don't like 'Enterprise' :)
Over all I liked the talk. I liked your real world example. Good presentation style.
I missed the point of this talk. I would have liked to see more about actual DDD. How you implement a traditional design in DDD? A minor gripe is that for every code sample you mentioned that it is 'simple', ok, now show me a not so simple example.
Also you mentioned some unresolved problems such as transactionality when storing messages to multiple systems (MySQL & ElasticSearch)