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.

HI Ismael, I enjoyed the talk, and if you're going to give it again in the future, I think there's a few areas where it could be improved with the same content. # Couple of things that I'm pretty sure about: * Please practice not looking at the slides, and preferably not even pointing at the slides. Although there can be exceptions for when you're guiding the audience through a complicated diagram, in general, every speaker should have their eyes facing the audience the whole time. It's much, much easier for the audience to follow what you're saying when you are talking to them, rather than looking at the screen. * The slides could do with some optimisation. You can be much more aggressive using the top space on a slide - there are very very venues where the top of slides are cut-off, so the content can be almost hard against the top. Currently the title for the slides is taking up almost 50% of each slide. I think the title could be moved to the top, into the border space currently available, and then the content could take 100% of the remaining space. * It would be worth breaking the talk into sections, and deliberately having breaks between those sections where you wrap up what that section was about, take 3 breaths and then introduce the next section. This would allow people in the audience to also take a break and mentally reset their brains, which makes it easier to follow for the whole talk. Currently you moved from each slide to the next without pause, which makes it hard for people to keep up all the way through the talk. # Now, the big thing that I am less sure about, but think it's worth suggesting: I think the structure of the talk could be re-arranged in a way that would make it much easier for people to follow, particularly for an audience of PHP developers, who are going to be less familiar with the topic of the talk than other audiences might be. As it was given, it was kind of hard for me to follow the talk, as the definition of what PWA is was after quite a few slides. Additionally, if information can be given as a story, because of the way human brains work it is almost always easier for people to follow a story, than just facts on their own. ## Act 1 - Introduce the problem. * We have web pages - the problem with these are no offline capabilities, restricted access to hardware etc, etc, etc. * We have applications - the problem with these are need to be installed, hard to update etc, etc. * "This caused a problem for big companies like google and facebook" Re-use the (almost?) first slide from the current talk with the how this gap between the webpages + apps, caused a problem for Google and Facebook and how their engineers wanted to come up with a solution ## Act 2 - Introduce the solution. * "So, these people at Google and Facebook came up with this solution" Really cleanly define what a progressive web app is preferably in as non-technical terms as possible i.e. not starting off with talking about manifests, but how the appear to end-users and what the experience is using them. * "What do PWAs allow us to do that is better than webpages/apps" - Describe what PWAs allow us to do that is better than webpages/apps. * "And this is what users experience" - Although putting a list of technical reasons why PWAs are better onto a slide is a good idea, rather than reading through the list, instead it would be better to just say "this is a list of PWA features, but we don't have enough time to talk about all of them. I think this one (or two) is the most important so lets look at this:" and then do a deep dive on that one (or two) features and show what the user experience is like through a recorded demonstration. That would allow people to see the benefits even if they didn't understand why the user experience would be better. ## Act 3 - How do we use the solution * "So how do we make PWAs" - at this point get into the tech details of manifest files and all the other details of how to get PWAs onto people's phones. * All other relevant technical details and maybe some downsides to using PWAs. Coda - Summary It would be worth just summarising again the key points from the talk, just to try to embed those key points in people's minds. * What the problem is - Web pages + apps both have downside * How PWAs solve it - PWAs allow us to have a nice 'in the middle' solution. * What the tech looks like. I hope the above is useful, and doesn't sound too negative.

Replace the “60% of the time” quote with developers looking for bugs under a streetlight https://en.m.wikipedia.org/wiki/Streetlight_effect

I think spending more time on why rewrites are bound to fail would improve the talk, as it's an important point, and although I agree with what was said, if I hadn't already heard the arguments in depth before the talk, I doubt I would have been convinced during the talk. If you can, end the talk on a solid take-away point, rather than a list of stuff as it gives a 'stronger' impression. The readability of the slides could be improved: * For the non-code slides, just use all the space available rather than just the middle and decide if you want the background light, then have all dark fonts, or a dark background and light text. * For the code slides, again use way more space but also optimise the code formatting for a presentation rather than editing the code. * We're not staring at the code for ages, so it's better to use a black background rather than they dark grey of an IDE theme. * The slides don't need '

Huh. It's possible my comment got chopped off due to a malfunctioning filter. I'd put "The slides don't need ' < ? php ' at the start of each of them", which presumably got chopped off as a hack attempt....continuing the other stuff that was lost: Also, although I agree that brackets belong on the next line when writing code, for slides have the { on the end of the method declaration line saves a whole line of space. Finally blue and green should be avoided as text colours. People's eyes find it much harder to resolve blue colours than red, and slightly harder to resolve green than red. Changing from colours that are appropriate in an ide, to very light pastel colours will make the text easier to read. e.g. even as bright as #dfdfff is noticeably blue in slides, but is much brighter and so stands out much better.