Talk comments

Always good to see this talked about. Extremely important. Easy delivery. Good to see the content evolve over time. I like the idea of the compiled, ready to go resource list, and I'm looking forward to the documentation that's coming.

Good overview of important principles. It was nice to see the user-based focus on APIs and where the pitfalls were if you did not. The car/driver analogy was particularly apt. apiux.com was a good find too. I hadn't considered specifically documenting what a breaking change was, either. Clearly speaking from a wealth of experience, and comfortable delivery. Image credits were a nice touch too.

An excellent talk, and the ideas and resources presented by Ed will be instrumental in my development as a manager and a peer.

Anonymous at 14:23 on 22 Aug 2015

Informative. Sandy stated things well

Anonymous at 12:41 on 22 Aug 2015

GREAT! Brian knowledge and provide useful tips/advice

Anonymous at 12:41 on 22 Aug 2015

Some examples surrounding abstraction vs extensibility would have been useful.

Perhaps showing how building low level, single responsibility classes or API endpoint allow for better composibility, but are harder to use for the simple use-case that someone might want. But on the flip side, you can wrap those small components in increasingly more use-case oriented facades to expose an API that expresses intent, and is easy to use.

That would give you the best of both worlds. And by starting out with small, single-purpose Apis/components, you can assemble them together in ways you've observed your users consuming them - that is identity and extract use cases and expose Apis that express those use cases.

Enjoyable, interesting overview of testing approaches, with good tips for solving particular problems. I had initially expected it would go down the phpSpec/BDD route, but it seemed to cover general testing philosophies and approaches with specific application to PHP.

The section on downsides and appropriate use cases was great. I think some more strategies and real world use cases would have really helped clarify when to use queues.