Dan Ackroyd

Interesting talk, and well presented, but could do with a little more energy in the presentation to get people a bit more fired up.

It was interesting.....I probably wasn't quite the target audience for this as I've use xhprof very briefly before. I think the talk might (or might not, who am I to judge) be improved by: * Explaining what the call graph diagrams mean a bit more clearly. The fact that the text on the diagram isn't easy to read probably isn't overcome-able, but explaining what the hierarchy of calls represents in general could be hammered home a bit more. And then for each of the scenarios tested, needs to be said more explicitly, as although that is clear when it's on a computer screen, it's not so clear when viewed through a projector. * The 'hook' of the talk showing that naive measuring of optimizations might not be worth the time spent on it....instead of spending the time on that, it might be worth spending time on a more complex scenario (maybe something involving Doctrine) where there can be a considerable amount of time spent on code that isn't very visible to the programmer. btw the description of the talk might be better focused - I enjoyed hearing about hearing about xhprof....but if people read the abstract and were expecting a "few options" rather than a nice focus on a particular tool, they might feel their expectations hadn't been met.

A nice little introduction to Go. Need to practice speaking very slightly more slowly. Wasn't ridiculously fast, but was quite a pace. Maybe need to break talk up into sections slightly more, with a clearer break between the sections, as the parts seemed to roll into each other. Code on slides needs to be waaaay clearer. I could read it, but only because I was directly in front and quite close to the screen. More time could have been spent on introducing channels as it's probably the most important bit of the talk. A clear "why" channels exist to begin with, then a really trivial example e.g. using the same function twice, rather than inline definition of a function, and then finally a useful example of why you would actually want to use channels.

Possible small improvement, at the end ask 'any questions' first, and only use the 'discussion provoking questions' you directed at the audience if the audience doesn't come up with their own questions unprovoked. I guess that is needed at some user groups, but other groups are good at asking questions.

I second Vítor's comment: "- add a visual diagram of commands, events, handlers and how they interact before diving in, having a (mental) image to back it up helps a lot" Even for people who've heard of them before, having a diagram that shows how they flow/interact would be useful.

I think a structural improvement could be made to the talk by breaking some of it up into 'chunks' that covered a concept, with little breaks between those chunks. Particularly for the last quarter of the talk, where it felt quite like the speaker was just going through a big list of stuff, rather than telling a coherent story. The readability of the code slides could be improved by really optimising the layout for slides e.g. Code snippets don't need declare(strict_types=1). Gray comments on gray background are never going to work. If possible losing the titles and footer for slides that have code on them would make more space avaiable. I'd change slide 91 to 98 to all be on 1 slide (possibly with each item appearing separately with fragments). This allows people to see the whole list at once when you get to the end, which makes it easier to re-read or take photo. A lot of the text could be a lot bigger. e.g. slide 12 which has "Products - Long-live projects. Open source software." There is plenty of space for both lines to be 3 times the size, which would make it easy to read at the back.

I think the slides could do with quite a bit of work to improve the legibility of them. For quite a few of the slides the code was just way too small to read even when squinting. For the slides that had images on them, those images should be 100% of the screen width and height for people to have chance to see the details on them.

Apologies in advance if this comment makes no sense, I had to nip to the loo during the talk so could have missed it if you're already doing this. I think you might be able to make the maths a bit easier to understand by showing the graph where the learning is seeking the minimum value and explain how the learning tries to get to the lowest point, before saying "in mathematics this is done by looking at the derivative and trying to find where it is zero". Although everyone will have done derivatives at school, showing the curve and saying we're trying to find the lowest point gives a much easier handle for people to grok, before throwing the big words around. Doug wrote: "I think you showed the cat example too early, it shows a complex network with lots of features before we’ve seen a simple one." - Second. Also it would be good to hold off showing any diagrams with hidden layers until a clear description of what hidden layers are, and why/when they are useful.