I am excited about the potential of Puli now. Great talk.
It was interesting to hear this talk from someone from the core Doctrine team. I took a lot of notes, and I think it was definitely worth attending. I agree that the speaker had an opinionated "this is the only way to use it" approach, but I think that was very much intentional.
Great examples, and very informative.
Excellent speaker and great talk. The build-up to the problem, with a history of MVC on desktops, followed by a well thought out refinement of MVC for the server was engaging to watch. I will be looking further into ADR.
Informative and fun talk. I especially liked the real-time Rx (reactive extensions) portion of the talk. I had no idea that I could use angular.js that cleanly without being forced to use their 2-way data bindings!
Short but sweet. I was inspired to attend the after-party.
What else is there to say...important subject talked about with the amount of passion it deserves. A+.
Great talk. Although I already use postman it was refreshing to see the other options out there and the pros and cons of using proxies. Talk was definitely well delivered and fun. Gotta love Keith's enthusiasm.
Great talk. My only nitpick is that it felt rushed at times. Lots to digest in regards to not only obvious application security concerns but exceptionally clever means of bypassing traditional best practices.
Chase: as Chris said, this tone was indeed intentional.
Consider that I spent the last 5 years helping out folks that get trapped in ORM internal behaviors because of them mixing behavior with persistence, or because they were building an anemic domain with a "smart-ui" (which is an anti-pattern) on top of that.
This is the main reason why I designed this talk: helping people _before_ they build an unmanageable trap that leads to accusing the ORM (this happens _every_ time) of being slow or complex.
The entire philosophy of the talk revolves around keeping it simple and OO-based, and since it is an ORM (object mapper), if you don't do OO-based, then a Table-Data-Gateway approach is sufficient, for example.
We basically do the non-OO part for you, but if you also keep doing it that way (for example via getter-setter), then you are just making your life more complicated than it actually is needed to be :-D