Great conclusion of the conference which touched both technology and people, while people seem to be the more important part of what we're doing.
Great job, Volker!
Enjoyable talk and whilst there were a lot of questions at the end, I suspect that's because Michelle managed to get across her enthusiasm for a project most of us hadn't heard about or considered before hand. I, personally, would have liked a bit more details about how to use it in a "recommendation engine" style setup (the recipes system didn't quite show Neo4J's potential in my opinion).
A talk that went far under the hood of what's under the hood, dealing with what most PHP developers probably never have to deal with - but nonetheless leaves us with a number of suggestions of how to write better code.
Entertaining as always, Anthony is a great and very knowledgeable speaker.
Clearly, I should have studied computer science instead of dropping out of business school!
Awesome
Totally agree that we shouldn't be discriminatory against people using packages such as WordPress - it's still PHP (disclaimer: for the last 3 years, I've had around 80% of my income come from WordPress orientated work!). Yes, you might not like working with WordPress/Magento/OsCommerce/Drupal etc etc , but if you want to be able to properly call yourself a PHP developer - then it shouldn't matter.... Brilliant keynote and did seem to set the flavour for the conference.
As commented, I've found it it very hard not (!) to refactor existing code at times where a tight schedule was used as an argument to forbid it by management.
I fully agree with Robert C. Martin, Martin Fowler, and the like, who suggest to refactor along the way while you're reading code, given you intend to work on it.
Boy-scouting rules!
However, you can easily refactor yourself into a corner where no one is willing to review or merge your PR if the culture on a team / project doesn't allow for it.
Probably time to move on, then.
From the title alone I would have expected the content of the talk to be more focused on actual application architecture, but as Volker pragmatically pointed out in the closing keynote, "it depends" would be the default answer anyway.
In my experience, using diagrams has helped a lot, but I've not yet used them in an agile context.
I fully agree, though, that more time should be spent on actually designing the architecture of an application and especially discussing it.
Liked the subject and especially the part which emphasized the usage of appropriate tools that allow for reviewing as closely to the code as possible.
Agree with the commenter who pointed out that less text on the slides and more movement on stage would be a win - but I'm also aware that giving a talk is hard.
Brilliant talk - despite Lorna's warning at the start that it was for "people new to API backend/web front end", I still found it very useful and has given me some ideas - I look forward to reading her book about the subject to hopefully find out about infrastructure possibilities (how many different APIs should you have for one system: i.e. should the web site speak to a "customer" API and a "stock" API etc).
Lots of information in a short period of time - and surprised PHP 5.6 didn't seem to be referenced...Very interesting and excellent presentation, but perhaps too much to cover stopping detailing as to why/how the new sections should be used.