I'm not adding anything new here, but I think diagrams instead of code examples would certainly work wonders. The terms (async, websockets) as well as libraries (react, ratchet) are unknown to most. Paint a picture of your non-blocking way of doing things by show a blocking example side-by-side.
Also, you gave an example after the talk in which you desribed reading from and writing to multiple (huge) files at the samen time. This is something people can relate to, a problem you can 'fix' for them with an async solution.
Finally - someone in the audience asked you to demo your project. I think your projects should in *in* the talk, so you can show the different moving parts in action. Not just from a search-and-result point of view, but starting with the request, follow that request to the db and back.
It's two thumbs up now, but you will certainly improve by doing this talk more often. Keep it up!
PS: small note - you paused quite often to take a drink. That took the flow out of the talk once or twice.
I agree with the comments above that your presentation skills are in shape and they will even improve by giving more talks.
I also agree that a demo with some context will be nice! Next to that you missed an big chance to show off the awesome presentation tool you where using, especially as that tool used the same concepts.
Another thing that can improve is the way you ask the crowd your questions. There is a huge difference in the response and interaction you get in the way you formulate them.
For instance 'is everybody familiar with PubSub' or 'who is familiar with PubSub' are almost the same, but I reckon the latter will get more response. Next to the difference in response you can also focus on the group of people that did not raised their hands.
Special credit for explicitly asking for feedback and presenting in a second language. You also repeated most of the questions from the audience, which is nice.
Hi Cees-Jan,
Thank you for the talk. As Herberto says, your presentation techniques where good and your presentation came across as well prepared.
To improve it a bit in the future, I would suggest starting off with a small demo or introduction showing what you are doing (so the domain you are working in, the problem you are trying to solve). This gives your audience some orientation.
Also, since you where addressing multiple services, you might want to slip in some schematic overviews of you services layout, showing the system parts, their responsibilities and the way they interact.
Thanks again and see you at the next meetup,
Johan Groenen
You had a good positioning on set, you had a good movement during the talk ( didn't cross the beam, were positioned enough on the side as to not cover the screen for the ppl on the sides), you spoke with the right volume and clear enough (although it could be better), the slides were plain and visually clear which is great, and you clearly knew what you were talking about.
However, this talk was not adequate for the audience you had. Maybe it would be good for ppl with experience about nodeJs or even reactphp, but I don't think the vast majority of the audience has any of those, I think most of them were there because reactphp is new to them and they wanted to learn something. I'm guessing about other ppl so I might be wrong, but that was definitely my case.
So, if you wanna do a presentation for all levels of knowledge about the content, the first thing to explain is the concept (ie before making a chair you have to know what a chair is, why it's used and how it's generically used), only after that you start explaining the implementation details of the concept (ie how the chair is actually used and/or built).
Let me start by stating that different ppl learn different contents in different ways. However, concepts are somewhat abstract and, as such, they are better explained with drawings, sketches, schemas.
The audience in a talk will not have the time and/or focus to understand a piece of code, specially if they don't have experience with the subject. And they will surely not remember the code examples. There's just too many details.
However, a good schema, they will remember for some time and will help grasp the concept. And of course the concept will be remembered, if they understand it during the talk.
You also talked about other libraries, which you assumed ppl were familiar with. Well, I wasn't, I still am not, I don't remember their names, nor what they are used for, nor why were they relevant for the talk. Again, a schema with an example of what they are used for, why they are needed, why they are a relevant example, would have been great.
Bottom line, I still don't know what is reactphp (nor nodeJs). Whats new about it? Ok, it provides for async calls, but we already did that with ajax a few years ago, so what's the difference? When should we use it? Why couldn't you do your map project with a regular framework and had to do it with reactphp? What do you mean by "symfony blocks everything"?
I'm sorry I'm giving you such a negative feedback, you do seem to have a lot of knowledge about the subject and I'm sure you have all the answers to my questions, so I truly hope my feedback improves your talk and presentation skills so next time you pass on to me some of that cool knowledge you have.
I was going to post a really long comment about this, but I will simply agree what previous people have said. As a new speaker you did great, and I'm sure with more practise and taking in the tips and criticism already posted you will grow to be awesome - Thank you for a great talk and I'm looking forward to hearing you speak at conferences.