ZendCon 2014
27 - 30 Oct 2014
at Santa Clara, CA Convention Center
Talk comments
I liked the mixture of high level "here's why you want to do this" and lower level "here's how you do this" (installation, configuration, code examples).
Talk was a bit short, there might have been time to do a bit more explanation of how the javascript/selenium2 tests looked on the code side.
No better way to get people excited about using Apigility than live-coding a file uploading, OAuth2-backed API in less than 30 minutes.
I'm excited for the upcoming time traveling system that Derick is working on for debugging. It was great to see live demos of the code tracing and even a live debugging session.
I thought the case studies here were really helpful. I came away with a lot of tips and ideas that I can use in difficult situations.
Engaging speaker and great overview of virtualization and plenty of examples / recipes too. I'm excited to try this out at work.
I love talks that provide this sort of higher level strategies. Eryn presents well and engages with the audience, which is great for keeping us awake and alert.
Slide deck was slick, but maybe a bit too much reading to us from the slides.
I loved the style of this talk and it was good to get some perspective on UX from another programmer.
This was a very helpful talk. I can't wait to check out the tools and use what I learned!
Great slides, familiar from the OSCON presentation earlier this year and full of great lessons learned.
I have some thoughts/concerns on this specific take on "double dispatch" however. Not so much that you're using something from inside the model but that I worry about it's usefulness without resorting to coupling & global state.
Any services a model internally instantiates would be isolated from the larger system that predates them. This means that they would really be little more than hideaways for code which could lead to misuse.
I'm not sure if my concerns are exceptions that one has to resign themselves to in order to leverage the pattern -- but I'd love to know a safe pattern for calling services from models without each model having to become the root of a new services graph?